Vector Safety Solution

Embedded Software for Functional Safety
MICROSAR Safe
V3.02.01 | 2019-07-12
Introduction
Functional Safety
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/53 © 2018. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V3.02.01 | 2019-07-12
Introduction
ISO 26262-compliant Development
Item Definition
Hazard Analysis and Safety Validation

Risk Assessment
Derivation of
OEM Safety Goals
Functional Safety
Concept
Item Integration and
Testing
Technical Safety
Tier 1 Concept
Basic SW Appl. SW
Hardware Development
Development Development
Vector
Introduction
Achieving Safety Together!
Vehicle Project SEooC (Vector)
Hazard Analysis and Risk Assessment
Specific Use-case
is Unknown!
Derivation of
Safety Goals
Assumptions on Technical Safety

Safety Concept validate !
Requirements
Software Development acc. ISO 26262 Software Development acc. ISO 26262
Software Safety Requirements Software Safety Requirements
ECU SW Integration consider ! Safety Manual
Safety Case reference ! Safety Case
Introduction
Evolution of Safety Concepts
fail-safe
Redundancy
(e.g. redundant data)
Enhancing Partitioning
driver actions
High Performance
Integrity
fail-operational
Redundancy
(redundant functions)
Taking over
driver decision
Introduction
In many cases we see mixed-ASIL Systems
SW Safety Requirements
QM QM QM QM ASIL ASIL ASIL Software Elements
ECU Software
QM ASIL QM ASIL QM ASIL
ECU 1 ECU 2 ECU 3 ECU 4
Adequate High Performance

Partitioning
Safety Concepts: Integrity
Introduction
Safety Concepts and Contribution of MICROSAR Safe
Partitioning High Performance Integrity

ASIL QM ASIL QM
SWC SWC SWC SWC SWC SafeE2E SWC SWC SWC

SafeE2E
SafeRTE SafeRTE
SafeWDG
SafeWDG
BSW SafeBSW
SafeOS SafeOS
MCAL MCAL
Hardware Hardware
MSR Safe Components Rationale MSR Safe Components Rationale
ISO 26262 requires that software ISO 26262 requires to implement

 SafeOS  SafeOS
with different ASIL in the same software components of different
 SafeWDG element do not interfere with  SafeWDG ASIL, or safety-related and non-
respect to memory, timing and safety-related software
 SafeE2E  SafeE2E components, in accordance
communication aspects
 SafeRTE with the highest ASIL
 SafeRTE
 SafeBSW
Introduction
Safety Building Blocks of MICROSAR Safe
MICROSAR SafeOS MICROSAR SafeWDG
 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)
 Supports memory partitioning using an MPU

 Provides safe context switch for each safety related task: MICROSAR SafeE2E
 register settings
 Ensures safe communication between ECUs
 stack pointer and program counter
 Available as E2E Protection Wrapper and E2E Transformer
 MPU settings
 Available for single- and multi-core  All AUTOSAR profiles supported
 OS Applications can be restarted individually
MICROSAR SafeRTE MICROSAR SafeBSW
 Ensures safe communication within the ECU  Increased performance

 Supports safe communication across partition boundaries to  complete BSW as ASIL software
exchange information between ASIL and QM applications  reduced partition switches
 Additional safety requirements, e.g.:
 Correct initialization using an ASIL EcuM
 Safe write/read of non-volatile data
Agenda
Introduction
 MICROSAR SafeOS
MICROSAR SafeWDG
MICROSAR SafeE2E
MICROSAR SafeRTE
MICROSAR SafeBSW
Process and Services
Summary
MICROSAR SafeOS
MICROSAR SafeOS
SWC SWC SWC SWC

 Completely developed according to ASIL D
E2E
 Provides features to argue freedom from interference for application and BSW
SafeRTE
regarding
 Memory: Supports memory separation using the MPU
SafeWDG
SafeBSW
SafeOS  Timing: Detection of time-budget violations
 Provides safe context switching for each safety related task:
