AUTOSAR-Compliant Functional Modeling with MATLAB®, Simulink®, Stateflow® and Real-Time Workshop® Embedded Coder of a Serial Comfort Body Controller Andreas Köhler, Volkswagen AG, Wolfsburg, Germany Tillman Reck, Carmeq GmbH, Berlin, Germany ABSTRACT Volkswagen AG and further partners are developing together a fully functional Body/Comfort ECU for a Volkswagen series-production vehicle that will be furnished with Automotive Open System Architecture (AUTOSAR) compatible software. The aim of the
of 9
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
    AUTOSAR-Compliant Functional Modeling with MATLAB  ®  ,Simulink  ®  , Stateflow  ®  and Real-Time Workshop  ®  EmbeddedCoder of a Serial Comfort Body Controller Andreas Köhler, Volkswagen AG, Wolfsburg, GermanyTillman Reck, Carmeq GmbH, Berlin, Germany ABSTRACT Volkswagen AG and further partners are developing together a fully functional Body/Comfort ECU for a Volkswagenseries-production vehicle that will be furnished with Automotive Open System Architecture (AUTOSAR) compatiblesoftware. The aim of the project is to check, over a period of 12 months on a day-to-day basis, how the demands of theautomotive industry with regards to real time functionality can be met.Volkswagen will also evaluate software integration, migration opportunities, use of resources, software runtimes, quality ofspecifications, and cost. One goal of this project is to integrate functions already developed in MATLAB  ®  and Simulink  ®   into this Body/Comfort ECU. In cooperation with The MathWorks, the tool chain has been prototypically extended so thatthe functions could be generated by means of the code generator interface of the AUTOSAR platform. Then theAUTOSAR Control Unit can be mounted in a Passat sedan, thus creating an authentic test environment.In this paper we point out how Volkswagen will use the model-based function development in the AUTOSAR context. INTRODUCTION The reuse of software components between different vehicle platforms, OEMs, and suppliers is one of the major goals ofAUTOSAR. Therefore a methodology supporting a distributed, function-driven development process was created.Standardization of the software architecture for ECUs forming a network in an automotive environment is essential.AUTOSAR also specifies compatible software interfaces at application level, although the functional contents of theapplication modules and components are different and related to the corporate identity and the desired characteristics ofthe car manufacturer, or its system suppliers. By using the abstraction it will be possible to separate software fromhardware in a complex decentralized network. [1]Within the function-driven development process, the technique of model-based function development has a hugeinfluence. Functions are described by models. Simulink and Stateflow  ®  provide a common language of model descriptionand allow most of the OEM needs to be represented. THE AUTOSAR TECHNICAL CONCEPT The need to concentrate on a common stack of infrastructure software is addressed by AUTOSAR with well-specified,standardized basic software that closes the gap between microcontroller hardware and application software. Thetechnical concept of the AUTOSAR approach is a layered model, which is new in the software design for automotiveapplications. [1]By introducing a Virtual Functional Bus (VFB), it is possible to separate applications from infrastructure. An applicationconsists of interconnected AUTOSAR Software Components (SWCs). The VFB (shown in the top part of Figure 1)provides standardized communication mechanisms and services for these components. The VFB acts independently fromthe chosen mapping of these components to the infrastructure of the interconnected ECUs. [1]    Virtual Functional Bus A  U T  O S A R  S W-  C 1 A  U T  O S A R  S W-  C 2 A  U T  O S A R  S W-  C  3 A  U T  O S A R  S W-  C n ...ECU m A  U T  O S A R  S W-  C n RTEBasicSoftware   ECU m A  U T  O S A R  S W-  C n RTEBasicSoftware ... VFB viewMapping System ConstraintDescriptionECUDescriptionsTool supporting deploymentof SW componentsGatewaySW-CDescriptionSW-CDescriptionSW-CDescriptionSW-CDescriptionECU II A  U T  O S A R  S W-  C 2  RTEBasicSoftware   ECU II A  U T  O S A R  S W-  C 2  RTEBasicSoftwareECU I A  U T  O S A R  S W-  C 1  RTEBasicSoftware A  U T  O S A R  S W-  C  3    Figures 1 and 2: The Virtual Functional Bus (VFB) decouples application and infrastructure. The realization of the VFB concept is possible if each AUTOSAR ECU has standardized basic software functionalities andinterfaces. Figure 1 shows the layered architecture of an AUTOSAR ECU, which basically identifies an application layer,and the AUTOSAR Basic Software (BSW). These parts are linked via the AUTOSAR Runtime Environment (RTE). Thatmeans the RTE can be interpreted as the runtime implementation of the VFB on a specific ECU. In principle this layeredmodel is applicable to nearly all vehicle domains. [1]AUTOSAR software components which are mapped to a specific ECU are located in the ECU’s application layer. Theimplementation of such an AUTOSAR SWC is independent from microcontroller and ECU as well as from the physicallocation of other components in the system. An AUTOSAR SWC interacts with other SWCs (on the same or differentECUs) and with the services and resources available on the ECU via the RTE. The RTE decouples the application SWCsfrom the infrastructure software. [1] MOTIVATION FOR THIS PROJECT A motivation is the insertion of AUTOSAR in series production. It is to be expected that only individual control units areloaded with the operating system first of all. One of the next steps is to check what an integration of the AUTOSAR basicsoftware in an existing vehicle network can look like.    Figure 3: Integration of an AUTOSAR ECU in an existing vehicle network. The OEM vehicle-specific records (TP, KWP2000, diagnosis) are to be considered. Another focus lies on the integrationof the application functions. The following questions have to be answered: how can existing code be adapted to the RTEin terms of refactoring? What is the right way to integrate existing MATLAB models into the AUTOSAR device?To answer these questions, different partners participated in this project: Volkswagen AG  Integrate OEM-specific software into the AUTOSAR Basic Software; ECU system integration andtest within the serial car HELLA  Build ECU hardware; hardware test, configuration, and initial startup of AUTOSAR BSW;application integration The MathWorks  Deliver the AUTOSAR development kit (ADK) ELEKTROBIT / 3Soft  Deliver the AUTOSAR Basic Software, including the configuration tool TRESOS NEC  Support through microcontroller V850; compiler, evaluations boards, debugger PROJECT CONDITIONS FOR THE MODEL INTEGRATION The following review shows how, within the context of the pilot project, the functions (access control) modeled in MATLABand Simulink were converted into AUTOSAR SWCs. MATLAB, Simulink, and Stateflow from Release 2006a and laterRelease 2007a versions were used. To enable the generation of AUTOSAR SWC, Real-Time Workshop  ®  EmbeddedCoder from The MathWorks was used with an appropriate upgrade for AUTOSAR (ADK). The ADK allows the importingand then exporting of SWC descriptions, in addition to the creation of automatically generated code. Thus, MATLAB andSimulink can be used as an authoring tool in the AUTOSAR process chain. Figure 4: Embedding of MATLAB and Simulink in the AUTOSAR process chain.
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!