Pierre Dissaux
email: pierre.dissaux@tni-world.com

Session 1B: Design Frameworks Using the AADL for mission critical software development

Introduction

The Avionics Architecture Description Language (AADL) is an emerging standard, prepared by the Society of Automotive Engineers (SAE), Architecture Description Language Subcommittee, Embedded Computing Systems Committee, Aerospace Avionics Systems Division (AS-2C ). The AADL standard is based on MetaH, an avionics architecture description language and toolset developed at Honeywell Laboratories under the sponsorship of the US Defense Advanced Research Projects Agency (DARPA) and US Army Aviation and Missile Command (AMCOM).

The Avionics Architecture Description Language (AADL) is a computer language used to describe the software and hardware components of an avionics system and the interfaces between those components. Extension to other mission critical application domains is of course also considered. The language is used to describe the structure of a real-time system as an assembly of software and hardware components. The language can describe functional interfaces to components (such as dataflows and control flows) and non-functional aspects of components (such as timing properties). The AADL describes how components are combined, in terms of subcomponents composition, interfaces connection and software to hardware allocation. The AADL was developed to meet the special needs of embedded real-time safety critical systems. This paper presents how the AADL can be used for the software modeling phases of the development lifecycle, in association with other applicable standards for embedded real-time systems, or more generally for mission critical systems. The awaited benefit of using the AADL in such a context is to widely improve the formal definition of the real-time software architecture, and to enforce a better interaction between system engineering and software engineering activities.

The compatibility with other model based software engineering approaches, such as the very practical and well proven Hierarchical Object Oriented Design (HOOD) method is established, as well as some tips for using new graphical notations as defined by the emerging UML 2.0 standard. This new approach combining the AADL rigorous semantical definition, the HOOD modeling process and some UML 2.0 graphical notation, provides a comprehensive, ready to use and up to date solution that complies with the requirements of industrial standards like DO-178B for avionics, ECSS-E40 for space systems, and EN-50128 for railways equipments. This approach is fully supported by an off the shelf tool, which already offers various code and documentation generators, as well as reverse engineering features. Finally, this approach is closely connected to the COTRE project, sponsored by the French department of research (RNTL), and which should provide enhanced real-time software verification techniques for this solution.

A summary of the AADL

The following definitions have been extracted from the current draft of the Avionics Architecture Description Language definition (AADL v 0.95). The reader is invited to refer to the final definition of the standard, when it will be released.

The AADL standard provides semantical and syntactical definitions to formally describe a real-time architecture in terms of interacting specialized components. An AADL specification of a system consists of a set of packages declaring a list of abstract components (components types and components implementations) and a static structure of component instanciations to describe the executable application and its allocation to the execution platform.

The abstract declaration of an AADL component in a package consists of one component type, and one or several component implementations. A component type describe the visible functional interface of the component, including a provided interface (list of declarations of public ports and subprograms), and a required interface (list of references to remote component provided interfaces). A component implementation contains all the additional details to fully define the architectural structure of the component, including a list of subcomponents and connections between these subcomponents and modes to describe the various operating states of the system. Several implementations may be defined for a same component type. All the implementations must strictly comply with the corresponding type declaration.

In order to provide an advanced support for real-time modeling, the AADL standard offers a set of predefined components categories which semantics is formally specified. These categories have been grouped into three sets:

• Data, threads and processes are the software components categories.

• Processors, memories, bus and devices are the execution platform categories.

• Systems represent composite sets of software and execution platform components.

Each component category can contain a controled set of features. Features represent connectors in the provided interface of the component, through which control flows and dataflows will be propagated. The AADL specifies three kinds of connectors:

• Ports are point to point connectors for individual data or events.

• Subprograms are composed sets of a control flow and dataflows (subprogram parameters).

• Subcomponent access represent access to remote data or bus components.

Finally, components and features descriptions are completed by a set of predefined specialized properties, providing all the necessary lower level additional information. Properties can be used to specify various kinds of data, such as links to source files or real time attributes. Properties are grouped into property sets, which provide a powerful extension mecanism for the language.

Due to these rigorous and well focused definitions, the AADL is the appropriate language to describe real time or other mission critical system and software architectures. However, in order to bring a maximal benefit to the projects, the use of this language must be considered within the overall development lifecycle. In particular, the issues of specifying a precise software design process, providing standardized graphical notations and advanced verification techniques, must also be addressed. Our proposed solution to meet these requirements, is to use the proven HOOD design process and the new UML2.0 graphical notations, to support the AADL modeling activities. The issue of verifying AADL model is being directly addressed by the COTRE project which is also presented during this conference. Please refer to the corresponding paper to know more about the COTRE project.

The HOOD method

The HOOD method first appeared in 1987 to meet the requirements of the European Space Agency (ESA). The early versions already included a set of notations and precise design rules to support advanced software engineering concepts and Ada code generation rules. In 1992, the version 3.1 of the HOOD Reference Manual (HRM) was published. In 1995, two concurrent major releases of the method were issued : HOOD4, conducted by the French Space Agency (CNES) improved widely the support of true Object Orientation to enable Ada95 and C++ code generation. At the same time, a new ESA project produced a Hard Real Time version of the method, called HRT-HOOD, dedicated to embedded real-time systems, and providing a direct support for schedulability analysis. After several years of operational use of these different variants of HOOD by major European projects, it appeared that HOOD 3.1, HOOD4 and HRT-HOOD were fully compatible and reflected the implementation of the same basic principles for various application profiles.

In HOOD, each Module (including the application itself), has an interface and a body. The interface consists of the Provided_Interface that lists the declaration of all the software elements that are implemented by the Module and made visible to be used by other Modules, and the Required_Interface that lists the references to all the remote software elements that are required to implement the Module. The body is called the Internals of the Module and contains either child Modules (for Non_Terminal Module) or a list of declaration of private software elements and all the implementation (for Terminal Module).

Additionally, HOOD only distinguishes between the Modules "type" and Modules "instances" in two particular cases only. The general case being that a Module is handled as an Object, that is, the unique instance of an anonymous "type". The first particular case is when the Module "type" is described by a Class (like in UML), but then, instances of this Class (which are in effect only instances of the main data Type provided by the Class) becomes Data, Constants, etc… embedded somewhere inside another Module. The other particular case is when the Module "type" is described by a Generic, then, instances of this Generic (which are in effect only instances of the formal parameters) becomes other Modules called Instance_Of. HOOD also supports Generic Classes (similar to C++ templates) that need to be instanciated twice. The only extension mecanism offered by HOOD is the Class Inheritance.

The main contribution of the HOOD method, however, comes from its well defined software modeling process. Based on a recursive top down hierarchical breakdown, this process provides rigorous design rules to enforce "good practices", like incremental documentation and coding, and improve the level of quality and productivity of a project. Moreover, its support by a tool offers automatized features such as multi languages code and documentation generators.

The use of the HOOD method fully complies with the main software engineering standard recommended for mission critical development of avionics, space, defense and some ground transportation projects, such as: -DO-178B for airborne applications (Software Design Process) -ISO/IEC-12207: for information technology (Software Architectural Design and Software Detailed Design) -ECSS-E40: for space applications (Software top-level Architectural Design and Design of Software Items) -EN-50128: for railway applications (Software Architecture and Software Design and Development)

The COTRE project, conducted by Airbus, and with the partnership of several French laboratories (LAAS, IRIT, CERT, ENSTB) and TNI, was an opportunity to investigate the connection between HOOD and the AADL. The result is that most HOOD concepts can be represented by an equivalent AADL paradigm without any major semantical discrepancy.

