AUTOSAR From the Automotive Industry’s Perspective

AUTOSAR from the automotive industry’s perspective

Feature innovation in automotive product development started drifting away from hardware and toward software in the 1980s. The change was slow in the beginning, but has steadily accelerated, especially since the early 2000s. From the 2010s and into the 2020s, software-defined features have proliferated in vehicles at rates never seen before. There is a great degree of diversity within vehicle product lines due to the customization afforded by software. Advanced Driver Assist (ADAS) features and autonomous Level 2, 2+, and 3 capabilities have grown rapidly and are available on an increasing number of vehicles. Vehicles are also coming to exist more within the Internet of Things (IoT), allowing connectivity with home, public, and certain private infrastructures. These innovations all drive the rapidly increasing software integration aboard a modern vehicle.

The future is coming very quickly. Currently, manufacturers can tailor a vehicle during and after its manufacture easier and with more flexibility with software, than is practicable with hardware. But there are issues inherent to the dominance and heavy use of software, and the product diversity that comes with it. Developers, suppliers, and original equipment manufacturers (OEMs) in the automotive industry must all address these issues just to keep up with the pace of change in the industry. The wide range of options now possible within each vehicle line also creates issues with managing all the different possible combinations and how they interact with each other. Adopting the Automotive Open System Architecture (AUTOSAR) is one way that manufacturers and suppliers can maintain this pace in a safe and controlled manner.

Contents:

• What is AUTOSAR?
• The AUTOSAR collaborative global partnership and organizational structure
• AUTOSAR and managing the scale of electronics
• Motivation for the adoption of AUTOSAR
• Summary

What is AUTOSAR?

AUTOSAR is a unique design instrument for developers of embedded controllers in automotive applications. When one says “AUTOSAR,” they could be referencing the architectural toolset, the software design process, or the collaborative global partnership of interested manufacturers and their suppliers. Since all three of these aspects of AUTOSAR have the same goals and are interrelated, this is not as confusing as it may seem at first glance. We will see these organizational goals and the structure of the partnership in the next section.

Architecture and the software design process

For the moment, to frame the answer to “what is AUTOSAR?” in slightly different terminology, consider a person buying a particular bolt to fit a device or assembly. The bolt must precisely fit the exact machined threads that already exist in his device. If this person were to go to a hardware or supply shop, he would not want to tell the store clerks how to make the bolt, or wait for them to do so on some machinery in the back. He already knows that bolts exist in multiple standardized configurations of length, diameter, thread type, and other specifications. There is no need to instruct the store employee how to build the bolt, but only to tell them which one he wants. All that is needed is to request the specific configuration that fits his existing requirements. AUTOSAR, as an architecture tool for software, performs a function much like this. It provides multiple specific and standardized configurations of software for a developer to use. With anywhere from twenty-five to one hundred embedded electronic control units (ECUs) in a modern vehicle, utilizing a standard software delivery mechanism and architecture is important for everything from functional safety to cybersecurity.

A standardized electronic architecture

As the automotive industry moves toward autonomous driving, every aspect of the electronics onboard becomes safety-critical, making standardized electronics architecture a factor that overlaps with functional safety. With the future fast approaching, the world is moving towards vehicles becoming independently driven. Even were it not, the industry should have standard ways of producing components. Software developers should not operate in a vacuum, so to speak, any more than the machinist producing standardized bolts should do. The individual machinist, or software developer, delivering work to their personal or internal quality standards, even if those standards are especially good, isn’t realistic at the volume required for production. The process should be set to an industry-wide standard to ensure outbound quality, especially as the scale of electronics continues to grow.

The “O” in AUTOSAR stands for “open.” However, AUTOSAR is not “open” in the sense that Linux or other open-source software is open. Instead, AUTOSAR is “open” in the sense of the architecture the platform uses, as opposed to a “closed,” or proprietary architecture. This design is intended to be expanded and upgraded. Components, or chunks of code, can be swapped in and out easily. The application interfaces are all standardized and open, allowing developers and manufacturers to use, reuse, and exchange software between applications far more easily than before.

It is also important to note that “open” does not mean “vulnerable,” at least not in the context of automotive ECU programming. The AUTOSAR architecture standard works to assist and maintain cyber security. Security protocols that are part and parcel of the standard include secure coding guidelines, network security, and overall hardening measures meant to deflect cyber attacks. Beyond this, as AUTOSAR encourages collaboration among peers, there are avenues to share intelligence regarding cybersecurity threats, making defense against vehicle hacking a collaborative and industry-wide effort.

The AUTOSAR collaborative global partnership and organizational structure

The AUTOSAR partnership came together in 2003 to promote a standard for electronic and software architecture throughout the automotive manufacturing industry.

The original core partners were:

