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.
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:
AUTOSAR projects are typically robust ones that require access to highly qualified hardware and embedded software engineering talent, R&D resources, complex integrations, etc.
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.
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.
The classic AUTOSAR platform runs on a microcontroller and is divided into three main layers:
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.
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.
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:
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:
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.
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
Classic AUTOSAR platform
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
Compared to the classic AUTOSAR framework, the AUTOSAR runtime for the Adaptive Framework dynamically binds services and clients at runtime.
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:
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:
Real-time Operating System (RTOS) Team:
Drivers Team:
As a result of using AUTOSAR, we achieved:
Read more about the project here.
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.
In conclusion, the implementation of AUTOSAR in digital cockpit software development has revolutionized the way software is designed, developed, and integrated in modern vehicles.
By providing a standardized platform, AUTOSAR simplifies the development process and enables seamless integration of software modules from multiple vendors. This results in significant cost savings, faster time-to-market, and improved quality and reliability of the software.
With the increasing complexity of digital cockpits, AUTOSAR offers a flexible and scalable solution that can accommodate evolving technology and user requirements.
Therefore, AUTOSAR is becoming an essential component of modern vehicle design, paving the way for a safer, more efficient, and enjoyable driving experience.
A comprehensive overview of Vehicle-to-Everything (V2X) communication technology, highlighting its role in creating a safer, smarter, and more connected transportation ecosystem.
Sharing trends that will shape automotive software development in the months to come.
Exploring how AUTOSAR enhances the security of SOTA updates, ensuring their reliable and safe deployment in software defined vehicles (SDVs).
