Standardized Interface

(1)

AUTOSAR and Functional Safety

Simon Fürst, BMW Group Safetronic 2011

8 Nov. 2011, Sheraton Arabellapark Hotel, Munich

(2)

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

(3)

AUTOSAR Vision

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

Yesterday

Application Software

Hardware

standardized

HW-specific

AUTOSAR

Customer needs

Adaptive Cruise Control Lane Departure

Warning

Advanced Front Lighting System ..

Using standards

Communication Stack OSEK

Diagnostics CAN, FlexRay

Hardware Software

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.

(4)

Intra- and Inter-ECU Communication

Ports implement the interface according to the communication paradigm (here client-server based).

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.

Appli- cation SW-C A

RTE

BSW

ECU I

Appli- cation SW-C B

RTE

BSW

ECU II

Appli- cation SW-C

C

VFB

Sensor

Communication Bus

Communication Path Hardware AUTOSAR Infrastructure Ports

Application

(5)

Software Architecture – AUTOSAR Defined Interfaces

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.

Automotive Open System Architecture (AUTOSAR):

Standardized, openly disclosed interfaces

HW independent SW layer Transferability of functions Redundancy activation

AUTOSAR Software Component

Standard Software

Interface VFB &

RTE relevant

RTE

relevant BSW relevant Interfaces:

ECU-Hardware

AUTOSAR Runtime Environment (RTE)

Application Software Component

...

AUTOSAR Software

Basic Software

AUTOSAR Interface

Complex Device Drivers Standardized

Interface

Operating System

Actuator Software Component

Sensor Software Component

AUTOSAR Interface Application

Software Component

Standardized Interface Standardized

AUTOSAR Interface Services

Standardized Interface

Communication Standardized

Interface

ECU Abstraction Standardized

Interface

Microcontroller Abstraction Standardized

Interface

StandardizedInterface

(6)

Software Architecture: Software Abstraction inside the Infrastructure Architecture

ECU-Hardware

AUTOSAR Runtime Environment (RTE)

Actuator Software Component AUTOSAR

Interface Application

...

AUTOSAR Software

Complex Drivers

Microcontroller Drivers

Memory Drivers I/O Drivers

I/O Hardware Abstraction

Memory Hardware Abstraction Memory Services System Services

Onboard Device Abstraction

Communication Drivers Communication

Hardware Abstraction Communication

Services

Basic SoftwareECU Resources

COM Drivers

Memory Hardware Abstraction

µC

Memory Drivers EEPROM

Driver SPIHandler

Driver

SPI EEPROM Flash

Internal Flash Driver External Flash

Driver Memory Abstraction Interface

External EEPROM Driver

EEPROM Abstraction Flash EEPROM

Emulation Memory Services

NVRAM Manager

SW Components

The Basic Software Layers are further divided into functional groups.

Each functional group consist of multiple basic software modules.

(7)

Methodology and Templates: The AUTOSAR Meta Model

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

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

(Meta Model)

(Defines AUTOSAR Modeling Elements)

M3: Model of the Meta Model (Meta-Meta Model) (Defines UML Modeling

Elements)

The AUTOSAR Meta Model

is the backbone of the AUTOSAR architecture definition

contains complete specification, how to model AUTOSAR systems

Common Structure

ECU Parameter Def Template

Metamodel Package Overview

Generic Structure

BSW Module Template System Template

SW Component Template

ECU Resource Template

ECU Description Template All other top-level

packages aggregate meta- classes from

“Generic Structure”

(8)

AUTOSAR Methodology – Alternative Visualization

System Configuration

Description

AUTOSAR System Configuration

Generator Component

API Generator

Generation step:

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

per ECU

SW- Component Description

ECU Resource Description

(HW only)

System – Constraint Description

Component API (e.g. app.h)

ECU Configuration Description

AUTOSAR ECU Configuration

Generator

SW-C Implementation

RTE extract of ECU configuration

OS extract of ECU configuration

Basic SW Module A extract

of ECU configuration

List of implementations

of SW components

e.g. OIL ECU extract

of System Configuration

ECU extract of System Configuration Decisions

(e.g. mapping)

AUTOSAR RTE Generator

OS, COM, … Generator

Other Basic SW Generator

MCAL – Generator Decisions

(e.g. scheduling)

System

(9)

Overview

(10)

Approach of AUTOSAR with regard to Functional Safety.

Requirements from Applications Requirements from

WPs & WGs

Requirements from Safety Concepts

Process Safety Requirements

AUTOSAR Safety Guidelines

Technical Safety Requirements

Interface Class 1 ISO WD 26262

AssignmentStructure and AllocationSources

Development Process

BSW & RTE Tools

Methodology Safety Requirements

Tools

Generation Interface Class 3

BSW & RTE Requirements

SRS SWS

SW-C HW

ECU Sensor Actor Consolidated Safety Requirements

Tools and Generation Process

Tools

Generation

Update of existing documents of WPs List of safety requirements allocated to BSW & RTE

Requirements on how to develop AUTOSAR SW

List of safety requirements allocated to methodology

Requirements on tools and generation process List of requirements on

development processes

(11)

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

(12)

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

(13)

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

(14)

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 partitioned. It runs with in CPU super- visor mode with full access to

memory, CPU and all other hard-

ware resources

ECU-Hardware

AUTOSAR Runtime Environment (RTE)

Actuator Software Component AUTOSAR

Interface Application

...

AUTOSAR Software

Basic Software

Standardized Interface AUTOSAR

Interface AUTOSAR

Interface

Microcontroller Abstraction Standardized

AUTOSAR Interface Services Standardized

Interface

ECU Abstraction

Standardized Interface

Complex Device Drivers AUTOSAR

