functional safety and ecu implementation - vector...functional safety introduction iso 26262 has...

V1.1 | 2019-07-22

Vector India Conference 2019, Pune, 2019-07-17

Functional Safety and ECU Implementation

© 2018. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.1 | 2019-07-22

Functional Safety

Introduction

ISO 26262

has been renewed in 2018 addressing safety-related electronic automotive systems

To reduce liability risks state of the art development methods as described in the ISO 26262 should be applied for such systems.

2/55


ISO 26262-compliant Development

Introduction

Item Integration and Testing

Safety Validation

Item Definition

Hazard Analysis and Risk Assessment

Derivation of Safety Goals

Functional Safety Concept

Technical Safety Concept

Basic SW Development

Hardware Development

Tier 1

Vector

OEM

Appl. SW Development

3/55


SEooC (Vector)Vehicle Project

Achieving Safety Together!

Introduction

Software Safety Requirements

ECU SW Integration

Safety Concept

Safety Manual

Safety Case

consider !

validate !

reference !Safety Case

Software Safety Requirements

Assumptions on Technical Safety Requirements

Specific Use-caseis Unknown!

Hazard Analysis and Risk Assessment

Derivation of Safety Goals

Software Development acc. ISO 26262 Software Development acc. ISO 26262

4/55


Evolution of Safety Concepts

Introduction

Redundancy(e.g. redundant data)

Partitioning

High Performance Integrity

Redundancy(redundant functions)

Enhancingdriver actions

Taking overdriver decision

fail-safe

…

fail-operational

5/55


In many cases we see mixed-ASIL Systems

Introduction

SW Safety Requirements

Software Elements

ECU Software

QM QM QM QM

ASILASIL QM

ECU 1 ECU 2

ASIL QMQM

ASIL ASIL

ECU 3 ECU 4

ASIL

High PerformanceIntegrity

PartitioningAdequateSafety Concepts:

6/55


Safety Concepts and Contribution of MICROSAR Safe

Introduction

SafeRTE

SWC SWC

SafeOS

SWC

Hardware

SWC

BSW

MCAL

ASIL QM

Safe

WD

G

SafeE2E

Partitioning

SafeOS

SafeWDG

SafeE2E

SafeRTE

ISO 26262 requires that software with different ASIL in the same element do not interfere with respect to memory, timing and communication aspects

MSR Safe Components Rationale

High Performance Integrity

SafeRTE

SWC

SafeOS

MCAL

SafeBSW

ASIL QM

SWC

Hardware

SWCSWC

Safe

WD

G

SafeOS

SafeWDG

SafeE2E

SafeRTE

SafeBSW

ISO 26262 requires to implement software components of different ASIL, or safety-related and non-safety-related software components, in accordance with the highest ASIL

MSR Safe Components Rationale

SafeE2E

7/55


Safety Building Blocks of MICROSAR Safe

Introduction

Supports memory partitioning using an MPU

Provides safe context switch for each safety related task:

register settings

stack pointer and program counter

MPU settings

Available for single- and multi-core

OS Applications can be restarted individually

Detects timing and execution order faults

Provides deadline, alive and logic monitoring

Capable of using internal or external watchdogs as well as system basis chips (SBCs)

Ensures safe communication between ECUs

Available as E2E Protection Wrapper and E2E Transformer

All AUTOSAR profiles supported

MICROSAR SafeOS MICROSAR SafeWDG

MICROSAR SafeE2E

Ensures safe communication within the ECU

Supports safe communication across partition boundaries to exchange information between ASIL and QM applications

MICROSAR SafeRTE

Increased performance

complete BSW as ASIL software

reduced partition switches

Additional safety requirements, e.g.:

Correct initialization using an ASIL EcuM

Safe write/read of non-volatile data

MICROSAR SafeBSW

8/55


Introduction

MICROSAR SafeOS

MICROSAR SafeWDG

