AUTOSAR Tools for Production Projects - dSPACE

AUTOSAR Tools for Production ProjectsDr.-Ing. Ulrich Eisemann, dSPACE GmbH, GermanyDr. Dirk Stichling, dSPACE GmbH, GermanyTranslation of “AUTOSAR und die Serie”Published at: Elektronik Automotive, 09/2010

Efficient developmentof AUTOSAR-compliantappli cation softwareTo harness the benefits of the AU-TOSAR standard in practical work,precisely coordinated tools are needed.Ideally, these should not only provideimport and export functionalities for AU-TOSAR files, but also support the entiredevelopment process, covering differentstages such as design, implementation,integration and testing.Architecture andBehavior ModelingThe endeavors of the AUTOSAR developmentpartnership [1] to establisha uniform software architecture andstandard exchange formats have hadnumerous positive impacts on automotiveproduction projects [2], [3], [4]. Todevelop AUTOSAR-compliant applicationsoftware, a behavior modeling toolsuch as dSPACE TargetLink ® is usuallycombined with a software architecturetool such as dSPACE SystemDesk ® , seeFig. 1. This architecture tool not onlyhelps design the AUTOSAR softwarearchitecture, it is also used later forsoftware integration by generating theAUTOSAR run-time environment (RTE)and then for software integration tests.Behavior modeling tools like TargetLinkare used to design models of controlfunctions and to implement the functionsas AUTOSAR software components(SWCs) by automatic productioncode generation. As is well known, theAUTOSAR standard defines exchangeformats in ARXML files for transferringAUTOSAR-related data between developmenttools. Practical experience hasshown that efficient AUTOSAR-compliantwork requires coordinated toolsthat all interpret the AUTOSAR standardin the same way. AUTOSAR-compliantsoftware development involves not onlyARXML files, but also numerous otherfile types that the software architects,component developers, software integratorsand testers need to exchange.For example, the behavior modeling toolgenerates code files for implementingcomponents, and these same files arealso used at other points in the developmentprocess, such as componentand software tests. Documentationfiles describing the component designcan also be exchanged, as can A2L filesfor calibration and measurement, evenwhere the AUTOSAR standard does notyet sufficiently cover this. These files,and the ARXML format standardizedby AUTOSAR, require special handlingin carrying out the round trips thatare typical of the development of AU-TOSAR-compliant application software.This article will therefore describe howcoordinated tools such as SystemDeskand TargetLink support the AUTOSARdevelopment process.AUTOSAR Round Trips Basedon SWC ContainersIn the top-down approach examinedhere, the development of a softwarecomponent typically begins with thesoftware architect specifying the component,including its ports and interfaces,in SystemDesk. The component is a partof a software architecture consisting ofnumerous nested components dividingthe overall functionality into units thatwill undergo separate development. Topass the specification of a component tothe component developer, the architectexports what is called an SWC containerfrom SystemDesk. The SWC containerholds at least the exported ARXMLfiles, and the architect can add furtherspecification documents to it. SWCcontainers serve to hold all the relevantfiles, and further artifacts are added tothem successively during the AUTOSARround trip.The TargetLink user begins implementationactivities for the componentby importing the SWC container suppliedby the architect and the ARXMLfiles that it contains. The specificationsfor the component’s interfaces are initiallyused to generate an AUTOSAR framemodel. This then has to be filled with thealgorithms for the control function – aprocedure that considerably facilitatesmodel-based component design. Theuser performs offline simulations inmodel-in-the-loop mode, generatesAUTOSAR-compliant code, and simulatesthe code in software-in-the-loopand processor-in-the-loop simulationsuntil the desired functionality has beenachieved and software componentimplementation is completed. TargetLinkcompletely covers the design and implementationof individual componentsand the necessary test steps, and makesthe entire spectrum of model-basedtechniques. On completion of theseactivities, an updated SWC containeris exported (see Fig. 1 below), whichnow contains not only the ARXML filesenriched with implementation information,but also additional artifacts. Theseparticularly include the source files forimplementing the components and,if necessary, documentation files orA2L files that will facilitate integrationtests.The software architect or integratorcompletes the first iteration in the developmentprocess by importing the new2Elektronik Automotive 09/2010

