Keywords: engine management, real time, integration, dynamic architecture, scheduling, data consistency

This dynamic facet is characterized by sporadic events, time events in a range of 1 millisecond (ms) to 1 second (s), and angular events in a range of 0.5ms to 100ms depending on engine configuration and speed. The EMS functions have to be called from these events, and in addition to their recurrence, they may have phasing, sequencing, and also deadline constraints.

Typical problems in the dynamic behavior are infinite loops, wrong initializations of pointers, stack overflows, recursivity, wrong calculation sequences, data inconsistencies, and deadline misses. Whereas some of these errors are intrinsic to SW-components (SW-C), others are related to their integration within the project. In other words, the same SW-C may show a correct behavior in one project, but an incorrect behavior in another project, because of integration failure, or different integration contexts.

After an overall description of the EMS context, we will describe in this paper the most common integration failures with impact on dynamic behavior, and means to avoid them. We will also show the importance of the architecture and integration activities in the specific area of engine management, in particular due to the above mentioned constraint of strong coupling.

Engine management software dynamic architecture versus integration

D. Claraz 1 , M. Niemetz [START_REF] Claraz | Fiabilité des logiciels embarqués, exemple architecture dynamique logicielle d'un contrôle moteur[END_REF] 1: Continental Automotive France SAS, 1, av. Paul Ourliac, BP 1149, Toulouse -France 2: Continental Automotive Germany AG, Siemensstr.12, Regensburg -Germany

Abstract

Variability, hard real time, increasing functional complexity (due to emissions and driveability standards), limited hardware (HW) resources : these are some of the -sometimes antagonisticconstraints a modern Engine Management Software (EMS) has to deal with. In addition, to face the price reductions in the automotive electronics industry, an intensive reuse strategy is deployed, based on a platform architecture and a component based development, despite the high functional coupling between those components, characteristic to the engine management area. To respond to these constraints, a static (or functional) architecture defines the split of the software (SW) into compilation units: modules or aggregations of modules. This static architecture mostly focuses on reuse and decoupling of functions. It is in general well managed, documented, and supported by tools.

In parallel to this static facet, to respond to the real time requirements, the dynamic architecture defines the split of the SW into execution units: functions, tasks, interruptions. This part of the architecture is often underestimated, poorly documented, and insufficiently supported by tools.

Context of Engine Management Software

A high end Electronic Control Unit (ECU) may have up to 200 connectors, 250.000 lines of code, and around 1000 functions to control all sensors and actuators needed to manage the combustion process of the engine.

Fig. 2: Gasoline direct injection system

The architecture of the software is mostly impacted by the following constraints:

Coupling between EMS functions:

An EMS is a system with a high functional cohesion.

There are only few functions mapped to an EMS, which could be exported to another ECU of the vehicle. These functions interact together either directly or through the engine and the components they control, and thus can hardly be managed independently.

Fig. 3: All sensors and actuators managed by EMS are involved in the same physical process For instance, misfire, injection and ignition functions depend on each other and participate all to the same combustion process. They are interacting together, and thus communicate by exchanging data. In the following figure, we give an overview of the coupling of the main EMS functions on a typical high end project.

Fig. 4: Coupling between main EMS functions

On this graphic, each dot represents interfaces (links) between the functions. In particular, we see that there is nearly no 1:1 link between functions, and that most of the functions are linked to many other ones. To be more concrete, typical variables of the system like engine speed, coolant temperature, ignition key, ... are needed in more than 100 modules, spread in around 50 functions. This strong coupling between functions creates one of the most important constraints on the architecture, and is specific to Engine Management Systems.

Variability:

Due to the reuse objectives, the configurability of the EMS SW is a key issue, in order to avoid parallel branches, expensive to maintain. EMS applications are similar, but have also a big level of variability, due to different engine architectures, sensor and actuator positions or electrical characteristics. This variability is much higher at the supplier side than the OEM side, due to a multi-customer and multiengine orientation.

As an example, the figure below shows the diversity of camshaft target profiles that have to be handled by the same SW. EGCP 250 12 490 5 0 11 3 14 0 3 2 5 2 1 0 1 13 3 0 1 0 2 0 1 1 3 0 6 0 1 0 0 0 0 0 0 0 0 0 INSY 80 337 0 6 15 17 11 7 0 2 2 3 0 1 2 1 1 0 0 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 2 0 1 CHRG 80 28 0 5 298 9 0 0 0 1 0 0 1 1 1 4 0 0 0 0 0 0 0 2 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 ERRM 243 31 21 6 5 11 8 16 2 11 6 4 1 2 1 0 3 6 3 2 0 8 5 0 3 5 2 2 0 1 0 2 0 1 0 0 2 0 0 EGTR 240 10 14 4 0 11 1 11 0 3 2 3 2 0 0 0 101 3 0 1 0 1 0 1 1 2 0 0 0 1 0 0 0 0 0 0 0 0 0 VVLI 43 9 2 10 0 0 200 5 0 1 7 1 0 5 0 1 0 1 1 0 0 0 0 1 2 0 0 0 1 0 0 0 0 0 0 0 0 0 0 ECM2 6 3 1 4 0 11 1 3 190 3 2 0 6 5 11 4 0 0 16 1 18 2 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 EVAM 144 12 0 2 0 8 2 3 0 2 2 5 1 0 0 0 0 0 2 101 0 0 0 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 ENSD 40 0 0 208 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 LACO 11 12 16 6 0 3 1 164 0 3 3 9 3 0 2 0 5 3 0 4 0 1 0 1 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 VVTI 28 4 0 6 0 8 7 0 0 2 165 0 0 3 0 1 0 0 0 0 0 0 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0 1 ENSC 72 6 0 8 0 13 0 2 0 3 2 1 0 0 1 3 1 0 86 1 0 0 0 3 1 0 0 1 2 1 0 0 0 0 0 0 0 0 0 AIRT 67 12 0 5 4 0 4 0 0 4 0 0 0 0 0 1 0 0 0 0 0 0 105 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 EVAC 4 9 5 3 0 2 0 12 0 2 2 141 2 2 4 1 1 1 0 6 0 3 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 THRO 19 7 0 2 0 162 2 0 1 2 0 0 0 1 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 INJR 6 2 0 10 0 1 5 0 1 2 0 0 126 1 17 1 1 2 0 0 5 2 0 4 6 0 0 2 2 1 0 0 0 1 0 0 0 0 0 TQSP 6 3 0 3 1 5 4 0 5 2 0 1 1 27 1 85 0 0 9 0 0 5 0 7 1 1 1 0 7 0 0 0 0 1 1 0 0 0 0 ENTE 41 9 0 4 0 0 0 0 0 115 0 0 0 0 0 1 0 0 0 1 0 0 3 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FMSP 0 9 0 6 0 2 8 3 0 4 1 0 6 1 103 2 0 0 1 1 0 3 0 6 10 0 0 0 0 1 0 0 0 1 0 0 0 0 0 MISF 23 3 2 6 0 4 2 0 0 2 1 0 5 3 0 0 0 96 0 1 0 0 0 1 1 1 0 0 0 3 0 0 0 0 0 0 0 0 0 FUSL 21 0 2 4 0 0 1 6 0 4 0 2 3 1 2 2 1 2 0 2 0 87 0 5 7 0 0 0 0 0 0 0 0 0 0 0 1 0 0 TQDR 0 9 0 4 0 1 3 0 0 2 0 0 2 91 0 14 0 0 4 0 0 0 0 1 0 0 1 0 0 1 0 0 1 1 0 0 0 0 0 KNCK 22 4 0 8 0 3 1 0 0 2 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 86 0 1 1 0 0 0 0 0 0 0 0 0 EXTD 23 2 2 1 1 0 1 0 0 4 0 0 2 1 2 0 1 0 0 0 0 0 0 0 2 83 0 0 0 0 0 0 0 0 0 0 0 0 0 EXTC 1 8 0 4 1 3 1 2 0 3 2 0 2 3 2 4 1 1 0 1 0 1 0 72 1 5 0 0 1 1 0 0 0 0 0 0 0 0 0 ALAM 1 2 4 3 0 0 0 16 0 1 2 2 1 0 0 1 0 2 0 0 0 0 0 2 0 1 0 67 0 0 0 0 0 0 0 0 0 0 0 ECM3 4 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 95 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IGRE 27 2 0 9 0 1 0 0 0 1 0 0 1 0 0 1 0 1 0 0 0 0 0 0 2 0 0 0 0 55 0 0 0 0 0 0 0 0 0 DRVB 0 0 0 4 0 0 1 0 0 1 0 0 1 1 0 4 0 0 3 0 0 0 0 0 0 0 0 0 61 0 0 0 0 0 0 0 0 0 0 ENRD 8 2 0 9 0 4 0 0 0 1 0 0 1 0 0 0 0 4 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ENSS 6 0 0 3 0 0 0 0 0 2 0 0 2 0 1 0 1 0 0 0 0 1 0 0 48 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IGSP 0 3 0 3 0 0 9 0 0 1 0 0 0 3 4 1 0 0 0 0 0 0 0 1 3 0 1 0 0 0 0 0 24 0 0 0 0 0 0 DRRQ 16 0 0 2 0 0 0 0 1 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 31 0 0 0 0 0 0 0 FUTL 8 0 0 1 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 35 0 0 0 0 0 0 0 0 TQLO 1 4 0 2 0 2 2 2 1 4 2 0 1 0 1 0 0 1 3 1 0 1 0 0 0 0 0 0 0 1 0 0 0 15 0 0 0 0 0 ENSL 0 0 0 5 0 3 1 0 2 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 11 0 0 0 0 LASP 0 1 2 1 0 0 0 0 0 2 0 0 0 3 0 1 2 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 7 0 AVIM 6 3 0 3 0 0 0 0 0 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 3 EGPR 0 3 0 1 4 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 0 0 0 AEFP 7 0 0 2 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 In total, more than 160 points of configuration are needed to configure the acquisition of engine position and speed, depending on the shape of the crankshaft, the type and position of sensors, the type of diagnosis, etc... For a complete application, more than 10.000 points of configuration are used.

