Safety_Manual_CBD1601056_D05s

 
 
 
 
 
 
 
 
 
 
Safety Manual 
CBD1601056 D05 
 
 
 
 
 
 
 
 
 
 
 
 
 
ID 
SPECDOC42381 
Status 
Draft 
Generated on 
2018-07-31 08:53 
 

---

Safety Manual CBD1601056 D05 
Contents 
Safety Manual ..................................................................................................................... 10 
1 General Part .................................................................................................................... 11 
1.1 Introduction................................................................................................................ 11 
1.1.1 Purpose ............................................................................................................. 11 
1.1.2 Scope ................................................................................................................ 11 
1.1.3 Definitions .......................................................................................................... 11 
1.1.4 References ........................................................................................................ 12 
1.1.5 Overview ............................................................................................................ 12 
1.2 Concept ..................................................................................................................... 12 
1.2.1 Technical Safety Requirements .......................................................................... 13 
1.2.1.1 Initialization................................................................................................. 13 
1.2.1.2 Self-test ...................................................................................................... 13 
1.2.1.3 Reset of ECU ............................................................................................. 13 
1.2.1.4 Data consistency ........................................................................................ 14 
1.2.1.5 Non-volatile memory ................................................................................... 14 
1.2.1.5.1 Saving data ......................................................................................... 14 
1.2.1.5.2 Loading data ....................................................................................... 14 
1.2.1.6 Scheduling.................................................................................................. 15 
1.2.1.6.1 Deterministic, hard real-time scheduling .............................................. 15 
1.2.1.7 Partitioning ................................................................................................. 15 
1.2.1.7.1 Memory partitioning ............................................................................. 15 
1.2.1.7.2 Time partitioning .................................................................................. 15 
1.2.1.8 Communication protection .......................................................................... 16 
1.2.1.8.1 Inter ECU communication ................................................................... 16 
1.2.1.8.2 Intra ECU communication ................................................................... 16 
1.2.1.9 Watchdog services ..................................................................................... 17 
2018 Vector Informatik GmbH 
1.0 
2 / 103 

---

Safety Manual CBD1601056 D05 
1.2.1.9.1 Program flow monitoring ..................................................................... 17 
1.2.1.9.2 Alive monitoring ................................................................................... 17 
1.2.1.9.3 Deadline monitoring ............................................................................ 17 
1.2.1.10 Peripheral in- and output .......................................................................... 17 
1.2.1.10.1 Peripheral input ................................................................................. 17 
1.2.1.10.2 Peripheral output ............................................................................... 17 
1.2.2 Environment ....................................................................................................... 18 
1.2.2.1 Safety Concept ........................................................................................... 18 
1.2.2.2 Use of MICROSAR Safe Components ........................................................ 20 
1.2.2.3 Partitioning ................................................................................................. 21 
1.2.2.4 Resources .................................................................................................. 22 
1.2.3 Process .............................................................................................................. 22 
2 Safety Manual BswM ....................................................................................................... 25 
2.1 Safety features .......................................................................................................... 25 
2.2 Configuration constraints ........................................................................................... 25 
2.3 Additional Verification measures ................................................................................ 25 
2.4 Safety features required from other components ....................................................... 25 
2.5 Dependencies to hardware ........................................................................................ 25 
3 Safety Manual CanIf ........................................................................................................ 26 
3.1 Safety features .......................................................................................................... 26 
3.2 Configuration constraints ........................................................................................... 26 
3.3 Additional verification measures ................................................................................ 26 
3.4 Safety features required from other components ....................................................... 28 
3.5 Dependencies to hardware ........................................................................................ 28 
4 Safety Manual CanNm .................................................................................................... 29 
4.1 Safety features .......................................................................................................... 29 
4.2 Configuration constraints ........................................................................................... 29 
4.3 Additional verification measures ................................................................................ 29 
2018 Vector Informatik GmbH 
1.0 
3 / 103 

---

Safety Manual CBD1601056 D05 
4.4 Safety features required from other components ....................................................... 29 
4.5 Dependencies to hardware ........................................................................................ 29 
5 Safety Manual CanSM ..................................................................................................... 30 
5.1 Safety features .......................................................................................................... 30 
5.2 Configuration constraints ........................................................................................... 30 
5.3 Additional verification measures ................................................................................ 30 
5.4 Safety features required from other components ....................................................... 30 
5.5 Dependencies to hardware ........................................................................................ 30 
6 Safety Manual CanTp ...................................................................................................... 31 
6.1 Safety features .......................................................................................................... 31 
6.2 Configuration constraints ........................................................................................... 31 
6.3 Additional verification measures ................................................................................ 31 
6.4 Safety features required from other components ....................................................... 31 
6.5 Dependencies to hardware ........................................................................................ 31 
7 Safety Manual Com ......................................................................................................... 32 
7.1 Safety features .......................................................................................................... 32 
7.2 Configuration constraints ........................................................................................... 32 
7.3 Additional verification measures ................................................................................ 32 
7.4 Safety features required from other components ....................................................... 33 
7.5 Dependencies to hardware ........................................................................................ 33 
8 Safety Manual ComM ...................................................................................................... 34 
8.1 Safety features .......................................................................................................... 34 
8.2 Configuration constraints ........................................................................................... 34 
8.3 Additional Verification measures ................................................................................ 34 
8.4 Safety features required from other components ....................................................... 35 
8.5 Dependencies to hardware ........................................................................................ 35 
9 Safety Manual Crc ........................................................................................................... 36 
9.1 Safety features .......................................................................................................... 36 
2018 Vector Informatik GmbH 
1.0 
4 / 103 

---

Safety Manual CBD1601056 D05 
9.2 Configuration constraints ........................................................................................... 36 
9.3 Additional verification measures ................................................................................ 36 
9.4 Dependencies to other components .......................................................................... 36 
9.4.1 Safety features required from other components ................................................ 36 
9.4.2 Coexistence with other components ................................................................... 36 
9.5 Dependencies to hardware ........................................................................................ 36 
10 Safety Manual Csm ....................................................................................................... 37 
10.1 Safety Features ....................................................................................................... 37 
10.2 Configuration constraints ......................................................................................... 37 
10.3 Additional verification measures .............................................................................. 37 
10.4 Dependencies to other components ........................................................................ 37 
10.4.1 Safety features required from other components .............................................. 37 
10.5 Dependencies to hardware ...................................................................................... 38 
11 Safety Manual Det ......................................................................................................... 39 
11.1 Safety features......................................................................................................... 39 
11.2 Configuration constraints ......................................................................................... 39 
11.3 Additional Verification measures .............................................................................. 39 
11.4 Safety features required from other components ..................................................... 39 
11.5 Dependencies to hardware ...................................................................................... 39 
12 Safety Manual EcuM ..................................................................................................... 40 
12.1 Safety features ........................................................................................................ 40 
12.2 Configuration constraints ......................................................................................... 42 
12.3 Additional verification measures .............................................................................. 42 
12.4 Safety features required from other components ..................................................... 43 
12.5 Dependencies to hardware ...................................................................................... 44 
13 Safety Manual Fee ......................................................................................................... 45 
13.1 Safety features ........................................................................................................ 45 
13.2 Configuration constraints ......................................................................................... 45 
2018 Vector Informatik GmbH 
1.0 
5 / 103 

---

Safety Manual CBD1601056 D05 
13.3 Additional Verification measures .............................................................................. 45 
13.4 Safety features required from other components ..................................................... 45 
13.5 Dependencies to hardware ...................................................................................... 45 
14 Safety Manual MemIf ..................................................................................................... 46 
14.1 Safety features ........................................................................................................ 46 
14.2 Configuration constraints ......................................................................................... 46 
14.3 Additional verification measures .............................................................................. 46 
14.4 Dependencies to other components ........................................................................ 46 
14.4.1 Safety features required from other components .............................................. 46 
14.4.2 Coexistence with other components ................................................................. 46 
14.5 Dependencies to hardware ...................................................................................... 46 
15 Safety Manual Nm ......................................................................................................... 47 
15.1 Safety features ........................................................................................................ 47 
15.2 Configuration constraints ......................................................................................... 47 
15.3 Additional Verification measures .............................................................................. 47 
15.4 Dependencies to other components ........................................................................ 47 
15.4.1 Safety features required from other components .............................................. 47 
15.4.2 Coexistence with other components ................................................................. 47 
15.5 Dependencies to hardware ...................................................................................... 47 
16 Safety Manual NvM ....................................................................................................... 48 
16.1 Safety features ........................................................................................................ 48 
16.2 Configuration constraints ......................................................................................... 48 
16.3 Additional verification measures .............................................................................. 49 
16.4 Safety features required from other components ..................................................... 49 
16.5 Dependencies to hardware ...................................................................................... 49 
17 Safety Manual OS .......................................................................................................... 50 
17.1 Safety features ........................................................................................................ 50 
17.2 Configuration constraints ......................................................................................... 55 
2018 Vector Informatik GmbH 
1.0 
6 / 103 

---

Safety Manual CBD1601056 D05 
17.3 Additional verification measures .............................................................................. 56 
17.3.1 Interrupt handling ............................................................................................. 56 
17.3.2 Memory mapping and linking ........................................................................... 60 
17.3.3 Stack ................................................................................................................ 61 
17.3.4 Multicore systems with mixed diagnostic coverage capability ........................... 62 
17.3.5 (Non-)Trusted Functions .................................................................................. 63 
17.3.6 Miscellaneous .................................................................................................. 63 
17.3.7 Tracing ............................................................................................................. 65 
17.4 Safety features required from other components ..................................................... 65 
17.5 Dependencies to hardware ...................................................................................... 66 
18 Safety Manual OS (RH850) ........................................................................................... 67 
18.1 Safety features ........................................................................................................ 67 
18.2 Configuration constraints ......................................................................................... 67 
18.3 Additional verification measures .............................................................................. 67 
18.4 Safety features required from other components ..................................................... 68 
18.5 Dependencies to hardware ...................................................................................... 68 
19 Safety Manual PduR ...................................................................................................... 69 
19.1 Safety features ........................................................................................................ 69 
19.2 Configuration constraints ......................................................................................... 69 
19.3 Additional verification measures .............................................................................. 69 
19.4 Safety features required from other components ..................................................... 69 
19.5 Dependencies to hardware ...................................................................................... 69 
20 Safety Manual Rte ......................................................................................................... 70 
20.1 Safety features ........................................................................................................ 70 
20.2 Configuration constraints ......................................................................................... 72 
20.3 Additional verification measures .............................................................................. 72 
20.3.1 Guided integration testing ................................................................................ 73 
20.3.1.1 BSW configuration .................................................................................... 73 
2018 Vector Informatik GmbH 
1.0 
7 / 103 

---

Safety Manual CBD1601056 D05 
20.3.1.2 Executable Entity Scheduling ................................................................... 74 
20.3.1.3 SWC Communication ............................................................................... 76 
20.3.1.4 Usage of RTE Headers ............................................................................. 78 
20.3.1.5 Usage of RTE APIs ................................................................................... 79 
20.3.1.6 Configuration of RTE APIs ........................................................................ 80 
20.4 Safety features required from other components ..................................................... 82 
20.5 Dependencies to hardware ...................................................................................... 83 
21 Safety Manual WdgIf ..................................................................................................... 84 
21.1 Safety features ........................................................................................................ 84 
21.2 Configuration constraints ......................................................................................... 84 
21.3 Additional verification measures .............................................................................. 84 
21.4 Safety features required from other components ..................................................... 88 
21.5 Dependencies to hardware ...................................................................................... 89 
22 Safety Manual WdgM .................................................................................................... 90 
22.1 Safety features ........................................................................................................ 90 
22.2 Configuration constraints ......................................................................................... 90 
22.3 Additional verification measures .............................................................................. 91 
22.3.1 Additional verification using WdgM Verifier ....................................................... 92 
22.3.2 Additional verification of generator execution ................................................... 95 
22.4 Safety features required from other components ..................................................... 98 
22.5 Dependencies to hardware ...................................................................................... 98 
23 Safety Manual XCP........................................................................................................ 99 
23.1 Safety features ........................................................................................................ 99 
23.2 Configuration constraints ......................................................................................... 99 
23.3 Additional verification measures ............................................................................ 100 
23.4 Safety features required from other components ................................................... 100 
23.5 Dependencies to hardware .................................................................................... 100 
24 Glossary and Abbreviations ....................................................................................... 101 
2018 Vector Informatik GmbH 
1.0 
8 / 103 

---

Safety Manual CBD1601056 D05 
24.1 Glossary ................................................................................................................ 101 
24.2 Abbreviations ......................................................................................................... 101 
25 Contact ........................................................................................................................ 103 
 
  
 
2018 Vector Informatik GmbH 
1.0 
9 / 103 

---

Safety Manual CBD1601056 D05 
Safety Manual 
Version  Date 
Author 
Remarks 
1.00.00  2015-11-
Jonas Wolf 
Initial creation 
13 
1.01.00  2015-12-
Jonas Wolf 
Information about ASIL added. 
18 
1.02.00  2016-01-
Jonas Wolf 
Improvements in formulation. 
29 
1.03.00  2016-02-
Jonas Wolf 
Improvements in formulation. 
25 
1.03.01  2016-03-
Jonas Wolf 
Review findings incorporated. 
30 
1.03.02  2016-05-
Jonas Wolf 
Added hint on hardware-software integration (SMI-4). 
13 
1.03.03  2016-07-
Hartmut 
Added SMI related to interrupt handling. 
20 
Hoerner 
1.04.00  2016-09-
Jonas Wolf 
Added TSR-101876 for data consistency. 
02 
1.04.01  2016-09-
Jonas Wolf 
Clarifications on SMI-100 and SMI-19. 
19 
1.04.02  2016-12-
Jonas Wolf 
Version of referenced document fixed. 
02 
1.05.00  2017-02-
Jonas Wolf 
Modified SMI-18: checks need to be enabled per 
24 
component as well. 
 
2018 Vector Informatik GmbH 
1.0 
10 / 103 

---

Safety Manual CBD1601056 D05 
1 General Part 
1.1 Introduction 
1.1.1 Purpose 
This document describes the assumptions made by Vector during the development of 
MICROSAR Safe as Software Safety Element out of Context (SEooC). This document 
provides information on how to integrate MICROSAR Safe into your safety-related project. 
This document is intended for the user of MICROSAR Safe. It shall be read by project 
managers, safety managers, and engineers to allow proper integration of MICROSAR 
Safe. 
1.1.2 Scope 
This document adds additional information to the components that are marked with an 
ASIL in the delivery description provided by Vector. Neither QM Vector components, nor 
components by other vendors are in the scope of this document. 
Vector assumes that hardware and compiler manuals are correct and complete. 
Vector uses the hardware reference manuals and compiler manuals for the development 
of MICROSAR Safe. Vector has no means to verify correctness or completeness of the 
hardware and compiler manuals. 
Example information that may be critical from these manuals is the register assignment by 
compiler. This information is used to built up the context that is saved and restored by the 
operating system. 
The compiler manual from the compiler version specified for the project is considered. The 
considered hardware manuals are documented in the Technical Reference of the 
hardware-specific component. 
A general description of Vector's approach to ISO 26262 is described in [2]. This document 
is available on request. 
1.1.3 Definitions 
The words shall, shall not, should, can in this document are to be interpreted as described 
here: 
1.  Shall means that the definition is an absolute requirement of the specification. 
2.  Shall not means that the definition is an absolute prohibition of the specification. 
3.  Should means that there may exist valid reasons in particular circumstances to ignore 
a particular definition, but the full implications must be understood and carefully 
weighed before choosing a different course. 
4.  Can means that a definition is truly optional.  
2018 Vector Informatik GmbH 
1.0 
11 / 103 

---

Safety Manual CBD1601056 D05 
The user of MICROSAR Safe can deviate from all constraints and requirements in this 
Safety Manual in the responsibility of the user of MICROSAR Safe, if equivalent measures 
are used. 
If a measure is equivalent can be decided in the responsibility of the user of MICROSAR 
Safe. 
1.1.4 References 
No.  Source 
Title 
Version 
[1] 
ISO 
ISO 26262 Road vehicles — Functional safety (all parts) 
2011/2012 
[2] 
Vector 
ISO 26262 Compliance Document 
1.2.1 
[3] 
Vector 
MICROSAR Safe Product Information 
1.4.0 
[4] 
Vector 
MICROSAR Safe Silence Verifier Technical Reference 
1.4 
 
1.1.5 Overview 
This document is automatically generated. The content of this document depends on the 
components and microcontroller of your delivery. This document is thus valid only for the 
delivery from Vector that it is included in. 
The structure of this document comprises: 
o  a general section that covers all assumptions and constraints that are always 
applicable, and 
o  a microcontroller specific section that covers all aspects of the selected 
microcontroller (only if microcontroller specific components are part of the delivery), 
and 
o  a section for each component that covers its constraints and necessary verification 
steps. 
Vector's assumptions on the environment of the MICROSAR Safe components as well as 
the integration process are described. 
Vector developed MICROSAR Safe as Safety Element out of Context for projects 
demanding ASIL D software. All requirements in this document apply independently from 
the actual highest ASIL of the project.  
1.2 Concept 
MICROSAR Safe comprises a set of components developed according to ISO 26262. 
These components can be combined - together with other measures - to build a safe 
system according to ISO 26262. 
Please read the Product Information MICROSAR Safe [3] first. 
2018 Vector Informatik GmbH 
1.0 
12 / 103 

---

Safety Manual CBD1601056 D05 
1.2.1 Technical Safety Requirements 
These are the assumed technical safety requirements on the Safety Element out of 
Context MICROSAR Safe. These requirements are expected to match the requirements in 
the actual item development. 
All technical safety requirements are assigned an ASIL D to service as many projects as 
possible. 
No fault tolerant time intervals are given. Timing depends on the used hardware and its 
configuration. It is assumed that the user configures MICROSAR Safe adequately for the 
intended use. 
No safe state is defined since MICROSAR Safe allows the user to define the desired 
behavior in case of a detected fault. 
1.2.1.1 Initialization 
TSR-1 The system shall initialize the CPU, MPU, watchdog, and operating system.  
Rationale: Initialization of the hardware, e.g. clocks, memory protection, scheduling etc. is 
necessary to enable the other safety requirements. 
MICROSAR Safe Feature: The ECU State Manager (EcuM) is responsible for performing 
the configured driver initialization. After initialization the EcuM starts the operating system. 
The EcuM distributes the post-built loadable configuration information within the ECU. 
The documentation of the operating system describes which parts of the CPU it initializes. 
The startup code and main function is in the responsibility of the user of MICROSAR Safe. 
1.2.1.2 Self-test 
TSR-2 The system shall perform self-tests based on the requirements of the system.  
Rationale: It may be necessary to periodically test individual components of the system to 
detect latent faults. 
MICROSAR Safe Feature :The operating system provides a function to self-test the 
effectiveness of the MPU settings. 
The ECU State Manager services callouts to user code that can check RAM consistency 
after wakeup. 
Other hardware self-tests are usually performed by MCAL components not developed by 
Vector. 
End-to-end protection of communication provides its own fault detection mechanisms. 
1.2.1.3 Reset of ECU 
TSR-3 The system shall reset itself in case of a detected fault.  
Rationale: Resetting the CPU of the ECU is in most cases an appropriate measure to 
achieve a safe state. 
It is assumed that the reset state of a microcontroller leads to the safe state of the ECU 
and system, since a reset may occur at any time due to e.g. EMC. 
MICROSAR Safe Feature: MICROSAR Safe does not reset the ECU on its own (there 
may be exceptions for the operating system). 
2018 Vector Informatik GmbH 
1.0 
13 / 103 

---

Safety Manual CBD1601056 D05 
Functionality from ECU State Manager (setting the shutdown target) can be used to reset 
the ECU instead, if this is the intended fault reaction. 
1.2.1.4 Data consistency 
TSR-101876 The system shall provide functions to ensure data consistency.  
Rationale: Concurrent access, e.g. from task or interrupt level, must not lead to data 
inconsistencies. 
MICROSAR Safe Feature: MICROSAR Safe provides functions to enable or disable 
interrupts, spin-locks, resources or abstractions (i.e. exclusive areas) to enable the user of 
MICROSAR Safe to ensure data consistency. This functionality is also used within 
MICROSAR Safe to ensure data consistency. 
1.2.1.5 Non-volatile memory 
The system must be designed in a way that in case of the absence of non‑volatile data it 
is still safe (e.g. safe state or degradation). 
It cannot be assured that data is saved completely or at all because a reset or loss of 
energy might happen at any time, e.g. brown-out, black-out. 
This also implies that it is in general impossible to guarantee that the latest information is 
available in the non-volatile memory, e.g. the system is reset before memory stack is even 
notified to write data to non-volatile memory. 
Thus, safety-related functionality may not rely on the availability of data in non-volatile 
memory. 
Since the availability of data in non-volatile memory cannot be guaranteed in any case, the 
only sensible use-case is reading safety-related calibration data. 
Writing of data into non-volatile memory must be verified to assure that the information is 
available in non-volatile memory. Verification can only be done manually in a protected 
environment, e.g. at end of line, in a workshop, etc.  
ECU software cannot verify if data was written, since at any time a reset could occur and 
the information that had to be written is lost immediately. 
Reading of data does not modify data stored in non-volatile memory. Thus, reading can be 
used by safety-related functionality. The memory stack has to assure that the read data is 
identical to the data stored in non-volatile memory. 
The absence of data still has to be handled by the application. 
The availability may be increased by e.g. redundant storage. 
1.2.1.5.1 Saving data 
TSR-4 The system shall save information in non-volatile memory.  
Rationale: see text above. 
MICROSAR Safe Feature: The intended block is written with the information provided by 
the application. 
1.2.1.5.2 Loading data 
TSR-5 The system shall retrieve the last stored information from non-volatile 
memory.  
Rationale: see text in above. 
MICROSAR Safe Feature: The intended block is read and the information is provided to 
2018 Vector Informatik GmbH 
1.0 
14 / 103 

---