MICROSAR SafeE2E

MICROSAR SafeRTE

MICROSAR SafeBSW

Process and Services

Summary

Agenda

9/55


MICROSAR SafeOS

MICROSAR SafeOS

Completely developed according to ASIL D

Provides features to argue freedom from interference for application and BSW regarding

Memory: Supports memory separation using the MPU

Timing: Detection of time-budget violations

Provides safe context switching for each safety related task:

register settings


MPU settings


AUTOSAR 4.3 Safety Features:

Safe access to peripheral registers even from user mode

Interrupt source control API

Features additional to AUTOSAR OS SC3/SC4:

Non-trusted function calls

Optimized S/R communication across different contexts

SafeRTE

SWC

SafeOS

MCAL

SafeBSW

SWC

Hardware

SWCSWCS

afe

WD

GE2E

10/55


Overview SafeOS

MICROSAR SafeOS

Memory Partitioning

OS Applications can be defined that are protected by the MPU

Protected peripheral access

Stack Protection

Stack is separately protected by the MPU

Indicator values detect stack overflows also for systems without MPU

Timing protection

Time budgets are monitored

Termination of applications

Memory violations

Wild Pointers

Stack overflow

Writing outside of intended memory location of variables

Timing violations

Endless loops

Too frequent interrupts

Longer calculation times due to unexpected input

Which faults are possible? How do we address them?

11/55


The memory of individual OS Applications can be protected against writing by other OS Applications

This requires dedicated hardware support (MMU/MPU)

Reading between OS Applications is typically not restricted

From AS 4.2 on it does not matter if the OS Applications run in supervisor mode or user mode

OS is responsible for re-programming of the MPU if the number of available regions not sufficient.

Partitioning

MICROSAR SafeOS

MPU Region 1

MPU Region 2

MPU Region 3

MPU Region 4

MPU Region 5

MPU Region 6

Task 1: Stack

Task 1: Code

Task 1: Data

OS Application 1

Shared Memory

1 (rw)

*(r)

1(rw)

1,2 (rw)

Software

Application A

Application B

Operating System

Context Switching

MPU RAM

Application 1

Application 2

Task1

Task 2

Task 3

12/55


Execution budgets are assigned to tasks and monitored

If the budget is exceeded a protection hook is called

Similarly, inter-arrival-times and resource locking times are monitored

Timing Protection vs. Watchdog

Timing protection does not detect deadline violation!

Detects causes of deadline violations earlier than watchdog

Timing protection is limited to tasks / ISR 2 (ISRs of type 1 bypass the timing protection)

Timing Protection

MICROSAR SafeOS

Time

Task 1

Task 3

Task 2

Budget Overrun

Deadline violation

13/55


Access to restricted registers might only be possible in supervisor mode

For QM software supervisor mode is typically restricted

The OS provides a register access API that is used by dedicated BSW modules to be able to run in user mode

Must be confirmed by the user

API can also be used by CDDs

Access to Peripheral Registers

MICROSAR SafeOS

Memory Map

MICROSAR SafeOS

CANdriver

BSW

QM OS-Appl.ASIL OS-Appl.

MPU

LIN

CAN

Timer

14/55


Example

API provided functions for read, modify and write access

The functions are defined for 8 Bit,16 Bit and 32 Bit registers

Register Access API

MICROSAR SafeOS

osWritePeripheral8(uint16 area,

uint32 address, uint8 value)

{

// Validate access request

// Change to supervisor mode

// Perform access

// Change to previous mode

}

…

osWritePeripheral8(id,addr,val)

…

OS BSW

15/55


Introduction

MICROSAR SafeOS

MICROSAR SafeWDG

MICROSAR SafeE2E

MICROSAR SafeRTE

MICROSAR SafeBSW


Summary

Agenda

16/55


BSW

A watchdog can detect timing violations in the Application and BSW

Also provides Program Flow Monitoring up to ASIL D