• Volkswagen
• Continental AG
• Siemens AG
• Robert Bosch GmbH
• BMW
• Daimler AG

While the original lineup was Eurocentric, the partnership soon expanded to US-based and Japanese automakers as well¹.

Today, Premium Partners influence the design and development of the standards, while Associate Partners may use the standard in the production and development of their software products.

The nine core partners now also include Ford Motor Company, General Motors, Toyota, and the Stellantis group. Siemens is no longer counted as an independent core partner, since its acquisition by Continental. There are also over 350 global partner members of the AUTOSAR organization, at six distinct levels of involvement. Each different partnership type in AUTOSAR comes with its own duties and benefits.

Goals of the partnership

The partnership’s original goal was to prepare for the upcoming rise in the propagation of new technology and the massive spike in software integration by establishing and maintaining a standard of software architecture for use in the development of automotive ECUs. AUTOSAR as a partnership encouraged collaboration between partners, even if they competed in the marketplace.

While this goal is still valid and the organization is actively pursuing it, there are more recent and far more specific goals that AUTOSAR.org has also identified. In the roughly twenty years since the partnership first formed, the automotive industry has evolved in ways that were not always predictable. AUTOSAR, as a software architecture framework and as an organization, has evolved along with it. Some of the organization’s more recent goals involve integrating more defined cyber security guidelines in response to emerging cyber security standards, as well as growing and evolving threats in that area. AUTOSAR also looks ahead to creating support for over-the-air (OTA) software updates and vehicle-to-everything communication, as those new technologies begin to appear in vehicles. AUTOSAR also aims to enhance its standards to incorporate data handling and analytics. And, as OEMs pursue initiatives to streamline, and to reduce their product line variations, AUTOSAR will likely add new goals as support mechanisms for that evolution. However, many measures currently being pursued by OEMs in the interest of managing the scale of automotive electronics already fall in line with AUTOSAR from the start.

AUTOSAR and managing the scale of electronics

Even as electronics and software use in vehicles continues to propagate at explosive rates, OEMs and suppliers are working to manage the scale of integration. One tool for this is AUTOSAR, but in this case it is only one of several. The consensus is that automakers (or their suppliers) cannot continue to deliver – i.e., to use, program, integrate, or manage – software in the same way that the automotive industry has always done so in the past.

In this era of the software-defined vehicle, there has been a significant expansion in the quantity and variety of different ECUs among body electronics, IoT communication, infotainment, engine or powerplant management, and more. The number of ECUs installed (or number of ECUs currently active) can vary even within a specific model line by the exact options which the vehicle was built with, or which features may have been switched on via purchase after the sale of the vehicle. All told, the lines of code embedded in these controllers can number in the hundreds of millions.

Currently, most if not all OEMs have initiatives in place to streamline and reduce the current number of vehicle platforms as well as the number of controllers in use per car. Some of the motivation for these initiatives stems from a need to speed up development times, reduce the time to market for newly developed features, and find greater pricing power. However, also, it is a measure to manage, if not decrease outright, the complexity of new vehicles in an environment where it has grown more difficult to keep up with the pace of change.

Motivation for the adoption of AUTOSAR

OEMs began adopting AUTOSAR very early. The original partnership was made up of several, and now seven out of the nine core partners of AUTOSAR are OEM enterprises. Their motivations in 2003 are still valid reasons to adopt the platform, but there are others now, as AUTOSAR has been around in the automotive manufacturing world for so long and has so many adherents.

Adopting the platform unlocks modular and component-based design capabilities, as well as the possibility of reusing software components (modules) or collaboratively reusing components developed by other partners and placed in a collective library. Many of these software modules can be ported across different hardware platforms, speeding development and falling in line overall with the OEMs’ initiatives to streamline product lines. AUTOSAR compliant architecture is scalable and adaptable to future hardware, since the software is largely abstracted of hardware-specific details. The modules can be quickly adapted to upgraded hardware without massive re-engineering.

Improved relationships with key suppliers help OEMs meet their deadlines for development and market delivery, pulling more value from the supplier. From the beginning, a key factor in AUTOSAR has been its collaborative nature, leading to what are essentially pocket partnerships of suppliers to a particular OEM so they can combine their efforts. The suppliers enjoy faster development and on-time delivery, and the OEMs, collaborating with the suppliers, ensure that the software meets AUTOSAR standards as well as the OEM’s specific needs.

Summary

Since modern software-defined vehicles run on software, efforts must be made to keep that software efficient, uncluttered, and secure. And it must be delivered as rapidly as possible. AUTOSAR is a powerful tool for suppliers and manufacturers to accomplish these goals in their automotive control module software development. This modularity, collaboration, and standardization can lead to advances in software for the innovations of the future while helping developers manage the technical complexity of today’s modern vehicles.

1.  https://www.autosar.org/about/partners/core-partner