The following table provides details on the SS1 and SS2 safe states.
Table 2. SS1 and SS2 safe state details
Safe
state
Condition
Compliant item
action
System transition to safe
state – 1oo1 architecture
System transition to safe
state – 1oo2 architecture
SS1
Application software is informed
by the presence of a fault and a
reaction by Application software
itself is possible.
Fault reporting
to Application
software
Application software drives
the overall system in its safe
state
Application software in one of
the two channels drives the
overall system in its safe state
SS2
Application software cannot be
informed by the presence of a
fault or Application software is not
able to execute a reaction.
Reset signal
issued by WDTe
WDTe drives the overall
system in its safe state (“safe
shut-down”)
(1)
PEv drives the overall system
in its safe state
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 and Section 3.6 Hardware and software diagnostics.
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 Section 5 List of evidences) keeps evidences of the current compliance
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
Electrical specifications and environment limits
UM2305 - Rev 10
page 9/110
To Next Page
Loading...
Need help?
General
