Usine Logicielle

The Inflexion’s sub-project objective is to define a flexible and optimised execution platform dedi-cated to embedded real-time systems. This platform will be compliant with the component/container architecture principles which allows a true separation of functional concerns (or business) and non functional concerns (or technical services). The inflexion platform will facilitate the design of systems by assembly of components and will facilitate the reuse of existing ones.
Inflexion extends the tasks already started on the theme of components based infrastructures for RTE systems by bringing the following innova-tions.

 

 

Furthermore, the design and assembly of a system running on top of Inflexion will be realised using the MDE IDE supplied by OpenDevFactory.

 

 
Inflexion’s Architecture

 

The container :
The container is the key architectural element of the component/container organisation. It isolates the components it protects from the underlying platform and provides the non functional properties which are required (temporal requirements, fault tolerance). These non functional properties are specified by the means of descriptors which allow attaching quality of Service requirements to the functional connectors of the components. As indicated on the right hand side of the above diagram, a tool for automating the generation of containers (parameterized by the descriptors of the compo-nents that they will host) is an inherent part of the environment provided services.

 

The administration service:
This environment service figuring on the left hand side of the hereunder diagram allows the display and configuration of the components and their containers then the supervision of the system and its reconfiguration in case of drifting. As a consequence, this component is highly impacted by the project’s innovations (fault tolerance and dynamic reconfiguration.)
In fact it must then support the starting, the stopping and the modification of one part of the system (and not of its entirety) while keeping a whole consistent execution. It must cope also with the partial failure of reconfiguration operations and allow their roll back. Finally, it must keep the system in a “fault tolerant” state while supervising the components state (active and passive) in collaboration with the containers that supervise them continuously.

Fault tolerance:
Fault tolerance is an extremely vast field. The first step is to define the taxonomy of faults and their management strategies that the project will address. On this basis, the model of fault tolerance for an application must be established. This model must in particular specify the criticality which applies to certain parts of the application (in most cases, dealing with the whole system at the highest degree of criticality is not realistic.) and the fault tolerance strategies (types of faults to detect, hardware faults, deadlines failure, time drifting, numerical exceptions, management strategies, redundancy, reconfiguration…) that we want to put in place.
This model is then taken into account (for use) by the administration service in collaboration with the dedicated support integrated in the containers:

 

Reconfiguration :
Dynamic reconfiguration capability is more and more requested to embedded systems and will become essential as soon as we will want to integrate them in “systems of systems” which composition is by essence much more dynamic than that of the classical systems.
Similarly to fault tolerance, reconfigurability has an impact both on the containers that implement the low level mechanisms and on the administration service that coordinates their activation (this last point is very important in order to minimize the risks for a system that a reconfiguration makes it unavailable in particular when the aim is to make systems tolerant to faults.) We should notice that these two new improvements (fault tolerance and reconfiguration) reinforce each others harmoni-ously because some fault management strategies will make use of the reconfiguration capability.

Integration to OpenDevFactory
In order to benefit from this type of architecture in terms of productivity improvement and to facilitate its adoption, it is important that the generation of the execution’s environment (the containers) and the various descriptors that are necessary to its operation (descriptors of components, descriptors of assemblies) be integrated in the tool chain developed in OpenDevFactory.

This integration requires that there exists an application model that correspond to the application’s execution platform view. One of the project’s objectives will be to define this execution platform’s meta-model. Then specific pluggings will be designed in order to allow the generation of descriptors from the application model and the triggering in a very transparent way of the generation tools environment.