Embedded Solutions for Real-time applications.

The design of softwares intended to be embedded must satisfy several criteria. Some of these criteria are imposed by the specific environment (real-time, limited resources, security, etc.) in which these software will operate. Others are linked to the normal software design process.

• Modularity: The complexity of a software requires the designer to divide it into smaller components which can be developed, implemented and tested individually.
• Openness: The software must be developed gradually, new components must be added by different actors, while reusing the existing components.
• Flexibility: The software must have a flexible structure making it easy to add or remove software components during or after the development phase.
• Real time: A control signal must be generated in any circumstances and within a determined time.
• Constraints management: The vehicle must be able to reach the long-term objectives of the mission while responding to immediate constraints.
• Reliability and robustness: The software must be able to execute a planned sequence of objectives in the presence of uncertainties and to manage situations whose occurrence is temporally unpredictable.
• Monitoring: The software must check the proper functioning of all the instrumentation, detect and react adequately to any failure.

In software architecture, the complete realization of a given task, such as trajectory tracking, requires several modules. The different phases of the task are expressed by the execution of these modules in which each implement algorithms specific to the role they play in the realization of the task (acquisition of a sensor measurement, calculation of the control law, application from control to actuators).

The interfaces of each module consist of two parts: one relating to the activity control interactions of a module "control flow" and the other relating to interactions in terms of data exchange and events (data flow). Respecting these interfaces during implementation allows, for the same module, to a very advanced phase of development (production of executable for example) without requiring knowledge of algorithms implemented by other modules.

This makes it possible to develop several modules in parallel and assemble them in a last step, on the same “infrastructure” i.e. “system” environment providing execution services). In addition to saving time due to the parallelization of IT developments, this approach also allows several engineers to take part in development of control software. This is especially important since the development of controllers in embedded systems is the responsibility of actors with different skills and roles.

A “middleware” (execution infrastructure) common to all implementations must also be provided to the actors involved. This “middleware” constitutes an abstraction of the operating system facilitating the portability of software from a platform to another (no explicit system call within the modules). But this “middleware” offers, above all, an API which makes available to the programmers a set of mechanisms usable, both for the implementation of a module and for module composition (communication with peripherals, inter-module communication, etc.).