Is supervised by independent HW-Watchdog

On detected violations in a supervised entity the ECU can be reset

Acknowledgements of a checkpoint are performed without context switch

Overview Watchdog

MICROSAR SafeWDG

SWC

MICROSAR RTE

Safe

Co

mp

lex D

riv

ers

Microcontroller

BSW

MCAL

SWC SWC

WdgDrv

WdgM

Checkpoint Checkpoint

Ch

eckp

oin

t

WdgIf

Watchdog

QM Software ASIL Software

17/55


Overview SafeWDG

MICROSAR SafeWDG

Deadline Monitoring

Applicable for aperiodic entities

Time between two checkpoints is compared to min/max values

Alive Monitoring

Applicable for periodic entities

Number of checkpoints in interval is monitored

Logic Monitoring

Detect wrong execution order

Validate checkpoint activation sequence against preconfigured execution graphs

Execution of code without request

Code not executed although requested

Execution of code started too early or too late

The execution time of an code is longer or shorter than expected

The program flow of an code differs from the expected behavior


It is assumed for all MICROSAR Safe components, that timing faults are handled using a watchdog.

18/55


Periodic Supervised Entities have constraints on the number of times they are executed within a given time span

The Watchdog Manager checks periodically if the Checkpoints of a Supervised Entity have been reached within the given limits

not too frequently

not too rarely.

Alive Monitoring

MICROSAR SafeWDG

𝑛 × WdgM_CheckpointReached()

t

WdgMSupervisionReferenceCycle

𝐴𝐼𝑚𝑖𝑛 ≤ 𝑛 ≤ 𝐴𝐼𝑚𝑎𝑥

Periodic Supervised Entities have constraints on the number of times they are executed within a given time span

The Watchdog Manager checks periodically if the Checkpoints of a Supervised Entity have been reached within the given limits

not too frequently

not too rarely.

19/55


Aperiodic Supervised Entities have individual constraints on the timing between two Checkpoints.

The Watchdog Manager checks

the timing of transitions between two Checkpoints of a Supervised Entity

if the time between two steps are within the configured minimum and maximum

Deadline Monitoring

MICROSAR SafeWDG

𝑡𝑚𝑖𝑛 ≤ Δ𝑡 ≤ 𝑡𝑚𝑎𝑥

WdgM_CheckpointReached() WdgM_CheckpointReached()

t

Aperiodic Supervised Entities have individual constraints on the timing between two Checkpoints.

The Watchdog Manager checks

the timing of transitions between two Checkpoints of a Supervised Entity

if the time between two steps are within the configured minimum and maximum

20/55


Logic Monitoring

MICROSAR SafeWDG

The execution order of the code is monitored

The Watchdog-Manager traces the checkpoints using a checkpoint graph, determining the validity of an execution sequence.

Checkpoints are declared as start and end checkpoints

WdgM_CheckpointReached()



Configured

Flow Graph

Reaction on monitoring results

For each violation

After n violations

21/55


Watchdog Manager combines all Supervised Entity states to a system state

Depending on the system state the Watchdog Manager triggers the Watchdog Driver

Global Watchdog State

MICROSAR SafeWDG

WdgM

Wdg

OK/NOK

SE1 SE2 SE3 SE4

trigger

22/55


System Basis Chips in the AUTOSAR Stack

MICROSAR SafeWDG

WDGM

WDGIF

WDG Driver (SBC)

SBC Driver

SPI Driver

CAN Transceiver Driver (SBC)

LIN Transceiver Driver (SBC)

Transceiver drivers can be put in different partition than the watchdog stack.

SBC Driver is specific for external hardware unit

SPI Driver is specific for microcontroller

23/55


Configurations

MICROSAR SafeWDG

Watchdog

Internal Watchdog

WDGM

WDGIF

WDGDRV

External Watchdog

WDGM

WDGIF

