Electrical Specifications And Environment Limits; Systematic Safety Integrity; Hardware And Software Diagnostics; Table 2. Ss1 And Ss2 Safe State Details - ST STM32L4 Series User Manual

The following table provides details on the SS1 and SS2 safe states.
Safe
state
Application software is informed
by the presence of a fault and a
SS1
reaction by Application software
itself is possible.
Application software cannot be
informed by the presence of a
SS2
fault or Application software is not
able to execute a reaction.
1. Safe state achievement intended here is compliant to Note on IEC 61508-2, 7.4.8.1
ASR9: It is assumed that the safe state defined at system level by End user is compatible with the assumed local
safe state (SS1, SS2) for Compliant item.
ASR10: Compliant item is assumed to be analyzed according to routes 1H and 1S of IEC 61508-2.
Note: Refer to Section 3.5 Systematic safety integrity
ASR11: Compliant item is assumed to be regarded as type B, as per IEC 61508:2, 7.4.4.1.2.
ASR12: It is assumed that dual-bank Flash memory mass erase and reprogramming features are used during
maintenance state of the final system, and not for the implementation of the safety function.
3.4

Electrical specifications and environment limits

To ensure safety integrity, the user must operate Device(s) within its (their) specified:
• absolute maximum rating
• capacity
• operating conditions
For electrical specifications and environmental limits of Device(s), refer to its (their) technical documentation such
as datasheet(s) and reference manual(s) available on www.st.com.
3.5

Systematic safety integrity

According to the requirements of IEC 61508 -2, 7.4.2.2, the Route 1S is considered in the safety analysis of
Device(s). As clearly authorized by IEC61508-2, 7.4.6.1, STM32 MCU products can be considered as standard,
mass-produced electronic integrated devices, for which stringent development procedures, rigorous testing and
extensive experience of use minimize the likelihood of design faults. However, ST internally assesses the
compliance of the Device development flow, through techniques and measures suggested in the IEC 61508-2
Annex F. A safety case database (see
level to the norm.
3.6

Hardware and software diagnostics

This section lists all the safety mechanisms (hardware, software and application-level) considered in the
Device safety analysis. It is expected that users are familiar with the architecture of Device, and that this
document is used in conjunction with the related Device datasheet, user manual and reference information. To
avoid inconsistency and redundancy, this document does not report device functional details. In the following
descriptions, the words safety mechanism, method, and requirement are used as synonyms.
As the document provides information relative to the superset of peripherals available on the devices it covers
(not all devices have all peripherals), users are supposed to disregard any recommendations not applicable to
their Device part number of interest.
UM2305 - Rev 10
Table 2. SS1 and SS2 safe state details
Compliant item
Condition
action
Fault reporting
to Application
software
Reset signal
issued by WDTe
Section 5 List of
Electrical specifications and environment limits
System transition to safe
state – 1oo1 architecture
Application software drives
the overall system in its safe
state
WDTe drives the overall
system in its safe state ("safe
shut-down") (1)
and Section 3.6 Hardware and software
evidences) keeps evidences of the current compliance
UM2305
System transition to safe
state – 1oo2 architecture
Application software in one of
the two channels drives the
overall system in its safe state
PEv drives the overall system
in its safe state
diagnostics.
page 9/110