Josef Krammer

Cadence, Günter Pascal Bornat

Günter Dengel

Stephan Kuttenkeuler

Rainer Lukas

Klaus Oberhofer

Jens Ruh

Joachim Stroop

Hans Quecke

Stephan Kuttenkeuler

Rainer Lukas

Fibex -An

Berata Dengel

Stephan Gmbh

Sulzer Kuttenkeuler

Rainer Gmbh

Robert Lukas

Klaus Bosch Gmbh

Ixxat Oberhofer

Jens Gmbh

Daimlerchrysler Ag Ruh

FIBEX -An Exchange Format for Networks Based on Field Busses

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

In the last decades an increased number of intelligent devices and electronic control units (ECU) has been used in many applications. In today's high-end cars a few dozens ECUs are used to control the large variety of functions whereby many real time applications are distributed via several ECUs. The need to interconnect these units forming clusters and networks for sharing information has risen dramatically. A single cluster (the term cluster is used as synonym for data bus) can transfer several hundred or even thousands of shared signals. A network can contain several clusters that are interconnected via so called gateways that transfer signals between them. Many protocols used within the different clusters have been developed to support the different needs of a wide range of applications. Among them are CAN, LIN [2], FlexRay [3], and MOST  [5]. Obviously, the importance of communication technologies has been increased dramatically. Databases are necessary to store the information of all signals and their parameters in order to manage efficiently these networks. That data is used for various design and verification steps. Many dedicated tools have shown up on the market to support that. However, their application focus may differ. Some support specific tasks (e.g. bus monitoring), others are more general for design of frames, configuration of software, and rest bus simulation (a commonly used term for hardware in the loop simulation, where the bus behavior if some ECUs are simulated, while others are real). Unfortunately, no common format for the exchange of data between different tools is presently available. This situation is shown in figure 1. The growing number of signals in a reasonable network yields an increasing demand for a straightforward way to exchange data to avoid an error prone manual handling of redundant data. Furthermore, the fast-growing communication requirements of the implemented functions result into an increasing number of new, extended, and more dedicated tools. This increases the need for an exchange format that supports better data handling. As illustrated in Figure 2, FIBEX is an XML data structure that can describe a complete network within one file. This data generally includes definitions of signals, frames, clusters, and ECUs sending and receiving the signals. FIBEX can be used to transfer network information between different tools. It is not intended to replace but to supplement established standards that are often used to store data locally. The coexistence with existing formats is regarded as an advantage since available tools and standards can still be used. FIBEX provides a bridge between them. FIBEX' strength is seen in the field of tool integration, data exchange, and data integrity. It is "more powerful" than most of the more dedicated formats. For example a single instance can contain the description of clusters with different protocols as well as the transfer function of the gateway between them. Note, that the formats of Figure 1 can represent the data of one type of protocol only. In this case the data integrity of the definitions can be checked efficiently. Hence, FIBEX should be used as an extension whenever the specific format is not sufficient. Since many tool vendors have announced to support FIBEX, a conversion between FIBEX and specific formats should be well supported.

FIBEX is also a continuation of preceding activities in MSR (MSRnet.dtd) [START_REF] Www | ASAM.net[END_REF]4]. The pure description of CAN clusters has been extended and experiences have been brought in. The paper is structured as follows: In section 2 the use cases and requirements that guided the definition of FIBEX are explained. Section 3 describes the content and capabilities. A guideline for usage and an example are completing the paper (Section 4).

Use-Cases and Requirements

Many activities are supported by FIBEX. Figure 3 illustrates some of the most important ones. The definition of a bus system is a classic task. Generally, a bus with the connected ECUs, the signals, and frames is defined by using an appropriate design tool. The result should be written to a FIBEX XML file. 2. Import/Export to/from a database. This use case has to support the merging of typical network data with other data that may be stored in a more general database. 3. A flexible data management supports the distribution and gathering of data and portions of it between different companies (OEM and sub suppliers). 4. FIBEX may be used for offline simulation of the distributed application's behavior (down to the time domain, by taking into account the frame timing information) 5. Within the Communication scheduling the timing of the transmitted signals and frames is defined. In synchronous systems such as FlexRay, this is an essential design step that may be performed by specialized tools. 6. With a driver code for software interfaces can be generated that allow the application to access the signals via an abstract API. 7. FIBEX information can be completed with task information and HW information, and can be used to describe ECU configuration (e.g. in OIL -OSEK Implementation Language) for code generation tools 8. Since gateways can be described in FIBEX, their configuration and mapping functions can be derived from FIBEX. 9. The network-and symbolic information of the frame contents can be passed to bus analyzing (bus monitoring) tools via FIBEX. 10. FIBEX can provide statistical information, e.g. for bus load and other analyses.

Signal

The signal entity serves two purposes: From the "functional" perspective, it is an input or output parameter of a function representing a physical or logical value of a specific data type. From the "communication" point of view it is a stream of bits of a defined length. Cluster A cluster describes the ensemble of ECUs, which are linked by a communication medium of arbitrary topology (bus, star, ring, ...). The nodes within the cluster share the same communication protocol, which may be event-triggered, time-triggered or a combination of both.

Channel

The communication medium of a cluster consists of one or more (redundant) communication channels. The channel entity interlinks the ECUs of a cluster physically: An ECU is part of a cluster if it contains at least one controller that is connected to at least one channel of the cluster.

In single-channel systems, this entity is known as "bus"; to avoid confusion we recommend not using this term any more. Frame A frame is the smallest piece of information that is exchanged over the communication system. A frame is a datagram with a header section and a payload section of a certain length in bytes, which contains an arbitrary number of non-overlapping signals and/or multiplexers/sub frames. The sendstimuli of a frame are described in the "frame triggering" elements of a frame.

Gateway

A gateway is an ECU that is connected to two or more clusters (channels, but not redundant), and performs a frame or signal mapping function between them.

The structure of FIBEX can represent a nearly arbitrary subsets of systems. Hence it can support any stage of the design process, independent from the succession of the definition steps for the various entities.

There are also some restrictions. FIBEX is restricted to represent one system at one time only. This means that there is no multi-vehicle or multi-version handling.

* not yet covered in FIBEX version 1.0, but planned for a future release Figure 4 shows the relationship between some entities. For a better understanding, some features such as requirements, gateway, multiplexing within frames, and project information are not shown. The numbers at the relation between the entities characterize their cardinality. For example, the 1 to n relation between the Cluster and Channel expresses that a cluster can contain an arbitrary number of channels. But a Channel can be member of one Cluster only. A typical situation would be a FlexRay Cluster with two redundant Cannels. Note, a CAN Cluster is described by a cluster with one channel connected by a one to one relation. The entities are specified in more details by appropriate attributes. These attributes consist of some general ones like name, short name, and description. Others are specific to the corresponding entity. To give an example, the Cluster would have the speed attribute since this is the same for all related Channels, whereas the Channel would have attributes defining the network management, as it might be Channel specific. But both of them might have a name and a description. FIBEX consists of a basic definition (fibex.xsd) that is used for any protocol. Protocol specific extensions are described by additional definitions (fibex4can.xsd, fibex4lin.xsd, fibex4flexray.xsd, …), see Fig. 5. Manufacturer specific extensions Almost any mid-and top-level element contains an optional <MANUFACTURER-EXTENSION> element. This acts as a container for an arbitrary sequence of elements that are not part of the FIBEX specification. Within these containers manufacturer specific extensions are possible for data that is not represented by standard FIBEX. The user should be aware that tools on the market would not support those extensions. Nevertheless, the structure of FIBEX together with the capabilities of the xml schema allows validation of FIBEX instances with or without protocol and/or manufacturer specific extensions.

The Release package contains several basic essentials.

1. The specification points out the goals, requirements, and use cases. It introduces the entities with the underlying model, and describes the relations between them. 2. The attributes are fully documented. In order to guaranty consistency between delivered essentials, the documentation is generated from the XML-Schema. 3. The XML-Schema contains the declaration of the expected XML-structure of FIBEX documents. There are several files. One for the main scheme (fibex.xsd) and one for each protocol (fibex4can.xsd, fibex4lin.xsd, ..). 4. The HTML documentation is a navigable visualization of the XML-Schema. These HTML pages are also generated from the schema. 5. The examples show how FIBEX is used for various communication technologies. The delivered XML files are described in the specification and can be used for first evaluations.

Usage and Examples

In general the user will not be confronted with the details of FIBEX. He just will export and import data represented in FIBEX. The benefit for him will be an easy exchange of data between tools. However, we will give a short tutorial for those people who have a deeper interest in FIBEX, e.g. for anybody who writes software for FIBEX. For that we use a very little example. We show how to find out what an entity (a frame) is and how it is represented in one of the examples.

