AUTOSAR and Functional Safety

Simon Frst, BMW Group Safetronic 2011 8 Nov. 2011, Sheraton Arabellapark Hotel, Munich

AUTOSAR and Functional Safety Overview Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety AUTOSAR Vision AUTOSAR aims to standardize the software architecture of ECUs. AUTOSAR paves the way for innovative electronic systems that further improve performance, safety and environmental friendliness.

Yesterday

AUTOSAR Application Software

standardized

Customer needs
Adaptive Cruise Control Lane Departure Warning Advanced Front Lighting System ..

Software

Using standards HW-specific

Communication Stack OSEK Diagnostics CAN, FlexRay

Hardware

Hardware

Hardware and software will be widely independent of each other. Development can be de-coupled by horizontal layers. This reduces development time and costs. The reuse of software increases at OEM as well as at suppliers. This enhances quality and efficiency.
3 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Intra- and Inter-ECU Communication Ports implement the interface according to the communication paradigm (here client-server based).
ECU I ECU II
Application SW-C B Application SW-C C

Ports are the interaction points of software components. The communication is channeled via the RTE. The communication layer in the basic software is encapsulated and not visible at the application layer.

Application SW-C A

Application

Ports
RTE

VFB

RTE

AUTOSAR Infrastructure
BSW BSW

Sensor

Hardware

Communication Bus Communication Path

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Software Architecture AUTOSAR Defined Interfaces

Automotive Open System Architecture (AUTOSAR): Standardized, openly disclosed interfaces HW independent SW layer Transferability of functions Redundancy activation AUTOSAR RTE: by specifying interfaces and their communication mechanisms, the applications are decoupled from the underlying HW and Basic SW by the RTE. This enables the realization of re-usable application software components.

Application Software Component AUTOSAR Interface

Actuator Software Component AUTOSAR Interface

Sensor Software Component AUTOSAR Interface

AUTOSAR Software

Application Software Component AUTOSAR Interface

..............

AUTOSAR Runtime Environment (RTE)

Standardized Interface Standardized AUTOSAR Interface Services Standardized Interface Standardized Interface Standardized Interface Communication Standardized Interface AUTOSAR Interface ECU Abstraction Standardized Interface AUTOSAR Interface

Operating System

Basic Software

Standardized Interface Microcontroller Abstraction

Complex Device Drivers

ECU-Hardware
Interfaces: AUTOSAR Software Component Interface Standard Software

VFB & RTE relevant

RTE relevant

BSW relevant

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Software Architecture: Software Abstraction inside the Infrastructure Architecture The Basic Software Layers are further divided into functional groups. Each functional group consist of multiple basic software modules.
SW Components
Application Software Component AUTOSAR Interface Actuator Software Component AUTOSAR Interface Sensor Software Component AUTOSAR Interface

AUTOSAR Software

Application Software Component AUTOSAR Interface

..............

Memory Services

AUTOSAR Runtime Environment (RTE)

System Services Memory Services Communication Services
NVRAM Manager

I/O Hardware Abstraction

Complex Drivers

Basic Software

Memory Hardware Abstraction

Onboard Device Abstraction

Memory Hardware Abstraction

Communication Hardware EEPROM Abstraction Abstraction Communication External EEPROM Driver Drivers
COM Drivers

Memory Abstraction Interface Flash EEPROM Emulation

Microcontroller Drivers

Memory Drivers

I/O Drivers

External Flash Driver

ECU Resources

Memory Drivers EEPROM Driver Internal Flash Driver Flash

ECU-Hardware

SPIHandler Driver

SPI

EEPROM

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Methodology and Templates: The AUTOSAR Meta Model The AUTOSAR Meta Model is the backbone of the AUTOSAR architecture definition contains complete specification, how to model AUTOSAR systems
Metamodel Package Overview M3: Model of the Meta Model (Meta-Meta Model) (Defines UML Modeling Elements)
All other top-level packages aggregate metaclasses from Generic Structure SW Component Template Generic Structure Common Structure

M2: Model of the model (Meta Model) (Defines AUTOSAR Modeling Elements)

ECU Resource Template

System Template

M1: Model of the system (Defines a real system)

ECU Description Template BSW Module Template ECU Parameter Def Template

M0: Realized System in the car (Implements a real system)

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety AUTOSAR Methodology Alternative Visualization

Component API (e.g. app.h)