Real time:

As the physical process in a combustion engine is fast and repetitive, an EMS is a fast system: Acquisitions, diagnosis, treatments, and corrections on control strategies are done very often. To reach new emission regulations, new functionalities require multiple acquisitions of the same parameter and multiple actuations of the same output within one same combustion cycle. Engine synchronous calculations may have a recurrence of 2.5 ms on 8 cylinder systems, and fast time bases like 5 ms are widely used. As a result, around 80% of the calculations are executed within a 10ms (or faster) time frame. In addition to this speed, the complexity of an EMS is due to the mixture between sporadic events (like for instance an ignition key transition), time periodic events, and angle periodic events. For instance, many calculations are synchronous to the crankshaft position. Their recurrence is variable, and can range from 100ms at low engine speed to 5ms at high engine speed, for a 4 cylinders engine. In total, around 70 different events are needed with sometimes precise phasing or deadlines needs.

Fig. 7: Time and Angle based events

Reuse:

As mentioned, reuse is a key driver of the architecture, in order to reach productivity objectives inherent to the automotive electronics industry. This reuse impacts mostly the static architecture, i.e. the split into functional bricks. The decoupling of functionalities is done using a top-down approach and an aggregate concept already described in ERTS2004 [1]. This is done through a better and formalized management of interfaces, and through an application of abstraction principle, in order to define sub-packages (aggregates) with a high internal coherency.

Time Events

Hardware resources:

In order to minimize the ECU price, the RAM, ROM and CPU load consumptions have to be limited. The balance has to be done between the economy of HW resources and the typical objectives of maintainability, testability, and in particular reusability. In the simple example shown below, a calculation done every top dead center (tdc) depends on interpolations on input variables with different dynamics. Some of them change every tdc, but some other only every 100ms or every 1s. To ease the integration (testability and maintainability) of such a function, a monolithic calculation every tdc would be the best choice. But this would cost approximately twice the CPU load as a calculation optimized according to the input variables dynamics.

Business model:

With the introduction of OSEK in 2001, a fundamental change of the business process has been initiated: before that date, the complete SW embedded in the ECU was developed by the supplier (based on own, or on OEM specifications). Today, a complete project is -and will be more and more -built from individual SW-C coming from the OEMs, suppliers, tool vendors, and even competitors. The formats of the SW-C to be integrated are disparate (C, obj, libraries, MDL, XML), and have increasing impact on the architecture. For instance, a non-negligible part of the CPU, RAM, ROM is dedicated to interface adaptation.

Different views on an EMS architecture

According to the above constraints, the EMS architecture is split into different facets (or areas), corresponding to different types of problems. Architectural choices and mechanisms are defined in each of these areas, and may apply either to a complete platform (or product line, or project family), to a single project, or finally to a single function. The Static architecture , or functional architecture, aims to split the system into functional abstractions, with an objective of decoupling functionalities. These functional abstractions will be either modules (i.e. compilation units, SW-Cs), or groups of SW-Cs. These SW-Cs will be the base for reuse, or for distributed development [START_REF] Claraz | Reuse Strategy at Siemens VDO Automotive : The EMS 2 Powertrain Platform Architecture[END_REF] .

Typical topics of static architecture are: -In which SW-C to locate the torque correction due to air conditioning? -Is it possible to exchange calibration data between SW-Cs? Which kind of exchange is allowed? Why? The Layer architecture defines the split into hardware abstractions, with an objective of independence from microcontroller, hardware, or [START_REF] Claraz | Reuse Strategy at Siemens VDO Automotive : The EMS 2 Powertrain Platform Architecture[END_REF] With increasing size and complexity of applications, a good partitioning is becoming essential to reduce coupling, allow work split between teams, and ease further integration. The "Configurational" architecture focuses on the management of the variability, with an objective of reducing its impact on development effort and hardware resources. Once integrated in a project, a SW-C designed to be "configurable" will then become "configured". This configuration can be done either at "build time" (same source code, different executables), at "runtime" (same source code, same executable, different parameters), or both.

Examples of topics related to this facet are:

-How to decouple the ignition functionality from the number of cylinders? -How to encapsulate the diversity? How to handle its impact on the interfaces?

The Dynamic architecture, finally, aims to split the system into execution units (i.e. tasks), with an objective of schedulability and efficiency. This facet is described in the following chapter.

Dynamic architecture of an EMS

As described before, an EMS is stimulated by around 70 sporadic, periodic, or angular events, mostly represented by Operating System tasks. The phasing between these events is sometimes important, and for one same recurrence, there might be different events with different phasing. For instance, in order to be precise in the combustion cycle, different events are necessary between 2 tdc of the same cylinder. So, the first dynamic architecture choice, when designing, and integrating a control strategy, is the selection of the adequate event(s), out of a list of around 60. The below figure shows the functions split on some events and puts in focus that the EMS functions are not monolithic in term of dynamics, but use various events (for functional or HW resources optimization reasons).

Fig. 13: Functions vs. events mapping Consequently, in addition to the static data flow described in Fig. 4, a dynamic data flow can be displayed, corresponding to the exchange between events, or tasks: A variable is modified by one (or more) event, and read by one (or more) other event. The above matrix shows the data flow between some producing and consuming tasks.

A comparison between the static data flow (between SW-Cs) and the dynamic data flow (between tasks)

shows that the static one is much better controlled than the dynamic one: The static flow is easy to formalize and to encapsulate. In general, there is only one single producer for various consumers, and the access to external data can be protected using special mechanisms. Finally, a failure of the static flow can hardly generate a failure at run time, but rather at build time. Which means that it is much easier to detect. None of these characteristics apply to the dynamic flow: formalization and encapsulation are difficult; there is often more than only one producer-task; and no simple mechanism permits reducing the access to a data from a single task. And finally, a failure here will hardly be detected at build time, and will be difficult to identify at run time.

Due to this huge "dynamic flow" (like the static one, a particularity of EMS systems), data consistency issues will be more difficult to handle, in particular in case of preemptive scheduling. This is a second aspect of the dynamic architecture.

Another consequence of the coupling between functions is the importance of the calculation sequence between them: When a new function is added, it has to be inserted at the right place in the program flow corresponding to one event. Different criteria are defined by the dynamic architecture, to ensure a correct and reproducible sequencing (the same combination of functions should be integrated in the same way on different applications). Another important parameter of a function is its deadline, or maximum allowed response time. The response time is the delay between the activation of a function and its completion. For instance, the time elapsed between the decision to update the injection time (detection of the tdc), and the point in time it actually is updated. The intrinsic duration of the function is included in its response time, but also the delay introduced by the other functions and events of higher priority. All these information depend on the integration platform, and a correct behavior has to be ensured on the slowest one.

Exceeding deadlines:

Depending on the functionality, a missed deadline can be destructive (e.g. injection update), or have such a light consequence that it is better to simply skip the calculation (e.g. coolant temperature acquisition). An EMS system uses a mixture of hard and soft deadlines, typically in the range of 1ms to 1 sec. In general, defining the deadline of a functionality is not a simple issue, and requires a good system knowledge. Violating deadlines is a typical problem of integration, as the response time of one function is mostly impacted by the other functions sharing the same CPU: The response time of a function integrated since a while can be impacted by the introduction of a new one. In order to fulfill the deadlines, priorities are assigned to tasks, based on a standard scheduling policy and task priority scheme. Standard priority orders ensure consistent response times between projects.