Safety Manual CBD1601056 D05 
the application. 
The last or any previous completely stored block in non-volatile memory is returned by 
memory stack. 
If CRC or ECC protections do not match block data an error is returned. 
If data is stored redundantly, the redundant information is returned. 
If no completely stored block is found, an error is returned. 
1.2.1.6 Scheduling 
1.2.1.6.1 Deterministic, hard real-time scheduling 
TSR-6 The system shall execute the specified functions within their respective hard 
timing limits.  
Rationale: Hard real-time scheduling may be used for scheduling safety mechanisms 
implemented in software. 
This requirement is even more important for fail-operational systems, where one function 
may have to work, while another blocks the processor. 
MICROSAR Safe Feature: The immediate priority ceiling protocol specified by AUTOSAR 
is capable of performing this task. The schedule tables specified by AUTOSAR may also 
be used on top of the scheduling algorithm. 
The operating system of MICROSAR Safe implements the scheduling algorithm according 
to the methods for ASIL D required by ISO 26262. 
1.2.1.7 Partitioning 
1.2.1.7.1 Memory partitioning 
TSR-7 The system shall protect software applications from unspecified memory 
access.  
Rationale: Partitioning in software is often introduced because of different quality levels of 
software and different responsibilities of software development on one ECU. 
Memory partitioning relies on the available MPU in hardware for the effectiveness of the 
mechanism. 
MICROSAR Safe Feature: Memory partitioning and context switching using AUTOSAR 
Operating Feature System SC3 mechanisms is implemented according to the methods for 
ASIL D required by ISO 26262. 
Adequate configuration of the memory partitions is in the responsibility of the user of 
MICROSAR Safe. 
1.2.1.7.2 Time partitioning 
1.2.1.7.2.1 Timing protection 
TSR-8 The system shall detect timing faults in the software.  
Rationale: Relying on a watchdog for timing protection is sometimes not sufficiently robust 
or efficient. 
MICROSAR Safe Feature: The operating system of MICROSAR Safe implements the 
timing protection functionality of SC4 according to the methods for ASIL D required by ISO 
26262. 
2018 Vector Informatik GmbH 
1.0 
15 / 103 

---

Safety Manual CBD1601056 D05 
1.2.1.7.2.2 Killing of applications 
TSR-9 The system shall terminate software applications.  
Rationale: In combination with the timing protection this allows the software to continue 
operation in case of a software fault. 
MICROSAR Safe Feature: The operating system of MICROSAR Safe implements the 
termination of applications according to the methods for ASIL D required by ISO 26262. 
1.2.1.8 Communication protection 
1.2.1.8.1 Inter ECU communication 
1.2.1.8.1.1 End-to-end protection 
TSR-10 The system shall protect communication between its elements.  
Rationale: Communication has to be protected against corruption, unintended replay and 
masquerading. The loss of a message must be detected. 
This can be achieved using the end-to-end (E2E) protection 
mechanism defined by AUTOSAR. 
MICROSAR Safe Feature: MICROSAR Safe implements the E2E functionality according 
to 
ISO 26262. This also includes the CRC library functionality. 
1.2.1.8.1.2 Protection by cryptographic algorithms 
TSR-11 The system shall protect communication between its elements using 
cryptographic hash algorithms to detect accidental corruption of the 
communication.  
Rationale: Cyclic redundancy codes (CRC) provide a specified hamming distance given a 
polynomial and data block size. 
Cryptographic hash functions provide a probabilistic statement on data corruption 
detection depending on the hash function, data block size and hash value size. 
MICROSAR Safe Feature: The Cryptographic Service Manager of MICROSAR Safe is 
implemented according to the methods for ASIL D required by ISO 26262. 
The Cryptographic Service Manager services the main function and functions to calculate 
a cryptographic hash function according to AUTOSAR specification. 
1.2.1.8.2 Intra ECU communication 
1.2.1.8.2.1 Intra OS application communication 
TSR-16 The microcontroller software shall communicate within its applications.  
Rationale: Software components need to communicate. 
Protection of the memory against random hardware faults is expected by the system (e.g. 
via ECC RAM and lock-step mode). 
MICROSAR Safe Feature: The RTE provides services to allow communication of software 
components within OS applications (intra-partition communication). 
1.2.1.8.2.2 Inter OS application communication 
TSR-12 The microcontroller software shall communicate between its applications.  
Rationale: Multi-core systems may need to exchange safety-related information between 
2018 Vector Informatik GmbH 
1.0 
16 / 103 

---

Safety Manual CBD1601056 D05 
applications. 
Protection of the memory against random hardware faults is expected by the system (e.g. 
via ECC RAM and lock-step mode). 
MICROSAR Safe Feature: The operating system of MICROSAR Safe implements the 
inter-OS application (IOS) functionality according to the methods for ASIL D required by 
ISO 26262. 
The RTE provides services to allow communication between OS applications (inter-
partition communication). 
1.2.1.9 Watchdog services 
1.2.1.9.1 Program flow monitoring 
TSR-13 The system shall provide a mechanism to detect faults in program flow.  
Rationale. Program flow can be corrupted by random hardware faults or software faults. 
MICROSAR Safe Feature: MICROSAR Safe watchdog stack implements program flow 
monitoring functionality according to the methods for ASIL D required by ISO 26262. 
1.2.1.9.2 Alive monitoring 
TSR-14 The system shall provide a mechanism to detect stuck software.  
Rationale: Alive monitoring is used to reset the software or controller in case it is 
unresponsive. 
MICROSAR Safe Feature: MICROSAR Safe watchdog stack implements alive monitoring 
functionality according to the methods for ASIL D required by ISO 26262. 
1.2.1.9.3 Deadline monitoring 
TSR-15 The system shall provide a mechanism to detect deadline violations.  
Rationale: Deadline monitoring using the watchdog stack can be used to implement timing 
monitoring. 
MICROSAR Safe Feature: MICROSAR Safe watchdog stack implements deadline 
monitoring functionality according to the methods for ASIL D required by ISO 26262. 
1.2.1.10 Peripheral in- and output 
1.2.1.10.1 Peripheral input 
TSR-17 The system shall read input values from peripheral devices.  
Rationale: In- and output is the most common use case for safety mechanisms. 
Some MCAL manufacturers call this feature safe acquisition. 
MICROSAR Safe Feature: MCAL components used for peripheral access are usually not 
developed by Vector. DIO and SPI drivers provided by Vector support the input as safety 
feature. 
1.2.1.10.2 Peripheral output 
TSR-18 The system shall write output values to peripheral devices.  
Rationale: In- and output is the most common use case for safety mechanisms. 
Some MCAL manufacturers call this feature safe actuation. 
MICROSAR Safe Feature: MCAL components used for peripheral access are usually not 
2018 Vector Informatik GmbH 
1.0 
17 / 103 

---

Safety Manual CBD1601056 D05 
developed by Vector. DIO and SPI drivers provided by Vector support the output as safety 
feature (to trigger external watchdogs or switch actuation paths). 
1.2.2 Environment 
1.2.2.1 Safety Concept 
SMI-14 
The user of MICROSAR Safe shall be responsible for the functional safety concept. 
The overall functional safety concept is in the responsibility of the user of MICROSAR 
Safe. MICROSAR Safe can only provide parts that can be used to implement the 
functional safety concept of the item. 
It is also the responsibility of the user of MICROSAR Safe to configure MICROSAR Safe 
as intended by the user's safety concept.  
The safety concept shall only rely on safety features explicitly described in this safety 
manual. If a component from MICROSAR Safe does not explicitly describe safety features 
in this safety manual, this component has been developed according to the methods for 
ASIL D to provide coexistence with other ASIL components.  
o  Example: NvM provides safety features for writing and reading of data, the lower 
layers, i.e. MemIf, Ea, Fee and drivers, only provide the ASIL for coexistence. 
The safety concept shall not rely on functionality that is not explicitly described as safety 
feature in this safety manual. This functionality may fail silently in case of a detected fault.  
o  Example: If a potential out-of-bounds memory access, e.g. due to invalid input or 
misconfiguration, is detected the requested function will not be performed. An error 
via DET is only reported if error reporting is enabled. 
SMI-1 
The user of MICROSAR Safe shall adequately address hardware faults. 
The components of MICROSAR Safe can support in the detection and handling of some 
hardware faults (e.g. using watchdog). 
MICROSAR Safe does not provide redundant data storage. 
The user of MICROSAR Safe especially has to address faults in volatile random access 
memory, non-volatile memory, e.g. flash or EEPROM, and the CPU. 
MICROSAR Safe relies on the adequate detection of faults in memory and the CPU by 
other means, e.g. hardware. Thus, Vector recommends using lock-step CPUs together 
with ECC memory. 
See also SMI-14. 
SMI-10 
The user of MICROSAR Safe shall ensure that the reset or powerless state is a safe 
state of the system. 
This assumption is added to this Safety Manual, because it is used in Vector's safety 
analyses and development process. 
SMI-20 
2018 Vector Informatik GmbH 
1.0 
18 / 103 

---

Safety Manual CBD1601056 D05 
The user of MICROSAR Safe shall implement a timing monitoring using e.g. a 
watchdog. 
The components of MICROSAR Safe do not provide mechanisms to monitor their own 
timing behavior. 
The watchdog stack that is part of MICROSAR Safe can be used to fulfill this assumption. 
If the functional safety concept also requires a logic monitoring, The watchdog stack that is 
part of MICROSAR Safe can be used to implement it. 
The watchdog is one way to perform timing monitoring. Today the watchdog is the most 
common approach. In future there may be different approaches e.g. by monitoring using a 
different ECU. 
See also SMI-14. 
SMI-98 
The user of MICROSAR Safe shall ensure an end-to-end protection for safety-related 
communication between ECUs. 
The communication components of MICROSAR Safe do not assume sending or receiving 
as a safety requirement, because considered faults can only be detected using additional 
information like a cycle counter. Vector always assumes that an end-to-end protection or 
equivalent mechanism is implemented on application level. 
Considered faults in communication are: 
o  Failure of communication peer  
o  Message masquerading  
o  Message corruption 
o  Unintended message repetition  
o  Insertion of messages  
o  Re-sequencing  
o  Message loss  
o  Message delay 
This requirement can be fulfilled by e.g. using the end-to-end protection wrapper for safety 
related communication. 
SMI-11 
The user of MICROSAR Safe shall ensure data consistency for its application. 
Data consistency is not automatically provided when using MICROSAR Safe. MICROSAR 
Safe only provides services to support enforcement of data consistency. Their application 
is in the responsibility of the user of MICROSAR Safe. 
To ensure data consistency in an application, critical sections need to be identified and 
protected. 
To identify critical sections in the code, e.g. review or static code analysis can be used. 
2018 Vector Informatik GmbH 
1.0 
19 / 103 

---

Safety Manual CBD1601056 D05 
To protect critical sections, e.g. the services to disable and enable interrupts provided by 
the MICROSAR Safe operating system can be used. 
To verify correctly implemented protection, e.g. stress testing or review can be used. 
Note the AUTOSAR specification with respect to nesting and sequence of calls to interrupt 
enabling and disabling functions. 
See also TSR-101876. 
1.2.2.2 Use of MICROSAR Safe Components 
SMI-2 
The user of MICROSAR Safe shall adequately select the type definitions to reflect 
the hardware platform and compiler environment. 
The user of MICROSAR Safe is responsible for selecting the correct platform types 
(PlatformTypes.h) and compiler abstraction (Compiler.h). Especially the size of the 
predefined types must match the target environment. 
Example: A uint32 must be mapped to an unsigned integer type with a size of 32 bits. 
The user of MICROSAR Safe can use the platform types provided by Vector. Vector has 
created and verified the platform types mapping according to the information provided by 
the user of MICROSAR Safe. 
SMI-12 
The user of MICROSAR Safe shall initialize all components of MICROSAR Safe prior 
to using them. 
This constraint is required by AUTOSAR anyway. It is added to this Safety Manual, 
because Vector assumes initialized components in its safety analyses and development 
process. 
Correct initialization can be verified, e.g. during integration testing. 
SMI-16 
The user of MICROSAR Safe shall only pass valid pointers at all interfaces to 
MICROSAR Safe components. 
Plausibility checks on pointers are performed by MICROSAR Safe (see also SMI-18), but 
they are limited. MICROSAR Safe components potentially use provided pointers to write to 
the location in memory. 
Also the length and pointer of a buffer provided to a MICROSAR Safe component need to 
be consistent. 
This assumption also applies to QM as well as ASIL components. 
This can e.g. be verified using static code analysis tools, reviews and integration testing. 
SMI-18 
The user of MICROSAR Safe shall enable plausibility checks for the MICROSAR 
Safe components. 
This setting is necessary to introduce defensive programming and increase robustness at 
the interfaces as required by ISO 26262. 
This setting has to be configured at /MICROSAR/EcuC/EcucGeneral/EcuCSafeBswChecks and 
<Component-specific path>/<Ma>SafeBswChecks for all components that are intended to 
2018 Vector Informatik GmbH 
1.0 
20 / 103 

---

Safety Manual CBD1601056 D05 
be ASIL. 
Ma is the Module Abbreviation. 
This setting is enforced by an MSSV plug-in. 
This setting does not enable error reporting to the DET component. 
SMI-1725 
The user of MICROSAR Safe shall configure and use the interrupt system correctly. 
The user of MICROSAR Safe is responsible for a correct and consistent configuration and 
usage of the interrupt system. 
Especially the following topics shall be verified: 
o  Consistent configuration of interrupt category, level and priority in OS and MCAL 
modules 
o  Correct assignment of logical channels/instances to interrupt vectors in case of 
MCAL modules with multiple channels/instances 
o  The interrupt controller is configured in a mode which processes interrupts of the 
same level sequentially to avoid unbounded interrupt nesting 
1.2.2.3 Partitioning 
SMI-9 
The user of MICROSAR Safe shall ensure that for one AUTOSAR functional cluster 
(e.g. System Services, Operating System, CAN, COM, etc.) only components from 
Vector are used. 
This assumption is required because of dependencies within the development process of 
Vector. 
This assumption does not apply to the MCAL or the EXT cluster. 
Vector may have requirements on MCAL or EXT components depending on the upper 
layers that are used and provided by Vector. For example, the watchdog driver is 
considered to have safety requirements allocated to its initialization and triggering 
services. Details are described in the component specific parts of this safety manual. 
This assumption does not apply to components that are not provided by Vector. 
In case the partitioning solution is used, this assumption only partially applies to the 
System Services cluster. Only the Watchdog Manager and Watchdog Interface need to be 
used from Vector then, because the Watchdog Manager and Watchdog Interface will be 
placed in separate memory partitions apart from the other System Services components. 
SMI-32 
The user of MICROSAR Safe shall provide an argument for coexistence for software 
that resides in the same partition as components from MICROSAR Safe. 
Vector considers an ISO 26262-compliant development process for the software as an 
argument for coexistence (see [1] Part 9 Clause 6). Vector assumes that especially 
freedom from interference with respect to memory is provided by an ISO 26262-compliant 
development process. 
Redundant data storage as the only measure by the other software is not considered a 
2018 Vector Informatik GmbH 
1.0 
21 / 103 

---

Safety Manual CBD1601056 D05 
sufficient measure. 
If ASIL components provided by Vector are used, this requirement is fulfilled. 
In general Vector components do not implement methods to interface with other software 
(e.g. components, hooks, callouts) in other partitions. They assume that all interfacing 
components reside in the same partition. Interfacing components are described in the 
respective technical reference. 
If an argument for coexistence cannot be provided, other means of separation have to be 
implemented (e.g. trusted or non-trusted function calls). 
SMI-99 
The user of MICROSAR Safe shall verify that the memory mapping is consistent 
with the partitioning concept.  
The volatile data of every component shall be placed in the associated memory partition. 
This can be verified e.g. by review of the linker map file. 
The memory sections for each component placed in RAM can be identified 
<MIP>_START_SEC_VAR[_<xxx>], where <MIP> is the Module Implementation Prefix of 
the component. 
1.2.2.4 Resources 
SMI-33 
The user of MICROSAR Safe shall provide sufficient resources in RAM, ROM, stack 
and CPU runtime for MICROSAR Safe. 
Selection of the microcontroller and memory capacities as well as dimensioning of the 
stacks is in the responsibility of the user of MICROSAR Safe. 
If MICROSAR Safe components have specific requirements, these are documented in the 
respective Technical Reference document. 
1.2.3 Process 
SMI-15 
The user of MICROSAR Safe shall follow the instructions of the corresponding 
Technical Reference of the components. 
Especially deviations from AUTOSAR specifications are described in the Technical 
References. 
If there are constraints for the implementation of an exclusive area, these are described in 
the Technical References. 
SMI-5 
The user of MICROSAR Safe shall verify all code that is modified during integration 
of MICROSAR Safe. 
Code that is typically modified by the user of MICROSAR Safe during integration 
comprises generated templates, hooks, callouts, or similar. 
This assumption also applies if interfaces between components are looped through user-
defined functions. 
Vector assumes that this verification also covers ISO 26262:6-9. Vector assumes that 
modified code that belongs to a Vector component, e.g. EcuM callouts or OS trace hooks 
2018 Vector Informatik GmbH 
1.0 
22 / 103 

---

Safety Manual CBD1601056 D05 
can at least coexist with this component, because no separation in memory or time is 
implemented. 
Example: Callouts of the EcuM are executed in the context of the EcuM. 
Non-trusted functions provided by the Vector operating system can be used to implement 
a separation in memory in code modified by the user of MICROSAR Safe. 
Support by Vector can be requested on a per-project basis. 
SMI-30 
The user of MICROSAR Safe shall only modify source code of MICRSAR Safe that is 
explicitly allowed to be changed. 
Usually no source code of MICROSAR Safe is allowed to be changed by the user of 
MICROSAR Safe. 
The user of MICROSAR Safe can check if the source code was modified by e.g, 
comparing it to the original delivery.  
SMI-8 
The user of MICROSAR Safe shall verify generated functions according to ISO 
26262:6-9. 
Generated functions can be identified when searching through the generated code. 
Support by Vector can be requested on a per-project basis. 
An example of generated functions is the configured rules of the Basic Software Manager 
(BSWM). Their correctness can only be verified by the user of MICROSAR Safe. Please 
note, however, that BSWM does not provide safety features. 
This requirement does not apply to MICROSAR SafeRTE. 
SMI-19 
The user of MICROSAR Safe shall execute the MICROSAR Safe Silence Verifier 
(MSSV). 
MSSV is used to detect potential out-of-bounds accesses by Vector's basic software based 
on inconsistent configuration. 
Details on the required command line arguments and integration into the tool chain can be 
found in [4]. 
If the report shows “Overall Check Result: Fail", please contact the Safety Manager at 
Vector. See the Product Information MICROSAR Safe for contact details. 
SMI-4 
The user of MICROSAR Safe shall perform the integration (ISO 26262:6-10) and 
verification (ISO 26262:6-11) processes as required by ISO 26262. 
Especially the safety mechanisms must be verified in the final target ECU. 
Vector assumes that by performing the integration and verification processes as required 
by ISO 26262 the generated configuration data, e.g. data tables, task priorities or PDU 
handles, are sufficiently checked. An additional review of the configuration data is then 
considered not necessary. 
Integration does not apply to a MICROSAR Safe component that consists of several 
subcomponents. This integration is already performed by Vector. The integration of 
subcomponents is validated during creation of the safety case by Vector based on the 
2018 Vector Informatik GmbH 
1.0 
23 / 103 

---

Safety Manual CBD1601056 D05 
configuration handed in by the user of MICROSAR Safe. 
However, integration of all MICROSAR Safe components in the specific use-case of the 
user of MICROSAR Safe is the responsibility of the user of MICROSAR Safe. This also 
includes the hardware-software integration in the context of the target ECU. 
Support by Vector can be requested on a per-project basis. 
SMI-100 
The user of MICROSAR Safe shall ensure that a consistent set of generated 
configuration is used for verification and production.  
Make sure that the same generated files are used for testing and production code, i.e. be 
aware that configuration can be changed without generating the code again. 
Make sure that all generated files have the same configuration basis, i.e. always generate 
the MICROSAR Safe configuration for all components for a relevant release of the ECU 
software. 
The use of post build loadable is supported but not recommended by Vector. 
SMI-176 
The user of MICROSAR Safe shall verify the integrity of the delivery by Vector.  
Run the SIPModificationChecker.exe and verify that the source code, BSWMD and safety 
manual files are unchanged. 
SMI-31 
The user of MICROSAR Safe shall verify the consistency of the binary downloaded 
into the ECU's flash memory. 
This also includes re-programming of flash memory via a diagnostics service. The 
consistency of the downloaded binary can be checked by the bootloader or the application. 
MICROSAR Safe assumes a correct program image.  
SMI-3 
The user of MICROSAR Safe shall evaluate all tools (incl. compiler) that are used by 
the user of MICROSAR Safe according to ISO 26262:8-11. 
Evaluation especially has to be performed for the compiler, linker, debugging and test 
tools. 
Vector provides a guideline for the evaluation of the Tool Confidence Level (TCL) for the 
tools provided by Vector (e.g. DaVinci Configurator). 
Vector has evaluated the tools exclusively used by Vector during the development of 
MICROSAR Safe. 
2018 Vector Informatik GmbH 
1.0 
24 / 103 

---

Safety Manual CBD1601056 D05 
2 Safety Manual BswM 
2.1 Safety features 
This component does not provide safety features. 
2.2 Configuration constraints 
SMI-3528 
The user of MICROSAR Safe shall configure the following attribute: 
o  Set /MICROSAR/BswM/BswMGeneral/BswMEthIfEnabled to FALSE. 
This setting is enforced by an MSSV plugin. 
SMI-3529 
The user of MICROSAR Safe shall assert the following preprocessor define: 
o  BSWM_CC_POWER_SOURCES is not defined in BswM_Cfg.h. 
This setting is enforced by an MSSV plugin. 
2.3 Additional Verification measures 
This component does not require additional verification measures. 
2.4 Safety features required from other components 
This component does not require safety features from other components. 
2.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
25 / 103 

---