Component API Generator

SW-C Implementation ECU Configuration Description

SWComponent Description

System Configuration Description

RTE extract of ECU configuration

AUTOSAR RTE Generator

ECU Resource Description (HW only)

AUTOSAR System Configuration Generator

ECU extract of System Configuration

AUTOSAR ECU Configuration Generator

OS extract of ECU configuration e.g. OIL Basic SW Basic SW ModuleBasic A extract SW Module A extract of ECU Module A of ECU extract configuration of ECU configuration configuration List of implementations of SW components

OS, COM, Generator

System Constraint Description

Decisions (e.g. mapping)

ECU extract of System Configuration

Other Basic SW Generator

Decisions (e.g. scheduling)

MCAL Generator

Information / Database (no files) Generation step: complex algorithm or engineering work

System per ECU

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Overview Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Approach of AUTOSAR with regard to Functional Safety.
Sources ISO WD 26262 Requirements from WPs & WGs Requirements from Applications Requirements from Safety Concepts

Consolidated Safety Requirements Process Safety Requirements Technical Safety Requirements Interface Class 1 SW-C HW ECU Sensor Actor
List of safety requirements allocated to BSW & RTE

Structure and Allocation

Methodology Safety Requirements Tools Generation

List of safety requirements allocated to methodology

AUTOSAR Safety Guidelines

Interface Class 3
List of requirements on development processes

Development Process Assignment

BSW & RTE Requirements SRS SWS

Update of existing documents of WPs Requirements on tools and generation process

Tools and Generation Process Tools Generation

BSW & RTE Tools

Requirements on how to develop AUTOSAR SW and Tools
10 8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Overview on Safety Mechanisms Supported by AUTOSAR Built-in self test mechanisms for detecting hardware faults (testing and monitoring) Run-time mechanisms for detecting software faults during the execution of software Program flow monitoring Run-time mechanisms for preventing fault interference Memory partitioning for SW-Cs Time partitioning for applications Run-time mechanisms for protecting the communication End-to-end (E2E) communication protection for SW-Cs Run-time mechanisms for error handling

11

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Safety mechanisms for detecting errors. Memory: RAM Test Flash Test Support for ECC memory Core: Core Test Watch Dog Logical and temporal program flow monitoring

12

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Run-time mechanisms for error handling Detected errors in the basic software: Are reported through DEM to SW-Cs. SW-Cs then executes application-specific actions Are reported to FIM, which permits to disable some functions of SW-C Detected hardware errors: Arithmetic exceptions (e.g. division by 0): handled by OS callouts (small error handling routines in the context of basic software). Typical reaction ECU reset HW errors detected by HW testing: handled by callouts. Typical reaction ECU reset Errors detected my MMU/MPU (memory and time partitioning). It will shut down or restart the faulty SW-C partition

13

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Memory partitioning for Software-Components Enables create protection boundaries around groups of SW-Cs This is realized by user-mode/non-trusted memory partitions (for groups of SW-Cs) This protects from interference: (1) basic software and (2) SW-Cs in other partitions Basic software is not AUTOSAR partitioned. It runs Software with in CPU super.............. visor mode with AUTOSAR Runtime Environment (RTE) full access to memory, CPU and all other hardware resources
Application Software Component AUTOSAR Interface Actuator Software Component AUTOSAR Interface Sensor Software Component AUTOSAR Interface Application Software Component AUTOSAR Interface Standardized Interface Standardized AUTOSAR Interface Services Standardized Interface AUTOSAR Interface AUTOSAR Interface Communication Standardized Interface ECU Abstraction Standardized Interface Standardized Interface

Standardized Inteface

Operating System

Basic Software ECU-Hardware

Standardized Interface Microcontroller Abstraction

Complex Device Drivers

14

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety End-to-End communication protection (1/4) E2E protection detects faults in data caused by both hardware and in software Typical sources of
Libraries OS-Application 2 Receiver 1 OS-Application 1 Sender

interferences, causing errors detected by E2E protection: SW-related sources: S1. Error in mostly generated RTE, S2. Error in partially generated and partially hand-coded COM S3. Error in network stack S4. Error in generated IOC or OS HW-related sources: H1. Microcontroller error during core/partition switch H2. Failure of HW network H2. Network EMI H3. Microcontroller failure during context switch (partition) or on the communication between cores

