How AUTOSAR Streamlines Digital Cockpit Software Development

Today's automotive trends such as autonomous driving, v2x connectivity, over-the-air (OTA) updates, predictive maintenance, and others are based on in-vehicle software functions. For all these functions to run smoothly and generate real-time data, each engine control unit (ECU) must work efficiently. Modern high-end vehicles have up to 100 ECUs that communicate via CAN bus, CAN FD, or Ethernet to support complex vehicle functions and ensure driving safety.

Previously, the ECU software used by OEMs was on different platforms. There was no standard software architecture that Tier 1 suppliers and their software vendors could use to develop ECU software for OEMs. Whenever an OEM wanted to switch to a new Tier 1 supplier, the transition was in dire straits. The new supplier struggled to understand the existing software architecture, hardware platforms and standards used in ECU software development. As such, it was almost impossible for a new supplier to kick in and manage an ongoing project in the middle of its production cycle.

To facilitate coordination between OEMs and vendors, improve the quality of ECU software, and reduce development time and cost, Tier 1 suppliers, semiconductor manufacturers, software, and tool vendors came forward in 2003 and formed a consortium called Automotive Open System Architecture (AUTOSAR).

This article will look into the main principles of AUTOSAR architecture, how automotive software projects benefit from it and where to source AUTOSAR engineering talents for digital cockpit solutions development.

Contents

What is AUTOSAR?

AUTOSAR is an open automotive software architecture that supports the standardization of interfaces between application software and core automotive functions and helps establish common ECU software architecture for all AUTOSAR members.

AUTOSAR is designed to provide automotive companies with inherent benefits for managing increasingly complex electrical/electronic (E/E) environments such as easy integration and sharing of functions across a complex ECU network and control over the entire product life cycle.

AUTOSAR doesn’t prescribe the exact order in which development activities should be performed. AUTOSAR doesn’t talk about the process, the business model, or “roles” and “responsibilities.”

Instead, AUTOSAR has the following objectives:

  • Fulfill future vehicle requirements, such as availability and safety, software upgrades, and maintainability.
  • Increase scalability and flexibility to integrate and transfer functions.
  • Increase a higher penetration of “Commercial off-the-Shelf” software and hardware components across product lines.
  • Create reusable software.
  • Accelerate development and maintenance of features.
  • Improve containment of product and process complexity and risk.
  • Optimize costs.

AUTOSAR Applications

  • Infotainment apps.
  • Sensors like LIDAR and RADAR.
  • Predictive Maintenance.
  • Electrification.
  • ADAS Functions with a Camera.
  • v2x.
  • Map updates.
  • Automotive Apps.

Advantages of using AUTOSAR in automotive solutions development

  • Seamless software sharing between different companies/teams in the case of distributed development.
  • Reusable software components and program code, which can help save costs from not having to build them from scratch.
  • The underlying software architecture is layered.
  • Interface consistency.
  • Cross-compatibility of components.
  • Design flexibility.
  • Reduced cost and development time.
  • Efficiency increase through functional development.
  • Transparency and clear interfaces enable the creation of new business models.
  • Easier handling of the rapidly growing electrical/electronic (e/e) complexity associated with ADAS.
  • Improved security and quality due to error detection early in the software development life cycle (SDLC).

Challenges of using AUTOSAR

  • Complexity

AUTOSAR projects are typically robust ones that require access to highly qualified hardware and embedded software engineering talent, R&D resources, complex integrations, etc. 

  • High initial investment

There’s an acute shortage of embedded software developers, so finding, hiring, and retaining an effective AUTOSAR development team in-house requires a high initial investment. Leveraging offshore/nearshore specialists and augmenting AUTOSAR teams with experienced talents overseas can be an effective solution to keep costs lower without compromising on quality.

  • Steep learning curve

AUTOSAR developer pool is highly limited globally so companies have no other choice but hire hardware and embedded software developers and train them to use the AUTOSAR architecture. It implies a pretty steep learning curve, which may slow down time to market or affect the quality of solutions.

AUTOSAR is an ever-evolving standard that defines layered software architecture. There’re two types of the AUTOSAR Platform: Classic (current release R21-11) and Adaptive (current release R21-11).

