2 ATZ elektronik 03I2006

Author:Gary Morgan

Auswirkungen von Autosar auf zukünftige Steuergerätesoftware

You will find the figures mentioned in this article in the German issue of ATZ elektronik 03I2006 beginning on page 6.

Impacts of Autosar on Future ECU Software

1 Introduction

It would be hard to overstate the importanceof Autosar as a force of innovation and stan-dardization. And it is safe to say that theproject represents the largest-ever collabora-tion of automakers, Tier One suppliers, andrelated industries.

The Autosar partnership, an alliance ofOEM manufacturers and Tier One automo-tive suppliers, was founded by five majorcompanies. Today, the 10 so-called Core Part-ners BMW, Bosch, Continental, Daimler-Chrysler, Ford, General Motors, PSA,Siemens VDO, Toyota, and VW, control bothdirection and destiny of the partnership.

Next in line after the Core Partners arethe Premium Members. This group consistsof more OEMs, along with many Tier Onesuppliers, tool and software vendors as well

as silicon and other hardware vendors.There are currently 52 Premium Members,with more joining all the time. PremiumMembers can join the many working groupswithin Autosar, and these groups are writ-ing the standards documents that define it.Etas and LiveDevices were among the firstPremium Members to join the Autosar com-mittee in 2004.

2 Reasons for Autosar

The motivation for Autosar stems from thehigh cost of automotive software. This costhas two aspects: One, development and, two,post-manufacture bug fixes.

It is intended that development costs ofautomotive software be reduced through thereuse as well as easy exchange of ECU soft-ware, the easy integration of software mod-

With its acronym denotingAutomotive Open SystemArchitecture, the Autosardevelopment partnership iscurrently one of the most in-teresting, far-reaching andinnovative projects in auto-motive electrical systems.This article discusses thetechnical basis of Autosarand its design methodology.

COVER STORYAutosar

3ATZ elektronik 03I2006

ules on an ECU, and by means of a softwarearchitecture that logically separates softwarefunctions from the executing ECUs.

Because Autosar is based on a set of openstandards, a small number of implementa-tions can be reused. This multiple use cutsdown on development costs and increasesthe deployment options for modules. The re-sult is a reduced number of bugs which, inturn, causes a smaller number of software-related recalls.

3 Technical Basis

Autosar defines an abstraction of the elec-tronic functions of a vehicle and a way of im-plementing the abstraction in software. Au-tosar defines the sum of an ECU´s SoftwareComponents (called SWCs) as the applicationsoftware that runs on an ECU. A softwarecomponent is an abstraction that allowssome piece of application software function-ality to be encapsulated. The encapsulationreduces the component's dependence on theenvironment in which it executes. Thismeans that it should run on any ECU provid-ed that the environment does not change.Figure 1 shows an SWC as a Black box thatcontains some functionality but which onlyinterfaces to the outside world through awell defined set of ports.

Although SWCs are assembled to form asystem, Autosar defines neither the numbernor the types of SWCs. This is in the manu-facturers’ domain. Autosar also allows mul-tiple instances of the same SWC. Figure 2shows a simple example of three SWCs.

Autosar also defines the environment inorder to prevent it from changing. The envi-ronment defines a component's interface tothe rest of the ECU and vehicle. The abstrac-tion of the environment is called the VirtualFunction Bus, – or VFB, Figure 3.

Therefore, to enable it to perform its I/Ofunctions and to communicate with otherSWCs, each SWC is connected to the VFB.

The interface between an SWC and theVFB can be changed to reflect the require-ments of that SWC. Accordingly, the verymethod for specifying the interface alsoneeds to be specified, and it needs to bereusable. This is where Autosar avails itselfof the Extensible Markup Language (XML).Because there are many reasonably priced,robust, and reliable tools available for work-ing with XML, this dispenses with the needto develop tools for proprietary languages,such as the OSEK Implementation Language(OIL). The upshot is reduced costs and a fur-ther increase in reliability. Autosar uses XMLexclusively and represents the vehicle's en-tire configuration in that language.

4 Runtime Environment

When two SWCs are configured to commu-nicate with each other, they can either be lo-cated on the same ECU (Intra-ECU communi-cations) or on different ECUs (Inter-ECUcommunications). This is shown in Figure 5.

In the Intra-ECU case, when an SWCsends a message to the RTE, it is configuredto deliver that message to an SWC on thesame ECU. The message thus passes fromthe sender SWC through the RTE to the re-ceiver. It never needs to use the BSW.