EXT_WDGDRV

SPI1 or DIO1

System Basis Chip

WDGM

WDGIF

SBC

SPI1

1 Digital I/O (DIO) and Serial Peripheral Interface (SPI) drivers can be developed by Vector or used from another source (e.g. MCAL) if available with the required ASIL.

24/55


Introduction

MICROSAR SafeOS

MICROSAR SafeWDG

MICROSAR SafeE2E

MICROSAR SafeRTE

MICROSAR SafeBSW


Summary

Agenda

25/55


Communication from one SWC to another SWC on a different ECU over an unsafe channel

This channel comprises:

RTE

Com-Stack

Bus Controller

Wiring

Overview E2E

MICROSAR SafeE2E

HW

BSW

SWC

HW

BSW

SWC

E2E is able to detect if fault occurred during the transmission

The application needs to use this information to react on the faults

SafeRTE

SafeOS

MCAL

SafeBSW

SWC

Hardware

SWCSWCS

afe

WD

GSWCSafeE2E

26/55


Overview E2E

MICROSAR SafeE2E

CRC over data, data ID and sequence counter

Allows to detect corruption and masquerading of the signal

Sequence counter

Allows to detect faults in the order of messages

Allows to detect repeated/inserted messages

Timer on receiver side

React on lost messages

React on delayed messaged

Failure of communication peer (even in lower software layers)

Message masquerading

Message corruption

Unintended message repetition

Insertion of messages

Re-sequencing

Message loss

Message delay


See also: ISO 26262 Part 6 D.2.4 Exchange of information

27/55


E2E Protection Wrapper

MICROSAR SafeE2E

RTE RTE

BSW BSW

Bus

verify CRC

E2E LIB

CRC LIB

E2EPW_Write( )

SWC A

Application

E2EProtectionWrapper

E2E LIB

CRC LIB

SWC B

Application

E2EProtectionWrapper

data

data cnt. crc data

data cnt. crcE2EPW_Read( )

status

Rte_Read_<A>_<B>Rte_Write_<A>_<B>

28/55


E2E LIB

CRC LIB

E2E LIB

CRC LIB

E2E Transformer

MICROSAR SafeE2E

RTE

BSWBSW

Bus

Rte_Write_<A>_<B>( )

SWC A SWC B

data

COMXF

E2EXF

RTE

COMXF

E2EXF

Application Application

Rte_Read_<A>_<B>( , )E2E_retdata

data cnt. crc

29/55


Other OEM specific E2E Profiles are available on request.

E2E Profile Overview

MICROSAR SafeE2E

Profile CRC CRC Length Counter Data ID Explicit1 Dynamic Data ID2 Msg. Length3

1 A4 0x1D 8 Bit 4 Bit 16 Bit 0 No 32 Byte

1 B4 0x1D 8 Bit 4 Bit 16 Bit 0 No 32 Byte

1 C 0x1D 8 Bit 4 Bit 16 Bit 4 No 32 Byte

2 0x2F 8 Bit 4 Bit 8 Bit 0 Yes 32 Byte

4 0x1F4ACFB13 32 Bit 16 Bit 32 Bit 32 No 4096 Byte

5 0x1021 16 Bit 8 Bit 16 Bit 0 No4096 Byte

6 0x1021 16 Bit 8 Bit 16 Bit 0 No4096 Byte

7 0x42F0E1EBA9EA3693 64 Bit 32 Bit 32 Bit 32 No 4 MByte

1 How many bits of the data ID are explicitly transmitted

2 Different data IDs for different counter values exist

3 Maximum possible message size

4 Difference between 1A and 1B is the inclusion of different parts of the data ID in the CRC

30/55


Configurations

MICROSAR SafeE2E

E2E Protection

Protection Wrapper Solution

E2EPW

E2ELIB

CRCLIB

Transformer Solution

E2EXf

COMXF and/orSOMEIPXF

E2ELIB