Let’s take a closer look at each.

AUTOSAR Classic Framework

The classic AUTOSAR platform runs on a microcontroller and is divided into three main layers:

  • Application layer
  • AUTOSAR runtime
  • Basic software architecture

AUTOSAR Application Layer

The application layer is the first layer of the AUTOSAR software architecture that supports the implementation of user functions. This layer consists of certain software components and many applications that perform specific tasks according to instructions.

The AUTOSAR application layer consists of application software components, software component ports, and port interfaces.

AUTOSAR provides standardized interfaces to application layer software components, and application software components help build simple applications to support vehicle functions.

Communication between software components is carried out through certain ports using a virtual functional bus. These ports also facilitate communication between the AUTOSAR Base Software (BSW) and software components.

The AUTOSAR architecture described above is its classic platform that supports real-time requirements and security constraints. The microcontroller-based classical platform can support networking and security applications by allowing control units to access vehicle sensors and actuators.

AUTOSAR Runtime Environment (RTE Layer)

The AUTOSAR runtime is a middleware layer of the AUTOSAR software architecture between the BSW and the application layer, providing communication services for the application software.

Basic Software Architecture (BSW)

The basic AUTOSAR software architecture consists of hundreds of software modules structured at different levels and is common to any AUTOSAR ECU. This means that the supplier that developed the BSW can share it with other suppliers working on engine ECUs, gearboxes, etc.

The basic software architecture in AUTOSAR consists of three layers:

Microcontroller Abstraction Layer (MCAL)

Also known as Hardware Abstraction Layer, MCAL implements an interface to a specific microcontroller. MCAL has software layers integrated with the microcontroller via registers and provides:

  • system drivers, 
  • diagnostic drivers, 
  • memory drivers, 
  • communication drivers (CAN, LIN, Ethernet, etc.), 
  • I/O drivers, and more.

 

ECU Abstraction Layer

The main purpose of the ECU abstraction layer is to provide higher levels of ECU-specific software. This layer and its drivers are independent of the microcontroller while being dependent on the ECU hardware. It provides access to all peripherals and ECU devices that support functions such as memory, communication, I/O, etc.

Services Layer

This is the topmost layer of the basic AUTOSAR software architecture. The services layer is an operating system that runs from the application to the microcontroller underneath. The OS has an interface between the microcontroller and the application layer and can schedule the execution of different application tasks. The service layer is responsible for

  • network services,
  • memory services,
  • diagnostic services,
  • communication services,
  • ECU health management, and more.
AUTOSAR classic architecture

Classic AUTOSAR platform. Source: autosar.org

Are you looking to hire an experienced AUTOSAR development team for your automotive software project?

AUTOSAR Adaptive Framework

The adaptive architecture of AUTOSAR comes with a central application server that facilitates high-performance computing. The Ethernet-based ECUs in this system support real-time functions. Adaptive AUTOSAR is scalable and has a dynamic architecture where applications can be updated throughout the vehicle’s life cycle. This allows OEMs to deploy high-tech software features in the car and update them wirelessly when needed.

The AUTOSAR Adaptive Framework implements the AUTOSAR Runtime for Adaptive Applications (ARA). Two types of interfaces are available: services and APIs. The platform consists of functional clusters that are grouped into services and the AUTOSAR adaptive basis.

Functional clusters

  • assemble Adaptive platform functionalities,
  • define requirements specification clustering,
  • describe software behavior from application and network perspective,
  • do not constrain the final software design of the architecture.

 

Compared to the classic AUTOSAR framework, the AUTOSAR runtime for the Adaptive Framework dynamically binds services and clients at runtime.

adaptive AUTOSAR architecture 

Adaptive AUTOSAR framework. Source: autosar.org

Example of using AUTOSAR for digital instrument cluster development

A world’s leading automotive Tier 1 supplier once hired our Automotive Software Team to build two instrument clusters for two of the biggest car manufacturers globally. There was no clarity in regard to the specifications and the technologies. In addition, we had to work in a 100% distributed environment where communication and constant synchronizing with other teams were the key elements for success. 

In particular, our rinf.tech team was responsible for the following jobs:

  • Embedded programming in C,
  • AUTOSAR modules integrations,
  • Hardware bring-up for new Hardware Instrument Clusters,
  • Vector tools for AUTOSAR.

 

