Implementing AUTOSAR and Functional Safety

Implementing AUTOSAR and Functional Safety

Functional safety (derived from the international standard ISO 26262: Road vehicles – Functional Safety), as a concept of risk mitigation, encompasses several other standards. Though written for different purposes, these other standards sometimes overlap with ISO 26262 in their application or implementation. This does not necessarily mean that an organization that either complies or attains certification to one standard has automatically complied with another, even if some of its requirements overlap.

However, some organizations have had success implementing functional safety together with the AUTomotive Open System Architecture (AUTOSAR) standard and platform, and others might be wondering if doing the same would be worthwhile for their company. Both the Classic and Adaptive Platforms of AUTOSAR were designed with functional safety as a prime consideration from the beginning, making the two standards easier to implement together, whether simultaneously or along a selected timeline.

This article will help to outline and clarify the benefits of synergistically implementing AUTOSAR and functional safety together as cooperative domains. Understanding how these standards work together with, and complement, one another can help organizations unlock the potential of both.

Contents

• How does AUTOSAR overlap with functional safety?
• Why has software complexity grown exponentially?
• Benefits to an organization of integrating AUTOSAR with functional safety.
• Summary

Compared to the earlier days of embedded controls and onboard software in automotive applications, in the 1990s to early 2000s, for example, automotive software has seen what some experts call exponential growth in the quantity and complexity of the code in use.

AUTOSAR was itself originally designed to help tame the chaos and manage the increasing scale of automotive electronics. In the past decade, however, the complexity and scale of software integration have outgrown early attempts to contain it. The increasing complexity of onboard software is now outpacing the capabilities of hardware to keep up with it, and additionally outstripping the capabilities of developers to manage it and keep it safe.

Automotive Original Equipment Manufacturers (OEMs) have begun to use AUTOSAR in a slightly unexpected application, as a way to reduce product line platforms to a more manageable number and then use software as a modular method of differentiating their tiers, trim levels, and configurations. Functional safety has been a key driver for AUTOSAR implementation, but that explicitly does not mean that rolling out AUTOSAR compliance in one’s organization will automatically make the organization ISO 26262 compliant as well.

How does AUTOSAR overlap with functional safety?

AUTOSAR is an architectural framework which we can build software on, which helps provide industry-wide standard formatting. While AUTOSAR is widely adopted in the industry, the fact remains that the increasing growth in code complexity demands a standardized architecture to reduce the growing complexity, and to manage it. Developers and programmers for automotive controller software cannot operate as if they are in a vacuum and deliver only to their personal or company-internal standards and architecture, even if those are quite good. The more suppliers and OEMs adhere to AUTOSAR, the more firmly the standard becomes established as the state of the art, ensuring a global system in which the industry as a whole can “cooperate on standards, and compete on implementation,” as the AUTOSAR slogan states.

AUTOSAR was built and standardized with functional safety in mind, and functional safety is the process we should follow when we build our complex electronic control unit (ECU) software on that industry-standard framework. With between twenty-five to over a hundred possible control units on a given vehicle, even if an ECU is not used for a safety-critical feature, it still benefits from adherence to the functional safety standard.

Part of what is driving code complexity (our starting point) is the fact that more features on more vehicles are falling into the “safety-critical” category. This is in turn partly due to the expansion of Level 2, 2+ and 3 autonomous features, also known as ADAS. Fully autonomous vehicles are becoming more plausible, and OEMs are bringing vehicles with Level 3 and 4 autonomous features to the market.

The higher proportion of autonomous or semiautonomous features means that more features on any given vehicle have the potential to land in the “safety-critical” category. This places them under the “jurisdiction” of the functional safety standard and causes the overlap between the functional safety and AUTOSAR standards to increase.

Why has software complexity grown exponentially?

To be clear, the problem is not only that the quantity of code involved in onboard ECUs has increased drastically in the last two decades, but also that the code which exists is exponentially more complex. There are multiple factors which, taken together, can account for the exponential growth in the complexity of onboard ECU software. We can concentrate on three broad categories: feature expansion; connectivity via the Internet of Things (IoT); and Artificial Intelligence (AI) and machine learning.