MCAL
Hardware  stack pointer and program counter

 MPU settings
 Available for single- and multi-core
 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
MICROSAR SafeOS
Overview SafeOS
Which faults are possible? How do we address them?

 Memory violations  Memory Partitioning
 Wild Pointers  OS Applications can be defined that are protected
 Stack overflow by the MPU
 Writing outside of intended memory location of  Protected peripheral access
variables  Stack Protection
 Timing violations
 Stack is separately protected by the MPU
 Endless loops
 Indicator values detect stack overflows also for
 Too frequent interrupts systems without MPU
 Longer calculation times due to unexpected input  Timing protection
 Time budgets are monitored
 Termination of applications
MICROSAR SafeOS
Partitioning
 The memory of individual OS Applications can be MPU Region 1 1 (rw) OS Application 1
protected against writing by other OS MPU Region 2 Task 1: Stack

*(r)
Applications MPU Region 3
Task 1: Code
1(rw)
 This requires dedicated hardware support MPU Region 4
Task 1: Data
(MMU/MPU) MPU Region 5
MPU Region 6 1,2 (rw)

 Reading between OS Applications is typically not
restricted Shared Memory
 OS is re-programming the MPU if the number of

available regions is not sufficient
Software MPU RAM
Application 1 Task1
Application A
Application B
Application 2 Task 2
Operating
Task 3
System
 Context
Switching
MICROSAR SafeOS
Timing Protection
 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)
Budget
Overrun
Task 3
Deadline
violation
Task 2
Task 1
Time
MICROSAR SafeOS
Access to Peripheral Registers
 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
Memory Map ASIL OS-Appl. QM OS-Appl.
MPU BSW
MICROSAR
LIN SafeOS
CAN
driver
CAN
Timer
MICROSAR SafeOS
Register Access API
 Example
BSW OS
…
osWritePeripheral8(id,addr,val) osWritePeripheral8(uint16 area,
… uint32 address, uint8 value)
{
// Validate access request
// Change to supervisor mode
// Perform access
// Change to previous mode
}
 API provided functions for read, modify and write access

 The functions are defined for 8 Bit,16 Bit and 32 Bit registers
Agenda
Introduction
MICROSAR SafeOS
 MICROSAR SafeWDG
MICROSAR SafeE2E
MICROSAR SafeRTE
MICROSAR SafeBSW
Summary
MICROSAR SafeWDG
Overview Watchdog
 A watchdog can detect timing violations in the

Checkpoint SWC Checkpoint SWC SWC
Application and BSW
MICROSAR RTE  Also provides Program Flow Monitoring up to ASIL D
 Is supervised by independent HW-Watchdog
Checkpoint
WdgM
 On detected violations in a supervised entity the ECU can
Safe Complex Drivers

BSW
be reset
WdgIf
 Acknowledgements of a checkpoint are performed
BSW
without context switch
MCAL WdgDrv
Microcontroller
Watchdog
QM Software ASIL Software
MICROSAR SafeWDG
Overview SafeWDG

 Execution of code without request  Deadline Monitoring
 Code not executed although requested  Applicable for aperiodic entities
 Execution of code started too early or too late  Time between two checkpoints is compared to
 The execution time of an code is longer or shorter min/max values
than expected  Alive Monitoring
 The program flow of an code differs from the expected
 Applicable for periodic entities
behavior
 Number of checkpoints in interval is monitored
 Logic Monitoring
 Detect wrong execution order
 Validate checkpoint activation sequence against
preconfigured execution graphs
 It is assumed for all MICROSAR Safe components, that timing faults are handled using
a watchdog.
MICROSAR SafeWDG
Alive Monitoring
 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 𝑛 × WdgM_CheckpointReached()
 not too frequently

 not too rarely.
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.
MICROSAR SafeWDG
Deadline Monitoring
 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
WdgM_CheckpointReached() WdgM_CheckpointReached()
 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