Although HOOD offers an appropriate set of graphical notations, the main issue that was encountered by many projects using this design method during the recent past years, was probably the unsuitability of the UML 1.x concepts and notations to represent real-time software architectures. This need is about to be satisfied with the new features that are offered by UML 2.0 structure diagrams.

Following description of structure diagrams refer to the "UML 2.0 Final accepted draft" dated August 2003. In the following paragraphs, the texts in italic are quotations from this document. As for the AADL, the reader is invited to refer to the final definition of the standard, when released.

UML 2.0 Components

"A component is a self contained unit that encapsulates the state and behavior of a number of classifiers. A component specifies a formal contract of the services that it provides to its clients and those that it requires from other components or services in the system in terms of its provided and required interfaces.

A component is a substitutable unit that can be replaced at design time or run-time by a component that offers that offers equivalent functionality based on compatibility of its interfaces"

The graphical notation for a UML 2.0 Component is either a "black box" view to only show the interfaces, or a "white box" view to show the internal assembly of subcomponents if any (parts or classifiers). The component logo can be associated or replace the <<component>> keyword.

UML 2.0 Interfaces

"An interface declares a set of public features and obligations that constitute a coherent service offered by a classifier. Interfaces provide a way to partition and characterize groups of properties that realizing classifier instances must possess. An interface does not specify how it is to be implemented, but merely what needs to be supported by realizing instances. That is, such instances must provide a a public facade (attributes, operations, externally observable behavior) that conforms to the interface."

"The set of interfaces realized by a classifier are its provided interfaces, which represent the obligations that instances of that classifier have to their clients. They describe the services that the instances of that classifier offer to their clients. Interfaces may also be used to specify required interfaces, which are specified by a usage dependency between the classifier and the corresponding interfaces. Required interfaces specify services that a classifier needs in order to perform its function and fulfill its own obligations to its clients."

Interfaces can be represented with the compact "ball-socket" graphical notation, or expanded as classes, with operations and attributes:

UML 2.0 Connectors

Like the other compositional notations, UML 2.0 specifies two main kinds of connectors between components: the links between components that are as the same level, and the links between a container component and its parts:

"A delegation connector is a declaration that behavior that is available on a component instance is not actually realized by that component itself, but by another instance that has "compatible" capabilities. This may be another Component or a (simple) Class."

"An assembly connector is a connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port."

To comply with the HOOD method, the assembly connector can be mapped to the Use relationship between sibling components, the (required) delegation connector can be used to describe the Use relationship between a component and its environment outside its immediate parent, and the (provided) delegation connector can be used to represent the Implemented_By relationship. However, unlike with HOOD or the AADL, the delegation connectors only links two interfaces, and doesn't provide the details of the individual links between each features.

All together: Stood v5

Stood is the HOOD tool that is in use for many mission critical projects such as the Airbus A380 embedded software. The last release of the product now includes an AADL interchange feature and a UML 2.0 structure diagrams editor, together with the HOOD notation. All the existing processing features such as design rules checkers, code generators and reverse engineering, and documentation generators remain available.

This was made possible by the various connections that was defined between these three modeling techniques. Each of them brings its specific benefits: AADL offers a powerful and precise semantics for real-time architectures, HOOD provides a rigorous and validated software design process, and UML 2.0 now brings a standard notation to describe these systems. A summary of the corresponding mappings and a preliminary snapshot of the Stood v5 tool are shown below:

-22 -23 January 2004

Using UML 2.0 structure diagrams UML 2.0 introduce structure diagrams to model component based architectures. These new UML concepts and notations is being studied in order to consider there use as a support for both AADL and HOOD paradigms.

By integrating these new technologies into an already deployed software development environment, the aim is to ease the dissimination of model based solutions to new projects, and to preserve the investment of those who already chose advanced modeling techniques during the past ten years.


Jean-François Tilman

Axlog Ingénierie

Session 1B: Design Frameworks Improvement of the system engineering and use of an architecture description language

The embedded real-time systems are more and more complex, and the safety or reliability requirements are stronger and stronger. In this context, many projects are led to improve the development processes. They show that there is a need for a means to more formally describe the developed systems and share information during the whole development cycle. The use of an architecture description language (ADL) is a good solution. It enables easy communications between different teams, tools, methods.

AADL (Avionics Architecture Description Language

) is an ADL dedicated to the description of avionics, and more generally all the embedded real-time systems. It is based on MetaH, developed since 1991 in the United-States, and its international standardisation is in progress under the authority of the SAE (Society of Automotive Engineers). AADL has been evaluated in the space domain; it appears that it is an interesting ADL to support the future development processes, because of its strong semantics and its flexibility.

With the use of more formal approaches, the objective of the future development processes may be the proof-based system engineering. This provides many advantages: no break from the capture of the need to the validation of the system, early detection of the problems, proofs of the correctness, reduction of the test effort, possible automatic generation... The automotive domain has also the same objective as the aerospace industry, as illustrated by the EEA project, and its AIL-transport architecture description language. It should be profitable to compare the practices of these different domains which could mutually fertilize themselves.

Introduction

The embedded real-time systems encompass more and more components, and the part of the software is increasing exponentially. This complexity is always more difficult to manage at the whole system level, as shown by the failure, delay or cancellation of critical systems: Taurus (stock exchange), Relit (stock exchange), AAS (air traffic control), Confirm (on-line hotel and car reservation), Socrate (on-line railways seat reservation), Freedom (manned orbital station), P20 (nuclear power plants), Arial 5 Flight 501 (satellite launcher). In the same time, the requirements for high safety or reliability are stronger. But nevertheless the current practices in system engineering are exceedingly empirical, and prevent the system engineering sector to become industrially mature. So, the system engineering has to evolve.

The main actors in the domain become aware of this situation (e.g., what ESA calls the "software crisis" [START_REF] Kjeld | ESA Software Initiative[END_REF]), and several major projects have been initiated to deal with this situation and propose improvements in various domains [START_REF]COTRE project home page[END_REF] [3] [START_REF] East-Eea | Embedded Electronic Architecture[END_REF]. What appears when thinking about the possible improvements is that the solution will need the introduction of more formal approaches in the development process. This is the work direction followed by some of these projects.

The following sections present how innovative approaches may help to succeed in this challenge by using formal methods such as proofs, and how architecture description languages will have to play a role by supporting these new processes during the whole lifecycle. The importance of the tools will also be mentioned since their existence or lack may condition the diffusion of any method. After the presentation of these concepts, largely inspired by the avionics practices, a different point of view will also be given for the automotive domain, which presents interesting particularities.

Formal approaches

Many aspects of the development cycle in system engineering may be improved by more formal practices. A few counterexamples will illustrate this argument. When the communications between the different actors of a project are done in a natural language, some interpretation problems may appear, and the correct information is not well transmitted. How many times the need of the client is not well suited by the developed solution? The generalized use of a more formalised communication means between the actors may reduce this risk of misunderstanding. Another example illustrating the purpose is the failure of Ariane 501, which was due to a fault at the system level [START_REF] Gérard | The failure of satellite launcher Ariane 4.5[END_REF]. This fault could have been detected with a formalised method to check the fulfilness of the requirements when reusing an existing building block.