Fig. 19: Standardization of priority scheme

To verify deadlines, advanced techniques can be used, like schedulability prediction, simulation of the dynamic behavior, or simply measurements. These techniques need a very good understanding of the dynamic behavior and are used by architects. To define the correct sequence between functions of the same event, one of the criteria which can be used is the data flow criterion. A function producing a variable should be located before all the functions that consume this data, in the program flow. Otherwise, the consuming functions will work with an old (or, even worst, non initialized) value. It is also preferable, in general, that all the consumers get a consistent value for the variable, which means that all consumers should be either before, but preferably after the producer module. Furthermore, in some cases, enlacing between functions is required: a function has to be inserted between 2 parts of another one Thus, defining the right sequence of functions connected to the same event can be a complex job: the below figure shows the amount of direct (produced, then consumed) and reverse (consumed, then produced) data flow in a typical task. Note here that one green or red arrow may encapsulate more than one variable. The amount of arrows (links) here is an additional testimony of the high coupling between EMS functions. Finally, the correct sequence of functions within a task is verified by a static analysis tool, based on data production and consumption order. Due to the big number of links between functions, finding the right precedence order may be a complicated job. Because of algebraic loops, the solution to the precedence problem is not always obvious, and needs some system choices. For the sequence flow across tasks (when defined), the same kind of analysis can be conducted.

Inconsistency of data:

The modification, by a high priority task, of a variable during its use in a low priority task, corrupts the behavior of the low priority functionality 4 , as its 2 parts work with different values for the same variable. This standard problem of real time software is particularly important in EMS context due to the big coupling (and data flow) between functions and between tasks.

4 This also applies across different functions which need to work with the same input values. For instance, misfiring, ignition, injection functions are strongly coupled together. The data consistency problem can also be analyzed statically by a tool, by checking the data flow between tasks ("dynamic flow"). Identifying this flow between the tasks is the first step for a better control.

Fig. 25: Shared data between tasks of different priorities and recurrences

Dynamically, it is nearly impossible to verify the consistence of data, as the occurrence of the critical case is very unlikely and difficult to reproduce. This is particularly the case in an EMS context, where regular time based tasks and engine angle based tasks can interact at any time.

Organization

In addition to the above measures, an adequate organization allows to control the dynamic architecture:

SW architects analyze new concepts, define standard methods and mechanisms, and support the projects in their deployment. SW integrators focus on their own project and ensure a correct integration of the reused functionalities. Both are well trained to the architecture mechanisms and constraints, and are highly skilled engineers. Developers of functions are specialists on their own functional scope and know perfectly how to develop a generic solution, portable on different system and HW configurations. They control the internal architecture of their function, in order to ease its maintainability and configurability.

Architecture and integration activities are budgeted, empowered, and considered in the early project planning, as major activities, particularly in a context of intensive reuse.

Architecture assessments are conducted by architecture specialists independent from the projects. They are done at an early phase of the project, to be able to take corrective or preventive actions.

Standardization

As seen in the above chapters, the frame a SW-C is plugged into has a major impact on its behavior, in particular in the EMS context of hard real time and high coupling between functions. For instance, a SW-C designed for a non-preemptive environment cannot simply be used in a preemptive one. Even in a given proprietary architecture, the behavior of a reused proprietary SW-C is not automatically the same, due to the different system and HW configurations.

With the trend to integrate more and more external SW-Cs, the need for adaptation layers increases, and consequently the need for HW resources. As long as the number of external SW-Cs is limited, such an integration can be managed. But with an increasing number, a standardization is necessary.

Ahead from the pure mechanisms (like interfacing mechanisms), a standardization of the architecture itself is necessary to build complete projects out of SW-Cs. Which events, which recurrences, which links between them (precedence, phasing, exclusion, ...) ? Which scheduling concept, which priorities, which deadlines for the functions, and how to ensure them? Which sequencing between components, and how to control it? Which data to be protected against concurrent accesses, and which mechanism to protect them, compatible with the HW resources constraints? These are some of the challenges to be solved by AUTOSAR or any standard willing to authorize porting of SW-Cs across different platforms.

Conclusion

Compared to other automotive areas like car body, an Engine Management System has specific constraints which make the integration of functions more difficult. High coupling between functions, hard and complex real time, and limited HW resources are the ones with major impact on the dynamic behavior. Combined with the strong reuse objectives inherent to the automotive business, these constraints increase the challenge of integration activities. Hidden part of the iceberg, the dynamic integration of a SW-C is certainly much more difficult to put under control than its static one. But there are nevertheless various techniques and means to reach this goal. Standardization will help in this direction, but has to be supported by efficient mechanisms and tools, and has to consider all the facets of the problem.

Fig. 1 :

 1 Fig. 1: Memory vs. price of EMS

Fig. 5 :

 5 Fig. 5: Same SW for different camshaft targets

Fig. 6 :

 6 Fig. 6: Relative weight of main recurrences

Fig. 8 :

 8 Fig. 8: Hierarchical architecture: packages of SW-Cs (Hood-like representation)Finally, a hierarchical architecture is defined, with different levels of interfaces.

Fig. 9 :

 9 Fig. 9: CPU load vs. dynamic architecture

Fig. 10 :

 10 Fig. 10: Facets and scope of architecture

Fig. 11 :

 11 Fig. 11: Static (or functional) architecture of EMS

  Fig. 12: Functional architecture plugged on layer architecture of EMS

Fig. 14 :

 14 Fig. 14: Data flow (coupling) between main tasks

Fig. 15 :

 15 Fig. 15: A task: sequence of functions

Fig. 16 :

 16 Fig. 16: Response time and deadline

Fig. 20 :

 20 Fig. 20: Response time verification by simulation

3 .Fig. 21 :

 321 Fig. 21: Correction of function sequence based on data flow

Fig. 22 :

 22 Fig. 22: Data flow between synchronous functions To reduce the coupling between functionalities and to better control the sequencing, standard sequence orders or ordering criteria are defined, and sequencing modules are used. Standard initialization mechanisms and standard task scheduling ensure that data are available at the right time.

Fig. 23 :

 23 Fig. 23: Intermediate scheduler reduces integration effort and risk of wrong sequence

Fig. 24 :

 24 Fig.24: Data inconsistent within 100ms functionality So, to reduce the risk of misuse of shared data, specific design patterns, atomic libraries, restrictions like controlled use of preemption, and encapsulation principles are applied. The data consistency problem can also be analyzed statically by a tool, by checking the data flow between tasks ("dynamic flow"). Identifying this flow between the tasks is the first step for a better control.

40 functions export... 40 functions import ...

														Fct_04	Fct_02	Fct_01	Fct_09	Fct_03	Fct_15	Fct_06	Fct_10	Fct_41	Fct_18	Fct_11	Fct_14	Fct_16	Fct_22	Fct_19	Fct_17	Fct_05	Fct_20	Fct_12	Fct_08	Fct_27	Fct_21	Fct_13	Fct_25	Fct_31	Fct_24	Fct_23	Fct_26	Fct_29	Fct_28	Fct_30	Fct_34	Fct_33	Fct_32	Fct_35	Fct_36	Fct_39	Fct_40	Fct_37	Fct_38
														Fct_01
														Fct_02
														Fct_03
														Fct_04
														Fct_05
														Fct_06
														Fct_07
														Fct_08
														Fct_09
														Fct_10
														Fct_11
														Fct_12
														Fct_13
														Fct_14
	Box Air Cleaner	Sensor with Mass Air Flow	Throttle Control Electronic	Recirculation Exhaust Gas	Manifold Composite	Absolute Pressure Manifold	Injection Piezo Piezo Direct	Ignition	Var. Dual Cont.	Position Camshaft	Fct_15 Fct_16
		Temp. Sensor Integrated		Valve (EGR)			Sensor		Injector		Cam Phaser	Sensor	Fct_18 Fct_17
														Fct_19
														Fct_20
											Exhaust			Fct_21
											T e			Fct_22 Fct_23
														Fct_24
														Fct_25
														Fct_26 Fct_27																											Number
										3-Way Catalyst	Lean NOx Trap Catalyst		Fct_28 Fct_29																											of links
														Fct_30
														Fct_31 Fct_32																											> 10
														Fct_33
														Fct_34 Fct_35																											6...10
														Fct_36
	Active Carbon Caniste												Fct_37 Fct_38 Fct_39																											< 6
														Fct_40
	Canister	Fuel Supply	High Pressure	Fuel Pressure	Engine	Active Crankshaft	Knock Sensor	Engine Coolant	Linear /	NOx
	Purge	Unit	Fuel Pump with	Sensor	Control	Position Sensor			Temperature	Binary
	Solenoid		Flow Control							Sensor	O2 Sensor
			Valve

