You will find the figures mentioned in this article in the German issue ofATZelektronik 04I2007 beginning on page 12.

Modellbasierte Entwicklung von

Autosar-Anwendungssoftware

Model-based Development of

Autosar Application Software

Authors:Ulrich Freund, Ulrich Lauff,Hans-Jörg Wolff and Dirk Ziegenbein

Today, control algorithms of electro-nic in-vehicle functions are imple-mented on networked control units with differing software architectures. Special effort is needed when inte-grating software components from different sources, which limits the reusability of automotive embedded software. This Etas paper focuses on the advantages of model-based de-velopment and describes the reengi-neering of an engine management system as an example.

With the aid of model-based function speci-fications and by using standardized inter-rrfaces for the ECU software the joint develop-ment of software for automotive electronicsgets simplified. In addition, this approach reduces costs and time-to-market, enhances software quality, and provides mechanismsrequired for the design of safety relevant sys-tems. To reach these goals, Autosar definesan architecture for automotive embeddedsoftware. It provides for the easy reuse, ex-change, scaling, and integration of ECU-in-dependent software components.

2 Model-based Function Development

With the Ascet development tool by Etas functions of the application software can be described in the form of a hardware-in-dependent model. Compared with thepurely textual specification making up the traditional engineering specification, a de-cisive advantage of this approach is theeasy migration of proven function models from one vehicle project to the next. This capability positively affects product quali-ty, significantly reduces development andmaintenance costs, while supporting plat-form strategies.

ATZelektronik 04I2007 5

3 Abstraction of Operating Functions

Ascet is a software tool for the graphical programming of ECU application soft-ware. Using finite state machines and block diagrams, the development tool fa-cilitates the graphical modeling of func-tion properties independently of the vehi-cle‘s E/E architecture. Unlike with typicalsimulation tools, the modeling in Ascetoccurs at an abstraction level that is opti-mized with regard to the requirements of ECU programming: – Finite state machines and block dia-

grams are translated into C code for theECU by means of simple and logicaltransformation steps

– Explicit mapping of subroutines (proc-esses) to operating system tasks makes itpossible to define the order of execution of the control algorithms contained in the models

– Upon model execution, data is safely transferred through defined interfaces (messages) between subroutines.

Ascet‘s own code generators are capable of the direct translation of models into opti-mized series C code for specific ECU micro-controllers [1]. The code thus generated is highly readable and MISRA compatible [2], as well as well-structured. It is suitable foreasy integration in the basic software of aseries production ECU.

When it comes to mapping a model in C code, Ascet provides developers with a high degree of control. The model is capa-ble of allowing for microcontroller-specif-ffic functions or memory areas. So-calledmodules and processes are used to subdi-vide both structures and sequencing of modeled functions. A function is repre-sented by one or more modules. Messagesare used to describe module interfaces,whereas processes define the ways andmeans by which messages are accessed by control algorithms. Because the processesare executed by operating system tasks,the Ascet message concept ensures the in-dependence of the process execution of the E/E architecture present – such as thecommunications matrix in use, or the in-tegration of sensors and actuators in theECU software.

The tool also opens the door to C code integration. For example, developers can import a network management algorithm from the basic software for combination with a function of the application. The re-sulting composite model is immediately available to the developer for testing on thePC, allowing specification faults to be iden-tified early on in the design phase.

Ascet manages the individual modulescontaining the function models in a data-base. In this way, one or more functions that shall be integrated on an ECU can be bundled for a given project. A special in-terface aids in versioning the function models in the Ascet database by means of an external configuration management system.

4 The Significance of Autosar

The approach of detaching the functions of the application from the basic func-tions of sensors and actuators and fromthose of the E/E architecture, can be fully exploited by means of Autosar [3, 4]. Auto-sar encapsulates control algorithms in the form of atomic software components thatcommunicate through „ports“. These are differentiated by their interfaces. The in-ternal behavior of a given software compo-nent is determined by the interaction of several executable, or „runnable“, entities.A runnable entity is activated in an oper-rrating system task on the ECU to perform control computations, while at the sametime defining the access to the data ele-ments of a port.