1. At first we look at the FIBEX specification. The Document gives a specification as follows: A frame is the smallest piece of information that is exchanged over the communication system. A frame is a datagram with a payload section of a certain length in bytes, which contains an arbitrary number of non-overlapping signals and/or multiplexers/sub frames. The send-stimuli of a frame are described in the "frame triggering" elements of a frame. 3. We check the attributes in the attribute table for the frame. That table shows all attributes and the detailed specification of the data type together with a textual description, see table below. The appearance specifies whether the attribute is mandatory or optional. We see that the frame has three mandatory attributes, SHORT-NAME, BYTE-LENGTH, and FRAME-TYPE. The frame description has references to contained signals as <SIGNAL-INSTANCE> tags. The frame "frmSetSpeed" contains only one signal. It is necessary to separate the position of a signal within a frame from its description to be able to map one signal to several frames. Hence, the start of the signal (<START> tag) is specified within <SIGNAL-INSTANCE> and not directly at the signal. The "frmSetSpeed" frame also shows the usage of bus specific tags which are namespace prefixed, e.g. <can:RTR-FLAG>. Here, the boolean value "false" specifies that the "remote transmission request" bit is not set for this frame. The prefix "can:" shows that this element is from the subschema fibex4can.xsd the others are from the main schema fibex.xsd. 6. In the last step we validate the example. Using freely available xml tools as described in Appendix of the FIBEX specification does this. Here, the strength of the schema is used for a thorough check of the instances including the values of attributes.

Current Projects A variety of projects are under way within the companies that are members in the FIBEX working group. Among them are:

• BMW AG: Integration of dedicated communication tools (comprising both development and configuration) for FlexRay and LIN into a tool chain that is connected to a database that comprises general data for networking.

The FIBEX support for the configuration of gateways is considered as one of the next steps. • DC will use FIBEX as an internal exchange format to exchange harmonized Signal descriptions between the different communication systems. • Robert Bosch GmbH: Usage of FIBEX as a means of modelling and parameterization for simulations yielding performance benchmarks of automotive-networked systems and topologies. • Cadence: "Based on the information provided by FIBEX, our SysDesign simulation tool configures the virtual components of the vehicle network and provides after simulation, the metrics about the performances of the system." • DECOMSYS GmbH is currently developing a FIBEX Import Module, which is translating FIBEX contents into the DECOMSYS tool chain internal representation. A prototype of this module has already been implemented for a previous version of FIBEX (0.9.3) in Q03/2003. DECOMSYS expects that the Import module will be available as a product in 2004. • dSPACE GmbH: The development of FIBEX is supported by dSPACE because of its potential as a common exchange format for communication data. A first use of FIBEX is considered in the scope of a tool integration dedicated for the design and test of applications using the FlexRay protocol. • Sulzer GmbH: XSLT converter from a company specific format into FIBEX • Vector Informatik GmbH: Import of communication data into CANdb++ for usage in the development workflow (system simulation, generation of embedded code, system test, …). The source of the data may be an arbitrary design and/or data management system that can export the data in FIBEX format. CANdb++ can create DBC files that are widely used in the CAN area. At the moment the import is focused on CAN data but will be provided for other bus systems in the future.

Because the FIBEX elements are assigned to several, largely independent parts (topology, communication, function, …), it is possible to describe and/or process only those aspect of the data needed to perform the different development tasks. In the case of the CANdb++ import only data describing the communication and topology of a system is used. The other parts (e.g. functions) may or may not be available in the FIBEX file. The independence of the different parts allows editing of the topology and the communication aspects of a system without influencing elements not covered by CANdb++.

Manufacturer extensions described in an additional XML schema allow the exchange of data not covered in the basic FIBEX definition. In addition there is a development project ongoing where a FIBEX file (export/import) will be used between the VNA and a FlexRay Schedule Builder.

Furthermore, other tool suppliers have expressed ambitions and plans to support FIBEX as well.

Figure 1 :

 1 Figure 1: Managing distributed real time systems by conventional tools and data bases.

Figure 2 :

 2 Figure 2: Describing a complete network with FIBEX

Figure 3 :

 3 Figure 3: Use Cases for FIBEX 1.The definition of a bus system is a classic task. Generally, a bus with the connected ECUs, the signals, and frames is defined by using an appropriate design tool. The result should be written to a FIBEX XML file. 2. Import/Export to/from a database. This use case has to support the merging of typical network data with other data that may be stored in a more general database. 3. A flexible data management supports the distribution and gathering of data and portions of it between different companies (OEM and sub suppliers). 4. FIBEX may be used for offline simulation of the distributed application's behavior (down to the time domain, by taking into account the frame timing information) 5. Within the Communication scheduling the timing of the transmitted signals and frames is defined. In synchronous systems such as FlexRay, this is an essential design step that may be performed by specialized tools. 6. With a driver code for software interfaces can be generated that allow the application to access the signals via an abstract API. 7. FIBEX information can be completed with task information and HW information, and can be used to describe ECU configuration (e.g. in OIL -OSEK Implementation Language) for code generation tools 8. Since gateways can be described in FIBEX, their configuration and mapping functions can be derived from FIBEX. 9. The network-and symbolic information of the frame contents can be passed to bus analyzing (bus monitoring) tools via FIBEX. 10. FIBEX can provide statistical information, e.g. for bus load and other analyses.

  Derived from the use cases and experiences made with existing formats several essential requirements have been set as prerequisites for the development of FIBEX. o The exchange format has to support (nearly) all communication systems in the car (CAN, LIN, FlexRay, byteflight, TTCAN, MOST * …) o It has to be standardized, free, and open for all development partners without any charge (OEM -Tier1-Tool Supplier -...) o It must be capable to specify the complete network (including gateways) in one file o The (logical) HW-topology (communication systems, ECUs, channels, gateways, …) must be included (no information about the physical topology included in FIBEX 1.0) o The data must contain information about signals, frames, routing, …, and o project information (version, vehicle type, ...).o Capabilities to exchange (import -export) specific subsets of networks (e.g. configuration for one ECU) to support OEM-supplier relationship must be possible. o Exchange format has to be user extendable o Exchange format has to be user friendly (e.g. readable, documented, ...) o Format has to be defined using commonly used, well tested and well supported technologies3. Content and capabilities of FIBEXFIBEX can be understood as an object oriented decomposition of communication systems into the following major elements: ECU Electronic Control Units contain the functions that communicate via the clusters. Generally an ECU contains one or more functions. Function A function is a part of the distributed application running in an ECU. It is assigned to an arbitrary number of input ports (input signals) and output ports (output signals).

Figure 4 :

 4 Figure 4: Reduced ER diagram that can describe already many systems

Figure 5 :

 5 Figure 5: Protocol specific extensions in FIBEX

2.

  We analyze the location and relations in the ER diagram; see Figure4in the previous section. The ER diagram shows how the frame is embedded into the FIBEX structure. We see that the Frame has a relation to FrameTriggering (1 to n relation) and to Signal instance (1 to n relation) and which refers to the signal (n to 1 relation). The frame is refered to one or more FrameTriggerings. Each of them is referred to one channel. With this structure it is possible to express that one frame is transferred via several channels with different timings. With the analog reference to signal instance and signal we can express a frame that contains an arbitrary number of signals.

  Figure 6: A simple CAN example

•

  The Volcano Communications Technologies (VCT) produced Network Design Tool (VNA) and its LIN only version (LNA) is now equipped with a FIBEX based interface. The FIBEX is used: -To import signals and their attributes where OEMs use a corporate signal database, and -to export complete vehicle network configurations from VNA including OEM specific attributes.

-22 -23 January 2004

-22 -23 January 2004Figure 7: Section of the FIBEX structure that describes a frame.


Xavier Cornu
email: xavier.cornu@trialog.com

Dominique Charny
email: dominique.charny@mpsa.com

Eric Charton
email: eric.charton@mpsa.com

Ajacs

AJACS : APPLYING JAVA TO AUTOMOTIVE CONTROL SYSTEMS

niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Context

Embedded and real-time systems are getting more and more complex. For long, embedded software programming was more a concern of reaching the highest performance with the cheapest hardware. Now software architectures are redesigned to manage this complexity and produce upgradable, maintainable and reusable software, mainly through component-based paradigms.

Still the question of the actual implementation of these components is open: the use of hand-written C code everywhere is now in the balance in most application domains, when not already replaced. Other implementation techniques such as code generation or object programming (ex: Java) are challenging, as they can more easily be integrated in these component-based paradigms.

The AJACS project

The success of Java as a mainstream language for Information Technology, and the increasing interest of the realtime community to use it, led the AJACS consortium to consider an investigation on the use of Java technology in automotive control applications :

• Through its object-orientation, Java makes it easy to design software component with strictly defined interfaces, even at the source code level. • The Java language is designed to be platform independent. Thus hardware independence and portability requirements are largely fulfilled. • Learning easiness -a lot of skilled programmers are already available -and robustness contribute to high programmer productivity and low defect rates. This will help the development team focus on high-level activities like component-based design.

To this end, the AJACS European initiative completed in early 2003 had the following objectives:

• Define an open technology which relies on existing standards of the automotive industry, such as OSEK/VDX. • Retain the benefits expected from object-oriented language programming in terms of software structuring, reusability, dependability in particular retain the portability, and robustness attributes associated with Java. • Address technical issues created by drawbacks of the Java language in terms of real-time and determinism support for embedded systems with high integrity constraints. In the case of automotive control, this means supporting the same kind of real-time constraints which non-Java based ECUs currently handle and targeting the type of memory footprints that are acceptable in the automotive industry (e.g. 256 Kbytes ROM, 16 Kbytes RAM).

