
STM8AF safety architecture
UM1915
14/43
UM1915 Rev 3
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’s 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).
Control flow monitoring in application software - CPU_SM_1
A significant part of the failure distribution of STM8AFcore 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) is detected within DTI.
This diagnostic measure also contributes to the transient fault detection affecting the
program counter and branch execution subpart in STM8AFcore.
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 to
constrain the triggering (preventing the watchdog reset) also to the correct
execution of 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
).
Double computation in application software - CPU_SM_2
A timing redundancy for safety-related computation is considered to detect transient faults
affecting the STM8AFsubparts devoted to mathematical computations and data access.