STMicroelectronics STM8AF6268, STM8AF6226, STM8AF6266, STM8AF6166, STM8AF6168 User Manual
...
UM1915
User Manual
STM8AF Safety Manual
Introduction
The STM8A is a family of microcontrollers designed for automotive applications, with different
memory
This document describes how to use the STM8AF series of microcontrollers in the context of
a safety-related system (STM8A-SafeASIL functional safety package), specifying the user's
responsibilities for installation and operation, in order to reach the targeted
level.
This manual applies to the following STM8AF series:
The STM8AF62 line that is the mainstay of the automotive STM8A 8 bit MCU:
The STM8AF52 line: STM8AF automotive MCUs with CAN:
densities, packages and peripherals.
safety integrity
– The low density devices with 8 Kbytes of Flash memory:
– The medium density with 16 to 32 Kbytes of Flash memory
STM8AF6266/68, STM8AF612x/4x and STM8AF6166/68
– The high density devices with 32 to 128 Kbytes of Flash memory:
STM8AF6269/8x/Ax and STM8AF6178/99/9A
– The high density devices with 32 to 128 Kbytes of Flash memory: STM8AF52xx and
STM8AF51xx
STM8AF6223/26
:
STM8AF624x,
If the STM8AF microcontrollers are used in adherence to this manual, the system designer
can avoid
estimation about the impact to
This manual is written in compliance with ISO 26262. It also indicates how to use the
STM8AF MCUs in
manual and FMEDA data were
YOGITECH, using their fault Robust
The safety analysis summarized in this manual, takes into account the variation in terms of
memory size, number of internal peripherals and the different packages available among
the different part numbers of the STM8A microcontrollers family.
This manual has to be read along with the technical documentation on related part numbers
available on www.st.com/stm8.
going into the details of the functional safety design and validation, to give an
the overall safety function.
the context of other functional safety standards such as IEC 61508. This
developed in cooperation with the safety expertise company
Methodology (fRMethodology).
July 2015 DocID028066 Rev 1 1/59
www.st.com
1
Content UM1915
Content
1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Terms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Reference normative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 STM8AFxxxx device development process . . . . . . . . . . . . . . . . . . . . . . 9
2.1 STMicroelectronics standard development process . . . . . . . . . . . . . . . . . . 9
2.2 YOGITECH fRMethodology process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 STM8AF Safety Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Definition of the Safety Element out of Context . . . . . . . . . . . . . . . . . . . 10
3.2 STM8AF as a SEooC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Assumed safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
3.3.1 The target safety metrics (ASIL, SPFM, LFM and PMHF) . . . . . . . . . . . 12
3.3.2 The assumed target time intervals (FTTI and MPFDI) . . . . . . . . . . . . . . 13
3.4 Electrical specifications and environment limits . . . . . . . . . . . . . . . . . . . . 14
3.5 Systematic safety integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Safety mechanisms/measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1 STM8A CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.2 Program FLASH memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.3 Data EEPROM memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6.4 RAM memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6.5 Boot ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.6 Basic enhanced CAN (beCAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.7 LINUART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6.8 USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.9 I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6.10 SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6.11 Analog to Digital Converter (ADC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.12 Basic timer (TIM 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.13 GPIO – PORT A/B/C/D/E/F/G/H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2/59 DocID028066 Rev 1
UM1915 Content
3.6.14 Address and Data bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.15 Supply voltage system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.16 Reset and Clock control subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.17 Auto-wakeup timer (AWU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6.18 Watchdogs (IWDG, WWDG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6.19 Debug/ SWIM (single wire interface module) . . . . . . . . . . . . . . . . . . . . 29
3.6.20 Interrupt controller (NVIC and EXTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.21 Latent fault detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.22 Disable and periodic cross-check of unintentional activation of unused
peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7 Assumption of Use (AoU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7.1 List of Assumptions of Use (AoU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Safety Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Hardware random failure analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Safety analysis result customization . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2 General requirements for Freedom From Interferences (FFI) . . . . . . . . 36
4.2 Dependent failures analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 List of evidences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Appendix A Appendix A Overview of fRMethodology . . . . . . . . . . . . . . . . . . . . 40
A.1 The essence of fRMethodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.2 fRMethodology and its flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.3 fRTools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix B Appendix B Change impact analysis for other safety standards . 44
B.1 IEC 60730-1:2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.2 Architectural categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.3 Safety metrics recomputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.4 Work products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.5 IEC 61508 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.6 Architectural categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
B.7 Safety metrics re-computation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
DocID028066 Rev 1 3/59
4
Content UM1915
B.8 Work products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4/59 DocID028066 Rev 1
UM1915 List of Tables
List of Tables
Table 1. Terms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 2. List of STM8AF Assumed Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 3. Target safety metric values at the item level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Table 4. List of safety mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 5. List of general requirements for FFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Table 6. Level of detail in fRMethodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Table 7. IEC 60730 required safety mechanism for Class B/C compliance. . . . . . . . . . . . . . . . . . . 46
Table 8. IEC 60730 work product grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table 9. Some reference architectures for IEC 61508 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 10. Mapping between this document content and IEC 61508-2 Annex D
requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Table 11. IEC 61508 work product grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 12. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
DocID028066 Rev 1 5/59
5
List of Figures UM1915
List of Figures
Figure 1. Definition of the STM8AF as a SEooC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 2. Relationship between assumptions and SEooC development . . . . . . . . . . . . . . . . . . . . . . 11
Figure 3. STM8AF FTTI allocation and cycle time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 4. The fRMethodology flow for ISO 26262 and IEC 61508. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 5. Overview of the YOGITECH fRTool suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 6. Correlation matrix between SIL and ASIL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6/59 DocID028066 Rev 1
UM1915 About this document
1 About this document
1.1 Purpose and scope
This document describes how to use the STM8AF microcontrollers in the context of a
safety-related system, specifying the user's responsibilities for installation and operation, in
order to reach the desired safety integrity level.
This document is useful to system designers willing evaluate the safety of their solution.
1.2 Terms and abbreviations
Acronym Definition
AoU Assumptions to Use
ASIL Automotive Safety Integrity Level
CCF Common Cause Failure
COTS Commercial Off-the-Shelf
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DC Diagnostic Coverage
DTI Diagnostic Test Interval
FIT Failure In Time
FTTI Fault Tolerant Time Interval
FMEA Failure Mode Effect Analysis
FMEDA Failure Mode Effect Diagnostic Analysis
HFT Hardware Fault Tolerance
HW Hardware
INTC Interrupt Controller
LFM Latent Fault Metric
MCU Microcontroller Unit
MPF Multiple Point Failures
MPFDI Multiple Point Fault Detection Interval
NVIC Nested vector interrupt controller
PMHF Probabilistic Metric for random Hardware Failures
QM Quality Management
SFF Safe Failure Fraction
SIL Safety Integrity level
SEooC Safety Element Out of Context
SPF Single Point Fault
Table 1. Terms and abbreviations
DocID028066 Rev 1 7/59
58
About this document UM1915
Table 1. Terms and abbreviations (continued)
Acronym Definition
SPFM Single Point Fault Metric
SW Software
1.3 Reference normative
This document is written in compliance with the ISO 26262 international standard for
functional safety of electrical and/or electronic (E/E) systems within road vehicles.
The versions used as reference are:
ISO/IS 26262-1 – 9 :2011(E)
ISO/IS 26262-10:2012(E)
This Safety Manual follows the list of recommended contents in Annex A, clause A.3.10 of
ISO 26262-10.
The other functional safety standards considered in this manual are the following:
IEC 61508:1-7 © IEC:2010
IEC 60730-1:2010, ed. 4.0
1.4 Annexes
Annex 1. “STM8AF FMEDA snapshot handling Application Note”:
it provides clarifications, guidelines and examples on how to handle the Failure Mode
Effect Diagnostic Analysis (FMEDA) outcomes related to STM8AF microcontroller
family
Annex 2. “STM8AF FMEDA snapshot”:
it summarizes the common results of FMEDA activities
it provides all the necessary information, which will allow the reader to understand
how
to combine different scenarios, by using the FMEDA outcomes and to evaluate
the
costs and benefits at system-level.
8/59 DocID028066 Rev 1
UM1915 STM8AFxxxx device development process
2 STM8AFxxxx device development process
The development process of a microelectronic device that is used in safety critical
application, takes into account the adequate management, to reduce the probability of
systematic faults, introduced during the design phase.
ISO 26262-10 Annex A (“A.3.7: Example of techniques or measures to detect or avoid
systematic failures during design of a microcontroller”) acts as a guidance in tailoring the
microcontroller standard design and manufacturer process to the compliance of the ISO
26262 requirements. The checklist reported in the named Annex A (Table A.8) helps to
collect all related evidences of a given real process.
2.1 STMicroelectronics standard development process
STMicroelectronics (ST) serves four industry domains:
Standard products
Automotive products: ST automotive products are AEC-Q100 compliant. They are
submitted to a specific stress testing activity and processing instructions, in order to
achieve the
Automotive safety: a subset of the automotive domain. ST uses, as a reference, the
ISO 26262 Road vehicles functional safety standard. ST supports customers’ inquiries,
regarding product failure rates and FMEDA, to support hardware system compliance to
established safety goals. ST provides products that are safe in their intended use,
working in cooperation with customers, to understand the mission profile, adopt
common methods and define countermeasures for residual risks
Medical products: ST complies with applicable regulations for medical products and
applies due diligence in the development and validation of these products
required quality levels and product stability
STMicroelectronics product development process, compliant with the ISO/TS 16949
standard, is a set of interrelated activities dedicated to transform a customer specification
and a market or industry domain requirements into a semiconductor device with all its
associated elements (package, module, sub-system, application, hardware, software and
documentation), qualified respecting ST internal procedures and able to be manufactured,
using ST internal or subcontracted technologies.
2.2 YOGITECH fRMethodology process
YOGITECH fRMethodology is the “white-box” approach for safety design exploration.
proprietary of YOGITECH, including tools and methodology for FMEA/FTA analysis and
fault injection of integrated circuits. Appendix A Overview of fRMethodology reports
additional information.
YOGITECH contribution to ISO 26262 compliance of STMicroelectronics development
process can be summarized in failure rate estimation, based on multiple industry standards
as well as STMicroelectronics manufacturing data.
DocID028066 Rev 1 9/59
It is
58
STM8AF Safety Architecture UM1915
3 STM8AF Safety Architecture
This section describes the safety architectures that could be implemented, using the
STM8AF microcontroller for automotive applications.
3.1 Introduction
The STM8AF microcontroller described in this document is a Safety Element out of Context
(SEooC), that is, a safety element that can be used in different safety applications.
The aim of this section is to define the context of the analysis, in terms of assumptions with
respect to reference safety requirements as well as assumptions with respect to the design
external to that SEooC.
As a consequence of the SEooC approach, the goal is not to provide an exhaustive hazard
and risk analysis of the system around the microcontroller, but rather to list the
system-related information (such as the application-related assumptions for dangerousness
factors, frequency of failures and diagnostic coverage already guaranteed by the
application), that have been considered during the consecutive steps of the analysis.
3.1.1 Definition of the Safety Element out of Context
The automotive industry develops generic elements for different applications and for
different customers. These generic elements can be developed concurrently and by
different companies in different tiers of the supply chain, as a distributed development.
Assumptions are made both on the requirements (including safety requirements) on the
element at higher levels of design and also on the design external to the element.
In a safety context, these elements can be developed as a “Safety Element out of Context”
(SEooC), as described in ISO 26262-10, Clause 9.
According to ISO 26262, a “safety element out of context (SEooC)” is a safety-related
element that is not developed for a specific item (i.e. in the context of a particular vehicle). A
SEooC can be a system, an array of systems, a subsystem, a software component or a
hardware component.
This document considers the STM8AF as a SEooC, which is required to have an ASIL
capability, up to and including ASIL level B (i.e. it is to be used in an ASIL level A and ASIL
level B
environment).
3.2 STM8AF as a SEooC
The STM8AF is a general purpose RISC microcontroller, suitable for embedded applications
and, in particular, for safety related applications.
For a detailed description of the STM8AF functionality refers to the microcontroller technical
reference manual (RM0016).
In this document, the SEooC is identified as the STM8AF microcontroller (MCU),
as a functional block inserted in a system defined by the following Figure 1: Definition of the
STM8AF as a SEooC. The
data from sensors,
processing according to the implemented algorithm and taking
MCU acts as the processing unit of the system, acquiring field
references
10/59 DocID028066 Rev 1
UM1915 STM8AF Safety Architecture
decisions, sent to external actuators in the form of specific commands. The MCU is
connected directly or indirectly to
Figure 1. Definition of the STM8AF as a SEooC
sensors and actuators by communication busses.
Other components might be connected to the SEooC, like the external HW components
needed to guarantee either the functionality of the STM8AF (external memory, clock quartz
etc.) or its safety (for example the external watchdog, voltage supervisors).
3.3 Assumed safety requirements
A SEooC is developed, according to ISO 2626-10 clause 9, on the basis of assumptions of
intended functionality, use and context, including external interfaces (Figure 2: Relationship
between assumptions and SEooC development).
Figure 2. Relationship between assumptions and SEooC development
The validity of the aforementioned assumptions is checked, in the context of the actual
after the integration of the SEooC.
In this document, it is assumed that the concept specification, the Hazard&Risk analysis,
the overall safety requirement specification and the consequent allocation, have determined
the assumed safety requirements reported in Table 2: List of STM8AF Assumed
Requirements:
DocID028066 Rev 1 11/59
item,
58
STM8AF Safety Architecture UM1915
Table 2. List of STM8AF Assumed Requirements
ID Type Assumed Requirement
AR01
Assumed
requirement
The SEooC is defined as the STM8A MCU playing a role of processing unit,
as in Figure 1: Definition of the STM8AF as a SEooC
Failures in STM8AF HW part leading to wrong execution of the application
program and/or wrong data computations shall be mitigated to fulfil the ASILB
capability, i.e.
single-point fault metric at the HW part level at least 90%
AR02
Assumed
requirement
latent point fault metric at the HW part level at least 60%
AR03
AR04
AR05
AR06
Assumed
requirement
Assumed
requirement
Assumed
requirement
Assumed
requirement
The STM8AF is assumed to be integrated in a product with a lifetime up to 10
years
In accordance with ISO 26262-.5, 6.4.8 – Note 1, it is assumed that the
MPFDI (Multiple-Point Fault Detection Interval) is equal to or lower than to the
item's “power-up to power-down” cycle (i.e. 1 hour).
Safety Integrity Level required for the STM8AF is ASILB
It is assumed a FTTI budget allocated to the STM8A of 250 msec
(1)
It is assumed that the STM8AF implements a safe state defined as one in
which either:
AR07
Assumed
requirement
the application software running on STM8AF MCU is informed of the
presence of a fault and a reaction is possible
(2)
or
if the application software cannot be informed, the MCU reset is executed
AR08
1. FTTI value used for reference only. The end user shall verify that the FTTI value of the final application is
2. The end user shall take into account that hardware random failures affecting the STM8AF can compromise
3. According ISO 26262-1, the safe state is the operating mode of an item without unreasonable level of risk.
4. The possibility for SEooC to execute ASIL, QM and non-safety-related functions together, has been
Assumed
requirement
compatible with the requirements in terms of execution of periodical software-based test (refer to section
3.6).
the MCU capability of operating properly (for example failure modes affecting the program counter, prevent
the correct execution of software).
The ultimate definition of the safe state depends on the end user application.
excluded because not supported by dedicated hardware.
On the STM8AF SEooC ASIL, QM and/or notwill be not executed together
safety related software
(3)
(4)
3.3.1 The target safety metrics (ASIL, SPFM, LFM and PMHF)
According to the assumed requirement AR05 of the Table 2: List of STM8AF Assumed
Requirements), the target for the safety functions is ASILB; therefore every consideration
about absolute and relative safety metrics will take ASILB targets, as reported in Table 3:
Target safety metric values at the item level:
12/59 DocID028066 Rev 1
UM1915 STM8AF Safety Architecture
Safety metric defined
Single-point fault metric (SPFM) ≥ 90% ≥ 90% relative
Latent-fault metric (LFM) ≥ 60% ≥ 60% relative
Probabilistic Metric for
Failures (PMHF)
Table 3. Target safety metric values at the item level
random Hardware
Target value at
system level
100 FIT 10 FIT absolute
Target value at
SEooC level
Despite safety metrics are defined at item level (i.e. at car level) for ISO 26262, the
functional safety standard explicitly foresees the computation of those metrics at a lower
level.
In this document, any claim and computation in terms of safety metrics will be done on the
activity safety scope, represented by the SEooC block diagram reported in Table 1:
Definition of the STM8AF as a SEooC.
The budget of the PMHF given to the SEooC should be, if possible, less than 10% of the
overall PMHF budget of the safety goal and therefore (for ASILB) the budget for the
STM8AF is 10%*100 FIT = 10 FIT.
3.3.2 The assumed target time intervals (FTTI and MPFDI)
As illustrated in ISO 26262-1:2001 - Figure 4 - Fault reaction time and fault tolerant time
interval, a system must be able to detect faults and move to safe state before a fault can
become a system level hazard.
Metric type
In ISO 26262-1, the Fault Tolerant Time Interval (FTTI) is defined as the time-span in which
a fault, or faults, can be presented in a system before a hazardous event occurs.
Moreover, according to ISO 26262-1:2011, the Multiple-Point Fault Detection Interval
(MPFDI) is the time span to detect multiple-point fault before it can contribute to a multiplepoint failure.
From a system point of view, the STM8AF MCU is a safety-related element, to which it is
associated a portion of the FTTI system budget (see Figure 3: STM8AF FTTI allocation
and cycle time).
DocID028066 Rev 1 13/59
58
STM8AF Safety Architecture UM1915
Figure 3. STM8AF FTTI allocation and cycle time
Therefore, according to the above figure, the portion of the FTTI assigned to a SEooC (in
this case the STM8A) strongly depends on the application.
In this document, according to ISO 26262-10, 9.2.3.3 d), it is assumed that any
implemented safety mechanisms related to the STM8A will complete its functions in less
than the assigned FTTI budget time reported in the AR06 of the Table 2: List of STM8AF
Assumed Requirements).
This value must be considered as a reference one and thus can be changed by the
MCU/system integrator, according to his own needs.
It is worth noting that according to ISO 26262-5, 7.4.3.3 a single point fault shall be
within the FTTI budget allocated to the component.
In this document, in accordance with ISO 26262-.5:2011, 6.4.8 – Note 1, it is assumed that
the MPFDI is equal to or lower than the “power-up to power-down” cycle of the item (i.e. one
driving cycle, see AR04 of the Table 2: List of STM8AF Assumed Requirements).
3.4 Electrical specifications and environment limits
The user must not exceed the electrical specification and the environmental limits defined in
the below list, as reported in the STM8AF user manual, in order to guarantee its own
integrity:
Absolute maximum rating
Capacity
Operating conditions
detected
safety
Due to the large number of STM8AF part numbers, the related user manuals/datasheets
not listed in this document; users are responsible to carefully check the above reported
limits in the technical documentation on the related part number available on www.st.com.
14/59 DocID028066 Rev 1
are
UM1915 STM8AF Safety Architecture
3.5 Systematic safety integrity
Due to known device limitations for STM8AFxxxx automotive MCUs, the user must follow
the errata sheets (e.g. ES0143 for STM8AF6xxx and ES0144 for STM8AF5xxx series)
available on www.st.com,
in order to avoid the introduction of systematic failures.
3.6 Safety mechanisms/measures
This section lists all the safety mechanisms/measures (hardware, software and application
level) considered in the safety analysis of the microcontrollers of the STM8AF series.
According to ISO 26262-1, “…a safety mechanism is a technical solution implemented by
Electrical/Electronic (E/E) functions or elements, or by other technologies, to detect faults
or control failures in order to achieve or maintain a safe state”.
It is expected that users are familiar with the STM8AF architecture, and that this document
is used in conjunction with the related device datasheet, user manual and reference
information. Therefore, in order to avoid any mistake and reduce the amount of information
to be shown, no functional details are included in this document.
Note that the part numbers of the STM8AF series represent different combinations of
peripherals (for instance, some of them are not equipped with CAN peripheral). To reduce
the number of documents and avoid information-less repetitions, the current safety manual
(and therefore this section) addresses the overall possible peripherals available in the
targeted part numbers. Users have to select which peripherals are really available on their
devices, and discard the meaningless recommendations accordingly.
The implementation guidelines reported in the following section are for reference purpose
only.
Please, read the following definitions:
end user: the final user of STM8AF who is in charge of integrating the MCU in a
application (for example an electronic control board).
application software: the real software that runs on the STM8AF and that is
implement the safety function.
real
used to
3.6.1 STM8A CORE
Periodical core self-test software: CPU_SM_0
Permanent faults affecting the CPU are addressed through a dedicated software test,
executing a sequence of instructions and data transfers.
The software test is built around well-known techniques already addressed by
ISO 26262-5, D.2.3.1 (“Self-test by software: limited number of patterns (one channel)”).
The processing unit (CPU) is tested for functional correctness by applying at least one
pattern per instruction. The testing of the same class of instruction with multiple not-trivial
patterns, in order to involve each operand input and output bits, at least once equal to “0” e
once equal to “1”, is high recommended. The accumulation by means of not-trivial
computation (e.g. XOR) of the single instruction test result on the basis of the concept of
signature, is high recommended. The safety analysis of the CPU hardware has shown that a
stress-test for the pipeline structure is high recommended.
The overall test software suite is assumed to be periodically executed with a time period
compatible with the ISO 26262 requirements for the relationship between FTTI and the
diagnostic test interval (DTI).
DocID028066 Rev 1 15/59
58
STM8AF Safety Architecture UM1915
Control flow monitoring in application software: CPU_SM_1
A significant part of the failure distribution of STM8A core for permanent faults is related to
failure modes directly related to program counter loss of control or hang-up. Due to their
intrinsic nature, such failure modes are not addressed by a standard software test method,
based on the execution of sequences of instruction/data access and consequent checks.
Therefore it is necessary to implement a run-time control of the application software flow, in
order to monitor and detect deviation from the expected behavior. Linking this mechanism to
watchdog firing, assures that severe loss of control (or, in the worst case, a program
counter
hang-up) will be detected within DTI.
This diagnostic measure also contributes to the transient fault detection, affecting the
program counter and branch execution subpart in STM8A core.
The guidelines for the implementation of the method are the following:
The different internal states of the application software is well documented and
described (the use of a dynamic state transition graph is encouraged)
The monitoring of the correctness of each transition between different states of
the
application software is implemented
The transition through all expected states during the normal application software
program loop is checked
The function in charge of triggering the system watchdog is implemented, in order
constrain the triggering (preventing the watchdog reset) also to the correct
execution of
to
the above-described method for program flow monitoring
The use of the window feature of the independent watchdog (IWDG) (or an external one)
helps to implement a more robust control flow mechanism fed by a different clock source. In
any case the safety metrics do not depend on the watchdog in use (the adoption of
independent or external watchdog contributes to the mitigation of dependent failures, see
Section 4.2.2: Clock).
Double computation in application software: CPU_SM_2
A timing redundancy for safety-related computation is considered to detect transient faults
affecting the STM8A subparts devoted to mathematical computations and data access.
The guidelines for the implementation of the method are the following:
The requirement needs to be applied only to safety-relevant computation, that is the
ones that could interfere with the system safety functions. Such computation needs to
be therefore carefully identified in the original application software source code
Both mathematical operation and comparison are intended as computation
The redundant computation for comparison could be implemented according to the
following template:
– Original code:
If (VarA > VarB) then { ( execute function) }
– Modified code:
copyVarA:=VarA; copyVarB:=VarB;
If (VarA > VarB) then {
If (copyVarA <= copyVarB) then { (signal_error);
break } ( execute function)
}
16/59 DocID028066 Rev 1
UM1915 STM8AF Safety Architecture
The redundant computation is implemented by using copies of the original data for
second computation, and by using an equivalent formula if possible
End users are responsible to carefully avoid that the optimization features of the
used compiler removes the timing redundancy introduced according to this current
condition of use
Stack hardening for application software: CPU_SM_3
The stack hardening method is required to address faults affecting the CPU register bank.
This method is based on source code modification, introducing information redundancy in
register-passed information to the called functions.
The guidelines for the implementation of the method are the following:
Pass also the redundant copy of the passed parameters values (possibly inverted)
execute a coherence check in the function
Pass also the redundant copy of the passed pointers and execute a coherence check
in the function
For the parameters that are not protected by redundancy, it is recommended to implement
defensive programming techniques (plausibility check of passed values). For example
enumerated fields are to be checked for consistency.
and
Independent watchdog: CPU_SM_4
Using an external watchdog for the control flow monitoring method (CPU_SM_1)
contributes to further reduce potential common cause failures, because the external
watchdog will be clocked and supplied independently from the STM8AF.
3.6.2 Program FLASH memory
Periodical software test for Flash memory: FLASH_SM_0
Permanent faults affecting the system Flash memory (that is the memory cells and address
decoder) are addressed through a dedicated software test that checks the memory cell
contents versus the expected value, using signature-based techniques. The use of CRCbased encryption for signature is encouraged.
Without information about the frequency of usage of different occupied Flash sections, in
principle, all used Flash area is assumed to be tested with a time period compatible with the
ISO 26262 requirements for the relationship between FTTI and the diagnostic test
(DTI).
Control flow monitoring in application software: FLASH_SM_1
Permanent and transient faults affecting the system Flash memory (that is the memory cells
and address decoder) can interfere with the access operation by the CPU, leading to
data or instruction fetches. Such wrong data and operation, if able to heavily
the expected flow of the application software, are detected by strong control
mechanism linked to a system watchdog. For more detailed implementation guidelines
such technique refer to safety mechanism CPU_SM_1.
Note: The implementation of the CPU_SM_1 automatically involves the FLASH_SM_1
implementation.
interfere with
flow
interval
wrong
for
DocID028066 Rev 1 17/59
58
STM8AF Safety Architecture UM1915
3.6.3 Data EEPROM memory
Information redundancy: EEP_SM_0
To address permanent faults affecting the internal EEPROM bank it is required to implement
information redundancy techniques. Possible techniques are:
use redundant copies of safety relevant data and perform coherence check
organize data in arrays and compute and check checksum field before use.
before use
Due to their nature, data stored in EEPROM are typically managed directly by the end user
application software, therefore it is reasonable to rely on methods implemented in the final
software solution
Software read-back after write operation: EEP_SM_1
To address missing writes on EEPROM cells, it is required that the application software
executes a read-back of written data after an update of the EEPROM values. Missing writes
will be handled as a hardware fault.
3.6.4 RAM memory
Periodical software test for RAM memory: RAM_SM_0
To address permanent faults affecting RAM data cells and address decoder it is required to
execute a periodical software test on the system RAM memory. The selection of the
algorithm ensures the target coverage for both the RAM cells and the address decoder. The
end user provides also evidences of the effectiveness of the coverage of the selected
method.
The overall test software suite is assumed to be periodically executed with a time period
compatible with the ISO 26262 requirements for the relationship between FTTI and the
diagnostic test interval (DTI).
Stack hardening for application software: RAM_SM_1
The stack hardening method is used to enhance the application software robustness to
RAM faults affecting the address decoder. The method is based on source code
modification, introducing information redundancy in the stack-passed information to the
called functions. This method is relevant in case the combination between the final
application software structure and the compiler settings requires a significant use of the
stack for passing function parameters.
The guidelines for the implementation of the method are the following:
Pass also the redundant copy of the passed parameters values (possibly
execute a coherence check in the function
Pass also the redundant copy of the passed pointers and execute a coherence
in the function
For parameters that are not protected by redundancy, implement defensive
programming techniques such as the plausibility check of the passed values (for
example to check the consistency of enumerated fields)
18/59 DocID028066 Rev 1
inverted) and
check
Loading...