• Feature expansion: modern smartphones are many evolutions beyond the rotary-dialed devices which once occupied a small desk in a nook in many homes. Similarly, today’s software-defined vehicles are vastly different from the carbureted cars and trucks that people drove in the 1970s and 1980s. New features like the graphic user interface (GUI), or Advanced Driver Assistance systems (ADAS) like smart cruise control rely on a wide array of ECUs, both to collect data, and as controllers. From the GUI or even a phone, a driver can affect the behavior of the vehicle in ways that, in the past, were only possible with a physical controller. The ADAS features themselves can affect the behavior of the vehicle without input from the driver. The coordinated actions of these multiple ECUs require increasingly complex software to keep all the features running right, maintain safety, and provide the desired user experience for the driver.
• IoT and connectivity go beyond “just another feature,” as they represent the coordinating effort to support communication between vehicles and one another, or the overarching infrastructure around them. In many instances, the increasing connectivity – and its attendant complexity – of the vehicle is what enables the expanded features above to function.
• AI and machine learning are technologies still in their infancy. As these technologies continue to develop, they will be integrated into increasing numbers of features. AI will also go into further applications in the vehicle that may be invisible to the end user – using it, for example, to control the power inverter switching in an electric vehicle (EV) or hybrid. The computing power demands and the increase in complexity resulting from AI and machine learning integration will continue to be significant. Using the AI in the previous example to control so-called “soft switching” largely solved the problem of heat loss in EV power inverters, but brought an additional degree of complexity to the motor controller software.

Benefits to an organization of integrating AUTOSAR with functional safety

Adhering to, or, even better, gaining certification in, both AUTOSAR and functional safety is a good way for an organization to increase relevance in the marketplace.

Much like a key and a lock, functional safety and AUTOSAR often appear to be made to fit one another. Where one is low, the other is high. AUTOSAR’s frameworks are built to allow ISO 26262-approved process inclusion, so adding code required by functional safety, as needed, is much simpler. Combining certifications and adherence to both the AUTOSAR and ISO 26262 standards can bring an organization a plethora of benefits. AUTOSAR’s built-in safety and security facets are excellent for helping implement functional safety because AUTOSAR was designed to work both with or without a concurrent functional safety plan; its standard components follow ISO 26262 guidelines in many if not all cases. ISO 26262 contains software architecture requirements, for when that software falls into the “safety-critical” category and becomes subject to the functional safety standard. These specifically include requirements for software component hierarchical structure, scheduling properties, and appropriate management of shared resources. The AUTOSAR architecture provides for all these requirements.

AUTOSAR has safety mechanisms included which make it especially compatible with functional safety, including fail-safe functions, End-to-End (E2E) communication protection, memory partition supports, and data flow managed by trusted functions certified to a particular Automotive Safety Integrity Level (ASIL), the risk classification system defined in ISO 26262. AUTOSAR can help standardize not only development but also testing. With the standardized architecture and development platforms, AUTOSAR makes it easy to automate software testing, which is a critical part of implementing functional safety and in ensuring the reliability of software components throughout a vehicle.

Summary

As more decisions in modern vehicles are made through AI, moving data through those systems is crucial. Making sure that information is transferred in the most rapid and error-free manner, and as safely as possible, is of vital importance. Combining functional safety with AUTOSAR helps OEMs and suppliers design within a standardized architecture in a safe and controlled manner; this technology integration is a specialty of LHP. AUTOSAR (AUTomotive Open System Architecture) is one facet of the LHP Functional Safety Ecosystem, an interconnected system of complementary technologies designed to place safety, standardization, and automation at the forefront of our clients’ software development processes. AUTOSAR and functional safety together help build a scalable mechanism, and a standardized, specific method of designing, programming, and testing software, to control the quality and safety of the hundreds of millions of lines of code currently in play in modern production software-defined vehicles.