• In one sentence, assess whether Java could become a suitable solution for the implementation phase of future component-based developments in embedded and real-time systems.

Technical issues

The objective of this paper is to present technical issues such as development environment, system programming, multithreading and synchronization, exceptions, initialization, memory management and native interface that were addressed pragmatically in order to achieve two automotive demonstrators. These technical issues are not only related to automotive control systems but also to various domains such as vehicle telematics, avionics and industrial control, etc., currently interested in using Java for their embedded and/or real-time systems.

Technical issues

This part lists the main technical features for which the Java language shows particular drawbacks or need for further specification in order to be used in embedded and/or real-time systems. It won't detail these technical aspects, so the reader is prompted to consult articles listed in bibliography in order to find further explanations.

Development environment

Root classes and Standard libraries

The execution environment of Java applications does not only rely on the Java Virtual Machine, but also on the basic classes delivered with it, which are required to construct application classes. In a well-defined real-time, embedded development environment, these classes should be re-written by the technology provider to both enable the change of thread model and decrease the amount of mutual dependencies between these classes, to avoid unnecessary memory use on class loading.

Debugging

To enable Java programming on deeply embedded systems, the JVM should be well integrated with current debugging solutions for these systems. For example, interfacing the JVM with emulator solutions is necessary to debug real-time Java applications. This is currently lacking in most solutions : by default, an emulator will present the code of the JVM, not the Java source code of the application.

System programming

Missing features

Some useful features used everyday by embedded software programmers (in C) are not available in Java environments. For example standardised pre-processor directives that enable easy constant definitions, conditional compilation or explicit macro definitions (not relying on uncontrolled compiler optimisations). Moreover basic data types in Java are all defined as signed. The problem is that unsigned integer types are very often used in embedded systems, for example to manage classical communication protocols, and converting these data for any treatment can quickly become very inefficient. So the development environment should provide a mechanism for defining unsigned integers. The same remark is true for bit access to processor registers, which cannot be efficiently implemented without a dedicated mechanism.

Input / Output management

In embedded systems, I/O management often imply having access to micro-controller registers, which is usually the only means to use peripherals. As classical Java environments don't provide access to physical memory (e.g. registers), one would use native access functions through the Java/Native Interface to manage I/O. In case of sustained use of I/O accesses, such as with the PSA demonstrator in AJACS, the JNI overhead may lead to inefficiency, so a dedicated Java mechanism is preferable.

Multithreading and synchronisation

Real-Time systems predictability

The thread model defined in the classical JVM specification is not compatible with hard real-time programming, as clearly stated in the Java tutorial: "Do not rely on thread priority for algorithm correctness". The consequence is that a real-time Java environment shall either define its own real-time thread definition or rely on an underlying Real-Time Operating System (RTOS) like OSEK/VDX, in order to warranty the predictability of system dynamic behaviour. The AJACS project uncovered the difficulty of interfacing a Java Virtual Machine with existing RTOS, especially a very static one such as like OSEK/VDX. One reason is that Java language allows a big amount of implicit or dynamic definition where OSEK/VDX prompts the programmer to declare explicitly and statically all the entities to be used. From the developer point of view, it is noticeable that most of the problems encountered by the classical Java programmer to write real-time application are indeed comparable to those of a mainstream C programmer that begins writing real-time C applications.

Real-Time Garbage Collecting

For long the garbage collection (GC) algorithm has been a strong handicap for designing a real-time Java environment. Now real-time GC algorithms have appeared on the market but still need serious assessment before usage in real products, especially for targets with very short latency constraints: before using this kind of environment, one shall verify if the worst case latency when the GC is collecting is affordable in his system. In very constrained applications, it may be preferable not to use a Garbage Collector and pre-allocate all the objects at start-up.

Synchronisation

Synchronisation of real-time threads are performed in several manners by embedded software programmers, from explicit and time-consuming synchronisation (such as with "synchronized" keyword in Java) to implicit and very light synchronisation (ex: read/write atomic data). The problem is that the classical Java Memory Model (JMM) is so permissive for compiler optimisations that any implicit synchronisation may not work on some Java platforms. The JMM should be made less permissive to allow portable light synchronisation.

Exceptions

Software engineering

Generally speaking, exceptions mechanism is good to avoid "spaghetti-like" code structure when error management is added. But as regards embedded systems, usage of exception has also been controversial, due to the difficulty to prove the correctness of the execution path: some even argue that exceptions are worse than "goto" statements, as they imply an abrupt branching to a dynamically defined place in the code. Furthermore, programmers using exceptions have to be very careful that no exception may branch to an unwanted "default" handler that could lead to system termination, undesirable in mission-critical applications.

Real-Time behaviour and memory usage

Exceptions in Java is a fully dynamic feature so the real-time behaviour of the exception management has to be well assessed and understood by the programmer before its usage. Furthermore, usual Java habits to create an exception object each time an exception is thrown consumes too much RAM memory, and thus shall be replaced by a more static technique using predefined exception objects.

Initialisation

Java model vs embedded C

In classical embedded application, written in C, programmers usually bring the system to a well-defined "initial" state before the application is actually "started". Initialisation of Java components follow an non-classic sequence, as some classes can be already executing whereas some are not even loaded in memory. As a consequence, in order to characterise the "initial" state of an application, and thus to warranty the reproducibility of the system behaviour, the programmer will have to set up specific programming techniques that will force a predictable execution ordering.

Memory management

Memory usage in Java

Current mainstream Java programmers are used to relying mostly on the Garbage Collector to manage the usage of RAM memory by their application. Indeed, most JVMs don't provide a clear view of the usage of RAM memory. In order to apply Java to constrained embedded systems, the programmer has to both use appropriate programming techniques (such as: usage of optimized basic libraries, object reuse…) and have some tools associated with the JVM to control the RAM usage by his application, in order to minimise the cost of the execution platform.

Dynamic downloading and low-cost systems

Classical Java systems need to execute Java programs from the RAM memory, as every class of the application is loaded dynamically. In low-cost embedded systems, this approach may be unacceptable, as RAM memory is far more expensive than Flash memory for instance. The consequence is that JVMs targeting low-cost applications have to be able to execute Java code from read-only memory, which implies to change the file format for class description, and use either a more optimised one such as JEFF (ISO/IEC 20970) or compiled native code. Then programmers will limit dynamic loading only to parts of the applications that can actually change during application execution.

Native interface

Java Native Interface

Since the first versions of classic Java, the need for interaction of Java components with components written in other languages (e.g. the C language) has been identified and addressed in the JNI (Java Native Interface). But this interface is sometimes too complex as regards the needs of low-cost embedded systems. The possibility to perform any kind of action on objects from the native world ended up in a so highly dynamic interface that its performance for constrained systems is not acceptable. As a consequence, nearly every embedded Java environment provider comes up with a (proprietary) dedicated interface. Standardisation of a light Java Native Interface is suitable.

Embedded systems requirements

In embedded systems, where reusability of components is a key factor for mature development process, the possibility to reuse efficiently existing components (ex: device drivers written in C), or to optimise some critical parts of the code by writing them in C or assembly language (ex: encryption algorithm) is mandatory to accept the usage of Java. Thus an embedded system programmer should be careful on the native interface provided by its environment, so that it fulfils his needs. This figure presents the flow of application data in the programming environment, green boxes are the part provided by the AJACS environment prototype. It isn't an industry-qualified environment, as these parts should be re-written by a compiler provider, instead of an university.

AJACS car body demonstrator

Together with PSA Peugeot-Citroën, Trialog developed a car body demonstrator, see picture below: This prototype gathers several off-the-shelf body components such as Citroën XM levers, Citroën C5 lights, Peugeot 307 dashboard around a prototype ISU, Intelligent Service Unit (or BSI, "Boîtier de Servitude Intelligent" in French). This prototype allowed us to validate our design by developing true car body applications in Java and run them successfully in a representative environment of automotive systems. Lessons learned during this development were our main input for uncovering and tackling the technical issues cited in the preceding part. Typically the importance of dedicated I/O management and efficient native interface.

Further steps for Embedded and Real-Time Java

International initiatives

Since the early beginnings of the Java language, its adaptation to develop real-time and embedded systems has been discussed in the developers community. Till the end of the work performed in AJACS, two major international initiatives led the discussion concurrently: the Real-Time Java Expert Group and the J Consortium, supporting respectively the Real-Time Specification for Java (RTSJ) and the Real-Time Core specifications. Besides those attempts, main Java development environments dedicated to embedded applications are based on proprietary extensions or dedicated profiles such as MIDP (Mobile Information Device Profile) in mobile phones, which don't follow any of these real-time specifications. This division prevented the usage of Java in real-time systems from reaching its maturity, as no serious development could be made on a potential stillborn standard. Now a true effort is being made to reach an agreement on a basic standard (likely to be a RTSJ evolution) associated to well-adapted profiles for each intended applications. Current work include for example a Java Specification Request (JSR) on "Mission and Safety Critical applications" under the Open Group aegis.

