In actual End user applications, not all the STM32L4 and STM32L4+ Series parts or modules implement a safety
function. That happens if:
• The part is not used at all (disabled), or
• The part implements functions that are not safety-related (for example, a GPIO line driving a power-on
signaling light on an electronic board).
Note: Implementation of non-safety-related functions is in principle forbidden by the assumed safety requirement
ASR6 (see Section 3.3.1 Safety requirement assumptions), hence under End user's entire responsibility. As
any other derogation from safety requirements included in this manual, it is End user's responsibility to provide
consistent rationales and evidences that the function does not bring additional risks, by following the procedure
described in this section. Therefore, it is strongly recommended to reserve such derogation to very simple
functions (as the one provided in the example).
Implementing safety mechanisms on such parts would be a useless effort for End user. The safety analysis
results can therefore be customized.
End user can define a STM32L4 and STM32L4+ Series part as non-safety-related based on:
• Collecting rationales and evidences that the part does not contribute to safety function.
• Collecting rationales and evidences that the part does not interfere with the safety function during normal
operation, due to final system design decisions. Mitigation of unused modules is exhaustively addressed in
Section 4.1.2 General requirements for freedom from interferences (FFI).
• Fulfilling the general condition for the mitigation of intra-MCU interferences (see Section 4.1.2 General
requirements for freedom from interferences (FFI)).
For a non-safety-related part, End user is allowed to:
• Exclude the part from computing metrics to report in FMEDA, and
• Not implement safety mechanisms as listed in Table 151. List of safety recommendations.
With regard to SFF computation, this section complies with the no part / no effect definition as per IEC 61508‑4,
3.6.13 / 3.6.14.
4.1.2 General requirements for freedom from interferences (FFI)
A dedicated analysis has highlighted a list of general requirements to be followed in order to mitigate potential
interferences between Device internal modules in case of internal failures (freedom from interferences, FFI).
These precautions are integral part of the Device safety concept and they can play a relevant role when multiple
microcontroller modules are declared as non-safety-related by End user as per Section 4.1.1 Safety analysis
result customization.
End user must implement the safety mechanisms listed in Table 153 (implementation details in
Section 3.6 Hardware and software diagnostics) regardless any evaluation of their contribution to safety metrics.
Table 153. List of general requirements for FFI
Diagnostic Description
BUS_SM_0 Periodic software test for interconnections
GPIO_SM_0 Periodic read-back of configuration registers
DMA_SM_0 Periodic read-back of configuration registers
DMA_SM_2
Information redundancy by including sender or receiver identifier on data packet transferred via DMA
(1)
DMA_SM_4
DMA transaction awareness
(1)
NVIC_SM_0 Periodic read-back of configuration registers
NVIC_SM_1 Expected and unexpected interrupt check
FFI_SM_0 Disable of unused peripherals
FFI_SM_1 Periodic read-back of interference avoidance registers
1. To be implemented only if DMA is actually used.
UM2305
Random hardware failure safety results
UM2305 - Rev 10
page 92/110
To Next Page
Loading...
Need help?
General
