The goal of AUTOSAR is to not only introduce standardization in the development of software but also to the whole development process, from functional description to software testing. As such, it uses a top-down design approach as follows:

• Complete system and product definition including hardware, software, and system constraints
• AUTOSAR software component allocation for each ECU
• Configuration and development of AUTOSAR OS, basic software, drivers, and applications on each ECU
• Conformance testing to validate the behavior at unit, component, and system level

The above approach helps with ease of use, upgrade, and modification while reducing the cost of development and time to market without compromising on quality. It also enables reusability and exchange of software components across suppliers and OEMs without changing the hardware.

AUTOSAR provides an opportunity to many new and existing suppliers to become relevant in the ecosystem of Automotive vendors, who generally provide reusable components. While reusability of software components reduces the cost of development and ensures stability, it also runs the risk of propagating the same defect or vulnerability of the software in products where the same code is used. AUTOSAR champions safety and security aspects in the software architecture to address this critical issue.

Functional Safety
ISO 26262 or popularly known as Functional Safety (FuSa) became an integral part of Automotive product development and embraced by AUTOSAR. The goal of Functional Safety is to ensure that every possible safety related issue is identified, documented, and appropriate action is defined to address the issue when it occurs. Functional Safety guidelines detail the different product lifecycle processes such as management, development, production, operation, service, and decommissioning. It also provides guidelines at different levels of the product such as system, hardware, and software.

In Automotive products, Automotive Safety Integrity Level (ASIL) defines different levels such as Q, A, B, C, and D to appropriately bucket the type of safety needed to be achieved in different parts of the product. Functional Safety provides guidelines for different ASILs. During the development of the product, each logical and physical part of the product is analyzed, and requirements are defined to achieve the appropriate ASILs. Standard software components of AUTOSAR also follow the same guidelines and comply to the requirements for appropriate ASIL.

Functional Safety provides guidelines and mandates required features for hardware and software components to achieve necessary safety levels. Some such features have been highlighted below:

1. Handling separate microcontroller cores: Although AUTOSAR was designed keeping single core microcontrollers in mind, with time multi-core microcontrollers became extremely popular because of their computing power. AUTOSAR embraced the multi-core microcontrollers and provides for the isolation of safety core and general core. Safety core runs AUTOSAR applications and services which are more critical and uses standard interfaces of AUTOSAR components, while general core runs application and other components such as complex device drivers, which do not use standard interfaces.
2. Memory Partitioning: Memory partitioning is an important feature of AUTOSAR which specifies that applications use private memory spaces to avoid interaction with other applications running in the system. This feature is also used along with core separation to achieve the necessary ASIL.
3. Timing Monitoring: With combination of internal and external watchdog, AUTOSAR provides a facility to monitor the timing of program execution at different points. Appropriate actions can be taken if the defined execution time is not met.
4. Failsafe Communication: AUTOSAR defines virtual function bus (VFB) architecture to provide communication interface for different applications. As per the Functional Safety guidelines, it provides end-to-end protected communication (E2E protection) over VFB with guaranteed payload delivery, tracking, and other safety mechanisms.
5. Safety at system level:Functional Safety also provides guidelines for behavior at the system level. AUTOSAR network management is one such example which defines the behavior for individual ECUs with respect to the system.
6. Conformance: Functional Safety guidelines and AUTOSAR architecture are driving the changes needed in hardware components as well along with the software. Today, hardware components have in-built fault detection mechanisms. During the product development, a detailed DFMEA (Design Failure Mode and Effects Analysis) is performed for each of the hardware components and software implements the checks or tests at different points of execution. E.g. Core Test or Ram Test are performed at the initial phase of the system boot process whereas other critical controllers such as CAN transceiver, SPI communication or telltale controller implement the checks at runtime. These checks or tests provide the conformance for ASIL.
7. Predictive behavior: Checks or tests provide data about the behavior of a particular component in AUTOSAR architecture. A failure needs to be identified and handled appropriately to have predictive and pre-defined behavior.

As Functional Safety becomes more relevant for all segments of Automotive electronics, AUTOSAR makes it easier to adapt, follow, and implement the same.

Sasken has 15+ years of Automotive platform experience with extensive experience in different domains of Automotive ECU software development such as Body Electronics, Telematics, ADAS, Infotainment, Instrument Cluster, Automotive Safety System, etc. Sasken is a specialist in enabling cognitive content to the ECUs by connecting to the Cloud and making the necessary AI-based decisions utilizing Adaptive AUTOSAR platform. In the realization of AUTOSAR, Sasken has been enabling its customers to remain profitable by enabling them to monetize the hardware, software and system integration solutions, services, and support. Sasken is a CMMI Dev V1.3 ML3, ISO/IEC 27001:2013 company and its quality management system is compliant to TL9000, Functional Safety ISO 26262, and Automotive SPICE v2.5 (HIS model) frameworks.