AUTOSAR

AUTOSAR based Embedded Software Development

AUTOSAR (Automotive Open System Architecture) is a standard for the development of software for vehicle functions. It has come to light as a serious necessity, which tackles the issue of software complexity, software development redundancy, and software life-cycle management.  Major OEMs (BMW, DaimilerCrysler, Volkswagen, Ford, etc.) and suppliers (Bosch, Continental, etc.) saw this as an opportunity to resolve it and in 2003 founded the AUTOSAR Standard under the motto "Cooperate on standards, compete on implementation" at the global level. Their common mission is to create a development environment for industry collaboration on basic software functions while providing a platform to encourage innovative functions. Additionally, to solving software complexity, AUTOSAR addresses the issue of software scalability, portability, updating, development cost, and reliability. The AUTOSAR Standard is continually updated over time by its global members to enable development of embedded vehicle software and accommodate new features. The AUTOSAR scope includes all vehicle domains. AUTOSAR Membership levels are Core Partners, Premium Members and Associate Members. The core partners decide who is accepted into the AUTOSAR Consortium and the premium members define the standard.

stwp fig1
Embedded control software development using AUTOSAR standard and HIL testing tools

AUTOSAR Development Tools

Software:

  • MATLAB/Simulink by MathWorks (for building AUTOSAR Application Software)
  • TargetLink by dSPACE GmbH (production code generator for AUTOSAR Application Software)
  • SystemDesk by dSPACE GmbH (for AUTOSAR System design and simulation)
  • K-SAR Suite by KPIT Technologies (for ECU software integration and configuration)
  • PREEvision by Vector Informatik (for AUTOSAR System design)
  • DaVinci Developer by Vector Informatik (AUTOSAR Application Software design)
  • DaVinci Configurator Pro by Vector Informatik (for AUTOSAR Runtime Environment and Basic Software generation and configuration)
  • Trace32 by Lauterbach (Debugger Software)
  • CANoe by Vector Informatik (ECU Test and Analysis software)
  • Eclipse IDE from The Eclipse Foundation (Open Source development IDE)

Hardware:

  • HIL Simulation Hardware by dSPACE GmBH

Why AUTOSAR?

  • Scalable to different vehicle and platform variants
  • Reduces development cost
  • Enables collaboration between various partners
  • Software Portability
  • Open Architecture
  • Addresses Legal enforcement requirements especially regarding environmental aspects and safety requirements
  • Faster Development Cycle
  • More reliable software
  • Provides a road map for life-cycle maintenance of the software.

Why Servotech ?

  • Run by people with technical expertise.
  • We practice AUTOSAR based embedded software development engineering standard.
  • Software building is done using Model-based development tools (such as Matlab/Simulink) and HIL (Hardware-In-Loop) testing tools (such as dSapce and National Instruments).
  • Our goal is to bring clear task division and communication to the table to enable smooth service delivery.
  • We are experienced embedded software developers and is 20 years in the running.
  • Currently we develop Powertrain, Transmission, Hydraulic Actuations and, Driver Assistance control functions.

Basic Technical Information

AUTOSAR standard defines the communication layers between software modules and embedded control system infrastructure.  The software modules are developed for specified functionalities while having standard communication interface to other modules in the software. This results in a hardware platform independent embedded software development.

One can think of AUTOSAR compliant software as a special software library with a specific standard communication interface.   For example, a software developed which is compliant with AUTOSAR standard can be easily deployed on different platforms by different manufacturers and OEMs. The AUTOSAR standard also facilities a clear task division between OEMs and Suppliers, hence Increases the possibility of more embedded software development by Suppliers. The resulting re-usability of the embedded software results in lower cost in software development.

autosar arch
AUTOSAR Architecture - source: www.autosar.org

The ECU software based on AUTOSAR standard contains three main layers namely from top to bottom are:

  • Layer 3 - Application Layer (AL)
  • Layer 2 - Runtime Environment (RTE)
  • Layer 1 - Basic Software (BSW)

The Application Layer contains the portable software for the ECU (Electronic Control Unit). The RTE acts as an enabler of communication between AUTOSAR Application Components and, between AUTOSAR Application and BSW. The BSW contains Operating System, Standard Services, Diagnostics, Communication Modules, ECU Abstraction, Microcontroller Abstraction and Complex Drivers. A typical AUTOSAR Software Component (SWC) does not see the RTE and BSW layers virtually. Their view below them is a so-called Virtual Functional Bus (VBF). VFB specified by AUTOSAR represents the conceptual foundation for the use of BSW services and communication between SWCs. The communication of SWCs is based on the VFB, thereby SWC is ECU independent.

Slide1
Information exchange per AUTOSAR (from the view of Software components)
Slide2
Information exchange per AUTOSAR (Actual flow of information)

