Skip to main content
Graduate
July 6, 2023
Solved

Question on Safety Manual /mechanisms for STM32F4 (and others)

  • July 6, 2023
  • 1 reply
  • 1507 views

Hi,

i have a question regarding the functional safety manual /safety mechanisms for the STM32F4 (and others with a similar functional safety manuals/mechanisms).

A lot of SMs address transient, random faults, e.g. (refering to document UM1840):

- CPU_SM_2 "Double computation in Application software"

- BUS_SM_1 "Information redundancy in intra-chip data exchanges"

Wouldn't these transient faults be covered when one would use two MCUs? The propability of the same transient fault happening in both MCUs should be near zero.

Nevertheless does the document require two MCUs and the mentioned SMs to achieve SIL 3 rating (chapter 3.2.4 in UM1840). Why are two MCUs in 1oo2 not enough protection against transient faults?

Greetings!

    This topic has been closed for replies.
    Best answer by Petr Sladecek

    Hello,

    the problem is not to cover either permanent or transient fails exclusively but cover their budget overall. While achieving SIL2 level is more relaxed, covering significant number of permanent fails can be sufficient. SIL3 requires more severe level of coverage so covering part of the short life transient fails at least is must at this case. Hardware features are required and helpful then as slow software testing is not very efficient to do this job. Commonly whatever redundancy is helpful here - structural, temporal, functional, informational… (see e.g., AN4750).

    Best regards,

    Petr

    1 reply

    ST Employee
    July 12, 2023

    Hello,

    the problem is not to cover either permanent or transient fails exclusively but cover their budget overall. While achieving SIL2 level is more relaxed, covering significant number of permanent fails can be sufficient. SIL3 requires more severe level of coverage so covering part of the short life transient fails at least is must at this case. Hardware features are required and helpful then as slow software testing is not very efficient to do this job. Commonly whatever redundancy is helpful here - structural, temporal, functional, informational… (see e.g., AN4750).

    Best regards,

    Petr