It should be specified, here, what means "integrated in the same way", when the 2 integration frames are different. Indeed, integration instructions are dependant on the integrated object itself, but also on the integration environment, which is not portable. This is particularly true on the dynamic aspects.

At first sight, this seems to be a wrong architecture, but in reality, this may be a consequence of the static partitioning, which is mainly driven by reuse aspects..

Integration faults and how to avoid them

Like described in a previous document [2], dynamic architecture failures can be classified in 3 categories: intrinsic to the reused component, intrinsic to the frame it is plugged into, or finally failure due to an integration error or incompatibility.

In the first category are the typical problems of infinite loops, wrong pointer initializations, recursivity, interrupt disabling. They are independent of the integration environment, and a verification needs to be done only once on a SW-C, independently of its reuse level. A correct SW-C will be correct even if reused many times on different platforms. On the other side, a faulty SW-C will be faulty on any integration platform. These typical problems are detected by peer reviews, architecture mechanisms, unit testing, or static analysis tools generally available on the market.

The second category of problems refers to the behavior of the project the SW-C is plugged into. CPU overload, or stack overflow are generally detected by embedded mechanisms, by static analysis tools, or by a combination of those. Regular measurements are done along the complete project life, in order to react before the limits are exceeded.

In this paper, we will focus on the third category of problems, which concerns the behavior of a SW component once it is integrated in the complete project. As the integration environment changes (e.g. due to the influence of other SW components), the behavior may change: The same SW-C shows different behavior on 2 different projects, being or not integrated in the same way 2 . These problems are generally less tracked; their specification, formalization, and verification can be a cumbersome job. Their effect is not immediate, difficult to reproduce, and in extreme cases, can be destructive. These problems are:

Wrong recurrences:

A calculation is not executed with the right recurrence, or has an unexpected jitter. In general, this problem is due to an integration error, or to high CPU load conditions. By static analysis, consistency between expected recurrence and integration task or container can be checked. By regular measurements on bench, engine, or vehicle, and by simulation, the correct


Jean-Louis Camus

Pierre Vincent

Olivier Graff

Sebastien Poussard

A verifiable architecture for multi-task, multi-rate synchronous software

Keywords: software, embedded, synchronous, realtime, scheduling

Synchronous model-based software development techniques have proven to be both rigorous and efficient for the development of safety critical real-time software. Currently, the most common practice is to limit the use of synchronous techniques to single tasking or locally synchronous globally asynchronous multitasking scheduling schemes. This paper presents a technique for implementing multi-rate software on several tasks whilst preserving the determinism and verifiability of the synchronous approach. Our technique uses the synchronous framework in order to ensure rigour and verifiability, but implements different parts of a global synchronous model into separate tasks with a simple and efficient architecture. This architecture ensures determinism even in the presence of variations in execution time, and it also allows verification of the complete software by simulation or formal verification. This architecture has been applied to avionics software of a real aircraft's equipment. Further perspectives are also provided.

Introduction

Development of safety-critical real time embedded software requires a combination of rigour, determinism and execution efficiency. Synchronous model-based software development techniques have proven to achieve these objectives on large civil avionics equipment [START_REF] Pilarski | Cost effectiveness of formal methods in the development of avionics systems at Aerospatiale[END_REF], railway signalling systems [START_REF] Legoff | Using synchronous language for signalling[END_REF] and nuclear power plant control systems [START_REF] Palaric | Advanced safety I&C system for nuclear power plants[END_REF]. However, the current application of these techniques to multi-rate software is most often based on one of the following (non exclusive) schemes:

• Implementation of different locally synchronous software modules into different tasks running independently. This approach neither ensures determinism nor allows analysis of the global behaviour.

• Decomposition of the application into elements, which are activated at appropriate periodic times by a pure sequential scheduler, all in a single task. This approach may become unpractical when such decomposition is complex. Going beyond these schemes is possible when the synchronous approach is understood as a powerful conceptual tool, not limited to what can be achieved with a loop in a sequential program. This paper describes a technique for a multi-rate, multi-tasking scheduling scheme in a synchronous framework that ensures determinism and supports verification of the global behaviour of the application. This paper is organized as follows:

• Section 2 is a short presentation of synchronous software principles and current practice. • Section 3 reviews the most commonly used scheduling schemes for multi-rate synchronous software, with their benefits and limitations. • Section 4 describes the extended technique for multi-rate/multi-task software development in a synchronous framework. • Section 5 describes the application of this technique to avionics equipment software. • The conclusion summarises the benefits and limitations of this technique and draws perspectives for extensions of this technique.

Synchronous Software Development Techniques

Objective of Synchronous Techniques Synchronous languages and their technology have been created in order to support the development and verification of reactive real-time systems for which confidence is essential, such that safety critical systems (eg: flight control software) or complex digital circuits. Indeed, when classical development techniques are used for real-time systems, development is complex, and it is extremely difficult or impossible to verify their behaviour, mainly because of the explosion of their state space. An excellent survey of the origin and state of the art for synchronous languages is provided in [9]. The synchronous languages Lustre [START_REF] Halbwachs | The synchronous dataflow programming language Lustre[END_REF], Esterel [START_REF] Boussinot | The Esterel language[END_REF] and Signal [START_REF] Le Guernic | Programming real-time applications with SIGNAL[END_REF] and are built on a common mathematical framework that combines:

• Synchrony

• Deterministic concurrency

The Essence of Synchrony

One currently used definition of synchrony is that reactions take zero time. We prefer to consider that it uses an abstraction of time:

The essence of synchrony is to: 1) Abstract time as a sequence of discrete instants 2) Restrict execution to a sequence of atomic reactions.

Reactions can be triggered by events or by time, as shown on Figure 1.

Notation

In the remainder of this chapter, we illustrate the synchronous approach using examples based on the SCADE language and tools, since this is the one we used for the application described in chapter 5.

The SCADE language supports the combination of two notations that are familiar to control engineers:

• Block diagrams to specify the algorithmic part of an application, such as control laws and filters • Safe State Machines (SSM) to model the behaviour. SCADE adds a rigorous view of these well known, but often insufficiently defined formalisms. SCADE has a formal semantics based on Lustre [START_REF] Halbwachs | The synchronous dataflow programming language Lustre[END_REF], with a precise definition of time and concurrency. This ensures that all programs generated from SCADE behave deterministically. SCADE allows for automatic generation of C code from these two formalisms. The basic building block in SCADE is called a Node. A node is a user defined function, built from lower level nodes, down to predefined operators (logical, arithmetic, delay, etc). A node can be represented either graphically (Figure 2) or textually (Table 1). The SCADE language provides a simple and clean expression of concurrency and functional dependency at the functional level, as illustrated by Figure 4. SetRegulationMode and ComputeTargetSpeed are functionally concurrent, since they are independent; the relative computation order of these blocks does not matter (since in SCADE there are no side effects). ComputeThrottle functionally depends on an output of ComputeTargetSpeed. The application is described in terms of logically concurrent activities in block diagrams or SSMs. The user needs not spend time performing tedious and error prone dependency analyses to determine the sequencing manually; the focus is elevated to the functions rather than the coding. Concurrency and dependencies are taken into account during code generation. KCG, the current commercial code generator is able to automatically generate sequential deterministic code for a reasonably wide category of situations (see sections 3 and 4 for the scope and limitations of sequential implementation). This code strictly conforms to the model's semantics. Notice that there is no overhead for communication which is implemented internally using well-controlled shared variables and avoiding any context switching.

Safe State Machines for discrete control

Discrete control is used when the behaviour varies qualitatively as a response to events. This is characteristic of modal human-machine interface, alarm handling, complex functioning mode handling, or communication protocols. SCADE hierarchical state machines are called Safe State Machines (SSM). These can be freely mixed with data flow. SSMs are hierarchical. States can be either simple states or macro states, themselves recursively containing a full SSM. When a macro state is active, so are the SSMs it contains. When a macro state is exited by taking a transition out of its boundary, the macro state is exited and all the active SSMs it contains are pre-empted, whichever state they were in. State machines communicate by exchanging signals, which may be scoped to the macro state that contains them. The definition of SSMs strictly forbids dubious constructs found in other hierarchical state machine formalisms: transitions crossing macro state boundaries, transitions that can be taken halfway and then back-tracked, and so on. These are nonmodular, semantically ill defined, and very hard to understand, hence are inappropriate for safetycritical designs. They are usually not recommended by methodological guidelines.

Traditional Scheduling Schemes for Multi-Rate Synchronous Software

Separate Development and Tasking Technique With this technique, software modules that have to run at different rates are allocated to different tasks each running at the appropriate rate. These modules, which may be designed each as a synchronous model, are developed, scheduled and verified separately. There is no formal definition of the global behaviour. The global behaviour is generally not deterministic in the presence of execution time variations, and there are no techniques for accurately verifying this global behaviour, since testing or simulation can only explore parts of the complex state space.

