AUTOSAR: overview, architecture, and challenges in automotive industry

Manufacturing a car had never been a smooth ride for OEMs, even back in the old days when automobiles were all mechanical. But then, automotive electronics and safety systems started to oversee many vehicle capabilities and passenger services. With this increasing number of complex functions, in-vehicle electronics development became a daunted task. Implementing a standard with well-defined processes such as AUTOSAR was a real turning point in software engineering practices. So, what is AUTOSAR? What is its architecture made of? What's the difference between the Classic and the Adaptive platforms? Why have standardization and abstraction opened the way to new challenges for engineers? And finally, what are SodiusWillert's AUTOSAR tools? Fasten your seatbelts, and we'll tell you all about it in this blog article!

1. Why AUTOSAR?

2. Defining AUTOSAR

3. AUTOSAR Classic Layered Architecture

4. From Classic AUTOSAR to Adaptive AUTOSAR 

5. Characteristics of Adaptive AUTOSAR architecture

6. The daily challenges of AUTOSAR for software engineers: why is AUTOSAR so complex? 

7. Conclusion and quick introduction of SodiusWillert's AUTOSAR tools

Why AUTOSAR?

In the late 90s, Electronic Control Unit (ECU) software deployed by OEMs were located on different systems. Each ECU was made up of specific modules and interfaces. Indeed, software development was company-proprietary and hardware-dependent. There was no such thing as a shared architecture that could be used (and reused) by Tier 1 suppliers to develop the ECU software for car makers.   

Handling such heterogeneous subsystems into interdependent vehicle network required considerable testing effort, and errors were far too common. It was a nightmare that brought about risky software adaptations, under high time pressure.

It's also important to understand how a workflow, from design to implementation, started to require the intervention of more parties (software engineers, system architects, testers, developers, etc.) Therefore, a greater amount of data was (and this is still the case) permanently exchanged between all these stakeholders, at every step of the project lifecycle. Managing workflow, dealing with the unexpected, and finding one’s way around a huge influx of data were new and major challenges for the industry. 

And that’s just a brief insight into the daily routine back then. Ask your colleagues who experienced that pivotal moment, they surely have plenty of stories to tell.  

Facing this never-ending complexity, rigorous formalization of and standardized processes for software were then more than expected. So, in 2003, companies from automotive electronics, car manufacturers, semiconductor, and software industries, set up a consortium known as the AUTomotive Open System ARchitecture (AUTOSAR). Leading industry players such as BMW, Bosch, Continental, PSA, Mercedes-Benz, Toyota, and many others were among the founding members of AUTOSAR. Over the years, other major companies became part of the AUTOSAR community. SodiusWillert has also been an AUTOSAR partner for several years now.

Defining AUTOSAR

AUTOSAR is an open and standardized architecture framework for automotive electronics. It stands as a unique and powerful means to manage ever more complex E/E in-vehicle environments. AUTOSAR also leverages and values the quality and efficiency of automotive systems.  

It enables setting a common ECU software architecture by supporting standardized interfaces between application software and basic vehicular functions. This common "playbook" allows certain aspects of development, including reusability and transferability.  

As you can see, the long-awaited standardization is now the cornerstone of this solution. Is AUTOSAR a solution? Not really! It’s first and foremost, a standard. It can also be considered as a series of skills and expertise allowing the development of tools compatible with the existing development ecosystem. We can also call it a methodology, a language, or a partnership of leading Automotive companies. All this serves one purpose: developing standardized automotive software applications.

"I think AUTOSAR is the logical consequence of many companies working together (or against each other) for decades in a vast industry where safety (and security) are increasing issues and where complexity is going through the roof. AUTOSAR attempts to structure the cooperation between car manufacturers OEM), ECU manufacturers (TierX), software companies, and more. t is also an attempt to make software (and hardware!) companies interchangeable by structuring the data exchange between the TierX and the OEM" 

 Walter van der Heiden, CTF, SodiusWillert 

AUTOSAR Classic Layered Architecture

