The AERO ($UFKLWHFWXUH IRU (QKDQFHG 5HSURJUDPPDELOLW\ DQG 2SHUDELOLW\) is an ESA project with the objectives to investigate on a real-time Java virtual machine for ERC32 processor. Special attention was put on the garbage collection mechanism and deterministic execution model. The project have first investigate existing virtual machine to choose a potential candidate that will be customized, are then investigates the definition of requirements concerning a real-time interpreter in on-board systems. The second phase of the project was dedicated to the definition of software functions of the real-time Java virtual machine and to their implementation and assessment through validation tests. The resulting application is the AERO-JVM.

,1752'8&7,21

Space missions require an enhanced level of spacecraft operability and reprogrammability, i.e., an appropriate ability to operate without routine support from ground in order to safeguard the mission objectives. Such requirement can be tackled through the implementation of an embedded interpreter managing high-level operational procedures. Astrium $YLRQLFV 3URGXFWV Business Unit have propose to the European Space Agency, the AERO ($UFKLWHFWXUH IRU (QKDQFHG 5HSURJUDPPDELOLW\ DQG 2SHUDELOLW\ project.

The goal of the AERO project is to provide a software architecture, which improves the reprogrammability and operability of the space systems. Then to propose a standard interface for operability based on state of the art technologies, which allows getting access to commercial low cost products with a good expected lifetime.

21%2$5' ,17(535(7(5

5DWLRQDOH IRU RQERDUG LQWHUSUHWHU

The interpreter provides important capabilities to the space systems. Thanks to the isolation provided by the Interpreter, the Application Programs can be developed and validated separately from the other software components (critical software layers or applications, services). This allows to tremendously reducing the cost of these Application Programs. The interpreter allows specifying, developing and validating Application Programs late in the life cycle and even during operational activity of the system in-orbit (including reprogramming). The execution context of the Application Programs is isolated from the rest of the system as well as the other Application Programs. The execution control of all the Application Programs is kept, so that application software failures, if any, do not disrupt software vital functions (AOCS, FDIR).

The interpreter offers the power of a high level language and supports the implementation of complex algorithms. It also gives the access to the system commands by the mean of a specific interface allowing the control of the entire spacecraft. This permits to implement autonomous operations enabling new complex missions when the ground cannot react in realtime due to the communication delays, including FDIR operations.

In addition, the interpreter technology allows testing on-board a new loaded control processing, running in parallel with the predefined one -a sort of « on-board simulation » which is often very difficult to simulate on-ground, because of real time representativity problems.

All these features show that the Interpreter approach brings benefit to the onboard systems, giving an important flexibility to the developments, operability and maintainability aspects. The interpreter shall offer control structure, data management, subprogram definition and numeric computations. It shall be activated at a cyclic rate or on asynchronous events, with the ability to execute with appropriate determinism, sequences of commands, in the right order and following specified delays, monitoring, and specific algorithms such as thermal controls.

The interpreter shall be able to interface with the remaining software layers through different kind of services: mathematical computations, delays, HW commands and acquisitions, system data.

The interfaces to the environment are critical parts of interpreters. They are the interface with the operating system, with the TC, with the data and with the other services:

• 7KH 2SHUDWLQJ V\VWHP LQWHUIDFH: interpreters are either designed to be activate cyclically or executed as a specific task of the system.

&DSDELOLWLHV

The interpreters suffer from their advantages because they require more and more capabilities. Actually, the development of an interpreted procedure is quicker and cheaper than the development of the equivalent standard application. The current trend consists in the implementation of non-recurring functions under the form of interpreted procedures to minimise the modifications on the rest of the system. Furthermore, the specific functions of a system are defined very late in the life cycle of the software are there is no other possibility than implementing them with interpreted procedures.

/DQJXDJH 7RROV

Current embedded interpreters work on non-standard front-end language, and non-standard byte code. This involves many problems during developments and validations. Setting up a development environment for a specific front-end language supposes to develop specifics tools: editor, debugger, analyser etc. Homemade tools have not the level of functionality of commercial tools. The cost associated to a modification of the language and tools is then extremely important. It appears necessary to define a standard for the language that can be reused from a project to another. This standard should support all the features of existing languages.

3HUIRUPDQFHV

The performances of current interpreters are very low, limited by the performance of the CPU on which they are executed. The definition of a high performance interpreter running on a modern processor will permit to execute faster a greater number of procedures 'HYHORSPHQW VWUDWHJ\ Current interpreters were designed with technologies that could not provide subsequent performances and security management. In the case of the interpreter technology, it's more efficient to take an optimised standard interpreter and to adapt it to the specific space systems constraints. This approach is more robust and secure, than using homemade interpreter, due to the number of specialised developers who worked on it.

Non-standard byte-code and front-end language suppose to develop specific tools and process solutions. The global cost involved is more important than choosing a market-based standard solution. Furthermore, the equivalency of performance, robustness and quality is not guaranteed.

$1$/<6,6 2) 327(17,$/ 62/87,21 5DWLRQDOH IRU XVLQJ WKH -DYD %\WHFRGH DQG /DQJXDJH They're many interests to have a standard interpreted bytecode. But the selected bytecode to use must have all capabilities to answer future requirements. On market, the standardized available bytecode are: Forth, Java bytecode (≠Java language), Lisp, Perl, SmallTalk,Tcl-Tk (interpreted language during execution).

The bytecode depends on functionalities provided by the front-end language, and must implement all its subtleness, with maximum performances and security. The performance of interpreters depends, in a great part, on the bytecode definition. Some criteria was defined to compare bytecode: first level functionalities, instructions size, entropy and redundancy, availability/commercial standard etc. The result the trade-off is that the Java bytecode have the most complete features.

The Java bytecode offers many advantages, even if the complex sets of opcode involves having specifically optimized interpreters. But a Java interpreter source code can be easily found, that could be adapted for embedded requirements.

As front-end source code language it's possible to envisage the use of another language than Java, but Java source code presents a new viewpoint in the evolution of programming languages--creation of a small and simple language that's still sufficiently comprehensive to address a wide variety of software application development. Although Java is superficially similar to C and C++, Java gained its simplicity from the systematic removal of features from its predecessors.

Primary design features of Java, namely, it's VLPSOH (from removing features) and IDPLOLDU (because it looks like C and C++) and the other characteristics (such as object oriented, robust and secure, architecture neutral and portable, interpreted, threaded, and dynamic) finish to decide to choose Java as the source code language.

5HDOWLPH SUREOHPDWLF

Unlike most languages designed for real-time programming, interpreted languages are designed more to simplify programming than to enable programmers to write software that complies reliably with real-time constraints. Therefore it is usually says that this is not the purpose of interpreted languages and associated Virtual Machine to include real-time considerations. But, contrary to popular notions, hard real-time problems with extensive hardware interaction can be solved entirely in interpreted languages. The real-time constraints are not tackled by systems that are interpreted or rely on techniques such as Ahead of Time compilation. However, two methods can be proposed to match the real-time requirements. But the determinism of bytecode execution and garbage collection have to be solve regardless of the methods.

The first method consists in the development of a specific Virtual Machine running over a real-time operating system (RTOS). In this case, the real-time considerations are directly managed by the RTOS. The Virtual Machine is simpler but depends on the RTOS.

The second method consists in the implementation of the real-time requirements directly in the Virtual Machine. Several working groups proposed the specification of a real-time Java, like the Real-Time for Java Expert Group, that have finalize the Real-Time Specification for Java (RTSJ). This specification introduces the common problems of the real-time programming: scheduling, memory management, synchronisation, asynchronous event handling, asynchronous transfer of control, asynchronous thread termination, physical memory access, and exception management. RTSJ propose to improve the Java language and/or JVM implementations. Presently, it does not exist any Java Virtual Machine that implements these real-time specifications. Nevertheless, this appears to be the right way to obtain a portable JVM with a standard behaviour whatever the platform used.

$(52 VROXWLRQ

The chosen solution is to involves both of this methods, by implement real-time requirements in a JVM, and use RTOS to ensure low-level hard real-time functions.

A specification that includes all requirements concerning the final interpreter to develop was written; it details real-time comportments and functions required, essential APIs to be supported, and compatibility with existing specifications and designs of space domain or others standards.

A large number of commercial and open source Java Virtual Machines are available on the market. The commercial JVMs are generally not delivered with their sources and their adaptation to the requirements of space systems is not possible. The open source JVM give us the possibility to focus our activity on the development of real-time and safety mechanisms. We already identified numerous virtual machines that should be a good foundation for the development of AERO-JVM.

The selection process has first start with the characterization of methodology, including destructive and selective criteria definition (features, availability, code readability, maintainability etc.) 25 JVM are evaluated, the resulting chosen solution is: Jamaica JVM from Aicas Gmbh.

'HYHORSPHQWV DQG FXVWRPL]DWLRQV

The base solution have been customized: new functions was developed for real-time support, specific deterministic garbage collection was added, then RTSJ compliance have require a lot of work to add all primitives, memory object and functionalities. A set of APIs required by space domain has been defined; some other features, of the base solution, not required have been removed.

The functionality of the classes of the RTSJ and the determinism of garbage collection are an important requirement for AERO-JVM and the major enhancement to the functionality made during the AERO-JVM project. Priority based scheduling is provided by the AERO-JVM through the RTSJ interface. New real-time thread classes can be used together with the priority interface. This scheduling is enabled by use of the underlying operating system's scheduler. Implemented garbage collector is based a new specific deterministic algorithm, with a particular implementation. There is no dedicated garbage collector thread, consequently, real-time thread are automatically executing at a priority logically higher than that of the garbage collector. All garbage collection work is performed within the application threads. Even though the AERO-JVM garbage collector does not require special treatment of memory allocations performed within realtime code, the special memory classes defined in the RTSJ are provided by the AERO-JVM to ensure inter-operability with other Java implementations and tools. These classes include scoped memory, immortal memory, physical memory etc.

9DOLGDWLRQ DQG HYDOXDWLRQ

Validation of the AERO-JVM has consisted to check the compliance with Java specification, then the RTSJ compliance and the specific space domain requirements compliance. This process is ended, and the application is conform to the full requirements list.

Evaluation is under progress on an ERC32 bench, and consists to run some representative applications, to insure the realtime comportment and performance of the AERO-JVM. This evaluation will finish in March 2003. First results confirm the high potential of the developed solution, but a more complete evaluation is foreseen during next industrialization of the project.

$(52-90 3URGXFW 'HILQLWLRQ

The AERO-JVM is a new implementation of the Java Virtual Machine specification that provides hard real-time guarantees for all features of the languages together with high performance runtime efficiency. This enables all of Java's features to be used for on-board hard real-time tasks. This includes features essential to object-oriented software development like dynamic allocation of objects, inheritance, introspection and dynamic binding. Sophisticated automatic class file compaction and dead-code elimination techniques are involved to reduce the code footprint to the bare minimum.

AERO-JVM includes a runtime system for the execution of applications written for the Java API V1.2. It is designed for real-time and embedded systems and offers unparalleled support for this target domain, including deterministic dynamic memory management, which is performed by the AERO GC garbage collector. The use of dynamic class loading is possible with AERO-JVM. This enables the hot swapping of code and the dynamic addition of new features.

)HDWXUHV AERO-JVM could interpret Java bytecode directly, but class files and the AERO-JVM may be linked into a standalone binary using a specific Ahead of Time Compiler that gives native performances. The final systems could use Posix standard, VxWorks or RTEMS operating systems.

The AERO-JVM provides hard real-time guarantees for all primitive Java operations, but all threads executed by the AERO-JVM are real-time threads too, there is no need to distinguish real-time from non-real-time threads. Any higher priority thread is guaranteed to be able to pre-empt lower priority threads within a fixed worst-case delay.

Among the features of AERO-JVM are:

• Hard real-time execution guarantees • Deterministic Garbage collection • Minimal foot print and ROMable code • Native code support (JNI)

• Dynamic Linking (interpreted mode only) • Java Portability • Fast execution (interpreter or AOT compiler) • RTSJ (Real-Time Specification for Java) compliant There are no restrictions on the use of the Java language to program real-time code: since the AERO-JVM executed all Java code with hard real-time guarantees, even real-time tasks can use the full Java language, i.e., allocate objects, call library functions, etc. No special care is needed; short worst-case execution delays can be given for any code.

The AERO-JVM is able to run some Java applications at the same time, on a single instance of the JVM. This new capability improves Java execution model efficiency; else a new instance of a JVM is required to execute a new application in classical scheme.

$(52-90 LQWHJUDWLRQ LQ 2Q %RDUG $UFKLWHFWXUH

The AERO-JVM run directly on a real-time operating system, but could be also interfaced with a core DHS. Java applications are compiled and/or interpreted, and may access directly native legacy code. APIs are libraries of Java code statically compiled in native. The Java execution model is preserved; AERO-JVM provides, in a real-time deterministic way, segregation between Java applications and the rest of the system.

&21&/86,21

Interpreted languages, and Java especially, with their Virtual Machines implement a large number of interesting features for the development of complex applications. The major expected benefits consist in the definition of a homogeneous development environment (object modeling and object development) and a better reusability of the existing components leading to an important reduction of the software cost and development time.

By implementing the Java language, AERO-JVM offer all required support to ensure the operability of complex onboard systems, and provide a standard way for the reprogramming function.

Evolutions and customisations made in the context of the AERO project, allow the use of Java in hard real-time applications with the AERO-JVM. The AERO-JVM is a new implementation of the Java Virtual Machine specification that provides hard real-time guarantees for all features of the languages together with high performance runtime efficiency and dual mode execution (interpretation and Ahead of Time compilation). This enables all of Java's features essential to object-oriented software to be used for on-board hard real-time tasks.

  +DUG 5HDO7LPH -DYD YLUWXDO PDFKLQH IRU 6SDFH DSSOLFDWLRQV )UpGpULF 'HODGHUULqUH ($'6 $VWULXP ± 7RXORXVH )UDQFH (PDLO IUHGHULFGHODGHUULHUH#DVWULXPHDGVQHW $%675$&7

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

ERC32

  .Walter: Deterministic Execution of Java's Primitive Bytecode Operations, -DYD 9LUWXDO 0DFKLQH 5HVHDUFK DQG 7HFKQRORJ\ 6\PSRVLXP -90, Monterey, California, April 2001 2. F.Siebert, Hard Realtime Garbage Collection in Modern Object Oriented Programming Languages, (7$36 &RQIHUHQFH, Genova, December 2000 3. F.Siebert: Guaranteeing Non-Disruptiveness and Real-Time Deadlines in an Incremental Garbage Collector, ,600, 1998, 4. F.Deladerrière, F.Siebert: Hard real-time JVM for space application, *DOLOHR :RUNVKRS, Noordwijk, October 2002 5. T.Ritzau, Deterministic Garbage Collection, (7$36 &RQIHUHQFH, Genova, December 2000 6. F.DeBruin, F.Deladerrière, F.Siebert: Hard real-time JVM for embedded systems, '$6,$ , Prague, June 2003

  • 7KH 7& LQWHUIDFH: interpreter TC interface is standardised and very simple. The interpreted program can be activated either by a TC, by the timeline function or by another interpreted program. • 7KH 'DWD LQWHUIDFH: an interpreter shall have access to the system data through an This also allows exchanging messages between the different SW components (TM, AP, AOCS, etc.). • 7KH 6HUYLFH ,QWHUIDFH: the interpreter has the capability to use the whole set or only a subset of the general services for basic computation by the means of direct calls or by the means of the standard telecommand interface. • 6WDWH RI WKH DUW DQG OLPLWDWLRQV Different application interpreter components have been developed in the scope of other project, (Eureca CLASP Interpreter, Eurostar 2000/2000+ AP Interpreter, E3000 AP Interpreter and Rosetta Interpreter, COF UCL Interpreter). These existing products correspond to four generation of interpreter.

nd European Congress ERTS -1 -21 -22 -23 January 2004

nd European Congress ERTS -2 -

nd European Congress ERTS -3 -

nd European Congress ERTS -4 -

nd European Congress ERTS -5 -

nd European Congress ERTS -6 -


Fergus Bolger
email: fergus_bolger@programmingresearch.com

C++ Language: Fit For Purpose in Embedded Systems

Keywords:

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Introduction

So you're an embedded developer. You know that C is the right language for the job, although sometimes those maintenance cycles can be, well, repetitive. You sometimes get that nagging feeling that you are coding like an automaton, repeatedly creating basic iterations over structures that are remarkably similar to ones from last week or last month.

You've heard the sales pitch for C++ as a powerful language but you also hear of horror stories about its large footprint, which makes it a no-go for embedded applications. Add to that its inherent complexity Does this have a familiar ring to it? The embedded development market covers a large range of application areas, including automotive, medical, defence & telecommunications. While C undoubtedly enjoys a good reputation as a strong and powerful language for embedded development, C++ does not have quite such a broad appeal. With today's capable and sophisticated C++ environments this is often an incorrect belief.

Why is C++ a viable alternative to C? As a language, it did of course grow from roots in C. Simply re-compiling a C project using a C++ compiler will yield more rigorous code type checking (there are some declaration and scope incompatibilities that you may have to overcome first). Once you embrace its core features, C++ offers a greater abstraction of data, which is an important objective for larger, more complex software systems. Object orientation (OO) takes this abstraction a step further, where you can replace global "worker" functions with class functionality. Of course, C++'s OO capabilities extend further than simple abstraction, and include principles for polymorphism, generic programming, and inheritance.

Templates are perhaps the biggest fear-factor against C++ usage, and most often quoted as the reason for large code-bloat experiences (and suppositions). But well-designed template code offers elegant means of handling a variety of data-types consistently. C++'s Standard Library is an advertisement for such generic programming styles.

Exceptions are added programmatically into many C software systems, and can be replaced, albeit at a cost, with a more elegant C++ exception-based solution. Often, the need for elegance in development only becomes apparent when requirements change. The speed with which well-crafted object-based designs can adapt in such circumstances can be put down, in part, to better abstraction and hiding of implementation.

Compiler performance

Comparing C and C++ compiler implementations can be odious. It is difficult to obtain scientific results from such apple versus orange comparisons. Anecdotal newsgroup discussions have reported space and performance efficiency losses of between 8 and 30% for C++ implementations.

Of course, for the exact same code using the same C library, identical binary code in expected. There is an important point in this. Often C and C++ compilers have shared development pedigrees, with just the front-end containing language unique elements. Therefore, when considering underlying performance, ignoring language implementation and feature differences, we can expect very similar performance.

Embedded C++ Initiative

Undoubtedly, there have been poor experiences of C++ performance in embedded applications. These show up in speed performance and particularly in executable and run time space needs. Concerns about this led to an interesting industry formation in 1997. A group of mainly Japanese embedded systems providers proposed a strictly limited language environment for the C++ language to cater for embedded requirements. The concept was to ban entire sections of the C++ language, mainly consisting of Exception Handling, Run-Time Type Information, Namespaces, Templates, Multiple Inheritance, and Virtual Functions.

There were two main elements to its justification. First was removal of language constructs that caused the dreaded "code bloat". Second was an objective to remove complexity from the C++ language, perhaps with the lower OO experience levels of embedded engineers in mind.

But, with respect to its authors, the approach to Embedded C++ seems fundamentally flawed. The hard-working members of the C++ language committee must have paled on hearing of the proposal to discard whole chunks of their well-engineered standard C++ language. Their collective response to this proposal was to begin an examination of the actual performance issues in the language and its most popular implementations (in terms of compiler and machine environments).

The result is a comprehensive report on the performance expectations of each of the major features of the complete C++ language. Within the report there is a section dealing with the performance and space (both static and run-time) efficiency for each feature. This article will include the report findings that are most apposite for the embedded community. Furthermore, I make a challenging proposition that C++ implementations can match C for equivalent application tasks using the key C++ language features that support OO programming, such as classes with member data and functions, hierarchies and virtual functions, multiple inheritance, and run-time type information (RTTI) at a small cost.

Costs of Language Features

Let us first deal with the aspects of the C++ language that have no additional cost over their equivalent C functionality. Cost here refers to space or performance cost. We must also remind ourselves of the difference between user-defined types and objects of these types. Storage must be reserved for type information, as well as creating the exact space required to hold objects of each type.

C Features

Use of 'C' objects such as structures, pointers, and global functions will compile into the same size and incur no additional space or performance cost in use. In this way, to a large extent, compiling your C programs under a C++ compiler will only add safety and not incur additional cost.

Class Operation

The basic class feature, somewhat surprisingly, does not suffer any space or speed overhead compared with C's struct and global function equivalents. This is because non-virtual functions and static data members are stored with the class definition, rather than in objects of the class. Member function calls have one additional implicit pointer argument, required to point to the class object (* this). On the other hand, freestanding function calls need operational data passed to them explicitly, typically through an equivalent explicit pointer argument.

Static data and functions inside class types are equivalent to C global functions, and take no space in each class object, therefore resulting in no additional cost. Use of single inheritance class structures involves a compile-time offset into the derived portion of the object.

The C++ feature of function overloading, and its specialised use in operator overloading, is a compiled-in feature, in that the selection of the overloading function is made at compile time, and resolves in each case to a specific actual function. This is an elegant and zero-cost solution.

The built-in operators, new and delete, are equivalent to (and often implemented as) "malloc plus ctor(s)" and "free plus dtor(s)" respectively.

Default parameters are also a compiled-in feature, and will be equivalent to a fully qualified function call in 'C'. It should be noted that function overloading might offer a more efficient and elegant solution to the widespread use of default parameters.

Type Conversion Operators

C++ carries forward the C-style cast notation, but supports more secure and explicit conversions, through four new operators, which apply to different conversion situations. For three of these new-style cast operators (const_cast, static_cast, and reinterpret_cast) there is no performance implication. In fact, it is typical for a compiler to transform cast notation into one of these new type conversion operators when generating object code. Only dynamic_cast may involve additional overhead, if the required conversion requires Run-Time Type Information (RTTI) mechanisms such as cross casting in a class hierarchy, which we'll see later. It should be noted that as in C, a cast may create a temporary object of the desired type, so casting can have run-time implications.

Namespaces

Namespaces are a sometimes-maligned feature that in fact cause no additional space or time overhead. They only affect name lookup rules at compilation time. The principle advantage of namespaces is in providing a mechanism for partitioning names in large projects in order to avoid name clashes. As an aside, the using directive avoids the additional typing effort in using explicit namespace qualification by moving all unqualified identifiers into the current namespace. The use of namespaces does, however, add some complexity to the rules for name lookup.

The cost of construction in C++ (calling a sequence of constructors and destructors when creating or removing an object) need not cost anything. It often, and optimally, contains mandatory and necessary initialisation and finalisation of objects.

Virtual Functions

Virtual functions incur a well-defined cost, which is based on the underlying operation: indexing into an array of pointers to function. This is an implementation technique that is common in C code, but more elegantly expressed in the virtual function paradigm.

There are situations where use of virtual functions can result in "code bloat". If a class template that contains virtual functions is specialized on a variety of types, then each of these specializations holds duplicated member functions and their associated support structures including the virtual table. This will generally result in excessive object code, since current linker/optimizer technology is not sufficiently sophisticated to identify this circumstance.

To avoid this problem, you can move common code (not dependent on the instantiated type) out of the class template and into non-template helper functions, or alternatively move functionality from the template class into a non-template base class.

Function Inlining

In terms of achieving performance efficiency, function calls are to be avoided. C++'s inline feature provides the compiler with a hint for functions that could be inlined into their calling location. The compiler is not obliged to take this hint. Advanced optimisation techniques can identify and remove small and less complex function calls automatically without the code explicitly providing the inline hint. However, experience to date suggests that implicit inlining yields no consistent benefit, and the explicit inline keyword should be used.

Virtual Base Class (VBC)

In non-virtual inheritance, member function calls perform a simple constant adjustment. The essential difference with VBCs is that member functions need to perform lookup at run-time to discover which class function in the inheritance tree should be activated. This involves an additional overhead of approximately 15% over the nonvirtual case.

However, simulating the feature of virtual calls through another feature carries costs as well. The alternative technique of implementing an interface class that is passed around the constituent class itself requires an indirection in its access, with the attendant costs and overhead.

Run-Time Type Information (RTTI)

RTTI is used to interrogate the type of an object and also part of the infrastructure of the dynamic_cast feature. As an indication of its expense in performance terms, consider the method of application of dynamic_cast. First find the virtual table (vtable) of the object, then find the most derived object of which this is part, then use that object's type_info data to perform the required adjustments to the this pointer.

Exception Handling

C++'s exception handling feature requires type information at run time, and partly overlaps and extends the RTTI structure. When considering manual coding alternatives to exception handling, consideration must be given to coding style, complete coverage of error handling routines, thread-safety, run-time system overheads, and overheads from handling errors. Considering the cost, run-time overhead, and code maintenance overheads of this makes exception-handling a reasonable alternative.

Templates

Templates are one of the most denounced features of C++ in terms of space costs. Code bloat arises when class and function templates generate a new set of code and data for each instantiation with different parameters. Tests conducted on multiple instantiations of the same specialization versus many different specializations indicate quite varied performance results, suggesting that compilers have some way to go to meet optimization goals in this area.

By enabling certain features, in particular partial specializations, compilers can allow library vendors to implement optimizations to overcome this problem.

The developer can deploy a technique to avoid multiple specializations by routing all instantiation requests through a common class template, for instance by using a common class-template for a single specialization based on void *.

C++ Coding Implementation

While this analysis might make you more comfortable with C++ as a development language, it does not by itself help you to create good, reliable, and above all high-performance, C++ code. There is much advice on optimization matters in the C++ language, including preference for initialization over assignment, avoidance of unwanted conversions, avoidance of temporary object creation (in parameter passing, function return, and expressions), and judicious use of inline. Beyond such language-based optimizations are recommendation on correct usage of C++'s excellent library.

However, let's get back to our C developer mindset. Often, the presumption is made that developing in C++ takes a vastly different approach than traditional C development. If we examine two typical C implementation techniques, we may come to a different conclusion.

Polymorphism in C

With a record that needs to store data of different types, the definition might look like this: error("Not fun"); break; } But this looks very much like the polymorphism concept. The member kind corresponds to a class vtable pointer, and code sections in the switch-statement correspond to a set of virtual functions. The polymorphism alternative is more elegant and maintenance-friendly, considering the proliferation of such switch statements when using this record. There is the further benefit that no data padding is required to fit the largest type, as has to happen in the union situation.

  Then any code that operates on this record must check what kind of data it represents:

	struct Record {
	int kind;
	union {
	int isFun;
	double noFun;
	};
	};
	switch (r.kind) {
	case 1:
	use_int(r.isFun);
	break;
	case 2:
	use_dbl(r.noFun);
	break;
	default:

-22 -23 January 2004 Session 5B: Objects-Oriented Languages and Models

-22 -23 January 2004

Acknowledgements

This presentation is partly based on the Technical Report on C++ Performance, 03-0012/ N1430, from the C++ standards committee. It is available at http://std.dkuug.dk/jtc1/sc22/ wg21/docs/papers/2003/ n1430.pdf.

Code bloat in C

In a typical C project, you will often see iteration code such as: for (int i=0; i <

The C++ library targets this type of repetitive code by putting rich iteration functionality into its set of container classes. It offers a more maintainable, compact, and most probably faster implementation than can usually be achieved with a hand-coded alternative.

Summary

So perhaps this does not convince you to consider an alternative to C. C++ is not a language to adopt lightly. C++ projects need to be well-engineered and well-managed, with continuity of development personnel. Of course, the same can be said for C development. But, based on our experiences, C++ repays you in spades when you adopt its higher level of abstraction, in terms of maintainability and responsiveness to changed requirements. In the more exacting requirements of embedded development, these research results show that, with a little care and attention, C++ has much to offer.


Michael Benkel
email: michael.benkel@aonix.de

Hannouz Mehdi
email: mehdi.hannouz@fr.aonix.com

Pre

Object-Oriented Modeling of Embedded-Software in the Automotive Environment ERST Conference 2004

Michael Benkel has more than 10 years of experience as a consultant in OO projects,

Introduction

The development of motor-vehicle control-systems software is characterized largely by customized demands on functionality, real-time capability and memory-requirements. These requirements vary not merely from one auto-manufacturer to another but also between different projects of the same manufacturer. Furthermore, this user-and project-specific software must be developed efficiently with regard to costs, time and quality. A structured and easily expandable software architecture which describes complete product families is necessary in order to measure up to the requirements of embedded real-time systems in the future. This software must support the forming of variants and the reuse of code effectively without leading to additional run-time-and memory requirements.

The modeling concept for control-systems software described in this article uses object-oriented techniques while avoiding additional run-time-and memory requirements, with C as the target language. OMOS also desrcibes how to model and form variants of software systems. OMOS is thus more than a predefined OO2C Mapping.

The tool-support for OMOS is a development by Aonix (www.aonix.de) based on the product family Software through Pictures.

The development of software for ECU's

The demands on functionality and security of control systems software in vehicles are constantly on the increase. This results in a significant growth in the amount of software in these systems and consequently in the complexity of the software. This poses the problem, especially for the auto-supplies industry, of how to keep the increasing variety of control systems software for the various automanufacturers and their models under control. These demands can only be met by the use of a structured and expandable software-architecture as well as efficient software development.

A high degree of re-use of existing components and code, as supported by inheritance in object-oriented technology, is necessary to achieve these goals. Re-use in this sense means that existing components, which have already been used in a particular context, are used again in a new context, for example in other projects. Quality is raised by the re-use of software which has been tested and already been employed. Components which are repeatedly used become more and more stable and the re-use also contributes to savings in time and money in the creation of the software.

The use of inheritance allows the forming of variants and consequently the alternative use of components. The goal of forming variants is to define new components, building on those which already exist, whereby parts of the functionality are changed or supplemented. This alternative use finally makes it possible to use variants of a component instead of the component itself, without having to change the coding of the component. Not all concepts of object-oriented technology are directly applicable in developing control-systems software, due to the requirements on run-time and memory. Object-oriented languages such as C++ are not sophisticated enough for real-time systems and because of this one often has to fall back on the programming language C.

OMOS at a glance

The modeling concept OMOS is tailored to the development of control-systems software. The consideration of rigorous demands on memory and run-time is thereby extremely important. OMOS confines itself to a certain subset of object-oriented modeling, which makes an optimized mapping to Ccode possible. Known concepts, such as object, class and inheritance as well as inline-and virtual methods etc. are emulated in C. Multiple inheritance, template classes and dynamic generation of objects are not used. Figure 1 shows the process in development with OMOS. The modeling occurs in UML notation with a profile fitted to the particular circumstances. The configuration of a precise control-systems software and the code generation are then tailored to this UML profile.

UML Profile for OMOS

UML stereotypes are used to differentiate between 1-Class and N-Class. An N-Class is equivalent to the class perception known from object orientation and can be instantiated as often as desired. Contrary to this, there can only be one instance of classes with the stereotype 1-Class. This characteristic provides great potential for optimization in the implementation in C with regard to run-time and memory.. For example, all attributes of the instance of a 1-Class can be implemented as global variables in C. The dereferencing of objects and the transfer of object references thus no longer apply. This potential for optimization can be used to great advantage in the development of control systems software as the number of 1-Classes is very high (for example motor, gears, pedal).

Forming Variants

A variant is expressed in UML notation by an inheritance relationship. A new (class) variation is modeled as a sub-class of a more general class variation. The new variant inherits the structure, the behavior and thereby the interface of the more general variation. The new class variation can be supplemented with additional attributes, methods and relationships and can overload the implementation of inherited methods. Inherited characteristics cannot be dispensed, as this would damage the conformity with the interface of the super class. The variant relationship describes a sort of pool of possible variations of control-systems software in a class model. In the above example the control-system software is expanded by an ASR functionality.

Configuration

OMOS models with variants always contain more than one SW system. A configuration thus describes all instances which make up a particular system as well as to which class they belong. The description of the objects takes place in a class diagram with UML object symbols.

Figure 1 :

 1 Figure 1: Development Process with OMOS

  and variant relationship based on inheritance are counted among the relationships supported by OMOS.

Figure 2 :

 2 Figure 2: Modeling with OMOS

Figure 3 :

 3 Figure 3: Forming Variants with OMOS

-22 -23 January 2004 Session 5B: Object-Oriented Languages and Models

-22 -23 January 2004

The above example configurates an ASR system on the rear axle. Instances of the classes CL_AxleAsr and CL_ASR are configured for this purpose. The communication relationships ASR_WL, ASR_WR and the attribute maxSlip are also initialized in the case of the instance CL_ASR.

Code generation

The generation of source code from OMOS models is based on templates. These templates then come into use depending on the stereotype of a particular class. The use of templates ensures that all classes are generated consistently and that a technological transfer to embedded C++ is later possible.

The target language is C as regards real-time capability and memory requirements. In addition, corresponding source is generated for the modeled configuration. The instances for a certain software system are declared and the class attributes initialized in these configuration data.

Summary

OMOS is a concept for modeling control systems software. The key aspects of this concept are the forming of variants in a model and the mapping of these models to the programming language C. OMOS is thus more than a predefined OO2C Mapping.

Today, the major areas of use for OMOS are to be found in the automotive environment, where there is an array of successful projects to be found. The concepts can also be applied to other industrial sectors.


Ramdane Tami
email: rtami@ntu.edu.sg

Boussaad Soualmi
email: boussaad.soualmi@irt-systemx.fr

Abdelkrim Doufene
email: abdelkrim.doufene@irt-systemx.fr

Javier Ibanez
email: javier.ibanez@renault.fr

Justin Dauwels
email: jdauwels@ntu.edu.sg

Machine learning method to ensure robust decision-making of AVs

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

Machine learning method to ensure robust decision-making of AVs

Ramdane Tami 1 , Boussaad Soualmi 2 , Abdelkrim Doufene 2 , Javier Ibanez 3 , and Justin Dauwels 4 Abstract-Replacing the human driver to perform the Dynamic Driving Task (DDT) [START_REF] Dauwels | Taxonomy and definitions for terms related to driving automation systems for on-road motor vehicles[END_REF] will require perception, complex analysis and assessment of traffic situation. The path leading to success the deployment of fully Autonomous Vehicle (AV) depends on the resolution of a lot of challenges. Both the safety and the security aspects of AV constitute the core of regulatory compliance and technical research. The Autonomous Driving System (ADS) should be designed to ensure a safe manoeuvre and a stable behaviour despite the technological limitations, the uncertainties and hazards which characterize the real traffic conditions. In fully Autonomous Driving situation, detecting all relevant objects and agents should be sufficient to generate a warning, however the ADS requires further complex data analysis steps to quantify and improve the safety of decision making. This paper aims to improve the robustness of decision-making in order to mimic human-like decision ability. The approach is based on machine learning to identify the criticality of the dynamic situation and enabling ADS to make appropriate decision and fulfil safe manoeuvre.

I. INTRODUCTION

In movies and the literature world, many fictions about the future deal with the coexistence of robots and humans. The autonomous vehicle could be one of those robots which could characterize the future. Although in several application fields, the machines have already successfully replaced some human tasks, the integration of autonomous vehicles in the traffic environment will be the first large scale and complex coexistence scenario. This topic worries the public and the deployment will require to rethink the legislation and the regulation. Despite the interest expressed by governments, manufacturers and X-tier companies, driving in the urban context still escapes being fully autonomous because of numerous challenges and constraints. It is still unclear when ADSs will be mature enough to replace completely the human in performing the DDT.

The purpose of deploying AV necessitates advanced technologies particularly in term of communication and it also requires a global regulation alignment. On the one hand, this requires to define the operating and regulatory frameworks. On the other hand, it requires to develop human-like driving strategies [START_REF] Li | Humanlike driving: Empirical decision-making system for autonomous vehicles[END_REF], and a panoply of intelligent systems in order to have AV behaviour similar to that of a human who has spent his whole life continuously learning how to assess risks and make appropriate decisions.

From a regulatory point of view, ADSs require to address safety and security. OEMs need to provide evidence that the AV is at leats safe as a human driven vehicle. According to World Health Organization (WHO), in the last decade, 1.3 million people have died in road traffic accidents and millions of people get injured in accidents caused by human drivers errors every year. Concretely the most accurate way to assess the safety of AVs is to test-drive them in real traffic and observe their performance. However a distance-based validation would require driving millions of kilometres in order to attain a statistical significance about the system efficiency and capabilities [START_REF] Kalra | Driving to safety: How many miles of driving would it take to demonstrate autonomous vehicle reliability?[END_REF].

Although, public road testing and dedicated testtrack testing are mandatory to verify real condition driving, designing virtual test framework which does not endanger the road users seems an appropriate and plausible alternative to the distance-based approach which is neither economical nor suitable for repeatable test. Therefore reproducing traffic environment in simulator with fair fidelity can have complementary role in reducing time and cost required by AV validation process with repeatable test runs.

For example in the urban context, since numerous and different types of agents have mingled dynamics, the ADSs requires a very robust perception system and decision making system. First, the sensors should be sensitive and suitable for an accurate real-time acquisition and communication. Then, the reliability of AV decision and action is a prerequisite to AV deployment in complex and time-varying traffic contexts.

Different manoeuvres and actions are jointly realized by human drivers and Advanced Driver Assistance Systems (ADAS) to avoid critical and risky driving situations, by doing basic actions such as: steering, braking, acceleration and combination of previous actions. The biggest challenge for AVs is the development of efficient approaches enabling to completely replace the driver decision-making while preserving the safety.

AV is driverless, then the human decision role is removed. Even without driver the ADS should be able to assess the complexity of the DDT according to agents behaviour and make decisions. This paper addresses a machine learning based approach for decision making in order to ensure safe manoeuvres in a driverless context.

The section II summarizes the state of the art of technologies related to AVs with a focus on the decision making during manoeuvre. The section III discusses risk assessment and introduces Adaboost algorithm. The section IV describes the proposed framework and shows the obtained results. A summary and conclusion are given in the section V.

II. RELATED WORK

Autonomous vehicle depends on five technological locks (Fig. 1): perception, localization, path planning, vehicle control, and decision making [START_REF] Cheng | Autonomous intelligent vehicles: theory, algorithms, and implementation[END_REF]. The latter system makes a choice after comparing several possibilities based on the data given by other systems, such as current vehicle state, sensors, weather conditions and traffic signs. An appropriate command is provided enabling safe movement. Then, an ADS should be able to prevent road traffic accidents and mitigate their consequences which implies new functional safety challenges.

During the DDT to arrive to his intended destination, the human driver behaves and reacts in order to avoid hazards and comply with the traffic rules. However, to achieve a fully driverless state, the AV technology will require human-like capabilities for the control and the decision making in order to move safely and smoothly in mixed and varying environment characterized by uncertainties, disturbances and complex traffic scenarios. Moreover managing the risk of false alarms is another challenge to avoid collisions.

To ensure an optimal design and robustness of AV decision making systems, developing algorithms which monitor the vehicle safety represents a key point of ADSs research. Currently, deep research and development activities are carried out world wide [START_REF] Maurer | Autonomous driving[END_REF], [START_REF] Van Brummelen | Autonomous vehicle perception: The technology of today and tomorrow[END_REF] and [START_REF] Abe | Vehicle handling dynamics: theory and application[END_REF]. Algorithm development activities are gradually increasing because of the critical challenges that need to be addressed. For example in case of path planning issue, [START_REF] Hatipoglu | Automated lane change controller design[END_REF] have proposed a robust lane change approach. The work is motivated by the discontinuous availability of valid data from sensors. [START_REF] Feng | Study on intelligent vehicle lane change path planning and control simulation[END_REF] have addressed a problem of smoothness in lane change. The approach is based on fuzzy-neural network and genetic algorithm.

Furthermore, human-like decision making in AV [START_REF] Li | Humanlike driving: Empirical decision-making system for autonomous vehicles[END_REF] is an emerging field where numerous relevant and promising methods are under development. [START_REF] Naranjo | Lane-change fuzzy control in autonomous vehicles for the overtaking maneuver[END_REF] present an overtaking system for AV. The approach uses fuzzy controller to mimic human behaviour and reactions during overtaking manoeuvres. [START_REF] Claussmann | A path planner for autonomous driving on highways using a human mimicry approach with binary decision diagrams[END_REF] conducted research on the path planning problem in dynamic environment. They proposed a Binary Decision Diagram (BDD) approach using a set of parametrized candidate trajectories. [START_REF] Gadepally | A framework for estimating driver decisions near intersections[END_REF], proposed an architecture of two layers describing a mathematical coupling of vehicle and driver within an intersection scenario. The article used hidden Markov models to estimate Human driver behaviour. [START_REF] Acosta | Teaching a vehicle to autonomously drift: A data-based approach using neural networks[END_REF] presented a decision approach based on hybrid structure formed by a model of predictive controller and feed-forward neural networks to teach a vehicle how to drift like professional drivers do. In the same context, a hierarchical reasoning game theory-based approach has been presented to test and verify the autonomous driving algorithms [START_REF] Li | Game theoretic modeling of driver and vehicle interactions for verification and validation of autonomous vehicle control systems[END_REF]. In such systems, generating Trust index, based on partial or local data, could help to evaluate the decision-making [START_REF] Rosenstatter | Modelling the level of trust in a cooperative automated vehicle control system[END_REF].

Subsequently, some improvement have been introduced to deal with uncertainty. [START_REF] Claussmann | Multi-criteria decision making for autonomous vehicles using fuzzy dempster-shafer reasoning[END_REF] pointed out that the predictive multi-criteria decision-making approach based on fuzzy logic can handle successfully uncertain data.

This paper does not address sensing or communication issues. We assume that the input data are available, we can propose a learning anomaly detection framework that goes beyond the current state-of-theart by considering not only the prediction of critical situation but also the decision under constraints.

III. PROBLEM FORMULATION

Human drivers use a variety of biological sensors when performing the DDT. We use both eyes for perception and our brain as well as our intuition for reasoning and decision. These capabilities enable to analyse the environment and react in less than 1 s, then the safety is achieved as far as possible. But in a driverless state, the capabilities of AV to deal safely with the urban traffic depends on ADS abilities to handle a multi-disciplinary challenges [START_REF] Furda | Enabling safe autonomous driving in real-world city traffic using multiple criteria decision making[END_REF].

A. Driving risk assessment

Human driver analyses the environment before the manoeuvre decision, whereas in AV the total control is transferred from Human to ADS. Therefore monitoring processes which analyse the risk, predict movements and deduce the intention of the other agents is required. In this case, the classification and the study of the dynamics of the other agents can be used to evaluate and estimate the risk and the possibility of collision before action.

[18] introduced the concept of traffic pressure mode and proposed a driving mode decision in the case of lane change. It is based on the assessment and monitoring of rear and front safety distance zones [START_REF] Chae | Model predictive control based automated driving lane change control algorithm for merge situation on highway intersection[END_REF].

Still, efforts to bring these approaches to a level of human-like abilities is linked to managing transition state, movement intention and hesitation of the agents. These aspects which are usually managed by intuition may constitute a limitation for a deterministic assessment criteria.

Let us consider m mostappr ∈ M all the most appropriate decision before execution of a driving manoeuvre based on its feasibility and the safety. The safety is based on traffic conditions and the road traffic rules. The feasibility is function of dynamics, perception and road configuration. The manoeuvre risk evaluation is mainly related to the relative speed, and the relative distance between agents:

R = R T T C + R T IV ,
where T T C and T IV are time to collision and intervehicle time, respectively. R T T C and R T IV are the risk associated with T T C and T IV respectively [START_REF] Hayward | Near miss determination through use of a scale of danger[END_REF].

R T IV = f (P T IV ),
where P T IV denotes the possibility of collision associated to TIV. When a decision can be formulated based on a relationship between mutual information, mutual dependence can be deduced. The mutual information between two discrete vectors is given as follows:

m i (X, Y ) = y∈Y x∈X p (x, y) log p (x, y) p (x) p (y)
where p (x), p (y) are the marginal probability distribution function of x and y respectively, and p (x, y) is the joint probabilistic distribution of x and y.

Moreover, Hybrid state system and hidden Markov models are mixed to estimate driver behaviour and the unknown decision of other vehicle [START_REF] Gadepally | A framework for estimating driver decisions near intersections[END_REF]. Another approach based on classification and regression trees has been established in order to predict and estimate driving manoeuvre risks.

However, the accurate calculation of mutual dependence is hard to achieve because numerous external indicators are not available. To design and improve functional safety of autonomous vehicle, this article proposes a machine learning based simulation approach.

B. Adaboost based Method

This section introduces the Adaboost classification algorithm [START_REF] Freund | A decision-theoretic generalization of on-line learning and an application to boosting[END_REF]. It is suitable for binary classification in which a strong classifier is achieved based on iterative minimization of exponential loss criteria and linear combination of weak classifiers.

Let Γ = {(x i , y i ), i = 1, n} denote a training set of n independent observations, where x i = (x i,1 , x i,2 , ..., x i,p ) T ∈ R p represents the input attributes for manoeuvre decision. y i ∈ {+1, -1} the class label of the i th instance, where the finite discrete values "+1" and "-1" are respectively the succeeded and failed labelled manoeuvre.

Input: Let consider (x i , y i ), i = 1, n set of n observation or training sample data, and H = {h k } the set of constructed weak classifiers.

Weak classifier: Classification And Regression Tree

h : x → [1, -1]
Initial weights: w

(1) i = 1 n for i = 1, n such that n i=1 w (1) i
= 1. As there are as much successes as failures, it is not necessary to take adjustable initial weights.

Let m be the maximum number of iterations For j = 1, m do Let ε j be the sum of weighed weak classifiers h j :

ε j = n i=1 w j i I [y i = h j (x i )] where I [γ] = 1 γ = Succeeded 0 γ = f ailed
Generate weak classifiers h k such that ε k the sum of weighed weak classifiers is minimizing:

h j = arg min h j ∈H ε j where εj = n i=1 w j i I [y i = hj (x i )] and I [γ] = 1 γ = Succeeded 0 γ = failed Learning coefficient α j = 1 2 ln 1-ε j ε j of each weak classifier Update weights distribution w j+1 i = w j i e -α j yih j (xi) Renormalize D j+1 i = w j+1 i /Sj for ∀i, where Sj = n i=1
w j i e -α j yih j (xi) end for Output: The final strong classifier:

H = sign m j=1 α j h j (x)
In the next section, we will combine the elements described above to carry out a method enabling safe decision making during driverless manoeuvre.

IV. FRAMEWORK FOR LEARNING-BASED DECISION

MAKING

Many important social and physical phenomena can be numerically modelled allowing an accurate representation of the real world. Furthermore, through simulation it is possible to quantify performance and provide relevant metrics about the considered model. In the case of ADS development and scenario-based testing, simulation enables deeper investigation of common scenarios and also situations which may not be very frequent on the roads. Simulation also helps in training and testing the system behaviour in critical and edge case scenarios. Therefore, simulation represents a powerful source of feedback and is a relevant means of validation.

The proposed approach uses SCANeR-studio which provides a framework for performing the testing and the analysis of autonomous driving systems in a virtual environment. It can be run on a desktop pc. The simulation environment contains models of cameras and radars for perception systems, models of both ego and agent vehicles, a model for the driver and models of physical environment (weather, light, infrastructures, agents, etc.). The simulator feeds sensor data to control the system which executes a path planning algorithm.

To validate the proposed approach, we consider to collect simulation data in a Cut-In scenario.

A. Data collection

A Cut-In manoeuvre, as illustrated in Fig. 3, consists in changing lanes by moving in front of or in between the vehicles that are driving in the target lane. For this scenario, depending on the number of vehicles in the target lane and the gap between those vehicles, numerous possibilities and test cases can be considered, taking into account increase and decrease of speed, reduced space, visibility, etc. The parameters considered for this scenario are as follows: Simulation proceed iteratively by varying speed of both the ego vehicle and the agent vehicle. At each run of the simulation as shown in Fig. 4, metrics for the test case are measured (TIV, DIV, TTC and DTC). This process is repeated thousand times to cover representative parameter ranges. In this study we consider that thousands of simulations are sufficient. Furthermore having more simulation and more data can only improve the result.

B. Simulation results

We present results from the application of proposed framework to the cut-in scenario. Thousands of simulations are executed. A part of collected data is used for the training and the remaining part is used for the validation. To implement the Adaboost classifier we chose as input the ego vehicle speed and the agent speed which are relevant variables for a collision, and as output the distance to collision (DTC). As shown in Fig. 5, hundred of classifications are executed with a random selection of training data set. Fig. 5 illustrates that whatever the chosen training set is, the validation error converges to a limit under the threshold of 2%. Therefore, such machine learning approach can be considered robust and suitable for scenarios that involve uncertainty and unknown decisions of others vehicles such as braking or overtaking.

In Fig. 6 we represent the simulated data by the red colour, the red-point represents the failed manoeuvres and the red-plus represents the succeeded manoeuvre. The green circle represents the prediction of failed manoeuvre, whereas the blue square represents the prediction of succeeded manoeuvre.

Fig. 6 shows that, through the proposed framework, we can predict the result of manoeuvres which is helpful to make dynamic decision in a driverless state enabling to avoid dangerous manoeuvres. Indeed, the results demonstrate that we can identify manoeuvres that violate a safety goal of no collision.

Moreover, Fig. 6 shows that machine learning could be performed by simulation since the tests proved that the proposed method could predict the critical situations. The results show that a simulation-based machine learning is an efficient way to manage the different scenarios faced by AV and that this machine learning approach can improve substantially the decision making.

V. CONCLUSION

Although it is hard to foresee the future, we can imagine that autonomous vehicles will be a part of it when the regulatory and technical challenges are solved. This paper proposes a simulation-based machine learning approach enabling ADS to learn how to make a safe decision before or during manoeuvre. The proposed approach uses the Adaboost classifier which has been trained using experimental data generated by a virtual test driver. A remarkable ability to predict the simulation outcome is shown.

PFig. 1 :

 1 Fig. 1: Challenges and requirements for autonomy.

Fig. 2 :

 2 Fig. 2: Risk evaluation. Where V egof and V egol relative speed between ego vehicle and respectively front and lateral vehicles, DT C f and DT C l are distance to collision between ego vehicle and respectively front and lateral vehicles, T T C f , T T C f are time to collision front and lateral vehicles and T IV f , T IV f are intervehicle time in front and lateral respectively .

Fig. 3 :

 3 Fig. 3: Cut-In manoeuvre.

Fig. 4 :

 4 Fig. 4: Scenario data collection.

Fig. 5 :

 5 Fig. 5: Learning validation error.

Fig. 6 :

 6 Fig. 6: Cut-in criticality prediction.

supported by IRT-SystemX and ERIAN


Industrial are more and more faces to the hard problem of developing more sophisticated real-time systems while time to market, quality and cost constraints are constantly increasing.

The product development challenges they have to meet with are:

• Accelerating rate of innovation and technology changes • Increasing pressure for delivering products faster

• 80% of the market share generally goes to the first two companies to market a new product

• Do it right the first time • Control risk associated to fast delivery • Drive components platform/technology reuse • Increasing product & process complexity

• Increasing number of requirements coming from multiple sources • Increasing regulation complexity • Increasing interactions between systems • Increasing software functionalities • Increasing product variants • Increasing multi-disciple interaction (Mechanical / Electronic/Software) • Unpredictable fluctuations • Increasing pressure on product cost reduction • Increasing pressure on higher quality Complex real-time systems are characterized by :

• Extreme dependability (reliability, availability) • Predictability

• For example, critical systems must be deterministic, for safety reasons. • System certification This paper will outline and discuss some of these trends through the presentation of an aeronautical project.

We have been involved in a preliminary technical development, three years ago, which deals with the following requirements:

• Airplane Electrical Power Management • Provide guidelines for the production of software for airborne systems and equipment.

• Assess new development method and CASE tool in order to improve productivity. • Dependability • Comply with airworthiness requirements define within the DO-178B standard.

• Assess new technological concepts and new architectures in order to improve the competitiveness of future airplanes and develop the prototype

• Integrated Modular Avionics

Airplane Electrical Power Management

The airplane electrical power management consists of the following applications:

• Load management Unit, • AC/DC commutation • Protection • Maintenance
The goal is mainly to prevent damage and fires from electrical and to distribute the power to all the technical and commercial facilities. • The electrical master box is composed of contactors and protections.

• The facilities configuration is loaded from the ground using the ad hoc operator interface.

This flexibility enables an aircraft manufacturer to "reuse" the electrical system.

New development method and CASE tool

What about using an object oriented methodology and defining a dedicated case tool for developing these software applications?

The main objectives are the following:

• Conciliate new development method and tools with the DO-178B standard,

• Provide a shared vision of the system within the consortium,

• Take into account new requirements during the first two third of the project.

In order to achieve them, we have performed the following tasks:

• First, all the DO-178B software plans have been developed

• The software life cycle, including the methods and tools to be used for the activities of each software life cycle process have been selected and set up

• The AGLAE workshop has been defined (see figure below)

• The added value was the optimal integration of all the COTS The Object Oriented Development has been done using the AGLAE workshop:

AGLAE

• Analysis /conception using UML profile real time

• Target C++/ C • Code / test / documentation generation • Cross Development NT/LynxOS
The commutation application is usually carried out with logic wired technology. We intend to implement it with software.

To facilitate and shared the system behavior before its development, a virtual test bench has been set up to validate the specification.

• The electrical behavior is simulated with Saber,

• The electrical power management is performed from the control unit

Dependability

The dependability of the system is done through Control Unit redundancy. The software development must handle multi control units requirements.

Model Driven Architecture

The OMG has formulated a vision of a method of software development based on the used of models. Key characteristics of MDA:

• The focus & principal products of software development are models rather than programs

• "The design is the implementation" (i.e. UML as both a modeling & implementing language) UML plays a critical role in MDA • Automatic code generation from UML models • Executable UML models

We will explain in our oral presentation how we have achieved the dynamic load management sub system development using all these different models

Architecture description language

Good architectures are essential for the successful construction and evolution of complex real-time systems. Architectural designs must be visible and enforceable or "architectural decay" sets in. The concepts of active objects, ports, connectors, and protocols provide powerful modeling capabilities for capturing our architectures. Furthermore, automatic enforcement can be achieved through automatic code generation from such models time 100% Critical Knowledge Threshold Yes, but what about performance and performance tuning?

• What is the cost of abstraction ? How about modeling real-time specific phenomena?

• Time and timing mechanisms • Resources (processors, networks, semaphores, etc.) Exploiting current real-time system theory?

• Schedulability analysis (e.g., rate-monotnic theory)

• Performance analysis (queueing theory) First of all, Rate Monotonic Analysis is the applicable technology used within the project to predict timing performance.

System Representation Modeling

RMA based Analysis

Secondly, our scheduling policy is divided in two levels :

• At the LynxOS level which manages processes and physical threads (priority …)

• At the thread level with a dedicated scheduler (in order to support Run Time Completion paradigm).

Figure 1 :

 1 Figure 1: AC network architecture

  Figure 2 Hard Real Time Case Tool

Figure 3 :

 3 Figure 3: Specification validation using a virtual test bench approach

Figure 4 :

 4 Figure 4: Model Driven Development

Figure 6 :

 6 Figure 6: Reduced Time development

Figure 8 :

 8 Figure 8: Rate Monotonic Analysis

•

  Physical distribution This complexity requires focused support in at least the following areas :

  Timeliness and

•

  Distributed system

•

  Fault tolerant (detection, treatment, analysis, recovery

•

  Architectural design

-22 -23 January 2004

Contactors & Protections

Using Executable Models

Complex real-time systems can be very difficult to understand and to design. The technical process involved should take into account human cognitive processes The use of automation (executable models and automatic code / test / documentation generation) has significantly reduce the development cycle, especially the time required to reach critical knowledge threshold and the time required to convert a design into an implementation.

LynxOS

Wrap up

The lessons learned during this project are:

• Use of UML Real Time for Hard Real Time system, • High responsiveness to requirements change, • Tools Integration within the AGLAE Workshop, • Software productivity,


Denis Claraz
email: denis.claraz@siemens.com

Dr Klaus Eppinger
email: klaus.eppinger@siemens.com

Lutz Berentroth
email: lutz.berentroth@siemens.com

Group Leader -Sv

P Gs

T P3

Session 6A: Architectures Title : Reuse Strategy at Siemens VDO Automotive : The EMS 2 Powertrain Platform Architecture

Keywords: Aggregate implementation group Architecture, Platform, Reuse, Process, Generic, Configuration, Flexibility

A modern engine management system has to cope with a big amount of conflicting requirements, and should in parallel be sufficiently flexible to address the increasing wish of car manufacturers to differentiate from competitors.

In order to fulfill these requirements, new solutions have to be introduced, which are open enough to make allowance for future technology trends. A promising approach is the introduction of a modular architecture as a necessary means for the definition of a scalable and adaptable platform. Siemens VDO Automotive addressed this challenge with the introduction of the EMS 2 platform, and showed that standardization need not to be in contradiction with flexibility. Right from the early definition phase, specific focus was given to the car manufacturers' needs, i.e. to allow the integration of competitive customer owned functionalities and technologies. The development of concepts for modular architectures has been carried out in different domains and is largely documented. A constant challenge is the definition of efficient processes and the necessary adaptation of the 2 nd European Congress ERTS -2 -21 -22 -23 January 2004 __ __ organization, in order to take advantage of the dedicated platform. This applies to the introduction of a new platform within an existing organization, as well as for its maintenance. With the EMS 2 platform architecture Siemens VDO Automotive is prepared to support different types of business models, while taking full advantage of a platform's features.

Introduction

In the last ten years, the complexity of the Engine Management Systems (EMS) has drastically increased, motivated by stronger emissions regulations, lower fuel consumption, and improved drivability. In parallel to this technical evolution, prices are decreasing and time-to-market is getting shorter. As a result, in the last 15 years, the functionality of EMS has increased by an order of magnitude, while in the same time the ECU price has roughly been divided by a factor 3, and the time-tomarket by a factor 2

To answer to the market development, business model, organization and processes are evolving:

-Competitive developments and shared developments are made possible: EMS systems are controlled integrations of Siemens VDO and OEM functions, of object or C code developed by OEMs, tool-vendors, partners, or even competitors.

-To ensure a good reactivity and proximity to the customers, an international organization is needed, with development centers located in different countries, and continents.

-To allow investigations on new components or new strategies, parallel branches of the same project are managed, with independent releases and resynchronization points.

In addition to the process and business, the technical complexity of an EMS system is also increasing, due to:

-High number of controlled system components (pin-out with up to 150 Inputs/Outputs).

-High reaction speed needed by the control laws (more than 90 % of SW done at 10 ms or faster) -High coupling between the functions (i.e. phasing between injectors opening and spark advance) -High number of functions (700) integrated in one single ECU. To handle these tendencies, and to be prepared for the future, Siemens VDO has developed a strategy in 3 axes focusing on function reuse. The goal is to capitalize experience, avoid multiple developments, improve maturity of solutions, and shorten response time. Synchronized with the introduction of a new technology (32 bits), a new architecture has been developed, with new principles, in particular to ease the data flow control. In parallel to this architecture, a process and an organization have been set-up and implemented, to support this approach.

The EMS Architecture

Exchangeability and reuse of assets as e.g. SW or HW components are two of the key features expected from a platform approach. Basic mechanisms to support these features are encapsulation and therefore abstraction.

Two different approaches are applied within the EMS 2 platform, both of them adapted to local needs in order to maximize exchangeability and reuse.

Layer architecture

Function partitioning

A "horizontal" abstraction or function partitioning, enables the encapsulation of control functionalities. In order to get independent functions and to master the data flow between modules, a standard partitioning is set-up, using the abstraction and encapsulation principles. Following a top-down system analysis, 19 groups have been defined

(fig. 4), which cover the complete functionality of the system. As these groups are too big to be reusable, they have been split into sub-sets, which are called "Aggregates".

An aggregate making abstraction of a sensor typically delivers a physical and validated data. For an aggregate including actuator control, the structure looks similar, but inverse. In total, 65 aggregates are defined, with a high internal coherence, and low inter-coupling. A standardization of the architecture at aggregate level leads to a standardization of the interfaces, at the same level. These aggregates are the basis for reuse, and are themselves split into modules (fig. 5). The modules are then the smallest units managed in configuration.

A first characteristic of an aggregate is that it contains a complete functionality. For instance, an aggregate managing a sensor contains the acquisition, diagnosis, limp home, and the computation of derived values (i.e.

distance calculation out of vehicle speed acquisition), as well as the requests to the other strategies (i.e. spark advance correction, due to knock detection). This grouping is of particular interest as the different facets of the functionality are supposed to evolve consistently, with new requirements. In addition, this is a mean to group all the technical expertise on the functionality.

Each time a function is modified, enriched or added, the architecture work consists in defining to which aggregate and module it belongs, and to define the best implementation, with less impact.

Interface standardization

Another characteristic of an aggregate is its interface description. Based on the encapsulation concept, a standard interface is defined, where all inputs and outputs are listed. Consumers and providers of the information are specified, as well as the required data types. In addition to the data flow, the control flow is also described in the interface: dynamic constraints between aggregates, connections to the operating system. Due to interactions between system components, aggregates cannot be executed sequentially and independently.

As aggregates have to be configurable to allow project adaptations, it may happen that the configuration of one aggregate depends on the configuration of another one. Consequently, there is a "configuration flow" between aggregates, in addition to the data and control flows, formalized in a third part of the interface (fig. 6). For instance, the VVT configuration impacts both the VVT aggregate, and the Camshaft/Crankshaft aggregate.

Here, the architecture work will consist in defining which information of the aggregate have to be exported, and try to limit this interface, in order to limit the coupling. Finally, the combination of all aggregate interfaces for the three facets, together with the partitioning, is fixing the overall EMS architecture.

Configuration for open systems

In order to increase reuse, we need at the same time standard and flexible solutions. Therefore, configuration becomes a key issue. So, each aggregate is split into a "generic fixed core", a "generic configurable" part, and a project-specific part (fig. 7). The two first parts are called "generic" because they are developed, maintained, and validated by a transverse team independent from the project, and they can be adapted to the project configuration, using standard mechanisms. The "generic fixed core" is strictly the same for all projects reusing the aggregate, and is totally independent of the system configuration. The "generic configurable" part can be adapted to the project, using standard mechanisms, but without modification. The third part can be modified by the project itself, but is still subject to restrictions. In particular the interfacing with the rest of the application stays under strict control.

Aggregate Internal Implementation

Data Flow

Static architecture

Control Flow

Dynamic architecture

Configuration Flow

Configurational architecture For instance, the camshaft/crankshaft aggregate is built out of 16 modules. 9 of them are strictly identical for all projects, 3 are depending on the type of sensors, and 4 have to be filled with project specific information. In parallel to the architecture principles, an aggregate dedicated process has been designed. Objective is to manage aggregates like internal products, or projects, with a defined quality level. This quality level will be linked to the level of validation, of documentation, of progress… In the following paragraphs, we will describe some principles of the process. Topics like risk management, configuration management, validation process are not described here, but have been subject to special adaptation for the aggregates.

Generic Fixed Core

Generic

Reuse granularity vs.

Development granularity

The first idea of the aggregate concept is that the reuse granularity is different than the development granularity. Reuse is based on consistent packages of pre-integrated and prevalidated modules. All the modules of an aggregate are maintained accordingly.

The project sees a release of the complete package, but does not see the intermediate releases of the modules, which were necessary during the development. The projects are not impacted by the changes of internal structure. The owner of the modules defines the valid combinations, not the user. The aggregates are split into the granularity best suited to their development and maintenance (i.e. splitting a module in two, in order to improve its testability, or portability is transparent for the project). This principle is applied for all involved disciplines: a complete specification is built out of specification aggregates; a complete SW is built out of SW aggregates, both of them formalized as "Aggregate Reference Lists". The architectural work, briefly described in the previous paragraph, takes here its real signification, as the split into aggregates and modules has to be suited to this concept.

Defined process for Aggregate development

The aggregate is developed following a dedicated process, similar to a project process. A kick-off meeting is To reach this objective of 2 releases per year, the projects requirements have to be managed in a very pro-active way through regular projects meetings.

Dynamic reuse vs. Static reuse

To ensure that all projects will benefit from the latest improvements of the aggregate, a dynamic reuse is applied, instead of a copy-andpaste reuse. The projects follow the aggregate evolutions with the help of a dynamic link, but they do not copy-and-paste the solution in their own work space. This follow-up is of course not automatic, as the project may have external constraints (hot trip, calibration already done, SOP, …) incompatible with the update of an already running functionality. On this last point, a precise study is done, when introducing a new aggregate, or when upgrading an already existing aggregate release, to avoid unexpected impacts. This dynamic follow-up of the aggregate by the project needs a certain effort and discipline, whose benefit may not be seen easily. Nevertheless, the maturity of the aggregate increases with the number of projects reusing it: due to the different projects system configurations, the aggregate is validated on a wide basis.

A multi-facet package

As last aspect of the concept, the aggregate is made of different facets, corresponding to all the involved disciplines. This eases the reuse for the project : once a specification package has been identified, one SW modules package is also identified, one set of default calibration data, … are defined. Thus, reusing an aggregate does not mean only reusing a specification or a code, but also reusing calibration report, HW description and so on.

In addition, this eases the access to the information, and helps the different disciplines to share a common view on

Organisation

In parallel to architecture and process adaptations, a consistent organization has been implemented, to support the reuse concept.

A long term investment

To develop and maintain the aggregates, generic teams ("Domains") are installed, apart from daily business.

Having a good knowledge and overview about the requirements of different projects, their challenge is to design reusable (and in practice reused) aggregates, keeping in mind other constraints like efficiency, quality standards, and functional correctness. A migration of the "old" module structure into the new aggregate structure has been done, with sometimes a complete re-design and re-coding of the solution. Of course, this migration had to be done in parallel to the running projects, and with as few perturbations as possible. Then, resources and priority management became critical issues (opposition between short-term-project and long-term-generic views), which needed involvement of the management. So, the aggregates have been introduced only step by step in the projects.

Consequently, the management has to communicate and explain the strategy to the complete organization, from management level to working level. This communication is of particular importance at the beginning of the migration, where the additional workload of the approach is more seen than its benefits. Such a task is complex due to the size of the organization and its multi-cultural dimension (country, plus discipline). But it is a key task, as a reuse strategy cannot address a single project, neither a single location, nor a single discipline, but the organization in its entirety.

A cultural change

For Domains, the architectural work becomes as important as the functionality itself, to reach the reuse objectives. Also, the application of a defined process, with formalized entries and outputs, with formalized communication with their customers becomes a key factor. Finally, the Domains become a kind of "function factory", with all quality, project management, and efficiency standards. In a next step, the gained experience will be used to optimize methods and tools necessary to handle major platform assets, and to review the concerned organisation in order to streamline the related processes. Therefore, the gained key learnings will also become a direct input to process optimizing activities like CMMI etc.

Further on, the experience will be used to extend the acquired know-how to other business fields, Domains and crafts. Here, an extensively discussed topic is the introduction of an automotive architecture standard within the Autosar consortium. The key learnings of EMS 2 will be presented for integration in this development. One topic from an EMS point of view is the seperation between engine specific functions, and those functions, in the past typically implemented on an EMS, but interesting for a vehicle architect. This separation is an important lever to increase reuse, e.g. between Diesel and Gasoline EMS.

Finally, introducing a new platform deals with pure change management. As it touches the way of working of everybody, including the related processes, the needed know-how, the interfaces within the organisation, the tools to be used and so on, the human factor should never be underestimated. From the communication of the strategy by the top management down to the consequent and anticipating application communicated by the concerned team leaders, motivation remains a key factor for success also for this type of development.

  Fig. 0 : Evolution trends of EMS

Fig

  Fig. 0 : The EMS layered architecture

Fig

  Fig. 0 : The EMS 2 Partitioning

Fig

  Fig. 0 : Aggregate = a complete interface

  Fig. 0 : Configuration of an aggregate

  Fig. 0 : Reuse granularity vs. Development granularity

Fig

  Fig. 0 : A dedicated process

Fig

  Fig. 0 : A multi-facet package

Hardware Abstraction Functional Mapping Representation of Real world Component Abstraction Control Strategy HW Componen Hardware ECU Connector Real world Librarie s OSEK OS

							A "vertical" structure leading
		EMS2 Standard Interface	to a multi-layered architecture is
	i. Process Process Combust Combust Engine -Gasoline Torque Exhaust Gas Gas Air Exhaust Engine -Gasoline or Vehi Vehicle Motion Drive Drive Electric Electric Vehicle Powertrain Vehicle Motion Powert Powertrain Management Powertrain Management	Chassis Chassis	Manager Manager System System Transverse Functions	used as basis for systematical abstraction of engine/car, sensors/actuators, successively
	States (Gasoline) Engine Torque Ignition Air	Position & Speed Fuel Engine	n Transmissio Transmission	interior interior Body & Body &	ECU Function ECU Functions Basic Basic	ECU connector (pin-out), ECU-
	Engine Engine Position & Speed States	Ignition Fuel (Gasolin e)	Engine Engine Cooling & & Cooling		Electric Electric Power Power	Commun Communi i-cation -cation	HW, and finally microcontroller. It
							allows e.g. to exchange the used
							microcontroller with a limited
							impact on the upper SW layers, or
							to exchange a sensor without
	impacting the control strategy. This HW dependent SW within the EMS 2 system is called
	"Infrastructure". The other part of the SW is HW independent, includes e.g. control strategies, and is partitioned in
	so called "aggregates".

Libraries Infrastructure (HW dependent) IO Drivers

-10 -21 -22 -23 January 2004

__ __

The projects have the objective to reuse solutions on-the-shelf (aggregates), rather than develop them specifically.

Step by step, the function expertise is capitalized in the Domains, and the projects become specialists of integration and customer relations. They give their inputs to the aggregate developments in a pro-active way. A team-work is initiated between these teams, and release planning and contents are negotiated together.

In summary, the generic aggregates should be considered as a common patrimony, for which any user is coresponsible, and participates to the maturity, as well as the owner himself.

Platform Group role

To support the reuse process, and to switch from an individual-initiative reuse to a managed and controlled reuse, a

Platform Group is created. This group, center of architecture competence, helps the Domains to create and maintain reusable aggregates. It also helps the Projects to configure their system and select the right aggregates, thanks to its portfolio expertise,.

This group has also a major role for the planning and control of the dynamic reuse. It synchronizes the Domains deliveries with the projects milestones, plans and supports the introduction of new aggregates within a project. It also ensures the compatibility of the available aggregates together, knows about the current issues, and masters the current portfolio. The Platform Group finally is the owner of the architecture rules and concepts, and is involved in all process improvements actions.

EMS 2 Implementation Status

The EMS2 reuse strategy at Siemens VDO is not only a concept, or an experimentation done on an advanced project, but a reality implemented step by step on the currently running industrial projects.

What is on the shelf…?

After a definition of the necessary concepts of process and architecture, the migration phase into the aggregate standard has started. The first pilot aggregate was developed, and introduced in June 2000 on a first project. In December '03, 40 aggregates have been migrated, covering standard functions. This represents 10 groups fully migrated, and 2 to be finished soon. This basis constitutes the EMS2 platform, used for any new 32 bits project.

… and what is really used ?

In parallel to the migration of aggregates, projects have started their integration. Of course, this integration has been done smoothly, not to endanger the customer deliveries. Also, and as shown in fig. 14, this integration has been limited by the level of integration of customer provided functionalities, or third party SW (object code).

From a turn-key project to a high-end specific project, the number of used aggregates can be very different.

Today, any new 32 bit Powertrain project started is build-up with an aggregate structure.

Of course, depending mainly on the system configuration, some parts of the project may be developed specifically, not reusing generic solutions. But for a turn-key project, a complete aggregate structure is used, leading to high reuse levels. In fig. 154, the part "generic conf" means the adaptable parts of the aggregate, knowing that these parts are also under architecture control.