Single Tasking Scheme

All software components run in a single task, activated at the highest frequency. This is best illustrated by the following example.

The following application has two rates: Sys1, which is as fast as the top-level, and Sys2, which is four times slower, as shown on Figure 6. The solution consists in splitting the slow part into several smaller slow parts and distributing their execution on several fast rates. This is a safe way to design a multi-rate application. Scheduling of this application is fully deterministic and can be statically defined. The previous application example can be redesigned as shown on Figure 8. The slow part, Sys2, is split into four subsystems. Note that any data exchanges are possible between these decomposed parts, provided causality is respected (it is verified by the qualified code generator) and will be reflected correctly in the single task implementation. These subsystems are executed sequentially, one after the other, in four cycles, as shown on Figure 9.

The Synchronous Multi-Rate Multi-Task Scheduling Scheme

Objective of the presented technique

The presented technique has the following objectives:

• Support the global design and implementation of multi-rate software in situations where slicing of the slow part is problematic as explained above. • Support analysis of the global behaviour at the model level, for instance by simulation or formal verification. • To be implementable on a simple static prioritybased pre-emptive scheduler. • Ensure functional equivalence between the functional model and its implementation running in physical time. This equivalence has to be based on solid theoretical foundations. • Be efficient in terms of computing resources.

• Last but not least, for usability in an industrial context, this shall be achieved by adhering to a standardised architecture with simple and easy to verify design rules.

Foundations

Contrary to a common prejudice, the scope of synchronous techniques is not inherently limited to periodic software, where single thread code is generated from a model. It is also a powerful framework for describing and analysing a wider class of real time systems, such as multi-periodic or even sporadic processing.

The technique presented in this paper is based on solid theoretical foundations, published in [START_REF] Scaife | Integrating model-based design and preemptive scheduling in mixed time and event-triggered systems[END_REF].

Compared to [START_REF] Scaife | Integrating model-based design and preemptive scheduling in mixed time and event-triggered systems[END_REF], we rely on usage conditions which simplify the design and verification tasks, thus making the approach affordable to common engineering practice. Tasks are periodic (not sporadic) and the presentation is limited to a situation with 2 tasks. We found these conditions appropriate for our application context. More general hypotheses may be adopted at the price of a higher complexity, using the approach described in [START_REF] Scaife | Integrating model-based design and preemptive scheduling in mixed time and event-triggered systems[END_REF].

Scheduling

The application is composed of two periodic parts, named "minor" (noted "m") for the faster one and "major" (noted "M") for the slower one. TM (the period for M) is an integer multiple of Tm (the period for m). Deadline monotonic pre-emptive scheduling is used. Each task is assigned a unique priority. The task with the highest priority executes first. Tasks are periodic, and all periods are multiples of the shortest period called the 'base period'.

The following constraints on the Worst Case Execution Time (WCET) are imposed: 1. WCET(minor) + other < Tm 2. N*WCET(minor+other)+WCET(Major)< TM where other includes time needed by other tasks (ex; input/output) and context switching.

What is the Central Issue?

No model or implementation can be considered as good by itself: we need representativeness of the model with respect to the implementation and determinism of both the implementation and the model. The central issue is to define a consistent set of modelling and implementation rules such that the behaviour of the model (as defined by the synchronous semantics, and reflected by simulators or formal verification tools) and the behaviour on the target are functionally equivalent: the same input sequence produces the same output sequence at the times where a subsystem communicates with outside. Indeed, the model semantics are defined in terms of logical instants (cycles), with no physical duration, while the execution of the real implementation runs in physical time. Execution time may vary within the limits defined in the previous section. For a single task implementation, equivalence is simply ensured if the Worst Case Execution Time (WCET) is smaller than the CPU time allocated to the task for a period. For a multi-rate, multi-task execution scheme, this is more complex; we also need to ensure that actual data, computation and ordering remain consistent despite variations in execution time under the WCET and scheduling hypotheses described above. As we shall see in the next sections, the key of this problem lies in the communication: what should be communicated and when should communication occur?

Global Application Model

We model the scheduling and communication in SCADE by creating a root node containing an instance of the following children nodes (see Figure 10):

• Node Major contains all SCADE nodes running on the major rate • Node Minor, contains all SCADE nodes running on the basic (fast) rate. • The connections formalise the communication to/from the environment and between these nodes. The scheduling is expressed by putting the major node under control of a clock named SlowClock, which is true every major cycle. From a synchronous viewpoint, even the computation of the major node is instantaneous. In the real world, the minor process may interrupt the major process before it has completed its computation, and one may think that the synchronous model is inherently inappropriate to match reality. We will see in the following sections that this depends on communication. For the time being, let us consider that we have no formal model of communication between the major and minor nodes. We will define this communication based on analysis of the relationship between the model and the real world.

Minor to Major Communication

Communication from minor to major cycle can occur instantly after completion of minor cycle computation and is modelled by a direct connection from minor to major nodes. However, minor shall not communicate to Major during a computation of Major (see Figure 11). The reason is that this might lead M into an inconsistent state. Assume for instance that m passes related data such as a pressure and its related validity flag and that the output of m in cycle k contains a valid pressure with the validity flag set to true. Assume that M starts computing, sees that the pressure is valid and bases following computations of its current cycle on this validity. If m(k+1) m puts an invalid pressure (even with the validity flag set to false) into M's input vector, this may clearly lead M to perform erroneous computations. The general rule for synchronous software is that the input vector of a component shall remain frozen during the complete computation of its cycle; this also concerns data coming from other parts of the real world.

Major to Minor Communication

Communication from major node to minor node requires specific handling. For simplicity, we will use as an example a situation where TM=2*Tm. First of all, let us analyse the most usual case, where M takes nearly as much as it WCET, i.e. it completes just before the next minor cycle where it will perform its new major cycle, as shown on Figure 11. In cycle k m is executed first and then it passes its output to M, which starts computing. M is interrupted and suspended by m executing its cycle. Then M resumes and completes computation of its major cycle during cycle k+1. The output of M is used as input by m at cycle k+2. Figure 12: Case where M computes faster than usual So, in order to keep the system deterministic, we should systematically communicate from M to m at the beginning of the minor cycle where M will starts its next major cycle, even if M finishes earlier.

Model of the Communication

We have analysed the behaviour in real time, so we can now define the communication scheme that will represent this consistently in the global model. The "LowToHigh" node is used in order to ensure that communication from major to minor occurs with a delay of one major cycle. Its reference definition (Figure 13) is a "fby" operator (unit delay) under activation condition by the slow clock. 2 summarises the mapping between the SCADE design specification (which is defined in logical synchronous time) and the implementation (which runs in real time on 2 processes and where computation time is variable). The code for nodes minor and Major can easily be automatically generated as pure sequential code, using a code generator such as the SCADE qualified code generator KCG. For each node there are two C functions: an initialisation function and a cyclic function, to be called at each cycle where the corresponding node has to be executed.

On the contrary, the root node, modelling activation of minor and major nodes, and communication between them has to be understood as a conceptual model. It cannot be implemented by simple sequential code. This is for instance beyond the scope of the current KCG. However this is not a major issue, since the code implementing the root node is quite simple. It just contains:

• Scheduling of minor an major processes using rate monotonic scheduling • Transfer of data between the processes in the exact conditions described above Data transfer has to be triggered either by the scheduler or by the fast process, if it can communicate with the slow process via shared memory.

It has to be implemented partially manually, possibly using KCG as a support to generate part of that code (in particular data type definitions and communication patterns).

Extension to Multi-Rate Software

Some reasonably simple extensions of the above analyses can be made for periodic multi-rate software when rates ratios are all a power of two (more general situations require the solution described in [START_REF] Scaife | Integrating model-based design and preemptive scheduling in mixed time and event-triggered systems[END_REF]). First of all the principle for communication from a slow node to a fast node remains the same: • In the model, communication from a slow node to any other node has to be modelled as a delay of the clock of the slow node • In the implementation, communication from the slow task to any other task has to occur at the beginning of the next slow cycle Second, the introduction of modules with intermediary rates introduces additional potential problems: the start of the slowest computation may be delayed by a task with an intermediary priority up to another cycle.

Application to Avionics Equipment Software

Context

Intertechnique company is part of Zodiac Aircraft Systems Segment. Its fuel management, oxygen and life support, electrical power management and monitoring and management safety-critical systems are installed in the airplanes and helicopters of all the leading international airframe manufacturers. Intertechnique chose to develop the software of a piece of safety-critical avionics equipment using the SCADE tool.

The software is bi-rate deterministic scheduled. Two models were created, one for each task (minor_process, major_process).

