O Grisvard

C Huntzinger

M Le Berre

V Verbeque

Cost-efficient design and production of flexible and re-usable near real-time tactical human-machine interfaces

Keywords: human-machine interface, near realtime, design, cost-efficiency, re-use

Cost-efficient design and production of flexible and re-usable near real-time tactical human-machine interfaces

O Grisvard, C Huntzinger, M. Le Berre, V Verbeque

Introduction

Making complex systems accessible to human operators supposes to design human-machine interfaces (HMIs) that provides the operator with means to manage the complexity of the system in an efficient manner. This is particularly true in the aeronautics domain for tactical command and control (C2) HMIs whose purpose is to present the operator with a synthetic and comprehensive view of the situation and where complexity is present in many dimensions: diversity of sensors, diversity of missions, diversity of environments (aircrafts, ships…), diversity of crew configurations. Current technical requirements, such as being able to display thousands of objects updated every half-second while remaining highly fault-tolerant to ensure stability for the operator under stress, coupled with economic requirements such as manning and cost reductions, make this issue even more crucial.

We present here our approach to the design and production of near real-time tactical HMIs, that enables us to devise HMIs that meet such requirements while being flexible enough to be used in a wide variety of contexts and produced at a reasonable cost. This approach associates rapid prototyping, in order to verify the compliance with user requirements and to identify dimensioning parameters, together with an innovative framework for HMI production based on state-of-the-art architectural patterns and HMI technologies.

We demonstrate our approach with examples of HMIs in the domain of C2 systems for maritime patrol and surveillance. Maritime patrol (military) or surveillance (civilian) consists in embarking operators in the cabin of an aircraft in order to survey coastal waters and identify the mobiles at the surface of the sea for various purposes. The corresponding HMI examples are taken from ongoing industrial programs in this domain.

Managing complexity

In the domains for which we develop mission systems, complexity is present in many dimensions that all impact the HMI. To begin with, there is an intrinsic functional complexity of nowadays C2 systems. For example, a state-of-the-art maritime patrol system is based on the combination of many sensors: radars (classic radar, SLAR -sideways looking airborne radar), TV/IR camera (infra-red), electro-magnetic detection, IFF (identification friend or foe), UV/IR scanner… Consequently, such a system can propose up to more or less six hundred different functions. The functional complexity of the resulting HMI is of course proportional to that intrinsic complexity. C2 systems are used for a wide variety of missions, depending on the domain of application, some of them being common to all domains, such as tactical situation elaboration (TSE), the others being specific to each domain. For example, in the domains we work for, the missions include the following: • Maritime patrol (military): TSE, anti-surface warfare, anti-submarine warfare, joint littoral warfare, targeting for cruise missiles; • Maritime surveillance (civilian): TSE, exclusive economic zone control, maritime traffic control, fishery control, fight against pollution, contraband, piracy, illegal immigration and drug trafficking, protection of installations (offshore, oil rigs, ports…), maritime search & rescue;

• Electronic warfare (military): TSE, radar detection, communication detection, radar jamming, self-protection, electronic intelligence. The mission system must be designed as to support the performance of these various missions, the HMI being the central access point for the operator(s) that must perform them.

Additionally, mission systems are embarked on various platforms with heterogeneous working environments, for example aircrafts, helicopters, frigates or submarines. Each platform has its own set of physical constraints that have a direct impact on HMI design, for example:

• Available room: constrains the ergonomics;

• Lighting: constrains the graphics;

• Movement, vibration: constrains the use of input devices; • … Finally, each domain also brings specific requirements for crew configurations. The number of operators may greatly vary. It ranges from one operator who performs all the work on board a small maritime surveillance plane, to nine operators on board the biggest maritime patrol aircraft, for which the work is broken down among the team members. In addition, the crew configuration may change during the mission, with operators coming in and out depending on the urgency of the situation. The workload has then to be dynamically re-dispatched and the mission system reconfigured accordingly. Additionally, the system must be highly fault-tolerant as to preserve stability for the operator under stress in critical situations. Being the operators' point of entry into the system, the HMI is directly impacted by that aspect of complexity management.

The current economic constraints impose to reduce as much as possible the number of operators. This implies to solve the difficult equation of enabling an ever smaller number of individuals to cope with an ever increasing system complexity. The solution lies in a design of the HMI that will make the functional complexity affordable to the operator, which is not a trivial issue (see [START_REF] Boy | Perceived complexity versus internal complexity. Did we take into account expertise, reliability and cognitive stability?[END_REF] for instance).

Maximising the efficiency of the operator has a direct technical impact as this means to accordingly increase the efficiency of the system while maintaining the standards in terms of reliability. A striking example is the requirements imposed on the HMI for tactical situation management. It is common nowadays to require the processing of thousands of moving graphical objects that are updated on the basis of time intervals inferior to half a second (see Figure 1 for an example of the resulting view). This of course has to be done while preserving the interactivity on these objects, such that there is no perceptible latency for the operator that manipulates them.

Figure 1: A typical tactical situation Table 1 below gives examples of time requirements taken from a real case of a tactical HMI for maritime patrol or surveillance. The terms "near real-time" (NRT) comes from such requirements. Fulfilling these requirements imposes to devise new architectural and technical solutions in order to optimise data processing at each stage of the process, from data production by the sensor to visual rendering of the data on the graphical display. This also results in an increased complexity of the HMI, both at the architectural level and in terms of technical solutions. In particular, tactical HMIs have to perform automatic data fusion from various sensors, merging for example video streams with synthetic objects. Being compliant with NRT requirements in such a context imposes to devise specific architectural patterns. All the dimensions of complexity of mission systems, both intrinsic and induced by their context of use, are reflected in the corresponding design and production process. A great number of actors with quite different profiles play a part in that process: system architects, system engineers, technical experts, software architects, software engineers, software developers, etc. Even the customer is now involved, both through end-users and domain experts. There also an increasing appeal to sub-contracting in order to lower the production costs. Indeed, due to market globalisation, cost reduction becomes mandatory in order to remain competitive. This is another difficult equation to solve, producing systems ever increasing in size and complexity while avoiding the explosion of costs if not actually reducing them.

In the following sections we present the approach that enables us to tackle the issues outlined above that rise from the problematic of near real-time HMI production for complex mission systems. Our approach is based on a precise separation of concerns through a step by step process from the HMI definition to its integration in the system, together with a multi-iterations process, iterating first on definition and prototyping, then on modelling and architecting, and finally on development and test (see Figure 2). The three following sections detail each iteration step of the process.

Rapid prototyping

As mentioned above, one of the main issues of the design of complex systems is to be able to design HMIs that make the complexity of the system affordable to the users. Traditional approaches to system design focus on the system's functions, the HMI being treated as a side task, not being particularly challenging. As a matter of fact, it is still nowadays often heard that HMI design is an easy task and that HMI production should cost nothing. This is a major mistake when addressing tactical command and control systems that are by definition HMI-centric. This has often led to bad HMI design and the rejection of the HMI by the end-users, with consequently important additional costs in order to reach customer satisfaction. This is even more crucial as the complexity of these systems explodes. If one does not allocate sufficient time an effort, the risk is very high to design unusable HMIs. As such, as costs must be kept reasonable, HMI design has to be re-thought completely [START_REF] Sedogbo | Human-System Interaction Container Paradigm[END_REF].

A solution that has proven efficient and affordable in terms of costs is to rely on rapid prototyping to iterate with the end-users during HMI definition in order to ensure the usability of the resulting HMI (see [START_REF] Hardtke | Rapid prototyping for user-friendly and useful human-machine interfaces[END_REF]). The additional initial costs induced by this approach are largely counterbalanced by the costs savings in the production process, as the HMI design is agreed once and for all at the end of the first iteration step. The prototype can then be used as a contract between the customer and the supplier in order to guarantee the end-user that the final HMI will conform to that agreement.

To support the definition step of our process, we have designed a solution for rapid HMI prototyping dedicated to tactical HMIs for C2 systems called SMOCK (for "Smalltalk MOCK-up"). At the prototyping step, the focus has to be put on easing the design and limiting the time required to update that design. Therefore, we have based our solution on the Smalltalk language (www.smalltalk.org) due to its essential property to integrate the model and the code, that has proven particularly suited for rapid code change. Figure 3 shows an example of a tactical HMI prototype produced with SMOCK. • To simulate the behaviour of the HMI and the interactions between the operator and the system, validating not only the graphical design but also the ergonomics of the HMI;