S1 H3 AUTOSAR Runtime Environment (RTE)

System Services S3 IOC

Memory Services

Communication Services S2

I/O Hardw are Abstraction

CDD

Onboard Device Abstraction

Memory Hardware Abstraction

Communication Hardw are Abstraction S3

Direct function call

Receiver 2

Microcontroller Drivers

Memory Drivers

Communication Drivers

I/O Drivers

H3

H4

Microcontroller 1 / ECU 1

Microcontroller 2 / ECU 2

15

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety End-to-End communication protection (2/4) Application is almost un-impacted by the introduction of end-to-end protection wrapper End-to-End protection wrapper protects/checks the communication on behalf of application, i.e. SW-Cs End-to-End Protection wrapper encapsulates the data protection and also invokes RTE
OS-Application 1 OS-Application 2 Sender 1 Receiver 1 Application logic Application logic 1 Produce safe data elements 2 Invoke safe transmission request E2EPW_Write()
E2E protection wrapper E2E protection wrapper

9 Consume safe data elements

6 Invoke safe read do get the data element - E2EPW_Read()

3 Call E2E protect on array E2E_P0x_Protect() 4 Invoke RTE - RTE_Write() to transmit the data element

8 Call E2E check on array - E2E_P0xCheck() 7 Invoke RTE read - RTE_Read() to get the data element

AUTOSAR Runtime Environment (RTE) Libraries

AUTOSAR Runtime Environment (RTE) Libraries

5: RTE communication (intra or inter ECU), either through COM, IOC, or local in RTE

E2E Lib

E2E Lib

16

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety End-to-End communication protection (3/4) Protection of data exchanged over communication channels like FlexRay and CAN Failure modes addressed as defined by ISO DIS 26262 for communication (repetition, deletion, insertion, incorrect sequence, corruption, timing faults, addressing faults, inconsistency, masquerading) Three different protection mechanisms for data are used CRC, counter, Data ID, timeout detection Data ID included in to calculated CRC, but not sent

Data Id

CRC

0xF Count Signal1 er

0xFF

Signal 2

CRC := CRC8 over (1) Data Id, (2) all serialized signal (including empty areas, excluding CRC byte itself)

17

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety End-to-End communication protection: future considerations (4/4) Fully AUTOSAR compliant design with major impact on ASIL inheritance Example: overall flow at sender
OS-Application 1 SW-C 1 1. Produce safe data elements

2. Invoke RTE - RTE_*_<p>_<o>() to transmit the data element

AUTOSAR Runtime Environment (RTE) Libraries Communication Services 4. COM Signals 7. E2E_PXXProtect(&Config, &State, (unit8*) IPduData)

3. Map Data Elements to signals

8. Execute E2E Library, wrte control fields (e.g. CRC, Counter) in IPduData

E2E Lib

COM E2E Callouts

COM

5. Serialize signals on I-PDU

9. Updated parameters State and IPduData 6. IPDU_E2EProtect_<IPDU ID>( PduId, IPduData)

11. If (ret = TRUE) deliver IPduData; else no action

10. ret: TRUE if no error else FALSE; updated IPduData

PDU Router

18

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Overview Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion

19

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Technical safety concepts supported by AUTOSAR Implementation of typical safety concepts in the automotive domain Intelligent HW watchdog (ASIC) / 3-level safety concept Monitored channel (2 Cs, the second is a simple C monitoring the first C) Dual channel (2 AUTOSAR Cs) Application redundancy (on the same or different Cs) Basic Software redundancy inside one ECU

20

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Application redundancy Assuming integrity of HW/ECU and AUTOSAR basic software implementation, software redundancy with ASIL decomposition can be used within the same ECU. Distribution of SW channels across ECUs is also possible..

SW-C Channel 1

SW-C Channel 2

AUTOSAR

SW-C Channel 1

SW-C Channel 2

C core 1

C core 2

AUTOSAR

AUTOSAR

ECU 1

ECU 2

21

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Basic Software redundancy inside one ECU Redundancy inside AUTOSAR e.g. double input/output data paths through Redundant IO hardware abstraction and IO drivers Redundant and diverse (e.g. ADC + DIO, internal ADC + external ADC) Redundancy through SW-C Channel 1 SW-C Channel 2 SW-C Channel 1 SW-C Channel 2 integration of complex Runtime Environment Runtime Environment drivers runnComplex Drivers I/O Hardware Abstraction I/O Hardware Abstraction ing on the I/O Signal Interface 1 I/O Signal Interface 2 I/O Signal Interface 1 same C Driver for ext. offering a ADC ASIC redundant Complex data path Driver COM Drivers COM Drivers I/O Drivers
ADC Driver 1 ADC Driver 1 ADC Driver 2 SPIHandler Driver SPI DIO Driver DIO