CRCLIBProtection Wrapper only supports Profiles 1, 2 and JLR

31/55


Introduction

MICROSAR SafeOS

MICROSAR SafeWDG

MICROSAR SafeE2E

MICROSAR SafeRTE

MICROSAR SafeBSW


Summary

Agenda

32/55


The RTE can be used to communicate between application software components.

The RTE can provide communication between different memory partitions and connects QM and ASIL software.

The RTE is usually required as ASIL if it is used within the same partition as ASIL application Software Components.

Overview RTE

MICROSAR SafeRTE

Using the RTE in safety relevant ECUs:

The RTE is completely generated using DaVinci Configurator PRO and a corresponding generator.

Thus, ISO 26262 Part 8 Clause 11 (Confidence in the use of software tools) applies.

DaVinci Configurator PRO ECU Software

RTE Generator

RTE.h/RTE.c

BSW Configuration generators

BSW(configuration)

SWCs

BSW(static code)

SafeRTE

SWC

SafeOS

MCAL

SafeBSW

SWC

Hardware

SWCSWCS

afe

WD

GSafeE2E

33/55


Derivation of Tool Confidence Level (TCL)

MICROSAR SafeRTE

Tool

features and their use

cases

TI2

TI1

TD3

TD2

TD1

Tool Impact Tool Error

Detection

Tool Confidence

Level

Tool Classification Tool Qualification

ASIL

Qualification methods for TCL2

No qualification required

Tool classification and qualification are usually performed by the user of the tool.

TCL1

TCL2

TCL3 Qualification methods for TCL3

34/55


Manual qualification of DaVinci Configurator PRO or the generated software by the user is necessary!

RTE vs. SafeRTE

MICROSAR SafeRTE

Classification of RTE:

TI2: “a malfunction of a particular software tool can introduce or fail to detect errors in a safety-related item or element being developed”

TD1: “high degree of confidence that a malfunction and its corresponding erroneous output will be prevented or detected”

Classification of RTE:

TI2: “a malfunction of a particular software tool can introduce or fail to detect errors in a safety-related item or element being developed”

TD2: “there is a medium degree of confidence that a malfunction and its corresponding erroneous output will be prevented or detected”

RTE SafeRTE

Vector provides argumentation to classify DaVinci Configurator PRO as TCL1.

Classification of DaVinci Configurator PRO as TCL2 necessary

No qualification for TCL 1 tools needed!

35/55


Development at Vector

DaVinci Configurator PRO

Development at customer

RTE.h/RTE.cunder test

Arguments for TD1 in Detail

MICROSAR SafeRTE

RTE Generator

RTE.h/RTE.cunder test

RTE.h/RTE.c

ARG3: Output of RTE Generator is integrated and verified according to

ISO 26262:6-10/11 by customer based on configuration feedback provided by RTE

Analyzer.

ARG2: Output of RTE Generator is analyzed by RTE Analyzer.

ARG1: RTE Generator is developed with additional effort.

ARG1a: Output of RTE Generator is tested according to ISO 26262:6-9.

Use during item development by customer

Test during RTE development

36/55


ISO 26262-compliant Software Development with SafeRTE

MICROSAR SafeRTE

Software integration and testing

Verification of software safety requirements

SW Safety Requirements

SW unit testing

SW Architectural Design

SW Unit Design and Implementation

System Description/ ECU Extract

RTE Analysis

DaVinciConfigurator PRO /RTE Generator

Generated RTE codeSoftware unit testing for RTE already performed by Vector

Verification is performed on several levels to ensure that ECU performs as

specified

Requires complete target SW, configuration and target ECU

Requires complete target SW, configuration and (target) ECU

37/55


Fault Detection and Prevention

MICROSAR SafeRTE

Potential faults in generated RTE

Development process of RTE GeneratorVector

Unit test of generated RTEVector

Self-test and validation before generationTool