Safety Manual CBD1601056 D05 
3 Safety Manual CanIf 
3.1 Safety features 
This component does not provide safety features. 
3.2 Configuration constraints 
SMI-348 
The user of MICROSAR Safe shall configure the following attributes: 
o  Set /MICROSAR/CanIf/CanIfPrivateCfg/CanIfOptimizeOneController to FALSE. 
o  Set /MICROSAR/CanIf/CanIfPublicCfg/CanIfJ1939DynAddrSupport to DISABLED. 
These settings are enforced by a MSSV plugin. 
3.3 Additional verification measures 
SMI-349 
The user of MICROSAR Safe shall verify for each entry of table 
CanIf_RxIndicationFctList that the signature of the function referred by member 
RxIndicationFct matches the expected signature that is selected the value of the member 
RxIndicationLayout. 
The table CanIf_RxIndicationFctList can be found in CanIf_Lcfg.c. 
The following table lists the expected signatures. The placeholder <name> represents the 
function's name: 
Value of RxIndicationLayout 
Signature of the function referred by 
RxIndicationFct  
CanIf_SimpleRxIndicationLayout 
void <name>(PduIdType CanRxPduId, const 
uint8* CanSduPtr) 
CanIf_AdvancedRxIndicationLayout  void <name>(PduIdType CanRxPduId, const 
PduInfoType* PduInfoPtr) 
CanIf_NmOsekRxIndicationLayout 
void <name>(PduIdType CanRxPduId, const 
uint8* CanSduPtr, Can_IdType CanId) 
 
