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”)
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
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
.
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
) 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