Conclusion

Implementation of embedded applications evolve. For a long time focused on satisfying timing and performance constraints on homogeneous problems, the development process could keep with writing a whole piece of code, written with the ADA language for critical applications or proprietary solutions based on the C/C++ languages. Now the complexity of embedded and/or real-time systems has tremendously increased and this classical approach cannot deal with their complex, heterogeneous requirements. So the embedded world needs a way to master this complexity, and this will have a huge impact on the development process:

• First, the main goal of the development process shall be to obtain a well-organised software, of course still fulfilling the adequate time and performance constraints, but also having the capacity to evolve.

Component-based approach can be the key to reach this new goal. • Second, sometimes classical implementation languages are not suited to handle this new approach, developers may need a new reference environment, preferably common with information systems: this could be Java.

The Java language, boosted by its assets such as robustness, portability and ability to cooperate with existing components written in the C language, is leading smoothly its revolution. The work performed in AJACS was basically oriented on automotive applications which, apart from telematic applications, are still too constrained to accept Java. But already other application domains such as mobile phone, payment terminals or safety systems for buildings adopted Java for its numerous advantages. That is the reason why we can expect a breakthrough of this language in a wider range of real-time systems. As soon as its real-time management capability has reached a good level of maturity… Anyway, the current trend in complex software development shows that the implementation phase, thus the language used, is not the most crucial aspect, the key for success. One shall not forget that a component-based approach, a good mastering of complexity, is more an architecture problem: a good implementation language is the one that better serves this architecture. In some cases it will be Java.

Bibliography

(1) Java dans les systèmes embarqués et temps-réel. Xavier Cornu. Techniques de l'ingénieur, recueil "Informatique Industrielle" Ref. S8068. To be published early 2004.

(2) The Java Tutorial. Third Edition. Mary Campione, Kathy Walrath, Alison Huml. Addison-Wesley. April 2001. (3) Concurrent Programming in Java : Design principles and Patterns. Doug Lea. Addison-Wesley. 1996-99. (4) The Java Language Specification. Second Edition. James Gosling, Bill Joy, Guy Steele, Gilad Bracha. Addison-Wesley. 2000. (5) The Emperor's Old Cloths. The 1980Turing Award Lecture. C.A.R Hoare. CACM. February 1981. (6) Essential JNI : Java Native Interface. Rob Gordon. Prentice Hall. 1998. (7) The Java Virtual Machine Specification. Tim Lindholm, Frank Yellin. Addison-Wesley. 1997. (8) Rajesh Gupta. UC Irvine. Winter 2002. Internet: www1.ics.uci.edu/~rgupta/ics212/w2002/intro.pdf (9) OSEK / VDX Specifications. Internet: www.osek-vdx.org (10) JSR-000001 The Real-Time Specification for Java. The Real-Time for Java Expert Group. Addison Wesley. 2001. Available on Internet: www.rtj.org (11) Real Time Core Extensions for the Java Platform -Draft 1.0.14. J Consortium. May 30 th 2000. Internet: www.j-consortium.org (12) Fixing the Java Memory Model. Bill Pugh. 1999. Internet: www.cs.umd.edu/~pugh/jmm.pdf (13) JEFF File Format Specification v1.0. J Consortium. ISO / IEC 20970. March 2002.