SMI-350 
The user of MICROSAR Safe shall verify for each entry of table 
CanIf_TxConfirmationFctList that function referred by member TxConfirmationFctList 
has the following signature (the placeholder <name> represents the function's name): 
void <name>(PduIdType CanTxPduId) 
The table CanIf_TxConfirmationList can be found in CanIf_Lcfg.c. 
2018 Vector Informatik GmbH 
1.0 
26 / 103 

---

Safety Manual CBD1601056 D05 
SMI-746 
The user of MICROSAR Safe shall verify for each callback function listed in the following 
table that the signature of the function matches the expected signature. 
All callback functions can be found in file CanIf_Lcfg.c. Please note that depending on 
configuration you must verify only the provided ones. 
Callback function 
Expected signature of the function 
CanIf_BusOffNotificationFctPtr 
void <name> (uint8 
ControllerId) 
CanIf_CtrlModeIndicationFctPtr 
void <name> (uint8 
ControllerId, 
CanIf_ControllerModeType 
ControllerMode) 
CanIf_TrcvModeIndicationFctPtr 
void <name> (uint8 
TransceiverId, 
CanTrcv_TrcvModeType 
TransceiverMode) 
CanIf_ConfirmPnAvailabilityFctPtr 
void <name> (uint8 
TransceiverId) 
CanIf_ClearTrcvWufFlagIndicationFctPtr 
void <name> (uint8 
TransceiverId) 
CanIf_CheckTrcvWakeFlagIndicationFctPtr 
void <name> (uint8 
TransceiverId) 
CanIf_WakeUpValidationFctPtr 
void <name> 
(EcuM_WakeupSourceType 
CanWakeupEvents) 
CanIf_RamCheckCorruptControllerIndFctPtr  void <name> (uint8 
ControllerId) 
CanIf_RamCheckCorruptMailboxIndFctPtr 
void <name> (uint8 
ControllerId, 
CanIf_HwHandleType HwHandle) 
CanIf_DataChecksumRxErrFctPtr 
void <name> (PduIdType 
CanIfRxPduId) 
 
SMI-25089 
The user of MICROSAR Safe shall ensure that any write access within the callout 
CanIf_TransmitSubDataChecksumTxAppend to the array referenced by parameter 
txPduDataWidthChecksumPtr is within its valid range. 
This measure is only applicable if attribute 
/MICROSAR/CanIf/CanIfPrivateCfg/CanIfDataChecksumTxSupport is configured to TRUE. 
The size of the array is defined by CANIF_CFG_MAXTXDLC_PLUS_DATACHECKSUM which can be 
found in file CanIf_Cfg.h. 
This requirement is fulfilled if the implementation of 
CanIf_TransmitSubDataChecksumTxAppend is provided by Vector. 
2018 Vector Informatik GmbH 
1.0 
27 / 103 

---

Safety Manual CBD1601056 D05 
3.4 Safety features required from other components 
This component does not require safety features from other components. 
3.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
28 / 103 

---

Safety Manual CBD1601056 D05 
4 Safety Manual CanNm 
4.1 Safety features 
This component does not provide safety features. 
4.2 Configuration constraints 
This component does not have configuration constraints. 
4.3 Additional verification measures 
SMI-326 
The user of MICROSAR Safe shall verify that the pointer (nmUserDataPtr) passed to the 
function CanNm_GetUserData references a valid memory location and that the size of the 
array referenced by parameter nmUserDataPtr is greater or equal to 
CanNm_GetRxMessageData_UserDataLengthOfPbChannelConfig(channel). 
This function is called by the application via the Nm_GetUserData function of the Nm. This 
interface only passes a pointer without a length. The length is statically configured in the 
CanNm for each channel. 
SMI-327 
The user of MICROSAR Safe shall verify that the pointer (nmPduDataPtr) passed to the 
function CanNm_GetPduData references a valid memory location and that the size of the 
array referenced by parameter nmPduDataPtr is greater or equal to 
CanNm_GetRxMessageDataLengthOfPbChannelConfig(channel). 
This function is called by the application via the Nm_GetPduData function of the Nm. This 
interface only passes a pointer without a length. The length is statically configured in the 
CanNm for each channel. 
4.4 Safety features required from other components 
This component does not require safety features from other components. 
4.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
29 / 103 

---

Safety Manual CBD1601056 D05 
5 Safety Manual CanSM 
5.1 Safety features 
This component does not provide safety features. 
5.2 Configuration constraints 
This component does not have configuration constraints. 
5.3 Additional verification measures 
SMI-389 
The user of MICROSAR Safe shall verify that only existing functions with the correct 
prototype are referred by the following function pointers. 
o  The following function pointer is generated only if the attribute 
/MICROSAR/CanSM/CanSMGeneral/CanSMBusOffBegin is configured to an non-
empty value: 
- CanSM_BusOffBeginIndicationFctPtr 
o  The following function pointer is generated only if 
/MICROSAR/CanSM/CanSMGeneral/CanSMBusOffEnd is configured to an non-
empty value: 
- CanSM_BusOffEndIndicationFctPtr 
o  The following function pointer is generated only if 
/MICROSAR/CanSM/CanSMGeneral/CanSMTxTimeoutEnd is configured to an 
non-empty value: 
- CanSM_TxTimeoutExceptionEndIndicationFctPtr 
The function pointers shall especially not contain NULL pointers nor numeric values of 
memory addresses. 
All function pointers can be found in CanSM_Lcfg.c. The function prototypes can be found 
in CanSM_Cfg.h. 
5.4 Safety features required from other components 
This component does not require safety features from other components. 
5.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
30 / 103 

---

Safety Manual CBD1601056 D05 
6 Safety Manual CanTp 
6.1 Safety features 
This component does not provide safety features. 
6.2 Configuration constraints 
SMI-2119 
The user of MICROSAR Safe shall configure the following: 
o  Set /MICROSAR/CanTp/CanTpGeneral/CanTpOptimizeSingleRxBuffer to FALSE. 
o  At least one /MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu 
container 
o  At least one /MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu 
container 
These settings are enforced by an MSSV plugin. 
6.3 Additional verification measures 
This component does not require additional verification measures. 
6.4 Safety features required from other components 
This component does not require safety features from other components. 
6.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
31 / 103 

---

Safety Manual CBD1601056 D05 
7 Safety Manual Com 
7.1 Safety features 
This component does not provide safety features. 
7.2 Configuration constraints 
SMI-314 
The user of MICROSAR Safe shall configure the following parameters: 
o  Set /MICROSAR/Com/ComGeneral/ComReceiveSignalMacroAPI to FALSE. 
o  Set /MICROSAR/Com/ComGeneral/ComMetaDataSupport to FALSE. 
o  Set /MICROSAR/Com/ComGeneral/ComDescriptionRoutingCodeGeneration to 
FALSE. 
This setting is enforced by a MSSV plugin. 
SMI-315 
The user of MICROSAR Safe shall configure the following: 
A container in /MICROSAR/PduR/PduRBswModules with a reference 
(/MICROSAR/PduR/PduRBswModules/PduRBswModuleRef) to /ActiveEcuC/Com and 
shall set the following parameters: 
o  /MICROSAR/PduR/PduRBswModules/PduRCommunicationInterface to TRUE 
o  /MICROSAR/PduR/PduRBswModules/PduRTransportProtocol to FALSE  
o  /MICROSAR/PduR/PduRBswModules/PduRCancelTransmit to FALSE 
This setting is enforced by a MSSV plugin. 
7.3 Additional verification measures 
SMI-1104 
The user of MICROSAR Safe shall verify that the SignalDataPtr passed to 
Com_ReceiveSignal and Com_ReceiveShadowSignal points to a valid buffer which matches 
the configured /MICROSAR/Com/ComConfig/ComSignal/ComSignalType or 
/MICROSAR/Com/ComConfig/ComGroupSignal/ComSignalType. In case of the 
ComSignalType UINT8_N the caller must ensure that the array size matches to the 
configured /MICROSAR/Com/ComConfig/ComSignal/ComSignalLength or 
/MICROSAR/Com/ComConfig/ComGroupSignal/ComSignalLength. 
This can be verified by comparing the type of the pointer passed to SignalDataPtr to the 
ApplType returned by Com_GetApplTypeOfRxAccessInfo(Index). 
2018 Vector Informatik GmbH 
1.0 
32 / 103 

---

Safety Manual CBD1601056 D05 
If the ApplType is set to COM_UINT8_N_APPLTYPEOFRXACCESSINFO additionally verify that the 
value of Com_GetRxSigBufferArrayBasedBufferLengthOfRxAccessInfo(Index) is less or 
equal to the size (in bytes) of the array passed to SignalDataPtr. 
The parameter of the macros Com_GetApplTypeOfRxAccessInfo(Index) and 
Com_GetRxSigBufferArrayBasedBufferLengthOfRxAccessInfo(Index) is the SignalId and 
can be found in the generated header files.  
7.4 Safety features required from other components 
This component does not require safety features from other components. 
7.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
33 / 103 

---

Safety Manual CBD1601056 D05 
8 Safety Manual ComM 
8.1 Safety features 
This component does not provide safety features. 
8.2 Configuration constraints 
This component does not have configuration constraints. 
8.3 Additional Verification measures 
SMI-94 
The user of MICROSAR Safe shall verify that the array size generated by ComM matches 
to the array size in the type definition of RTE. The following procedure shall be applied to 
each channel that has activated the ComM parameter 'Full Comm Request Notification 
Enabled'. 
1.  ComM_Cfg.h contains array size definition in the format 
COMM_MAX_CR_<ShortNameOfChannel> 
2.  rte_type.h contains the definition of the corresponding structure type in the format 
ComM_UserHandleArrayType_<ShortNameOfChannel> 
3.  Verify that the structure member 'handleArray' has the same size as the corresponding 
define value of ComM in 1). 
4.  Verify the content of the generated functions ComM_CurrentChannelRequestInit and 
ComM_CurrentChannelRequestNotification to ensure that the proper define 
COMM_MAX_CR_<ShortNameOfChannel> is used to limit the array index when 
writing to ComM_UserHandleArrayType_<ShortNameOfChannel>.handleArray[]. 
SMI-95 
The user of MICROSAR Safe shall verify that the value of ComSignalLength (byte) in Com 
module is smaller or equal to the value of COMM_PNC_SIGNAL_LENGTH (can be found 
in ComM_Cfg.h). 
This shall be verified for each ComPncSignal referenced by Partial Network Clusters and 
having ComMPncComSignalDirection = RX. 
SMI-1046 
The user of MICROSAR Safe shall verify that each element of table 
ComM_UserModeNotiFunc refers either a NULL_PTR or a function that has the following 
signature (the placeholder <name> represents the function's name): 
Std_ReturnType <name>(uint8 nextMode) 
The table ComM_UserModeNotiFunc can be found in ComM_Lcfg.c. This measure is only 
needed if at least one ComM user has enabled the parameter 'User Mode Notification'. 
2018 Vector Informatik GmbH 
1.0 
34 / 103 

---

Safety Manual CBD1601056 D05 
8.4 Safety features required from other components 
This component does not require safety features from other components. 
8.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
35 / 103 

---

Safety Manual CBD1601056 D05 
9 Safety Manual Crc 
9.1 Safety features 
SMI-344 
Crc provides the following safety features: 
ID  
Safety feature  
CREQ-858  
Crc shall provide a service to calculate 8-bit SAE-J1850 CRC. 
CREQ-859  
Crc shall provide a service to calculate 8-bit 0x2F CRC. 
CREQ-860  
Crc shall provide a service to calculate 16-bit CCITT CRC. 
CREQ-861  
Crc shall provide a service to calculate 32-bit IEEE-802.3 CRC. 
CREQ-862  
Crc shall provide a service to calculate 32-bit E2E Profile 4 CRC. 
CREQ-117997  
Crc shall provide a service to calculate 64-bit ECMA CRC. 
 
9.2 Configuration constraints 
This component has no configuration constraints. 
9.3 Additional verification measures 
SMI-49 
The user of MICROSAR Safe shall verify that the CRC is calculated for the intended data. 
This includes the intended buffer and its size (see also SMI-16), start value and if it is the 
first call to the service. 
Verification can be performed by the "magic check" (see AUTOSAR SWS Crc). 
If Crc is used by a MICROSAR Safe component (e.g. E2E, NvM), this requirement is 
fulfilled for the MICROSAR Safe component. 
9.4 Dependencies to other components 
9.4.1 Safety features required from other components 
This component does not require safety features from other components. 
9.4.2 Coexistence with other components 
This component does not require coexistence with other components. 
It is assumed that the user of Crc has the adequate ASIL. 
9.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
36 / 103 

---

Safety Manual CBD1601056 D05 
10 Safety Manual Csm 
10.1 Safety Features 
SMI-47 
Csm provides the following safety features: 
ID  
Safety feature  
CREQ-330  
Csm shall provide services to compute hash functions. 
CREQ-331  
Csm shall provide services to compute MAC functions. 
CREQ-1252  
Csm shall provide services to verify MAC functions. 
Note: It is assumed that cryptographic algorithms yield different results for different input 
parameters. 
10.2 Configuration constraints 
This component does not have configuration constraints. 
10.3 Additional verification measures 
SMI-46 
The user of MICROSAR Safe shall verify that the intended callback functions is called 
during integration testing. 
This requirement only applies if callback functions are configured. 
This requirement only applies if TSR-11 is considered a safety requirement. 
SMI-45 
The user of MICROSAR Safe shall verify that the intended Cry service is called during 
integration testing. 
This requirement only applies if TSR-11 is considered a safety requirement. 
10.4 Dependencies to other components 
This component does not require safety features from other components. 
10.4.1 Safety features required from other components 
SMI-44 
The used Cry shall provide the services to compute hash functions, to compute MAC 
functions, to verify MAC functions and to compute checksums over data as safety feature. 
This requirement only applies if TSR-11 is considered a safety requirement. 
2018 Vector Informatik GmbH 
1.0 
37 / 103 

---

Safety Manual CBD1601056 D05 
10.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
38 / 103 

---

Safety Manual CBD1601056 D05 
11 Safety Manual Det 
11.1 Safety features 
This component does not provide safety features. 
11.2 Configuration constraints 
This component does not have configuration constraints. 
SMI-60 
If the DET is used in series production the extended debug features shall be switched off, 
because they are only relevant if a debugger is attached.  
The user of MICROSAR Safe shall configure and verify the following attribute: 
o  /MICROSAR/Det/DetGeneral/DetExtDebugSupport = False 
11.3 Additional Verification measures 
SMI-4671 
The user of MICROSAR Safe shall verify that the enter and exit functions of the 
DET’s exclusive area do not produce DET errors. 
Verification can e.g. be performed by review. If these functions are mapped to OS services 
it has to be checked that from the ErrorHook of the OS no DET error reporting functions 
are called if the ErrorHook has been called due to an error in the OS service used for the 
DET's exclusive area. 
11.4 Safety features required from other components 
This component does not require safety features from other components. 
11.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
39 / 103 

---

Safety Manual CBD1601056 D05 
12 Safety Manual EcuM 
12.1 Safety features 
SMI-34 
EcuM Flex provides the following safety features: 
ID  
Safety feature  
CREQ-
EcuM shall provide a service to initialize the ECU management. 
470  
CREQ-
EcuM shall provide ECU initialization on multiple cores. 
454  
CREQ-
EcuM shall perform validation of all postbuild configurable BSW module configuration 
543  
parameters. 
CREQ-
EcuM shall provide a callout to set programmable interrupts during the startup phase. 
375  
CREQ-
EcuM shall provide a callout to initialize driver prior the start of the OS. 
525  
CREQ-
EcuM shall provide a callout to determine the Postbuild configuration data. 
488  
CREQ-
EcuM shall provide a callout to initialize drivers prior Postbuild data is available. 
505  
CREQ-
EcuM shall provide a callout to reset the ECU. 
391  
CREQ-
EcuM shall provide a callout to generate a RAM Hash. 
381  
CREQ-
EcuM shall provide a callout to check the RAM Hash. 
440  
CREQ-
EcuM shall provide a callout to re-initialize drivers during a restart. 
509  
CREQ-
EcuM shall provide a service to set the current shutdown target of the ECU. 
445  
CREQ-
EcuM shall provide a service to get the shutdown target of the ECU. 
483  
CREQ-
EcuM shall provide a service to initiate the ECU shutdown depending on the 
372  
shutdown target. 
CREQ-
EcuM shall provide a callout to notify Errors from the ECU management. 
431  
CREQ-
EcuM shall provide a service to complete the ECU shutdown process. 
421  
CREQ-
EcuM shall provide a service to initiate an ECU shutdown. 
535  
CREQ-
EcuM shall indicate mode changes to the RTE. 
699  
CREQ-
EcuM shall provide a service to request the run state. 
2018 Vector Informatik GmbH 
1.0 
40 / 103 

---

Safety Manual CBD1601056 D05 
691  
CREQ-
EcuM shall provide a service to release the run state. 
692  
CREQ-
EcuM shall provide a service to release the post run state. 
693  
CREQ-
EcuM shall provide a service to request the post run state. 
690  
Note: RAM Hash generation and checking callouts are only available when sleep modes 
are configured. 
SMI-286 
EcuM Fix provides the following safety features: 
ID  
Safety feature  
CREQ-
EcuM shall provide a service to initialize the ECU management. 
470  
CREQ-
EcuM shall provide ECU initialization on multiple cores. 
454  
CREQ-
EcuM shall perform validation of all postbuild configurable BSW module configuration 
543  
parameters. 
CREQ-
EcuM shall provide a callout to set programmable interrupts during the startup phase. 
375  
CREQ-
EcuM shall provide a callout to initialize driver prior the start of the OS. 
525  
CREQ-
EcuM shall provide a callout to determine the Postbuild configuration data. 
488  
CREQ-
EcuM shall provide a callout to initialize drivers prior Postbuild data is available. 
505  
CREQ-
EcuM shall provide a callout to reset the ECU. 
391  
CREQ-
EcuM shall provide a callout to generate a RAM Hash. 
381  
CREQ-
EcuM shall provide a callout to check the RAM Hash. 
440  
CREQ-
EcuM shall provide a callout to re-initialize drivers during a restart. 
509  
CREQ-
EcuM shall provide a service to set the current shutdown target of the ECU. 
445  
CREQ-
EcuM shall provide a service to initiate the ECU shutdown depending on the 
372  
shutdown target. 
CREQ-
EcuM shall provide a callout to notify Errors from the ECU management. 
431  
CREQ-
EcuM shall provide a service to complete the ECU shutdown process. 
421  
CREQ-
EcuM shall indicate mode changes to the RTE. 
699  
2018 Vector Informatik GmbH 
1.0 
41 / 103 

---

Safety Manual CBD1601056 D05 
CREQ-
EcuM shall provide the ECU state machine. 
703  
CREQ-
EcuM shall trigger the NvM write job in shutdown path. 
707  
CREQ-
EcuM shall provide a callback which is called by the NvM to notify the end of the write 
668  
all job. 
CREQ-
EcuM shall provide a service to request the run state. 
691  
CREQ-
EcuM shall provide a service to release the run state. 
692  
CREQ-
EcuM shall provide a service to release the post run state. 
693  
CREQ-
EcuM shall provide a service to request the post run state. 
690  
CREQ-
EcuM shall provide a service to kill all post run requests. 
694  
CREQ-
EcuM shall provide a service to kill all run requests. 
695  
Note: RAM Hash generation and checking callouts are only available when sleep modes 
are configured. 
SMI-38 
If EcuM service to complete the shutdown process is called prior to initiate the shutdown 
process, no shutdown will be performed. 
12.2 Configuration constraints 
SMI-36 
The user of MICROSAR Safe shall configure the following attribute: 
o  Set /MICROSAR/EcuM/EcuMFlexGeneral/EcuMEnableDefBehaviour to FALSE. 
o  Do not configure any reference in 
/MICROSAR/EcuM/EcuMConfiguration/EcuMCommonConfiguration/EcuMWakeup
Source/EcuMComMPNCRef to a PNC for a wakeup source  
These settings are enforced by MSSV plugins. 
12.3 Additional verification measures 
SMI-39 
The user of MICROSAR Safe shall verify the intended initialization procedure during 
integration testing. 
The user of MICROSAR Safe can verify the intended initialization procedure by performing 
the following tests: 
2018 Vector Informatik GmbH 
1.0 
42 / 103 

---

Safety Manual CBD1601056 D05 
o  Start the ECU and verify that the intended initalization routines are called. This 
needs to be verified for each Postbuild-selectable configuration. 
o  Corrupt the Postbuild data (but not corresponding CRC) in non-volatile memory and 
start the ECU. Then verify that the corruption is detected by EcuM. 
o  Start the ECU and verify that the intended Postbuild-selectable configuration is 
used by the EcuM. This needs to be verified for each Postbuild-selectable 
configuration. 
A start of the ECU includes a "cold-start", reset as well as wake-up from sleep if 
applicable. 
This requirement only applies if TSR-1 is considered a safety requirement. 
SMI-35 
The user of MICROSAR Safe shall verify the intended shutdown procedure during 
integration testing. 
The user of MICROSAR Safe can verify the intended shutdown procedure by shutting 
down the ECU with all configured shutdown paths. A shutdown path is a call to the service 
that sets the current shutdown target with a relevant (e.g. combination used to achieve 
safe state) combination of its parameters. For each shutdown path the intended final state 
of the ECU (e.g. sleep, shutdown, reset) and the method of reset (e.g. using MCU or 
Watchdog) is used. 
The user of MICROSAR Safe shall also consider the service to initiate the ECU shutdown 
depending on the shutdown target as a possible shutdown path. 
The user of MICROSAR Safe shall also verify the default shutdown target. 
This requirement only applies if TSR-3 is considered as a safety requirement. 
SMI-40 
The user of MICROSAR Safe shall verify that the memory region used for RAM hash 
generation and verification is as intended. 
Verification can be e.g. performed by review. 
12.4 Safety features required from other components 
SMI-42 
The used operating system shall provide the service to get the core ID as safety feature. 
If the operating system from MICROSAR Safe is used, this dependency is fulfilled. 
This requirement only applies if TSR-1 is considered a safety requirement. 
2018 Vector Informatik GmbH 
1.0 
43 / 103 

---

Safety Manual CBD1601056 D05 
12.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
44 / 103 

---

Safety Manual CBD1601056 D05 
13 Safety Manual Fee 
13.1 Safety features 
This component does not provide safety features. 
13.2 Configuration constraints 
This component does not have configuration constraints. 
13.3 Additional Verification measures 
SMI-1292 
The user of MICROSAR Safe shall verify that valid notification routines are provided to 
FEE via configuration. 
'FeeNvmJobEndNotification' and 'FeeNvmJobErrorNotification' callbacks are called by 
FEE using a function pointer. 
13.4 Safety features required from other components 
This component does not require safety features from other components. 
SMI-1643 
This component requires coexistence with MemIf, NvM, FlsDrv and Det components if the 
interface for those components is configured. 
13.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
45 / 103 

---

Safety Manual CBD1601056 D05 
14 Safety Manual MemIf 
14.1 Safety features 
This component does not provide safety features. 
14.2 Configuration constraints 
This component does not have configuration constraints. 
14.3 Additional verification measures 
This component does not require additional verification measures. 
14.4 Dependencies to other components 
14.4.1 Safety features required from other components 
This component does not require safety features from other components. 
14.4.2 Coexistence with other components 
SMI-311 
This component requires coexistence with NvM, Det, Fee, and Ea components if the 
interface for those components is configured. 
14.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
46 / 103 

---

Safety Manual CBD1601056 D05 
15 Safety Manual Nm 
15.1 Safety features 
This component does not provide safety features. 
15.2 Configuration constraints 
This component does not have configuration constraints. 
15.3 Additional Verification measures 
This component does not require additional verification measures. 
15.4 Dependencies to other components 
15.4.1 Safety features required from other components 
This component does not require safety features from other components. 
15.4.2 Coexistence with other components 
SMI-149 
This component requires coexistence with ComM, Com, BswM, Det, SchM/Rte, Rtm and 
bus network manager components if the interface for those components is configured. 
15.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
47 / 103 

---

Safety Manual CBD1601056 D05 
16 Safety Manual NvM 
16.1 Safety features 
SMI-21 
This component provides the following safety features: 
ID  
Safety feature  
CREQ-724  
NvM shall provide a service to read a single NvM block from NVRAM. 
CREQ-725  
NvM shall provide a service to write a single NvM block to NVRAM. 
CREQ-730  
NvM shall provide a service to read all possbile NvM blocks from NVRAM. 
CREQ-731  
NvM shall provide a service to write all possible NvM blocks to NVRAM. 
CREQ-746  
NvM shall provide configurable callbacks to synchronize block data. 
NvM can detect missing, corruption and masquerading (lower layers provide the wrong 
block) of NvM blocks. 
SMI-29 
The user of MICROSAR Safe must design the system in a way that in case of the absence 
of non‑volatile data it is still safe (e.g. safe state or degradation). It cannot be assured by 
the memory stack that data is saved completely or at all because a reset or loss of energy 
might happen at any time, e.g. brown-out, black-out. 
This also implies that it is in general impossible to guarantee that the latest information is 
available in the non-volatile memory, e.g. the system is reset before memory stack is even 
notified to write data to non-volatile memory. 
Thus, safety-related functionality may not rely on the availability of data in non-volatile 
memory. 
Since the availability of data in non-volatile memory cannot be guaranteed in any case, the 
only sensible use-case is reading safety-related calibration data. 
Writing of data into non-volatile memory must be verified to assure that the information is 
available in non-volatile memory. Verification can only be done manually in a protected 
environment, e.g. at end of line, in a workshop, etc. 
ECU software cannot verify if data was written, since at any time a reset could occur and 
the information that had to be written is lost immediately. 
Reading of data does not modify data stored in non-volatile memory. Thus, reading can be 
used by safety-related functionality. The memory stack assures that the read data is 
identical to the data stored in non-volatile memory. 
The availability may be increased by e.g. redundant storage. 
16.2 Configuration constraints 
SMI-25 
The user of MICROSAR Safe shall configure and verify the following attributes for each 
NvM block that contains safety-related data: 
o  Set /MICROSAR/NvM/NvMBlockDescriptor/NvMBlockUseCrc to TRUE. 
o  Set /MICROSAR/NvM/NvMBlockDescriptor/NvMBlockCrcType to NVM_CRC32. 
2018 Vector Informatik GmbH 
1.0 
48 / 103 

---

Safety Manual CBD1601056 D05 
SMI-26 
The user of MICROSAR Safe shall configure and verify the following attribute: 
o  Set /MICROSAR/NvM/NvMCommon/NvMUseBlockIdCheck to TRUE. 
16.3 Additional verification measures 
SMI-22 
The user of MICROSAR Safe shall pass the intended block ID for reading and writing of a 
single NvM block. NvM cannot detect if an unintended block that is configured is provided 
by the user.  
Verification can be performed during integration testing. 
SMI-23 
The user of MICROSAR Safe shall verify that the buffer passed for reading and writing of a 
single NvM block is valid and sufficiently large for the passed block ID. 
Verification can be performed by a review of the generated configuration and the code 
passing the pointer and block ID to the NvM. 
SMI-48 
The user of MICROSAR Safe shall verify the size of the internal NvM buffer. 
The buffer has the symbol name NvM_InternalBuffer_au8. 
The buffer is generated when at least one of the following features is used: 
o  at least one block with explicit synchronization is configured 
o  repair of redundant blocks is enabled 
o  NvM internal CRC buffer is enabled 
The buffer size shall be at least the size of the largest NVM block plus the size of the 
configured CRC value. 
Verification can be performed e.g. by review. 
16.4 Safety features required from other components 
SMI-28 
The used Crc library shall provide the CRC calculation routines as safety feature. 
If the Crc library from MICROSAR Safe is used, this dependency is fulfilled. 
16.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
49 / 103 

---

Safety Manual CBD1601056 D05 
17 Safety Manual OS 
17.1 Safety features 
SMI-1259 
This component provides the following safety features: 
ID  
Safety feature  
CREQ-63  
OS shall provide a service to start the OS.  
CREQ-162   OS shall provide a service to initialize itself.  
CREQ-51  
OS shall automatically start a subset of alarms for an application mode.  
CREQ-146   OS shall automatically start a subset of tasks for an application mode.  
CREQ-72  
OS shall automatically start a subset of schedule tables for an application mode.  
CREQ-117   OS shall provide a service to get the current application mode.  
CREQ-45  
OS shall provide a global callback during OS startup.  
CREQ-299   Os shall synchronize the startup in multicore systems.  
CREQ-153   OS shall provide a service to shutdown the OS.  
CREQ-95  
OS shall provide a service to shutdown all cores synchronously.  
CREQ-161   OS shall provide a global callback upon shutdown.  
CREQ-71  
OS shall provide a global callback directly before a task starts its execution.  
CREQ-165   OS shall provide a global callback directly before a task finishes its execution.  
CREQ-42  
OS shall provide a service to activate a task.  
CREQ-28  
OS shall handle multiple activations of basic tasks.  
CREQ-101   OS shall provide a service to terminate the calling task.  
CREQ-121   OS shall provide a service to define the next activated task.  
CREQ-126   OS shall provide a service to explicitly invoke the scheduler.  
CREQ-80  
OS shall provide a service to get the ID of the current task  
CREQ-74  
OS shall provide a service to get the state of a given task.  
CREQ-135   OS shall provide a service to declare a task.  
CREQ-115   OS shall provide a service to execute a callback in category 2 ISRs.  
CREQ-16  
OS shall provide a service to get the ID of the currently executing category 2 ISR.  
CREQ-24  
OS shall handle unconfigured interrupt sources.  
CREQ-78  
OS shall provide a service to determine the interrupt source of a non-configured 
interrupt upon handling of such interrupt.  
CREQ-154   OS shall provide a nestable service to disable all interrupts.  
CREQ-98  
OS shall provide a nestable service to enable all interrupts.  
CREQ-151   OS shall provide a nestable service to disable all category 2 interrupts.  
CREQ-82  
OS shall provide a nestable service to enable all category 2 interrupts.  
CREQ-111   OS shall provide a non nestable service to disable all interrupts.  
CREQ-43  
OS shall provide a non nestable service to enable all interrupts.  
2018 Vector Informatik GmbH 
1.0 
50 / 103 

---

Safety Manual CBD1601056 D05 
CREQ-
OS shall provide a non nestable service to disable all interrupts callable from kernel 
1257  
mode  
CREQ-
OS shall provide a non nestable service to enable all interrupts callable from kernel 
1259  
mode  
CREQ-
OS shall provide a non nestable service to disable all interrupts callable from user 
1256  
mode  
CREQ-
OS shall provide a non nestable service to enable all interrupts callable from user 
1258  
mode  
CREQ-
OS shall provide a non nestable service to disable all interrupts callable from any 
108741  
mode.  
CREQ-
OS shall provide a non nestable service to enable all interrupts callable from any 
108742  
mode.  
CREQ-
OS shall provide a non nestable service to disable all category 2 interrupts callable 
108744  
from kernel mode.  
CREQ-
OS shall provide a non nestable service to enable all category 2 interrupts callable 
108747  
from kernel mode.  
CREQ-
OS shall provide a non nestable service to disable all category 2 interrupts callable 
108743  
from user mode.  
CREQ-
OS shall provide a non nestable service to enable all category 2 interrupts callable 
108748  
from user mode.  
CREQ-
OS shall provide a non nestable service to disable all category 2 interrupts callable 
108745  
from any mode.  
CREQ-
OS shall provide a non nestable service to enable all category 2 interrupts callable 
108746  
from any mode.  
CREQ-
OS shall provide a service to disable a specific interrupt source.  
106181  
CREQ-
OS shall provide a service to enable a specific interrupt source.  
106182  
CREQ-
OS shall provide a service to clear pending interrupts  
106183  
CREQ-
OS shall provide a service to check whether or not the source of the given ISR is 
114872  
enabled  
CREQ-
OS shall provide a service to check whether or not the given ISR has been requested  
114873  
CREQ-68  
OS shall provide a service to wait for the occurrence of events.  
CREQ-155   OS shall provide a service to signal the occurrence of events to a task.  
CREQ-53  
OS shall provide a service to acknowledge the occurrence of events.  
CREQ-129   OS shall provide a service to get the event states of a given task.  
CREQ-133   OS shall provide a service to declare an event.  
CREQ-22  
OS shall provide a service to increment a counter.  
CREQ-156   OS shall provide a service to get the current value of a counter.  
CREQ-39  
OS shall provide a service to get the difference between a given and the current 
counter value.  
CREQ-44  
OS shall provide a service for each hardware counter to translate a given period of 
2018 Vector Informatik GmbH 
1.0 
51 / 103 

---

Safety Manual CBD1601056 D05 
time into number of ticks.  
CREQ-297   OS shall provide a service for each hardware counter to translate number of counter 
ticks into a period of time.  
CREQ-
OS shall provide a service to get the maximum possible value of a counter  
1260  
CREQ-
OS shall provide a service to get the number of underlying driver ticks required to 
1261  
reach a specific unit  
CREQ-
OS shall provide a service to get the minumum allowed number of ticks for a cyclic 
1262  
alarm of a counter  
CREQ-116   OS shall provide a service to set a relative alarm.  
CREQ-29  
OS shall provide a service to set an absolute alarm.  
CREQ-93  
OS shall provide a service to get an alarm.  
CREQ-164   OS shall provide a service to cancel an alarm.  
CREQ-19  
OS shall provide a service to get the alarm base.  
CREQ-142   OS shall provide alarm callbacks.  
CREQ-32  
OS shall provide a service to declare an alarm.  
CREQ-61  
OS shall provide a service to start a schedule table at a relative value.  
CREQ-136   OS shall provide a service to start a schedule table at an absolute value.  
CREQ-96  
OS shall provide a service to stop the processing of a schedule table.  
CREQ-112   OS shall provide a service to switch the processing between different schedule 
tables.  
CREQ-100   OS shall provide a service to start an explicitly synchronized schedule table 
synchronously.  
CREQ-152   OS shall provide a service to synchronize a schedule table with a synchronization 
counter.  
CREQ-25  
OS shall provide a service to stop synchronization of a schedule table.  
CREQ-108   OS shall provide a service to query the state of a schedule table.  
CREQ-36  
OS shall provide a mechanism to coordinate concurrent access to shared resources.  
CREQ-56  
OS shall provide a service to acquire a resource.  
CREQ-107   OS shall provide a service to release a resource.  
CREQ-163   OS shall provide a service to declare a resource.  
CREQ-17  
OS shall provide a service to acquire a spinlock.  
CREQ-139   OS shall provide a service to asynchronously acquire a spinlock.  
CREQ-167   OS shall provide a service to release a spinlock.  
CREQ-172   OS shall provide a service to determine the application ID to which the current 
execution context was configured.  
CREQ-60  
OS shall provide a service to determine the application ID in which the current 
execution context is executed.  
CREQ-114   OS shall provide a service to make an application accessible.  
CREQ-109   OS shall provide a service to identify accessibility of OS objects .  
CREQ-18  
OS shall provide a service to identify object ownership.  
CREQ-110   OS shall provide a service to terminate an application.  
2018 Vector Informatik GmbH 
1.0 
52 / 103 

---

Safety Manual CBD1601056 D05 
CREQ-170   OS shall provide restart tasks.  
CREQ-104   OS shall provide a service to get the state of a given application.  
CREQ-34  
OS shall provide a service to call exported services from trusted applications.  
CREQ-
OS shall allow usage of exported services from trusted applications before start of 
115372  
the OS.  
CREQ-
OS shall provide a service to call exported services from non-trusted applications.  
105586  
CREQ-
OS shall allow usage of exported services from non-trusted applications before start 
105587  
of the OS.  
CREQ-48  
OS shall provide an application specific callback during OS startup.  
CREQ-76  
OS shall provide an application specific callback during OS shutdown.  
CREQ-54  
OS shall provide an application specific callback if an error occurs.  
CREQ-73  
OS shall provide a service to return the access rights of a memory access of a task.  
CREQ-13  
OS shall provide a service to return the access rights of a memory access of a 
category 2 ISR.  
CREQ-49  
OS shall provide execution time protection.  
CREQ-85  
OS shall provide inter-arrival time protection.  
CREQ-31  
OS shall provide locking time protection.  
CREQ-845   OS shall monitor execution times.  
CREQ-846   OS shall monitor inter arrival time frames.  
CREQ-847   OS shall monitor locking times.  
CREQ-35  
OS shall provide a service to modify a value in a peripheral region.  
CREQ-79  
OS shall provide a service to read a value from a peripheral region.  
CREQ-145   OS shall provide a service to write a value in a peripheral region.  
CREQ-
OS shall allow usage of services for peripheral regions before start of the OS.  
115373  
CREQ-26  
OS shall be able to call a global callback function if an error occurs.  
CREQ-38  
OS shall be able to call a global callback function if a fatal error occurs  
CREQ-97  
OS shall provide a service to all configured error callbacks, which return the 
parameters of the system service which triggered error handling.  
CREQ-23  
OS shall provide a service to all configured error callbacks, which returns the service 
identifier where the error has been risen.  
CREQ-102   OS shall provide information to determine the service and the cause of a reported 
error.  
CREQ-
OS shall provide a service, which writes the context of the thread to which the 
129663  
system returns after error handling.  
CREQ-
OS shall provide a service, which returns the context of the thread which triggered a 
129664  
fatal error.  
CREQ-70  
OS shall provide a service to forcibly terminate a task.  
CREQ-21  
OS shall provide a service to forcibly terminate a category 2 ISR.  
CREQ-168   OS shall provide a service to select the idle mode action.  
CREQ-150   OS shall provide a service to write data to an unqueued IOC channel.  
2018 Vector Informatik GmbH 
1.0 
53 / 103 

---

Safety Manual CBD1601056 D05 
CREQ-55  
OS shall provide a service to read data from a unqueued IOC channel.  
CREQ-91  
OS shall provide a service to send data to a queued IOC channel.  
CREQ-160   OS shall provide a service to receive data from a queued IOC channel.  
CREQ-90  
OS shall provide a service to write multiple data to an unqueued IOC channel.  
CREQ-147   OS shall provide a service to read multiple data from an unqueued IOC channel.  
CREQ-119   OS shall provide a service to send multiple data to a queued IOC channel.  
CREQ-113   OS shall service a method to receive multiple data from a queued IOC channel.  
CREQ-128   OS shall provide a service to clear all data from a queued IOC channel.  
CREQ-141   OS shall be able to call a callback function upon IOC data reception.  
CREQ-149   OS shall provide a service to identify the local core.  
CREQ-148   OS shall provide a service to get the number of cores controlled by OS.  
CREQ-37  
OS shall provide a service to start a core for usage of AUTOSAR OS software.  
CREQ-120   OS shall provide a service to start a core for usage of non AUTOSAR OS software.  
CREQ-
OS shall be able to initialize itself and the hareware on any of the available cores.  
115996  
CREQ-
OS shall provide a callback for signalling a task activation.  
115010  
CREQ-
OS shall provide a callback for signalling the setting of an event.  
115028  
CREQ-
OS shall provide a callback for signalling a thread switch.  
115029  
CREQ-
OS shall provide a callback for signalling forcible termination of a thread.  
115030  
CREQ-
OS shall provide a callback for signalling the acquirement of a resource.  
115031  
CREQ-
OS shall provide a callback for signalling the release of a resource.  
115032  
CREQ-
OS shall provide a callback for signalling the attempt to acquire a spinlock.  
115033  
CREQ-
OS shall provide a callback for signalling the acquirement of a spinlock  
115034  
CREQ-
OS shall provide a callback for signalling the release of a spinlock.  
115035  
CREQ-
OS shall provide a callback for signalling the attempt to internally acquire a spinlock.  
115036  
CREQ-
OS shall provide a callback for signalling the internal acquirement of a spinlock  
115037  
CREQ-
OS shall provide a callback for signalling the internal release of a spinlock.  
115038  
CREQ-
OS shall provide a callback for signalling the locking of interrupts.  
115039  
CREQ-
OS shall provide a callback for signalling the release of an interrupt lock.  
115040  
2018 Vector Informatik GmbH 
1.0 
54 / 103 

---

Safety Manual CBD1601056 D05 
CREQ-
OS shall provide a callback for signalling failed task activation because the number 
140268  
of activations exceeds the limit.  
CREQ-
OS shall provide a callback for signalling that event is already set when WaitEvent is 
140269  
called.  
 
17.2 Configuration constraints 
SMI-378 
The user of MICROSAR Safe shall configure and verify the extended OS status of APIs. 
The attribute /MICROSAR/Os_Core/Os/OsOs/OsStatus shall equal to EXTENDED. 
The OS safety measures rely on the validity checks defined for EXTENDED status of OS 
API calls. Without these checks invalid calls might destroy the system integrity and violate 
safety requirements. Ensuring the validity of API calls and arguments in STANDARD 
status for any caller (which e.g. might be QM software) is considered to be infeasible. 
SMI-377 
The user of MICROSAR Safe shall configure and verify the service protection. 
The attribute /MICROSAR/Os_Core/Os/OsOs/OsServiceProtection shall equal to TRUE. 
The OS safety measures rely on the validity checks defined for OsServiceProtection 
enabled. Without these checks API invalid calls might destroy the system integrity and 
violate safety requirements. Ensuring the validity of API calls with 
OsServiceProtectiondisabled for any caller (which e.g. might be QM software) is 
considered to be infeasible. 
SMI-379 
The user of MICROSAR Safe shall configure and verify the scalability class 3 or 4. 
The attribute /MICROSAR/Os_Core/Os/OsOs/OsScalabilityClass shall equal to SC3 or 
SC4. 
The OS safety measures rely on memory protection and service protection provided by the 
scalability classes SC3 and SC4. Without memory protection, all software parts (even QM 
parts) would have to ensure freedom from interference regarding memory (including 
absence of stack overflow). Without service protection, all software parts (even QM parts) 
would have to ensure only calls with valid access rights. 
SMI-385 
The user of MICROSAR Safe shall not use ISRs of category 1 if timing protection is 
configured. 
If a thread is killed because of timing protection, ISRs of category 1 might be aborted. 
A possible workaround is using ISRs of category 2 instead of category 1. 
2018 Vector Informatik GmbH 
1.0 
55 / 103 

---

Safety Manual CBD1601056 D05 
17.3 Additional verification measures 
SMI-380 
The user of MICROSAR Safe shall ensure the correct usage of the OS regarding program 
flow. The correct program flow is ensured only if all OS API functions are correctly used 
according to the AUTOSAR OS specification, according to the technical reference and 
according to the requirements of the user application. 
SMI-3732 
The user of MICROSAR Safe shall ensure the correct usage of the hardware. 
It is assumed that user software uses the microcontroller exactly as specified in the 
vendors hardware documentation. 
SMI-383 
The user of MICROSAR Safe shall not call OS hook functions. The OS hook functions 
shall be called by the OS only. This applies to the following hook functions: 
o  StartupHook 
o  ShutdownHook 
o  ProtectionHook 
o  PreTaskHook 
o  PostTaskHook 
o  ErrorHook 
The OS makes assumptions which are valid if these hook functions are called by the OS 
(e.g. set a hook context). These assumptions might be violated if the hook functions are 
called directly by the user. As a hook may expect, that it is called within a specific context, 
hooks shall not be called from directly from user code. 
SMI-1047 
The user of MICROSAR Safe shall ensure that the context definition as described in the 
Technical Reference is complete for his application. Only this context is preserved on 
context switches. 
SMI-100816 
The user of MICROSAR Safe shall verify that the processor state bits controlled by the 
user are correctly set. This especially applies in case of forcible termination. 
17.3.1 Interrupt handling 
SMI-381 
The user of MICROSAR Safe shall ensure the correct usage of the OS regarding interrupt 
disabling. Unintended disabling of interrupts may lead to timing inconsistency because 
pending interrupts might be delayed.  
2018 Vector Informatik GmbH 
1.0 
56 / 103 

---

Safety Manual CBD1601056 D05 
The following interrupt disabling API functions shall be used correct according to the 
AUTOSAR OS specification and according to the requirements of the user application, 
otherwise the correct functionality is not ensured: 
o  DisableAllInterrupts 
o  SuspendAllInterrupts 
o  SuspendOSInterrupts 
o  DisableLevel 
SMI-382 
The user of MICROSAR Safe shall ensure the correct usage of the OS regarding interrupt 
enabling. Unintended enabling of interrupts may lead to timing inconsistency (because 
interrupts might occur which should be disabled) and data inconsistency (see also SMI-
11). The user shall ensure that timing inconsistencies are detected or avoided.  
The following interrupt enabling API functions shall be used correct according to the 
AUTOSAR OS specification and according to the requirements of the user application, 
otherwise the correct functionality is not ensured: 
o  EnableAllInterrupts 
o  ResumeAllInterrupts 
o  ResumeOSInterrupts 
o  EnableLevel 
SMI-482 
The user of MICROSAR Safe shall verify that API functions DisableLevel, EnableLevel, 
DisableGlobal and EnableGlobal are never called in the following cases: 
o  if interrupts are disabled 
o  within critical sections 
o  nested within other interrupt APIs 
o  within interrupt resources 
o  within interrupt locking spinlocks 
o  within ISRs, Hook functions, non-trusted functions, trusted functions and alarm 
callbacks 
SMI-488 
The user of MICROSAR Safe shall verify that the following API functions are called from 
privileged mode only: 
2018 Vector Informatik GmbH 
1.0 
57 / 103 

---

Safety Manual CBD1601056 D05 
o  DisableLevelKM 
o  EnableLevelKM 
o  DisableGlobalKM 
o  EnableGlobalKM 
SMI-489 
The user of MICROSAR Safe shall verify that the API function EnableGlobal is called only 
if interrupts are disabled before by call of DisableGlobal. 
SMI-490 
The user of MICROSAR Safe shall verify that the API function EnableLevel is called only if 
interrupts are disabled before by call of DisableLevel.  
SMI-44677 
The user of MICROSAR Safe shall verify that all APIs called in ISRs of category 0 are 
allowed to be called in this context by the AUTOSAR specification or technical reference. 
ISRs of category 0 are transparent to the OS. Therefore the call context „inside category 0 
ISR“ cannot be checked by the API functions. Erroneous calls are not detected. 
SMI-590 
The user of MICROSAR Safe shall verify that all APIs called in ISRs of category 1 are 
allowed to be called in this context by the AUTOSAR specification or technical reference. 
ISRs of category 1 are transparent to the OS. Therefore the call context „inside category 1 
ISR“ cannot be checked by the API functions. Erroneous calls are not detected. 
SMI-44676 
The user of MICROSAR Safe shall verify that all ISRs of category 0 are implemented 
transparent with respect to the processor state (including bits controlled by the user) for 
the interrupted code. This includes core registers, MPU settings and the current interrupt 
priority. 
SMI-541 
The user of MICROSAR Safe shall verify that all ISRs of category 1 are implemented 
transparent with respect to the processor state (including bits controlled by the user) for 
the interrupted code. This includes core registers, MPU settings and the current interrupt 
priority. 
SMI-491 
The user of MICROSAR Safe shall verify the functionality of each configured ISR.  
This includes the correct call of the ISR handler with the correct priority (level) as well as 
enabling, disabling, reading the enable state, reading the pending state and clearing of the 
pending information of the corresponding ISR sources. 
SMI-44675 
2018 Vector Informatik GmbH 
1.0 
58 / 103 

---

Safety Manual CBD1601056 D05 
The user of MICROSAR Safe shall be aware that category 0 ISRs can be interrupted by 
the OS in case of ECC violations. 
In case that ECC violations are handled by the MICROSAR OS, the ProtectionHook is 
called for ECC violations. 
The protection handling can be interrupted by a category 0 ISR. This also applies if the 
protection handling was triggerd by the same category 0 ISR. 
If the protection reaction is terminate Task, ISR or Application the category 0 ISR will be 
terminated by the OS, as well. 
SMI-44678 
The user of MICROSAR Safe shall be aware that category 1 ISRs can be interrupted by 
the OS in case of ECC violations. 
In case that ECC violations are handled by the MICROSAR OS, the ProtectionHook is 
called for ECC violations. 
If the protection reaction is terminate Task, ISR or Application the category 1 ISR will be 
terminated by the OS, as well. 
SMI-44680 
The user of MICROSAR Safe shall be aware that category 0 ISRs can be interrupted by 
the OS in case of exceptions. 
In case that unhandled or handled exceptions are managed by the MICROSAR OS, the 
ProtectionHook is called. 
The protection handling can be interrupted by a category 0 ISR. This also applies if the 
protection handling was triggerd by the same category 0 ISR. 
If the protection reaction is terminate Task, ISR or Application the category 0 ISR will be 
terminated by the OS, as well. 
SMI-44681 
The user of MICROSAR Safe shall be aware that category 0 ISRs cannot be disabled or 
suspended by the OS interrupt APIs. 
The following APIs have no effect on category 0 ISRs: 
o  DisableAllInterrupts 
o  EnableAllInterrupts 
o  SuspendAllInterrupts 
o  ResumeAllInterrupts 
o  SuspendOSInterrupts 
o  ResumeOSInterrupts 
o  Os_DisableLevelAM 
o  Os_EnableLevelAM 
o  Os_DisableLevelKM 
o  Os_EnableLevelKM 
2018 Vector Informatik GmbH 
1.0 
59 / 103 

---

Safety Manual CBD1601056 D05 
o  Os_DisableLevelUM 
o  Os_EnableLevelUM 
o  Os_DisableGlobalAM 
o  Os_EnableGlobalAM 
o  Os_DisableGlobalKM 
o  Os_EnableGlobalKM 
o  Os_DisableGlobalUM 
o  Os_EnableGlobalUM 
17.3.2 Memory mapping and linking 
SMI-340 
The user of MICROSAR Safe shall verify that the complete range specified by each 
Os_PeripheralConfigType object in Os_Peripheral_Lcfg.c is either part of the writable 
address space or that there are no write accesses to that region via the Peripheral API. 
The first writable address is denoted as AddressStart and the last writable address is 
denoted as AddressEnd. 
If the addresses do not fit the intended/configured addresses, illegal write accesses would 
be possible. 
SMI-494 
The user of MICROSAR Safe shall verify for IOC functions that the configured access 
rights and linker configuration allow only valid callers to write the corresponding IOC data. 
SMI-495 
The user of MICROSAR Safe shall ensure by linkage for each optimized spinlock that only 
intended tasks and ISRs have write access to the corresponding spinlock data (or at least 
only tasks and ISRs of partitions with the same ASIL levels). 
The user of MICROSAR Safe shall verify that no unintended task or ISR has access to 
data of optimized spinlocks. 
SMI-539 
The user of MICROSAR Safe shall verify that none of the configured MPU regions allows 
write access to OS variables from non-trusted software. 
SMI-549 
The user of MICROSAR Safe shall verify the linkage of stack sections and MPU 
configuration that none of the configured MPU regions grants write access to any OS 
stack. 
The MPU setting for stacks is internally done by the OS and granting write access might 
prevent from memory protection of stacks. 
2018 Vector Informatik GmbH 
1.0 
60 / 103 

---

Safety Manual CBD1601056 D05 
SMI-1044 
The user of MICROSAR Safe shall verify that additional configured MPU regions shall 
never overlap with any OS stack sections. 
Overlapping MPU regions might provide illegal write access to OS stack sections. By using 
an OS generated linker command file (see technical reference) it is assured that the OS 
stacks are linked consecutively into the RAM. 
SMI-1045 
The user of MICROSAR Safe shall verify that the linkage scheme includes a stack safety 
gap linked adjacent to the stack section (in dependency of the stack growth direction, see 
technical reference). No software parts shall have write access to the stack safety gap. 
This measure enables to detect stack overflows by MPU even if the owner of the stack has 
also write access to data linked adjacent to the stack section. 
SMI-562 
The user of MICROSAR Safe shall verify that all user data are linked into the intended 
sections. 
SMI-564 
The user of MICROSAR Safe shall verify the configuration of access rights to sections. 
Software with lower diagnostic coverage shall not be able to destroy data of software with 
higher diagnostic coverage. This applies to memory access within one core as well as 
memory access across cores. 
See Technical Reference, chapter "Memory Protection" for details. 
Note that OSApplications do not need access to other OS Applications memory. 
SMI-109809 
The user of MICROSAR Safe shall ensure that the whole OS code is linked within OS start 
and end code labels. 
17.3.3 Stack 
SMI-565 
The user of MICROSAR Safe shall ensure that sufficient stack is available for 
call/execution of StartOS. 
StartOS performs some initializations before switching to an internal stack and enabling 
the memory protection. The active stack at call of StartOS shall provide sufficient space to 
execute this code. Because the stack consumtion is depending on compiler and compiler 
options it is recommended to switch to a stack provided by the OS before calling StartOS 
and to use the stack usage measurement API of the OS to determine the necessary stack 
size. 
SMI-4452 
If the attribute /MICROSAR/Os/OsOS/OsGenerateMemMap is equal to 
USERCODE_AND_STACKS_GROUPED_PER_CORE, the user of MICROSAR Safe shall 
2018 Vector Informatik GmbH 
1.0 
61 / 103 

---

Safety Manual CBD1601056 D05 
ensure that all configured stack sizes match the MPU granularity and alignment. Otherwise 
stack protection cannot be ensured. 
17.3.4 Multicore systems with mixed diagnostic coverage capability 
SMI-592 
The user of MICROSAR Safe shall verify that software with higher diagnostic coverage 
does not rely on the results of APIs with lower diagnostic coverage. 
Note that only APIs listed in section "Safety Features" provide functionality on ASIL level.  
SMI-483 
The user of MICROSAR Safe shall ensure that cross core API calls with high frequency 
from cores with lower diagnostic coverage to cores with higher diagnostic coverage do not 
interfere with the requirements. Excessive runtime consumption of cores with lower 
diagnostic coverage shall not prevent cores with higher diagnostic coverage form keeping 
the timing constraints.  
One possible measure is using timing protection. 
SMI-484 
The user of MICROSAR Safe shall ensure that synchronous cross core API calls from a 
core with higher diagnostic coverage to a core with lower diagnostic coverage do not 
violate the safety goals if the API calls never return. 
Synchronous calls block the caller until the return result is received. If for any reason a 
core with lower diagnostic coverage does not return the result or does not return the result 
in time, the caller has to deal with this situation. 
SMI-485 
The user of MICROSAR Safe shall call ShutdownAllCores only on cores with the highest 
diagnostic coverage. 
SMI-486 
The user of MICROSAR Safe shall note that the ShutdownHook might not be called on 
Shutdown for multicore systems with mixed diagnostic coverage capability. 
Errors caused by cores of lower diagnostic coverage (data overwrite) might prevent the 
call of ShutdownHook by cores with higher diagnostic coverage. 
SMI-487 
The user of MICROSAR Safe shall configure and verify that the core with the highest 
diagnostic coverage initializes the peripheral moduls used by the OS (e.g. MPU, Interrupt 
Controller). 
The attribute /MICROSAR/Os/OsOS/OsHardwareInitCore shall be set to the core 
reference with the highest diagnostic coverage. 
The user of MICROSAR Safe shall ensure that if a core with lower diagnostic coverage 
initializes peripherals or hardware components (like e.g. a system MPU), the core with 
higher diagnostic coverage does not rely on this initialization. 
SMI-493 
2018 Vector Informatik GmbH 
1.0 
62 / 103 

---

Safety Manual CBD1601056 D05 
The user of MICROSAR Safe shall verify that the configuration of cross core API calls 
prevents cores with lower diagnostic coverage from shutdown of cores with higher 
diagnostic coverage. 
SMI-25766 
The user of MICROSAR Safe shall ensure that receiver core of cross core API calls is able 
to handle unintended calls of APIs. This applies only to APIs which are allowed to be called 
between two cores by configuration. 
17.3.5 (Non-)Trusted Functions 
SMI-497 
The user of MICROSAR Safe shall verify that if a trusted or non-trusted function uses the 
passed argument, the trusted function validates these data before usage to prevent from 
any violation of safety goals. The caller of CallTrustedFunction or 
Os_CallNonTrustedFunction and therefore the passed data might be non-trusted. 
SMI-542 
The user of MICROSAR Safe shall verify that each caller of a trusted or non-trusted 
function is allowed to call the function, or the function validates the caller before performing 
its functionality to prevent from any violation of safety goals. 
SMI-95699 
The user of MICROSAR Safe shall verify that the caller Task/ISR of each trusted or non-
trusted function which is using FPU, is configured to use the FPU context. 
17.3.6 Miscellaneous 
SMI-480 
The user of MICROSAR Safe shall not rely on the error parameter macros (starting with 
Os_ErrorGetParameter_...). 
They are not assumed as safety features by Vector. 
SMI-481 
The user of MICROSAR Safe shall notify that the PanicHook might not be called if the 
active thread is not allowed to modify the interrupt enable/disable state.  
Before calling the PanicHook the OS disables all interrupts. If this fails, the ProtectionHook 
might be called, caused by the illegal access (depending on hardware platform). 
SMI-492 
The user of MICROSAR Safe shall verify for cross core API calls that for each pair of 
sender/receiver cores at least one API call is tested and verified across these cores. 
SMI-496 
The user of MICROSAR Safe shall verify that calls of the optimized spinlock API don’t 
violate any of the spinlock API constraints (e.g. the order of locking). The optimized 
spinlock API skips any checks and therefore does not prevent from wrong calls. 
SMI-538 
2018 Vector Informatik GmbH 
1.0 
63 / 103 

---

Safety Manual CBD1601056 D05 
The user of MICROSAR Safe shall verify that the context described in the Hardware 
Software Interface (HSI) of the used platform is sufficient for the requirements his 
application. 
SMI-591 
The user of MICROSAR Safe shall verify the correct usage of IOC API functions. Some of 
these functions don’t call the ErrorHook if the called function does not return a valid result. 
It is recommended to check the return code of these functions:  
o  IocSend/IocWrite 
o  IocSendGroup/IocWriteGroup 
o  IocReceive/IocRead 
o  IocReceiveGroup/IocReadGroup 
SMI-109842 
The user of MICROSAR Safe shall be aware that if spinlocks are used by an IOC channel, 
they are not released if the communicating task or ISR is terminated via protection hook. 
The operating system does not guarantee that calls to the IOC API for channels that have 
blocked spinlocks will return. 
Spinlocks in IOC APIs are used e.g. if 
o  An IOC channel is non-queued or 
o  Multiple senders are configured for the same queued channel 
SMI-540 
The user of MICROSAR Safe shall verify that the user software does not contain system 
call instructions. 
Any system call instruction will result in an OS API or in an OS Error. If the user code 
directly uses a system call instruction it is likely that the triggered OS API does not work as 
expected. Instead, system calls shall only be used by using calls to OS APIs. 
A possible verification method might be reviewing the code for (inline) assembler 
statements, pragmas or intrinsic functions containing system call instructions. 
SMI-2900 
The user of MICROSAR Safe shall verify that the array OsCfg_CorePhysicalRefs contains 
all physical cores. 
For each existing physical hardware core identifier there shall be one corresponding entry 
inside the array which is indexed by the physical hardware core identifier provided directly 
by the hardware registers. 
SMI-39288 
The user of MICROSAR Safe shall verify that the array 
OsCfg_Hal_Context_ExceptionContextRef contains all physical cores. 
For each existing physical hardware core identifier, which is also an Autosar core, there 
2018 Vector Informatik GmbH 
1.0 
64 / 103 

---

Safety Manual CBD1601056 D05 
shall be one corresponding entry (not NULL_PTR) inside the array which is indexed by the 
physical hardware core identifier provided directly by the hardware registers. 
SMI-44342 
The user of MICROSAR Safe shall verify that peripheral APIs  
o  Os_ReadPeripheral8Legacy 
o  Os_ReadPeripheral16Legacy 
o  Os_ReadPeripheral32Legacy 
o  Os_WritePeripheral8Legacy 
o  Os_WritePeripheral16Legacy 
o  Os_WritePeripheral32Legacy 
o  Os_ModifyPeripheral8Legacy 
o  Os_ModifyPeripheral16Legacy 
o  Os_ModifyPeripheral32Legacy 
are not used on platforms with address width greater than 32 bits. 
SMI-44679 
The user shall ensure real time behavior of the system, even in case of delayed calls of 
ProtectionHook. 
ProtectionHook may be delayed by the execution of Cat 0 ISRs. 
SMI-109810 
The user of MICROSAR Safe shall be aware that in case that MICROSAR OS detects a 
potentially internal inconsistency, MICROSAR OS enters the PanicHook. 
17.3.7 Tracing 
SMI-69754 
The user of MICROSAR Safe shall be aware that user timing hook implementation 
influences runtime behaviour of the system. 
SMI-69755 
The user of MICROSAR Safe shall not use any OS API within TimingHooks. 
17.4 Safety features required from other components 
This component does not require safety features from other components. 
2018 Vector Informatik GmbH 
1.0 
65 / 103 

---

Safety Manual CBD1601056 D05 
17.5 Dependencies to hardware 
The dependencies of this component to hardware is described in the platform specific part 
of the Safety Manual. 
2018 Vector Informatik GmbH 
1.0 
66 / 103 

---

Safety Manual CBD1601056 D05 
18 Safety Manual OS (RH850) 
18.1 Safety features 
No additional safety features are provided. 
18.2 Configuration constraints 
SMI-3167 
The user of MICROSAR Safe shall enable software stack checks for RH850 derivatives 
which are based on G3K core (e.g. RH850 F1L) in order to ensure stack protection also in 
supervisor mode as monitoring by MPU in supervisor mode is not supported. 
18.3 Additional verification measures 
SMI-3310 
The user of MICROSAR Safe shall verify the PIT timer configuration of type 
Os_Hal_TimerPitConfigType in Os_Hal_Timer_Lcfg.c for its correctness. 
If the OSTM unit <X> (0,1,2,3,5) is configured, the following attributes must be generated 
as follows: 
Timer Base Address = OS_HAL_TIMER_OSTM<X>_BASE 
Timer Hardware Type = OS_HAL_TIMER_OSTM 
Timer Channel Index = OS_HAL_TIMER_CH0 
If the TAUJ unit <X> (0,1,2,3) channel <Y> (0,1,2,3) is configured, the following attributes 
must be generated as follows: 
Timer Base Address = OS_HAL_TIMER_TAUJ<X>_BASE 
Timer Hardware Type = OS_HAL_TIMER_TAUJ 
Timer Channel Index = OS_HAL_TIMER_CH<Y> 
SMI-3311 
The user of MICROSAR Safe shall verify the FRT timer configuration of type 
Os_Hal_TimerFrtConfigType in Os_Hal_Timer_Lcfg.c for its correctness. 
If the OSTM unit <X> (0,1,2,3,5) is configured, the following attributes must be generated 
as follows: 
Timer Base Address = OS_HAL_TIMER_OSTM<X>_BASE 
Timer Hardware Type = OS_HAL_TIMER_OSTM 
Timer Channel Index = OS_HAL_TIMER_CH0 
Timer Unit Index = OS_HAL_TIMER_OSTM<X> 
If the STM unit <X> (0,1) channel <Y> (1,2,3) is configured, the following attributes must 
be generated as follows: 
Timer Base Address = OS_HAL_TIMER_STM<X>_BASE 
Timer Hardware Type = OS_HAL_TIMER_STM 
Timer Channel Index = OS_HAL_TIMER_CH<Y> 
Timer Unit Index = OS_HAL_TIMER_STM<X> 
2018 Vector Informatik GmbH 
1.0 
67 / 103 

---

Safety Manual CBD1601056 D05 
18.4 Safety features required from other components 
No additional safety features are required from other components. 
18.5 Dependencies to hardware 
The following Safety Applications Notes (SAN) have been taken into consideration: 
o  RH850/P1M Safety Application Note R01AN2118EJ0300 Rev.3.00 Mar 29, 2017 
o  RH850/F1L Safety Application Note R01AN2152EJ0211 Rev.2.11 October 17, 2016 
o  RH850/F1H Safety Application Note R01AN2886EJ0110 Rev.1.10 July 27, 2016 
o  RH850/F1K Safety Application Note R01AN3578EJ0100 Rev.1.00 Dec 22, 2016 
o  RH850/D1L/D1M Safety Application Note LLWEB-10000950 Rev.2.00 Dec 1, 2016 
This OS does not implement any recommended usage from safety application notes 
except for the memory protecion unit (SAN-P1x-0405, SAN-F1L-2201, SAN-F1H-2201, 
SAN-F1K2M-0190, SAN-D1x-1801). This implementation does not cover a software test 
procedure at startup to confirm the operation of the MPU as described by SAN-F1L-2201, 
SAN-F1H-2201, SAN-F1K2M-0190 and SAN-D1x-1801. 
It is assumed that the recommended usage related to OS functionality are related to latent 
faults only and ASIL D is still achievable without implementation of the recommended 
usage by the OS. Such implementation would cause significant runtime overhead. 
SMI-3168 
The user of MICROSAR Safe has to consider DMA controller usage if the used RH850 
derivative incorporates a DMA controller (DMAC). 
The DMA controller has direct access to the data bus. Therefore DMA access to memory 
is not controlled by MPU protection. 
2018 Vector Informatik GmbH 
1.0 
68 / 103 

---

Safety Manual CBD1601056 D05 
19 Safety Manual PduR 
19.1 Safety features 
This component does not provide safety features. 
19.2 Configuration constraints 
The user of MICROSAR Safe shall configure the following parameters: 
o  /MICROSAR/PduR/PduRGeneral/PduR_QueueOverflowNotification to FALSE 
This setting is enforced by a MSSV plugin. 
19.3 Additional verification measures 
This component does not require additional verification measures. 
19.4 Safety features required from other components 
This component does not require safety features from other components. 
19.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
69 / 103 

---

Safety Manual CBD1601056 D05 
20 Safety Manual Rte 
20.1 Safety features 
SMI-323 
This component provides the following safety features: 
ID  
Safety feature  
CREQ-
Rte shall provide a service to initiate the transmission of data elements with last-is-best 
1024  
semantic for explicit S/R communication.  
CREQ-
Rte shall provide a service to copy the received data element to a buffer with last-is-
1021  
best semantic for explicit S/R communication.  
CREQ-
Rte shall provide a service to get the value of the received data element with last-is-
1022  
best semantic for explicit S/R communication.  
CREQ-
Rte shall provide a service to read a data element for implicit S/R communication.  
1031  
CREQ-
Rte shall provide a service to write a data element for implicit S/R communication.  
1029  
CREQ-
Rte shall provide a service to get the reference of a data element to be written for 
1041  
implicit S/R communication.  
CREQ-
Rte shall provide a service to get the status of a data element for implicit S/R 
1037  
communication.  
CREQ-
Rte shall provide a service to access the update flag for a data element for explicit S/R 
1033  
communication.  
CREQ-
Rte shall provide a "Never-received" status of a data element for S/R communication.  
1036  
CREQ-
Rte shall provide a service to initiate the transmission of a data element with queued 
1023  
semantic for explicit S/R communication.  
CREQ-
Rte shall provide a service to initiate the reception of a data element with queued 
1025  
semantic for explicit S/R communication.  
CREQ-
Rte shall provide a service to initiate a client-server communication.  
1042  
CREQ-
Rte shall provide a service to get the result of an asynchronous client-server call.  
1043  
CREQ-
Rte shall provide mode management.  
1109  
CREQ-
Rte shall provide a service to get the currently active mode.  
1055  
CREQ-
Rte shall provide a service to get the currently active, previous and next mode.  
1052  
CREQ-
Rte shall provide a service to initiate a mode switch.  
1053  
CREQ-
Rte shall provide Nv data communication.  
1299  
CREQ-
Rte shall provide a callback to copy data from a NVM buffer to RTE.  
2018 Vector Informatik GmbH 
1.0 
70 / 103 

---

Safety Manual CBD1601056 D05 
1150  
CREQ-
Rte shall provide a callback to copy data from RTE to a NVM buffer.  
1148  
CREQ-
Rte shall provide a callback to get notified about a finished NVM job.  
1144  
CREQ-
Rte shall provide a callback to get notified about a requested mirror initialization.  
1147  
CREQ-
Rte shall provide a service to read Inter-Runnable Variables with explicit behavior.  
1046  
CREQ-
Rte shall provide a service to write Inter-Runnable Variables with explicit behavior.  
1048  
CREQ-
Rte shall provide a service to read Inter-Runnable Variables with implicit behavior.  
1047  
CREQ-
Rte shall provide a service to write Inter-Runnable Variables with implicit behavior.  
1044  
CREQ-
Rte shall provide a service to access per-instance memory.  
1045  
CREQ-
Rte shall provide a service to enter an exclusive area.  
1051  
CREQ-
Rte shall provide a service to leave an exclusive area.  
1050  
CREQ-
Rte's Basic Software Scheduler shall provide a service to enter an exclusive area of a 
1056  
BSW Module.  
CREQ-
Rte's Basic Software Scheduler shall provide a service to leave an exclusive area of a 
1049  
BSW Module.  
CREQ-
Rte shall provide a service to access internal calibration parameters.  
1068  
CREQ-
Rte shall provide a service to access calibration parameters accessible via ports.  
1075  
CREQ-
Rte shall provide a service to initialize itself.  
1059  
CREQ-
Rte's Basic Software Scheduler shall provide a service to initialize itself.  
1073  
CREQ-
Rte shall provide a service to trigger executable entities.  
1161  
CREQ-
Rte shall use schedule points to invoke the scheduler of the OS.  
1165  
CREQ-
Rte shall provide the event handling of TimingEvents to trigger a runnable.  
1129  
CREQ-
Rte shall provide the event handling of SwcModeSwitchEvents to trigger a runnable.  
1112  
CREQ-
Rte shall provide the event handling of AsynchronousServerCallReturnsEvents to 
1124  
trigger a runnable.  
CREQ-
Rte shall provide the event handling of OperationInvokedEvents to trigger a runnable.  
1126  
2018 Vector Informatik GmbH 
1.0 
71 / 103 

---

Safety Manual CBD1601056 D05 
CREQ-
Rte shall provide the event handling of DataReceivedEvents to trigger a runnable.  
1118  
CREQ-
Rte shall provide the event handling of ModeSwitchedAckEvents to trigger a runnable.  
1132  
CREQ-
Rte shall provide the event handling of the InitEvents to trigger a runnable.  
1114  
CREQ-
Rte shall provide the event handling of TimingEvents to trigger a schedulable entity.  
1295  
CREQ-
Rte shall provide a "RTE_AND_SCHM_UNINIT" state.  
1152  
CREQ-
Rte shall provide a "RTE_UNINT_SCHM_INIT" state.  
1164  
CREQ-
Rte shall provide a "INIT" state.  
1166  
 
20.2 Configuration constraints 
SMI-2066 
The user of MICROSAR Safe shall disable online calibration and measurement 
during series production. 
The RTE can be generated with online calibration and measurement enabled for series 
production, but they shall be made inoperable for normal operation. Vector's XCP can e.g. 
be disabled safely during runtime by ASIL software. 
20.3 Additional verification measures 
Please note that the RTE Generator and RTE Analyzer only implement measures to detect 
systematic faults by the software. No measures are implemented to detect or mitigate 
random faults on the computer used for generation. 
SMI-322 
The user of MICROSAR Safe shall execute the RTE Analyzer. 
The RTE Analyzer performs checks to identify faults in the generated RTE. Especially out-
of-bounds accesses within the RTE are detected. If RTE Analyzer reports a fault, the 
generated RTE cannot be used. Moreover it provides the user of MICROSAR Safe with 
feedback what was generated. This feedback shall be reviewed during integration testing 
against the intended software design and its configuration. 
Please see the Technical Reference of the RTE Analyzer how to execute it. 
SMI-36067 
The user of MICROSAR Safe shall ensure that the RTE Analyzer does not report 
unsupported templates. 
2018 Vector Informatik GmbH 
1.0 
72 / 103 

---

Safety Manual CBD1601056 D05 
The generated RTE code is based on templates. The templates are instantiated by the 
RTE Generator in different variants. The RTE Analyzer verifies that the analyzed template 
variants have been tested during the development of the RTE Generator according to ISO 
26262. 
The last section of the RTE Analyzer configuration feedback report provides the 
information about the template variants. 
The report must show that no unsupported templates have been found. 
20.3.1 Guided integration testing 
Residual faults in the RTE Generator can only be found during integration testing. Vector 
assumes that the user of MICROSAR Safe performs an integration testing and verification 
of software safety requirements according to ISO 26262 Part 6 Clauses 10 and 11 (see 
also SMI-4). To support this integration testing the RTE Analyzer produces a configuration 
feedback report.  
Please refer to the Technical Reference of the RTE Analyzer for a description of the 
configuration feedback report. 
The following subsections describe the requirements that must be fulfilled during 
integration testing and verification of software safety requirements. 
Each Safety Manual Item (SMI) is structured in the following way: 
o  The requirement that must be fulfilled 
o  Explanation of the requirement and a rationale 
o  Recommended configuration constraints (optional) 
o  Recommended means of complying with the requirement (optional) 
o  Details on the information provided by the RTE Analyzer supporting this 
requirement 
20.3.1.1 BSW configuration 
SMI-2124 
The user of MICROSAR Safe shall ensure that the RTE and the operating system 
assume the same scheduling properties. 
The scheduling properties of the RTE tasks depend on the configuration of the operating 
system. The scheduling properties are e.g. preemptability, core assignment or task priority. 
The RTE Analyzer lists the scheduling properties in the configuration feedback report to 
assist in this integration step. The scheduling properties listed in the feedback report shall 
be verified. 
SMI-2129 
2018 Vector Informatik GmbH 
1.0 
73 / 103 

---

Safety Manual CBD1601056 D05 
The user of MICROSAR Safe shall ensure that the assumptions of the operating 
system and the RTE are the same with regards to the locking behavior of the 
spinlocks. 
The RTE generator uses spinlocks from the operating system to protect inter-core 
communication. Spinlocks must not be called concurrently on the same core. The 
operating system optionally provides spinlocks that can prevent these concurrent 
accesses on the same core. If this protection by the operating system is not used, the RTE 
generator has to prevent concurrent calls to the spinlock APIs on the same core.  
Verification can e.g. be performed by review of the configuration feedback report. 
The RTE Analyzer lists spinlocks that are not protected by the RTE to assist in this 
integration step. 
SMI-684 
The user of MICROSAR Safe shall ensure that the configuration of COM and RTE are 
consistent. 
The interfaces to the COM that are used for signal reception use void pointers as 
parameter. Inconsistencies between the configuration of the COM and the RTE might lead 
to memory corruption by the COM. During integration the size assumptions between the 
COM and the RTE shall be compared.  
Verification can be performed by review of the generated configuration and/or static code 
analysis. 
The RTE Analyzer lists relevant calls to assist in this integration step. 
The RTE Analyzer listing includes the number of written bytes for MICROSAR COM. 
SMI-685 
The user of MICROSAR Safe shall ensure that the configuration of NVM and RTE are 
consistent. 
The interfaces to the NVM that are used to handle NV Block SWCs use void pointers as 
parameters. Inconsistencies between the configuration of the NVM and the RTE might 
lead to memory corruption by the RTE. During integration the size assumptions between 
the NVM and the RTE shall be compared.  
Verification can be performed by review of the generated configuration and/or static code 
analysis. 
The RTE Analyzer lists relevant calls to assist in this integration step. 
20.3.1.2 Executable Entity Scheduling 
SMI-2063 
The user of MICROSAR Safe shall ensure that all safety-related executable entities 
are triggered with their correct conditions. 
These conditions are: 
2018 Vector Informatik GmbH 
1.0 
74 / 103 

---

Safety Manual CBD1601056 D05 
o  cylic triggers with cycle time and offset 
o  init triggers 
o  background triggers 
o  triggers fired by RTE APIs 
If triggers have a dependency on modes, the scheduling has to be verified for all modes. 
Modes can be switched with the Rte_Switch API. 
Triggers can be decoupled by the minimum start interval functionality and the data 
reception filter functionality. 
The scheduling of the executable entities also depends on the configuration of the 
operating system, the used controller, other running tasks and interrupt service routines 
and the resource usage of the entities that are implemented by the user. 
Vector recommends not using the minimum start interval and the data reception filter 
functionality for safety-related runnables. 
Vector recommends not using background triggers for safety-related functionality. 
Vector recommends using cyclic scheduling without mode dependencies and using of a 
watchdog as safety mechanism for safety-related entities where possible. 
Cyclic triggers are e.g. scheduled deterministically. Thus, an integration test verifying that 
safety-related functionality is scheduled at the expected times may be sufficient. 
The RTE Analyzer lists the executable entities of SWCs and the tasks in which they are 
executed to assist in this integration step.  
SMI-2128 
The user of MICROSAR Safe shall ensure that reentrant runnables are reentrant. 
Runnables can be called reentrantly from multiple tasks. Their implementation needs to 
support this use case.  
Verification can e.g. be performed by review, static code analysis and/or integration 
testing. 
The RTE Analyzer lists all runnables of SWCs that are called from concurrent tasks to 
assist in this integration step. 
Implicit exclusive areas and nonpreemptive tasks can be configured to prevent concurrent 
execution. 
SMI-2064 
The user of MICROSAR Safe shall ensure that the timeouts configured for blocking 
APIs that are used in safety-related executable entities are adequately addressed. 
If a timeout for a blocking API is used as a safety mechanism (E.g. no checkpoint with 
deadline monitoring in the task), the user of MICROSAR Safe shall also ensure that the 
timeout value is adequate. 
Relevant timeouts are: 
2018 Vector Informatik GmbH 
1.0 
75 / 103 

---

Safety Manual CBD1601056 D05 
o  timeouts of Rte_Call APIs 
o  timeouts of Rte_Result APIs 
o  timeouts of Rte_Receive APIs 
o  timeouts of Rte_Feedback APIs 
o  timeouts of Rte_SwitchAck APIs 
The timeouts also depend on the configuration of the operating system, the used 
controller, other running tasks and interrupt service routines and the resource usage of 
entities that are implemented by the user. 
Vector recommends not using blocking APIs in safety-related entities except for cross 
partition client-/server communication. 
Vector strongly recommends not using blocking APIs without timeout. 
A review may be sufficient to verify that timeout handling is implemented properly by the 
SWC. 
If no other safety mechanism is in place, a test that the timeout is notified at the expected 
time by the RTE can be used as means of verification. 
The RTE Analyzer lists the blocking APIs of SWCs to assist in this integration step. 
SMI-2122 
The user of MICROSAR Safe shall ensure that the correct implementation method 
has been chosen for every exclusive area. 
Exclusive areas can be used to ensure data consistency (see SMI-11). 
The implementation depends on the requirements of the application and on other factors 
like the expected duration of the exclusive area. Interrupt locks are typically faster than 
resources but can only be used for short sequences due to the blocking of interrupts. 
Operating system interrupts only block the interrupts of the operating system whereas all 
interrupts blocks all interrupts. 
Verification can e.g. be performed by review, static code analysis and/or integration 
testing. 
The RTE Analyzer lists the exclusive areas and their implementation method to assist in 
this integration step. 
20.3.1.3 SWC Communication 
SMI-41492 
The user of MICROSAR SafeBRE shall provide the RTE APIs for systems without 
RTE. 
MICROSAR Basic Runtime Environment (BRE) only provides the BSW scheduler 
functionality of the RTE and does not support application SWCs. The implementation of 
the interface from the application to BSW modules must be developed according to ISO 
2018 Vector Informatik GmbH 
1.0 
76 / 103 

---

Safety Manual CBD1601056 D05 
26262. The Technical References of the BSW modules as well as the AUTOSAR standard 
define the semantics and APIs that will have to be implemented while integrating the BRE. 
The RTE Analyzer does not assist in this integration step. 
SMI-324, SMI-2065 and SMI-2123 do not apply to MICROSAR SafeBRE. 
SMI-324 
The user of MICROSAR Safe shall ensure that the connections between SWCs are 
as intended. 
Many types of faults can lead to a mix of connections between SWCs. These are unlikely 
and usually already addressed by straight forward integration testing. 
The list of senders needs to be correct for every receiver and the subset of the received 
data needs to be correct. 
Vector recommends the following RTE subset for safety-related SWCs: 
o  use only 1:1 or 1:N connections. 
o  use the same datatype on both sides of a connection 
o  avoid data conversion 
Information that is used from non-safety-related SWCs has to be checked for plausibility. If 
such a data path is found during integration this is an indicator that your safety analysis 
has to be reconsidered. Please note that also other code in the same partition as the non-
safety-related SWCs can corrupt the communication if freedom from interference with 
regards to memory is not ensured. 
Verification can be performed by review and/or an integration test testing the normal 
operation. 
The RTE Analyzer list the connections between SWCs to assist in this integration step. 
SMI-2065 
The user of MICROSAR Safe shall ensure that inter-ECU sender-/receiver and inter-
ECU client-/server communication work as expected. 
This requires verification of: 
o  data needs to be routed to the correct ECU by the underlying communication stack. 
This includes 1:1, 1:N, N:1 and reception of partial signal data. 
o  both ECUs need to use the same data representation (datatypes, endianness, 
serialization) 
Vector requires using E2E protection for safety-related signals. 
Vector recommends using 1:1 connections. 
Vector recommends always sending and receiving complete data elements. 
2018 Vector Informatik GmbH 
1.0 
77 / 103 

---

Safety Manual CBD1601056 D05 
Integration testing on vehicle network level using fault-injection can be used. Vector 
assumes that this is normally done to verify the effectiveness of the E2E protection. 
The RTE Analyzer lists the APIs of SWCs with inter-ECU communication to assist in this 
integration step. 
SMI-2123 
The user of MICROSAR Safe shall ensure that all connected SWCs expect the same 
converted data. 
The RTE offers conversions that can be applied to specific connections. 
Vector recommends not using data conversion for safety-related connections. 
Verification can e.g. be performed by review or integration testing of all data conversions. 
The RTE Analyzer lists all APIs of SWCs that perform data conversion to assist in this 
integration step. 
20.3.1.4 Usage of RTE Headers 
SMI-2067 
The user of MICROSAR Safe shall ensure that the defines and typedefs that are 
generated by the RTE match the expectations of the SWCs that use them. 
Inconsistencies may lead to e.g, memory corruption when a runnable uses an RTE array 
datatype within its implementation and writes beyond the bounds of this array. 
Moreover, different SWCs may have different assumptions with regards to the meaning of 
communicated values, e.g. if one SWC uses the symbolic name, another SWC the integral 
value of an enumerated type. 
The following code is provided: 
o  Configured Application Error Defines for Client-/Server Communication 
o  Configured AUTOSAR Datatypes 
o  Configured Upper and Lower Limit Defines for Primitive Application Data Types 
o  Configured Init Value Defines for Sender-/Receiver Communication 
o  Configured InvalidValue Defines for Sender-/Receiver Communication 
o  Configured Enumeration Defines for CompuMethods 
o  Configured Mask Defines for CompuMethods 
o  Configured Mode Defines for Mode Communication 
o  Configured ActivationReasons 
2018 Vector Informatik GmbH 
1.0 
78 / 103 

---

Safety Manual CBD1601056 D05 
The defines and typedefs are part of the Rte_Type.h, Rte_<SWC>.h and 
Rte_<SWC>_Type.h headers. 
Vector recommends using the headers generated by the RTE when a static code analysis 
is performed on the application code. 
Vector recommends only using the defines instead of the defined values in the code. 
Vector recommends using the defines only when needed (Mode, Application Error 
Defines). 
Vector recommends reviewing the used defines for safety-related SWCs. 
Vector recommends not using union types in the SWCs. 
Verification for correct usage of datatypes may be performed by review and/or static code 
analysis. Consistent usage of defines can be verified by review and/or integration testing 
with all used values. 
The RTE Analyzer verifies that all accesses within the RTE do not lead to memory 
corruption. 
SMI-2071 
The user of MICROSAR Safe shall ensure that the indirect API is used consistently. 
Indirect API functionality consists of the APIs: 
o  Rte_Port 
o  Rte_Ports 
o  Rte_NPorts 
The indirect API makes it possible to call different APIs through an array access. The 
indirect API functionality can be enabled individually per port. 
A wrong configuration switch can easily lead to a call outside of the array returned by the 
Rte_Ports API. 
Vector recommends not using the indirect API. 
Verification can e.g. be performed by review that the intended APIs are returned. 
The RTE Analyzer does not assist in this integration step. 
20.3.1.5 Usage of RTE APIs 
SMI-2072 
The user of MICROSAR Safe shall ensure that the RTE and all of its users have the 
same assumptions with regards to the sizes of the datatypes. 
The RTE supports the configuration of custom datatypes for its APIs. The RTE 
specification mandates that arrays are passed as pointer to the array base type. 
The RTE does not enforce that both sides of a connection use arrays of the same size. 
2018 Vector Informatik GmbH 
1.0 
79 / 103 

---

Safety Manual CBD1601056 D05 
No NULL pointers or invalid pointers shall be passed to RTE APIs. 
The object to which the pointer points needs to have at least the size of the pointer base 
type. 
Vector recommends using the headers generated by the RTE when static code analysis is 
performed on the application code. 
Vector recommends using the same datatypes on both sides of a connection. 
Arrays and void pointers on interfaces where the called function writes to them are 
considered especially relevant. 
Verification can e.g. be performed by review and/or static code analysis. 
The RTE Analyzer lists APIs and runnables that use such parameters to assist in this 
integration step. 
SMI-2073 
The user of MICROSAR Safe shall ensure that RTE APIs are only called from their 
configured contexts. 
Fast response times are crucial in embedded systems. Therefore, the RTE generator 
analyzes the call contexts of all APIs in order to optimize away unneeded interrupt locks. 
When the application calls the APIs from a different context than the RTE assumes, data 
consistency problems may arise. 
In systems with ASIL partitions, the RTE generator uses a conservative locking strategy. 
Locks are only optimized away if all accesses are done within the same task. 
Verification can e.g. be performed by review and/or static code analysis. 
The RTE Analyzer lists the optimized APIs of SWCs to assist in this integration step. 
The RTE Analyzer lists APIs that must not be called by the application because they are 
considered unreachable due to the RTE configuration. 
20.3.1.6 Configuration of RTE APIs 
SMI-2074 
The user of MICROSAR Safe shall ensure that the receivers can handle the initial 
value provided by the RTE if no write or calibration occurred. 
For implicit accesses the user of MICROSAR Safe shall assure that the correct initial value 
is sent when Rte_IWrite or Rte_IWriteRef were not called in the runnable. 
Initial values can be configured for: 
o  non-queued sender-/receiver communication 
o  inter-runnable variables 
o  mode ports  
o  calibration parameters  
2018 Vector Informatik GmbH 
1.0 
80 / 103 

---

Safety Manual CBD1601056 D05 
The initial value is returned when no sending API was called before the first read or no 
calibration was performed before the first read. The initial values depend on the connected 
components. 
Vector recommends using the same initial value on all port data elements that are 
connected with each other. 
The RTE Analyzer lists all APIs of SWCs that may provide an initial value to assist in this 
integration step. If possible, the RTE Analyzer reports the initial value generated by the 
RTE into the configuration feedback report. 
SMI-2075 
The user of MICROSAR Safe shall ensure that the alive timeout by the COM is not 
used for safety-related inter-ECU sender/receiver communication. 
Safety-related communication must be protected by E2E protection. The decision if new 
data is available (alive) can only be made by the E2E mechanism. Data is not interpreted 
by the COM. For example the sending ECU might repeat old data. This is only detected by 
the cycle counter that is part of the E2E protection. 
The RTE Analyzer lists the reading APIs that provide the alive timeout status to assist in 
this integration step. 
SMI-2126 
The user of MICROSAR Safe shall ensure that SWCs handle the RTE_E_INVALID 
return code properly. 
The RTE offers a functionality to invalidate signals. 
Vector requires using end-to-end protection for safety-related inter-ECU communication. 
Relying on the invalidation mechanism for safety-related signals is not an option. The user 
of MICROSAR Safe shall not use invalidation for inter-ECU communication. 
Verification can e.g. be performed by review and/or integration testing. 
The RTE Analyzer lists RTE APIs that return the RTE_E_INVALID return code to assist in 
this integration step. 
SMI-2127 
The user of MICROSAR Safe shall ensure that SWCs handle the 
RTE_E_NEVER_RECEIVED return code properly. 
The RTE offers a functionality to report if a signals was received after the ECU was 
started. 
Vector requires using end-to-end protection for safety-related signals. Relying on the never 
received mechanism for safety-related signals is not an option. Especially, when using the 
E2E transformer, its return value shall be evaluated. 
Verification can e.g. be performed by review or integration testing. 
2018 Vector Informatik GmbH 
1.0 
81 / 103 

---

Safety Manual CBD1601056 D05 
The RTE Analyzer lists RTE APIs that return the RTE_E_NEVER_RECEIVED return code 
to assist in this integration step. 
SMI-2125 
The user of MICROSAR Safe shall ensure that the queue sizes that were chosen 
during the configuration are sufficient for the integrated system. 
The RTE uses queues for mode communication, sender-/receiver communication and 
mapped client-/server communication. The queue sizes depend on the scheduling of 
entities and the call sequences of the APIs. 
Vector recommends not using APIs with queues for safety-related functionality. 
Verification can e.g. be performed by stress testing. 
The RTE Analyzer lists the queue sizes to assist in this integration step. 
SMI-36068 
The user of MICROSAR Safe shall ensure that all connections with end-to-end (E2E) 
protection are generated. 
The RTE Analyzer lists RTE APIs that read or write end-to-end protected data (see SMI-
98). 
20.4 Safety features required from other components 
SMI-2121 
RTE requires the following functionality as safety feature from the operating system: 
o  Interrupt enabling/disabling 
o  Resource handling 
o  Inter OS Application Communicator (IOC) sending and receiving functionality 
o  Spin-lock functionality 
o  Alarm handling 
o  Schedule table handling 
o  Activation of tasks 
o  Event handling 
This requirement is fulfilled if an ASIL operating system by Vector is used. 
SMI-2978 
RTE requires the following functionality as safety feature from the NvM: 
o  Reading blocks 
2018 Vector Informatik GmbH 
1.0 
82 / 103 

---

Safety Manual CBD1601056 D05 
o  Writing blocks 
This requirement is fulfilled if an ASIL NvM by Vector is used. 
20.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
83 / 103 

---

Safety Manual CBD1601056 D05 
21 Safety Manual WdgIf 
21.1 Safety features 
SMI-519 
This component provides the following safety features: 
ID  
Safety feature  
CREQ-
WdgIf shall provide a service to set the mode of a watchdog device 
107414  
CREQ-
WdgIf shall provide a service to set the trigger condition for a watchdog device 
107415  
CREQ-
WdgIf shall support a mechanism to combine statuses of different cores and handle 
107416  
one watchdog for different cores 
 
21.2 Configuration constraints 
SMI-522 
If a state combiner is used, the user of MICROSAR Safe shall configure  
o  WdgIfStateCombinerSpinlockID and 
o  WdgIfStateCombinerStartUpSyncCycles 
for each core that is used by the state combiner. 
SMI-523 
If a state combiner is used and WdgIfStateCombinerStartUpSyncCycles is set to a value s, 
the user of MICROSAR Safe shall consider that for the first s SupervisionCycles of the 
master, the master does not monitor the slave triggers. 
However, reset requests from a slave within the first s SupervisionCycles, are escalated by 
the master with the next call of the master’s WdgM_MainFunction(). 
21.3 Additional verification measures 
SMI-525 
The user of MICROSAR Safe shall verify that the output path of the generator is empty 
before the generator is started. 
The output path can be defined by the command line argument OUTPUT-DIRECTORY. 
SMI-526 
The user of MICROSAR Safe shall inspect the messages of the generator execution. 
If the generator aborts the generation process with an error message, the (partially) 
generated output files shall not be used in the system. 
If the generator detects an error, a message starting with "ERROR" is displayed on the 
standard output. 
If the generator shows a warning message starting with "WARNING", the user of 
2018 Vector Informatik GmbH 
1.0 
84 / 103 

---

Safety Manual CBD1601056 D05 
MICROSAR Safe shall ensure that the cause of the warning does not invalidate the 
generated output files. 
SMI-527 
The user of MICROSAR Safe shall verify that the following preprocessor directives are 
defined with the correct value independent from whether a state combiner is configured or 
not: 
Preprocessor Directive  
Value  
WDGIF_VERSION_INFO_API 
STD_ON if WdgIfVersionInfoApi is TRUE, otherwise 
STD_OFF. 
WDGIF_USE_AUTOSAR_DRV_API 
STD_ON 
WDGIF_DEV_ERROR_DETECT 
STD_ON if WdgIfDevErrorDetect is TRUE, otherwise 
STD_OFF. 
WDGIF_INTERNAL_TICK_COUNTER  STD_OFF 
WDGIF_USE_STATECOMBINER 
STD_ON if WdgIfUseStateCombiner is TRUE, otherwise 
STD_OFF. 
The defines can be found in WdgIf_Cfg_Features.h. 
SMI-528 
The user of MICROSAR Safe shall verify that the following preprocessor directives are 
defined with the correct value only if a state combiner is configured: 
Preprocessor Directive  
Value  
WDGIF_STATECOMBINER_USE_OS_SPIN_LOCK  STD_ON if 
WdgIfStateCombinerUseOsSpinlock is 
TRUE, otherwise STD_OFF. 
WDGIF_STATECOMBINER_MANUAL_MODE 
STD_ON if 
WdgIfStateCombinerUseManualMode is 
TRUE, otherwise STD_OFF. 
The defines can be found in WdgIf_Cfg_Features.h. 
SMI-529 
The user of MICROSAR Safe shall verify that the following preprocessor directives are 
defined with the correct value independent from whether a state combiner is configured or 
not: 
Preprocessor Directive  
Value  
WDGIF_NUMBER_OF_WDGIFDEVICES 
The number of configured WD Interface Devices. 
The define can be found in WdgIf_LCfg.h. 
SMI-530 
The user of MICROSAR Safe shall verify that the following preprocessor directives are 
defined with the correct value only if a state combiner is configured: 
Preprocessor Directive  
Value  
WDGIF_NUMBER_OF_SLAVES  The configured number of slave cores. Cores that are not 
attached to a State Combiner (i.e. they run independent from 
2018 Vector Informatik GmbH 
1.0 
85 / 103 

---

Safety Manual CBD1601056 D05 
other cores) do not count as slave. 
The define can be found in WdgIf_LCfg.h. 
SMI-531 
The user of MICROSAR Safe shall verify that the C-struct const WdgIf_InterfaceType 
WdgIf_Interface is defined in WdgIf_LCfg.c. 
WdgIf_Interface shall contain the following fields: 
Field   Value  
Description  
1st  
WDGIF_NUMBER_OF_WDGIFDEVICES  The number of WD Interface Devices. 
2nd   WdgIf_FunctionsPerWdg 
A reference to the list of WD Interface Devices. 
If a state combiner is configured, WdgIf_Interface shall also contain the following fields:  
Field   Value  
Description  
3rd  
&wdgif_statecombiner_common_config  A reference to the state combiner data structure. 
4th  
wdgif_statecombiner_manual_config 
In case of manual mode. 
 
SMI-532 
The user of MICROSAR Safe shall verify that the array static const 
WdgIf_InterfaceFunctionsPerWdgDeviceType WdgIf_FunctionsPerWdg 
[WDGIF_NUMBER_OF_WDGIFDEVICES] is defined in WdgIf_LCfg.c. 
WdgIf_FunctionsPerWdg shall refer all – and only - the WD Interface Devices that are 
configured in the EDF. 
WdgIf_FunctionsPerWdg[i] shall refer the underlying WD Interface Device in the EDF with 
WdgIfDeviceIndex = i. 
The fields in an array element in WdgIf_FunctionsPerWdg shall be set as follows: 
Field   Value  
Description  
1st  
&device_functions  If the underlying WD Interface Device is directly linked to a WD driver 
for device, then the field refers to the C-struct device_functions. 
1st  
NULL_PTR  
If the underlying WD Interface Device shares the WD driver with other 
WD Interface Devices using a state combiner, then the linked WD 
device is referred in wdgif_statecombiner_common_config. 
If a state combiner is configured, an array element in WdgIf_FunctionsPerWdg shall also 
contain the following field:  
Field   Value  
Description  
2nd   WdgInstance  A number that uniquely identifies the WD Interface Device instance for the 
underlying platform. All instances on the same platform are numbered 
consecutively starting with 0. Example: One platform has instances A and B, 
another platform has instances C and D. Then A, B, C, and D have 
WdgInstance set (in this order) as: 0,1,0,1. 
 
SMI-533 
2018 Vector Informatik GmbH 
1.0 
86 / 103 

---

Safety Manual CBD1601056 D05 
If a state combiner is configured, the user of MICROSAR Safe shall verify that the array 
static const WdgIf_StateCombinerCommonConfigType 
wdgif_statecombiner_common_config is defined in WdgIf_LCfg.c. 
The fields in wdgif_statecombiner_common_config shall be set as follows: 
Field   Value  
Description  
1st  
WDGIF_NUMBER_OF_SLAVES 
The number of configured slaves. 
2nd   WdgIfStateCombinerSpinlockID 
The value of field 
WdgIfStateCombinerSpinlockID in the EDF. 
3rd  
WdgIfStateCombinerStartUpSyncCycles  The value of field 
WdgIfStateCombinerStartUpSyncCycles in the 
EDF. 
4th  
&device_functions 
A reference to the WD driver API functions for 
device. 
5th  
wdgif_statecombiner_shared_memory 
A reference to the shared memory for the state 
combiners of the Watchdog Interfaces. 
 
SMI-534 
If a state combiner is configured, the user of MICROSAR Safe shall verify that the array 
WdgIf_StateCombinerSharedMemory wdgif_statecombiner_shared_memory 
[WDGIF_NUMBER_OF_SLAVES] is defined in WdgIf_LCfg.c. 
The WdgIf writes to this array, hence it is not const. 
wdgif_statecombiner_shared_memory shall contain one array element for each configured 
slave and the fields in the element shall be set as shown in the following table: 
Field  
Value  
Description  
1st  
0u 
Initial value for the slave’s WindowStart. 
2nd  
(uint16)~0u 
Inverse initial value for the slave’s WindowStart. 
3rd  
0u 
Initial value for the slave’s Timeout. 
4th  
(uint16)~0u 
Inverse initial value for the slave’s Timeout. 
5th  
0u 
Initial value for the slave’s counter. 
6th  
(uint16)~0u 
Inverse initial value for the slave’s counter. 
 
SMI-535 
If the state combiner is configured in manual mode, the user of MICROSAR Safe shall 
verify that the array static const WdgIf_StateCombinerManualConfigType* 
wdgif_statecombiner_manual_config [WDGIF_NUMBER_OF_SLAVES] is defined in 
WdgIf_LCfg.c. 
wdgif_statecombiner_manual_config shall list the references to all configured slaves. 
wdgif_statecombiner_manual_config[i] = &wdgif_statecombiner_config_slave<ID>, where 
ID is the slave’s consecutive number starting with 1. 
SMI-536 
If the state combiner is configured in manual mode, the user of MICROSAR Safe shall 
verify that for a configured slave with ID the C-struct static const 
2018 Vector Informatik GmbH 
1.0 
87 / 103 

---

Safety Manual CBD1601056 D05 
WdgIf_StateCombinerManualConfigType wdgif_statecombiner_config_slave<ID> is 
defined in WdgIf_LCfg.c. 
wdgif_statecombiner_config_slave<ID> shall be set as follows: 
Field   Value  
Description  
1st  
WdgIfStateCombinerReferenceCycle 
The value of field 
WdgIfStateCombinerReferenceCycle in the 
EDF. 
2nd   WdgIfStateCombinerSlaveIncrementsMin  The value of field 
WdgIfStateCombinerSlaveIncrementsMin in 
the EDF. 
3rd  
WdgIfStateCombinerSlaveIncrementsMax  The value of field 
WdgIfStateCombinerSlaveIncrementsMax in 
the EDF. 
 
SMI-537 
The user of MICROSAR Safe shall verify that for each configured platform the C-struct 
static const WdgIf_InterfaceFunctionsType <platform>_functions is defined in 
WdgIf_LCfg.c. 
The fields for each C-struct <platform>_functions shall be set as follows: 
Field   Value  
Description  
1st  
Wdg_<infix>_SetMode_  
A reference to the WD driver’s API 
function to set the mode of the device 
referred to by infix. 
2nd   Wdg_<infix>_SetTriggerWindow_ and 
A reference to the WD driver’s API 
Wdg_<infix>_SetTriggerCondition_  
function to set the trigger window of the 
device referred to by infix. 
 
21.4 Safety features required from other components 
SMI-520 
This component requires the triggering of the watchdog and setting the triggering mode as 
a safety feature from the watchdog driver. 
This requirement is fulfilled if a watchdog driver by Vector is used. 
SMI-3085 
The WdgIf shall be used in order to call the services of underlying Watchdog driver(/s) to 
set the mode and the trigger condition as expected by the drivers. 
The user of MICROSAR Safe shall verify that the WdgIf services are only called by the 
WdgM. 
This requirement is fulfilled for all components of MICROSAR (if Vector's WdgM is used). 
If e.g. the trigger condition is called by another component, this may lead to unintended 
triggering of the watchdog. 
If the watchdog stack is not properly set up, it may not provide the expected protection. 
2018 Vector Informatik GmbH 
1.0 
88 / 103 

---

Safety Manual CBD1601056 D05 
21.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
89 / 103 

---

Safety Manual CBD1601056 D05 
22 Safety Manual WdgM 
22.1 Safety features 
SMI-373 
This component provides the following safety features: 
ID  
Safety feature  
CREQ-
WdgM shall provide a mechanism for Alive Supervision. 
102746  
CREQ-
WdgM shall provide a mechanism for Deadline Supervision. 
102745  
CREQ-
WdgM shall provide a mechanism for Logical Supervision. 
102744  
CREQ-
WdgM shall provide a service to trigger a checkpoint. 
102749  
CREQ-
WdgM shall provide a service to initiate a reset triggered by the hardware 
102752  
watchdog. 
CREQ-
WdgM shall provide a service to activate the supervision of a Supervised Entity. 
102754  
CREQ-
WdgM shall provide a service to deactivate the supervision of a Supervised Entity. 
102755  
CREQ-
WdgM shall provide a service to cyclically update the global supervision status. 
102763  
CREQ-
WdgM shall provide a service to set a new trigger mode. 
102758  
 
The watchdog manager is able to detect program flow violations, alive counter violations 
and deadline violations. 
The following types of faults can be detected: 
o  omission of an operation (program flow, alive counter), 
o  unrequested execution of an operation (program flow, alive counter), 
o  operation executed too early (alive counter, deadline), 
o  operation executed too late (alive counter, deadline), and 
o  operations executed in the wrong sequence (program flow). 
22.2 Configuration constraints 
SMI-501 
The user of MICROSAR Safe shall use the WdgM only on 32-bit microcontroller platforms. 
2018 Vector Informatik GmbH 
1.0 
90 / 103 

---

Safety Manual CBD1601056 D05 
SMI-499 
The user of MICROSAR Safe shall configure and verify alive supervision for a supervised 
entity. 
If no alive supervision is configured for a supervised entity, WdgM cannot detect if the 
corresponding checkpoint is reached at least once. 
Please note that for non-periodic supervised entities alive supervision is not possible. 
A value of a pre-compile configuration parameter is valid for every core. A different value 
cannot be set for the same pre-compile parameter and different cores. 
SMI-498 
The user of MICROSAR Safe shall set the value of WdgMTimebaseSource according to 
the required source of time ticks: 
WdgMTimebaseSource  
Description  
WDGM_INTERNAL_SOFTWARE_TICK   An internal time source for Deadline Monitoring is 
selected. The tick counter is incremented each time the 
WdgM_MainFunction() is invoked. 
WDGM_OS_COUNTER_TICK  
An OsCounter is selected for Deadline Monitoring as 
timebase. The user of MICROSAR Safe is responsible 
for configuring the OsCounter accurately. 
WDGM_EXTERNAL_TICK  
An external time source for Deadline Monitoring is 
selected. The tick counter is incremented each time the 
WdgM_UpdateTickCount() function is invoked. The 
function is implemented in the WdgM. The user of 
MICROSAR Safe is responsible for calling 
WdgM_UpdateTickCount() accurately. 
 
SMI-560 
The user of MICROSAR Safe shall use the functions WdgM_ActivateSupervisionEntity() 
and WdgM_DeactivateSupervisionEntity() to activate and deactivate the supervision of 
supervised entities.  
Activation and deactivation shall only be performed by a software component that is 
developed according to the highest ASIL that is allocated to the ECU. 
The functions are only available if WdgMEntityDeactivationEnabled is set to TRUE. 
Vector recommends setting WdgMEntityDeactivationEnabled to FALSE to prevent that 
faults are not detected. 
22.3 Additional verification measures 
SMI-3072 
The user of MICROSAR Safe shall verify that the WdgM is initialized only at intended 
points in time, e.g. during initialization. 
Unintended re-initialization may lead to a incorrect monitoring. 
SMI-502 
2018 Vector Informatik GmbH 
1.0 
91 / 103 

---

Safety Manual CBD1601056 D05 
The user of MICROSAR Safe shall verify that the output path of the generator is empty 
before the generator is started. 
The output path can be defined by the command line argument OUTPUT-DIRECTORY. 
SMI-524 
The user of MICROSAR Safe shall inspect the messages of the generator execution. 
If the generator aborts the generation process with an error message, the (partially) 
generated output files shall not be used in the system. 
If the generator detects an error, a message starting with "ERROR" is displayed on the 
standard output. 
If the generator shows a warning message starting with "WARNING", the user of 
MICROSAR Safe shall ensure that the cause of the warning does not invalidate the 
generated output files. 
22.3.1 Additional verification using WdgM Verifier 
SMI-503 
The user of MICROSAR Safe shall execute the supplied WdgM Verifier. 
Instructions can be found in the technical reference of WdgM on how to run the WdgM 
Verifier. 
SMI-504 
The user of MICROSAR Safe shall verify that the report of the WdgM Verifier 
o  comprises "All tests passed" in the last line. and 
o  that all tests in the Summary of the report are marked with PASSED. 
SMI-1578 
If an AUTOSAR OS with a version higher than 4.0 is used the verification test with id '109' 
is marked as "NOT PASSED". 
The user of MICROSAR Safe shall verify whether the assigned core id to a WdgMMode is 
generated correctly if an AUTOSAR OS with a version higher than 4.0 is used. The WdgM 
Verifier cannot not verify this step due to an incompatible change of the Os's description 
file. 
SMI-512 
The user of MICROSAR Safe shall verify the generated local transitions in 
wdgm_verifier_info.c. 
Generated local transitions are defined by the C-struct array with the name 
local_transitions. 
The array holds all local transitions of all supervised entities. 
Each local transition lt contains the names of: 
o  the source entity (SE) of lt, 
o  the source checkpoint of lt, 
o  the destination entity (SE) of lt and 
2018 Vector Informatik GmbH 
1.0 
92 / 103 

---

Safety Manual CBD1601056 D05 
o  the destination checkpoint of lt. 
Verification shall include that 
o  each local transition is defined as stated in the System Specification, and 
o  no local transition in the System Specification is missing. 
SMI-513 
The user of MICROSAR Safe shall verify the generated global transitions in 
wdgm_verifier_info.c. 
Generated global transitions are defined by the C-struct array with the name 
global_transitions. 
The array holds all global transitions of all supervised entities. 
Each global transition gt contains the names of: 
o  the source entity (SE) of gt, 
o  the source checkpoint of gt, 
o  the destination entity (SE) of gt, and  
o  the destination checkpoint of gt. 
Verification shall include that 
o  each global transition is defined as stated in the System Specification, and 
o  no global transition in the System Specification is missing. 
SMI-514 
The user of MICROSAR Safe shall verify the checkpoints in wdgm_verifier_info.c. 
Supervised entities named se are defined by a C-struct array with the name 
se_<se>_cp_list_. 
The array se_<se>_cp_list_ holds information about all checkpoints configured for se. 
Each array item contains information about one checkpoint cp of the supervised entity se: 
o  the supervised entity's ID (for this cp of se), 
o  the checkpoint's ID (for this cp of se), 
o  the supervised entity name (for this cp of se), and 
o  the checkpoint name (for this cp of se). 
Verification shall include that 
o  each checkpoint is configured as stated in the System Specification, and 
o  no checkpoint for the actual supervised entity is missing. 
2018 Vector Informatik GmbH 
1.0 
93 / 103 

---

Safety Manual CBD1601056 D05 
SMI-515 
The user of MICROSAR Safe shall verify the supervised entities in wdgm_verifier_info.c. 
Supervised entities named se are defined by a C-struct array with the name entities. 
The array entities holds information about a onfigured supervised entity. 
The fields in an array item for a supervised entity se shall have the following values (in this 
order): 
Value  
Source Line Comment  
The entity ID (of se).  
enitity id  
The entity name (of se).  
entity name 
The number of checkpoints configured for se.  
number of checkpoints 
A reference se_<se>_cp_list_, which refers to the list of CPs for se   this entity's checkpoints 
A reference to the callback function for se as configured in 
WdgMLocalStateChangeCbk 
WdgMLocalStateChangeCbk (or NULL_PTR if no callback function 
is configured).  
false 
autosar_3_1_x_compatibility 
The application task for se as configured in field WdgMAppTaskRef  WdgMAppTaskRef 
Verification shall include that 
o  each supervised entity is configured as stated in the System Specification, and 
o  no supervised entity is missing. 
SMI-516 
The user of MICROSAR Safe shall verify the deadline supervisions in 
wdgm_verifier_info.c. 
Deadline supervisions are defined by a C-struct array with the name 
deadline_supervisions. 
The array deadline_supervisions holds information about all transitions with deadline 
supervision. 
Each deadline supervision dl contains the following values: 
o  the source entity name (SE) of dl, 
o  the source checkpoint name of dl, 
o  the destination entity name (SE) of dl, 
o  the destination checkpoint name of dl, 
o  the minimum deadline for dl (in seconds), and 
o  the maximum deadline of dl (in seconds). 
Verification shall include that 
o  each deadline supervision is configured as stated in the System Specification, and 
2018 Vector Informatik GmbH 
1.0 
94 / 103 

---

Safety Manual CBD1601056 D05 
o  no deadline supervision is missing. 
SMI-517 
The user of MICROSAR Safe shall verify the alive supervisions in wdgm_verifier_info.c. 
Alive supervisions are defined by a C-struct array with the name alive_supervisions. 
The array alive_supervisions holds information about all transitions with alive supervision. 
Each alive supervision al contains the following values: 
o  the supervised entity name (SE) of al, 
o  the checkpoint name of that se of al, 
o  the number of expected alive indications per reference cycle of al, 
o  the minimum margin for alive indications of al, 
o  the maximum margin for alive indications of al, and 
o  the number of supervision reference cycle of al. 
Verification shall include that 
o  each alive supervision is configured as stated in the System Specification, and 
o  no alive supervision is missing. 
SMI-518 
The user of MICROSAR Safe shall verify the configured cores in wdgm_verifier_info.c. 
The configured cores are defined in the main() function. 
For each configured core with ID, the following line shall be present: 
 
 
result += verify (&WdgMConfig_Modem_core<ID>, &verifier_info); 
 
 
 
 
where ID is the core ID and m is the ID of the WdgM mode. 
Verification shall include that for each core there is a corresponding line in the file. 
22.3.2 Additional verification of generator execution 
SMI-506 
The user of MICROSAR Safe shall verify that for the following arrays in WdgM_PBcfg.c, 
the array length matches the number of items in the array: 
2018 Vector Informatik GmbH 
1.0 
95 / 103 

---

Safety Manual CBD1601056 D05 
o  WdgMTransition 
o  WdgMGlobalTransition 
o  all arrays named StartsGlobalTransition<se>_<cp>_<i>_ (for a supervised entity se, 
a checkpoint cp and an integer i) 
o  WdgMCheckPoint 
o  WdgMSupervisedEntity 
o  all arrays named WdgMTriggerMode_core<ID> (for each core with ID) 
o  WdgMWatchdogDevice<ID> (for each core with ID) 
o  WdgMAllowedCallers 
Some of these arrays have preprocessor defines for their size, e.g. WdgMCheckPoint 
[WDGM_NR_OF_CHECKPOINTS]. These defines can be found in WdgM_PBcfg.h. 
SMI-507 
The user of MICROSAR Safe shall verify that each item in the array 
WdgMSupervisedEntity follows this rules: 
1. WdgMCheckpointRef has a value of the form &WdgMCheckPoint[i] with i < 
_WDGM_NR_OF_CHECKPOINTS, and 
2. _WdgMCheckpointLocInitialId has a value of 0. 
The array can be found in WdgM_PBcfg.c. 
SMI-27923 
The user of MICROSAR Safe shall verify that each WdgM_StatusReportToRte member of 
struct WdgM_ConfigType and each WdgM_StatusReportToRte member of struct 
WdgM_SupervisedEntityType has a valid entry if 
WDGM_STATUS_REPORTING_MECHANISM is set to 
WDGM_USE_MODE_SWITCH_PORTS. 
The functions must be implemented by the Rte and must have the following signature: 
Std_ReturnType (*WdgM_StatusReportToRte) (WdgMMode). 
Both structs can be found in WdgM_PBcfg.c. 
SMI-508 
The user of MICROSAR Safe shall verify that for each core with ID 
WDGM_NR_OF_WATCHDOGS_CORE<ID> matches the actual number of configured 
WD devices. 
The define can be found in WdgM_PBcfg.h. 
SMI-509 
The user of MICROSAR Safe shall verify that for each core with ID 
WDGM_NR_OF_TRIGGER_MODES_CORE<ID> matches the actual number of 
configured Watchdog Manager Trigger Modes. 
The define can be found in WdgM_PBcfg.h. 
SMI-510 
2018 Vector Informatik GmbH 
1.0 
96 / 103 

---

Safety Manual CBD1601056 D05 
The user of MICROSAR Safe shall verify that WDGM_NR_OF_ALLOWED_CALLERS 
matches the number of modules that call function WdgM_SetMode(). 
The define can be found in WdgM_PBcfg.h. 
SMI-511 
The user of MICROSAR Safe shall verify that in WdgMConfig_Mode<m>_core<ID> (for 
each core with ID and every mode m), the field WdgMCallersRef points to 
WdgMAllowedCallers and WdgMAllowedCallers is an array of type WdgM_CallersType 
with a length of WDGM_NR_OF_ALLOWED_CALLERS. 
The variable can be found in WdgM_PBCfg.h. 
SMI-550 
The user of MICROSAR Safe shall verify the types used by WdgM. 
If the configuration parameter WDGM_USE_RTE is set to STD_ON, the types from 
Rte_Type.h are used: 
Type  
Allowed Value  
WdgM_SupervisedEntityIdType 
uint16 
WdgM_CheckpointIdType 
uint16 
WdgM_ModeType 
uint8 
WdgM_LocalStatusType 
uint8 
WdgM_GlobalStatusType 
uint8 
The WdgM includes WdgM_Rte_Includes.h if and only if WDGM_USE_RTE is set to 
STD_ON. 
If the configuration parameter WDGM_USE_RTE is set to STD_OFF, the types from 
WdgM are used: 
Type  
Allowed Value  
WdgM_SupervisedEntityIdType 
uint16 
WdgM_CheckpointIdType 
uint16 
WdgM_ModeType 
uint8 
WdgM_LocalStatusType 
uint8 
WdgM_GlobalStatusType 
uint8 
 
SMI-551 
The user of MICROSAR Safe shall verify the definitions used by WdgM. 
If the configuration parameter WDGM_USE_RTE is set to STD_ON, the definitions from 
Rte_WdgM_Type.h are used. 
If the configuration parameter WDGM_USE_RTE is set to STD_OFF, the definitions from 
WdgM are used. 
Definition  
Value  
WDGM_LOCAL_STATUS_OK 
0  
2018 Vector Informatik GmbH 
1.0 
97 / 103 

---

Safety Manual CBD1601056 D05 
WDGM_LOCAL_STATUS_FAILED 
1  
WDGM_LOCAL_STATUS_EXPIRED 
2  
WDGM_LOCAL_STATUS_DEACTIVATED 
4  
WDGM_GLOBAL_STATUS_OK 
0  
WDGM_GLOBAL_STATUS_FAILED 
1  
WDGM_GLOBAL_STATUS_EXPIRED 
2  
WDGM_GLOBAL_STATUS_STOPPED 
3  
WDGM_GLOBAL_STATUS_DEACTIVATED 
4  
The WdgM includes Rte_WdgM_Type.h if and only if WDGM_USE_RTE is set to 
STD_ON. 
22.4 Safety features required from other components 
SMI-372 
This component requires setting a trigger condition and setting the triggering mode as 
safety features from WdgIf. 
This requirement is fulfilled if the WdgIf by Vector is used. 
SMI-3414 
The user of MICROSAR Safe shall call the service to set the mode as expected by the 
Wdg stack. 
If the watchdog is not properly set up, it may not provide the expected protection. 
22.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
98 / 103 

---

Safety Manual CBD1601056 D05 
23 Safety Manual XCP 
23.1 Safety features 
This component does not provide safety features. 
SMI-178 
This component is only partly developed according to ASIL development process. This part 
includes the disabling of the Xcp. 
The main part of this component is developed according to a QM development process.  
Thus, this component shall only be enabled in an operating mode that do not impose risk 
for the health of persons. 
23.2 Configuration constraints 
SMI-3412 
The user of MICROSAR Safe shall configure the following: 
o  Set /MICROSAR/Xcp/XcpGeneral/XcpControl to TRUE. 
The user of MICROSAR Safe shall verify that the corresponding configuration switch is set 
in the Xcp protocol layer and all used transport layers: 
File  
Define  
STD_ON/STD_OFF  
Xcp_Cfg.h  
XCP_CONTROL  
STD_ON  
CanXcp_Cfg.h  
CANXCP_ENABLE_CONTROL  
STD_ON  
FrXcp_Cfg.h  
FRXCP_ENABLE_CONTROL  
STD_ON  
TcpIpXcp_Cfg.h  
TCPIPXCP_ENABLE_CONTROL  
STD_ON  
 
SMI-179 
The user of MICROSAR Safe shall use the macros XCP_ACTIVATE() and 
XCP_DEACTIVATE() to activate and deactivate XCP protocol layer and transport layer 
components.  
Activation and deactivation shall only be performed by a software component that is 
developed according to the highest ASIL that is allocated to the ECU. 
XCP shall only be activated in an operating mode that does not impose risk for the health 
of persons.  
Note: XCP is active by default. 
SMI-183 
The user of MICROSAR Safe shall make the following memory sections read-only for the 
XCP protocol layer and transport layer components as well as all other software with an 
ASIL lower than the highest ASIL allocated to the ECU: 
o  XCP_START_SEC_VAR_INIT_UNSPECIFIED_SAFE 
2018 Vector Informatik GmbH 
1.0 
99 / 103 

---

Safety Manual CBD1601056 D05 
o  CANXCP_START_SEC_VAR_INIT_UNSPECIFIED_SAFE 
o  FRXCP_START_SEC_VAR_INIT_UNSPECIFIED_SAFE 
o  TCPIPXCP_START_SEC_VAR_INIT_UNSPECIFIED_SAFE 
23.3 Additional verification measures 
SMI-184 
The user of MICROSAR Safe shall verify during integration testing that XCP is disabled 
during normal operation. 
23.4 Safety features required from other components 
SMI-177 
This component requires an operating system with enabled memory partitioning. 
23.5 Dependencies to hardware 
This component does not use a direct hardware interface. 
2018 Vector Informatik GmbH 
1.0 
100 / 103 

---

Safety Manual CBD1601056 D05 
24 Glossary and Abbreviations 
24.1 Glossary 
Term 
Definition 
User of 
Integrator and user of components from MICROSAR Safe provided by Vector. 
MICROSAR 
Safe 
MICROSAR 
MICROSAR Safe comprises MICROSAR SafeBSW and MICROSAR SafeRTE 
Safe 
as Safety Element out of Context. MICROSAR SafeBSW is a set of components, 
that are developed according to ISO 26262 [1], and are provided by Vector in the 
context of this delivery. The list of MICROSAR Safe components in this delivery 
can be taken from the documentation of the delivery. 
Critical section 
A section of code that needs to be protected from concurrent access. A critical 
section may be protected by using the AUTOSAR exclusive area concept. 
Configuration 
Data that is used to adapt the MICROSAR Safe component to the specific use-
data 
case of the user of MICROSAR Safe. Configuration data typically comprises 
among others: feature selection, routing tables, channel tables, task priorities, 
memory block descriptions. 
Generated 
Source code that is generated as a result of the configuration in DaVinci 
code 
Configurator Pro 
Partition 
A set of memory regions that is accessible by tasks and ISRs. Synonym to 
OSApplication.  
 
24.2 Abbreviations 
Abbreviation 
Description 
ASIL 
Automotive Safety Integrity Level 
BSWMD 
Basic Software Module Description 
CPU 
Central Processing Unit 
CREQ 
Component Requirement 
EEPROM 
Eletronically Ereasable and Programmable Read-only Memory 
ECC 
Error Correcting Code 
ECU 
Electronic Control Unit 
EXT 
Driver for an external hardware unit 
ISO 
International Standardization Organization 
MCAL 
Microcontroller Abstraction 
MIP 
Module Implementation Prefix 
MSSV 
MICROSAR Safe Silence Verifier 
OS 
Operating System 
PDU 
Protocol Data Unit 
QM 
Quality Management 
2018 Vector Informatik GmbH 
1.0 
101 / 103 

---

Safety Manual CBD1601056 D05 
RAM 
Random Access Memory 
SMI 
Safety Manual Item 
TCL 
Tool Confidence Level 
 
2018 Vector Informatik GmbH 
1.0 
102 / 103 

---

Safety Manual CBD1601056 D05 
25 Contact 
Visit our website for more information on 
o  News 
o  Products 
o  Demo software 
o  Support 
o  Training data 
o  Addresses 
www.vector.com  
2018 Vector Informatik GmbH 
1.0 
103 / 103 

---

Document Outline

• Safety Manual
• 1 General Part
  • 1.1 Introduction
    • 1.1.1 Purpose
    • 1.1.2 Scope
    • 1.1.3 Definitions
    • 1.1.4 References
    • 1.1.5 Overview
  • 1.2 Concept
    • 1.2.1 Technical Safety Requirements
      • 1.2.1.1 Initialization
      • 1.2.1.2 Self-test
      • 1.2.1.3 Reset of ECU
      • 1.2.1.4 Data consistency
      • 1.2.1.5 Non-volatile memory
        • 1.2.1.5.1 Saving data
        • 1.2.1.5.2 Loading data
      • 1.2.1.6 Scheduling
        • 1.2.1.6.1 Deterministic, hard real-time scheduling
      • 1.2.1.7 Partitioning
        • 1.2.1.7.1 Memory partitioning
        • 1.2.1.7.2 Time partitioning
          • 1.2.1.7.2.1 Timing protection
          • 1.2.1.7.2.2 Killing of applications
      • 1.2.1.8 Communication protection
        • 1.2.1.8.1 Inter ECU communication
          • 1.2.1.8.1.1 End-to-end protection
          • 1.2.1.8.1.2 Protection by cryptographic algorithms
        • 1.2.1.8.2 Intra ECU communication
          • 1.2.1.8.2.1 Intra OS application communication
          • 1.2.1.8.2.2 Inter OS application communication
      • 1.2.1.9 Watchdog services
        • 1.2.1.9.1 Program flow monitoring
        • 1.2.1.9.2 Alive monitoring
        • 1.2.1.9.3 Deadline monitoring
      • 1.2.1.10 Peripheral in- and output
        • 1.2.1.10.1 Peripheral input
        • 1.2.1.10.2 Peripheral output
    • 1.2.2 Environment
      • 1.2.2.1 Safety Concept
      • 1.2.2.2 Use of MICROSAR Safe Components
      • 1.2.2.3 Partitioning
      • 1.2.2.4 Resources
    • 1.2.3 Process
• 2 Safety Manual BswM
  • 2.1 Safety features
  • 2.2 Configuration constraints
  • 2.3 Additional Verification measures
  • 2.4 Safety features required from other components
  • 2.5 Dependencies to hardware
• 3 Safety Manual CanIf
  • 3.1 Safety features
  • 3.2 Configuration constraints
  • 3.3 Additional verification measures
  • 3.4 Safety features required from other components
  • 3.5 Dependencies to hardware
• 4 Safety Manual CanNm
  • 4.1 Safety features
  • 4.2 Configuration constraints
  • 4.3 Additional verification measures
  • 4.4 Safety features required from other components
  • 4.5 Dependencies to hardware
• 5 Safety Manual CanSM
  • 5.1 Safety features
  • 5.2 Configuration constraints
  • 5.3 Additional verification measures
  • 5.4 Safety features required from other components
  • 5.5 Dependencies to hardware
• 6 Safety Manual CanTp
  • 6.1 Safety features
  • 6.2 Configuration constraints
  • 6.3 Additional verification measures
  • 6.4 Safety features required from other components
  • 6.5 Dependencies to hardware
• 7 Safety Manual Com
  • 7.1 Safety features
  • 7.2 Configuration constraints
  • 7.3 Additional verification measures
  • 7.4 Safety features required from other components
  • 7.5 Dependencies to hardware
• 8 Safety Manual ComM
  • 8.1 Safety features
  • 8.2 Configuration constraints
  • 8.3 Additional Verification measures
  • 8.4 Safety features required from other components
  • 8.5 Dependencies to hardware
• 9 Safety Manual Crc
  • 9.1 Safety features
  • 9.2 Configuration constraints
  • 9.3 Additional verification measures
  • 9.4 Dependencies to other components
    • 9.4.1 Safety features required from other components
    • 9.4.2 Coexistence with other components
  • 9.5 Dependencies to hardware
• 10 Safety Manual Csm
  • 10.1 Safety Features
  • 10.2 Configuration constraints
  • 10.3 Additional verification measures
  • 10.4 Dependencies to other components
    • 10.4.1 Safety features required from other components
  • 10.5 Dependencies to hardware
• 11 Safety Manual Det
  • 11.1 Safety features
  • 11.2 Configuration constraints
  • 11.3 Additional Verification measures
  • 11.4 Safety features required from other components
  • 11.5 Dependencies to hardware
• 12 Safety Manual EcuM
  • 12.1 Safety features
  • 12.2 Configuration constraints
  • 12.3 Additional verification measures
  • 12.4 Safety features required from other components
  • 12.5 Dependencies to hardware
• 13 Safety Manual Fee
  • 13.1 Safety features
  • 13.2 Configuration constraints
  • 13.3 Additional Verification measures
  • 13.4 Safety features required from other components
  • 13.5 Dependencies to hardware
• 14 Safety Manual MemIf
  • 14.1 Safety features
  • 14.2 Configuration constraints
  • 14.3 Additional verification measures
  • 14.4 Dependencies to other components
    • 14.4.1 Safety features required from other components
    • 14.4.2 Coexistence with other components
  • 14.5 Dependencies to hardware
• 15 Safety Manual Nm
  • 15.1 Safety features
  • 15.2 Configuration constraints
  • 15.3 Additional Verification measures
  • 15.4 Dependencies to other components
    • 15.4.1 Safety features required from other components
    • 15.4.2 Coexistence with other components
  • 15.5 Dependencies to hardware
• 16 Safety Manual NvM
  • 16.1 Safety features
  • 16.2 Configuration constraints
  • 16.3 Additional verification measures
  • 16.4 Safety features required from other components
  • 16.5 Dependencies to hardware
• 17 Safety Manual OS
  • 17.1 Safety features
  • 17.2 Configuration constraints
  • 17.3 Additional verification measures
    • 17.3.1 Interrupt handling
    • 17.3.2 Memory mapping and linking
    • 17.3.3 Stack
    • 17.3.4 Multicore systems with mixed diagnostic coverage capability
    • 17.3.5 (Non-)Trusted Functions
    • 17.3.6 Miscellaneous
    • 17.3.7 Tracing
  • 17.4 Safety features required from other components
  • 17.5 Dependencies to hardware
• 18 Safety Manual OS (RH850)
  • 18.1 Safety features
  • 18.2 Configuration constraints
  • 18.3 Additional verification measures
  • 18.4 Safety features required from other components
  • 18.5 Dependencies to hardware
• 19 Safety Manual PduR
  • 19.1 Safety features
  • 19.2 Configuration constraints
  • 19.3 Additional verification measures
  • 19.4 Safety features required from other components
  • 19.5 Dependencies to hardware
• 20 Safety Manual Rte
  • 20.1 Safety features
  • 20.2 Configuration constraints
  • 20.3 Additional verification measures
    • 20.3.1 Guided integration testing
      • 20.3.1.1 BSW configuration
      • 20.3.1.2 Executable Entity Scheduling
      • 20.3.1.3 SWC Communication
      • 20.3.1.4 Usage of RTE Headers
      • 20.3.1.5 Usage of RTE APIs
      • 20.3.1.6 Configuration of RTE APIs
  • 20.4 Safety features required from other components
  • 20.5 Dependencies to hardware
• 21 Safety Manual WdgIf
  • 21.1 Safety features
  • 21.2 Configuration constraints
  • 21.3 Additional verification measures
  • 21.4 Safety features required from other components
  • 21.5 Dependencies to hardware
• 22 Safety Manual WdgM
  • 22.1 Safety features
  • 22.2 Configuration constraints
  • 22.3 Additional verification measures
    • 22.3.1 Additional verification using WdgM Verifier
    • 22.3.2 Additional verification of generator execution
  • 22.4 Safety features required from other components
  • 22.5 Dependencies to hardware
• 23 Safety Manual XCP
  • 23.1 Safety features
  • 23.2 Configuration constraints
  • 23.3 Additional verification measures
  • 23.4 Safety features required from other components
  • 23.5 Dependencies to hardware
• 24 Glossary and Abbreviations
  • 24.1 Glossary
  • 24.2 Abbreviations
• 25 Contact

---