HW component

ADC 1

ADC 2

ADC

22

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Overview Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion

23

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Relationship to ISO 26262 Essential concepts of ISO 26262 have been developed in sync with AUTOSAR Software configuration Part 6, Chapter 7 and Annex C Freedom of interference by partitioning Part 6, Chapter 7 and Annex D Safety Element out of Context (SEooC) Part 10, Chapter 9 Qualification of software tools Part 8, Chapter 10

Item Development
3-7 Hazard analysis and risk assessment Hazard analysis and risk assessment

SEooC Development
Concept phase ASIL Capability Assumptions on safety goals (ASIL Safety Element out of Context Capability per system failure ) Overall management of safety requirements 3-7 Hazard analysis and risk assessment Specification of safety goals

8-6 Overall management of safety requirements require

Assumptions on functional safety concept Assumptions on functional safety requirements

3-8 Functional safety concept Specification of functional safety requirements

4-6 Specification of technical safety concept Specification of technical safety requirements

Product development

4-7 System design

System design specification

5-6 Specification of HW safety requirements Hardware safety requirements

6-6 Specification of SW safety requirements Software safety requirements

24

8 Nov. 2011

After SOP

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

AUTOSAR and Functional Safety Relationship to ISO 26262 Due to rules on ASIL inheritance defined in ISO 26262 the AUTOSAR basic software and RTE inherits safety relevance. Either implement complete AUTOSAR basic software according to max. ASIL of application software or demonstrate freedom of inference in basic software by appropriate mechanisms
1. Vocabulary 2. Management of functional safety

Implementers have to tailor ISO 26262 according to their activities in the safety-lifecycle For all implemented safety mechanisms a safety manual is needed containing The fault model according to which the safety mechanism was developed The constraints that must be fulfilled when applying a safety mechanism
25 8 Nov. 2011

2-5 Overall safety management

2-6 Safety management during item development

2-7 Safety management after release for production

Chapters to be considered by Implementers

3. Concept phase
3-5 Item definition 3-6 Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment 3-8 Functional safety concept

4. Product development: system level

4-5 Initiation of product development at the system level 4-6 Specification of the technical safety requirements 4-7 System design 4-11 Release for production 4-10 Functional safety assessment 4-9 Safety validation 4-8 Item integration and testing

7. Production and operation

7-5 Production 7-5 Operation, service (maintenance and repair), and decommissioning

5. Product development: hardware level

5-5 Initiation of product development at the hardware level 5-6 Specification of hardware safety requirements 5-7 Hardware design 5-8 Hardware architectural metrics 5-9 Evaluation of violation of the safety goal due to random HW failures 5-10 Hardware integration and testing

6. Product development: software level

6-5 Initiation of product development at the software level 6-6 Specification of software safety requirements 6-7 Software architectural design 6-8 Software unit design and implementation 6-9 Software unit testing 6-10 Software integration and testing 6-11 Verification of software safety requirements

8. Supporting processes
8-5 Interfaces within distributed developments 8-6 Specification and management of safety requirements 8-7 Configuration management 8-8 Change management 8-9 Verification 8-10 Documentation 8-11 Qualification of software tools 8-12 Qualification of software components 8-13 Qualification of hardware components 8-14 Proven in use argument

9. ASIL-oriented and safety-oriented analyses

9-5 Requirements decomposition with respect to ASIL tailoring 9-6 Criteria for coexistence of elements 9-7 Analysis of dependent failures 9-8 Safety analyses

10. Guideline on ISO 26262 (informative)

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR

Core processes

AUTOSAR and Functional Safety Conclusion AUTOSAR systematically derived safety mechanisms supported in release 4.0 AUTOSAR provides support for dedicated safety mechanisms with generic fault models AUTOSAR supports typical technical safety concepts During system and software design the safety manual is considered to appropriately use the safety mechanisms of an AUTOSAR implementation. AUTOSAR provides essential support for building of safety related systems

26

8 Nov. 2011

Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR