Tuesday, March 17, 2015

Why AUTOSAR? - Part 2 (AUTOSAR Methodology)

In an earlier post, Why AUTOSAR - Part 1, I described some of the major aspects of AUTOSAR.  In this entry I will attempt to explore some of the benefits of AUTOSAR.

Benefits of the AUTOSAR Schema and Methodology

AUTOSAR specifies a schema (data model), along with development methodology that aid in the development of automotive ECUs.


The AUTOSAR schema is sufficiently detailed to specify the architecture and implementation of an entire system, consisting of multiple ECUs.  The schema is sufficiently detailed enough to allow for the specification of software components and compositions, interfaces, data types, network topology, ECU deployment, OS Configuration, and Basic Software configuration.  This information is stored in AUTOSAR XML format.  One important benefit of this well defined schema is that it provides us a language to usefully describe the system.

For example, the description of a software component is now unambiguous.   The architect can describe a software component, the data it sends and receives, and some details on its internal behavior in AUTOSAR XML format (with the help of tooling).   This Software Component Description provides essentially everything a software component developer needs to understand how his component interacts with the rest of the system.

In conclusion, the AUTOSAR schema is sufficiently detailed to stipulate the architecture and implementation specifics of an automotive ECU.  Next, let's look at how this schema can be used as part of a development methodology.

Development Methodology

The AUTOSAR methodology helps specify some workflows for different roles involved in the creation of an AUTOSAR ECU.

  • For the Systems Engineer (generally at OEMs), the system can be described in terms of software components and their connections.   Essentially, he/she can describe what the system should do.  In the diagram below, this can be seen as the "Virtual Function Bus (VFB)" view.
  • A Systems Engineer can then add network information, and deploy the software components onto ECUs.  This information can be bundled into something called an Extract.  The Extract can then be shared with the software teams for implementation.  Therefore,  AUTOSAR gives us a language for describing system and architectural constraints that can be processed further into an implementation.

  • The software development team (generally at Tier-1s) can now start with the Extract provided to them.   
    • Software Component Implementation:  Using the Software Component descriptions in the Extract, the developer can begin work on creating the component implementations.   One advantage to this approach is that the schema contains the necessary architectural constraints (interfaces, internal behavior), and eliminates the need for manual translation from specification to implementation.  This also ensures a smoother integration since the interfaces between all components have been codified in the schema.
    • Basic Software:  Here, we see another benefit.   In the past, an OEM might share a CAN dbc file for network description, or a specification for diagnostics configuration.  The software team would then have to process that information into their low level software (usually manually).  In AUTOSAR, with the help of tooling, this step can be largely automated.   The information in the Extract can be translated into BSW configuration quickly and accurately, thereby reducing potential errors.  
    • RTE and OS:  Next, the RTE is configured.  Here, the integrator, or architect, can decide details such as: number of OS tasks, priorities, mapping of component runnables to tasks, etc.  Once this configuration is completed, the RTE is generated.   As part of the generated RTE, an "OS Needs" file is generated.  This file can be directly imported into the OS generation tooling, again reducing the need for manual configuration.
In conclusion, the AUTOSAR schema and methodology allow a structured and well-defined software development workflow.  Additionally, the schema provides an agreed upon language between different functional areas that can reduce the manual steps common in legacy architectures.