The modular layering of the software forms the basis for the objectives of AUTOSAR development. Application Layer’s Software Components (SWC) carries out the required function; While the codes for RTE and BSW are taken care of by prebuilt libraries defined by the AUTOSAR standard which is integrated with the Software Components using an AUTOSAR software integration application and compiling the final software for the target hardware. If the same function is to implemented in a different hardware, only the BSW and RTE modules need to be changed and, possibly minimal or no changes in Software Component; And they are integrated, compiled and then flashed to the target hardware. If the task were to be done by conventional/non-standardized software development the, most of the code would have to be rewritten. This will lead to more man-hours and resource wastage on coding and testing with the possibility of increased software bugs, simply because the target hardware for the same function being different.

Role of the Complex Device Driver

The Complex Device Driver provision in the BSW, enables new or complex demanding sections that are yet to be standardized to be contained within the AUTOSAR framework. It also helps in the migration of old ECU software to AUTOSAR implementation.

migrateautosar1
Migration of Hardware Control based on AUTOSAR implementation
migrateautosar2
Migration of an Application Algorithm and the Hardware Control to AUTOSAR implementation

AUTOSAR 4.0 Software Development

In the development process description, when mentioning AUTOSAR Tool, it is a generic reference to an Application that is used for development or design or verification or configuration or generation of software for building AUTOSAR ECU software. The ARXML files are XML files adhering to the respective AUTOSAR schema requirement and is, used as a bridge between development stages by transfer code parameters and requirements.

AUTOSAR typical tool distribution of process steps
AUTOSAR typical tool distribution of process steps - source: www.vector.com

The AUTOSAR development starts with the definition of the SWCs (Software Components) of the whole system (vehicle) using the AUTOSAR Tool. The Software Component Description file (.arxml) is generated after the definition of SWCs. Thereby the development of SWCs can commence in parallel. This ARXML file contains information with which the respective SWCs will be developed.

SWC development is done by importing the required sections of the Software Description file into the AUTOSAR Tool (Model Based Development tool) and developing using it or, by performing manual coding. If the AUTOSAR Tool supports, the SWCs are tested in MIL (Model-In-Loop) test followed by SIL (Software-In-Loop) test then, optionally PIL (Processor-In-Loop) test. RPC (Rapid Control Prototyping) can be done if the Software Development Application supports it and is seen as required for the project.

Following the definition of the SWCs, the distribution of SWCs to ECUs and networking of SWCs are done. The combination of definition, distribution and networking is called a System Design process and, a System Description file (.arxml) is generated using the AUTOSAR Tool.

AUTOSAR Methodology levels
AUTOSAR 4.0 Methodology levels - source: www.vector.com

A System Extract of the System Description file (.arxml) is extracted as a subset of the System Description file (.arxml) for the developing ECU (Electronic Control Unit) software modules (i.e. SWCs, RTE and, BSW).  By a process called “Flattening” on the System Extract of the System Description file (.arxml) where, additional SWCs are added if necessary and this resultant file obtained is called a ECU Extract of the System Description (.arxml). Further configuring this file for suitability of the implementation of the BSW and RTE Module, the ECU Configuration Description (.arxml) file is generated. Using this file and the AUTOSAR Tool, the RTE and BSW are configured, and codes for the RTE and BSW are generated for the respective ECU; Also a BSW Module Description (.arxml) file is produced.

With the completed codes of SWCs, RTE and BSW for the ECU, executable code/binaries is generated for the ECU for the target platform. Now, the ECU executable is flashed to the ECU using a supporting software. Then, HIL (Hardware In-loop) testing is done on the ECU. After successful completion of which, the ECU is ready for deployment.

Note: The SWCs for an ECU can be development can be started by extracting the relevant sections of the SWC Description file or System Description file or, the System Extract of System Description file. The ARXML file, when imported to a AUTOSAR Tool provides a framework, which conform to the AUTOSAR Standard, within which the logic control algorithm or selected prebuilt modules are implemented.

Workflow: OEM-supplier

  • The OEM creates a System Extract of the vehicle system design from the System Description.
  • Supplier modifies this System Extract to another file (ECU Extract of System Description) and configures it to ECU Description file. To generate the RTE and BSW.
  • The content of the System Extract provided by the OEM is their arbitrary decision.
Content of ECU extract provided by the OEM v3

AUTOSAR Acceptance Test

The AUTOSAR Standard Acceptance test reduces test cost and efforts. AUTOSAR provides Acceptance test that checks the SWC is in conformance to RTE requirements and BSW services. Bus behavior and protocols are also tested for conformance to AUTOSAR. It provides a methodology which can be extend further to the standard test suite. These test cases need not be run by both the supplier and customer. The AUTOSAR acceptance test does not replace other testing activities.