S

  Se es ss si io on n 5 5B B: : O Ob bj je ec ct ts s--O Or ri ie en nt te ed d L La an ng gu ua ag ge es s a an nd d M Mo od de el ls s TO AUTOMOTIVE CONTROL SYSTEMSSession 5B: Object-Oriented Languages and Models Executive summary: This paper presents the conclusions of AJACS (Applying Java to Automotive Control Systems, http://www.ajacs.org), a 2.5 years European initiative 1 including Trialog and PSA Peugeot-Citroën, aiming to specify, develop and demonstrate an open technology allowing the use of Java in deeply embedded automotive control systems running on top of OSEK / OS.

Figure 2 :

 2 Figure 2: PSA car body demonstrator for AJACS

-22 -23 January 2004

Participants to AJACS were Trialog (leader), PSA, CRF (Fiat), University of Karlsruhe and Mecel.

DPTA

AJACS achievements

High Integrity Profile for Automotive (HIPA) Specification

Within the J Consortium, AJACS chaired the HIPA group which defined a High Integrity Profile Specification adapted to highly constrained automotive systems: both hard real-time and small footprint were addressed. The result is a specification based on a subset of the Real-Time Core Specification from the J Consortium, with the following main adaptations:

• the embedded world does not coexist with a classical Java world,

• the thread model is replaced by OSEK/VDX-compliant task management,

• applications are basically static: most entities are known at design time.

This specification cannot be considered as directly applicable to an industrial project, due to the particular context of the Real-Time Core specification which still lacks standardisation, but the work done is a good starting point for a specification that would address highly constrained embedded systems.

AJACS development environment

The


Francois Bossard
email: francois.bossard@cnes.fr

Event driven architecture for hard real-time embedded systems

This paper presents a computing model and a related modeling process dedicated to hard realtime embedded systems. This model meets the understandability for the architecture, adaptability to various application contexts and compliance to stringent time constraints. The implementation relies on an open framework made of real-time tailored and generic services The overall approach aims at robustness thanks to fast iterative prototyping. The model and its framework have been validated and patent application is ongoing.

INTRODUCTION

The new modeling technologies for embedded systems aim at controlling software development costs by outstanding the re-usability. In fact, varied technologies are proposed but the challenge is to cover the overall lifecycle from high abstractions to low level implementations while solutions should be opened to new research results. Furthermore as systems are more and more complex, many risks come if you do not rely the design process on stepping it with proofs and real simulations. This paper proposes both an event driven design pattern and a re-usable middleware for monoprocessor implementation. This original solution is fully object oriented and suits to most modeling methods. Moreover, it fits in with an overall approach which highlights real-time constraints and behavior.

RATIONALE FOR NEW SOLUTION

We consider a new real-time model for three major reasons. At first, an embedded system controls external processes by means of periodic activities and it is assumed to be reactive to environment and internal events too. In any cases response times should be achieved. Off line and on line checks are recommended while system is not absolutely deterministic. Then, re-using is relevant if architecture is flexible to several kinds and fields of applications. Different quality criteria are primarily expected and constraints are moving which makes harder to find the optimized solution. For instance it could be useful to allow time segregation for reliability . In the other hand, increasing processor workload saves computing resources. In addition, requirements changes or unexpected facts during development do not comply with current design. A sure and fast method to modify the software is fully convenient. At last, as far as state of the art in research and technology is evolving , a solution is lead to upgrade sooner or later. Obsolescence is somewhere anti-economic by loss of efficiency and attraction.

SYSTEM BEHAVIOR MODELING

REQUIREMENTS CAPTURE

In a practical point of view, system is assumed to aggregate several subsystems with different requirements. So we need to pick up all the user functions and all the behaviors in response to external system events and inter-subsystems events. Better understanding is reached by synthesizing general functions then parameterizing with modes. Again problem simplification is provided by break down the overall behavior according to mission phases. Furthermore non functional properties are assigned to user functions and subsystems. At least time properties like maximal response time and periods are given. At this stage, it is relevant to add safety requirements provided by fault and criticality analysis.

Requirements are usually captured in an informal way such as to define a complete problem to solve.

ANALYSIS STAGE

The goal of this stage is to unambiguously take over the problem in order to specify a solution.

As problems are often complex and call upon varied engineering domains, description models are frequently chosen in relation to each sub-system. Another difficulty lies in the fact that sub-systems are not independent because environment is common, resources are shared and same events could concern many of them. So it is convenient to adopt some common approach and to formalize the whole system representation.

A modern response consists in using abstractions and related models as a high level design solution. Object oriented approach is largely adopted even in the embedded systems area with new standards such UML, ADL… The proposed modeling principle is to represent the internal behavior of the system by limiting action to the effect of events on sub-systems. Thus at sub-system level, the designer is free to apply the design technology he prefers. Moreover the goal targeted is the fast prototyping of the system design model regardless of how is implemented each sub-system. In addition the system is assumed to simultaneously control continuous physical processes with own time constraints. A subsequent issue is to build consistent models dealing with events and continuous processes without taking into account any implementation feature.

MODELING TECHNIQUES • FEATURES

The selected basic technique is the state and transition diagram by which the behavior of the system is entirely defined. "Entirely defined" means that at any moment the current state of the system is known and the effect from any system event is defined (see figure 1).

A system event is an internal sub-system event or an event from another system with effects on several sub-systems.

2 nd European Congress ERTS -3 -21 -22 -23 January 2004

The system event is the major item of the implementation and design models described later on. Notice that the system event notion could apply recursively to sub-systems and lower components.

Another concept suitable to model real-time system operating is the cooperative activity.

Actually the system counts on related parallel activities to formalize continuous physical processes. Of course the operating modes can evolve depending on specific conditions.

The modeling language selection is out of concern in this paper.

• STATES

The states are mainly characterized by the activities taking place inside and the values of physical parameters they outcome.

The main difficulty in this type of modeling is due to the fact that both continuous and momentary activities are mixed. Furthermore all sub-systems are not concerned by a status change and an activity may be carried out continuously on several states independently from other activities.

The system state diagram gives a macroscopic view of sub-system activities coordination and expected time properties.

• EVENTS

A system event is a logic expression combining signals generated by the sub-systems without any hypothesis at this level on their format or the mechanisms generating them. The declared events cause transitions with or without a state change. The transition without a state change makes it possible to limit the number of system states represented, but indicates an activity change in one or more sub-systems. Notice events also cover any detection of abnormal behavior.

• ACTIONS A transition entails one or more actions to be carried out in parallel or serially. Furthermore, it is possible to phase shift actions by indicating a delay. An action is connected to the sub-system which is in charge of it. Otherwise an action could be sent to another system. An action transiently exists and its duration is as short as an event is.

• ACTIVITIES An activity is either continuous with periodic recurrence or aperiodic. In any case, an activity is long relating to action and needs a transition to be started , stopped or modified. A state diagram action defines what and how to control. Maximum response time is assigned to all activity occurrences as deadline.

Notice action is reserved to control activity so that event is used to refer to a signal generated by an activity. At this abstraction level, no assumption is made whether an activity consists of several operations or an operation exchanges data with environment or another sub-system. System behavior modeling provides a solution specification for the whole system to build.

Then the process consists in iteratively and confidently implementing the right solution (see figure 2).

On purpose the approach relies on both analytic proof and fast prototyping. The former entrusts the design and the latter enhances the confidence in an physical implementation. Process starts with a rough architectural design and goes on with refining sub-systems in a consistent manner so that rolling back is easy.

Hardware architecture could concurrently be defined in a similar way but should influence process as late as possible. For instance first prototypes run on some simulator or evaluation board. It is enough to start in sizing computing resources even if later a single processor is replaced by a distributed architecture.

The inherent flexibility is achieved with a three layered architecture (see figure 3) where middleware isolates application software from real-time kernel and hardware drivers.

GENERAL APPLICATION DIAGRAM

A high level object breakdown model constitutes the logical architecture of the system. The key element of the structure is the Supervisor as it alone must guarantee compliance of the behavior modeled in the System state diagram in chapter 3. Sub-systems include active objects of which the activities are entirely controlled by the Supervisor . The generic diagram of the application consists in defining the interfaces between the Supervisor and the sub-system activities.

The exchanges between the Supervisor and the sub-systems are of three types:

actions which are asynchronous signals sent by the Supervisor events which are asynchronous signals sent by the sub-systems to the Supervisor functions which are sub-system methods statically invoked by the Supervisor. They are useful to acquire internal status of sub-systems. Updating of the system architecture model primarily consists in an adaptation of the object breakdown model. However analysis changes could require an intervention in System state diagram and therefore in Supervisor.

SUPERVISOR

The Supervisor manages and co-ordinates all on board system activities. To this end a generic engine executes a provided automaton compliant to the System state diagram. The automaton logic is described by a data structure encapsulating the behavioral attributes proper to the application.

EVENT PROTOCOL

Most events are specific to application contexts and only sub-systems are aware of how their occurrence conditions are practically detected. So each activity is asked to use middleware facility when conditions are met to generate an event. Some pre-defined events concern deadlines misses and are automatically generated by the middleware. Another event class is called generic and designates events where actions are dynamically fixed at transition time. These events are useful for embedded systems which face to nonpredetermined situations.

The events are queued in the Supervisor immediately or at a specified date according to their order of arrival. The events indicate their original activity but are not dated because they are expected to quickly operate. Only one event is delivered at a time so that it belongs to Supervisor to detect a complete events combination.

ACTION PROTOCOL

Supervisor deals with actions generation according to its given automaton. As actions effects are immediate or delayed, simple triggering sequence allows to schedule parallel sub-system activities. Supervisor uses middleware facility to dynamically order any kind of control with time parameters. Thus action is capable of starting, interrupting a periodic activity . Again it is possible to synchronize or definitively stop executions.

The action is queued in the proper receiver file at the required moment with its execution mode as its sole attribute. Each activity is in charge of collecting its related actions by invoking middleware as soon as possible.

Notice dynamic change to the execution mode is secured because it only operates at the only synchronization point, even though the action has been sent asynchronously.

SUB-SYSTEMS ACTIVITIES

Subsystems are designed with any method provided final items are threads, tasks or processes.

Normally each above activity is mapped to a main task but more complicated structures are possible for it. For instance an activity may consist in several children tasks running in parallel under the main task control. Again an activity may sequence several operations which server tasks deal with. Server tasks work on behalf of the client task and nothing is initially assumed about their local or remote placement. The only design constraint is any main task is organized according to a loop flow starting from the unique synchronization point reserved for activation and deactivation. When an action is received, its attribute must be recognized to eventually change functional mode or leave the loop to terminate. A typical activity for continuous control consists in programming, in the loop, a sensor acquisition followed by computation on these inputs, then delivery of the result in the form of a command sent to the actuator. The periodic occurrences of this processing operation start and finish as Supervisor decides . At this stage a key point is that a final or intermediate application is above all a set of tasks. At present it should be relevant to select both an hardware architecture model and a suitable set of real-time middleware algorithms. Then it becomes valuable to check the solution correctness according to required system properties. Proofs are given by analytic formula compliant to chosen pair of topology and algorithmic. In the second assumption, no placement rules are imposed for sub-system tasks. Also it is possible to break down the Supervisor in distributed objects where each one manages local activities. Remote communications to convey events and actions are hidden in the middleware and the lower layer. This paper focuses on what is needed to run a prototype on a single processor.

The minimum infrastructure required for execution comprises:

in the top layer: the application program including activities tasks and the Supervisor task with tables describing the System state diagram in the middleware layer: the time management service (TMS) managing the actions and events is the basic component and its companion is the clock service delivering the on board time -In the bottom layer: the hardware time counters and their drivers, the processor and the real time kernel. Notice the middleware complies with any real-time operating system whatever its scheduling policy is.

TIME MANAGEMENT SERVICE

• OVERALL FEATURES This service goals are : manage events from tasks to Supervisor manage actions from Supervisor to tasks control tasks execution flows with time synchronization watch deadlines and operations durations finely observe the real-time behavior Main programming features are: offer a friendly interface adapt to various contexts free user from low mechanisms handling

• BASIC FUNCTIONS

The main methods made available by the time management service to implement the generic design model are:

-Send an immediate or differed event to Supervisor. Event is recorded to a specific queue till it is read. -Read an event by Supervisor. Next event in the above queue is delivered.

-Signal an immediate or differed action to a named task. Action is recorded to a specific queue till it is requested.

2 nd European Congress ERTS -7 -21 -22 -23 January 2004

-Request the next triggering signal for a task. Trigger can be either an Supervisor action or an internal periodic signal. When a triggering signal is received, the task state moves from inactive to active.

Other functions exist and manage the time and the events during execution of tasks:

generate an event to warn that a task has carried out all actions in its queue suspend execution of a task to a future date or for a duration invoke a software subroutine at a date or at the end of a time out monitor the duration of part of the task erase a deferred event while it is not put in the Supervisor queue dynamically designate a task as Supervisor set an absolute reference time test the presence of an event for the Supervisor monitor the execution of the time management service by an integrated watchdog and invoke the emergency procedure in case of an anomaly. Optional function makes an observation of real-time scheduling events (see figure 3).

PROTOTYPES EXECUTION

The iterative development process of the software is completed by its installation on the execution and validation platform. Running a real prototype enforces analytic proofs performed in the design stage which are rather pessimistic.

To check the actual dynamic behavior versus to the expected one it is easy to set up a time chart from observation results (see figure 3). Moreover, determinism and performance analysis of the current solution are assessed by processing the timed events. At a high abstraction level the non-ambiguous description of the internal behavior of a hard real time system is a guarantee to start a correct development.

It includes enough information to devise a good solution but not too much in order to be easily revised.

Then an architectural design model is straight forwarded which can be analytically proved and then hardened by early assessment on real hardware. Proposed approach does not imply some product or standard to be used but aims at mixing favorite models.

However a new framework has appeared essential while making some compromise between time properties, flexibility and scalability.

An interesting perspective would be to adapt the computing model to a distributed architecture.

  The design model in chapter 4 may be implemented on a single or multi-processor architecture.


Ulrich Freund

Stuttgart Etas Gmbh

Henrik Lönn

Evelyne Silva

Jörn Migge

Vélizy Psa Peugeot-Citroën

Denis Bugnot

Valeo

Matthias Weber

Session 7A

Introduction

Around ninety percent of vehicle innovations are driven mainly by electronics. Hence, software-and systems-engineering becomes a crucial discipline which vehicle manufacturers and their suppliers have to conquer. Automotive software runs on so-called Electronic Control Units (ECU). Besides a microcontroller and memory an ECU consists of power electronics to drive sensors and actuators. The software implementing control algorithms combines the sensor values and calculates some meaningful actuator signals. ECU software-and system-engineering is characterized by the following attitudes: -It is embedded software which means it directly interacts with sensors and actuators and does not change its purpose during lifetime.

-The software fulfils a dedicated control task, i.e. the performance of the control algorithm imposes real-time constraints on the software to be fulfilled.

-The software is realized as a distributed system. Since the information of several sensors provided can (and hence will) be used to improve the control algorithm's performance the information has to be sent to several other ECUs.

-The development itself is distributed. As a rule, a vehicle manufacturer employs several suppliers to deliver the control algorithms and the ECU. Since both the algorithms as well as the ECUs have to work together the vehicle manufacturer has to do a lot of integration work to get the vehicle on the road.

Since vehicle manufactures traditionally put their focus on production cost rather than on development cost, the sensors and actuators along with the bare ECU represent almost the whole amount of costs for electronics spent. Though software does not have a direct amount of production cost it is not for free! The only parameter where software contributes directly to production cost is by memory size. It is therefore a must for a software to be as tiny as possible. Furthermore, there is a direct relationship between the amount of production cost for sensors/actuators and the complexity of the control software in between.

The EAST-EEA project was formed as an ITEA project by working groups from EUCAR & CLEPA in mid 2001 and runs to mid 2004. 23 partners from vehicle manufacturers, suppliers, tool-suppliers and research institutes contribute to define a common middleware as well as an architecture description language. The results are validated by the vehicle manufacturers and suppliers. This paper starts with a bottom-up consideration how embedded basic software components are identified to structure embedded software programs. Afterwards the EAST-ADL is introduced from a vehicle manufacturer's point of view. The middleware is explained on the body electronics domain while the following section shows how ADL and middleware are incorporated in the design of distributed embedded automotive control software.

Embedded Basic Software

To meet the constraints of series production ECUs several programming techniques have been identified in the last twenty years:

-Establishing building blocks and sub blocks. Exchange of information between building blocks asynchronously by means of messages (ECU global variables) instead of synchronous procedure calls.

-Building blocks are implemented by using so-called "void-void functions", i.e. subroutines having neither formal parameters nor return values. At a first glance these techniques differ considerably from the layered approaches proposed in computer-science. However, taking a deeper look into embedded automotive software, one can identify building blocks for basic functions like communication drivers or peripheral access routines as well as building blocks for control-algorithms. Last but not least, there are program fragments realizing a scheduler and global variables for data-exchange between the void-void functions. These building blocks can be layered as depicted in Figure 1. In this layered interpretation of the building blocks the middleware takes a prominent role because it encapsulates the global variables for data-exchange. Access in the void-void functions to the middleware will be realized by an API instead of a direct access to the global variables. This API might be realized by macros.

The program fragments realizing the OS-scheduler as well as the building blocks for the communication layer or the hardware-abstraction layer are (or will be soon) standardized by OSEK-VDX 1 and HIS 2 . The feasibility of a middleware has been shown independently by the French AEE project introducing the ICEM [START_REF] Migge | Embedded Electronic Architecture, 3 rd. OSEK/VDX Workshop[END_REF] (Inter-Component-Exchange-Manager) or by DaimlerChrysler's ORPC [START_REF] Eisenmann | Entwurf und Implementierung von Fahrzeugsteuerungsfunktionen auf Basis der TITUS Client Server Architektur[END_REF] (OSEK-based Remote Procedure Call). The latter has been prototypically realized in the TITUS-Tool-Suite. Both projects have shown that introducing a middleware has a considerable impact on the structure of the building blocks for application functions. To design these building blocks properly, an Architecture Description Language (ADL) is indispensable.

The EAST-ADL

Managing complexity in automotive electronics is the approach to transform vehicle level functional and non-functional requirements to structured distributed automotive embedded control software running on an appropriate electronic architecture. The EAST-ADL is introduced to provide means to facilitate the numerous approaches existing currently in the European automotive industry. To cope with the complexity the EAST-ADL is structured into several abstraction levels as shown in Figure 2. Wherever possible, the EAST-ADL is based on UML 2.0 concepts.

Defines features in

Refined into

Refined into

Appears as

Tentatively allocated to

Allocated to

Results in

Figure 2: EAST-ADL Abstraction Layers

The goal of the vehicle project (VP) is to describe the product line architecture for a vehicle. An Electronic Feature is a user-visible aspect of a system that is implemented by the electronic architecture of the system. Electronic features may be linked by the "is a variant of"-relationship. The goal is to define a structured view of the inherent variability. For example, the "Wiper System with Rain sensor" is a variant of "Advanced Wiper System" which is a variant of "Wiper System". The vehicle type concept is introduced to allow the hierachical structuring of vehicle architecture variants. For each vehicle type a variant is defined by tagging the appropriate electronic features from the library. Furthermore, a vehicle type may inherit the mandatory or optional electronic features of another, more general, vehicle type. This is expressed by an "inheritance"-relation (generalisation, to be more precisely). Additionally, an optional electronic feature of a more general vehicle type can be specified as mandatory for a more specific vehicle type but not vice versa. Last but not least, it is possible to exclude an "inherited" electronic feature in a vehicle type explicitly.

The functional analysis architecture (FAA) is a description of the electronic architecture from a functional point of view. In other words, it is a precise answer to the question "What does the system do?", but independently of software implementation concerns ("How does the system do it?"). This implies that the way the analysis functions are structured is likely to be closer to the structuring of the user visible electronic features than the structuring of software functions implementing later on these features. The goal is to have a precise technical specification of the electronic architecture that allows checking desired properties at system level. The functional analysis architecture could for example support a simulation of the global behavior of the control algorithms. For this purpose, the functional analysis architecture consists of hierarchically decomposed analysis functions that may communicate with each other through signals. In parallel to the hierarchical decomposition, analysis functions may be linked by "is a variant of"-relations. If an analysis function is a variant of another analysis function the latter resolves "variation point" of the former. If an analysis function having variants is used somewhere in the decomposition hierarchy it means that at this "point" any of its variants may be inserted. Hence, the interface of an Analysis Function with variants is the union of the interfaces of its variants. The combination of the decomposition hierarchy and the variant hierarchy allows to "factor out" what is common and thus obtain a compact description of the variability inherent in the functional analysis architecture due to the vehicle type hierarchy. Analysis functions contribute to the realization of electronic features. These links are expressed through a special relation called "selects". The terminology stems from variant modeling. The selects relation enables traceability of dependencies. The EAST-ADL employs a two-stage type system, i.e. all variables have an abstract data type as well as an implementation data type. All formal parameters in methods of the Operational-Function-Interfaces or Values of the Signal-Function-Interfaces are at first specified as Abstract-Data-Types. This means that no physical limits or integer arithmetic are considered. In a second step these Abstract-Data-Types will be "refined" to Implementation-Data-Types, now taking into account the specified physical limits of the signal as well as appropriate resolution [START_REF] Schäuffele | Automotive Software Engineering[END_REF]. This results in a number of required bits which have to be "mapped" to an appropriate implementation type, e.g. an 8-bit unsigned integer. Code-generation will later on respect these settings and adjust the operators accordingly. In addition, it is possible to associate behavior with functions of the hierarchy. However, only elementary software functions, can carry behavior. Behavior can be described using finite state machines, difference equations or plain source-code. Separating function types from their tentative instances ensures sparse ROM utilization in later design stages.

The logical architecture (LA) describes the system on pure instance level. Function instances, i.e. instances of elementary software functions, are clustered to so-called Logical-Clusters. Within a Logical-Cluster, function instances communicate synchronously and ensure that tightly coupled function instances are mapped on the same ECU as well as to the same OS-task. While respecting all timing and memory requirements, Logical-Clusters can be mapped freely to ECUs and OS-tasks. In Body Electronic applications, application software components represent logical clusters. ECU properties with their sensors and actuators as well as the bus-systems are described in the hardware architecture (HA).

Configurable embedded basic software components for the ECUs like OS, HAL, communication.software as well as the EAST-middleware establishes the technical architecture (TA). An example from Body electronics is given in the next section.

Last but not least the operational architecture (OA) describes the running system. It is conceived by first mapping the Logical-Clusters of the logical architecture to ECUs and afterwards to OS-tasks running on that ECU. Connectors being mapped to "different ECUs" will be mapped to the bus-message. Codegeneration of the application software and configuration of the basic software results in appropriate C-Code for the ECU which has to be compiled, linked, and flashed to the micro-controller of the ECU.

On every level of abstraction except the vehicle project it is possible to attach behavioral descriptions to the model, simulating it or checking the properties of the model and to generate code for an appropriate target, e.g. a PC, an experimental hardware or a series production ECU. Generally speaking, the EAST-ADL is capable of linking design-information horizontally (e.g. simulation and code-generation) and vertically (i.e. between different layers of abstraction).

Behavior is either described by external tools (external behavior) or by native elements. In the first case the behavior being described in an external tool (such as Simulink, Statemate, or ASCET-SD) which can be used for simulation, implementation or analysis. The entity can be attached either to analysis functions in the FAA or to composite software functions and elementary software functions in the FDA.

The behavioral description may be associated to a software function with two different aims:

-Specification: this is the case whenever the external behavior will be associated with an analysis software function or a composite software function. It will represent a behavior specification and may be used for simulation and analysis purposes depending on the external tool capabilities.

-Implementation: the external behavior description may represent the chosen behavior implementation only in the association with an elementary software function.

As a rule, behavior modeling tools employ a modeling language consisting of behavioral and structural elements, e.g. blocks & sub-blocks. If such behavioral modeling tools are used to model external behavior, there has to be an equivalence model between the ADL and the structuring elements of the external tool. The structural elements in that tool are derived from the EAST-ADL and thus must not be modified because system integration is again defined in the EAST-ADL. Means for accessing external description parts will be provided in the language for traceability and documentation purposes.

There exists furthermore a native behavior description based on UML 2.0 components. These entities can be used on FDA-level only and are based on object-and interaction-diagrams. A state-chart interpretation with appropriate semantics for series production code generation is currently under definition. The EAST-middleware offers services to transmit data transparently between different ECUs and different tasks. The number of bits specified with the implementation-data-types determine the number of bits the communication software has to reserve on the bus-system. In automotive applications, it is usual to map several SDUs3 , i.e. application signals, to one PDU4 , e.g. a CAN-Frame. For communication between logical-clusters within the logical architecture the middleware implements the IPC-exchangers. From the ECU programming point of view, the IPC-exchangers are implemented by ECU-global variables. Access to the IPC-exchangers is provided by an API which code-generation has to respect for the logical-cluster.

The EAST-

For each of the vehicle domains, i.e. Body-Electronics, Powertrain, Chassis and Telematic/-Infotainment a middleware is defined. This middleware consists mainly of domain specific services. In this paper, the domain specific implementation of the body-electronics middleware is used as an example. An overview of the EAST-middleware for all domains can be found in [START_REF] Thurner | The EAST-EEA project -a middleware based software architecture for networked electronic control units in vehicles[END_REF]. Typically for the Body-Electronics domain is the high number of interconnected ECUs. Currently, the application software is considered as one piece of software while, as a rule, the operating system and the communication layer including network & power-management is realized by standard embedded software components. In EAST-EEA, this approach is extended for application software components too in order to show:

-Hardware independency: Show the feasibility of different suppliers for application software and ECU hardware.

-Portability: Software functions of a supplier can be deployed on ECUs provided by a different supplier.

-Interoperability: The EAST-EEA middleware provides common services used by application software components.

The corresponding ECU architecture is depicted in Figure 4. Each of the embedded software components provides dedicated services which can be accessed merely by means of the corresponding middleware interfaces. Besides an OSEK-operating system, the embedded basic software components for the Body Electronic ECU architecture are: Communication between application software components is always done via the middleware, independently whether the application software components reside on the same ECU or on different ECUs. In Figure 5 Sensor/Actuator access is performed by similar means. An ASAL component has a "hybrid" interface because it communicates via the middleware with application software components and via the HAL API with the micro-controller's peripheral. The ASAL however is an application software component because it reflects all electrical & mechanical properties of the Sensor/Actuator. It is micro-controller independent because it transfers all actions via the µC specific HAL. In Figure 6, application software component K talks via the middleware with the ASAL for sensor S1 (solid line). A remote application software component K' will talk to Sensor S1 by only using the appropriate middleware interface. Conceptually, the basic software components are invoked in the sequence CAL on ECU A, COM-HAL on ECU A, COM-HAL on ECU B, CAL on ECU B. CAL on ECU B will transfer the signal to the ASAL component via the middleware. Technically, this sequence is reflected by the OS-and bus-schedule whereas for each application signal there is an appropriate IPC buffer allocated at the ECUs and a slot in a communication systems's frame. The allocation of application signals to IPC-buffers & communication systems frames is done statically at compile time.

Incorporating EAST Concepts

Figure 7 shows a typical design flow incorporating the EAST concepts of the ADL and the middleware. Starting with a description of the electronic features on vehicle level the application software is designed and analyzed independently from the hardware by means of the EAST-ADL. The behavior of elementary software functions is either described by using a native notation or external modeling tools. Application software components are obtained by applying code generation to logical clusters. Afterwards, they are mapped to ECUs according to non-functional requirements, e.g. cost. All basic software components are configured according to this mapping thus not introducing superfluous variables wasting memory. Configuration is applied to the OS (number & type of tasks), CAL & COM-HAL (mapping inter-ECU application signals to Frames), Middleware (IPC-Exchangers for Intra-ECU application signals), and ASALs (setting IPC-Exchangers & HAL API). The result is the operational architecture.

Conclusion

The EAST-EEA approach to manage the complexity uses a domain specific middleware for information exchange between application software components. These components are modeled by the Architecture description language.

-

  Call stack minimization due to limited synchronous function calls within a building block.-Use of message duplication in case of tentative task interruption. Cyclic tasks with a well chosen cycle time ensure the meeting of hard real-time constraints.-To save overall vehicle's weight and wiring harness, bus-systems are preferred for the communication between ECUs.-In case of bus-interconnected ECUs, cyclic broadcasting mechanisms with collision resolution (e.g. CAN) are the preferred communication means.-Explicit and static scheduling of functions within building blocks.

Figure 1 :

 1 Figure 1: Layered ECU-Architecture

Figure 3 :

 3 Figure 3 : Composite Software Function

Figure 4 :

 4 Figure 4 : Body Electronic ECU-Software-Architecture

-AFigure 5 :

 5 Figure 5: Local and Remote Communication between Application Software Components 5

Figure 6 :

 6 Figure 6: Sensor Access from Local and Remote Application Software Components

  application software component K "talks" to application software component L locally on ECU A, i.e. an application signal is transmitted. In fact, this is done by writing to an ECU-global variable via a standardized API. Depending on the implementation, this global variable resides in the middleware building block (solid connection) or the CAL building block (dashed connection). From the ADL point of view, this ECU-global variable is called in both cases an IPC-buffer However, if application software component K talks to application software component N residing on ECU B, the ECU global variable used to exchange the application signal between the application software component and the CAN-driver resides in the CAL. The CAN-driver is part of the HAL -or COM-HAL to be precise-and will be accessed via the COM-HAL API from the CAL.

			Steuergerät A			Steuergerät B
	Appl. K	...	Appl. L	Appl. K	...	Appl. N	ASAL
		MW API		MW API
		Middleware	Middleware
		CAL API	HAL API		CAL API	HAL API
		CAL	HAL		CAL		HAL
	COM HAL API	COM HAL API
							S1

ASAL

-22 -23 January 2004

According to ISO/OSI, an SDU (Service Data Unit) is a packet or frame from the (n+1)-layer and treated like application data in the n-layer

According to ISO/OSI, a PDU (Protocol Data Unit) is a packet or frame on the n-layer


Camille Ragi
email: camille.ragi@thales-avionics.com

Keywords: Aircraft, ARINC, electronics, IMA, IME, LRU, LRM, standards

HAL is

Electronics is a critical part of civil aircraft, in terms of flight efficiency, safety and also cost. Considering the latter, electronics based systems and equipment of a typical medium-size aircraft of current generation amounts to roughly 20 % of the overall cost. Computers are increasingly being used for control functions of aircraft systems in all domains. Throughout the aircraft life cycle, the cost of modifications, including parts obsolescence mitigation and functional upgrades has becomes even more significant for the airlines. Similarly the demand for new on-board functions and services has increased to the extent that on-board electronics is definitely a major and increasing differentiation factor for the whole chain of Air Transport industry -airlines, aircraft manufacturers and electronics equipment manufacturers-.

The demand for new functions and services

The demand, as expressed by the airlines, raises the following technical and economic challenges:

• Firstly, to fulfil the aircraft design drivers and philosophy which are and remain: Safety, Economy, Comfort, Automation and Communication • Secondly , to increase the functionality of Airborne systems to support the continuous increase in Air Traffic (with FANS, ATM and other new concepts) • Lastly, to respond positively to the demanding competition in Air Transport for more efficiency and more services to operators, passengers and freight: In-Flight Entertainment (IFE), easy access to the web and to e-mail, automatic transfer of all maintenance or commercial data to ground base, maintenance free electronics, etc. 21 -22 -23 January 2004

Today's Aircraft electronics profile

As of today, aircraft electronics is still characterised by a large number of different equipment or "black boxes", the linereplaceable units (LRUs), of diverse technologies, each with their own hardware and software combined into specific architectures.

In terms of weight and volume, the avionics bay of a typical commercial aircraft hosting around one hundred LRU's weighs about 500 kg, with an extra 500 kg of wiring and occupies several cubic meters.

Each black box is dedicated to a function or to part of it, and is developed, qualified, certified, integrated and maintained independently. The effort and related costs of such operations are of course considerable and such a design limits dramatically the possibility for evolution and imposes on airlines costly logistic support.

Evolution of aircraft electronics demand for New Functions and Services

The future demands for new functions expressed by the airlines have led to a steady growth in computer processing capacity and in data communications as shown by the diagram in figure 2. New concepts have arisen with the potential to offer increased efficiency and savings. To address this problem of computer processing and data communications capacity growth vs electronics ownership cost, the aircraft electronics industry has taken the route to take advantage of the concepts and technologies developed in the public information and communication domains.

The Choice for New Open Standards

The Communications and IT market have demonstrated how powerful the concept of Open Standards is in increasing the competition in equipment (i.e. reducing costs whilst preserving and improving the safety level), encouraging the design of creative, innovative and efficient solutions and shortening the "time to market" (i.e. the time between the start of the design of a product and its availability on the market place) and facilitating the development of new generation of hardware and software. The view, now widespread in the aerospace industry, is that it is time to move away from single-source components and manufacturers' proprietary standards towards concurrent development of components by several suppliers working to open standards. Standardisation of electronic components and systems will reduce the costs of purchasing and maintaining equipment throughout the aircraft life. This approach may also be applied to the associated development means and tools, to the system applications performing the functions, and to the various hardware and software system interfaces.

The right Technology at the right place

To respond efficiently to the expressed demands for new functions, it is necessary to make the best use of potentially applicable technologies (detailed below), for each functional Aircraft domain against their safety and reliability requirements, which differ significantly between the "critical" functions:

• the cockpit, utilities and cabin environment (such functions are encompassed in the "avionics" concept). (IMA technology will be used for these domains). and the less critical functions, as found in:

• the On-board Information System or OIS -grouping electronic functions for cockpit crew such as the maintenance information services, the Aircraft Condition Monitoring Function (ACMF), the data loading, the cockpit logbook.

• the Passenger and Cabin crew Electronics Services or PCES, grouping the IFE with Intranet / Internet access, and the cabin crew services such as cabin log book, catering management, duty free sales management (in these domains the use of COTS is considered desirable).

The heart of Avionics Reshaping: Integrated Modular Electronics (IME) concept :

One technological response to the processing capacity growth vs electronics cost is the IME concept which, is based on sharing a bare standardised processing platform (called Line Replaceable Modules or LRM) by several functions.

An IME platform provides the following capabilities :

• Share of the Hardware Resources -Multiple functions can be hosted on the same platform • Independence of the SW vis-à-vis the HW -A standard OS API layer enables the function to make an "abstraction" of the platform hardware. The advantage of the LRMs lies in the fact that these hardware modules are, for a given category of functions, identical, and are independent of the functions they can support. This inter-changeability leads to a drastic reduction in the hardware diversity (i.e. the different types of LRMs). The benefits are considerable: reduction in development, production and certification costs, reduction of maintenance operations costs and spares inventory. Moreover, this architecture brings a high flexibility for the update of functions, or the implementation of new ones in the life of the aircraft.

A key enabler of efficient data communications: the High Bandwidth Network

The stringent reliability and safety constraints on avionics have led the European industry and research centres to initiate several studies to determine the most appropriate technology for high speed communications on-board the aircraft. One of these important studies was led in the European Project PAMELA of the 5 th Framework programme. One essential result was the recommendation to use the Avionics Full Duplex Ethernet (AFDX) technology for data communications with an IMA architecture.

This result has been endorsed by most European aircraft electronics companies, and the AFDX technology based on Arinc 664 (AFDX) standard supports a 100Mbits dataflow and is now acknowledged as a solution with growth potential to meet aircraft system data communication requirements

THE EUROPEAN OPPORTUNITY

Designing new systems based on new architectures and technologies require a considerable amount of effort and investment. This has been acknowledged by the European Commission who included in the FP5 Work-programme of GROWTH, Key-Action 4 "New Perspectives in Aeronautics" -a call for a Target Platform (TP9) on Integrated and modular electronics systems, to allow the European Industry to make the necessary step for forthcoming competitions.

The VICTORIA answer

In this context, European aircraft electronics companies, associated with European research centres and universities, submitted to the EC in full compliance with the terms of work-programme for this TP9 on Integrated and modular electronics systems, a proposal named VICTORIA, as Validation platform for Integration of standardised Components, Technologies and Tools in an Open, modulaR and Improved Aircraft electronic system. This project is aimed at validating the feasibility of a new aircraft electronics architecture: « Integrated Modular Electronics» concept based on open standards through the:

• Modularity and standardisation of the components,

• Definition of adapted Tools • Design of new architectures,

• Certification processes.

Beside the IMA topic, the VICTORIA project tackles the following new issues:

• Interactive MMI of the Cockpit displays,

• Applications enabled by the "Open World" domain,

• Passenger services: communication / business / entertainment needs.

As mentioned above, VICTORIA capitalises directly on the results from both NEVADA and PAMELA projects (former European studies).

The Schedule

Means & Tools

The introduction of new technologies and new avionics concepts has a significant impact on development process, tools, integration and validation means in order to comply with the new roles and responsibilities and with the certification objectives. As VICTORIA takes into consideration the whole sequence of IME development activities a set of means and tools were selected to cover the following areas and development steps:

• System design and modelling

The Applications

The set of applications developed in the framework of VICTORIA was selected according to the following criteria :

• applications which validate new concepts or standards,

• applications which validate the interoperability of independent functions hosted on a common platform, with a standardised operating system. • applications which validate the interoperability of separate domains.

Figure 1 :

 1 Figure 1 : Current aircraft electronics

Figure

  Figure 2 : Evolution of Requirements on Aircraft Electronics

P

  la t fo r m D e fin it io n P la tfo rm D e v e lo p m e n t P la t fo r m V e r ific a t io n

Figure 4

 4 Figure 4 : schedule The VICTORIA programme was kicked-off on January 2001, the validation platform was defined during 2002/2003, now VICTORIA is entering its integration & verification phase.

  According to these criteria : One of the focussed developments has been on the Arinc 661 Interactivity capabilities of the Displays in the Cockpit domain. Integrated Modular Avionics, supporting flight-critical / flight-essential functions were implemented in the Cabin/Utilities/Energy domains : • Fuel management, Landing Gear Extension/Retraction, Braking & Steering • Air Conditioning, Smoke Detection, Pressure Control, Ventilation Control, Doors and Slides Management • Primary Power Distribution, Secondary Power Distribution, Remote power distribution

1980 1985 1990 1995 2000 2005 Memory capacity (MB) Bus data rate (kb/s) 40 20 30 100 000 50 000 25 000 75 000 10 Bus data rate Memory capacity Z80 6800 8080 80186 68000 80286 88000 Power PC Pentium Processors:

-22 -23 January 2004

-6 -21 -22 -23 January 2004

The Organisation

In compliance with the contractual rules of the 5 th F.P., the 34 partners have organised themselves according to the scheme in the figure 5 : The VICTORIA project has led to a partnership of 34 participants from 10 European countries: Denmark, France, Germany, Greece, Italy, Ireland, Netherlands, Portugal, Sweden, and United Kingdom:

• 3 civilian large and medium size aircraft manufacturers for their expertise in Systems Integration,

• 1 civilian regional aircraft manufacturer for applicability of the IME concept to this type of aircraft,

• 2 helicopter manufacturers for studying the IME concepts applicability to rotary wings aircraft, in order to study these concepts on the widest possible range of commercial vehicles that fly as helicopters. • 18 large medium and small aircraft equipment and applications suppliers selected according to their expertise in the different electronics domains and/or their involvement in the VICTORIA processes and means, • 3 state research centres for their scientific expertise in modular electronics and IST technologies, • 4 universities dealing with large system design processes,

• 1 R&D company associated with a large University for component supply, • 2 software companies for applications development.

The Imperial College are an assistant to Smiths

Thales Avionics is the co-ordinator of VICTORIA.

-7 -21 -22 -23 January 2004 The VICTORIA programme has been broken down into seven primary work packages investigating the need for new equipment and applications, as well as the tools and methods to design them. These are respectively:

• The preparation of new standards • The definition of the "validation platform"

• The preparation of new development tools and means • The implementation of components and modules • The development and modification of the software application exercisers • The integration, evaluation and validation testing of resources and applications

Standards

Effort on contribution to international standards is an essential part of VICTORIA. "Core" standards were selected in the first phase of the project to support the exploitation of IME concepts. Effort on contribution to the EUROCAE WG-60 / RTC SC-200 working groups to propose, document and deliver means to support the certification (or approval) of Modular Avionics, systems integration and hosted applications, including considerations for installation and continued airworthiness in all categories and classes of aircraft.

The experimental platform

One essential achievement of VICTORIA will be the realisation of an integrated VICTORIA platform encompassing six domains: Cabin, Cockpit, Utilities, On-board Information System (OIS) and Passenger and Crew Electronic Services (PCES) distributed in three different sites.

-9 -21 -22 -23 January 2004

CONCLUSION

The VICTORIA project enables the European industry to:

• check the feasibility of components / modules compliant with the new standards,

• exercise, at components / modules level, the verification of conformance and validate the conformance test suite, which is a necessary part of any successful standard, • validate the interoperability standards by integrating components / modules from different sources and achieving direct compatibility, • demonstrate through integration of representative applications the overall adequacy and performances of future platforms built around these standards, • validate through their use in this process the various development tools defined for future aircraft electronics programs.

And also very importantly, beside the technical achievements described in this paper, the VICTORIA programme is a successful co-working demonstration of a large European industry team, contributing to strengthen the links and cooperation between its partners beyond the programme.