Tuesday, November 18, 2014

Why AUTOSAR? - Part 1

As AUTOSAR gains momentum in the automotive community, you may still be wondering whether it’s a good idea for your company and what benefits it will bring. And it’s just as important to understand the potential drawbacks as well.

The answers, of course, depend on whether you’re an OEM, Tier 1 or Tier 2, and are different for each case. The best approach is to first describe what AUTOSAR is and then consider the varying viewpoints.

In this blog entry, let’s focus on the “what”.

What is AUTOSAR?

AUTOSAR is essentially a collection of specification documents (approximately 200 in all), specifying three major areas:

1) Software Architecture:  

Layered software architecture allowing complete abstraction of application from lower level implementation details. Additionally, a standardized and complete basic or environmental software stack for ECUs – the AUTOSAR Basic Software – is specified.

While layered software architectures are not a new concept, what AUTOSAR provides is standardization. This standardization ensures a consistency between competing solutions as well as interoperability. The major areas defined by AUTOSAR are:

  • Component Template – Provides a specific way to describe a software component. This includes details on the component’s interfaces as well as its internal behavior.
  • System Template – Provides a specific way to describe a system of software components as well as any details regarding what lower level services those components may need.
  • Run-time Environment (RTE) – Can be thought of as the “glue code” that abstracts the lower level interfaces to the application. This includes access to network data as well as scheduling of the application software “runnables”.
  • Operating System – The AUTOSAR OS specification is based on the prior OSEK standard, but can provide some advanced functionality such as memory and timing protection.
  • Basic Software – The basic software in AUTOSAR is organized into three layers: the Microcontroller Abstraction Layer (MCAL), ECU Abstraction Layer and the System Services Layer. The specifications for these modules typically describe the API, the file structure, and the configurability details.

2) Systems/Software Methodology (Data model, workflows):  

Exchange formats & templates to enable a seamless configuration process of the basic software stack and the integration of application software in ECUs, including the methodology for using this framework.

The top diagram above depicts the methodology used in creating an AUTOSAR system. Briefly, the VFB view shows an entire system described as a set of components (or functions), and how they communicate with each other via a Virtual Function Bus (VFB).

The lower diagram shows those components deployed to one or more ECUs. The RTEs and Basic Software in each of these ECUs need to be configured to realize the VFB.

This configuration step is greatly enhanced by the xml-based exchange format that AUTOSAR has defined.

3) Standard Application Interfaces:

Specification of interfaces of typical automotive applications from all domains in terms of syntax and semantics, which should serve as a standard for application software.

Next time, we’ll go into more detail on each of these items and the potential benefits and drawbacks.