From 2003 to 2015, AUTOSAR Classic was the first and original established framework allowing the development of automotive software that could be seamlessly integrated into ECUs - a common framework capable of running 100 to 150 ECUs in a vehicle. The AUTOSAR standard, supported by numerous technology providers, is perfect for deeply embedded systems and application software with high requirements for predictability, safety, security, and responsiveness. Then, the trends for IoT, V2X connectivity, or automated driving took hold of the car industry and Adaptive AUTOSAR made its entrance. We'll come to that later. For now, let's uncover the main characteristic of the Classic Platform: 

• It focuses on real-time applications: More specifically, on time-critical functions such as powertrain, chassis control, body electronics, and more. This means those functions can be supported but also brings interoperability between ECUs to a new level.   

• It enhances reliability, robustness, and safety in automotive software development. Errors detection and correction tools are now the guardians of integrity in such critical systems. This explains why AUTOSAR Classic is the reference for safety-related applications. 

AUTOSAR Classic operates as a layered architecture, consisting of three layers, supporting the role of an intermediary between application software and hardware, depicting abstraction and standardization at their finest. At the bottom of this architecture stands the microcontroller (MCU), representing the hardware unit.  

Here's an overview of each layer and its main functionalities. 

Application Layer (ASW) 

ASW is the upper layer of AUTOSAR architecture, where the application software components (SWCs) stand. SWCs encompass specific vehicle features such as airbags ECUs, braking systems, etc.  

Runtime Environment (RTE) 

As the scheme below demonstrates, RTE acts as the middleware between the ASW and the BSW. Indeed, RTE is responsible for effective communication between those layers.  It abstracts the underlying hardware and software details, providing a standardized interface for the application components. 

We cannot talk about RTE without mentioning the Virtual Functional Bus VFB supports communication between SWCs and the use of BSW services. Each SWC connects with its peers and with other ECUs in a system using a low-level communication bus like CAN, LIN, or FlexRay. 

Basic Software (BSW) 

AUTOSAR's basic software architecture covers hundreds of software modules organized into different sub-layers. This includes essential services and functions, such as operating system services, communication services, memory services, and diagnostic services.  

Prior to AUTOSAR, basic software modules and interfaces were highly varied, leading to unnecessary difficulties and avoidable mistakes. Today, BSW is common to any AUTOSAR ECU (apart from minor details). It allows a supplier to share this architecture with others working on the same ECU. It is further divided into modules such as Microcontroller Abstraction Layer (MCAL), ECU Abstraction Layer, and Services Layer. 

From Classic AUTOSAR to Adaptive AUTOSAR

As we mentioned earlier, cars have been evolving again over the past decade or so. Tomorrow's cars will become true cyber-systems connected to almost everything, from your home to smart roads while autonomous driving will continue to gain momentum. Most importantly, these newest automotive trends require an unparalleled level of flexibility and connectivity.  

Understanding Adaptive AUTOSAR 

It soon occurred that  AUTOSAR Classic Platform was too rigid and limited to support these developments and architecture – now demanding higher computing performance and flexibility. Adaptive AUTOSAR's release in 2017 aimed to address these core functions.  

So, in short, AUTOSAR Adaptive Platform enables ECU applications to be developed independently of each other, in distributed workgroups. It has a functional cluster structure (see below) allowing more stable, flexible, and powerful software architectures in vehicles – an ideal environment for the dynamic and distributed nature of modern automotive systems. 

The objective consists of integrating coherently all these multiple functions​ (and more down-to-earth, finding room for all dedicated cables...)! Manufacturers began to consider using different types of controllers in cars, to integrate more functions on a single controller.  

A very well-conceived idea, because using larger (and fewer) central units that handle numerous functions in a single CPU can reduce bus load and make features easier to implement at any stage of the product lifecycle.   

Keep in mind that the Adaptative platform does not intend to replace AUTOSAR Classic. We still need sensors, actuators, and smaller controllers. The new platform improves some aspects of the old one, no more, no less.  Indeed, tools based on adaptive AUTOSAR can be added to existing AUTOSAR Classic architectures. 

Comparing the two AUTOSAR 

AUTOSAR CLASSIC – Many small ECUs all connected to each other

AUTOSAR Adaptive – Larger ECUs controlling many small sensors and actuators 

Chart’s source: Walter van der Heiden blog 

Characteristics of Adaptive AUTOSAR architecture