In the Inter-ECU case, the RTE is config-ured to deliver the message to the communi-cations stack. This packages up the messagewith other relevant messages and sends it tothe correct bus. The bus carries the messageto the receiving ECU, where the communi-cations stack unpacks the message and for-wards it to the RTE, which then forwards itto the appropriate receiving SWC.

Communications between SWCs is theRTE's most obvious role. However, it alsoneeds to manage communications with oth-er BSW functionalities. For example, whenan SWC needs to perform I/O or use thememory services, the RTE is also used tomanage the communications.

Another interesting point about the RTEis that its main purpose is to present a uni-form interface to application SWCs and so,to a large extent, what is underneath theRTE does not matter. This means that thereis a migration path from legacy ECU soft-ware to Autosar ECUs simply by inserting anRTE that will work with the legacy ECU's OSand further platform software. This ap-proach was demonstrated by Bosch andLiveDevices in their recent paper (see refer-ence 3).

Bosch and LiveDevices evaluated an RTEfor use within an existing ECU’s software ar-chitecture. The experimental ECU was notan Autosar ECU but had been developed us-ing similar principles. This meant that indi-vidual software functions could be separat-ed from each other with little refactoring.The software architecture of the experimen-tal ECU is shown in the front picture.

A set of three functions that roughly cor-responded in abstraction to SWCs were ex-tracted. Their points of communication tothe rest of the software were then rewrittento use Autosar ports. The RTE available fromLiveDevices (see reference 2) was used to in-terface to the rest of the ECU software. Thisapproach enabled the overheads introducedby the transition of a legacy SWC to an Au-tosar SWC to be evaluated along with thoseintroduced by the use of an RTE. This appli-cation architecture is shown in Figure 6.

The VFB is merely an abstraction. In or-der to build a real system, there needs to bean implementation of the VFB. Autosarsplits the VFB into two major areas of func-tionality: the Runtime Environment (RTE)and the Basic Software (BSW). The BSW isfurther subdivided into communications,input and output, memory services and sys-tem services, such as the operating system(OS). Figure 4 shows the architecture of theECU software that implements the VFB. AllSWCs are connected to the Runtime Envi-ronment (RTE), which acts like a telephoneexchange connecting SWCs, I/O, and otherservices.

The Basic Software (BSW) is located belowthe RTE.

The BSW provides communications, I/O,and other functionalities that all SWCs arelikely to require. For example, diagnosticsand error reporting, non-volatile memorymanagement, etc.

The I/O module provides the I/O servicesto the ECUs. This module consists of manycomponents that depend on the hardwareon which the SWCs are running. Most of thesoftware in the I/O services is designed to becommon so that it can also be reused. Somelow-level device drivers need to exist for par-ticular silicon. However, it is likely that thedrivers will also be reused so that there is noneed to re-implement these for each ECUcompletely.

An operating system is used to coordi-nate all of the activities of the SWCs, BSW,and RTE. Neither SWCs nor BSW modulescall the OS directly. The RTE is responsiblefor providing the interface between theSWCs, the BSW, and the OS. This also allowsa certain amount of OS independence.

In the early design stages of developing asystem with Autosar, defining the ECU onwhich a particular SWC will run is not re-quired. This is because the VFB interface isalways the same. During the development ofthe SWC, the source code that implementsthe interface is also independent of the ECUon which the SWC runs. This allows the sys-tem consisting of a composition of SWCs tobe constructed without any need to buildthe real ECUs. Eventually, the compositionmust be divided up and the individual SWCsallocated to real ECUs.

These areas of functionality can be seen inFigure 4. The RTE is the only interface pres-ented to the SWCi, i=1,.., n. Also, all the BSWmodules and the OS interact via the RTE. Thepurpose of the RTE is to coordinate commu-nications between the SWCs and BSW and toencapsulate the relevant OS functionality.The functionalities of the RTE, the BSW mod-ules, and the OS are described below.

COVER STORY Autosar

4 ATZ elektronik 03I2006

The results of this study showed that anaïve transformation of an existing compo-nent to Autosar may cause high overheads.The reason is that some of the communica-tions modes between an SWC and the VFBuse rich semantics and imply a lot of stateand run-time overheads. However, by mak-ing more intelligent choices and using anoptimizing RTE generator, the overheadscould be considerably reduced. This ap-proach clearly showed that the overheadsfrom Autosar are manageable, but alsodemonstrated that it is possible to adapt ex-isting ECUs to work within Autosar systems.