Interface Standardized

Interface

Communication Standardized

Interface Standardized

Interface

Operating System

StandardizedInteface

(15)

End-to-End communication protection (1/4)

E2E protection detects faults in data caused by both hardware and in software

Libraries

CDD

Microcontroller 1 / ECU 1 AUTOSAR Runtime Environment (RTE)

Microcontroller Drivers Memory Drivers I/O Drivers

I/O Hardware Abstraction

Memory Hardware Abstraction Memory Services System Services

Onboard Device Abstraction

Communication Drivers Communication Hardware

Abstraction Communication Services

OS-Application 1 Sender

Receiver 2 IOC

OS-Application 2 Receiver 1

Microcontroller 2 / ECU 2 S1

Direct function call

Typical sources of

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

S2

S3

H3 H3

S3

H4

(16)

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

Libraries AUTOSAR Runtime Environment (RTE)

OS-Application 1 Sender 1

OS-Application 2 Receiver 1

E2E protection wrapper E2E protection wrapper

E2E Lib 1 Produce safe data elements

2 Invoke safe transmission request - E2EPW_Write()

3 Call E2E protect on array – E2E_P0x_Protect()

4 Invoke RTE - RTE_Write() to transmit the data element

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

Application logic

7 Invoke RTE read - RTE_Read() to get the data element 9 Consume safe data elements

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

8 Call E2E check on array - E2E_P0xCheck()

AUTOSAR Runtime Environment (RTE) Libraries

E2E Lib

(17)

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

CRC := CRC8 over (1) Data Id,

(2) all serialized signal (including empty areas, excluding CRC byte itself)

Data Id Count Signal1

er

CRC 0xF 0xFF Signal 2

(18)

End-to-End communication protection: future considerations (4/4)

Fully AUTOSAR compliant design with major impact on ASIL inheritance Example: overall flow at

sender

Libraries

AUTOSAR Runtime Environment (RTE) OS-Application 1

SW-C 1

E2E Lib

1. Produce safe data elements

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

Communication Services

COM

4. COM Signals

5. Serialize signals on I-PDU

3. Map Data Elements to signals

6. IPDU_E2EProtect_<IPDU ID>( PduId, IPduData) 7. E2E_PXXProtect(&Config, &State,

(unit8*) IPduData) 8. Execute E2E Library, wrte control fields

(e.g. CRC, Counter) in IPduData

9. Updated parameters State and IPduData

COM E2E Callouts

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

PDU Router

11. If (ret = TRUE) deliver IPduData;

else no action

(19)

Overview

(20)

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

(21)

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..

µC core 1 µC core 2 SW-C Channel 1

AUTOSAR

SW-C Channel 2

ECU 1 SW-C Channel 1

AUTOSAR

ECU 2 AUTOSAR SW-C Channel 2

(22)

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 integration of complex drivers runn- ing on the same µC offering a redundant data path

SW-C Channel 1 SW-C Channel 2 Runtime Environment

COM Drivers

I/O Hardware Abstraction I/O Signal Interface 1

µC

I/O Drivers

DIO Driver

SPIHandlerDriver SPI DIO

Driver for ext.

ADC ASIC

ADC Driver 2 ADC 2 I/O Signal Interface 2

ADC Driver 1 ADC 1

SW-C Channel 1 SW-C Channel 2 Runtime Environment

COM Drivers I/O Hardware Abstraction

I/O Signal Interface 1

µC

ADC Driver 1 ADC

Complex Drivers

Complex Driver

HW component

(23)

Overview

(24)

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

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

3-7 Hazard analysis and risk assessment Specification of safety goals

3-8 Functional safety concept

Specification of functional safety requirements

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

requirements

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

Overallmanagementofsafetyrequirements

8-6Overallmanagementofsafetyrequirements

ProductdevelopmentConceptphase

Assumptions on functional safety concept Assumptions on functional safety

requirements ASIL Capability Assumptions on safety goals (ASIL

Safety Element out of Context Capability per system failure )

SEooC Development

”Item” Development

requirements

8-6Overallmanagementofsafetyrequire

requirements

8-6Overallmanagementofsafetyrequirements

ProductdevelopmentConceptphase

Assumptions on functional safety concept Assumptions on functional safety

requirements ASIL Capability Assumptions on safety goals (ASIL

Safety Element out of Context Capability per system failure )

SEooC Development

”Item” Development

(25)

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

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

3. Concept phase

2. Management of functional safety 2-5 Overall safety management 2-6 Safety management during item development

7. Production and operation

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

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-10 Hardware integration and testing

Core processes

2-7 Safety management after release for production

3-6 Initiation of the safety lifecycle

1. Vocabulary

3-5 Item definition

3-7 Hazard analysis and risk assessment

3-8 Functional safety concept

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

8. Supporting processes 8-5 Interfaces within distributed developments

8-6 Specification and management of safety requirements

8-8 Change management 8-9 Verification

8-7 Configuration management

4. Product development: system level 4-5 Initiation of product

development at the system level

4-7 System design 4-8 Item integration and testing 4-9 Safety validation

4-10 Functional safety assessment 4-11 Release for production

6. Product development:

software level 5. Product development:

hardware level

5-9 Evaluation of violation of the safety goal due to random HW failures

4-6 Specification of the technical safety requirements

9. ASIL-oriented and safety-oriented analyses 9-5 Requirements decomposition with respect to ASIL tailoring

9-6 Criteria for coexistence of elements

8-10 Documentation 8-11 Qualification of software tools

8-13 Qualification of hardware components 8-14 Proven in use argument 8-12 Qualification of software components

9-7 Analysis of dependent failures 9-8 Safety analyses Chapters to

be considered by Implementers

(26)

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