These two examples illustrate the fact that some common problems are due to informal practices, based on human experience, and then subject to human errors. More formal practices may help in the reduction of these problems of system engineering, by avoiding uncertainties. But formal approaches are not only interesting by reducing problems, they may also provide solutions to go further, for example by automating complete activities of the development lifecycle (code generation, test generation, etc.). As we will see later, the use of formal descriptions of the architectures are required to expect a powerful automation of these activities.

Use of proofs

Some formal techniques already exist for various system engineering activities. Among them, one of the well known, and perhaps also one of the less mastered and applied, is the use of proofs. The interest of a proof is obvious: what is proven correct does not need to be tested. Since the test phase often requires considerable efforts in term of time, manpower and money, each technique which could reduce this phase without loss of quality should be considered.

Nowadays the use of proofs is fairly common for particular and local parts of the project (real time properties such as schedulability, etc.). These practices are often associated with the use of dedicated formal languages (e.g., Lustre, Esterel, SDL) and their supporting tools, which provide proven solutions for specific problems. We can also note that these techniques often only appear at a detailed level of the development lifecycle, near the implementation phase. They generally use the formal model of a given building block and produce the code which implement it. This technique is interesting but there is not a specific method for each part of the system, and many parts of the code may be manually written for a long time again. On the other hand, techniques exist to prove other aspects, such as the generation of a set of tests with a proven complete coverage (e.g., InKa [START_REF] Axlog | InKa Project web page[END_REF], Agatha [START_REF] David | Validation and automatic test generation on UML models: the AGATHA approach[END_REF]). But these proofs are not largely applied.

The use of proofs at a global level is also possible, but is much more difficult, and may not be done in a similar approach. Indeed, the increasing complexity prevents from processing the same formal checks on a global system like on a well delimited subset. In return, some practices dealing with the whole system during other phases of the development, and mainly the top ones, may take advantage of proven approaches. Many proofs may be interesting at these levels: proof that all the needs of the client have been captured with no lack or ambiguity, and particularly with all the implied needs, proof that the resulting specifications are complete and coherent, proof that the composition of the system and the reuse of existing building blocks are correct and fulfil the requirements, proof that the integration tests completely cover the specifications, etc.

Proof-based system engineering

It is unrealistic to envisage the development of a completely proven system for the moment, and probably for a long time again. Indeed, too many problems have not yet known solutions, or the theoretical solutions are unpractical in a realistic case (e.g., theoretical worst case analyses may require enormous systems to tackle improbable fault situations). Nevertheless many other results of the theories exist but are not applied in the current practices. For example proven algorithms exist to solve common problems (e.g., distributed consensus and coordination algorithms), but they are not used and the same poor solutions are always implemented, and always generate the same failures.

The purpose of the proof-based system engineering (PBSE) is to provide improved processes for the system engineering where the known proven solutions will be used. Both technical solutions for particular problems (e.g., scheduling, resource management, etc.) and methods to deal with global aspects (e.g., production of a specification which is proven correct). Since it is probably too difficult to apply immediately a completely proof-based method, PBSE might stay a realistic middle term objective. The first steps towards PBSE will be the elaboration of good practices.

TRDF

TRDF , which means (in French), « real time, distributed treatments and fault tolerance », is one of the most mature, if not the only, PBSE methods [START_REF] Gérard | Proof-Based System Engineering and Embedded Systems[END_REF]. This method has been developed at INRIA for ten years and validated on industrial projects.

The TRDF process is organised in three essential phases: the capture of the problem, the system design, the system dimensioning. The first phase, also called the requirement capture, has an application problem description as input. This description may be incomplete and ambiguous. From this material, the purpose of the phase consists in the production of a complete and coherent specification of the problem and its requirements. One of the difficulties tackled by this phase is the capture of the implied needs of the client: from his point of view, some information is obvious for his domain and he does not give them explicitly.

The system design phase consists in the specification of a solution with respect to the requirements defined by the first phase. Each design stage needed to arrive at this solution is complete when correctness proof obligations are fulfilled. For example, a system may be composed by the reuse of existing building blocks, provided that the hypotheses to reuse it are verified. At the end of the design phase, a solution is specified for the problem, which is proven correct and complete with regard to the initial requirements. This solution may still contain parameters which may be adjusted with the particular needs. For example, some building blocks composing the system may be parametered (memory size, number of processors, etc.). So, the system dimensioning phase consists in the valuation of these parameters. Of course, the values given to these parameters may have consequences on other parts of the system: a high reliability may imply more replicas of a function, which may imply more processors, etc. All these constraints are checked during the dimensioning phase.

As any formal method, TRDF requires some training to be used by hand. Nevertheless, the use of tools supporting the different phases of the method may help the user and avoid this prerequisite to apply TRDF. For the moment these tools do not exist yet. This may explain why, although the method has been validated, it is not yet deployed in the industrial processes. However, some projects are currently starting and will fulfil this lack [START_REF]ASSERT: Automated proof based System and Software Engineering for Real-Time applications[END_REF].

Architecture description languages

In the previous sections we have seen the general interest of more formal practices for system engineering. We have also mentioned the problems resulting from the communications between actors when using a natural language. So, it seems normal to also search for a formal means to communicate about the system under development. This is where an architecture description language (ADL) may play a role.

Due to the very general meaning of the ADL acronym, plenty of different ADLs exist in the world, for a large variety of purposes. We are only interested here by those which are able to describe the complete architecture of the system, that is both the software part and the hardware supporting the software, and for general purposes.

With this restriction, only few ADLs currently exist and seam interesting for our purpose. One of them, called AADL, is under standardisation and has already been proposed for such a role in a major project, ASSERT [START_REF]ASSERT: Automated proof based System and Software Engineering for Real-Time applications[END_REF]. The other alternative, if needing an ADL, is to create a new one from scratch. Other projects have chosen this solution, but we sometimes observe a convergence with an existing ADL like AADL.

Interest of an ADL

An architecture description language (ADL) is a formal means to describe a system. Thus we immediately imagine that its use may favourably replace the use of natural languages between the different actors of a project, and then reduce the misunderstanding problems. The choice of an ADL is then coherent with the will of more formal practices. But an ADL is also a mean to communicate between the various tools used in a project, or to store and manipulate a coherent and unique representation of the system under development. The previous mention of the use of proofs has given the feeling that the same formal information may be used at different stages of the development, since the capture of the requirements to the specification of integration tests covering these requirements. The figure 1 shows many activities and tools which may use a common description of the system architecture during the lifecycle.

Figure 1Use of an ADL in the development lifecycle.

Another important interest of the ADLs does not well appear in the figure 1: the reusability. Indeed, since a building block has been completely defined, and formally described with the ADL, it may be stored in a data base. Then it may easily reused for a new development in the future. The risk when reusing an existing component is that it might be not exactly adapted to the problem. If this risk is not well taken into account, a failure such as Ariane 501 may occur. This shows the importance of the formal methods to check the compatibilities, as described before. And of course, the ADL used to describe the component must be able to contain all the needed information to perform these verifications (validity hypotheses, etc.).

Requirements

When choosing an ADL to provide the support of the system engineering process during the whole development lifecycle, we have to take into account several requirements. The use of an ADL is interesting if the same ADL is used during all the activities of the development lifecycle, and if the needs of each activity are fulfilled by the ADL. This implies that the whole system architecture may be described by the ADL (both software and hardware), and that the language must be generic enough to deal with various kinds of information. Each activity of the development lifecycle may have very specific needs in term of information related to the manipulated architecture and it is impossible for a given ADL to natively support all of them. So, the used ADL will have to provide extension mechanisms to support them. These mechanisms will be used to handle the needs of the different actors of the system engineering. Once an improved system engineering process has been defined by using an ADL, its dissemination will be related with the dissemination of the used ADL. So, an important aspect of any ADL is its standardisation. Indeed, the existence of a standard is a strong advantage to promote such a language. We will also see later that the existence of tools is very important to support the process. The tool vendors will be encouraged in the development or adaptation of tools for a given ADL if this language is a standard.

AADL

AADL [START_REF]Avionics Architecture Description Language", version 0.92[END_REF], whose name means "Avionics Architecture Description Language", is an ADL initially dedicated to avionics. It is based on MetaH [START_REF] Honeywell | MetaH home page[END_REF], which has demonstrated for more than ten years the quality of its concepts. AADL is currently in an international standardisation phase, under the authority of the SAE (Society of Automotive Engineers), and more precisely the Aerospace division. In spite of its name, the application field of AADL is the whole real time embedded system domain, not only the avionics one.

The main principle of AADL is to describe an architecture as a composition of components, and to describe these components. Each component description is divided into a "component type" and a "component implementation". The former represents the functional interface, that is, how the component is seen from outside, and the latter represents its internal description. This feature of the language is very interesting for the purpose of system engineering. Indeed, it is possible to separate the specification of the component, which is in fact its type, and its design which is the implementation. The coherence between the type and the implementation is automatically checked. In a well defined process, the author of the type description will probably not be the same as the author of the implementation description.

AADL also offers mechanisms to represent requirements in the (re)use of components into an architecture. For example, it is possible for a given component to require the existence of another component at the same level of the architecture to be instantiated. The purpose of this paper is not to give a complete description of AADL. For more details, see [START_REF] Axlog | Detailed presentation of AADL[END_REF].

AADL is interesting for our purpose since it is generic enough and offers extension mechanisms to support the needs of the different activities of the lifecycle. Moreover this language is currently standardised by an international committee, and some partners of the system engineering projects mentioned before are members of this committee. This is a good opportunity to integrate improvements directly in the specification, and then have a well suitable ADL.

Tools

We have seen what could be improvements in system engineering practices: more formal approaches, and particularly the use of formal descriptions. Now, let's have a look on the practices in the real life. Today, many activities are supported by dedicated tools to help the user in his work.

If the development process is improved to take advantage of new formalisms, the tool aspect will also have to be taken into account. Since the whole development lifecycle is considered here, we may also imagine new design frameworks covering all the development process.

Fundamental role

Whatever the quality of a system engineering method may be, it has no chance to be applied if not supported by tools. First, we need tools to help the user in the application of the new methods. For example, a requirement capture tool will help the developer in the collection of the information about the needs of the client. Second, the tools already used in the current processes must stay useable in the new processes, to avoid too many changes in the habits.

The tool aspect of the problem constitutes also a justification for the use of an architecture description language in system engineering. Indeed, since a single ADL is chosen for the whole process, any tool may use it as input or output to communicate. This approach also avoids many translations of the manipulated information at different steps of the development lifecycle.

Difficulties

As mentioned before, all the activities of the development lifecycle should be covered by the tools. For some of them the feasibility is already mastered, and the purpose is just an adaptation of existing tools. But other phases are completely new, and the associated tools must be invented: requirement capture, oracles checking the fulfilment of proof obligations, etc.

Another difficulty may be risk of incompatibilities between ADL extensions. Indeed, whatever ADL is chosen, it will have to be extended to support all the needs of the different activities. If each one develops its own extensions, two tools covering the same problem may be unable to share the same information. So it will be necessary to well organise this work during the projects, and search for factorisations between them.

Automotive context

The previous sections have presented a generic point of view, although it directly comes from the experience of the aeronautic and space industry. The automotive industry has also developed similar projects and ideas to improve its engineering processes. The general needs of this industry are about the same as the other embedded system ones. The "Xby-wire" (drive-by-wire, brake-by-wire, etc.) evolution imposes high reliable and safe systems, and the certification question is currently taken into consideration. The avionics practices may provide interesting solutions for this domain. However, other aspects are more particular such as the need to deal with many variants of a same project, depending on options and choices proposed to the client. The cost dimension is also probably more critical, in an industry where each cent is counted.

In this context, we can mention the EAST-EEA project [START_REF] East-Eea | Embedded Electronic Architecture[END_REF]. Its goal is to enable a proper integration through the definition of an open architecture, and then to improve the interoperability and reusability of the components. To reach this objective an ADL is currently developed, EAST-ADL. Since the project is inspired by the previous AEE project [START_REF] Aee | Architecture Électronique Embarquée[END_REF], EAST-ADL is inspired by AIL-transport, which is an ADL resulting from the AEE project. An overview of this ADL is given below.

AIL-transport

This ADL, coming from the AEE project, is a graphical architecture description language based on UML. It is dedicated to the car architectures. This language proposes many objects representing all the elements of the car architecture, both software and hardware ones: processors, devices, network, functions, messages, etc.

The use of AIL-transport is organised in several predefined levels, which enable the separation of the description into a specification point of view and a conception point of view.

The main difference between this approach and the one described before is that AEE is very specialised, and defines a strict frame to develop automotive architectures. This difference also appears between AIL-transport and another ADL such as AADL: AIL-transport defines a complete list of well defined components whereas AADL defines categories of components which may be extended by the user.

Conclusion

We have seen that current practices in system engineering may be improved by the use of formal methods and particularly by the use of formal descriptions. This conclusion has been drawn by major actors of the embedded domains such as aeronautic, space or automotive, and projects are led with this objective.

In this context the architecture description language may play an important role since they enable the needed formal descriptions of the manipulated system architectures during the development.

Lastly, the tool aspect must not be neglected since they are essential to support and promote good system engineering practices.

-22 -23 January 2004


P Mortara

Session 1B: Design Frameworks Hardware and Software Development Framework for Embedded Automotive Electronics

Electronics in Automotive

Applications is constantly growing with an increasing quantity and complexity of their related embedded software. Multiplexed networked architectures give the possibility to implement different distributes solutions thus allowing optimized partitioning. This paper has the aim to describe the Hardware and Software Development Framework conceived and realized in Ixfin Magneti Marelli Electronic Systems in order to improve and optimize design and prototypes implementation of distributed electronics in the area of body applications. Quick function re-allocation, solutions reuse, customer function integration, time to market reduction and R&D costs containment were the main objectives of this project. The document starts with a brief overview of the development process introducing the concept of the platform approach. Then both the Hardware and in particular the Software development framework are described and discussed in details. Some examples of real applications of the framework, performance indexes and balance metrics of the obtained results are presented in the conclusion. 1.

INTRODUCTION

Electronics in Automotive Application will grow strongly in the future years. Concerning Body Car Applications (body computer, doors / light / seats management, antitheft, climate control..) starting from new products generation up to 2005-2006 is also expected that Multiplex Systems will gradually move to a Sub-Systems integration increasing in the meantime the number and the complexity of functionalities. Dialing with such a scenario, instead of an ECUs modules development approach, a 360° System vision is necessary. This will be useful to assure flexibility in hardware and software design, to grant possibility of quick function reallocation, reuse of solution, reducing time to market and containing R&D costs. Functional distribution on different nodes allows the optimization of computing power in the Multiplex Systems: algorithms, strategies, and high level functions do not necessary need to be resident in a specific ECU. Optimal function partitioning improves flexibility in the multiplex system definition, from low end up to high end configuration. This article has not been conceived with the aim to discuss engineering principles, but to illustrate with a real fact description the concrete example of their application in the R&D center of an industrial automotive electronic component supplier. The paper is principally focused on the hardware and software development framework for prototyping platform based design. Nevertheless for more clearness a very short overview of the process and the others main development stages are recalled in Chapter 3 More details on system design and software engineering concepts can be found in the articles listed in the bibliographic reference.

PLATFORM CONCEPTS

Following the above considerations Ixfin Magneti Marelli Electronic System has defined a Development Process based on Platform approach with these main objectives:

• To anticipate the needs for functionality of customers • To anticipate technological and methodological steps aiming to take competitive differentials and to improve product functionality • To develop on the shelf available competitive solutions A product Platform is:

• A defined Hardware and Software System Architecture

DEVELOPMENT PROCESS

The "Y" graph of the System Design approach is synthetically represented in Fig. 1.

Modeling and Simulation, Architectures and Components selection and the different possible instances mapped solution provide the input to the Hardware and Software develepment framework for prototype implementation. This phase uses in input the set of functional requirements coming from different customers as well as internally defined preliminary specifications for new innovative functionalities. This represents the functional system perimeter that will address the platform development approach. With the modeling and simulation activity performed with appropriate tools (continuous and discrete modeling, network simulation) preliminary different possible distributed architectures are verified.

ARCHITECTURES & COMPONENTS -MAPPING

To allow preliminary individuation of the optimal hardware architecture and components able to satisfy the requirements characterized in the previous analysis stage, a dedicated internal company tool called F_DIAMOND has been designed. F_DIAMOND is the acronyms for Function Deployment on Instances and Architecture Mapping Of Device.

It's essentially a software database; it has been conceived to collect technical, economics and availability time information of new devices offered by semiconductor market for automotive applications. Added to the database feature there are some special functions that can help designers to:

• Define a set of hardware requirements (elementary resources) • Find the available devices into the database that satisfy partially or totally the requirements • Choose a set of devices ( one or more) that can perform the required functions • Compare different solutions in terms of performance, cost and timing. • Collect and summarize the results in standard format report files

Fig. 2 Database Components Library

The main goal of the database, was to create a supporting tool compatible to the "Y development flow " of system architecture, described in Fig. 1, in order to evaluate alternative electronic architectures.

F-DIAMOND provides to:

• Organize component's information offered by the market in a database. In Fig. 2 an example of the GUI for micro-controllers data entry is represented.

• Support the definition of the electronic resources required by the platform, starting from the functional requirements.

• Give the support to associate these components in architectures fulfilling the Platform's requirements. This means to help designer searching components and collect them in a kit (named instance) that satisfies the requirements (instance creations) (Fig. 3).

• Give support for comparison evaluations of alternative instance solutions regarding technical performance, cost and availability.

HOW (HARDWARE OPEN WORKBENCH)

.

The HOW (Hardware Open Workbench) represented in Fig. 4, as been designed with the aim to support in an adequate way the hardware prototype development with the following main objectives:

• Quick implementation of new functions

Fig. 5 Logic Board

The basic assumption is that any logic architecture for platforms Nodes will use the same SLB; the quantity of I/O features present on LSB will depend of course from the complexity of the particular Node.

Completely different logic architectures, starting for instance from the smallest Node to the most complex Body Computer, based on different micro-controller, can be implemented on the base of the same board boundary.

FPGA BOARD

The FPGA Board implemented on a 150x150 mm PCB (Fig. 6) has the aim to provide the mono-directional digital I/O connection between the Logic Board and Plugs-In Boards. This is designed using a BGA 600 FPGA giving a flexible solution for easy and quick Logic and Functions reallocation. In consideration of the high number of signals, the connection to the Big Board is implemented using 8 Flat Cables. For more stable environment such as final platforms to be released to the Application team this Board may be removed and substituted with direct connections realized using a Wire Wrapped Harness: this is also a cheaper solution respect the more flexible but also high expensive FPGA approach.

The FPGA used in the body platform supports the insystem programmability (ISP). Configuration data are downloaded from the PC parallel port via a download cable. All functionalities are implemented using this predefined scheme and grouped in an homogeneous way. In case the functionality exceeds the capability of the perimeter, it will be splitted in more Plug-in. Some examples of Function Boards Plug-in are: Analog Input, Digital Input (Fig. 7), Relais Driver, SmartMOS Driver, Serial Line Transceiver (CAN/LIN Driver), RF modules…etc. The middleware with their internal standard A.P.I. provide the mean for interaction with the high level application functions.

THE SOFTWARE LAYER STRUCTURE

The Components and their related sub-modules of the Software Architecture are mapped in 5 Layers (Fig. 10). • Presentation Layer: provides standard access to process data.

• Application Layer: provides application dependent function and some particular configurable services, such as gateway function, periodic and/or event messages transmission. • • System Layer: provides management of the overall software. Operating system, scheduler, boot software is here included. It provides the declaration of common definition for all platform modules.

Each Layer communicates with the others by means of internally defined standard API. The same for the Network Management even if for some car manufacturer the component is directly implemented in the Application Layer following the customer specification.

The OSEK specifications was defined with the aim to improve re-usability / portability of the embedded software components. Nevertheless OSEK concerns the RTOS and part of the network communication system, but does not take in charge other input/output system interface with the hardware subsystems. Thus the software implementation only based around OSEK environment is not enough to enable the completely re-use and portability of software components. This is the reason why the environment called MOSAIC in which a specific API abstracts the interface between the application software and the system platform has been conceived and internally designed.

In the following an essential overview of this environment is provided. More details can be found in [START_REF] Bettini | A Configurable Software Platform for Embedded Systems[END_REF].

5.3.

MOSAIC MOSAIC take in charge the software components that are not provided by the OSEK/VDX standards. Basically implements the abstraction layer from the logic boundary hardware architecture (Fig. 11) such as the internal microcontroller peripheral devices (A/D converter, digital and frequency I/O channels etc.) as well as the external dependencies, typically sensors and actuators management. MOSAIC software pieces are implemented like a components libraries that can be configured and specialized using the MOSAIC manager. All I/Os of the same type (e.g., analog inputs, PWM inputs, digital inputs, digital outputs) are grouped together and managed by a specific software component called the I/O engine.

Fig 11 MOSAIC Architecture

The main configuration scheme is represented in Fig. 12. All configuration parameters are stored and maintained in a relational database. The database contains components data describing the hardware platform and all sensors/actuators of the system and application specific data of the I/Os configuration for a specific control unit on the vehicle network . The configuration Manager provides the interface between the user and the database allowing the data introduction and automatically implementing validity and consistency checks. By means of dedicated GUI sessions it is used to introduce I/O hardware and software informations. Hardware information includes component selection (microcontrollers, analog and digital multiplexers, power devices..) resource allocation including pin assignment, I/O ports, registers and memory map. Software information includes all the parameters necessary for the acquisition or actuation of the I/O as well as for the intermediate treatments defined at the API level. For instance linearization tables for A/D treatments can be introduced choosing between several structure type: linear, step with hysteresis, dynamic and others (Fig. 13 A new node configuration can be created copying and modifying from an existing one thus reducing the effort. When the configuration phase is terminated the MOSAIC environment will be able to provide the code generation. In according to the rules defined in each I/O engine in the template module, the configuration data are extracted by the parser from the data base. The configuration files to be included and linked with the I/O engine modules and application software will then automatically created by the code generator that will provide with the configuration data insertion. The specification of the implemented module can be automatically produced by the documentation generator that reports all the information contained in the database in a formatted document. The overhead introduced by this configurable layered environment (5%-20% for ROM, below 5% for RAM and less than 10% for CPU load) is tiny respect the acquired benefits. The effort needed for a complex node configuration is today evaluated in hours instead of weeks for manually written coding approach. Only few minutes are required to make changes due to significant hardware modifications. .

EXAMPLE OF A COMPLETE FUNCTION

In the Fig. 14 the example on how a complete UHF receiver function is mapped in the four layers of the software architecture is illustrated. Using this layered structure, for instance in changing the remote transmission device with a new one that use a different data encapsulation, only the Presentation Layer of the receiver function need to be changed, while substituting the receiver components both the Driver and Control Layer have to be modified; if this two level of the software receiver management are implemented in the MOSAIC environment the modification can be done only using the configurator thus avoiding any direct modification of the source code. Any changes on the upper level strategies control will require interventions in the Application Layer only. Obviously is the same for software: the configuration feature provided by the OSEK components and in particular by the MOSAIC environment, beside time and money savings, will drastically reduce the possibility of errors introduction of manual coding, thus improving quality and reliability. Moreover the well structured layered approach easily allow the function application integration as well as their partial modification.

BALANCE METRICS

As an example of the benefits of the application of the framework, the results of a porting activity due to the change of a micro-controller in the Body Platform will be described in the following.

A favorable contract with a silicon supplier entailing the use of a new 16 bit micro-controller on Body Electronics Applications was signed during the product development.

An hardware and software porting activity to microcontroller B from the existent Body Platform based on a micro-controller A was consequently swiftly addressed.

Due to the advanced development phase, time constraint was very tight, and a detailed aggressive plan has been drown up with the silicon supplier that was involved in the porting activities and development tools reintegration.

Excluding the third part software components (OSEK OS and COMM ) the amount of implemented software at the moment of the micro-controller change was 46 modules for a total of 23452 pure line of code (without comments and empty lines).

The actors in the porting activities were:

1. The Silicon Supplier

• To assure the HAL MOSAIC modules porting and some others low level drivers, the microcontroller B development environment and tools support. • To support Ixfin Magneti Marelli for the software integration/verification till end of platform delivery.

Third part Software Components Supplier

• To assure the availability of the complete software suite (OSEK OS,COMM,TP & KWP2000) for the specific micro-controller B

Ixfin Magneti Marelli

• To assure the porting of all the above layers and the complete software integration/verification • To integrate the third part software components with remote support of the supplier.

From the hardware point of view, using the Open Workbench only few days were spent to redesign the Logic Board substituting the CPU and some glue logic components. Interconnection with the plugs-in was made with jumpers and a swift FPGA reprogramming.

Related to the Software only the 50% of modules required modification. The remaining 23 modules have been reused as their was just re-compiling the C source code for the micro-controller B.

The percentage of modified code lines respect the total (23452) was 28%.

We must point out that the micro-controller B was a completely new one and the low level drivers of the MOSAIC were not yet available in the library. So, in terms of effort a significant part were related to the HAL modules of MOSAIC (that includes the hardware depended software and low level drivers) 35%, one serial communication driver that has been rewritten in software due to the absence of one more UART on the new micro-controller 10%, third parts modules integration/adaptation 15%, and the remaining effort was spent for general environment troubleshooting activities (Emulators,Compilers,…). The porting activity begun in the second half of July 2001 and has been successfully finished in less than two months. This include the complete software integration and verification at laboratory bench. The structured layered architecture of the Body Platform has allowed a good job partitioning and the possibility to work in autonomous way in different separate sites. Despite the fact that Platform Software, at that stage of development didn't yet include all the application and a great part was quite near to the hardware dependencies, the 50% of totals modules didn't need any modification and have been reused as their was just re-compiling the source C code. The remaining porting of application functions to complete all the Body features has not increased significantly the effort already spent. The effort spent for pure software porting was drastically reduced: more than 60% less respect an equivalent less structured and not Platform based previous porting. Now the availability of many micro-controllers abstraction layer integrated in MOSAIC allow us to gain another great reduction in development time. As asserted in [START_REF] Bettini | A Configurable Software Platform for Embedded Systems[END_REF], the time needed to implement changes for different architectures is now really measured in days.

CONCLUSIONS

In this paper the development process and the Hardware and Software Development Framework conceived and realized in Ixfin Magneti Marelli Electronic Systems in order to improve and optimize design and prototypes implementation of distributed electronics in the area of body applications have been presented. This is a concrete example of the application of several engineering techniques and in particular the platform approach described in [START_REF] Bettini | A Configurable Software Platform for Embedded Systems[END_REF] .. The application of the framework dials with new complex scenarios in automotive electronics in which instead an ECUs modules development approach, a 360° System vision is necessary and a rational function partitioning is a must to improve flexibility in the multiplex system definition, from low end up to high end configuration. Moreover quick function re-allocation, solutions reuse, customer function integration, time to market reduction and R&D costs containment take significant benefit with the platform approach implemented in the framework.

As illustrated in the examples of application in the area of Body Electronics, technical results was very good. The use of the HOW give the advantage of rapid prototyping environment but is very close to the final product : circuit solution and software remain exactly the same. Finally, the balance metric example of the porting activity illustrated at the end confirm the validity of the approach.

9.

•

  A library of standard configurable Hardware and Software validated components • A set of test solutions, modules and tools • A defined industrial process • A workbench useful for the development of the first functional prototypes of all applications

Fig. 1

 1 Fig. 1 System Design -"Y" flow graph

Fig. 3

 3 Fig. 3 Create Instances

Fig. 4 HOW

 4 Fig. 4 HOW (Hardware Open Workbench)

Fig. 6 FPGA

 6 Fig. 6 FPGA Board

Function

  Boards implements the modularly Plug-In concept. They host the hardware features to be implemented around the Logic core. Each Function Board from the structural point of view is designed in the same way and it is basically composed by a 80 x 50 mm PCB, 14 pin Connector for the external I/O and 20 pin Connector for the FCB.

Fig. 7 Function

 7 Fig. 7 Function Board Plug-In (Digital Inputs)

Fig. 8

 8 Fig. 8 LIN Node

Fig. 9

 9 Fig. 9 Software ArchitectureThe low level is composed by the basic I/O modules drivers for analog, digital and frequency signal management. discussed in[START_REF] Bettini | A Configurable Software Platform for Embedded Systems[END_REF] this part represent the HAL (Hardware Abstraction Layer) that include all the micro-controller and the Hardware devices dependent Software. Basic functions are integrated for the most part in a developed in house environment called MOSAIC (Modular Open Software Architecture, Integrated and Configurable). The skeleton of the Software Architecture is completed with the OSEK compliant Communication Components and the Operating System normally acquired from third parts software suppliers. The middleware with their internal standard A.P.I. provide the mean for interaction with the high level application functions.

Fig. 10

 10 Fig. 10 Software Platform Layers

  configurable and OSEK compliant real time Operating System and CAN driver with Keyword 2000 communication protocol and Transport Protocol are the only third part software components used in the Gen. 2 of our Platform Architecture. The choice of the Operating System Conformance Class depends of the characteristics/complexity of the node, but basically for Body Applications the most used are BCC2 and ECC1. KWP2000 and Diagnostics Services are usually specialized in the respect of the OEM customers requirement and implemented by the third part software supplier itself.

  ). The configuration manager today supports I/O modules such as: • Analog inputs; • Digital inputs; • Digital outputs (including power devices and PWM); • Frequency inputs; • LIN; • Stepper and DC Motor controllers • EEPROM Driver The complete hardware and software informations set introduced with the Configuration Manager represents the configuration characteristics of a node. Several nodes can be created, modified and managed with different versions.