Electronic functions can be constructedfrom atomic software components. This is accomplished by interconnecting the ports of the atomic software components, and by adding proprietary ports to the software component – or composition – assembledin this way. The compositions’ ports can be used, for example, for receiving signals such as vehicle speed, which are available vehicle-wide. The mechanisms defined by Autosar for the connection of ports ensure independence of the E/E architecture, espe-cially for signal names.

The iterative assembly of compositions culminates in the so-called virtual func-tion bus (VFB), which interconnects all of the software components of a vehicle or vehicle domain, such as the powertrain, for example. The VFB segments – the atom-ic software components – are distributed to the individual ECUs of a given vehicle type, Figure 1.

On an Autosar-compliant ECU, the run-time environment (RTE) handles the com-munications for the atomic software com-ponents. The RTE serves as the interface between software components, basic soft-ware (BSW), and operating system (OS) as shown in Figure 1. The operating system uses the RTE to call the software compo-nents‘ runnable entities. The RTE replacesproprietary interfaces between function

components, sensor/actuator components, as well as the communications matrix of the respective vehicle type.

Ascet already realizes essential Autosarconcepts: Atomic software components are easily represented by modules, runnable entities by processes, and instances of port access by messages. In addition, Ascet sup-ports Autosar constructs such as interfaces, RTE events, services, and so-called exclusive areas.

In addition to an Autosar Authoring Tool, which provides initial descriptions of the system architecture and Autosar inter-rrfaces, Ascet is therefore ideally suited to the definition and implementation of the be-havior of Autosar-compliant vehicle func-tions, Figure 2.

In order to implement the communica-tions between the various Autosar software components, Ascet employs the RTE-API as part of its code generation. This approach ensures the consistent development of soft-ttware components, from their structural design to behavior modeling. Thanks to thesimilarity of Autosar and Ascet concepts, adapting the interfaces of existing Ascetmodels to Autosar is not an issue. As has been demonstrated in the evaluation de-scribed below and in other examples [5, 6], the required modifications are far from ex-xxorbitant.

5 Virtual Integration and Validation of Autosar Software Components

The Autosar virtual function bus paves theway for the virtual integration of software components. With Autosar, software com-ponents can be integrated with greater ease, instead having to distribute them to ECUs beforehand because the VFB is dis-solving the ECU boundaries. The virtual integration is accomplished with the use of the Etas-made tool Intecrio. This prototyp-ing environment is capable of integrating behavioral models designed in Matlab/Simulink or Ascet, as well as modules that were manually developed in C. The new version 3.0, scheduled for rollout in late 2007, enables the integration of Autosar software components (SWCs) with legacy function modules, Figure 3. Intecrio thus provides for the reuse of existing models and C code during the migration of ECUsoftware to Autosar architectures.

Intecrio already comprises the RTA-OSEK real-time operating system as an inte-gral part. It ensures target-close behavior of control function prototypes. RTA-OSEK is available stand-alone for Microsoft Win-

AUTOSAR

ATZelektronik 04I2007 6

Development Processes

dows providing support for virtual valida-tion on the PC (virtual prototyping). In ad-dition, Intecrio can also be used for testing the behavior of integrated components on a rapid prototyping system in the real-world vehicle environment by means of Autosar RTE and OS.

6 Autosar-compliant Reengineeringof an Engine Management System

Starting from an existing Ascet project themigration from a purely Ascet-based devel-opment to Autosar was explored. The base point of this work [7] was an existing Ascetproject of an engine management system (EMS) which demonstrated the applicabili-ty and benefits of model-based design and automatic code generation with the Etastools [8].

