In actual end-user applications, not all the STM32F2 Series parts or modules are used for the implementation of
the safety function. That can happens under two possible alternative conditions:
• The part is not used at all (disabled).
• The part is used for the implementation of a function that is non-safety related (for example a GPIO line
driving a “power-on” signaling led on an electronic board).
Requiring the implementation of the respective safety mechanism for those unused parts could result in an
overkill. The safety analysis results can be therefore customized.
The end user can define the selected STM32F2 Series parts as “non-safety related” under the following
conditions (end user responsibility):
• Collect rationales and evidences that the parts play no role in safety function implementation.
• Collect rationales and evidences that the parts do not interfere with the safety function during normal
operation due to final system design decisions.
• Fulfill the below-reported general condition for the mitigation of the intra-MCU interferences (Table 118. List
of general requirements for FFI).
The end user is therefore allowed for “non-safety related” parts to do the following:
• Discard the part contribution from metrics computations in FMEDA;
• Do not implement the related safety mechanisms listed in Table 1.
With regard to SFF computation, this procedure is equivalent to declare “no part/no effect” as per IEC61508-4,
3.6.13 or 14 definition any failure of discarded modules.
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 STM32F2 Series internal modules in case of internal failures (freedom from interferences,
FFI). These precautions are integral part of the STM32F2 Series safety concept and they can play a relevant role
when multiple microcontroller modules are declared as “non-safety related” by the end user as per Section 4.1.1 .
The requirement for the end user is to implement the safety mechanism listed in Table 118. List of general
requirements for FFI (implementation details can be found in Description of hardware and software diagnostics )
despite any evaluation about their contribution for the safety metrics computations.
Table 118. List of general requirements for FFI
Diagnostic Description
FFI_SM_0 Unused peripheral disable
FFI_SM_1 Periodical read-back of interference avoidance registers
BUS_SM_0 Periodical software test for interconnections
NVIC_SM_0 Periodical read-back of configuration registers
NVIC_SM_1 Expected and unexpected interrupt check by application software
DMA_SM_0 Periodical read-back of configuration registers
DMA_SM_2
Information redundancy including sender or receiver identifier on data packet transferred via DMA
(1)
DMA_SM_4
DMA transactions awareness
(1)
GPIO_SM_0 Periodical read-back of configuration registers
1. To be implemented only if DMA is actually used
4.1.3 Notes on multiple faults scenario
In principle, IEC61508 requires to analyze multiple faults scenarios, therefore restrictions to one fault at time
conditions could be not acceptable. Accordingly, the safety analysis for STM32F2 Series took into consideration
also multiple faults scenarios. Furthermore, following the spirit of ISO26262 (the reference and state-of-art
standard norm for integrated circuit safety analysis) the analysis investigated faults able to “disable” each safety
mechanism, in order to individuate mitigation measure for such condition. Section 3.6 tables report on the
UM1845
Random hardware failure safety results
UM1845 - Rev 4
page 83/108
To Next Page
Loading...