MICROSAR SafeWDG
Logic Monitoring
Configured
WdgM_CheckpointReached()
Flow Graph
 The execution order of the code is monitored  Reaction on monitoring results

 The Watchdog-Manager traces the checkpoints using a  For each violation
checkpoint graph, determining the validity of an  After n violations
execution sequence.
 Checkpoints are declared as start and end checkpoints
MICROSAR SafeWDG
Global Watchdog State
 Watchdog Manager combines all Supervised Entity states to a system state

 Depending on the system state the Watchdog Manager triggers the Watchdog Driver
SE1 SE2 SE3 SE4
WdgM
OK/NOK
trigger
Wdg
MICROSAR SafeWDG
System Basis Chips in the AUTOSAR Stack
WDGM
WDGIF Transceiver drivers can be put in different partition than the watchdog
stack.
CAN Transceiver Driver LIN Transceiver Driver

WDG Driver (SBC) (SBC) (SBC)
SBC Driver
SBC Driver is specific for external hardware unit
SPI Driver is specific for microcontroller
SPI Driver
MICROSAR SafeWDG
Configurations
Watchdog
Internal Watchdog External Watchdog System Basis Chip
WDGM WDGM WDGM
WDGIF WDGIF WDGIF
WDGDRV EXT_WDGDRV SBC
1 Digital I/O (DIO) and Serial Peripheral

Interface (SPI) drivers can be developed
SPI1 or DIO1 SPI1 by Vector or used from another source
(e.g. MCAL) if available with the
required ASIL.
Agenda
Introduction
MICROSAR SafeOS
MICROSAR SafeWDG
 MICROSAR SafeE2E
MICROSAR SafeRTE
MICROSAR SafeBSW
Summary
MICROSAR SafeE2E
Overview E2E
SWC
SWC SWC SWC  Communication from one SWC to another SWC on a different
SafeE2E
ECU over an unsafe channel
SafeRTE
 This channel comprises:
 RTE
SafeWDG
SafeBSW
SafeOS  Com-Stack
 Bus Controller
MCAL
 Wiring
Hardware
 E2E is able to detect if

fault occurred during the
transmission SWC SWC
 The application needs to

use this information to
react on the faults BSW BSW
HW HW
MICROSAR SafeE2E
Overview E2E

 Failure of communication peer  CRC over data, data ID and sequence counter
(even in lower software layers)
 Allows to detect corruption and masquerading of
 Message masquerading the signal
 Message corruption
 Sequence counter
 Allows to detect faults in the order of messages
 Unintended message repetition
 Allows to detect repeated/inserted messages
 Insertion of messages
 Re-sequencing  Timer on receiver side
 React on lost messages
 Message loss  React on delayed messaged
 Message delay
See also: ISO 26262 Part 6 D.2.4 Exchange of information
MICROSAR SafeE2E
E2E Protection Wrapper
SWC A SWC B
E2EPW_Read( data cnt. crc )
Application Application
E2EPW_Write( data )
E2E E2E
Protection data status
Protection
data cnt. crc
Wrapper Wrapper
E2E LIB E2E LIB
Rte_Write_<A>_<B> Rte_Read_<A>_<B>
CRC LIB CRC
verifyLIB
CRC
RTE RTE
BSW BSW
Bus
MICROSAR SafeE2E
E2E Transformer
SWC A SWC B
Application Application
Rte_Write_<A>_<B>( data ) Rte_Read_<A>_<B>( data , E2E_ret )
RTE RTE
COMXF COMXF
E2EXF E2E LIB E2E LIB E2EXF
data cnt. crc