The EMS application software, which was developed in various stages, was de-ployed on a series production ECU. The ECU was operated by an OSEK operating system (Ercosek) and installed in a BMW 5-series in order to control the engine, a4.3 liter 8 cylinder 4-stroke gasoline en-gine with intake manifold fuel injection.The complexity of the real-world example emphasizes the relevance of the work.

The reengineering of the software com-prised multiple steps: – Partitioning of the existing functionali-

ty into Autosar SWCs– Autosar-specific adaptations – Generation of Autosar-compliant code– Integration of the Autosar software com-

ponents – Configuration of the basic software (OS

and COM stack)– Generation of the Autosar runtime envi-

ronment (RTE)– Validation of the functions using virtual

and rapid prototyping– Generation of suitable basic software

(especially operating system and COM stack)

– Compilation and linking of all generat-ed source code files (SWCs, RTE, OS,COM stack)

– Deployment on a TriCore evaluationboard.

For the reengineering project, Ascet was used as an integrated development envi-ronment for Autosar software components,offering the full range of modeling entities and flexibility of Ascet for this purpose. In-tecrio was used for functional validationusing virtual and rapid prototyping and asa mean to integrate the SWCs developed in Ascet into an ECU software system and con-

figure the basic software (OS and COM stack). An appropriate Autosar XML descrip-tion was generated directly from Intecriowhich serves as input for RTE generation,OS generation, and COM stack generation.The complete software was deployed on aTriCore evaluation board. To validate the engine management, the board was cou-pled via CAN to a test system executing an engine simulation. Other basic softwaremodules such as NVRAM management or diagnostics were out of the scope of thisproject.

7 Conclusion

In the course of this work, the mapping of concepts from the Ascet behavioral mode-ling tool and the Intecrio prototyping envi-ronment to Autosar has been demonstrat-ed. Different packaging of functionality toAutosar software components can be pro-vided to service specific requirements, suchas the protection of intellectual property.The reuse of functions for different compo-nents helps to reduce development costsand to increase software quality.

References[1] Nicolaou, M.: ASCET V5.1 mit neuer Generation des

Codegenerators. RealTimes Etas Group-Magazin,

2006, Ausgabe 2, S. 34-35

[2] Mackh, M.: MISRA-Konformität von ASCET-Autocode.

Automobil Elektronik, April 2007, S. 40-41

[3] Autosar – www.autosar.org

[4] Morgan, G.: AUTOSAR – ein Projekt zur Entwicklung

von Steuergerätesoftware: Teil 1, Inhalte, Methoden

und Anwendungen. Elektronik Automotive, 2006, Aus-

gabe 1, S. 44-47; Teil 2, Laufzeitumgebung und Basis-

software. Elektronik Automotive, 2006, Ausgabe 2, S.

30-33; Teil 3, Anwendbarkeit und Vorteile des Stand-

ards. Elektronik Automotive, 2006, Ausgabe 3, S. 38-41

[5] Siwy, R.: Der OEM als Softwarelieferant – Model-

lierung von Bedienfunktionen mit AUTOSAR-Schnitts-

tellen in ASCET. RealTimes Etas Group-Magazin,

2007, Ausgabe 1, S. 8-9

[6] Schwerin, W., Jenter, M.: AUTOSAR-Evaluierung bei

BMW – Durchgängige Verwendung der AUTOSAR-

Technologie in der Software-Entwicklung eines Se-

riensteuergeräts der Karosserie-Elektronik. RealTimes

Etas Group-Magazin, 2007, Ausgabe 2, S. 12-13

[7] Frey, P., Freund, U.: AUTOSAR-Compliant Reengineering

of an Engine Management System. Tagungsband des

OMER4 Workshops, 30.-31. Oktober 2007, Paderborn

[8] Gebhardt, M., Stier, G., Beaumont, A., Noble, A.:

Automation of ECU Software Development: From Con-

cept to Production Level Code. SAE Technical Papers,

1999, SAE-Paper 1999-01-1174

ATZelektronik 04I2007 7

AUTOSARDevelopment Processes