AUTomotive Open System ARchitecture – (AUTOSAR)- is a standardization initiative of a group of leading automotive OEMs and suppliers which was founded in autumn 2003. Its ongoing mission is to develop reference architectures for ECU software, which can overcome the growing complexity of software in modern vehicles.
Compliance with any of the AUTOSAR standards and architectures is a necessary step in many automotive software development projects. However, it offers no guarantee of functional safety or cybersecurity. Concurrent adherence to AUTOSAR and other standards is therefore a commonplace project requirement.
According to their website:-,
“AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor, and software industry.”
“It paves the way for innovative electronic systems with improved performance, safety, and security.”
The term “AUTOSAR” is also frequently used to reference the standards produced by the AUTOSAR development partnership, whose primary aim is “the standardization of basic system functions and functional interfaces”.
In December 2017, the AUTOSAR family of standards expanded to embrace the new “Adaptive Platform,” with the existing development branch becoming known as the “Classic Platform”.
First published in 2005, the Classic Platform is AUTOSAR’s established solution for embedded systems with hard real-time and safety constraints. The addition of the AUTOSAR Adaptive Platform provides a solution for high-performance computing ECUs to build safety related systems for use cases such as highly automated and autonomous driving. It is complementary to the AUTOSAR Classic Platform, and not a replacement for it, it is not a question of ” AUTOSAR Classic vs Adaptive” or ” AUTOSAR Adaptive vs Classic!”
Additionally, the purpose of the Foundation standard (shown in the graphic above) is to enforce interoperability between the two AUTOSAR platforms. It contains requirements and technical specifications common to them – for example, communications protocols.
AUTOSAR is a worldwide development partnership of vehicle manufacturers, suppliers and other companies from the electronics, semiconductor, and automotive software industries. There are nine founding “core partners” including OEMs (BMW, Mercedes, Ford etc) and tier 1 suppliers (Continental, Bosch). The three other partnership levels are for Premium, Development, and Associate partners. While described in more detail on the AUTOSAR website, these partnership levels have a broadly similar make-up, with the inclusion of several software tools and RTOS vendors.
Advantages of AUTOSAR include:
These advantage apply to both platforms- again, there is no question of an “Adaptive AUTOSAR vs Classic AUTOSAR” scenario.
Disadvantages of AUTOSAR relate mostly to initial costs. They include:
Again, these disadvantages are common to both platforms.
AUTOSAR is not an Operating System (OS), although each platform specifies which operating system(s) should be used. The AUTOSAR Classic platform includes a specification for its own custom operating system, whereas the AUTOSAR Adaptive platform leverages POSIX compliant operating systems.
Functional safety is concerned with the management of the level of risk in a piece of equipment or a system.
Development processes for functional safety are designed to identify potentially harmful conditions and corrective actions. The aim is to avoid or reduce the impact of an incident such that the response is proportionate to the risk. In practice, functional safety relies on active systems that can respond to a potentially dangerous situation. Examples include the initiation of anti-lock braking, and the unlocking of car doors after an accident.
AUTOSAR compliance offers no guarantee of functional safety. As a result, functional safety standards such as ISO 26262 are often applied in parallel to it.
Traditionally, software development for automotive applications was completed in isolation by OEMs or their suppliers. This led to a lot of duplicated effort amongst players in the automotive sector, prolonged development cycles, and a lack of commercial flexibility especially when updating either hardware or automotive software.
The AUTOSAR Classic Platform looks to address those deficiencies by providing a clearly defined layer of abstraction between the hardware and the application layer, providing a common software foundation irrespective of the chosen microcontroller.
As stated above, automotive applications traditionally consisted of software developed in isolation. This resulted in unnecessary time spent on development because of duplicated work and a lack of flexibility when updates were required. With the help of the AUTOSAR Classic Platform, developers have a common automotive software foundation due to the defined layer it provides between the hardware.
Consider an example system consisting of 3 interconnecting software units. Each AUTOSAR software component encapsulates a part of the application, and the components communicate with each other over a hardware independent “Virtual Function Bus.” Each ECU can host one or more software units, and a runtime environment to implement the Virtual Function Bus and the AUTOSAR Basic Software.
This Basic software provides service functions to the application developer such as operating system services, network communication and management services, memory services, and diagnostic services. In this way, the hardware environment is abstracted away from the software units, and so is largely transparent to the application developers.
These software units are known as AUTOSAR software components (AUTOSAR SWC). In practice, the architecture provides a level of abstraction such that the AUTOSAR SWCs are transferable and can be deployed to ECUs very late in the development process.
AUTOSAR Classic applications are developed using several C language source files compiled together to create a monolithic executable. Configuration takes place at compilation time, and the applications run on the bespoke AUTOSAR Classic Operating System.
The purpose of the AUTOSAR Platforms is to standardize software architectures for automotive electronic control units (ECUs). The AUTOSAR Adaptive Platform is designed to address the increasing complexity of software in modern vehicles, especially in the context of autonomous driving and advanced driver assistance systems.
The illustration below shows the layered architecture of the AUTOSAR Adaptive Platform (sometimes known as the Adaptive AUTOSAR Platform).
Adaptive applications communicate using ara::com middleware —an AUTOSAR standard designed to complement the AUTOSAR Adaptive Platform, and provide a mechanism for communications between applications. ara::com is just one of the services provided for Adaptive Applications to call upon. It was created because there were no existing solutions that met all key AUTOSAR requirements.
Unlike AUTOSAR Classic applications, AUTOSAR Adaptive applications do not consist of a few source files compiled together to create a monolithic executable. Instead, they are separately executable, single, or multi-threaded processes. Adaptive applications are configured on target by means of Manifest files, rather than at compilation time as with Classic applications. The C++ language is preferred to C, bringing all the advantages of Object-orientation.
Unlike the bespoke AUTOSAR Classic Operating System, Adaptive AUTOSAR uses any available POSIX PSE 51 compliant OS operating system.
However successful the AUTOSAR Classic Platform continues to be, the advent of the connected car has revealed its limitations. When the AUTOSAR Adaptive Platform was launched in 2016, Simon Fürst, an AUTOSAR spokesperson said that the Classic Platform “remains the system of choice with regard to control units from the classical E/E domains of the automobile”.
He went on to discuss the AUTOSAR Adaptive Platform, saying that: “Upcoming new functionalities will be realized more efficiently by a software platform being designed for their special requirements.”
Some key differences between the platforms are tabulated below.
Many AUTOSAR SWCs will also be required to be compliant with other standards, such as ISO 26262 (functional safety) and/or ISO/SAE 21434 (cybersecurity). There can be some challenges that result from combining multiple requirements.
For example, below is the classic V-model derived from the ISO 26262 functional safety standard. Several aspects of this process model are impacted by AUTOSAR Platform objectives.
The illustration below is based on table 6 from ISO 26262-6. It shows the coding and modelling guidelines to be enforced during implementation, superimposed with an indication of where compliance can be confirmed using automated static analysis tools. These essentially perform an “automated inspection” of the source code.
The topics detailed in the table combine to make the resulting code more reliable, less prone to error, easier to test, and/or easier to maintain. Adherence to appropriate coding standards such as MISRA C and AUTOSAR C++ covers most of the topics.
LDRA’s static analysis tools can also provide metrics to ensure compliance with the standard — complexity metrics as a product of interface analysis, cohesion metrics evaluated through data object analysis, and coupling metrics via data and control coupling analysis.
More generally, they can help to ensure that the good practices required by functional safety standards such as ISO 26262 are adhered to alongside the objectives of the AUTOSAR standards.
ISO 26262 references the MISRA language subsets as an example of what might be used. It is also entirely permissible to use an in-house set or to manipulate, adjust and add to a standard set, making it more appropriate for a particular application. This aligns with the recommendations for the development of AUTOSAR Classic SWCs.
Anyone working with both the AUTOSAR Classic Platform and MISRA standards has a second challenge to overcome, in that the standard format of AUTOSAR system calls are not MISRA compliant. The LDRA tool suite can recognise AUTOSAR system calls without highlighting them as MISRA related violations.
Recommendations relating to AUTOSAR coding guidelines as they relate to AUTOSAR Adaptive SWCs were updated in October 2023
AUTOSAR C++14
The AUTOSAR document, “Guidelines for the use of the C++14 language in critical and safety-related systems” (AUTOSAR C++14) is designed as an addendum to MISRA C++:2008. Its purpose is to address language features that were introduced more recently. These include lambda expressions, override specifiers, smart pointers, variable templates, and variadic templates.
For the earlier language features, AUTOSAR C++14 guidelines reference many MISRA C++ rules without modification and without reproduction. Consequently, developers applying AUTOSAR C++14 also referenced the MISRA C++ guidelines.
Because AUTOSAR C++14 was an addendum to MISRA C++ 2008, the MISRA format was retained for the complementary AUTOSAR C++ rules. Both take a common approach to rule classification through obligation levels, enforcement, and allocation. These classes clearly define pertinent rule characteristics, including whether static analysis can automatically check a rule, and where in the tool chain the rule is applicable.
MISRA C++:2023
The consolidation of the MISRA C++ and AUTOSAR C++ guidelines was announced in January 2019. That work has now concluded, resulting in the release of MISRA C++:2023 in October 2023. This consolidated document serves as a unified language subset for safety-related C++ development processes, applicable to both AUTOSAR Adaptive SWCs and other application software.
LDRA has actively participated in the MISRA C++ working group throughout the development of this edition, with an LDRA representative chairing the group for a significant portion of the duration. The extensive knowledge gained during this involvement will be evident in LDRA’s support for the newly released document.
Static analysis techniques (an automated “inspection” of the source code) are applicable across the sub-phases of coding, architectural design and unit implementation. Likewise, dynamic analysis techniques (involving the execution of some or all of the code) are applicable to unit, integration and system testing as provided by components of the LDRA tool suite such as TBrun and TBvision.
ISO 26262 tables list techniques and metrics for performing unit and integration tests on target hardware to ensure that the safety and functional requirements are met and software interfaces are verified at the unit and integration levels. Fault injection and resource tests further prove robustness and resilience; also, where applicable, back-to-back testing of model and code helps to prove the correct interpretation of the design.
Those mechanisms lend themselves equally well to exercising the interfaces of AUTOSAR applications to their environment, as well as interfaces within or between applications.
Artefacts associated with these techniques provide both a reference for their management, and evidence of their completion. They include the software unit design specification, test procedures, verification plan and verification specification. Upon completion of each test procedure, pass/fail results are reported and compliance with requirements verified appropriately.
As stated previously, AUTOSAR Classic applications run on the AUTOSAR Classic Operating System, whereas Adaptive AUTOSAR uses any one of several POSIX PSE 51 compliant OS. In addition to native POSIX conformant RTOSs such QNX Neutrino and Lynx LynxOS, there is a multitude of POSIX conformant offerings such as Green Hills INTEGRITY and Wind River VxWorks. Linux Standard Base compliant options from Linux providers include Automotive Grade Linux.
Because all of these are well-established RTOSes, there is considerable existing and proven support for them throughout the development lifecycle. from partner organisations such as LDRA Dynamic analysis performed by the LDRA tool suite uses the same development chain as the application code ensuring tests are as representative of the application as possible.
In addition to showing that the software is functioning correctly, dynamic analysis can be used to exercise instrumented code, and hence generate structural coverage metrics. When used in conjunction with requirements-based testing, this code coverage analysis provides the necessary data to evaluate the completeness of test cases, and demonstrate that there is no unintended functionality.
Traceability of artifacts throughout the development life cycle is an essential component for designing complex, critical systems. It is important to be able to trace from requirements to software design and implementation, then up to unit, system, and integration tests. However, it is equally important to be able to reverse that traceability to show that all tests and implemented code perform tasks that are pertinent to the requirements.
Requirements and objectives are frequently derived from various sources – including AUTOSAR standards, ISO 26262, ISO/SAE 21434, and so on. Importing the pertinent parts of those standards into an automated requirements traceability tool, such as the TBmanager component of the LDRA tool suite, ensures that all such requirements are concurrently traceable.
Standards vary in size, scope and detail, and it would be easy to think of AUTomotive Open Systems ARchitecture (AUTOSAR) as just another standard. In fact, it is so huge that it is hard to imagine any one individual having detailed knowledge of it all.
The Adaptive Platform does not supersede the Classic Platform. It extends AUTOSAR’s capabilities, with the net result that the challenge of getting a sufficient grasp on the different elements of AUTOSAR as a whole is now considerably bigger.
Any tools that have a proven track record across a range of safety critical industries in the fields of static analysis, dynamic analysis, unit test, and requirements and objectives traceability are surely beneficial. However, applying a disparate collection of tools to the development cycle carries with it the potential to add needless complexity to an already challenging situation. Perhaps, then, the most significant attribute of all is the capability to integrate such a toolchain into one seamless whole.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707