LiveDevices built a similar system as atechnology demonstrator. This is based up-on the same arrangement of componentslike in the study but bases the ECU’s soft-ware architecture upon Autosar and with aprototype GUI for configuration. Thisdemonstrator has two ECUs and shows themigration of SWCs from one ECU to anotherwith no code changes. A screenshot of theGUI is shown in Figure 7.

5 Basic Software

The Basic Software (BSW) is highly struc-tured in Autosar. All BSW modules, theirfunctionality and interconnections are de-fined. This allows for competition and com-patibility between BSW vendors just as thereis between SWC vendors.

Before considering the main modules inthe BSW in detail, some overview of thestructure is useful. The BSW is structuredboth vertically and horizontally, as shown inFigure 8.

On the vertical axis, the lower end con-sists of the interface to the hardware. This iscalled the microcontroller abstraction layer.This layer is designed to contain the smallestamount of microcontroller specific softwareand will need to be re-written for differentmicrocontrollers. It is therefore a very thinlayer. Higher layers in the BSW gradually ab-stract away from the hardware to presentuseful high-level facilities to the RTE, andare designed to be portable.

The horizontal axis accommodates col-lections of services provided by the BSW.These are classified as communications, I/O,memory and OS, plus other services.

The BSW is specified in such a way that Cis the most obvious implementation lan-guage, and is also designed to be reconfig-urable. Autosar is designed to be configuredand optimized off-line. Typically this worksby tools producing C source code represent-ing the configuration from the XML that de-scribes the system. The C is compiled andlinked with the appropriate BSW modules

to produce the BSW implementation. How-ever, it is also recognized that some aspectsof the BSW may need to be reconfiguredonce the software is in the ECU's flash mem-ory. Because of this, the BSW also has a con-cept that supports end of production line,and later, reconfiguration.

6 OS and other Services

Autosar uses existing standards whereverpossible. The Autosar OS is based upon thealready well accepted OSEK-VDX OS. The Au-tosar OS has four scalability classes, en-abling the support of facilities at differentlevels by different types of hardware.

For example, the lowest scalability classfacilitates efficient implementations onsmall (e. g., 16-bit) processors. However, whenthe processor features memory protection fa-cilities (on some 32-bit processors, for exam-ple), the highest scalability class allows SWCsto be protected from each other both in timeand in space. This last point is very impor-tant in Autosar systems. Autosar allows com-ponents from different vendors to be com-bined. A failing component might fail inspace (i.e., it writes to memory to which itdoes not have access) or in time (i.e., it runsfor too long before exiting). In both cases, afailure in one component might be seen asan error in another component from a differ-ent vendor. This can make debugging andproduct liability a nightmare. The AutosarOS detects and contains these problems.

The Autosar OS has two models of tasks,inherited from OSEK-VDX, called Basic andExtended. Basic Tasks are single-shot tasksmeaning that they start, do some work, andterminate. They are not capable of voluntar-ily suspending their execution. By compari-son, Extended Tasks are allowed to voluntar-ily suspend their execution in order to blockwhile waiting for some other event. This dis-tinction is useful because basic tasks can beimplemented much more efficiently than ex-tended tasks, and most algorithms can be ex-pressed in single-shot tasks. The system de-signer can therefore trade efficiency for func-tionality in the tasking model. Other servicesthat are regarded as peers of the OS includethose to start up and shut down the ECU,and to manage the ECU's mode.

7 Communications

The communications stack in Autosar is re-sponsible for implementing communica-tions between ECUs. It supports the CAN,LIN, and Flexray buses commonly used inautomotive systems. The internal structureof the stack is shown in Figure 9.

The core of the stack is a COM modulebased upon the OSEK-VDX COM standard.On the transmit side, the COM module is re-sponsible for packing messages from theRTE into so-called I-PDUs, which are thentransmitted over the respective data bus. Onthe receive side, the COM module unpacksthe messages from PDUs and passes them tothe RTE which then delivers them to the ap-propriate receivers.

PDUs are routed to and from the appro-priate bus using the PDU Router. The PDURouter can also route between buses and,therefore, can act as a frame gateway. Signalgatewaying is performed in COM.

An I-PDU usually maps onto a frame atthe bus level, but this need not be true in allcases.

Each bus technology has a single inter-face that abstracts some of the higher levelfeatures of the communications stack sothat these do not have to be implemented inthe driver for that bus. The only target-spe-cific part of the communications stack isthe bus driver. All other parts support differ-ent bus technologies by reconfigurationrather than code changes.

8 Design Methodology

Currently Autosar is concentrating on thespecification of the components of the soft-ware architecture. However, Autosar also im-plies a significant change in the whole waythat ECUs and vehicle systems are designedand implemented.