Fig

  Fig 12 MOSAIC Configuration

Fig

  Fig. 14 UHF Remote Control Function

Fig. 16 "

 16 Fig. 16 "HOW" to build the product -Central Nodes

  This is the fixed part of the Workbench that remain the same for any implementation. Big Boards may represent what in the actual Body Multiplex Systems are normally called Body Computer and Body Nodes (doors, roof, trunk..etc). Big Board hosts connectors based Logic and Function Plug-in interconnected by a FPGA (for logic signals) and manual jumpers (for analog signals). The interface to the externals sensors/actuators implemented in the laboratory Bench Simulator or in the Car is provided with dedicated connectors. Big Board has been designed in order to host up to 21 Function Boards Plug-In.

	4.1.	BIG BOARD
	The Hardware part of the development framework is based
	on a 590 x 470 mm four layers Big Boards PCB
	implementing the basic layout interconnection between
	every plug-in connectors (Logic and FPGA flat cables
	connectors, Function Boards connectors, external
	connectors...).
	• Easy & quick function re-allocation / partitioning • Test / Verification of different system architectures • Test / Verification of different components/circuit
	solutions • Fast reusability in several projects and the possibility
	to share circuit solution between different teams • Direct use of hardware circuit solutions just re-
	composing the electrical schematic, and build-up the
	definitive Layout • Use of the software platform running on workbench as
	it is on the product

-22 -23 January 2004

ACKNOWLEDGMENTS

Thanks to Piero De La Pierre and Franco Salerno for their contributions, and to Jean Lopez, Roberto Bettini and Antonino Damiano that have constantly supported and inspired the work.


Alain Fernandez
email: alain.fernandez@cert.fr31036toulouse

Session 2A: Testing Model generation techniques to debug software

In this article, we consider the test of synchronous data flow software (written in SCADE) embedded in aircraft computers. The validation of such software is a complex process, which requires some tests in real conditions (e.g. flying conditions). During these tests, some variables of the software are recorded at a chosen frequency. The recorded data represent a partial observation of the state of the computer during the flight. When an unwanted behaviour of the aircraft is detected during the test, we need to identify the cause of this behaviour from the recorded data in order to choose the best way to correct the software. The cause of the observed behaviour can be determined by computing some scenarios consistent with the partial observation according to the specification of the system. The number of plausible scenario might be high and we have to identify a finite subset of the most relevant scenarios. Indeed, each computed scenario involves particular computation paths in the SCADE software. It is worth noting that a computation path can be activated by a class of scenarios. So we propose to compute a scenario per path to identify the part of the software which should be corrected. For these purposes, we have used GATEL tool. We show how to use this tool on an example taken from software of an A320 computer for which the engineers observed the detection of non meaningful alarms, and we compare the result obtained with each tool. For such experiment, the main difficulty is due to a problem of combinatorial explosion, and we show how these tools can take into account the engineer knowledge about the system in order to reduce the number of possible scenarios.

Introduction

The debugging of real time embedded software consists in finding out the cause of an unexpected behaviour from a generally partial observation of the calculator state. More precisely, we need to identify the input data value, which leads to erroneous value of the output data, or of any observed data (e.g. internal data of the software observed by a development tool). In a way, the activity of debugging can be seen as the dual of testing which consist in fixing the value of input data, and to check the corresponding output value against the specification.

In this paper, we suggest a technique to assist the debugging of embedded software like those used in avionics or car industries. Such software is generally written in a language, which mixes calculations, state-transition systems, boolean functions and temporal operators to generate some commands for some actuators. These commands are usually subjected to time constraints, the size of the software can be big (in term of number of software components, or lines of code), and the calculator is, most of the time, interacting with a complex environment.

In such a situation, the debugging can be fastidious and costly. The technique we describe here aims at highlighting the pieces of code by which an error is susceptible of having been propagated. Our approach concerns data flow software specifications like SCADE [Esterel2003] or SIMULINK. In these formalisms, the software is described as a net of operators. The nodes of the net correspond to operators (boolean gates, arithmetical operations, temporal gates, comparison operators), and the arcs represent software variables.

In this context, a piece of code propagating an error is a path from an input to an output of the net, such that: -We observe an error (unexpected value) on the output arc of the path.

-All operators along the path propagate on its output, the error present on its arc input, which belongs to the path. We use so, the concept of path predicate and arc predicate given in [START_REF] Ouabdesselam | Techniques de Test pour les Logiciels Réactifs Synchrones[END_REF], and the Gatel test case generator [START_REF] Marre | Test Sequences Generation from Lustre Descriptions: GATeL[END_REF] to compute the input/output values corresponding to each error propagation paths of the net.

Remark. Our technique does not concern the code verification. The code is supposed to meet its specification because it has been checked by structural tests for instance or, as in our case, because it is automatically generated from the SCADE specification. The problem we are tracking here corresponds to some mistakes in the model of the environment which lead to behaviour cases which are not taken into account by the specification. The computation of the error propagation path allows the identification of the inputs which cause these behaviour cases and gives some information to the software designers so they can choose an appropriate solution to correct the problem.

Data flow specification of real time software

The computation of a SCADE or SIMULINK operator net is performed periodically i.e. the runs of the operators are synchronised on the clock of the net. The arguments of the operators are data flows i.e. infinite sequences of values taken at each clock cycle. For example: -The variable x is the sequence : x(t 0 ), x(t 1 ), ..., x(t i ), ... where x(t i ) denote the value of x at the i-th clock cycle.

-The constant 1 is the sequence: 1, 1, ..., 1, ... -Operators are applied on the flows point to point : x ⊕ y is the sequence : x(t 0 ) ⊕ y(t 0 ), ..., x(t i ) ⊕ y(t i ), ... where ⊕ stand for an operator: ∧ (logic and), ∨ (logic or), ¬ (not), + (addition), ... -Temporal operators are defined as follow :

-Confirmation delay CONF(e, d):

s(t) ↔ ( e(t-d) ∧ e(t-d+1) ∧ ... ∧ e(t))
Where e and s are respectively the input and the output of the operator, and d is the confirmation duration. -Set/reset SRQ(s, r):

q(t) ↔ (set(t) ∨ q(t-1)) ∧ ¬ reset(t)
Where q(t) is the value of the output of the set/reset operator at t The interested reader may find more details in papers related to Lustre, the textual language that underlay the SCADE notation [START_REF] Halbwachs | Lustre: a declarative language for programming synchronous systems[END_REF].

The example given in the figure below is a simplification of a part of Airbus A320 software dedicated to the monitoring of accelerometer sensors. x is an input values provided by a sensor. When the input x is greater than a threshold for more than 8 clock cycles (confirmation delay CONF i ), an error is detected and stored by using the set/reset operators (node SRQ). The output flow z6 represents a 'confirmed error sensor' signal. For safety reason, this computation is duplicated on several lanes. When an error has been confirmed on a lane, the software sends a reset on the corresponding set/reset operator, and then it switches to a backup mode, which computes the acceleration value from a different set of sensors (not represented). Inputs p1, p2, p3 and p4 are used to take into account the current functioning mode of the lane. On this example, the values of the sensors were noisier than expected during particular behaviour cases (take off). This was leading to the detection of non-meaningful errors.