CRC LIB CRC LIB
BSW
BSW
Bus
MICROSAR SafeE2E
E2E Profile Overview
Other CRC
Profile OEM specific E2E Profiles are available
CRC Length Counter on request.
Data ID Explicit1
Dynamic Data
Msg. Length3
ID2
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
1C 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
4096 Byte
5 0x1021 16 Bit 8 Bit 16 Bit 0 No
4096 Byte
6 0x1021 16 Bit 8 Bit 16 Bit 0 No
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
MICROSAR SafeE2E
Configurations
E2E Protection
Protection Wrapper
Transformer Solution
Solution
E2EPW E2EXf
COMXF and/or
E2ELIB
SOMEIPXF
CRCLIB E2ELIB
CRCLIB
Protection Wrapper only supports Profiles 1, 2 and JLR
Agenda
Introduction
MICROSAR SafeOS
MICROSAR SafeWDG
MICROSAR SafeE2E
 MICROSAR SafeRTE
MICROSAR SafeBSW
Summary
MICROSAR SafeRTE
Overview RTE
SWC
SWC SWC SWC  The RTE can be used to communicate between
SafeE2E
application software components.
SafeRTE
 The RTE can provide communication between different
memory partitions and connects QM and ASIL
SafeWDG
SafeBSW software.
SafeOS
 The RTE is usually required as ASIL if it is used within
MCAL the same partition as ASIL application Software
Hardware
Components.
DaVinci Configurator PRO ECU Software
 Using the RTE in safety relevant ECUs:

SWCs
 The RTE is completely generated RTE Generator
using DaVinci Configurator PRO and a

corresponding generator. RTE.h/RTE.c
 Thus, ISO 26262 Part 8 Clause 11 BSW Configuration BSW

(Confidence in the use of software generators (configuration)
tools) applies. BSW

(static code)
MICROSAR SafeRTE
Derivation of Tool Confidence Level (TCL)
Tool Confidence
Tool Impact Tool Error ASIL
Level
Detection
TCL3 Qualification methods for TCL3
TD3
TI2 TD2 TCL2 Qualification methods for TCL2

Tool
features and their use TD1
cases
TI1 TCL1 No qualification required
Tool Classification Tool Qualification
Tool classification and qualification are usually performed by the user of the tool.
MICROSAR SafeRTE
RTE vs. SafeRTE
RTE SafeRTE
 Classification of RTE:  Classification of RTE:
 TI2: “a malfunction of a particular software tool can  TI2: “a malfunction of a particular software tool
introduce or fail to detect errors in a safety-related can introduce or fail to detect errors in a safety-
item or element being developed” related item or element being developed”
 TD2: “there is a medium degree of confidence
 TD1: “high degree of confidence that a
that a malfunction and its corresponding
malfunction and its corresponding erroneous
erroneous output will be prevented or detected”
output will be prevented or detected”
Classification of DaVinci Configurator PRO Vector provides argumentation to classify

as TCL2 necessary DaVinci Configurator PRO as TCL1.
Manual qualification of
DaVinci Configurator PRO or the
generated software by the user is
necessary!
 No qualification for TCL 1 tools needed!
MICROSAR SafeRTE
Arguments for TD1 in Detail
Development at Vector Development at customer

Test during RTE
development RTE.h/RTE.c
RTE.h/RTE.c
under test
under test
DaVinci Configurator PRO
RTE Generator
RTE.h/RTE.c
Use during item

development by customer
ARG1: RTE Generator is developed with additional effort. ARG2: Output of RTE Generator is analyzed
by RTE Analyzer.
ARG1a: Output of RTE Generator is tested according to ISO 26262:6-9.
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.
MICROSAR SafeRTE
ISO 26262-compliant Software Development with SafeRTE
Verification of software
SW Safety Requirements
safety requirements
Requires complete target

Verification is performed on several SW, configuration and
levels to ensure that ECU performs as target ECU
specified
Software integration and

SW Architectural Design
testing
Requires complete
System Description/ target SW, configuration
ECU Extract and (target) ECU
DaVinci
Configurator PRO
/RTE Generator
SW Unit Design and

SW unit testing
Implementation
Software unit testing for RTE

Generated RTE code RTE Analysis already performed by Vector
MICROSAR SafeRTE
Fault Detection and Prevention
Potential faults in generated RTE
Development process of RTE Generator