RTE AnalyzerTool

Usage of non-complex subset of RTE featuresUser of RTE

Integration testing based on output of RTE AnalyzerUser of RTE

Generated RTE is considered sufficiently fault-free for ASIL D here

38/55


Features of the RTE Analyzer

MICROSAR SafeRTE

Compilation check for RTE code

Detection of recursive call sequences

Analysis report generation

General

Detection of RTE variables that are accessed from concurrent execution contexts without protection

Detection of concurrent calls to non-reentrant APIs within the RTE

Detection of variables that are accessed from multiple cores and that are not mapped to non-cacheable memory sections

Concurrent Access

Detection of out-of-bounds write accesses within RTE APIs

Detection of non type-safe interfaces to the BSW and SWCs where a call with a wrong parameter might cause out of bounds writes by the RTE or a called runnable/BSW API

Out-of-bounds Access

Detection of interrupt lock API sequence mismatches within RTE APIs

Detection of unreachable RTE APIs and runnables

Detection of RTE APIs for which a call from a wrong context might cause data consistency problems

RTE API Usage

39/55


RTE

MPU restricts write access from other partitions put may allow read access

Data is stored in own partition and event notifies availability of data

Principle is identical for ASIL ➔ QM communication

Example – Inter-partition Sender/Receiver Communication

MICROSAR SafeRTE

SWC 1

Rte_write()

Part

itio

n

bord

er

Data

element

read access

write access

Partition 2Partition 1

ASIL DQM

SWC 2

Rte_read()

40/55


RTE

BSW

Vector’s SafeRTE automatically generates proxies to allow inter-partition client/server communication.

Example – Inter-partition client/server communication

MICROSAR SafeRTE

C/S proxyService call

Part

itio

n

bord

er

OUT parameter

IN parameter

read access

write access

Partition 2Partition 1

Server runnable

BSW service component

SWC 1

41/55


Introduction

MICROSAR SafeOS

MICROSAR SafeWDG

MICROSAR SafeE2E

MICROSAR SafeRTE

MICROSAR SafeBSW


Summary

Agenda

42/55


MICROSAR SafeBSW

MICROSAR SafeBSW

BSW modules developed according to ASIL D

Certified by exida

SafeBSW can be run in the same OS application as your ASIL SW components.

There is no need for context switches for calls to SafeBSW.

SafeBSW can implement (parts of) safety mechanisms.

SafeRTE

SWC

SafeOS

MCAL

SafeBSW

SWC

Hardware

SWCSWCS

afe

WD

GE2E

43/55


Choosing the Right Approach

MICROSAR SafeBSW

SafeRTE

SWC1 SWC3

RTE

SafeOSBSW

QM PartitionASIL Partition

SWC4SWC2

runtim

e o

verh

ead

SafeRTE

SWC1 SWC3

RTE

SafeOSSafeBSW


SWC4SWC2

Calls from ASIL partition Calls from QM partition

BSW in QM Partition BSW in ASIL Partition

QM BSW (Partitioning Solution)

ASIL BSW (SafeBSW)

Calls to BSW are necessary for e.g. external communication, notifications, …

If the majority of application software has the same ASIL, performance can be boosted by having an ASIL BSW that allows to coexist in the same partition.

[ ]#

#

44/55


Improving Performance

MICROSAR SafeBSW


SafeRTE

SWC1 SWC3

RTE

SafeOS

SafeBSW

SWC4SWC2

QM SWC can use trusted-function calls to call BSW functions

There is a mode-switch, but no context switch ➔ The code is executed on the stack of the caller

Resulting time to cross partition boundary is reduced

Trusted Function stubs can be automatically generated for BSW services

BSW can run in same partition as ASIL SWCs

No partition switch necessary if ASIL SWCs communicate with BSW

Reduced overhead for scheduling of ASIL tasks

Direct access to protected registers possible from ASIL drivers