The primary methodology innovationlies in the specification of the SWCs. Autosarstandardizes their interfaces using a set ofvery strong concepts. These concepts allowthe vehicle’s functionality to be built in avery abstract manner and then gradually re-fined using a strong top-down approach.

At the same time, the bottom up ap-proach can be used in the specification andacquisition of ECU hardware and basic soft-ware. Once again, the concepts are suffi-ciently well defined that, when the top-down and bottom-up approaches meet (atthe RTE), the main risks will already havebeen removed from the system.

Autosar shifts the emphasis onto softwarecomponents in a way that is independent, atleast initially, of the physical properties(number and types of buses and ECUs) of thevehicle. This means that prototyping hard-ware and software that conforms to Autosarspecifications but may be based upon otherunderlying technologies can be used in earlydevelopment stages but in the knowledgethat functional behavior will still be thesame when the final ECU is produced.

9 Evaluation of RTA Basic Software Modules

Etas and LiveDevices are already offering products of the RTAproduct family that are based on the emerging Autosar stan-dards. Reference 2 lists components and packages that are al-ready available.

In addition, Etas and LiveDevices have introduced the Au-tosar Early Access Program (EAP). This is a range of pre-pro-duction Autosar parts that has already been integrated andcan be used for early evaluation and experimentation withAutosar prior to system development. The EAP concentrateson the BSW, RTE, and debugging. The range consists of thefollowing modules:

RTA-OSEK: This is a leading implementation of the OSEK-OS and Autosar OS standards and comes together with a so-phisticated planner tool, which can be used to model dead-lines and real-time behaviour, and a builder tool that gener-ates the optimized data structures for the OS.

RTA-RTE: RTE is the key to implementation of Autosar sys-tems. Currently the RTA-RTE is compatible with the version 1Autosar specifications.

RTA-COM: The RTA-COM module is compatible with RTA-OSEK and RTA-RTE. It has been designed to enable it to inte-grate with lower layers that are not Autosar compatible,therefore allowing it to be used in Autosar as well as hybridECUs. Currently RTA-COM is compatible with OSEK COM V3and with Autosar COM V1.

RTA-PDU: The PDU router implements communicationsbetween RTA-COM and Autosar-compliant bus interfaces,such as RTA-CAN.

RTA-CAN: Currently RTA-CAN provides an implementa-tion of the HIS CAN Driver standard. RTA-CAN is fully com-patible with RTA-COM and RTA-OSEK, and supports morethan one CAN bus. RTA-CAN V2 will also support Autosar.

RTA-TRACE: This acts as a software logic analyzer display-ing, in simple format, the operation of the BSW modules andSWCs in the ECU.

EAP II, launched at the start of 2006, bundles pre-produc-tion Autosar RTE, BSW modules, and an IDE tool that arecompatible with V2 of the Autosar specifications, forming alow-risk way of investigating the issues surrounding thebuilding of Autosar ECUs.

10 Summary/Outlook

Autosar is certainly a large and ambitious project. It rede-fines the way in which E/E software is written. However, itwill also have a massive impact on the entire software prod-uct life cycle: All OEMs, vendors, and Tier One suppliers willbe affected and must act carefully to manage the resultingchanges. There is considerable commitment to Autosar fromthe automotive industry. Its influence is spreading at a highrate into allied industries.

References[1] Autosar Website: http://www.autosar.org[2] Further information about development solutions for Autosar ECUs from

LiveDevices, Etas Group: http://de.etasgroup.com/downloads/autosar_br.shtml[3] Schnelle, K.-P.; Maldener, N.J.; Buttle, D.L.; Morgan, G.; Mitchell, S.E.:

Refactoring ECU Software to Work Under Autosar. VDI-Berichte 1907, 12.Internationaler Kongress „Elektronik im Kraftfahrzeug“, Baden-Baden,2005

EDITORIAL STAFFEditor-in-ChiefWolfgang Siebenpfeiffer (si)Tel. +49 611 7878-342 · Fax +49 611 7878-462 E-Mail: wolfgang.siebenpfeiffer@vieweg.de

Vice-Editor-in-Chief Gernot Goppelt (gg)Tel. +49 221 28056-91 · Fax +49 221 28056-92E-Mail: gernot@goppelt.de

Chief-on-DutyKirsten Beckmann M. A. (kb) Tel. +49 611 7878-343 · Fax +49 611 7878-462E-Mail: kirsten.beckmann@vieweg.de