• To mock-up several complete operator positions and to evaluate the whole in a multi-operator environment (see Figure 4 below), easily testing different crew configurations; • To share this vision with all the actors, including the customer, and proceed to light-cost iterations in order to reach an agreement on the HMI definition; • To simulate early dimensioning scenarios, in particular by integrating the calculation of a costmodel in order to evaluate the financial impact of a choice in terms of ergonomics; • To pre-model the HMI architecture, outlining the basic building blocks or components and the interfaces between these components as well as identifying at an early stage in the process the important issues regarding efficiency, resource consumption, data-flows, etc.

Figure 4: A multi-user prototype SMOCK maximises the productivity enabling short iterations with the customer on the HMI definition. As an example, it takes from one minute to change a button up to one day and a half to update about ten panels. With SMOCK, prototyping becomes a lightweight process, as the tool can be installed rapidly on a laptop and frequently and easily updated. Finally, it benefits from additional properties of Smalltalk, for example openness to other technologies, rapid adaptation to any type of platform and compatibility with legacy software.

SMOCK has been used successfully in real-sized programs for maritime patrol and surveillance systems. The images above are taken from one of these programs. One important benefit of SMOCK in terms of cost reduction is that the prototypes developed for a given program can be straightforwardly re-used for another program in the same domain as they do not have to cope with hardware and technical requirements and can be easily and rapidly adapted.

A generic HMI framework

Following prototyping, we find the central steps of the process that consist in modelling the HMI and defining its software architecture. These steps are crucial as they condition the code production process by identifying the building blocks and the principles on which the code decomposition and assembly will be based. They are initiated during the architecture pre-modelling phase of the prototyping step.

Our approach to modelling and architecture falls within the scope of the model-driven engineering (MDE) and model-driven architecture (MDA) methodologies, as established standards for the development of complex software systems (see [4]).

The MDE approach places the model as the centre of the software production process. The model contains the necessary information to ensure the consistency of the source code, the testing of that code, and the associated documentation (see Figure 5). Additionally, following a MDA approach, we also include in the model the architectural patterns that will guarantee both the efficiency of the HMI and the manageability of the HMI code. Model

UML Model

Picture import Test generation

Tests

Automatic non-regression testing

Figure 5: The MDE process for HMI Our approach is implemented as a specific layer dedicated to tactical HMI production (GFL for Graphical Framework Layer) on top of a generic framework for HMI production called JAGUAR (JAva Graphic Unified ARchitecture) developed conjointly with another division of THALES now part of DCNS. JAGUAR/GFL is implemented with up-to-date Java technology (java.sun.com). The models are expressed using the UML standard (www.uml.org), and code generation from the model relies on a direct mapping of the UML class diagram into a Java class hierarchy.

JAGUAR/GFL relies on a component-based approach to HMI architecting. In JAGUAR, components are realised on the basis of JACOMO (JAguar COmponent MOdel), which is a lightweight component model derived from the CCM (CORBA Component Model, see www.omg.org/technology/ documents/formal/components.htm) specification. In JACOMO, components are characterised by the following elements (see Figure 6 below):

• The services they provide (facets) and use (receptacles); • The events they produce (event sources) and consume (event sinks); • A clear separation between their interface and their implementation; • A customisable behaviour using parameters (attributes). A direct consequence in terms of HMI production management is that components provide direct support to:

• The HMI code production organisation with facilitated implementation task distribution and explicit contracts, especially useful when involving subcontracting; • The HMI software validation process with blackbox unitary testing at the level of elementary components;

• The HMI software management with an independence from COTS components (for example the cartographic component) and an optimised re-usability of software components.

Building on the component-based approach, GFL implements a new architectural pattern dedicated to the highly demanding processing of tactical graphical HMIs. This pattern is an enhanced version of the traditional model-view-controller (MVC) pattern for HMIs (see Figure 7). • Independence between the various HMI processes (operator inputs, displays, data updates); • Optimal management of the various HMI tasks;

• Isolation of tasks that are costly in time or in resources. The benefit for the operator is the preservation of the interactivity even in the case of a highly loaded situation such as the one of Figure 8 (page 6).

Relying on that specific architectural solution, we guarantee the following capacities to the operator: • A maximum reactivity on interactions;

• No global slowdown or freezing of the HMI;

• Fault tolerance and robustness to breakdowns.

The quality, the efficiency and the robustness of the HMI is thus maximised, which enables us to ensure the processing of about fifteen hundred tactical objects during six hours of mission consuming only 5% to 8% of the available CPU time. This has been measured on an up-to-date dual-core processor together with a standard video card. Using the JAGUAR/GFL framework, we have developed a library of generic tactical HMI components that can be re-used across programs even in these concern different application domains. Indeed, we have already experimented the effective re-use of components developed for a maritime patrol system in the context of an electronic warfare system with HMIs that have different look and feel but share similar efficiency and interactivity requirements. Capitalisation with JAGUAR/GFL has been evaluated as such:

• 35% of re-use intrinsic to the generic HMI production framework; • 35% of additional re-use of graphical HMI components; • Only 30% of the code remaining to be produced for each specific HMI. These figures clearly demonstrate a high capacity to reduce the costs of HMI production after a first initial development.

Performing validation

As mentioned above, the component-based approach we follow allows for unitary testing of individual components as black-boxes. System-wide testing is also facilitated by that approach as individual components can be tested in the system context using simulation of the other components or even simulation of the software infrastructure. Test productivity is thus increased by the capacity to perform parallel and incremental testing of the HMI during its implementation, not having to wait for the whole HMI to be developed before the validation phase can start. Furthermore, our approach to HMI validation targets the automation of tests, once again in order to reduce the costs. We use the prototype model in order to identify the characteristics of the HMI that must be tested. Test scenarios can be generated from experimentations with the prototype using logs of the operator's actions. These scenarios can then be used by our validation environment to go through all the necessary HMI testing. This environment is currently being implemented in Smalltalk, like our prototyping framework. This will enable us to effectively couple the two in order to implement the test automation process.

Conclusion

We have presented here our approach and process for NRT tactical HMI design and production. Our solution integrates a rapid prototyping tool, a generic tactical HMI modelling and production framework and a validation environment. All the architectural and technical choices we have made have been driven by the need to manage the complexity of such HMIs, while preserving the usability for the operator and limiting the production costs.

We have demonstrated how our approach ensures that end-user requirements are appropriately taken into account, guarantees the efficiency of the resulting HMI and maximises the re-use from one development to the other.

Our current activity is focussed on the automation of tests as described above. The main foreseen perspective to our work is to study a stronger coupling between the prototyping phase and the modelling and architecting steps. The idea consists in re-using the model and the first architecture produced during the prototyping phase as a basis for the production of the final model and architecture of the HMI. This should enable us to save time and efforts for the production of the final HMI model and functional architecture.

Figure 2 :

 2 Figure 2: The HMI design and production process

Figure 3 :

 3 Figure 3: A tactical HMI prototype

Figure 6 :

 6 Figure 6: The component model

Figure 7 :

 7 Figure 7: The MVC pattern

Figure 8 :

 8 Figure 8: The standard load of a tactical view

Table 1 :

 1 HMI response time requirements

	Action	Response time definition	Time
			(sec)
	Window move	From command to resulting display	0.5
	Key press	From key press to visual feedback	0.1
	Key print	From key press to character display	0.2
	Page scroll	From end of request to beginning of	0.5
		text scroll
	X/Y entry	From selection of field to visual	0.2
		verification
	Pointing	From pointing input of to visual	0.2
		feedback
	Sketching	From pointing to line display	0.2
	Local update	Time for updating the screen image	0.5
		with data from the local cache

Code under test

Java code generation

Code execution: display the HMI

Document generation

Java Code

Unified Modelling Language UV/IR: Ultra-Violet/Infra-Red


Claude Gomez
email: claude.gomez@inria.fr

Simone Mannori
email: simone.mannori@inria.fr

Scilab/Scicos: an Open Source Platform for Embedded Real Time Systems Development

Keywords: Scilab, Scicos, embedded systems, real time, multi platform, Open Source scientific software

Complex, heterogeneous, real time embedded applications require sophisticated developments tools for simulation and implementation.

Commercial, closed source applications are available "on the shelf", but the associated financial effort and the limited flexibility are not always compatible with the budget constraints and the technical specifications. Some specific requirements of the embedded applications match very well the intrinsic proprieties of the Open Source software. In this paper we show how Scilab/Scicos can play the role of an Open Source platform for embedded systems by presenting both its development model and its applications.

Introduction

The purpose of this paper is to present how the Open Source platform for numerical computation Scilab/Scicos [1] can be used for embedded real time systems. But as well as presenting the functionalities, we also explain why it is important that this platform be an Open Source platform and which is the corresponding organization of Scilab development.

Figure 1: Open Source trends for embedded.

