A Car has over hundred million lines of code. Know how code gets assembled?

Safety Extensions of AUTOSAR Models

Functional safety is an increasingly important topic in automotive companies including OEMs, Tier 1 and Tier n. In this article, we describe a solution to common problems faced by an automotive company when safety information needs to be exchanged among the other organizations in the supply chain.

Functional safety activities do concern the whole lifecycle of the system (item) under development and involve a cooperative effort from all participating stakeholders. Thus, safety-related work products have to be exchanged between all the organizations involved in the supply chain. Details such as roles, responsibilities, and work products should be specified in a Development Interface Agreement (DIA), according to ISO 26262. However, it is not prescribed by ISO 26262 how such information should be exchanged (regarding content, formats, etc.).

In current practice, this typically leads to inefficient and manual document-centric processes with information duplication on both sides of the supply chain i.e. the consumer and the supplier. It may also happen, that important information is missing at the time when certain activities (such as the provisioning/configuration of safety mechanisms of basic software) are finally executed. All of this results in inconsistencies, limited traceability, and difficulties when demonstrating the overall safety case.

AUTOSAR architecture, methodology and supporting tools provide standard exchange formats and a common methodology

On the other side, the AUTOSAR Architecture together with the AUTOSAR methodology and supporting tools already work between organizations in the supply chain by providing standard exchange formats and a common methodology. Using these formats, relevant software system and ECU implementation information can easily be exchanged. In the following sections, we will explore how a standard such as AUTOSAR could solve the functional safety problem in an elegant way.

Let us take an example of an OEM functional safety deployment for a vehicle platform.

Figure 1 The Vaillant diagnostic platform

OEM design & definition

The OEM provides the general concepts for the systems (items) of the same platform. The functional safety concept work typically starts at the item level(s) of a vehicle platform, leading to safety goals and requirements for different items, systems and sub-systems of the platform.

OEM to Tier 1 transfer

The functional safety concepts of the OEM are then shared to Tier 1 for their specific items, system or sub-system.

OEM Integration and Validation

OEM would collect various implementations for integration of safety concepts into their system and perform validation of the system on a vehicle platform level. This process could be iterative in nature

Figure 2 Safety Phase

A similar process would occur for lower Tiers, which contribute to the Tier 1 work. The difficulties in transferring safety related information, as described above, mainly exists in two phases when such information gets exchanged between organizations:

OEM to Tier 1 Transfer

The information to be transferred contains relevant parts of the functional safety concept i.e. the safety goals and requirements, safety considerations in the architecture and allocation information of safety requirements to elements of the architecture.

Tier 1 to OEM’s Transfer

In this phase, the information on the implemented safety mechanisms and measures and the mapping between the safety requirements and such mechanisms is an important information.

As initially described, the OEM will potentially communicate with multiple Tier 1 suppliers and the Tier 1 suppliers usually again have to contact multiple Tier n suppliers. The presence of a standardized exchange format for safety information will ease the communication between organizations and help in avoiding cost-intensive and error-prone rework or translation of safety related information.

Presence of standardized exchange format eases communication between organizations

The AUTOSAR Safety Extensions introduced in release 4.2.1 provide such a standardized exchange format. In addition to the introduction of the pure exchange format, the AUTOSAR methodology has been extended and now contains activities in which the safety related artifacts are produced.

The idea of the AUTOSAR Safety Extensions is to facilitate the AUTOSAR XML (.arxml) representation as the format in which safety information is represented and exchanged. In the current release as part of AUTOSAR 4.2.1, an approach is used which does not impact the existing AUTOSAR metamodel. The new standard defines how the information has to be provided using only existing generic concepts of the AUTOSAR metamodel by applying specific standardized tags and content.

The approach used in the current release of AUTOSAR 4.2.1 does not impacts the existing AUTOSAR metamodel

Thus, in addition to the conventional AUTOSAR models that are exchanged among organizations in the supply chain, these safety extensions add new elements to the model and refer to existing elements. The fact that these safety extensions can be applied only as extensions means that they do not affect exiting AUTOSAR models.

According to the development process described above, the main concepts of the extension are Safety Requirements and Safety Measures together with their ASIL attributes.

Safety Requirements

In AUTOSAR R4.2.1 clearly distinguishable safety requirements can be defined in AUTOSAR metamodel, thus fulfilling the needs as specified by ISO 26262 parts 4 and 8 (section 4). Safety Requirements may have attributes and relations that are used to define them in accordance with ISO26262 specifications, such as decomposition and refinement. Additionally, by using AUTOSAR Trace the traceability and allocation of safety requirements and safety measures can be described according to ISO 26262 parts 4, 6 and 8 (section 6)

Safety Measures

Safety Measures have a textual description, a unique ID and a type that declares whether it is a safety mechanism (i.e. part of the AUTOSAR implementation) or an external measure (e.g. a review). Furthermore, ASIL attributes according to ISO 26262 can be specified.

ASIL Attribute Values

In AUTOSAR R4.2.1, safety integrity levels / ASIL can be assigned for each AUTOSAR element including safety requirements and safety measures.

The provisioning and processing of AUTOSAR models with safety extensions is subject to appropriate tool support. Tools supporting the safety process according to ISO 26262 could be used to provide the safety requirements and the required ASIL attributes. AUTOSAR tools such as configuration tools could read this information and add further information such as the traces to the safety mechanisms and measures that are part of the final configuration. As the safety extensions are standardized, arbitrary AUTOSAR compliant tools can be used here

The application of AUTOSAR Safety Extensions together with appropriate tool support provides several benefits. The need for information exchange in arbitrary formats (mostly with Word and Excel) is reduced and also the time required for the transformation of this information, if it flows across an organization border, is reduced. Hence, the workflow can be organized much more efficiently than today. Besides the advantages in the process, there is also an increase in the quality of the safety information, as the traceability is much better, e.g. for a safety case argumentation. In addition, this explicit traceability in the models offer possibilities for consistency checks

AUTOSAR Safety Extensions reduce the need to exchange information in arbitrary formats and the time required to transfer it