SWC Container ExportSystemDeskSWC Container ImportContainerManagerSWC Container.arxml .doc.arxml .doc .a2l.c .h......SWC ContainerSWC Container ImportTargetLinkSWC Container ExportFig. 1: Exchanging SWC containers between SystemDesk, the architecture and integrationtool, and TargetLink, the behavior modeling tool, in the AUTOSAR-compliant developmentprocess.the round trip between SystemDeskand TargetLink. The SWC ContainerManager also allows visual comparisonof two SWC containers and the artifactsin them. When different project versionsarise, as is inevitable with round trips,they can be visualized and examinedfor differences. The software architectcompares his or her own SWC containerwith the one sent by the TargetLink userto check whether any specifications inthe ARXML files have been incorrectlymodified. At the other end of the roundtrip, the TargetLink user also uses theSWC Container Manager to makechecks, for example, to see whetherthere are interface modifications madeby the architect that necessitate changesto the model-based design. Thus, theSWC container back into SystemDesk.This includes flexibly applying the updatedARXML files. The source and A2Lfiles in the container can be used to testthe interaction between individual componentsin the software architecture. Asimulation target for these tests, basedon a generated run-time environmentand the source files of individual components,is generated in a build process.This allows a software integration test tobe carried out extremely conveniently,and also gives the tester read and writeaccess to all the relevant variables.Handling Changes:The SWC Container ManagerIn any real development process,there are always iterations in whichthe round trip outlined in Fig. 1 is runthrough repeatedly. This happens whenmodifications are made to the interfaces,or additional ports are insertedin software components, and so on.The concept behind SWCcontainers and their importand export functionalitiesis specifically designed tominimize the number ofuser interactions neededduring the round trips.The import and export ofSWC containers can beadapted to project- or customer-specificworkflowsby means of configurationfiles. This includes definingwhich users can overwriteor modify which file typesto protect the developmentprocess against unwantedchanges.The SWC containers are managed inthe SWC Container Manager, a specialized,graphics-based tool, see Fig. 2. Thislets users insert additional specificationdocuments or other items in an SWCcontainer and then exchange them inFig. 2: The SWC Container Manager as a user interfacefor comparing two SWC containers and the artifacts theycontain.concept of SWC container exchangebetween SystemDesk and TargetLinkgoes far beyond the mere import/exportof ARXML files, making it considerablyeasier to carry out round trips in theAUTOSAR development process.Elektronik Automotive 09/2010 3

Dr. Ulrich Eisemannis Product Manager for the TargetLinkproduction code generator atdSPACE GmbH in Paderborn,Germany.Dr. Dirk Stichlingis Product Manager for the systemdesign tool SystemDesk atdSPACE GmbH in Paderborn,Germany.4Elektronik Automotive 09/2010

www.dspace.com© Copyright 2010 by dSPACE GmbH.All rights reserved. Written permission is required for reproduction of all or parts of this publication. The source mustbe stated in any such reproduction. dSPACE is continually improving its products and reserves the right to alter thespecifications of the products contained within this publication at any time without notice.dSPACE is a registered trademark of dSPACE GmbH in the United States or other countries, or both. See www.dspace.com/goto?trademarks for a list of further registered trademarks. Other brand names or product names are trademarksor registered trademarks of their respective companies or organizations.Company Headquartersin GermanydSPACE GmbHRathenaustraße 2633102 PaderbornTel.: +49 5251 1638-0Fax: +49 5251 16198-0info@dspace.deChinadSPACE Mechatronic ControlTechnology (Shanghai) Co., Ltd.Jinling Haixin Building Unit B, 25F/LFuzhou Road 666200001 ShanghaiTel.: +86 21 6391 7666Fax: +86 21 6391 7445infochina@dspace.comUnited KingdomdSPACE Ltd.Unit B7 . Beech HouseMelbourn Science ParkMelbournHertfordshire . SG8 6HBTel.: +44 1763 269 020Fax: +44 1763 269 021info@dspace.co.ukJapandSPACE Japan K.K.10F Gotenyama Trust Tower4-7-35 KitashinagawaShinagawa-kuTokyo 140-0001Tel.: +81 3 5798 5460Fax: +81 3 5798 5464info@dspace.jpFrancedSPACE SARL7 Parc BurospaceRoute de Gisy91573 Bièvres CedexTel.: +33 169 355 060Fax: +33 169 355 061info@dspace.frUSA and CanadadSPACE Inc.50131 Pontiac TrailWixom . MI 48393-2020Tel.: +1 248 295 4700Fax: +1 248 295 2950info@dspaceinc.com09/2010