Speedup of ASIL SWC Comm. Speed-up of QM SWC Comm.

45/55


SafeOS

Safe

WD

GSafeRTE

Safety Requirements

MICROSAR SafeBSW

Hardware

MCAL

Communication Services

(CAN, LIN, FlexRay, Ethernet)

Dia

gn

osti

c S

ervic

es

Memory Services

I/O HW Abstr.

Complex Drivers

System Services

Crypto Services

SWC SWCSWC SWC SWC SWCSWCSWC

Storage of Non-volatile Data

Initialization and Reset

ASIL forCoexistence Only

End-to-end Protection Required

ASIL for CoexistenceOnly

Not useablefor safety

ASIL forCoexistence

Only

Watchdog/SBC Drivers and Digital I/O

SWC SWCSWCSWCSWCSWCE2E

Complex Drivers

I/O HW Abstr.

46/55


Introduction

MICROSAR SafeOS

MICROSAR SafeWDG

MICROSAR SafeE2E

MICROSAR SafeRTE

MICROSAR SafeBSW


Summary

Agenda

47/55


Customer project

Example timeline for Safety Case


1. DeliveryPre-Production

[Production SIP]

2. DeliveryPre-Production[Maintenance]

(optional)

A-Sample

Customer

Vector

Provision of BSW configuration to Vector

(for ASIL C/D)

12 weeksProject-specific

Safety Case activities*

Integration of n-th. Delivery

Request Production(Safety-ready)

Delivery

26 weeksLead Time for

Production (Safety-ready)

SOPB-Sample C-Sample

n-th. DeliveryProduction(Safety-ready)

[Maintenance]

(n+1)-th. DeliveryProduction(Safe)

[Safety Case]

If Safety Case is required, it has to be ordered at latest with the request for Production (Safety-ready)

Standard Lead Time

Order

*) For ASIL A/B project-specific Safety Case activities are started with the Production (Safety-ready) delivery

48/55


The following activities are performed to create a Safety Case by Vector

Validation of component tests> Based on your configuration we examine if Vector’s component tests match your configuration. In doubt Vector

performs additional tests on your configuration.

> Necessary for ASIL C/D only

Confirmation report for completeness by quality department> Our quality department is considered sufficiently independent (I3).

Creation of safety case report> The safety case report summarizes the relevant information, i.e.:

> Set of MICROSAR Safe components

> Configuration

> Microcontroller (and external hardware) derivative

> Compiler and compiler options

> The safety case report is your confirmation from Vector that the basic software has the requested ASIL.

Project-specific Safety Case Activities


49/55


1.MICROSAR Safe Training

1-day basic ISO 26262 knowledge

Conception and application of MICROSAR Safe

2. Integrated Safety Training

2-days hands-on-training with Vector Tools (PREEvision, MICROSAR Safe)

3. ISO 26262 Workshop (Vector Consulting Services)

Implementation of a safety process

Consideration of the specific situation

Option: Usage of MICROSAR Safe within the safety project

4.MICROSAR Safe Workshop

Analysis of the safety concept

Usage of MICROSAR Safe and the Safety Manual

Discussion of technical details regarding MICROSAR Safe

Review of work products

Safety Trainings and Workshops


50/55


Introduction

MICROSAR SafeOS

MICROSAR SafeWDG

MICROSAR SafeE2E

MICROSAR SafeRTE

MICROSAR SafeBSW


Summary

Agenda

51/55


Overview and Availability

Summary

Partitioning: SafeOS availableSafeE2E availableSafeWatchdog available

RTE: SafeRTE available

BSW SafeBSW available for most modules(e.g. ETH will follow)

QM (Tier1/OEM)

ASIL (Tier1/OEM)

ASIL (3rd party)

MICROSAR Safe

MICROSAR QM

1,2: RTE and BSW are either ASIL or QM

SafeRTE1

SWC SWC QM

SafeE2E