Editors Rüdiger Baun (rb), Ruben Danisch (rd), Moritz-York von Hohenthal (mvh), Ulrich Knorra (kno), Michael Reichenbach (rei)

AssistantsEllen-Susanne Klabunde, Martina SchraadTel. +49 611 7878-244 · Fax +49 611 7878-462E-Mail: atz-mtz@vieweg.de

Office ColognePalanterstraße 16 b · D-50937 KölnTel. +49 221 28056-91 · Fax +49 221 28056-92

Office StuttgartWerastraße 54 · D-70190 Stuttgart,Tel. +49 711 2348204 · Fax +49 711 2361415

Office WiesbadenPostfach 15 46 · D-65173 Wiesbaden,Tel. +49 611 7878-244 · Fax +49 611 7878-462

MARKETING | OFFPRINTSProduktmanagement AutomedienMelanie Engelhard-Gökalp M. A.Tel. +49 611 7878-192 · Fax +49 611 7878-407E-Mail: melanie.engelhard-goekalp@vieweg.de

SonderdruckeMartin Leopold Tel. +49 228 6907-87 · Fax +49 228-6907-88E-Mail: leopold@medien-kontor.de

ADVERTISINGAd Manager Elisabeth Maßfeller Tel. +49 611 7878-399 · Fax +49 611 7878-140E-Mail: elisabeth.massfeller@gwv-fachverlage.de

Key Account ManagementGabriele StaabTel. +49 611 7878-388 · Fax +49 611 7878-140E-Mail: gabriele.staab@gwv-fachverlage.de

Ad Sales Frank Nagel Tel. +49 611 7878-395 · Fax +49 611 7878-140E-Mail: frank.nagel@gwv-fachverlage.de

Display Ad Manager Susanne Bretschneider Tel. +49 611 7878-153 · Fax +49 611 7878-443E-Mail: susanne.bretschneider@gwv-fachverlage.de

Ad PricesList No. 49

SUBSCRIPTIONSServiceVVA-Zeitschriftenservice, Abt. D6 F6, ATZ elektronik, Postfach 77 77, D-33310 GüterslohTel. +49 5241 80-1968 · Fax +49 5241 80-9620E-Mail: vieweg@abo-service.info

ManagementRenate ViesTel. +49 5241 80-1692 · Fax +49 5241 80-61692E-Mail: renate.vies@bertelsmann.de

PRODUCTION | LAYOUTKerstin GollarzTel. +49 611 7878-173 · Fax +49 611 7878-464E-Mail: kerstin.gollarz@gwv-fachverlage.de

PRINT | PROCESSINGImprimerie Centrale Luxemburg. Printed in Europe.

SUBSCRIPTION CONDITIONSThe journal appears at least 4 times a year atan annual subscription rate of 78,00 €. Priceper copy 21,00 €. All prices exclude mailing(annual subscription: inland 10,00 €; foreigncountries 16,00 €; AirMail 52,00 €). Cancel-lation of subscriptions in writing at least sixweeks before the end of the subscriptionyear.

The journal and all articles and figures are pro-tected by copyright. Any utilisation beyond thestrict limits of the copyright law without permis-sion of the publisher is illegal. This applies par-ticularly to duplications, translations, microfilm-ing and storage and processing in electronicsystems.

HINTS FOR AUTHORSAll manuscripts should be sent directly to theeditors. By submitting photographs and draw-ings the sender releases the publishers fromclaims by third parties. Only works not yet pub-lished in Germany or abroad can generally beaccepted for publication. The manuscriptsmust not be offered for publication to otherjournals simultaneously. In accepting the man-uscript the publisher acquires the right to pro-duce royalty-free offprints. The journal and allarticles and figures are protected by copyright.Any utilisation beyond the strict limits of thecopyright law without permission of the pub-lisher is illegal. This applies particularly to du-plications, translations, microfilming and stor-age and processing in electronic systems.

© Friedr. Vieweg & Sohn Verlag/GWV Fachverlage GmbH, Wiesbaden 2006.

The Vieweg Verlag is a company of Springer Science+Business Media.

IMPRINT

www.atzelektronik.com

03 | September 2006 Vieweg Verlag | GWV Fachverlage GmbHPostfach 1546 · D-65173 Wiesbaden · Abraham-Lincoln-Straße 46 · D-65189 Wiesbaden

Managing Directors Andreas Kösters, Albrecht F. Schirmacher, Dr. Heinz WeinheimerSenior Advertising Executive Thomas Werner Senior Production Executive Thomas FornerSenior Sales Executive Gabriel Göttlinger