To check the behaviour of the global software, simulations were performed to make minor_process and major_process work together.

Multi-task issues

The main effort was the management of data exchanges between both tasks, as explained in the previous section. The decision was taken to experiment the use of KCG to generate a code which could work correctly on the real target. Since KCG is designed for generating single thread code, the code generated by KCG from the root node modelled in Figure 10 would not work correctly on the real target. The following approach has been adopted: build a root node such that:

• From a modelling perspective it should be semantically equivalent to the model of Figure 10 • The generated code is such that it communicates appropriately thanks to buffering and triggering conditions. Communication from minor_process to major_process can occur instantly after completion of minor_process; however, re-entrance may have unwanted side effects on major_process. Since KCG passes structured data by reference, it might happen that a minor_process pollutes the inputs of the running major_process which it interrupts. On the other hand, inconsistencies can occur between inputs of minor_process of the first minor cycle and minor_process of the second minor cycle if communication from major_process to minor_process occurs instantly after completion of major_process. Thus, in order to ensure determinism, the communication from major to minor cycles shall occur only after full completion of a major cycle, rather than as soon as computation is completed

Adopted Solution

In order to avoid these communication issues, dedicated nodes were designed.

Communication from minor_process to major_process

Inputs of major node shall stay invariant during major node processing. Since the actual implementation runs on two threads (minor and major), communication from major node to minor node requires specific handling. This is ensured by inserting a dedicated node MinorToMajor activated before executing the node major_process. This MinorToMajor node shall not be interrupted.

Input1 Output1

Figure 15: MinorToMajor node definition

The SCADE activation operator (condact) ensures that when activation condition is true, Output1 takes Inputs1 value and when activation condition is false, Output1 stays invariant.

Communication from major_process to minor_process

Inputs of the minor_process shall not be dependent of major_process time processing. Inserting a dedicated node MajorToMinor ensures that communication from major_process to minor_process occurs only before the first minor_process of the first minor cycle. This node is activated at each cycle (no activation condition). Leftmost "fby" stores the output of major_process; rightmost "fby" sends the last valid output from major_process. The switch sends the updated major_process output stored by the leftmost "fby" and updates the rightmost "fby". The simulation scheduler node definition is then as follows, and includes also "and" gates to model a scheduling validity signal:

Benefits and Limitations

Model driven simulation enables testing of functional software very early in the development cycle. Scheduling the model using the chosen architecture allows a global simulation and the detection of potential errors in data exchanges between minor and major cycles. This simulation activities reduced integration time on hardware by around 60%, most of functional malfunctions being detected early on simulation environment.

Since the code generator is not designed to create multi-task code, human review of the code generated for the root node is required in order to check that it is compatible with the multi-task realtime integration. The code for minor and major nodes runs in the nominal conditions for which KCG has been designed and qualified and so does not need to be reviewed.

Perspectives

Intertechnique chose to develop more software using the SCADE tool. SCADE 6, implementing new constructs, allows the use of model driven development on more programs than the previous versions. These new constructs, especially qualified state machines could ease the development of real-time simulations. This will be carefully studied by Intertechnique to continue reducing integration costs using scheduling simulation on simulation environment.

Conclusion

We have defined a simple and efficient technique for the development and verification of multi-rate software. This technique makes it possible to specify, implement and accurately verify the global behaviour of a multi-rate application, without paying the price for a complex synchronisation mechanism, such as semaphores or polling, and introduces no risk of deadlock. This was made possible by using the synchronous software concepts, not just as a means for implementing a piece of software in a program loop, but also as a powerful conceptual framework able to describe behaviour distributed over several tasks. Future work will explore the following areas: 1

Use of the extended approach described in [5] 2 Automation of the implementation of scheduling and communication

Figure 1 :

 1 Figure 1: Common synchronous execution schemes This type of model is used everyday under various forms in mathematics, automata, in the discrete-time dynamic systems of control engineering, and in synchronous digital logic familiar to hardware designers.

Figure 2 :

 2 Figure 2: Graphical notation for an integrator node

Equations

  delta = u * TimeCycle ; y = delta + last_Y ; last_Y = fby(y,1, 0.0);Timing and CausalitySCADE provides an approach to properly deal with issues of timing and causality. Causality means that if datum x depends on datum y, and then y has to be available before the computation of x starts. A recursive data circuit poses a causality problem, as shown in Figure3, where "throttle" depends on itself, via the ComputeTargetSpeed and ComputeThottle node. The SCADE semantic checker detects this error and signals that throttle has a recursive definition.

Figure 3 : 4 Functional

 34 Figure 3: Detection of a causality problem Inserting an FBY (delay) operator in the feedback loop solves the causality problem, since the input of the ComputeTargetSpeed block is now the value of throttle from the previous cycle as shown in Figure 4 Functional Dependency and Concurrency

Figure 4 :

 4 Figure 4: Functional expression of concurrency

Figure 5 :

 5 Figure 5: State Machine Fragment for Cruise Control

Figure 6 :

 6 Figure 6: Basic Bi-rate Software Model

Figure 7 :

 7 Figure 7: Basic Bi-rate Scheduling

Figure 8 :

 8 Figure 8: Multi-cycle Bi-Rate Model

Figure 9 :

 9 Figure 9: Multi-cycle Bi-rate Scheduling

Figure 10 :

 10 Figure 10: Model of a Synchronous Bi-Rate System

Figure 11 :

 11 Figure 11: Case when M computes slowly Now, let us analyse the less intuitive situation shown in Figure12, were (in some cycles) M needs significantly less than its WCET. In the example, M completes during cycle k+2, rather than cycle k+3. It would seem natural that M sends its output to computation k+3 of m. But if we do that, then the global behaviour will vary, depending on the current execution time of M. Even a variation of a microsecond in execution time of M may abruptly switch from the previous situation to this situation or vice-versa (this is a kind of chaotic behaviour). The global behaviour becomes non deterministic and impossible or extremely difficult to analyse.

Figure 13 :

 13 Figure 13: Low To High Node

Figure 14 :

 14 Figure 14: Three rate scheduling and communication

Figure 16 :

 16 Figure 16: MajorToMinor node definition:

Figure 17 :

 17 Figure 17: Simulation Root Node

Table 1 :

 1 Textual Notation

	Concept	Text Fragment
	Formal	node IntegrFwd(
	interface	U: real ;
		TimeCycle: real)
		returns ( Y: real);
	Local	var
	variables	delta : real;
		last_Y : real;

Table 2 :

 2 Mapping Logical to Physical Time

	Synchronous Model	Target Program
	Minor node triggered	Computation of minor C
	every basic cycle	function at beginning of
		every minor cycle in minor
		process
	Major node triggered	Computation of major C
	every major cycle (M	function, in major process,
	basic cycles)	starting after computation
		of minor function. It is
		distributed over one major
		cycle (N minor cycles).
	Communication from	Just before starting
	minor node to major	computation of major
	node: is only taken	function
	into account by the
	major node at major
	cycles
	Communication from	Just before starting
	major node to minor	computation of minor
	node: contains a	function in a cycle where
	delay of one major	major will start
	cycle

Implementation of the Model

Acknowledgement

The authors acknowledge the contribution of Paul Caspi (Verimag), Thierry Lesergent (Esterel Technologies) and Sébastien Penot (Intertechnique/Turbomeca) to this work. The foundations of this technique are based on results of the EC project RISE (38117) and dissemination is partly supported by the EC project INTEREST (3361).


Jean-Marie Calluaud

Jean Casteres

Stéphane Gaudaire

Technology evolution of aircraft simulator for real equipments validation

Keywords: Simulation, real time, operating system

Aircraft systems have increased in number and complexity since 1985. The integration test rig, often known as the "iron bird" integration simulator, has been developed to assemble and test as many as possible of the various aircraft systems in a simulated environment. The integration simulator aims at:

• Simulating the aircraft environment, the natural flight loop and certain systems • Stimulating the real aircraft equipment The evolution, in the last twenty years, of simulators for aircraft equipment validation is presented in this article. From 1995 to 2008, integration simulator architecture has taken various evolutionary steps that have affected:

• Simulation complexity

• Simulation architecture

• Technology used

The article shows how mass-market technology (hardware, communication, bus, operating system) can fit into the specific and complex architecture of the integration simulator. The multiple technical and industrial constraints that must be taken into account to migrate from specific to generic solution will be presented.

Introduction