Service-Oriented Architecture (SOA) 

Champion of modularity and flexibility, SOA is a software design framework that focuses on creating functional and scalable software systems from individual components, referred to as services.

The so-called services interact with each other to perform tasks, such as enabling a user to sign in once and have access to a wide range of applications. Services are not deeply encoded in applications.  

Through this architecture, applications are designed to both provide and request services. This means that each application can either capture, produce, process, and communicate data. The idea behind this double role is to create a distributed system carrying multiple functions that can be reused for various and future purposes.  

Here, flexibility and dynamism take a whole new dimension! 

Seamless integration of new applications 

The most significant shift between Classic and Adaptive AUTOSAR is almost certainly the capability to download an application or add new features at any moment. Indeed, innovative automotive trends such as autonomous driving or car-to-x communication require a new level of flexibility and communication: over-the-air updates (OTA), applications upgraded to enhance the system's performance, components that offer communication with services outside the vehicle, etc.  

High-performance computing  

More specifically, Adaptive AUTOSAR is designed to take advantage of both increasing processing power and faster communication. How is such performance now achieved? 

• ECUs and virtual ECUs: It would be more accurate to replace the term ECU with "machine" as they are now true centralized machines able to support multi-core processors. ECUs can even be virtual devices using shared hardware. These larger ECUs are now controlling many small sensors and actuators (see the scheme below). 

• Ethernet:  CAN, FlexRay or LIN bandwidth is no longer sufficient for such functions. That's why Adaptive AUTOSAR uses exclusively Ethernet as its communication protocol.
  
  

C++ and Linux-based POSIX system 

The increasing complexity of systems has prompted a switch from C to C++ language. The latter delivers better support for structuring extensive and distributed systems and provides better mechanisms for data encapsulation. 

In addition, the operating system for the Adaptive Platform is the Linux-based POSIX. This is a standardized programming interface between the application function and the OS, making vehicle software development significantly more flexible. 

The daily challenges of AUTOSAR for software engineers: why is AUTOSAR so complex? 

As Walter once said in a blog post, there are many prices to pay for such levels of standardization and abstraction, and he couldn't be more right. Indeed, the standardized software architecture revolutionized the automotive industry and leveraged collaboration between stakeholders.   

Yet, it has replaced a complexity with another complexity! Engineers are now required to follow meticulous and very extended guidelines and adapt to complex architecture. To this configuration, we have to insist on how today's software industry has become ultra-competitive. The race for innovation is fiercer than ever and this is a major source of tension for project managers and their engineer's squadron.

It takes time for software engineers to train and comprehend this architecture. As you probably know too well, time is money, and it affects the deliverability of projects in an era where the product lifecycle is shrinking.  

Generally speaking, software engineers have to struggle with: 

• Focusing on creating new features and technologies instead of reinventing the wheel for each project. In clear, they need to find a way to auto-generate AUTOSAR-compliant artifacts.  
• Developing every single component without coding 
• The absence of clear and valuable documentation and guidelines 
• Gathering in one model, the multiple architectures resulting from the coexistence of Classic and Adaptive AUTOSAR 
• Integration with other existing AUTOSAR tools. 

Conclusion and quick introduction of SodiusWillert's AUTOSAR tools 

No further doubts, car manufacturers and suppliers need to be at the cutting edge of software development while complying with increasingly demanding standards. AUTOSAR must therefore be as easy to use as possible. 

For several years, IBM Engineering took on this challenge by developing and delivering the IBM Engineering Systems Design Rhapsody – AUTOSAR Extension (enabled by SodiusWillert). Our tools enable a seamless integration of AUTOSAR standard in your IBM’s Rhapsody Model-Driven Development environment. Why did we choose such an approach? Our priority was to provide acceleration and simplification within the automotive software development process.  

With this combination, developers can now focus on creating highly demanding applications without struggling to switch from one language to another and to code every single component. We then ambitioned to bring extensibility and seamlessness within your favorite Model-driven environment and to rely on automated features.  

To find out more, have a look at our product pages and watch the replay of the webinar, organized by 321 Gang and presented by Walter van der Heiden (SodiusWillert & Moshe Cohen (IBM).