Monitoring of a sensor input

In the following sections, we show how we can find out a finite set of scenarios, which raise an alarm, i.e. put the value z6 to true. In order to get a representative subset of scenario, we propose to cover all computation paths which lead to z6=true. We first introduce the formal definition of such paths, and then we present how to generate scenarios covering the paths with Gatel. Finally, we give the results obtained for our example.

Error propagation path

An error is detected when some output has not the expected value within a given input context. In order to help debug, we want to find out on which inputs depend the faulty outputs and for these inputs of interest, what are the class of values that can cause the error.

In [START_REF] Ouabdesselam | Techniques de Test pour les Logiciels Réactifs Synchrones[END_REF], the authors introduced the concept of "arc predicate" in order to characterise dependency between an input and an output of one operator, whatever is the input value. Let op be an operator, ei one of op input and sj one of op output. Then, an arc predicate AP(ei, sj, op(e1, … en)) is the condition, which ensures that sj value depends on ei value. Let us examine an AND operator and a temporal operator SRQ. AND operator. We note s=AND(e1,e2). The first operand e1 is evaluated in any case. So activation condition is true. We note this as follows:

AP(e1, s,)=true. The second value e2 is propagated to s if e1 is not equal to false (else, s value is false, independently from e2 value). So AP(e2, s)=not(e1). SRQ operator. We note q=SQR(s,r). Reset r has the priority. So AP(r, q)=true. Set condition s will impact q if r is false. So AP(s, q)=not(r). During a computation, a path (e1, e2, … en) is active if all the predicates AP(ei, ei+1) are true. We want to exhibit the paths related to a given test objective by generating inputs that trigger these paths. So, we propose to use the arc predicate definitions as coverage criteria and ask a test case generator to cover a maximum of arc predicates.

In [START_REF] Bousquet | Technical notes for Vepre project[END_REF], the authors propose to extend the arc predicate coverage in order to take into account also the classes of values that go through operators. The new predicates can be illustrated in the following way. AND operator. s=AND(e1,e2). The predicates AP(e1, s,)=true and AP(e2, s)=not(e1) are complemented to identify the classes of propagated values (true or false in this case). We note this "arc-value-predicate" AVP. We got the following new criteria for the AND operator:

1. AVP(e1=true , s)=true and e1 = e1 2. AVP(e1=false, s)=true and not(e1) = not(e1) 3. AVP(e2=true , s)=not(e1) and e2 4. AVP(e2=false, s)=not(e1)and not(e2) The case 2 is covered by cases 3 and 4. So, the retained criteria are: AVP(e1=true , s)= e1 AVP(e2=true , s)=not(e1) and e2 AVP(e2=false, s)=not(e1)and not(e2).

Similarly, we retained the criteria below for the SRQ operator. AVP(r=true , q)=r AVP(s=true , q)=not(r) and s AVP(s=false, q)=not(r)and not(s).

Generation of scenario with Gatel

We need a scenario generator to compute the inputs that allows the coverage of AVP predicates with respect to a given test objective (error observed). We propose to use the Gatel tool [START_REF] Marre | Test Sequences Generation from Lustre Descriptions: GATeL[END_REF]. Gatel generates test sequences by solving a set of constraints derived from a Lustre specification and a test objective. Test objectives describe an execution context we want to reach by tests. These objectives are stated by Lustre boolean expressions. They might be simple expression like "z6=true". Such a formula characterizes memory states. They might also refer any temporal operator or any function written in Lustre in order to specify the partial runs we are interested in.

Gatel has two main functioning modes. In the fully automatic mode, it tries to generate one sequence of input values that leads to the situation described by the test objective. In the interactive mode, users guide the resolution in order to explore several scenarios. Moreover, users can stop the resolution in the interactive mode in order to point out classes of values that should satisfy the constraints. The interactive mode seems appropriated in our case but a difficulty is to avoid too much interactivity.

Lustre specifications are structured into hierarchy of nodes. So, in our example, the whole schema is a node consisting of six instances of more generic nodes. The five generic nodes are AND, OR, <, CONF, SRQ, which encode in Lustre the operators depicted previously. We want to interact at the level of the generic nodes and not go into the details of their Lustre encoding. We use the "split with" directive to work at this level. This directive can be associated to a node output. It imposes sub-cases that shall be considered when the tool searches possible values of the tagged outputs. In our example, we associated to the output of each generic node the AVP conditions presented before.

During the interactive resolution, Gatel proposes to split a selection of outputs (a subset of {z6, z5, z4, z3, z2, z1} in our example) at a clock cycle (the current cycle or older ones). Users choose one output of the selection and trigger a new resolution step by simply clicking on the chosen output. Thus a set of test cases is progressively built. The process is iterated until all test cases are completely built or until the users decide to stop the exploration. We used the following exploration strategies. Firsts, priority is given to the outputs computed at the current clock cycle. Secondly, at a given cycle, priority is given to the most external outputs in order to progressively go back to the inputs. Third, we stop the resolution of a branch when Gatel proposes to solve at an older clock cycle a set of constraints that were already solved at a more recent clock cycle. This means indeed that we privileged the coverage of path by the shortest scenario and do not want enter into useless loops. Finally, we also stop the resolution when Gatel proposes only to go into the detail of a generic node.

By such cuts, we reduce dramatically the number of scenarios. We risk getting partially solved scenarios, which do not lead to the test objective. Gatel offers the possibility to go back to the automatic mode in order to complete each partial scenario.

Example

In our example, we want to understand when an alarm is raised, i.e. we want to identify which paths are taken when the output z6 is true. We got the following scenarios thanks to the strategy described previously. In this case, the values of x and p1 impact z6 because they have particular values during 8 computation cycle. The notation 3..? means that x is an integer greater than 2. We stopped here the resolution before allocating an exact value to x and this allows the identification of a class value of interest. We stopped the resolution of this case because it explores new paths with respect to the time dimension. Indeed, it tries to trigger a set condition (as in the two previous cases) but at the previous clock cycle.

Conclusion

We proposed methods and tools to assist the debugging of dataflow synchronous software. More specifically, our proposal allows the exhibition of scenario classes, which lead to the observation of an erroneous behaviour. The number of such scenarios may be very high. We identified coverage criteria of interest for the debugging in order to reduce the scenario search: we aim at covering all computation paths within the net of dataflow operators and

  This Gatel result states : "p4 is true and z6 is true at the current time cycle 0". This result satisfies all the constraints derived from the specification, whatever are the values of the other input variables. This is a skeleton of admissible runs, which reach the test objective. Such skeletons are also called "models" of the specification and the test objective. Gatel can be seen as a "model" generator. Finally, we notice that the path of interest goes from p4 to z6 directly.In this case, the values of p2 and p3 impact z6 because p4 is false. It is worth noting that all cases are disjoint. The coverage criteria impose indeed this separation.

	%#CYCLE % ? ... ... p2 p3 0 _ _ true true p4 z6 ... ...
	%#CYCLE % ? 0 true false false true p2 p3 p4 z6 ... ... ... ...
	%#CYCLE % ? 9 8 3..? true x p1 ... ... _ _ 7 3..? true 6 3..? true 5 3..? true 4 3..? true 3 3..? true 2 3..? true 1 3..? true 0 3..? true false false false true p2 p3 p4 z6 ... ... ... ... _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

-22 -23 January 2004