Vector
Unit test of generated RTE

Vector
Self-test and validation before generation

Tool
Usage of non-complex subset of RTE features

User of RTE
RTE Analyzer
Tool
Integration testing based on output of RTE

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

MICROSAR SafeRTE
Features of the RTE Analyzer
General Out-of-bounds Access

 Compilation check for RTE code  Detection of out-of-bounds write accesses within RTE
APIs
 Detection of recursive call sequences
 Detection of non type-safe interfaces to the BSW and
 Analysis report generation
SWCs where a call with a wrong parameter might
cause out of bounds writes by the RTE or a called
runnable/BSW API
Concurrent Access RTE API Usage

 Detection of RTE variables that are accessed from  Detection of interrupt lock API sequence mismatches
concurrent execution contexts without protection within RTE APIs
 Detection of concurrent calls to non-reentrant APIs  Detection of unreachable RTE APIs and runnables
within the RTE
 Detection of RTE APIs for which a call from a wrong
 Detection of variables that are accessed from multiple context might cause data consistency problems
cores and that are not mapped to non-cacheable
memory sections
Agenda
Introduction
MICROSAR SafeOS
MICROSAR SafeWDG
MICROSAR SafeE2E
MICROSAR SafeRTE
 MICROSAR SafeBSW
Summary
MICROSAR SafeBSW
MICROSAR SafeBSW
SWC SWC SWC SWC  BSW modules developed according to ASIL D

E2E
 Certified by exida
SafeRTE
SafeWDG
SafeBSW
SafeOS  SafeBSW can be run in the same OS application as your ASIL
SW components.
MCAL
 There is no need for context switches for calls to SafeBSW.
Hardware
 SafeBSW can implement (parts of) safety mechanisms.
MICROSAR SafeBSW
Choosing the Right Approach
BSW in QM Partition BSW in ASIL Partition

ASIL Partition QM Partition ASIL Partition QM Partition
SWC1 SWC2 SWC3 SWC4 SWC1 SWC2 SWC3 SWC4
SafeRTE RTE SafeRTE RTE
SafeOS SafeOS
BSW SafeBSW
Calls from ASIL partition Calls from QM partition
 Calls to BSW are necessary for e.g. external communication, notifications, …
runtime overhead
QM BSW (Partitioning Solution)
ASIL BSW (SafeBSW)
[ ]
#
#
 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.
MICROSAR SafeBSW
Improving Performance
ASIL Partition QM Partition
SWC1 SWC2 SWC3 SWC4
SafeRTE RTE
SafeOS
SafeBSW
Speedup of ASIL SWC Comm. Speed-up of QM SWC Comm.

 BSW can run in same partition as ASIL SWCs  QM SWC can use trusted-function calls to call BSW
functions
 No partition switch necessary if ASIL SWCs
communicate with BSW  There is a mode-switch, but no context switch ➔ The
code is executed on the stack of the caller
 Reduced overhead for scheduling of ASIL tasks
 Resulting time to cross partition boundary is reduced
 Direct access to protected registers possible from ASIL
drivers  Trusted Function stubs can be automatically
generated for BSW services
MICROSAR SafeBSW
Safety Requirements
SWC E2E SWC SWC SWC SWC SWC SWC SWC
SafeRTE
Storage of Non-
Memory Services
volatile Data
Diagnostic Services
Not useable
SafeWDG
End-to-end Protection
Communication
for safety
Complex I/O HW Initialization and Required
Services
System Services ASIL for
Drivers Abstr. Reset (CAN,
ASIL LIN,
for FlexRay,
Coexistence
SafeOS Coexistence Ethernet)
Only
Only
ASIL for
Crypto Services
Coexistence Only
Watchdog/SBC MCAL
Drivers and Digital I/O
Hardware
Agenda
Introduction
MICROSAR SafeOS
MICROSAR SafeWDG
MICROSAR SafeE2E
MICROSAR SafeRTE
MICROSAR SafeBSW
 Process and Services