SafeOS

MCAL

SafeBSW2

ASIL QM

SWC QM

Hardware

SWC QM

RTE1

BSW2

MCAL

Safe

WD

G

52/55


Components acc. ASIL D available with R22.7 (2019/04)

Summary

3rd Party SoftwareVector Standard Software

1 Includes ExtAdc, EepExt, FlsExt, EthSwtDrvExt, EthDrvExt, vMem and WdgExt2 Functionality represented in EthTSyn and StbM* Different variants available

Vector Standard Software developed acc. to ASIL D

Vector Standard Software developed acc. to ASIL B

Application

Rte

OS

Os

ComplexDriver

Microcontroller

E2ePw

SYS

BswM

ComM

Det

EcuM

StbM

Tm

WdgIf

WdgM

CRYPTO

Csm

CryIf

DIAG

Dcm

Dem

vDes

FiM

J1939Dcm

vDrm

AMD

vDbg

Dlt

vRtm

Xcp

OTA

MEM

Ea

Fee

MemIf

NvMCAN

J1939Tp

J1939Nm

J1939Rm

CanXcp

CanTp

CanNm

CanSM

CanTSyn

CanIf

LIN

vLinXcp

vLinTp

LinNm

LinSM

LinIf

FR

FrXcp

FrTp

FrArTp

FrNm

FrSM

FrTSyn

FrIf

COM

Com LdCom

IpduM Mirror

Nm

ComXf

SomeIpXfE2eXf

PduR

SecOC

ETH

EthXcp

UdpNm

Sd

DoIP

SoAd

vEtm

vTls

TcpIp

EthSM

EthTSyn

vEthFw

EthIf

IO

vDioHwAb

LIBS

Crc

E2e

AVB

vRtp

vAvTp

vSrp

vPtp2

V2X

V2xBtp

V2xFac

V2xGn

V2xM

MCAL

Adc

Can

CorTst

Dio

Eep

Eth

EthSwt

Fls

FlsTst

Fr

Gpt

Icu

vI2c

Lin

Mcu

Ocu

Port

Pwm

RamTstCrypto(Hw)*

Spi

Wdg

WEthCrypto(vHsm)

EXT

CanTrcv

Ext1

EthTrcv

FrTrcv

LinTrcv

vSbc

WEthTrcv

CHARGE

vDns

vExi

vHttp

vScc

vXmlSecurity

vCanCcCdm

vCanCcGbt

IPC

vIpc

vIpcMem*

vIpcMemIf*

HSM

vHsm

Crypto (Sw)

vOtaDl

vIpcAd Posix

vLhyp

vEcuAuth

KeyM

vJson

vXmlEngine

vEap

SomeIpTp

vIpcSpiIf*

53/55


Safety Building Blocks of MICROSAR Safe

Summary

Supports memory partitioning using an MPU

Provides safe context switch for each safety related task:

register settings


MPU settings


OS Applications can be restated individually

Detects timing and execution order faults

Provides deadline, alive and logic monitoring

Capable of using internal or external watchdogs as well as system basis chips (SBCs)

Ensures safe communication between ECUs

Available as E2E Protection Wrapper and E2E Transformer

All AUTOSAR profiles supported

MICROSAR SafeOS MICROSAR SafeWDG

MICROSAR SafeE2E

Ensures safe communication within the ECU

Supports safe communication across partition boundaries to exchange information between ASIL and QM applications

MICROSAR SafeRTE

Increased performance

complete BSW as ASIL software

Reduced partition switches

Additional safety requirements, e.g.:

Correct initialization using an ASIL EcuM

Safe write/read of non-volatile data

MICROSAR SafeBSW

54/55


Author:Günther Heling, Jonas WolfVector Germany

For more information about Vectorand our products please visit

www.vector.com

http://www.vector.com/

functional safety and ecu implementation - vector...functional safety introduction iso 26262 has...

Documents