To support our client in their automotive dev journey, we engaged engineers with different skillsets to work together using an Agile methodology, Cycle-V process and following ASPICE policies. 

We divided the project team into three subteams, and assigned certain tasks to each:

Applications Team:

  • Illumination – controls the PWM for led
  • Pointers – controls the pointers (speed, RPM)
  • Button – handles the input from Board Computer button
  • Check Controls – controls the fault indicators
  • Dimming – controls the intensity of the PWM
  • Odometer – counts the trip and the total kilometers traveled
  • TMM – time control
  • Board computer – consumption, trip info, range
  • LDM – adaptive cruise control, dynamic cruise control Tasks for Drivers Team
  • Complex device drivers (MCU, Head-up Display, Real Time Clock, Sound, InputOutput Controller)
  • SAFETY Controller
  • CAN Wrapper
  • Diagnostics
  • Power Management
  • Inter-processor Proxies (between Control and Graphics Processors)
  • AUTOSAR Core Components integration and configuration
  • Hardware Bring-up

 

Real-time Operating System (RTOS) Team:

  • CAAM crypto driver for iMX6
  • AVB stack
  • RDA encryption
  • MOST communication
  • IPSEC certificates
  • SOMEIP components
  • NAND/NOR/Filesystem code
  • Integrity OS
  • DLT
  • IPC encryption
  • HUD
  • HMI
  • VideoDecoder/Renderer updates
  • CoreDump implementation
  • CarModel code
  • Bootloader code

 

Drivers Team:

  • Complex device drivers (MCU, Head-up Display, Real Time Clock, Sound, InputOutput Controller)
  • SAFETY Controller
  • CAN Wrapper
  • Diagnostics
  • Power Management
  • Inter-processor Proxies (between Control and Graphics Processors)
  • AUTOSAR Core Components integration and configuration
  • Hardware Bring-up

 

As a result of using AUTOSAR, we achieved:

  • 50% faster deployment of new features,
  • 100% compliance with our client’s tools, standards, processes and methodologies,
  • Record time in taking over the ownership of two major projects, which allowed the client to focus on more pressing deliverables.

 

Read more about the project here.

Where to source qualified AUTOSAR developers?

AUTOSAR is mostly about hardware and embedded software development, so when we speak about AUTOSAR developers, we mainly refer to embedded developers with AUTOSAR experience.

Currently, application development seems to be a more popular career option than embedded software development. This is partly due to the extremely high demand for custom app development among businesses and a lower entry threshold due to a more flat and faster learning curve for job switchers and re-skillers. 

This means that the pool of resources for good embedded software developers is relatively small, and we often see engineers moving between companies on a regular basis looking for new challenges and opportunities. For any technology business, the loss of complex engineering expertise can be costly, as most often the engineer takes the knowledge away when they quit.

Although many automotive companies really need AUTOSAR skills, finding the good ones is a huge challenge. For instance, our clients are looking for seasoned developers with three to five years of AUTOSAR experience to join their teams to drive projects forward and help train teammates. 

Given the current war for engineering talents and the global shortage of hardware and embedded software developers, the chance is slim to find senior specialists with firsthand experience with AUTOSAR fast and cost-effectively. As per a recent survey by Infragistics, more than a third (40%) of software industry professionals across all domains and verticals are facing increased customer demands, and 39% are working with limited resources due to talent shortage and lack of budget to match their salary expectations. 

From a developer perspective, a typical path to AUTOSAR is as follows: an embedded software engineer (skilled in C, C++, and CAN) gets a job at an automotive OEM or joins a dedicated automotive software team on the vendor’s side, where they’re introduced to and trained in the AUTOSAR software architecture by AUTOSAR-skilled colleagues. AUTOSAR skills can hardly ever be gained without getting a deep dive into real-world AUTOSAR development projects.

At rinf.tech, our Automotive Division has been building and delivering custom AUTOSAR-based solutions for a while, so we have access to a vetted pool of hardware and embedded software engineers who “speak the AUTOSAR language” and can be available to join your project upon your request.

Looking for a technology partner?

Let’s talk.

Related Articles