Summary
Example timeline for Safety Case
A-Sample B-Sample C-Sample SOP

Customer project
Order Request Provision of BSW

Production(Safety-ready) configuration to Vector
Delivery (for ASIL C/D)
Integration of
n-th. Delivery
1. Delivery 2. Delivery n-th. Delivery (n+1)-th. Delivery

Pre-Production Pre-Production Production(Safety-ready) Production(Safe)
[Production SIP] [Maintenance] [Maintenance] [Safety Case]
(optional)
Customer
Vector
Standard Lead 26 weeks 12 weeks
Time Lead Time for Project-specific
Production Safety Case
(Safety-ready) activities*
If Safety Case is required, it has to be ordered at latest

with the request for Production (Safety-ready)
*) For ASIL A/B project-specific Safety Case activities
are started with the Production (Safety-ready) delivery
Project-specific Safety Case Activities
 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.
Safety Trainings and Workshops
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
Agenda
Introduction
MICROSAR SafeOS
MICROSAR SafeWDG
MICROSAR SafeE2E
MICROSAR SafeRTE
MICROSAR SafeBSW
 Summary
Summary
Overview and Availability
ASIL QM
ASIL (Tier1/OEM)
QM (Tier1/OEM)
SWC SWC QM SWC QM SWC QM
SafeE2E MICROSAR Safe
MICROSAR QM
SafeRTE1 RTE1
ASIL (3rd party)
1,2:RTE and BSW are
either ASIL or QM
 Partitioning: SafeOS available

SafeBSW2
SafeWDG
BSW2 SafeE2E available

SafeOS SafeWatchdog available
 RTE: SafeRTE available
 BSW SafeBSW available

MCAL MCAL
for most
modules
(e.g. ETH
Hardware will follow)
Summary
Components acc. ASIL D available with R22.7 (2019/04)
E2ePw Application
Rte
OS SYS DIAG MEM COM IO LIBS

vLhyp BswM Dcm Ea Com E2eXf LdCom Nm SecOC SomeIpXf vDioHwAb Crc
Os ComM Dem Fee ComXf IpduM Mirror PduR SomeIpTp E2e
Det vDes MemIf
CAN LIN FR ETH IPC CHARGE
EcuM vDrm NvM
CanIf LinIf FrArTp DoIP vIpc vCanCcCdm
StbM FiM
CanNm LinNm FrIf vEap vIpcAd Posix vCanCcGbt
Tm J1939Dcm
CanSM LinSM FrNm vEthFw vIpcMem* vDns
V2X
WdgIf
CanTp vLinTp FrSM EthIf vIpcMemIf* vExi
V2xBtp
WdgM AMD OTA vHttp
CanTSyn vLinXcp FrTp EthSM vIpcSpiIf*
V2xFac
vDbg vOtaDl CanXcp FrTSyn EthTSyn vJson
V2xGn
Dlt J1939Nm FrXcp EthXcp vScc
V2xM
CRYPTO vRtm J1939Rm vEtm vXmlEngine
CryIf J1939Tp Sd vXmlSecurity Complex
Driver
Crypto (Sw) SoAd AVB
Csm TcpIp vAvTp
vEcuAuth vTls vPtp2
KeyM UdpNm vRtp
Xcp vSrp
HSM MCAL EXT

vHsm Adc Crypto(Hw)* EthSwt Gpt Mcu RamTst CanTrcv LinTrcv
Can Dio Fls vI2c Ocu Spi Ext1 vSbc
CorTst Eep FlsTst Icu Port Wdg EthTrcv WEthTrcv
Crypto(vHsm) Eth Fr Lin Pwm WEth FrTrcv
Microcontroller
1 Includes ExtAdc, EepExt, FlsExt, EthSwtDrvExt, EthDrvExt, vMem and WdgExt