Simulation, in today's complex systems, plays an increasing role. The aircraft industry has been one of the earliest users of the simulation techniques and is still paving the way for the adoption of new technologies. The complexity of systems has increased the cost of their development and simulation is often a way to reduce the costs of testing aircraft complex systems. We have developed a chain of simulation platforms ranging from the research simulator to the integration test rig to support the aircraft program. The aerospace industry vision is that embedded systems will be key differentiators in the aircraft business. But this embedded systems industry is driven by mass-market products (PDA, Cell phone, gaming). These products display a different production pace which creates a difficult obsolescence problem for the other industries. Focus must be put on architecture methods and development tools to adjust to this pace, with each industry contributing its know-how for cost reduction: automotive with large scale production cost savings and aerospace for safety and quality control. This article will present how the steps to adapt to this new market conditions have taken place; and how the integration test rig is now ready to adapt to the fast pace of change of the mass market. We will first look at the simulation chain implemented to answer the aircraft program simulation needs. An analysis of the evolution of the architecture for the integration simulator and of its real time performance profile will be presented in several steps: the initial specific architecture, the first evolutions to standard operating system, and finally highlighting the mass market technology adoption.

Simulation Platform Needs

An aircraft is a complex system that involves different knowledge domains such as: aerodynamics, engines, electric and hydraulic systems, flight dynamics. In order to validate new ideas and new technologies in these various domains, a series of simulation platform has been built. This chain covers the prospective research simulator (EPOPEE), the development simulators (A/C-1 and desktop simulators) and the integration simulator A/C-0. These simulators support the aircraft development from 5 years, 2.5 years and one year before the first flight respectively. In this article we will focus on the integration simulator: aircraft 0 or A/C-0 (or "iron bird" integration test rig) that enters into service one year before the program's first flight. The iron bird integration concept dates back to the Concorde program: compatibility checking between various aircraft systems can be performed at a lower cost on the ground [START_REF] Coureau | Airbus Engineering Simulation Methods -Past and Future Trends[END_REF]. The integration test rig tests, verifies and validates the compatibility between real aircraft systems, as they will be assembled onto the aircraft with a pilot in the loop. As a consequence, an important characteristic of the integration simulator is that it shall perform simulation in real time since it needs to stimulate real avionics equipments and interface with a real pilot. A/C-0 is used to prepare the first flight but also to participate in aircraft certification, and remains operational throughout the aircraft program lifecycle. The integration test rig comprises of two main components: the simulated world environment and the real equipment that needs to be integrated. These are:

• Aircraft equipment such as: flight controls, flight warning systems and aircraft communication networks, avionics bays • Cockpit systems such as: integrated cockpit panels, cockpit display systems • Aircraft electrical power generation system • The "iron bird" which is constructed using the hydraulic, electrical and flight control actuators from the aircraft. In order to perform the integration of these elements a simulated world environment is developed. The integration simulator embeds the required simulation computing capacity to be able to model the natural flight loop, the engines, the aircraft environment as well as other missing systems. The simulator also supports the communication between the simulated to the real systems worlds via an interface. The interface samples and synthesizes the various aircraft signals necessary for the simulation: analog, digital, ARINC 429, CAN and AFDX signals. The aircraft 0 integration simulator must support a fundamental need for the integration step: the ability to be reconfigured between simulated and real equipment. We illustrate this feature with the following representative example of the aircraft Electrical Flight Command System. When connected to the Iron bird test bench, the integration simulator directly drives the aircraft actuators present on the test bench; when the integration simulation is not connected to the iron bird, but only to the avionic bay, a simulation of the actuator loop is required.

Figure 3: Simulator with actuator simulation

Specific Integration Simulator Architecture

In 1987 the A320 makes its first flight. The program is very important for Airbus since it introduces fly-bywire flight controls to the industry. At the time, the computing means are far more limited than those we know today: this limits the ambitions and needs covered by the simulation. The integration simulation is based on a real time loop at 40 milliseconds for the flight loop, and 80 ms for the other models. On the interfaces, the sampling of the input and output is performed at 20 milliseconds, while outputs that require this refresh rate are computed using extrapolation methods.

Since the integration simulator needs to test as many as possible of the real aircraft equipments, these have to be "stimulated" as they arrive on the test rig. Stimulation of aircraft equipment can be defined as the art of communicating with the systems without going to a full range functional model. For example, aircraft flight command actuators were simulated using recorded tables.

In the following table, we give a view on the number of models involved in the simulation: this gives an idea of the number of simulated models and stimulated elements, as well as the required processing power (CPU). We will use the A320 program integration simulator as a reference throughout this article for CPU power and data exchange throughput. Additionally the number of data signals indicates the volume of exchanges at the interface level.

Table 1: simulation size

In the early days of the A320 development program, there were only proprietary solutions for computers, operating systems and I/O acquisition buses. The integration simulators were built around these solutions, before the appearance of Unix workstation and Ethernet a few years later. The next aircraft program is the A340 in 1989 and the program allows bringing new technology to the integration simulator. The VME bus is available and enables an easy "on demand" addition of IO boards to the interface bays. Reflective memory technology fulfils the new processing power requirements whilst keeping existing software developments. The integration simulator architecture at that time was built on computers connected to each other using reflective memory. These computers were running proprietary operating systems driving avionic signals IO acquisition boards that had been developed in-house. At this time, the timing reference for the simulation was the 50 Hz coming from the power grid. The real time software principles, that are still valid today, were already present: simulation models needed to be scheduled. Simulation models are therefore controlled within a real time simulator infrastructure that offers the following services:

• Computer platform abstraction layer The new requirements demand that flight commands be validated while modelling the aircraft structure dynamic behaviour. Other models gained in the level of detail that could be modelled for example: the transients for slat/flaps and gears, ground reaction and runway topology, as well as dynamic modelling of the fuel displacement while the aircraft was in motion. These needs will all contribute to increase the accuracy level of the simulation and trigger the use of new tools and methods: for example code generation. The program will also be the first one to test the integration of a functional simulation model delivered by another partner, in the case of the FUEL model. The validation of flight controls in the context of aircraft dynamic structure behaviour requires:

•
• A new aircraft dynamic structure modelling and a IO sampling rate at 10ms • New aircraft flight control actuator simulation control loop at 5ms At this time two new technologies were used for the development simulators as well as the integration simulators:

• Symmetric Multi-Processor SMP

• Versatile Module European Bus or VME Both technologies will bring benefits to the integration simulator and introduce two main path to real-time solutions.

Figure 5: A340-600 simulator architecture The SMP server architecture uses a general purpose UNIX operating system (GPOS). This operating systems brings two fundamental capabilities:

• Pre-emptive process scheduling

• Deterministic timer driven events

The VMEbus utilization introduces the controlling CPU board. This CPU, closer to the acquisition interface, runs its own smaller Real Time Operating System, RTOS (Lynx OS), often called hard real time capable OS, yielding deterministic response time on the CPU board.

The GPOS brings a wide software base, while the RTOS focuses on strict deterministic real-time.

The integration architecture for the program will finally be a mix of both technologies: an SMP host will handle the models for all the simulations and a VME bus rack will drive the IO cards. The link between the SMP host and the VME rack CPU head is a proprietary solution.

A dedicated CPU card and its RTOS perform the inner control loop, in charge of the flight command actuator simulation. With this architecture the real-time performance profiles are:

• SMP Host scheduling: 10 ms +/-200µs

• Interface scheduling: 5ms +/-50µs

Looking back at this technology step, one of the main benefits was to be able to migrate the simulation infrastructure to a standard host equipment, and benefit from the international standardization efforts conducted on UNIX, that would soon become POSIX. The VMEbus was also a step in that direction but with still a relatively small RTOS audience at the time.

Additionally, another lesson still true today was the trend and need for more accurate and high fidelity simulations, that would require more computing power.

Evolution to standard maturity

The A380 program brought the simulation world to the forefront. The breakthroughs achieved on the aircraft systems side as well as the structural size of the airplane required simulations on every step of the way from the design to the first flight. Integration of models coming from partners was extensively used. These models were required to run at 40 ms, and, as a consequence the simulation flight loop had to be executed in 10ms The integration simulator architecture had to take into account these new requirements and investigate new techniques to bring additional benefits. PC based distributed architecture was envisaged, but abandoned since the performance at the time did not meet the requirements.

One can insist on a key point that helped the SMP quad CPU staying at the heart of the integration simulator architecture. These UNIX based architectures took benefit of the microprocessor war involving major manufacturers such as Intel, Motorola, Mips or SUN. These architectures improved dramatically over the years from the CPU clock speed point of view but also from the inter processor communication standpoint. This allowed the SMP platform to cope with the increased level of accuracy required for the models. The SPEC benchmarks (Standard Performance Evaluation Benchmark), one of the most successful attempts to create a standardized benchmark application suite [START_REF] Hennessy | Computing Architecture: A quantitative Approach[END_REF], helps represent the integration simulator application to predict if a platform would be appropriate for a given simulation. As for the required performance for the flight command control loop, the A380 program required an increase of 10 times the performance, but there too the CPU power increase available on the board was enough.