Why is Open Source important for embedded real time applications?

Today more and more Open Source software is used for industrial applications [2] (fig. 1). This is a new economical model where software is given and business is made by service and support. This has well known advantages for users such as the independence with respect to the vendor, the reduction of recurring costs, the flexibility of use, etc… In the domain of embedded real time applications, there are more arguments for Open Source software:

• Safety. For safety critical applications, the full access to the source code (of the tools and the target's code) is indispensable. Every certification needs code inspection. The release of the code under NDA agreements is not sufficient because of the impossibility of independent evaluations. But the development of Open Source software must be made in a professional way in order to be used by both Academics and Companies, leaving the possibility to be helped by the community of contributors. This is what we show in the following sections.

Scilab until 2007. Development and Structure:

the Scilab Consortium Scilab is used all around the world and there are now about 50,000 monthly downloads from Scilab web site.

Scilab after 2007: Scilab 5 and the non profit organization

We can consider that the 5-year INRIA-hosted Scilab Consortium was the first step for transferring Scilab software made by researchers to Scilab software made by development dedicated team. Now we are starting a second step by two major actions.

New Scilab software

Next Scilab release, Scilab 5, will be available at the end of March 2008. It is the beginning of a new Scilab family and it can be considered as a technological leap:

• Complete cleaning and reorganization of source code.

• New GUI and graphics rendering with Java technology. Modularization is a very important improvement (fig. 4). First it allows easier collaboration with the contributors. Second it allows changing the license: Scilab 5 will be GPL compatible by adopting CeCILL license [3].

Scilab license CeCILL

Free modules: other licenses So Scilab 5 will be Free Software according to the definition of the Free Software Foundation.

Non free modules

It will allow Scilab to be really open software ready for use and collaboration with a big community of users both in Academic world and in Industrial world.

New Scilab structure

Together with new Scilab 5.0, a new organization will take place for Scilab. New Scilab Consortium will be a non-profit organization, following the example of Mozilla Foundation. New Scilab Consortium will be completely dedicated to Scilab and in charge of Scilab development, promotion and support for the members of the organization.

The new organization will be set up before mid 2008 and will play the role of real software publisher.

Generating code from Scilab

Scilab itself can be used as a tool for embedded systems development. This work is done in the European integrated project named "hArtes" funded by FP6 call 5 Embedded Systems Scilab Language is adopted as one of the starting points of the project for C code generation.

For that we are reorganizing the Scilab computational kernel in order to support "visitors oriented" code generation tools.

The work is to create a Scilab to C translator that will generate minimal C code from Scilab scripts (fig. 5). Then it will be possible to put the C generated code in processors such as FPGA or DSP. So Scilab interpreter can be used to easily create the program and then efficient C code is automatically generated.

Scilab/Scicos for Embedded Systems

Scilab-EMB: (Scilab Embedded)

For some complex control applications the presence on the target of the full Scilab/Scicos installation is a reasonable solution. Modern Industrial PCs are fast enough to run Scilab/Scicos in real time but the associated costs and technical limitations (power, heath, etc.) can render this solution inappropriate. Scilab-EMB [5] is the implementation of a full, optimized Linux and Scilab/Scicos integrated installation on an industrial PC based on ARM processor. The ARM processor has sufficient performances at reduced costs with minimal power requirements (50% cost reduction respect a standard industrial PC, no heat sinks, no fans).

Scicos for Embedded Systems

Scicos

Scicos [6] [START_REF] Campbell | Modeling and Simulation in Scilab/Scicos[END_REF] is a Scilab toolbox for modeling and simulation of dynamical systems where continuoustime and discrete-time components are interconnected. Implementing these simulations using only Scilab scripts is possible but is complex and time consuming. Scicos uses a graphical editor where the user can place blocks and connect it with links: the usual "block diagram" control system representation (fig. 6). Scicos includes palettes of standard blocks that cover most of the usual situations found in control applications. The user is free to assemble standard blocks to create custom blocks or write directly the code. The block's code is composed by an "interfacing function" and a "computational/simulation function". The former is used by the editor to interact with the block's internal parameters; the latter is used by the Scicos simulator. Usually, for optimal performances and maximum flexibility, the computational function is written in C code and compiled. The Scilab language is supported for early development, but not suggested for performance reasons (Scilab language is interpreted, slower that compiled C functions). FORTRAN is supported but not suggested for new development. Other language can be easily used if required (e.g. Java using JNI).

Scicos Modelica support

The standard Scicos blocks are "explicit" (oriented blocks): they have inputs and output ports. This representation, typical of the control system's theory, is not capable to directly model "implicit" elements (like electrical components), where each port can be, at the same time, input and output (fig. 7). Scicos use the Modelica [8] representation to implement implicit blocks.

Scicos Code Generation

The code generation [9] was initially developed to accelerate the simulation of complex super-blocks (hierarchical user diagrams composed by many blocks). The code generator integrates the information of the Scicos compiler (that decides the sequence of the calls to each computational function) and the computational function's source code to create a single source file. This file becomes the super-block's computational function. This kind of code generation can be used, with some manual effort, for embedded real time target.

Scicos Toolboxes for Embedded Real Time Systems

Modern software simulation tools have changed radically the development flow of the control for embedded system engineers. Scilab and Scicos can guide the designer to elaborate and optimize complex control strategies but the results must be implemented and tested on real systems. This means doing some tests using the simulator connected to the real -physical -system and producing code to be run on the embedded target. There are several specialized toolboxes in Scicos targeting different specific needs:

• Scicos-HIL (Hardware In the Loop) allows the testing and validation of models and controllers inside the interactive, graphical, Scicos environment.

• Scicos-RTAI is a specific code generator capable to produce standalone hard real time executables under Linux RTAI.

• Scicos-FLEX is another customization of the Scicos code generator for small DSP and micro controller target.

• Scicos-HDL is a simulator and code generator extension for programmable logic circuits application using HDL (High Level Hardware Languages, VHDL and Verilog).

These toolboxes are described below.

Scicos-HIL

Modern PCs are fast enough to simulate complex systems in real time. The main idea behind Scicos "Hardware In the Loop" [10] is to use directly Scicos to simulate part of a control system in close connection with a real one (fig. 8). This kind of "in the loop" simulation can be used to tune a controller or validate a model (fig. 9).

Figure 9: Ball and beam HIL controller.

To implement HIL, it is indispensable to add to the standard Scicos some I/O blocks and some real time functions. Scilab/Scicos provides some system independent "soft real time" capability, but the real performances are very system dependent. This means that the same code can run using different boards from different constructors.

Scicos-HIL on Linux -RT_PREEPT

The "real time pre emption patch" [14] is not yet a Linux standard functionality, but many Linux distributions begin to offer pre-configured kernel. This patch transforms Linux in a real hard real time OS (without loose any compatibility with standard applications) and push the limit of the sampling time to 100 microseconds (real performances are configuration dependent). Probably, next year this hard real time extension will be included in the Linux source code main line and will be adopted by the major distributions (IBM, Red Hat and HP are the main sponsors of this project). We provide a patch to the standard Scilab/Scicos real time functions that detects and uses the hard real time features of RT_PREEPT. 8.2 Scicos-RTAI RTAI (Real Time Application Interface, [15]) is a hard real time extension of the standard Linux kernel. RTAI creates a special class of Linux process and threads (both in kernel and user space). The standard Linux programs continue to run in the "non hard real time" space but can be pre-empted any time by RTAI programs. Using this "dual kernel" mechanism, the maximum latency (for real time applications) is reduced to very low values: with a well tuned machine is possible to push the sampling time to 10 microseconds (the "suggested" minimum sampling time is 40 microseconds). Scicos-RTAI is a custom version of the standard Scicos code generation that includes RTAI for hard real time support and Comedi for I/O interface. With a single click operation, a complex Scicos diagram is compiled to a stand alone Linux RTAI application. Internal parameters control and real time visualization are realized using a RTAI-Lab [START_REF]RTAI-Lab[END_REF] control panel (fig. 10). The latest FPGA devices are sufficiently rich to implement, at cost comparable to "hard-coded" solutions, very complex functions. This possibility opens the door to real "system on chip" realizations where there is only one chip in the system that implements all the functions. Some FPGA are capable to integrate also analog / mixed signal functions (linear amplifier, data converter, etc.). Silicon providers offer free (but not open source) tools for the device configuration (using high level definition languages such as Verilog or VHDL) and digital only simulation tools: these tools are not capable to simulate the full system. Scicos-HDL [START_REF]Scicos-HDL[END_REF] is an extension for Scilab/Scicos to the world of digital design. It includes palettes of the standard combinatorial and sequential digital basic blocks, a palette of IP-CORE blocks and a Scicos-HDL specific palette of tools (fig. 13).

Figure 13: Scicos-HDL main palette.

Using Scicos-HDL is possible simulate the full analog, mixed-signal, digital system. Scicos-HDL includes an automatic code generation tool capable to produce Verilog or VHDL code for the "digital only part" of the simulation (fig. 14). This code can be "cut and pasted" inside the compiler that produces binary configuration file for the physical devices.

In the actual release (0.50), Scicos-HDL is capable to simulate at reasonable speed only small/medium complexity circuits. For the simulation phase, standard Scicos functions written in Scilab or C language are used. These simulation functions are not optimized for speed. For next releases we are working on the integration of the GHDL compiler inside the Scicos simulator. GHDL [START_REF] Ghdl | [END_REF] is a native VHDL compiler based on the GNU-GCC structure. GHDL is capable to translate VHDL code in an optimized shared library usable for simulation. This kind of integration (still in development) opens the way to multithread co-simulation inside Scicos, with evident advantages of speed on multi cores and multi processors PC. We are integrating the GHDL produced shared libraries as separate, independent threads using semaphores for the synchronization.

Conclusion

The Open Source software can be a valid alternative to closed source solution, not only for economic reasons but also for intrinsic flexibility of the development model that matches most of the technical challenges of the embedded world.

Figure 2 :

 2 Figure 2: Scilab Consortium model. Since 2003, Scilab Consortium and the dedicated team have made Scilab versions and Scilab promotion in the world. The latest Scilab version is

Figure 3 :

 3 Figure 3: Scilab in action.

Figure 4 :

 4 Figure 4: Scilab 5 modular architecture.

  [4]. The aim of the project is to build a heterogeneous development platform for embedded system. The complexity of future real-time embedded systems for consumer and professional products is becoming too big to design monolithic processing platforms. "Monolithic" means based on single hardware and software architecture (e.g. micro-controller with C compiled code). "Heterogeneous" means based on different, mixed and interconnected, hardware and software architecture like DSP, micro-controllers, FPGA, ASIC, general purpose processor, etc. that requires different programming languages and development tools.

Figure 5 :

 5 Figure 5: From Scilab script to C code.

Figure 5 :

 5 Figure 5: Scilab EMB. The full documentation of the project it is available on the web site [5]. The porting procedure is fully based on multi platform open source tools. With minimal effort, it is possible to use the porting guide for other hardware architectures (PPC, MIPS, OMAP, etc.). For hard real time application, a patched Linux kernel version will be available. The use of a platform different from x86 offer another advantage: improved immunity from virus. Scicos-EMB is developed by professor Ma Longhua and Zhe Peng the Zhejiang University (China).

Figure 6 :

 6 Figure 6: Typical Scicos diagram.

Figure 7 :

 7 Figure 7: Scicos Modelica (electrical) diagram.

Figure 8 :

 8 Figure 8: Ball and beam demo model.

8. 1

 1 .1 Scicos-HIL on Windows Soft real time support under Windows is limited to 20 milliseconds as minimum sampling time. The I/O support is realized using the library provided from Measurement Computing [11]. Under Windows, each I/O board constructor provides a custom library. Hard real time under Windows is possible only using expensive, closed source, patches. 8.1.2 Scicos-HIL on Linux Recent Linux kernels (2.6.2x) [12] offer "near hard real time" performances for sampling time up to one millisecond. The Comedi [13] project offers a complete set of I/O drivers (more than 200 models) and a unified library. Comedi offers advanced functions for board inspection and configurations.

Figure 10 :

 10 Figure 10: RTAI-Lab control panel.RTAI Lab and the standalone executable exchange real time data using a custom UDP protocol via Ethernet network. The same Ethernet connection can be shared between RTAI applications and standard Linux applications (e.g. video conferencing, see fig.10). RTAI-Lab requires a Linux-RTAI equipped PC: RTAI-XML [17] is a client/server application that replicates the RTAI-Lab virtual instruments and control panels in a Java enabled web browser (Java RTAI Lab, fig.11).

Figure 11 :

 11 Figure 11: JRtaiLab control panel. Before "RT_PREEPT", RTAI was the only hard real time open source option for Linux. RTAI is an open source project lead by Paolo Mantegazza (Politecnico di Milano, Italy). Scicos-RTAI is a project developed and maintained by Roberto Bucher in collaboration with the INRIA/Scilab Consortium and the RTAI Team. 8.3 Scicos-FLEX Most of the usual Scicos embedded applications are closed loop controls: using a full PC to implement them can be a real waste of resources. A microcontroller/DSP is a better solution from many points of view, but the development of micro-controller/DSP control applications is expensive in terms of time and hardware and software tools. Recently, microcontroller and DSP silicon providers give free tools (integrated development environment, assembler, C compiler, libraries, etc.), but the coding is still very time consuming because the programmer is responsible of all the fine details like I/O management and real time support. Practically, this means that most of the development time is "lost" for the low level device management and not invested in the real customer's application. Scicos-FLEX [18] is the combination of: • a custom code generator and specific palettes of Scicos blocks • a real time OS optimized for microcontrollers (ERIKA) • an integrated environment (RT-DRUID) based on Eclipse • a development board. The control loop are designed and simulated with Scilab/Scicos; when the simulation is ready, the code is automatically generated, compiled, linked with the operating system and downloaded on the target board via USB connection (fig 12).

Figure 12 :

 12 Figure 12: Scicos-FLEX development flow.The same USB port can be used to monitor and remotely control the internal parameters of the running controller on the target (fig.13).

Figure 13 :

 13 Figure 13: Scicos-FLEX (light) board. Scicos-FLEX is a joint development of the INRIA/Scilab Consortium, Roberto Bucher (code generation tools) and Evidence (real time OS, integrated development environment, hardware support). 8.4 Scicos-HDL

Figure 14 :

 14 Figure 14: Scicos-HDL diagram.

  Scicos-HDL is developed by Zhang Dong and Kang Cai (Ningxia University, LIAMA, China Institute of Automation, Chinese Academy of Sciences) in close collaboration with the INRIA/Scilab Consortium.


Jean-Raymond Abrial
email: jabrial@inf.ethz.ch

A System Development Process with Event-B and the Rodin Platform

Keywords: Formal method, Event-B, Industrial process, Modelling tool

The aim of this presentation is to show that the Event-B technology can be put into practice. For this, we must follow a well defined development process. That process is precisely the one which has to be transferred to industry. The Rodin platform, in its final form, will be the supporting tool for achieving this. Before describing the Event-B development process however, we make precise what we mean by an industrial development process in general terms.

EVENT-B

Event-B [START_REF]Modelling in Event-B: System and Software Engineering[END_REF] is the name of a mathematical (set-theoretic) approach used to develop discrete system models, be they computerized or not. It is the successor of the B Method [START_REF] Abrial | The B-Book: Assigning Programs to Meanings[END_REF], which has been used in various operational industrial projects [START_REF] Behm | Meteor: A successful application of B in a large project[END_REF] [START_REF] Badeau | Using B as a high level programming language in an industrial project: Roissy val[END_REF]. Event-B has been strongly influenced by the work of the Finnish School on Action System [START_REF] Back | Decentralization of process nets with centralized control[END_REF] [START_REF] Butler | Stepwise Refinement of Communicating Systems[END_REF].

It has been found over the years that a unique paradigm, that of discrete transition systems, was the common denominator to apparently very different computation mechanisms: sequential, distributed, concurrent, parallel, etc.

THE RODIN PLATFORM

The Rodin Platform [START_REF]Tools for Constructing Large Systems (a proposal)[END_REF] [4] [START_REF] Butler | Hallerstede The Rodin Formal Modelling tool[END_REF] [START_REF]Rodin Platform[END_REF] is an open tool set implemented on top of Eclipse [10]. It is devoted to supporting the development of such systems. It has been developed within the framework of the European project Rodin [START_REF]Rodin Project[END_REF].

It contains a modeling database surrounded by various plug-ins: static checker, proof obligation generator, provers, model-checkers, animators, UML transformers, requirement document handler, etc. The database itself contains the various modeling elements needed to construct discrete transition system models: essentially variables, invariants, and transitions.

FORMAL DEVELOPMENT

With the help of this palette, users can develop mathematical models and refine them. In doing so, they are able to reason, modify, and decompose their models before starting the effective implementation of the corresponding systems. Such an approach is well known and widely used in many mature engineering disciplines where reasoning on a abstract representation of the future system is routine. Just think of the usage of blueprints made by architects within a building construction process.

TECHNOLOGY TRANSFER

One of the main difficulties in transferring this technology is not that of its mastering by industry engineers (a common opinion shared by many analysts). It is rather, we think, the incorporation of this technology within the industrial development process. We believe that the above argument about the difficulty of mastering this technology is, in fact, a way of hiding (consciously or not) the one concerning the incorporation within the development process.

INDUSTRIAL PROCESS

It is now common practice among important critical system manufacturers (train signalling system companies, avionic and space companies, automotive manufacturers, power system designers, defense sector industries, etc.) to embark in important projects within the framework of a well-defined development process. Such a process contains the definition of the various milestones encountered in the system construction together with the precise definition of what is to be done between these milestones, by whom, and within which delays. It also contains different ways of re-iterating on these milestones in case the process encounters some difficulties.

Usually, industrial managers are very reluctant to modify their development processes because: (1) it is part of their company culture and image, (2) it is difficult to define and make precise, and (3) it is even more difficult to have them accepted and followed by working engineers.

In order to know how to modify the development process due to the introduction of some formal method technology (Event-B and Rodin) in the construction of complex systems, it is clearly very important to understand that this process is aimed at obtaining systems which can be considered to be correct by construction. This presentation does not pretend to solve all related problems nor to give the key to a successful incorporation of formal methods in industry: it aims at providing the beginning of a systematic way of envisaging these matters.

Let us now briefly present the Event-B development process and show how the Rodin platform supports it.

THE REQUIREMENT DOCUMENT

After the initial feasibility studies phase which is not subsequently modified, the second phase of the process is the writing of the requirement document. It must be pointed out that most of the time such documents are very poor: quite often, they just contain the pseudo-solution of a problem which, to begin with, is not stated. Our opinion is that it is very risky to proceed further with such poor documents. More precisely, we think that it is necessary to rewrite them very carefully in a systematic fashion. Each requirement must be stated by means of a short English statement which is well recognizable and clearly labelled according to some taxonomy to be defined for each project.

The Rodin platform in its final form will provide a plug-in able to support the gradual construction of such structured requirement documents, to retrieve them, and to form the initial basis of the necessary traceability.

THE REFINEMENT STRATEGY

The next phase consists in defining a temporary refinement strategy. It contains the successive steps of the refined models construction. Clearly, it is out of the question to construct a unique model taking account of all requirements at once. Each such refinement step must give a reference to the precise requirements, stated in the previous phase, which are taken into account. A preliminary completion study can be performed in order to ensure that no requirements are forgotten. The refinement strategy in this phase is only temporary as it might be reshaped in further phases.

The Rodin platform in its final form will provide a plugin able to support the writing of the refinement strategy and to check that it is correctly linked to the requirement document.

REFINEMENTS AND PROOFS

The next phase is divided up in many sub-steps according to the precise strategy defined in the previous phase. Each sub-step is made of the definition of the formal refinement which is performed, together with the corresponding proofs. It might be accompanied by some model-checking, model testing, as well as animations activities.

The three previous activities are very important to be performed at each refinement sub-step as they help figuring out that some requirements are impossible to achieve (or very costly), whereas some other had been simply completely forgotten. In other words, these activities help validating the requirement document. The outcome of these activities (checked or tested properties and model animations) can be seen and understood by the "client", who is then able to judge whether what has been formally modeled at a given stage indeed corresponds to what he had in mind. Notice that in each refinement sub-step, it might be found also that the previous refinement strategy was not adequate so that it has to be modified accordingly.

The Rodin platform provides the core elements able to support this central phase: modeling database, proof obligation generator, and provers. The surrounding plug-ins (model-checker, animator, UML translator) support the other requirement document validation activities

DECOMPOSITION

The next phase proceeds with the decomposition of the refined model obtained at the end of the previous one. In particular, this decomposition might separate that part of the model dealing with the external environment from that part of the system dealing with the hardware or software implementation. The latter part might be refined in the same way as it was done on the global model in the previous phase. This refinement/decomposition pair might be repeated a number of times until one reaches a satisfactory architecture.

The Rodin platform in its final form will provide plugins to support and prove that proposed decompositions are correct.

CODE GENERATION

The final phase consists in performing the various hardware or software automatic code generation. The Rodin platform in its final form will provide plug-ins to perform these translations.

CONCLUSION

As can be seen the incorporation of these phases within an existing development process is certainly not an easy task. An important point to take into account is the incorporation (and measurement) of the many proofs which have to be performed in order to be sure that the final system will be indeed "correct by construction". The Rodin project, as described here, will be extended with a new IP European FP7 Project named DEPLOY starting in February 2008.


H Heinecke

M Rudorfer

P Hoser

C Ainhauser

O Scheickl

Enabling of AUTOSAR system design using Eclipse-based tooling

Keywords: AUTOSAR Tooling, AUTOSAR-Based Development Platform, Eclipse, AUTOSAR quick start 1

AUTOSAR is a development partnership for standardisation of software architectures for the development of complex E/E systems. The software configuration process specified by AUTOSAR involves the handling of large amounts of data describing the E/E system. An efficient application of the process requires good and continuous tool support.

In this paper we propose an approach for AUTOSAR tooling, which is based on the technology and, more important, on the idea of Eclipse. Eclipse is one of the most successful open source projects of the last years with a strong influence on the industry. It provides an open development platform that can easily be extended. On top of Eclipse, the approach provides an open tool basis, which can be extended by special, free or commercial plug-ins. Our AUTOSAR tooling approach is oriented towards the ideas behind Eclipse and focuses on reusing the success factors for a tool approach within the AUTOSAR community.

Introduction

Today's automotive system development is getting more and more complex because of several reasons (e.g. exponential increase of automotive functionality, restricted package envelope) [START_REF] Heinecke | Automotive system designchallenges and potential[END_REF]. To handle this complexity, the automotive industry has launched AUTOSAR, a development partnership for standardisation of E/E architectures. AUTOSAR specifies a highly configurable software architecture for Electrical Control Units (ECU) in the automotive domain [START_REF]AUTOSAR development partnership[END_REF]. The configuration process of the architecture's software modules involves the handling of large amounts of data describing the E/E system. Thus, for an appropriate application of AUTOSAR, a good tooling, which supports the users in handling all the configuration data during system development, is required. BMW Car IT has gained already a lot of experiences in this area by implementing a tooling prototype named Orpheus [START_REF] Salzmann | Erfahrungen mit der technischen Anwendung einer AUTOSAR Runtime Environment[END_REF]. Based on the experiences collected at BMW Car IT, this paper introduces a novel tooling approach that promises to satisfy most of today's and tomorrow's AUTOSAR tooling requirements. The so-called AUTOSAR-Based Development Platform (ADP) has to be handled like an open tool framework, however limited to AUTOSAR members and partners only. Due to the fact that the AUTOSAR partnership comprises more than 100 partners and members, the layout equals to an open source activity, limited to the somewhat smaller world. ADP shall provide as an initial donation the basic functionality every AUTOSAR tool suite needs (importing/exporting AUTOSAR templates, AUTOSAR meta model implementation etc.). The entire basic functionality (as depicted in Fig 2) is open to every member in the AUTOSAR development partnership and is continuously improved by contributions of the partners. On top of the basis, tool developers can provide their area of expertise in terms of pluggable extensions, released either as free or commercial products. In the following sections we give a brief overview of the proposal for the promising approach. Section 2 sums up the AUTOSAR methodology. Section 3 gives the reader a survey of Orpheus and our gained experiences with AUTOSAR tooling. Section 4 introduces the motivation and the concept behind ADP and reflects the impact such a tooling platform has on the AUTOSAR development partnership.

2

The AUTOSAR methodology Aside from the software architecture itself, AUTOSAR specifies the methodology for configuring the architecture. Each of the software modules in the AUTOSAR architecture can be configured and are partially generated. This way the software can be tailored for the special needs of the target ECU it is used on. Fig 1 shows the data flow of the configuration process, which mainly consists of the following four steps.

System Configuration

In the first step, the system as a whole is being described and configured. In this step the topology of the hardware is described as well as the used application software components and their deployment on the ECUs.

Extraction of ECU specific information

The overall system description is being split into several smaller descriptions. Each of those descriptions only contains the information needed for configuring the AUTOSAR architecture for one ECU.

ECU Configuration

The information extracted from the system description is enriched with additional ECU specific information. This additional information is ECU specific in the sense that it only affects one dedicated ECU. This could be for example the size of a buffer or the diagnosis functionalities supported by the ECU.

Code Generation

With all the information in place, in the final step the code for the AUTOSAR architecture's software modules is generated and deployed on the target ECU.

The shown process steps indicate, that a lot of configuration and generation tasks have to be done. Handling this process in an efficient and consistent manner, requires an adequate tooling support for the described steps. This means, that the appropriate usage of AUTOSAR in series production strongly depends on the availability of appealing AUTOSAR tools.

Orpheus -AUTOSAR tooling prototype

Orpheus is an AUTOSAR tooling prototype developed at BMW Car IT in the early stage of the AUTOSAR specification. In the following, we give a brief overview on Orpheus and, in particular, the experiences we collected. More details on the tool can be found in [START_REF] Salzmann | Erfahrungen mit der technischen Anwendung einer AUTOSAR Runtime Environment[END_REF].

Motivation

After the initial phase, the specification of the AUTOSAR methodology had reached a state where it was ready for approval. In order to verify the feasibility of the specified process it needed to be applied to an example project.

In this first proof of concept the configuration and generation of one module of the AUTOSAR architecture was realised. The module chosen was the Runtime Environment (RTE), which is the communication middleware of the AUTOSAR architecture.

In such an early phase no AUTOSAR tools were available on the market. Orpheus was developed to fill this gap for the concept proof. Another intention of Orpheus was to give AUTOSAR users a first impression of how ECU development with AUTOSAR could be.

Technical background

Orpheus is an Eclipse-based tooling prototype. On top of this basic functionality, Orpheus provides some sophisticated features (e.g. the RTE generator) [START_REF] Salzmann | Erfahrungen mit der technischen Anwendung einer AUTOSAR Runtime Environment[END_REF].

As Orpheus is a proof of concept, it does not cover the whole range of the AUTOSAR methodology. Nevertheless, with the comfortable extension and adoption mechanism provided by Eclipse, Orpheus can be extended easily with new features, that are currently not supported by AUTOSAR. On the one hand, the tool is continuously extended by additional plug-ins (e.g. a Timing plug-in for the verification of the timing behavior of the developed system), on the other hand the AUTOSAR-compatible meta model of Orpheus is used to analyse, develop and to introduce new meta model features and concepts.

Experiences

The technical background section has shown the outstanding applicability of Eclipse as tool basis, since it provides a lot of desirable features (e.g. core functionality, extensibility, adaptability, …)

1 . Despite the tool basis, we had to implement a lot of AUTOSAR-specific basic functionality as listed in the functional overview section (e.g. persistence mechanism, input/output, core meta model, editors, …). Prototyping a first AUTOSAR RTE generator showed us, that a lot of core AUTOSAR functionality had to be implemented, before reaching the real development task. So, this fundament was needed as a prerequisite to provide the actual functionality (e.g. RTE generator). This means, that only when this basic functionality is available, the user can exploit his area of expertise (see Fig 2). Keeping this observation in mind, we analyse now the experiences gained from developing the basic functionality:

The basic functionality was implemented by a small group at BMW Car IT. These plug-ins were only written as proprietary developments. Therefore, the developers had only feedback from a restricted user group. For example we developed some graphical editors to model AUTOSAR entities. Those editors were good for small scenarios, but, as we realized much later, were not usable for big projects. If we published those editors earlier, we would have received user feedback and could have improved them, or, even better, some other person would have improved the editors and contributed them back to the community, which means, back to us. Obviously, this limited feedback had impact on the speed to reach quality and maturity of the tool. As the resulting software was not shared with others, the effort that was spent on providing the basic functionality was only exploited BMW internally. Redundant development of similar functionality had to be done by several other AUTOSAR tool developers elsewhere. For example we had to implement a mechanism to read and write the AUTOSAR templates from and to XML. We are almost sure that in a lot of other companies, people developed the exact same functionality in a similar way. So, if we had published those Readers/Writers to the AUTOSAR community, a lot of duplicate work could have been avoided. Joining forces on the implementation of the basic functionality would have speed up the development of the overall tool.

The experiences described above (no community and therefore little feedback, redundant development) reveal that the development of the basic functionality was associated with some hurdles, decreasing the implementation quality and speed.

The next chapter now illustrates a promising approach, which caters to the above-mentioned issues. As a relation between Eclipse and the basic functionality of Orpheus was discovered before, the new approach exploits the Eclipse success factors in order to absorb the identified issues of Orpheus and, in general, of AUTOSAR tools.

ADP -AUTOSAR-Based Development Platform

Definition

In this chapter we propose a novel "Open" Tooling approach. The term "Open" in the context of this paper is defined as a common core platform that is open within the AUTOSAR community, not to the general public. The limitation is mandatory due to contractual regulations within AUTOSAR. However, because AUTOSAR is already a large partnership (with more then 100 partners and members), this restriction does not reduce the benefits of an "open source" strategy.

Situation today

Orpheus was one of the first developed AUTOSAR IDEs and gave a first impression of how such a tool could look like, but was never planned to become a series tool and only covers a subset of the AUTOSAR functionality. Since then, several tool vendors introduced their products to the market. However, there is currently no tool chain available which provides the complete required functionality. One of the reasons for that is, that the AUTOSAR methodology implies the handling of large amounts of information describing the E/E system. Another difficulty for tool vendors is that different OEMs with different specific needs, for example features to cope with legacy systems, force them to implement different custom-made additions to their tools, which are quite time consuming. Additionally, today's tools are proprietary and not open which prevents extension by third parties or the customer himself.

In the following, an approach that considers and neutralizes those reasons will be presented

Exploiting the Eclipse success story

Eclipse is one of the most successful (open source) projects around.

It is an open development platform for almost every kind of Rich Client Software with a large community that builds and supports it.

The key benefit of Eclipse is its extensible architecture that is based on the usage of plug-ins.

Eclipse consists of a small kernel and a set of basic plug-ins that provide functionality that is needed by many users. Eclipse can be extended by writing custom plug-ins, which bring new functionalities to the platform.

As Eclipse is such a convenient starting point for developing applications, more and more people use it, extend it, and themselves contribute their extensions back to the community, so that the Eclipse core grows in functionality and quality. Those success factors of Eclipse could be applied to an Open AUTOSAR Tool Framework as well. For such an approach, some requirements have to be fulfilled. We need an open tool basis that is used by a large number of developers. This basis has to provide a set of core functionalities, needed by almost every AUTOSAR tool. The core platform has to be extensible in order to add custom functionality. Fig 3 shows the effort needed for developing AUTOSAR tools with and without such a common AUTOSAR development platform. Last but not least, it needs a community. Such a community cannot be created or established. This community has to form itself because of the benefit that such an approach has.

The following sections outline a rough idea, how the structure of an AUTOSAR-Based Development Platform could look like and some thoughts on the open platform, extensibility and community.

It leaves and creates enough headroom for free as well as commercial extensions of the core functionality. It is a chance rather than a threat to commercial tool vendors as they can focus on their expertise and are freed from coding the same basic functionality over and over again.

Structural Overview

The The MDSD Layer provides rudimentary concepts and functionality needed for building a Model Driven Software Development (MDSD) tool. The services located in the MDSD Layer provide mechanisms for loading, saving, accessing, manipulating and validating models. For most of these mechanisms, the core functionality is already available in today's Eclipse distributions:

MDSD Layer AUTOSAR Layer Custom Layer

• Ecore for designing the meta model

• OAW for code generation • EMF for persistence mechanism • GMF, GEF for graphical editors • OCL for model validation The concepts and functionalities are not specific to AUTOSAR. They build the basis for the AUTOSAR specific services in the AUTOSAR Layer and for custom services, which reside in the Custom Layer.

On top of the MDSD layer the AUTOSAR Layer is located. It provides plug-ins, which extend the basic services of the MDSD Layer with AUTOSAR specific services. The core plug-in is the meta model plug-in, which provides an implementation of the most recent AUTOSAR meta model. Further plug-ins provide functionalities of reading and writing AUTOSAR conform XML files, validating an AUTOSAR model and viewing AUTOSAR models. The AUTOSAR Layer makes use of various AUTOSAR specifications. This is the reason why the usage of the AUTOSAR-Based Development Platform has to be limited to AUTOSAR partners and members only (see 4.1).

The Custom Layer is the layer where the actual tool functionality is located. These functionalities can access and build on the services provided by the MDSD and AUTOSAR Layer and are not part of the tool basis. They are implemented by tool vendors or even might be implemented by the ECU developers themselves if some OEM specific proprietary extension is needed. Examples for custom plug-ins provided by tool vendors would be a configurator for an AUTOSAR module or any fancy editor with sophisticated support for editing AUTOSAR models.

The three layers mentioned above represent the architecture of the proposed approach. In the following sections, the benefits of such an approach will be illustrated and discussed.

Open Tool Basis

As the success story of Eclipse suggests, an open tool basis that is used by a large number of users is required. The basis should provide basic functionality that most of the tool developers need before they can provide their expertise. The section before has depicted the basic functionality such an open tool basis should contain.

With the help of this basis a lot of benefits can be exploited. Firstly, not every tool developer has to implement the basic functionality on his own; redundant implementation can be avoided. The developers can concentrate their effort on their area of expertise and extend the basis. This leads to an increased tool development speed and quality. Furthermore, the platform has great benefits for tool developers as well as end users:

For a tool developer it is attractive because it lowers the initial hurdle of entrance to the AUTOSAR tooling market. They can immediately start to work on their area of expertise and do not need to implement first the basic functionality offered by the basis.

For the end users of the tool, like ECU developers, the open basis lowers the hurdle of entrance of AUTOSAR since they have a free and immediate access to it. This results in a better integration of AUTOSAR into the corporation's processes. The open tool basis is an auspicious approach to resolve current issues in the system development tooling chain. The basis represents a kind of interface for every extension. Therefore the interoperability between the different extensions is easy to manage and the coupling between them can be performed without time loss.

As the section before has depicted, the meta model plug-in is one of the core plug-ins provided by the basis. It is an implementation of the most recent AUTOSAR meta model. Hence, the AUTOSAR-Based Development Platform is always synchronized with the AUTOSAR specification and the migration to new releases is made centrally in one plug-in. This agility allows furthermore an early validation of new releases, because it is immediately in use. In the end, the common basis platform is also useful for the communication across development partners. Misunderstandings caused by the usage of different tools can be avoided and increase therefore the effectiveness of communication between development partners.

Extensibility

Having this open tool basis with its core functionality brings us to the next point -extensibility. There are various reasons or scenarios for an extension of the core: Providing special functionality or replacing core functionality by sophisticated, improved functionality: An RTE generator is an example that we do not see inside the core platform. A party that specializes on RTE generator can provide them as a plug-in. Another party specializes on graphical editors with supreme usability, good performance. Although the open tool basis contains a simple SWC editor, users may decide to buy and use those sophisticated graphical editors without having to abandon the rest of their tool chain.

• Adding functionality on top of AUTOSAR: Another party may be specialized in a certain field of research, for example timing analysis and wants to port their product to be compatible with AUTOSAR. They can use the ADP and build their software on top of that. They can improve and sell their product without spending time on reimplementing the AUTOSAR core. • Adding configuration tool for special AUTOSAR software, e.g. a single AUTOSAR BSW component: Yet another software party is selling AUTOSAR basis software components. Those BSW components have to be configured, using part of the information that is present in the AUTOSAR model. The can write a small configurator plug-in that is integrated into ADP. • Self-made plug-ins for project specific requirements: In a ECU project where AUTOSAR is used, some modeling steps have to be performed over and over again. This is timeconsuming and error-prone and could be automated. Scripting comes to ones mind. Instead of writing a script in a special scripting language, one could also implement this as a simple plug-in on top of ADP.

• Adding OEM specific functionality, e.g. connectivity: Last but not least, a lot of OEMs and Tier-1s have special requirements when integrating the whole of AUTOSAR into their companies' processes and backend-systems. This integration is so company specific that it can and will never be addressed by the AUTOSAR standard. This connectivity to proprietary backend systems could be realized as OEM specific ADP plug-ins.

All those examples show how extensibility can improve the benefit of the overall platform. Those extensions can be either free, part of another commercial product or a commercial product itself. Core functionality is implemented once and is reused. This frees resources to concentrate on the area of expertise. Migration scenarios are addressed, as proprietary parts of the tool-chain can be used in the first place, later replaced by standard-conform plug-ins without having to change the rest of the tooling. The possibility, to exchange certain plug-ins opens the market for a competition on plug-in level, not on the whole tool suites. This allows the user to select the plug-ins which are best suitable for him (freedom of choice) and allows the tool vendor, to differentiate on quality and development speed from his competitors.

Large Community

A vital factor for the success of Eclipse as a tooling platform is the active community that evolved around it.

Challenges and Prerequisites of ADP

The previous sections have discussed some thoughts regarding the AUTOSAR-Based Development Platform. They outlined the potentials and benefits of such a framework. However, in order to introduce the ADP some challenges have to be faced and prerequisites have to be fulfilled. As a very important prerequisite of the platform, a group of interested parties must provide the tool basis as an initial donation. Every member of the community needs this basic functionality before they can start with developing tool extensions for their own area of expertise. One of the greatest challenges ADP has to face is the reaching of a critical mass of active participants. Only if a certain amount of participants establish, maintain and extend the tool basis, the platform can reach the required quality and maturity. In order to permit an appropriate development of the platform, some prerequisites concerning the infrastructure of the development environment must be fulfilled. For example, an issue tracking system (e.g. bugzilla, jira), collaboration tools (e.g. cvs, svn) and bulletin boards are needed for those infrastructure issues.

Conclusion

In this paper we propose the approach of an open development platform for AUTOSAR tools. The platform shall provide basic functionalities common to all AUTOSAR tools (importing/exporting AUTOSAR templates, AUTOSAR meta model implementation etc.). It can be freely used by the partners and members of the AUTOSAR development partnership. We propose not only to base the AUTOSAR development platform on Eclipse but also to apply Eclipse's success factors to it. Similar to Eclipse the ADP shall provide an open and extensible architecture. This leads to an increase of the development speed for AUTOSAR tools. Furthermore, it eases the creation of a continuous and homogenous tool chain. Another important aspect of our proposal is the exploitation of Eclipse's most vital success factor: its large community. The community helps Eclipse to continuously improve its quality and extend its functionality. Applying this success factor implies encouraging actively the growth of a large community around the AUTOSAR development platform and maintaining it. As desirable all these advantages are, they will not come all by themselves. The initiation of such an open development platform faces some challenges. The most obvious challenge is reaching a critical mass of interested partners who commit themselves to the idea and support it actively. However, as the success story of Eclipse has shown, once the critical mass of interested parties is reached, the benefits and advantages to the community are numerous and overweigh the initial efforts. Summarizing, ADP is a proposal for applying the Eclipse success story to the AUTOSAR tooling environment in order to provide AUTOSAR users with the tools they need.

Fig 1 -

 1 Fig 1 -AUTOSAR Design Flow

Fig 2 -

 2 Fig 2 -The area of expertise on top of the tool Reflecting about the basic functionality indicates an interesting relation to Eclipse: Eclipse represents a fundament for application development in general. The basic functionality of Orpheus represents a fundament for a specific application development, namely for AUTOSAR tool development.

fFig 3 -

 3 Fig 3 -Common tool basis on top of Eclipse

  basis for the AUTOSAR-Based Development Platform is Eclipse with its plug-in mechanism. As illustrated in Fig 4, the architecture of the development platform defines three layers on top of Eclipse.

Fig 4 -

 4 Fig 4 -The structural overview of ADP

Already in the early stage of Orpheus (2004) Eclipse and its technology were a good choice for a tool basis. Actual Eclipse releases are even more attractive since the technology has been enhanced successively (e.g. GMF).


S Eberle

E Fourgeau

Built-in Interoperability and Scalability of an Eclipse-based AUTOSAR Tool Platform

Keywords: AUTOSAR, Eclipse, Tool Platform

The automotive industry is experiencing a major paradigm shift by introducing their next generation embedded software engineering standard AUTOSAR. This does not only create a need for new tool environments supporting AUTOSAR-based electrical & electronics (EE) system design but also requires these tools to be open, customizable, and highly interoperable. Eclipse is a promising platform for realizing such engineering environments and delivers many of the necessary basic building blocks.

Introduction

The worldwide value creation in electrical & electronics (EE) systems in automotive industry reached estimated €127 billions in 2002 and should amount €316 billions in 2015 according to a Mercer study. In less than 2 years from now, software will make up an estimated 40 percent of this value creation. The considerable and increasing complexity of automotive software systems, their huge economic relevance as well as the increasingly stringent requirements on software dominant innovations in relation to comfort, safety, fuel economy, emission reduction, and onboard diagnostics have been pushing the automotive industry toward novel engineering solutions for EE architectures, such as the AUTOSAR software standardization initiative, with major consequences for EE processes and tools and new ways of sharing development and exploitation tasks.

AUTOSAR, with contributions coming from the entire automotive development chain (OEMs, suppliers, tool manufacturers, semiconductor manufacturers, software houses), has set itself the goal of developing an open, standardized EE architecture concept for the automotive industry, with some distinctive principles, such as the scalability and transferability of functions, leading to standardized software interfaces and descriptions in terms of XML file formats (see figure 1).

Figure 1: The AUTOSAR Architecture However, the design of automotive systems at large, and moreover of built-in AUTOSAR systems, demands continuous exchange of data between different parties. In addition, appropriate tools are required supporting each of the interlaced development steps which are implemented by OEMs together with their suppliers and integration partners. The mere existence of a standardized XML-based data exchange format doesn't guarantee seamless interoperability which is required to fulfil the needs of architecture-oriented development processes (see figure 2). In addition to the interoperability of commercial offthe-shelf tools, a prominent compelling reason for such an open platform is the need for customers to develop dedicated, i.e. use case, workflow and company-centric tools that are tightly linked to the custom processes used by each stakeholder in EE system development cycles (OEMs and suppliers alike). An open platform enabling close integration of off-the-shelf and custom tools will ease the setup of such dedicated tool environments and help to cover specific requirements along the development cycle.

Need for Openness and Ease of Use

Even though AUTOSAR defines common concepts for EE architectures and parts of the underlying development processes, there are many aspects of the development cycle which are not covered. On the one hand there are design activities which are not addressed by AUTOSAR standard such as the concrete function and behaviour of components, dependencies between configuration parameters of AUTOSAR basic software, etc. On the other hand AUTOSAR is more or less limited to EE system design and doesn't provide much advice on the development steps before and after design, e.g. requirements management and tracing, incorporation of timing and safety constraints, simulation, test, etc. So, it's up to each OEM and supplier to come up with appropriate concepts and processes for those aspects. And as usual when things are done off-standard, the resulting concepts and processes appear to be fairly different in each organization and therefore can be considered domain-specific. These facts have an important impact on the question how to provide an appropriate tool support for AUTOSAR-based EE system engineering. It becomes clear that the tool environments which are limited to purely AUTOSAR-based aspects are not of much value. What OEMs and suppliers need are integrated tool solutions which provide seamless integration and interoperation of standardized AUTOSAR and domain-specific non-AUTOSAR development steps and design activities.

When thinking of how to make a good tool environment for AUTOSAR according to these considerations, looking at other embedded system engineering tools such as MATLAB and Simulink can be helpful. Providing comprehensive math and graphics functions, they are powerful computation and modeling/simulation environments. The interesting fact is however that the versatility and success of MATLAB and Simulink does not arise from their completeness. It is because they are based on an architecture which clearly separates the generic engineering environment core from problemnear and typically domain-specific behavior. The latter is realized using built-in scripting languages which are easy to learn and can be used without requiring in-depth knowledge of the engineering environment core. This enables users who are usually domain experts rather than tool experts to adapt the engineering environment to domainspecific contexts by conveniently modifying existing or adding new behaviors. This approach is an interesting starting point for AUTOSAR-based EE system engineering environments.

The different non-AUTOSAR development steps and design activities normally require very dedicated kinds of skills and expertise and may even involve specific languages, formalisms or meta models. Due to the complexity and specificity of these different development methodologies and given the fact that they are moving on and evolving quickly, it is not likely that all these needs can be satisfied by a single case tool from a single tool vendor. Therefore, a clear separation in two regards has to be made. First, to have on the one hand an open AUTOSAR tool platform and on the other hand custom extensions which are built on top of this platform. Second, there are on the one hand the tool suppliers who are true experts from a tool technology point of view and are the best to provide such an AUTOSAR tool platform. On the other hand there are the tool users who are experts of the methodologies behind the respective development steps and design activities. They are consequently the best to know how to create the extensions required for integrating AUTOSAR with these methodologies into a continuous development flow. The idea is to involve the respective experts into tool development without requiring that any of the parties has to know everything.

A promising approach for providing integrated tool support covering AUTOSAR and non-AUTOSAR aspects of EE system development is therefore to have an open AUTOSAR tool platform providing standardized AUTOSAR tooling services plus extension mechanisms which are easy enough to be used by different kinds of EE domain experts for realizing and adding in their own tools or coupling the platform with third-party or legacy tools.

Eclipse-based AUTOSAR Tool Development Kit

Leveraging on AUTOSAR standard description files, structured development process, scalability and exchangeability principles, In order to ensure that the features of AUTOSAR TDK are not only exploitable by tool development experts with in-depth Eclipse knowledge but also by EE domain experts having only general programming skills, an easy to use scripting and plug-let environment has been added to AUTOSAR TDK. However, rather than relying on some existing or, even worse, inventing a new dedicated scripting language and having all AUTOSAR TDK adopters to learn it, the broadly known and well-understood Java programming language is reused for that purpose.

Eclipse's built-in Java-development environment JDT which very is intuitive and comfortable to use has been extended and made available as script development and debugging environment. Equinox and PDE have been leveraged for contributing Javabased scripts in the form of dynamic plug-lets. As a result, scripts become compiled and deployed on the fly after each modification and are immediately available for execution. Manual export and contribution to the underlying Eclipse installation followed by a time-consuming restart of the Eclipse environment are no longer necessary. Users can develop, debug, and run scripts in short cycles and directly within the environment where they intend to use them (see figure 5). Given these features AUTOSAR TDK enables a wide range of application scenarios. Existing AUTOSAR tool components can be enhanced or adapted to fit domain or even project-specific needs. This is typically necessary when it comes to guided or automatic configuration of AUTOSAR basic software modules. Dedicated tool environments can be setup to support different process roles and constraints. Connectors can be created to integrate AUTOSAR with non-AUTOSAR tools, like e.g. design tools for vehicle functions and behaviors.

Legacy artifacts such as company-specific message matrixes can be imported and seamlessly integrated into the AUTOSAR design flow. AUTOSAR is nevertheless merely a design standard and does not cover the complete EE system development cycle. Even within the scope of AUTOSAR there are many activities like e.g. automation of AUTOSAR basic software configuration which remain domain-specific. Tool environments for AUTOSAR-based development of EE systems can therefore hardly be complete out of the box. Consequently, AUTOSAR tools must not only be ready to use in terms of AUTOSAR-based design functions. They also must be extensible by custom tools which cover domain-specific design activities or connectors to third-party or legacy tools for integration with non-AUTOSAR development steps.

Conclusion

Geensys responds to this demand by building AUTOSAR tools upon an open and easy to extend tool platform: AUTOSAR TDK. It is based on the open source Eclipse framework and provides common meta models, APIs and services which are typically required by all kinds of AUTOSAR tools. It also provides a built-in scripting support enabling automation-like extension and customization of existing AUTOSAR tools as well as creation of new AUTOSAR tools. Scripts are written in fairly wellknown Java programming language, dynamically compiled, and packaged into plug-lets and deployed at runtime. This enables EE domain experts who typically have general programming skills but no dedicated Eclipse knowledge to instantly start developing the very specific kind of tools and connectors they need and to run and use them within the same environment.

Glossary

Figure 2 :

 2 Figure 2: The AUTOSAR Process These processes ultimately couple SYSTEM level and ECU level design tools in a single PRODUCTcentric development flow, with distributed responsibilities across the various development stakeholders. This poses the crucial demand for the

  Geensys has been striving to develop such an open and easy to extend tool framework, capable of hosting various AUTOSAR-compliant design and verification tools, and providing mechanisms for being extended by custom tools or being integrated with third-party or legacy tools. It is called AUTOSAR Tool Development Kit (TDK), and represents an intrinsic part of Geensys' AUTOSAR Builder tool suite. Alike the AUTOSAR Builder tool suite, the TDK has been built upon open source Eclipse technology. Eclipse is a versatile and technology-rich platform with an open and innovative ecosystem for Eclipse-based add-ons and solutions. Given that Eclipse is based on the well-known Java programming language and its openness and extensibility it is an ideal basis for AUTOSAR TDK.At the bottom line, AUTOSAR TDK provides the most important basic building blocks which are typically required for realizing any kind of AUTOSAR-related tool. Instead of reinventing the wheel with each AUTOSAR tool to be realized, tool developers and users can reuse this infrastructure and base their own solutions upon it. AUTOSAR TDK therefore encompasses EMF-based implementations of AUTOSAR meta model releases 2.0, 2.1, and 3.0, and a number of related services including AUTOSAR XSD conform serialization, rulebased validation, tree-based viewers, form-based and graphical editing, and template-based target code and documentation generation (see figure3). All these models and services are accessible via on open APIs. They are at the same time the common basis for the off-the-shelf AUTOSAR design tools realized by Geensys (see figure4) and simplify the task of developing custom tools or connectors to third-party or legacy tools for AUTOSAR TDK adopters outside Geensys.

Figure 3 :

 3 Figure 3: Meta Models, Services and APIs offered by AUTOSAR TDK

Figure 5 :

 5 Figure 5: Development and running scripts inside AUTOSAR Builder