Vector Standard Software 3rd Party Software Vector Standard Software developed acc. to ASIL D 2 Functionality represented in EthTSyn and StbM
Vector Standard Software developed acc. to ASIL B * Different variants available
Summary
Safety Building Blocks of MICROSAR Safe
MICROSAR SafeOS MICROSAR SafeWDG
 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)
 Supports memory partitioning using an MPU

 Provides safe context switch for each safety related task:
MICROSAR SafeE2E
 stack pointer and program counter  Ensures safe communication between ECUs
 MPU settings  Available as E2E Protection Wrapper and E2E Transformer
 Available for single- and multi-core  All AUTOSAR profiles supported
 OS Applications can be restated individually
MICROSAR SafeRTE MICROSAR SafeBSW
 Ensures safe communication within the ECU  Increased performance

 Supports safe communication across partition boundaries to  complete BSW as ASIL software
exchange information between ASIL and QM applications  Reduced partition switches
 Additional safety requirements, e.g.:
 Correct initialization using an ASIL EcuM
 Safe write/read of non-volatile data
For more information about Vector
and our products please visit
www.vector.com
Author:
Dr. Günther Heling, Jonas Wolf
Vector Germany
© 2018. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V3.02.01 | 2019-07-12

Vector Safety Solution

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vector Safety Solution

Uploaded by

Copyright:

Available Formats

Embedded Software for Functional Safety

Hazard Analysis and Safety Validation

Vehicle Project SEooC (Vector)

Hazard Analysis and Risk Assessment

Assumptions on Technical Safety

Software Safety Requirements Software Safety Requirements

ECU SW Integration consider ! Safety Manual

Safety Case reference ! Safety Case

QM QM QM QM ASIL ASIL ASIL Software Elements

ECU 1 ECU 2 ECU 3 ECU 4

Adequate High Performance

Partitioning High Performance Integrity

SWC SWC SWC SWC SWC SafeE2E SWC SWC SWC

MSR Safe Components Rationale MSR Safe Components Rationale

ISO 26262 requires that software ISO 26262 requires to implement

MICROSAR SafeOS MICROSAR SafeWDG

 Detects timing and execution order faults

 Supports memory partitioning using an MPU

MICROSAR SafeRTE MICROSAR SafeBSW

 Ensures safe communication within the ECU  Increased performance

SWC SWC SWC SWC

Hardware  stack pointer and program counter

 Features additional to AUTOSAR OS SC3/SC4:

Which faults are possible? How do we address them?

 The memory of individual OS Applications can be MPU Region 1 1 (rw) OS Application 1

protected against writing by other OS MPU Region 2 Task 1: Stack

MPU Region 6 1,2 (rw)

 OS is re-programming the MPU if the number of

Software MPU RAM

 Execution budgets are assigned to tasks and monitored

 Timing Protection vs. Watchdog

 Access to restricted registers might only be possible in supervisor mode

Memory Map ASIL OS-Appl. QM OS-Appl.

 API provided functions for read, modify and write access

 A watchdog can detect timing violations in the

Safe Complex Drivers

QM Software ASIL Software

Which faults are possible? How do we address them?

 not too frequently

 The execution order of the code is monitored  Reaction on monitoring results

 Watchdog Manager combines all Supervised Entity states to a system state

SE1 SE2 SE3 SE4

CAN Transceiver Driver LIN Transceiver Driver

Internal Watchdog External Watchdog System Basis Chip

WDGM WDGM WDGM

WDGIF WDGIF WDGIF

WDGDRV EXT_WDGDRV SBC

1 Digital I/O (DIO) and Serial Peripheral

 E2E is able to detect if

 The application needs to

Which faults are possible? How do we address them?

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

E2E LIB E2E LIB

Rte_Write_<A>_<B>( data ) Rte_Read_<A>_<B>( data , E2E_ret )

E2EXF E2E LIB E2E LIB E2EXF

data cnt. crc

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

1C 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

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

1 How many bits of the data ID are explicitly transmitted