The Ethernet had made it into the aircraft with AFDX and since the host was easily capable of managing Ethernet connections, it was very natural to connect directly connected to the ADCN aircraft switches. At the same time, one of the interfaces dedicated to cockpit digital input acquisition had become obsolete and a solution was developed in Airbus that also used Ethernet connections from the host to the interface.

Figure 7: A400M simulator architecture With this architecture the real-time performance profiles are:

• SMP Host scheduling: 10 ms +/-200µs

• Interface scheduling: 2,5ms +/-50µs

Linux Mass Market Technology

For the first time in this small history, the next step came from the computer industry and not from an aircraft program. It pushed us to go for the next technology gap. The servers we were relying on, were announced to be obsolete by 2008. At the time, the micro-processor gap was so big that from the SPECfp_rate on SPECint_rate analysis the PC generation could outperform the machine we were using by two orders of magnitude or more.

In parallel, the Linux operating system had matured in the UNIX industry. It was no longer a pet project and was supported by major distribution companies (such as Red Hat or SUSE). The operating system was following the POSIX international standardization effort, and would be a more natural migration for our teams.

Another major advantage in the modern open source operating system was the multi-media capabilities that were making their way into the mainstream PC world. Modern Internet connections had raised the need for audio and video capabilities at home. Voice over IP was shaking the plain old telephone system business model, and the Linux operating system was pioneering ways to support these features thanks to its very active community. Multi media codex used for the recent Internet applications turned out to have real time requirements that triggered an effort in the Internet community to put new improved real time handling capabilities in the kernel. This initiative was known as the Linux PreemptRT kernel [3]. At the same time chip manufacturers were converging on the hardware modules at the periphery of the microprocessor cores that would handle the management of time and interrupts on the chip (Local Advanced Programmable Interrupt Controller [START_REF]Intel 64 and IA-32 Architectures Software Developer's Manuals[END_REF]). Time management for the simulation application would rely on the newly adopted microprocessor chip standards. Little by little, fundamental patches dealing with the way the interrupts are managed and the way the priorities are handled made it to the mainline kernel source code trunk. Because of this evolution Linux PreempRT was selected for the simulation host. The process is the executing instance of a program [START_REF] Stevens | Advanced Programming in The Unix Environment[END_REF] (the word "task" is used as a synonym). A process has a unique identification number and a priority is associated to that number. The operation of suspending a process and inserting it into the ready queue is called pre-emption [START_REF] Giorgio | Hard Real-Time Computing Sysyems: Predictable Scheduling Algorithms and Applications[END_REF]. The scheduling policy of the kernel selects the next process to run based on the priority number. This allows a high priority process to take the CPU if its priority number allows it. The scheduling policy algorithm computes process priority as explained in [START_REF] Giorgio | Hard Real-Time Computing Sysyems: Predictable Scheduling Algorithms and Applications[END_REF]. This mechanism was introduced in the Linux kernel, in the recent versions of the kernel, in a homogenous manner for all processes. Together with the architecture of timers on the new processor chips it allowed Linux developers to implement a pre-emptive version of the operating system. In parallel, Linux co-kernel simulation became available on the market more widely, with the ability to run an RTOS. For a tighter real time application this solution was selected as a good candidate for the control loops. The main selection for the simulation host Pre-empt RT Linux solution raised a fundamental product life cycle dilemma. In order to ensure the long term support for a Linux based solution through the long life of the integration simulator three options were envisaged:

• Internal development: we are in charge of the operating system and hardware, we experiment the integration choices. We assume responsibility for the entire operating system package integration. • Market expert: we select a complete realtime packaged solution from the catalogue of a manufacturer. • Integrated service: we select an architect consulting company that architects with us, on our recommendations, a real-time solution and is responsible for the package. The third path was agreed on and the integrated service defined. This choice proved to be the correct one: since then, major commercial companies involved in the distribution of Linux have decided to look into this technology. Recent announcements confirm their interest [START_REF]Glossary AFDX: Aircraft Full DupleX CAN: Controller Area Network GPOS: General Purpose Operating System RTOS: Real Time Operating System SMP: Symmetric MultiProcessing VME: Versa Module Eurocard[END_REF] The integration simulator architecture selected was based on multi-core mainstream PC architectures. Ethernet link, with an adequate network topology were selected to connect to the VME equipment performing the interface functions for traditional and AFDX IO. This architecture is being retrofitted to the in_service aircraft simulator of the department. The paradigms and formalism used for the specifications of complex aircraft systems have witnessed significant progress in the recent years, and benefit today from recent improvements in automated code generation. This fact together with the increase in the model precision and broader use of simulation in every aircraft's system will constitute the main driver for our future investigations.

Figure 9:new simulator architecture. These new tools and environments require more computing infrastructure performance, while modelling precision will require tighter real time control loops. Distributed simulation, pre-emptive kernel performance and co-kernel simulations are the lines on which we should be able to draw a solution for our future needs.

Figure 10: architecture forecast Another constraint that Linux helped us withstand was to share binary compatible models for all our simulation platforms.

Conclusion

Architecture choice for an industrial product such as the integration simulator is constrained by the technology solutions available on the market. In the past 20 years we have moved, with some difficulties, from a proprietary technology to a standard set of technologies. And today, we have been able to architect industrial solutions around available mass-market technology. The transition from a Unix based solution to a Linux mass market PC architecture did not trigger an expensive software migration, and this step is economically sound. Mass-market solutions are moving fast, but this continuous move guaranties the flexibility and versatility of our solutions. Monitoring this continuous move represents a manageable effort, and allows the freedom to select the pace at which new technology is introduced in the product. Simulation is more and more used as a validation tool. Representative and precise models will set the rule for the requirements requested of the integration simulator architecture and computing infrastructures associated. Architecture for aircraft simulators is a fantastic domain to explore: there are always new ways to investigate and new questions to ask. VME architecture, for example, will need to be revisited and it is our challenge to look at the emerging technology that will fulfil our needs. Virtual machines today, may not offer real time performance that our integration simulator is aiming at. But product life cycle management schemes that the virtualization enables, as well as ease of migration and third party partner hosting are certainly advantages and we shall periodically revisit the performance of this technology. Lastly, modelling the simulator and abstracting the simulation application from the hardware and the software it runs would allow us to define the architecture of the simulator based on the application it is simulating. The emergence of a formalism in this domain would open the possibility of simulation as a whole. The completeness and functional possibilities of the recent models developed for simulation are set to demonstrate the tremendous help that simulation already brings today to the industry. Technology available in the industry allows following the everincreasing level of precision required in the simulation environment. Our objective will be to look at these new technologies and see how they can serve our goal of providing high fidelity real time simulation for aircraft systems.

Figure 1 :

 1 Figure 1: Basic elements of integration simulator

Figure 2 :

 2 Figure 2: Aircraft 0 simulator

Figure 4 :

 4 Figure 4: Simulator software architecture

Figure 6 :

 6 Figure 6: A380 simulator architecture

Figure 8 :

 8 Figure 8: Monta Vista Fostem 2006In parallel, Linux co-kernel simulation became available on the market more widely, with the ability to run an RTOS. For a tighter real time application this solution was selected as a good candidate for the control loops. The main selection for the simulation host Pre-empt RT Linux solution raised a fundamental product life cycle dilemma. In order to ensure the long term support for a Linux based solution through the long life of the integration simulator three options were envisaged:• Internal development: we are in charge of the operating system and hardware, we experiment the integration choices. We assume responsibility for the entire operating system package integration. • Market expert: we select a complete realtime packaged solution from the catalogue of a manufacturer. • Integrated service: we select an architect consulting company that architects with us, on our recommendations, a real-time solution and is responsible for the package. The third path was agreed on and the integrated service defined. This choice proved to be the correct one: since then, major commercial companies involved in the distribution of Linux have decided to look into this technology. Recent announcements confirm their interest[START_REF]Glossary AFDX: Aircraft Full DupleX CAN: Controller Area Network GPOS: General Purpose Operating System RTOS: Real Time Operating System SMP: Symmetric MultiProcessing VME: Versa Module Eurocard[END_REF] The integration simulator architecture selected was based on multi-core mainstream PC architectures. Ethernet link, with an adequate network topology were selected to connect to the VME equipment performing the interface functions for traditional and AFDX IO. This architecture is being retrofitted to the in_service aircraft simulator of the department. The paradigms and formalism used for the specifications of complex aircraft systems have witnessed significant progress in the recent years, and benefit today from recent improvements in automated code generation. This fact together with the increase in the model precision and broader use

Table 2 :

 2 A380 simulation sizing

	.

Acknowledgement

The work described in this paper is a team effort of the simulation team in our company and partners. All the individuals of the team as well as additional experts contributed to the success. Thanks to you all.