Home

STM32F1 series safety manual

1. specification Software 4 Fault class ate SM for SM for Component error Definitions Class B2 Class c Gaps Notes B C GPIO SM 1 H 2 18 13 GPIO SM 2 None 7 Input output Fault H 2 18 15 periphery conditions H 2 18 3 specified in NOE GPIO SM 1 ii 7 1 Digital O H 27 jeu Sips 7 H 2 18 12 pi aca H 2 18 22 H 2 18 2 H 2 18 13 ADC_SM_2 None 7 2 Analog I O Fault eee ADC SM 1 conditions H 2 18 3 ADC SM 3 In case of adoption of D A converter H 27 H 2 18 11 BE values are acquired by H 2 18 12 both MCUs H 2 18 22 cae H 2 18 13 ADC_SM_2 None 7 2 2Analog Wrong H 2 18 15 ADC SM 1 In case of adoption of multiplexer addressing H 2 18 3 ADC SM 3 DUAL SM O0 the analog H 2 18 8 or values needs to be H 2 18 22 DUAL_SM_0O acquired by both MCUs Any output outside the 8 Monitoring static ond H 2 18 21 WDG SM 1 devices and H 2 18 17 None dynamic CPU SM 5 comparators H 2 18 6 functional specification 9 Custom Any output N A Not applicable s outside the chips 5 static and for example dunama ASIC GAL y N A Not applicable functional Gate array 1 For fault error assessment some components are divided into their sub functions 2 Itis recognized that some of the addressed measures provide a higher level of assurance than required by this standard for Class B 3 Foreach sub function in the table the software class C measure will cover the software class B fault error Note
2. 0 0 0 eee eee 11 Definition of the compliant item illii ee 13 Abstract view of compliant item functions llli 14 Allocation and target for STM32 PST iusllssslllllle ee 15 Block diagram of safety characteristics for STM32F1 modules 45 The fRMethodology flow for IEC 61508 00 00 ee 52 Overview of the fRToolS 0 0000 ce eens 54 The HFT 0 1001 and 1001d architectures 0000 cee tee 55 The HFT 1 1002 and 1002d architectures 2 000000 cece eee 56 The HFT 1 2002 architecture 2 00000 cee 56 A possible voter structure combining PEvi and PEve 00 eee eee 57 Block diagram for IEC 13849 Cat B and Cat 1 00 0002s 61 Block diagram for IEC 13849 Cat 2 2 0 00 0c sees 62 Block diagram for IEC 13849 Cat 3 and Cat 4 00 00002 62 Block diagram for IEC 62061 Cat A naana annaa aaae 68 Block diagram for IEC 62061 Cat B 0 0002s 69 Block diagram for IEC 62061 Cat C 0 00 ee 69 Block diagram for IEC 62061 Cat D 0 te ees 70 SRECS high level diagram 2 0 eee 71 IEC 61800 architectural view 0 00 ccs 73 Correlation matrix between SIL and ASIL nananana anaa 84 a DoclD026823 Rev 2 UM1814 1 1 1 2 d About this document About this document Purpose and scope This document describes how to use the STM32F1 series microcontrollers in t
3. llis 38 3 6 29 Disable and periodic cross check of unintentional activation of unused peripherals ssssssses e hh nna 39 3 7 Conditions of use 1 1 eee 40 4 Safety resulis o 552b 08208 eee F9 Y CSS ai se eek a E EE 46 4 1 Hardware random failure safety results lille 46 4 1 1 Safety analysis result customization lille 47 4 1 2 General requirements for Freedom From Interferences FFI 47 4 2 Dependent failures analysis 0 00 0c cee eee 48 4 2 1 Power supply 202000 c eee n 48 4 2 2 COCK 23255 cade paw awe See ee hha eh lee 49 4 2 3 DIMA reae otek eka te eee ead ee echt r eee ee 49 4 2 4 Internal temperature 0 0 0 ee 49 5 List of GVIGGNCES 62 cccc7 scien RRRREER RARE SEIEEdIGS RE ewE NER E NR E 50 Appendix A Overview of fRMethodology eeeeeeeeeeeeeeese 51 A 1 The essence of fRMethodology lisse 51 A 2 fRMethodology and its flow llis 51 A TRIOOIS 2 idum ces n bers PEO EE ENE ERGO RE ESSE e E REA 53 Appendix B Examples of safety architectures Informative 55 Ky DoclD026823 Rev 2 3 90 Contents UM1814 B 1 Conceptual block diagrams of the target safety architectures 55 B 2 Considerations about voter implementation 57 Appendix C Change impact analysis for other safety standards 59 C 1 ISO 13849 1 ISO 13849 2 20 020 00 000 ee 59 C 1 1 Architect
4. 3 DoclD026823 Rev 2 UM1814 Reference safety architecture Figure 5 Block diagram of safety characteristics for STM32F1 modules FLASH Flash inferface MS35547V1 Lyr DoclD026823 Rev 2 45 90 Safety results UM1814 4 4 1 46 90 Safety results This section reports the results of the safety analysis of the STM32F1 series MCU according to IEC 61508 and to the Yogitech fRMethodology flow related to the hardware random and dependent failures Hardware random failure safety results The analysis for random hardware failures of STM32F1 series devices reported in this safety manual is executed according to Yogitech fRMethodology flow The main advantages of this flow described in details in Appendix A are the following e the component is split into elementary parts and the analysis is executed at such level of detail therefore with a more accurate granularity than typical approaches based on IEC 61508 tables where granularity is the subpart level e Verification of safety results by means of fault injection for both permanent and transient faults executed on the real netlist and RTL of real device e comparison of safety results coming from fault injection validation with those coming from estimation phase allowing a redundant double check In summary with the adoptions of the safety mechanism and conditions of use reported in Section 3 7 Conditions of use it is possible to achieve the integrity
5. e Latent faults those multiple point failures are not completely covered by the defined safety mechanisms and are usually not perceived by the driver Moreover these failures that are classified in IEC 61508 standard as no parts no effect are classified as safe failures as they do not affect results Considering the metrics computation the main differences between IEC 61508 and ISO 26262 are related to how the safe faults are computed and how the failure rate of diagnostic is computed with the mission The differences in failure rates related to hardware diagnostics are assumed to be negligible hardware native safety failures in STM32F1 series are very few and with very little weight in terms of gate counts Therefore the safety analysis already performed for SFF target can be reused for the SPF targets in ISO For such kind of Commercial Off the Shelf COTS microcontroller the natural target in ISO scenario is ASIL B 90 is the SPF target for permanent and transient and 60 for latent As these are the same targets as for 1001 SIL2 case one can assume that the same set of conditions of use safety mechanisms apply Metrics computations are detailed into the FMEDA for microcontrollers of the STM32F 1 series note that the resulting PMHF values comply with the expectations for an ASIL B MCU We can conclude that the ASIL B target is reachable with some constraints for the final application Note that safety diagnostic measures based
6. execute function Modified code copyVarA VarA copyVarB VarB If VarA gt VarB then If copyVarA lt copyVarB then signal_error break execute function j e The redundant computation for mathematical computation is implemented by using copies of the original data for second computation and by using an equivalent formula if possible e End users are responsible to carefully avoid that the intervention of optimization features of the used compiler removes the timing redundancy introduced according to this current condition of use ARM Cortex M3 HardFault exceptions CPU_SM_3 HardFault exception raise is an intrinsic safety mechanism implemented in ARM Cortex M3 core mainly devoted to intercept systematic faults due to software limitations and or error in software design leading for example to execution of undefined operations unaligned address access This safety mechanism is therefore able to detect hardware random faults inside the CPU bringing to such described abnormal operations Stack hardening for application software CPU SM 4 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 e Pass also the redundant copy of the
7. Information redundancy techniques on messages including End to End safing CAN SM 2 The CAN communications are protected by addressing both the permanent and transient faults with the redundant information technique that includes the End to End Safing For the implementation of redundant information it is possible to adopt a different approach e Multiple sending of the same message with comparison of the received results e Addition by the sender of a checksum field to the message to be verified by the receiver In case the checksum field approach is adopted the selection of the algorithm for checksum computation shall ensure a similar protection against message corruption as the one ensured by a full redundancy For End to End Safing additional measures are implemented e Additional field in payload allowing the unique identification of sender receiver and coherence check by receiver side e Timing monitoring of the message exchange for example check the message arrival within the expected time window e Check of the message consistence using a message counter in the additional payload field and checking the right sequence of messages on the receiver side The use of a safe communication protocol such as ProfiSAFE is recommended for the correct implementation of this safety mechanism USART 1 2 3 4 5 Periodical read back of configuration registers UART SM 0 This diagnostic measure that is typically referred to as
8. This safety standard does not mention safety metrics therefore there it is no need to recompute anything The possibility for a system to achieve Class B or Class C ranking is related to the adoption of a certain set of methods the qualitative table see Table H 1 in the standard lists the respective types of safety mechanism that need to be present in a Class B or C system Table 13 lists the requirements of the standard versus the target ranking B or C for the various parts functions of the STM32F1 series device that are detailed in Section 3 6 Description of hardware and software diagnostics In case the IEC 60730 requires a safety method not yet foreseen in the framework of the IEC 61508 safety analysis the gap is reported in the related field For sake of clarity the original text of the standard requirement is omitted in the table refer to standard Table 13 IEC 60730 required safety mechanism for Class B C compliance Software Component peas class Definitions ae Gaps Notes B C H 2 16 5 H 2 16 6 Stuck at X H2196 CPU SM 0 None H 2 19 8 2 H 2 18 15 H 2 18 3 1 CPU H 2 18 9 1 1 Registers H 2 19 5 CPU SM 1 H 2 19 7 CPU SM 5 DC fault X H2 19 4 or None H 2 19 2 1 DUAL SM 0 H 2 19 8 1 H 2 19 6 H 2 20 8 2 In case of single MCU architecture the safety mechanism CPU SM 0 H 2 18 15 described in the Manual 1 2 Instruction Wrong H 2 18 3 could be used but it shall decoding and decoding X H2 189 DUAL S
9. UM1814 Change impact analysis for other safety standards Table 13 IEC 60730 required safety mechanism for Class B C compliance continued Software 4 Fault class mios SM for SM for Component error Definitions Class B2 Class C9 Gaps Notes B Cc H 2 19 3 1 cT pit H 2 19 3 2 FLASH SM 0 None H 2 19 8 2 4 Memory FL 18 15 In case of adoption of 1 o 4 1 Invariable 99 6 H 2 18 3 DUAL SM 0 FLASH SM 0 memory coverage of H 2 19 5 allinformation H 2 194 1 or evidences shall be given PPP FLASH SM 0 about the 99 696 target emors mole of information errors H 2 19 8 1 H 2 19 6 DC fault H 21982 RAM SM 0 None H 2 18 15 4 2 Variable H 2 18 3 FOrSINgIE Met Solution the RAM_SM_0 memory DC fault H 2 19 5 roposed for IEC 61508 and dynamic H 2 19 7 DUAL_SM_o PIP needs to be enriched to cross links H 2 19 1 p H 2 19 21 add features like H 249 8 1 Abraham GALPAT FLASH SM 0 Stuck at H 2 19 18 2 en None 4 3 Addressing DUAL SM 0 relevant for variable and freee invariable H 2 18 4 4 FLASH SM 0 memory DC fault H 2 18 22 E None H 2 19 4 1 H 2 19 4 2 DUAL SMY H 2 19 8 1 Stuck at H 2 19 8 2 BUS_SM_1 None 5 Internal data H 2 18 15 DUAL SM 0 path H 2 18 3 or H 2 19 8 1 DMA SM 1 5 1 Data BG fault H 2 18 2 1 pma SM 3 None H 2 18 22 BUS SM 0 H 2 18 14 BUS SM 1 H 2 19 8 2 BUS SM 1 None H 2 18 15 5 2 Addressing Wrong H 2 18 3 DUAL SM 0 address and H 2 19 8 4 or Rane multiple H2181 4
10. method is implemented by constraining the use of DMA to the transfer of data packed covered by a redundancy check like CRC or similar techniques Note that other diagnostic measures on data communication peripherals potential DMA sources or destinations already foresee the implementation of information redundancy at message level therefore the overlap with those measures could reduce the potential complexity in the referred method implementation Information redundancy including sender receiver identifier on data packet transferred via DMA DMA SM 2 This method requires that the information redundancy introduced at message level therefore adding a checksum field to the message helps to identify inside the MCU the source and the originator of the message exchange that is which peripherals dialogs with the RAM or the CPU This is implemented by adding an additional field to the protected message with a coding convention for message type identification fixed at MCU level That is this method implements some virtual channel between the peripheral and the target Periodical software test for DMA DMA SM 3 This method requires the periodical testing of the DMA basic functionality implemented through a deterministic transfer of a data packet from one source to another for example from memory to memory and the checking of the correct transfer of the message on the target The data packets are composed by not trivial patterns avoi
11. A 7 4 the above described method is considered able to achieve high levels of coverage and it has to be verified by means of fault injection Information redundancy in intra chip data exchanges BUS SM 1 Both permanent and transient fault affecting the intra chip connection features Bus Matrix AHB APB bridges are addressed by information redundancy techniques implemented over the messages exchanged inside the MCU Lock mechanism for configuration options LOCK SM 0 The STM32F1 series MCUs feature spread protection to prevent unintended configuration changes for some peripherals and system registers for example PVD LOCK timers the spread protection detects systematic faults in software application and transient faults such as soft errors that cause some bit flip on registers during running time The use of this method is encouraged to enhance the end application robustness to systematic faults The method described in this section provides a marginal protection against permanent and transient faults affecting system interconnect bus Flexible Static Memory Controller FSMC Control flow monitoring in application software FSMC_SM_0 If FSMC is used to connect an external memory containing software code to be executed by the CPU permanent and transient faults affecting the FSMC memory controller are able to interfere with the access operation by the CPU leading to wrong data or instruction fetches The strong control flow mecha
12. In case the checksum field approach is adopted the selection of the algorithm for checksum computation shall ensure a similar protection against message corruption as the one ensured by a full redundancy Theoretic demonstrations on coverage capability are admitted the use of CRC coding is anyway suggested The above reported approaches are equivalent an additional criteria for the selection of the approach is the availability of a quick hardware support on the MCU platform and the evaluation of the computation capability of the external device with which the STM32F1 will exchange data Note that if the message is transferred by the DMA the implementation of this safety mechanism takes into account also the overlap of DMA related safety mechanism related to the message exchange inside the MCU and already declared as highly recommended 12C 1 2 Periodical read back of configuration registers IIC_SM_0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of I2C against their expected value previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic cov
13. MS33692V1 Ly DoclD026823 Rev 2 61 90 Change impact analysis for other safety standards UM1814 Figure 13 Block diagram for IEC 13849 Cat 2 Interconnecting means Im l Input device e g sensor L Logic Oo Output device e g main contactor m monitoring TE Test equipment OTE Output of TE MS33693V1 Figure 14 Block diagram for IEC 13849 Cat 3 and Cat 4 Im Interconnecting means 11 12 Input device e g sensor L1 L2 Logic 01 O2 Output device e g main contactor m monitoring cm cross monitoring MS33694V1 C 1 2 Safety metrics recomputation Appendix C of ISO 13849 presents tables of standardized MTTFd for the various electric electronics components However table C 3 in ISO 13849 points to ICs manufacturer s data while attempting to classify MTTFd for programmable ICs As a consequence Yogitech fRMethodology results even if native for IEC 61508 but definitely more and more accurate in the definition of dangerous failures identification can be re mapped in ISO 13849 domain When for a certain component PFH 1 we can assume that PFH is the opposite of MTTFd that is MTTFd 1 PFH years 62 90 DoclD026823 Rev 2 Ly UM1814 C 1 3 d Change impact analysis for other safety standards In IEC 61508 part 6 B 2 3 2 it is stated the system is made of components completely and quickly repairable with constant failure and repair rates for example dangerous detected failures
14. Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of USART against their expected value previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Protocol error signals UART SM 1 The UART protocol errors signals if used despite being conceived to detect physical layer related abnormal conditions are able to contribute to the detection to faults leading to error messages generation For instance option parity bit in data byte frame overrun error The handling at application level of such error signals is a common technique in embedded applications Their use is highly recommended DoclD026823 Rev 2 25 90 Reference safety architecture UM1814 3 6 10 Note 26 90 Information redundancy techniques on messages UART SM 2 The redundant information technique is used to protect the USART communications by detecting both the permanent and transient faults There are two different approaches to implement this technique e Multiple sending of the same message with comparison of the received results e Addition by the sender of a checksum field to the message to be verified by the receiver
15. This is not aligned with the assumptions of the report No repair not de energizing in case in case of a dangerous detected failure From the reliability theory MTTF the inverse of and PFH is a metric applicable only to not reparable systems Nowadays it is a common practice to use MTBF also for not reparable systems where MTBF has to be understood as the average time for the first and only failure of the equipment in this case MTBF is equal to MTTF Moreover the standard definition of diagnostic coverage 83 1 26 warrants the previously performed estimations for DC refer to 3 1 1 7 of this report obtained from fRMethodology application are still valid in the scope of ISO 13849 1 The DC for each single component has the same meaning of the IEC 61508 metric However this standard defines the concept of DCavg applicable to the whole SRP CS in the form of the equation defined in Annex E formula E 1 where the contribution of each part of the control system is weighted with respect to MTTF of the various subsystems of the channel The standard denies any possibility of fault exclusion while calculating DC4 IS013849 2 Tab D 21 no exclusion allowed and this is the same assumption of fRMethodology Application of fRMethodology to STM32F1 produces a complete classification of all possible failure modes without any exclusion being compliant to the standard s requirements It is necessary to calculate the DC only for subsystem made of a
16. or Acontinuous mode high demand SIL2 safety function CM2 or Alow demand SIL2 safety function LD2 The compliant item is used in a safety function with a worst case budget of 10 ms for the STM32 MCU to detect and react to a failure which corresponds to the portion of the Process Safety Time allocated to the STM32F1 MCU STM32F1 duty in Figure 4 Figure 4 Allocation and target for STM32 PST STM32 MCU duty End User duty MCU detection FW reaction SW reactio Actuator reaction ers lt gt OO ov i System level PST MSv35543V1 The compliant item is used in a safety function powered on for a long time It is assumed to not require any proof test and the lifetime of the product is considered to be not less than 10 years The safe state of the compliant item is the one in which either the operating system OS is informed by the presence of a fault and a reaction is possible or ifthe OS cannot be informed or the OS is not able to execute a reaction in case of a 1002 or 1002D architecture the PEv shall be directly informed so that the PEv itself is able to achieve or maintain the safe state of the system or in case of 1001 and 1002 1002D high demand or continuous mode architectures the safe state of the electronic system is de energize The compliant item is assumed to be analyzed according to routes 1H and 1S of IEC 615082 As explai
17. registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Software test for watchdog at startup WDG SM 1 This safety mechanism ensures the right functionality of the internal watchdogs in use At startup the software test programs the watchdog with the required expiration timeout stores a specific flag in the RAM and waits for the reset signal After the watchdog reset the software understands that the watchdog has correctly triggered and does not execute the procedure again Debug Independent watchdog DBG SM 0 The debug unintentional activation due to hardware random fault will result in the massive disturbance of the independent watchdog or alternately the other system watchdog WWDG or an external one Cyclic Redundancy Check module CRC CRC self coverage CRC SM 0 The CRC algorithm implemented in this module CRC 32 Ethernet polynomial 0x4C11DB7 offers excellent features in terms of error detection in the message Therefore permanent and transient faults affecting CRC computations are easily detected by each operation using the module to recompute the expected signature Dual MCU architecture Cross checking between two STM32F1 microcontrollers DUAL SM 0 In a dual MCU safety architecture the previously defined diagnostics are complemented by a cross check between the two MCUs The rationale behind this safety mechanism is to involve in the cross check both the sel
18. 2 MCUs architecture by applying the formula Dewey n DC ucuz MTT Fucus MTT Ficu2 D Cayg i 1 MTT Facu MTT Fucuz For two identical MCUs that is devices having the same DC and MTTF DCayg DC An evaluation of the possible common failure modes is required for any architectural solution implemented with two channels This standard defines a simplified approach with respect to IEC 61508 approach Table 7 of the IEC 13849 standard provides a simplified procedure for PL evaluation of SRP CS based on category DCgyg and MTTFd Each architectural solution analyzed by Yogitech with fRMethodology results in PFH producing high values of MTTF Work products Table 8 lists the work products required by the IEC 13849 and how to map these into available work products from IEC 61508 compliance activity DoclD026823 Rev 2 63 90 Change impact analysis for other safety standards Table 8 IEC 13849 work product grid ISO 13849 1 Information to be provided ISO 13849 1 Part Clause Safety functions provided by the SRP CS Characteristics of each safety function Exact points at which the safety related part s start and end Environmental conditions Performance level PL Category or categories selected STM32F1 series IEC 61508 document 10 Technical documentation End user responsibility Parameters relevant to the reliability MTTFd DC CCF and mission time Measures against systematic failure Technology
19. FCRS snd report Plan o analysis of Common Cause for o z Failures CCF phase A1 9 Be lt o E s Estimation of metrics g 2 3 DC SFF PFD H for HW Draft of 98 random failures Safety ww c 55 Manual Safety o 5 E 5 ge i w HW Architectural Manual Plan gee ss review M Annexes a 9 Fi 2 22 229 5 t c 2 m HP fRFMEA 2 calculation of metrics assessment M vo 3222555 predayout dev level amp SFFIDCIPFH Ee m SEEPSPP H zi ii m netlist 5 for HW random failures systematic 2 2s 3 2 faults e Besoess z 2 avoidance ES Oss oo 2 z 235 ul 5 and Safety Eisisbs 39978 5 t Validation of metrics case S iteportt o fault S SFF DC PFD H Safe PELO EEE d Injection 8 for HW random failures bein IU u Workload RFI with fault injection iu a z E z Final S 1 Regression of 3 afety Post layout analyses at analysis of assessment netlist post layout ee report layout infos level for phase A3 y Process Tools Activities Main Deliverables d 52 90 DoclD026823 Rev 2 UM1814 Overview of fRMethodology Table 6 Level of detail in fRMethodology Phase Input from customer Level of detail Accuracy of metrics Verification type Initial Estimated figures driven by info from standard Block diagrams A1 0 preliminary gate flip Part level and experience with similar flop count architectures Inspection detailed specifications More detailed esti
20. HDMI SM 2 Information redundancy techniques on m PA X X messages ADC SM 0 Periodical read back of configuration ds m X X a registers ADC SM 1 Multiple acquisition by application software X ADC SM 2 Range check by application software X X ADC SM 3 Periodical software test for ADC X ADC SM 4 1002 scheme for acquisition 0 o X X DAC SM 0 Periodical read back of configuration T dd X X registers DAC SM 1 DAC output loopback on ADC channel x x DMA SM 0 Periodical read back of configuration ch m X X iregisters Information redundancy on data packet DNI transferred via DMA ud ii E x DMA Information redundancy including DMA_SM_2 sender receiver identifier on data packet X X transferred via DMA DMA SM 3 Periodical software test for DMA X GTIM SM 0 Periodical read back of configuration a uae X X TIM6 7 registers GTIM SM 1 1002 for counting timers X X Periodical read back of configuration DAC ATIM SM 0 X X iregisters TIM1 2 3 4 5 8 9 10 1 ATIM SM 1 1002 for counting timers x x 1 12 13 14 15 16 17 ATIM SM 2 1002 for input capture timers X X ATIM SM 3 Loopback scheme for PWM outputs X X CRC SM 0 CRC self coverage X X d 42 90 DoclD026823 Rev 2 UM1814 Reference safety architecture Table 3 List of safety mechanisms continued r Sing
21. an electronic control board e application software the real software that runs on the STM32F 1 and that is used to implement the safety function Cortex M3 CPU Periodical core self test software CPU SM 0 Permanent faults affecting the CPU Core ARM Cortex M3 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 IEC 61508 7 A 3 2 Self test by software walking bit one channel A detailed safety analysis has shown that a self test software based only on software testing operation is not able to reach the required values of coverage due to the complexity of the CPU Therefore in order to reach the required values of coverage the self test software has to be specified by means of a detailed analysis of all the CPU failure modes and related failure modes distribution Moreover it has to be verified by means of fault injection according to ISO 26262 10 Annex A the state of the art in terms of safety analysis applied to integrated circuits fault injection is the recommended method for the verification of failure modes coverage in modern and complex microprocessor like Cortex M3 DoclD026823 Rev 2 17 90 Reference safety architecture UM1814 18 90 The overall test software suite is assumed to be periodically executed with a time period compatible with the IEC 61508 requirements for the relationship
22. and inspections 3 DoclD026823 Rev 2 UM1814 Overview of fRMethodology AppendixA Overview of fRMethodology This section provides an overview of Yogitech faultRobust Methodology fRMethodology A 1 The essence of fRMethodology The quality and completeness of the safety analysis is necessary to e identify the failure modes of a microcontroller e plan the corresponding mitigations and e establish their effectiveness that is their diagnostic coverage These are key points to consider for the functional safety applied to integrated circuits A typical black box functional safety analysis is based on the collection of data from block diagrams and component user manuals It assumes the following 1 an equal failure mode distribution 2 an equal split between dangerous and safe failures and 3 it claims a diagnostic coverage higher than 60 without a detailed quantitative analysis and accurate safety verification However the complexity of modern integrated circuits in terms of number of transistors CPU features bus architecture memory size and the complexity of the safety application are such that the adoption of a black box approach is no longer realistic A functional safety analysis exclusively based on the aforementioned items leads to an unacceptable gap between the estimated and measured safety integrity levels A SIL In stark contrast to the black box approach Yogitech enables the highest safety integrity
23. be assigned to one and or different categories and different PLs 3 The safety function is completely in the scope of the end user application 4 The STM32F1 series MCU with the adoption of safety mechanism described in this safety manual as single compliant item is by itself suitable for CM application up to PLd SIL2 The ISO 13849 architectural categories for Logic Solver are shown in Table 7 Table 7 IEC 13849 architectural categories Designated architecture of Logic Block diagram The main category occurrence of one i fault can lead to the loss of the safety Single channel architecture one MCU function in 1001 Somes No need of DC and CCF usually single Refer to Section 3 g channel MTTFd is low medium Compliant item s MTTFd high Highest achievable is PL b Enforcing category B requirements by adopting solutions based on well tried components for safety critical application Single channel architecture one MCU and well tried safety principles in 1001 A microprocessor is not classified as a Refer to Section 3 Figure 12 well tried component END No need of DC and CCF usually singe Compliant item s MTTFd high channel MTTFd is high Highest achievable is PL c With respect to category 1 itis expected to include in the architecture a test Single channel architecture one MCU equipment performing checks on the in 1001d 2 6 2 5 safety function and reporting its los
24. between PST and the diagnostic test interval Control flow monitoring in application software CPU SM 1 A significant part of the failure distribution of ARM Cortex M3 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 due to such faults 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 ARM Cortex9 M3 The guidelines for the implementation of the method are the following e The different internal states of the application software is well documented and described the use of a dynamic state transition graph is encouraged e The monitoring of the correctness of each transition between different states of the application software is implemented e The transition through all expected states during the normal application software program loop is checked e The function in charge of triggeri
25. can be decomposed leading to an item made of two ASIL B independent elements Thus end users can positively match SEooC assumptions in the form of STM32F1 series CoU refer to Section 3 7 Conditions of use Then the safety requirements of the system under development can integrate the STM32F1 series MCU together with the related safety mechanism defined in this manual in items performing up to ASIL D safety functions In the automotive domain hardware architectures that implement loops with two identical MCUs are rare When challenged with the highest ASIL requirements that are ASIL C 84 90 DoclD026823 Rev 2 Ly UM1814 C 5 1 C 5 2 3 Change impact analysis for other safety standards and or ASIL D automotive safety designers usually adopt a multi core MCU solution A practical application of this principle is the ECM implementing E GAS control strategy that relies on a dual core lock step MCU Architectural categories Not Applicable since ISO 26262 does not define any category Safety metrics recomputation Hardware metrics in ISO 26262 standard have been defined with a slightly different perspective that is mainly focused on the capability of identification of the following e Single Point Failures SPF those failures which occurrence leads to the violation of a safety goal e Dual multiple point failures a chain of two subsequent or more independent failures is required for the violation of the safety goal
26. faults that affect the configuration registers by detecting bit flips in the registers due to these transient faults The register test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Expected and unexpected interrupt check NVIC SM 1 According to IEC 61508 2 Table A 1 recommendations a diagnostic measure for continuous absence or cross over of interrupt must be implemented The method of expected and unexpected interrupt check is implemented at application software level It contributes to detecting both permanent and transient fault for all the above reported failure modes affecting interrupt handling The guidelines for the implementation of the method are the following e Thelist of the implemented interrupt for the MCU is well documented reporting also the expected frequency of each request when possible for example the interrupts related to ADC conversion completion therefore coming on a deterministic way e Individual counters are maintained for each interrupt request served in order to detect in a given time frame the cases of a no interrupt at all b too many interrupt requests babbling idiot interrupt source The control of the time frame duration shall be regulated according to the individual interrupt expected frequency e Interrupt vectors related to unused interrupt source point to a default handler that will report in case of triggering a faulty condition unexpecte
27. integrates the results into a comprehensive view for the portions of hardware injected Permanent transient and bridging fault models are supported e Vector Manager a tool that supports the fault simulation flow on which the Safety Verifier is based decoupling it from the actual verification environment The fault manager plugs into the customer s verification suite and allows the user to extract all the vectors being fed into the design whatever is the language used These vectors will be then used by the fault injector for the fault simulation DoclD026823 Rev 2 53 90 Overview of fRMethodology 54 90 Figure 7 Overview of the fRTools UM1814 Design Vector Manager Database Workload Fault lists gt Safety Designer Annotated Safety Verifier fault lists S DC DoclD026823 Rev 2 3 UM1814 Examples of safety architectures Informative Appendix B Examples of safety architectures Informative This section includes complementary information to Section 3 Note This section is informative only and the proposed architectures and or solution are to be considered just as an example B 1 Conceptual block diagrams of the target safety architectures From a principle point of view the safety architectures targeted in this document can be represented with one of the following block diagrams depending if an HFT 0 1001 1001d or HFT 1 1002 or 10024 architecture is
28. levels for integrated circuits to be achieved by means of its fRMethodology The Yogitech fRMethodology is a patented white box approach to perform and verify validate functional safety analyses and safety oriented design exploration of integrated circuits according to different functional safety standards In essence fRMethodology consists of e Dividing the component into elementary parts by using automatic tools to guarantee the completeness of the analysis e Computing the safety metrics by looking to the fault models of each elementary part attributing the failure rate the dangerousness and estimating the diagnostic coverage of the planned HW or SW safety mechanisms e Verifying Validating the safety metrics by an extensive fault injection campaign simulating permanent transient and common cause faults A 2 fRMethodology and its flow fRMethodology is approved by T V S D as the flow to assess and validate the safe failure fraction of given integrated circuit in adherence to IEC 61508 statement included in the certificate of Yogitech fRMEM product Z10 06 11 61674 001 fRMethodology has been extended by Yogitech to ISO 26262 benefiting from Yogitech active role as member of the ISO TC22 SC3 WG16 ISO 26262 international working group In the ISO 26262 international working group Yogitech is a leading author of the Annex A of part 10 that is DoclD026823 Rev 2 51 90 Overview of fRMethodology UM1814 about how to de
29. levels summarized in Table 4 Table 4 Overall achievable safety integrity levels MCUS used Safety architecture Target Safety analysis result SIL2 LD Achievable 1 1001 1001D SIL2 HD CM Achievable with potential performance impact SIL3 LD Achievable 1002 SIL3 HD CM Achievable with potential performance impact SIL3 LD Achievable 2 1002D SIL3 HD CM Achievable with potential performance impact SIL3 LD Achievable 2002 SIL3 HD CM Achievable with potential performance impact 1 Note that the potential performance impact related to some above reported target achievements is mainly related to the need of execution of periodical software based diagnostics refer to safety mechanism description for details The impact is therefore strictly related to how aggressive the system level PST is see Section 3 3 1 Assumed safety requirements The resulting metrics DC and SFF are not reported in this section but in the FMEDA and the same happens for absolute metrics PFH PFD due to e the large number of STM32F1 series devices e the possibility to declare not safety relevant unused peripherals and e the possibility to enable or not the different available safety mechanism The FMEDA calculation sheet can be provided on demand please refer to your local ST sales contact DoclD026823 Rev 2 Ly UM1814 Safety results 4 1 1 d Safety analysis result customization The saf
30. on periodical execution of software are executed at least once each FTTI As in the automotive domain this condition is easily achievable the STM32F 1 series devices are an effective solution for many applications Some typical automotive ASIL B examples are listed below e Electronics door closure failures affecting the Electronic Control Unit ECU normally generate ASIL A safety goals e Lighting ECU faults on lighting functions such as failure on driving or braking lights lead to safety goals ranked as ASIL B e Forward collision warning Advanced Driver Assistance System ADAS the safety goal of avoiding unattended deceleration can reasonably be ranked as ASIL B if decomposition is applied For the STM32F 1 series device the fulfillment of ASIL B latent faults metrics 60 is achieved according to Yogitech fRMethodology analysis results with the adoption of the same safety mechanism combination as the one that guarantees the microcontroller to be suitable for SIL2 applications DoclD026823 Rev 2 85 90 Change impact analysis for other safety standards UM1814 C 5 3 Work products Table 15 lists the work products required by the ISO 26262 standard and their mapping with the work products from IEC 61508 compliance activity Table 15 IEC 26262 work product grid IEC 26262 STM32F1 series Information to be provided IEC 26262 Part Clause IEC 61508 document Technical safety requirements specification 4 6 5 1 Technica
31. or technologies used All safety relevant faults considered STM32F1 series safety 10 Technical documentation manual Justification for fault exclusions see ISO 13849 2 10 Technical documentation End user responsibility Design rationale e g faults considered faults excluded Measures against reasonably foreseeable misuse Dated reference to this part of ISO 13849 that is ISO 13849 1 2006 Category B 1 2 3 or 4 Performance level a b c d or e 10 Technical documentation 11 Information for use STM32F1 series safety manual Use of de energization see ISO 13849 2 Measures for controlling the effects of voltage breakdown voltage variations overvoltage under voltage G 2 Measures for the control of systematic failures Measures for controlling or avoiding the effects of the physical environment for example temperature humidity water vibration dust corrosive substances electromagnetic interference and its effects Program sequence monitoring shall be used with SRP CS containing software to detect defective program sequences Measures for controlling the effects of errors and other effects arising from any data communication process see IEC 61508 2 2000 7 4 8 Failure detection by automatic tests G 2 Measures for the control of systematic failures End user responsibility G 2 Measures for the control of systematic failures STM32F1 series safet
32. sensor lines Range check by application software ADC SM 2 To address permanent faults affecting ADC module and also to address failure modes affecting the analogue section it is required that the application software executes a range of check plausibility checks on the measures coming from ADC acquisitions The guidelines for the implementation of the method are the following e The expected range of the data to be acquired are investigated and adequately documented Note that in a well designed application it is improbable that during normal operation an input signal has a very near or over the upper and lower rail limit saturation in signal acquisition e Ifthe application software is aware of the state of the system this information is to be used in the range check implementation For example if the ADC value is the measurement of a current through a power load reading an abnormal value such as a a current flowing in opposite direction versus the load supply may indicate a fault in the acquisition module e Asthe ADC module is shared between different possible external sources the combination of plausibility checks on the different signals acquired helps to cover the whole input range in a very efficient way The implementation of this safety mechanism is strongly application dependent Periodical software test for ADC ADC SM 3 To address permanent faults affecting ADC module and also to address failure modes affecting t
33. since these are complex electronics parts is classified as Type B Also the concept of HFT is derived from IEC 61508 as it is The development lifecycle depicted in 5 2 fig 2 matches with the realization phase phase 10 of the overall safety lifecycle IEC 61508 refer to part 1 figure 2 Annex A holds a cross reference table of the ISO 61800 5 2 produced document set in order to match the information content with respect to IEC 61508 requirements The strong link with the norm IEC 61508 is reflected also by the adoption in IEC 61800 5 2 of the same relevant metrics PFH ref to 6 2 1 and SFF ref to 6 2 3 C 3 1 Architectural categories The IEC 61800 standard provides an architectural view of PDS SR refer to figure 1 that is duplicated below in Figure 20 Figure 20 IEC 61800 architectural view PDS SR Control section Diagnostic functions EN Modulation External signals Communications and and control and I O a protection Power Power section IEC 1224 07 The purpose of this logic representation is to introduce the basic elements used to design PDS SR and it is deployed into a real system in the Annex B of the standard as an example of implementation of the standard safety function Safe Torque Off STO and related metrics DoclD026823 Rev 2 73 90 Change impact analysis for other safety standards UM1814 C 3 2 Safety metrics recomputation The PFH of a safety function performed by
34. steps e MCU2 compares the result of algorithm steps of MCU2 with the result of algorithm steps of MCU1 e MCU1 compares the result of algorithm steps of MCU1 with the result of algorithm steps of MCU2 The above referred algorithm steps are used to record intermediate safety related computation data and tracking information on the internal state of the application software algorithm Note that the latter can be derived from the available data already computed by the safety mechanism linked to control flow monitoring refer to Control flow monitoring in application software CPU_SM_1 Latent fault detection This safety manual is based on a safety analysis according to IEC 61508 ISO 26262 the reference for integrated circuit safety analysis considers also a metric for latent faults The latent fault is a multiple point fault which presence is not detected by a safety mechanism nor perceived by the driver within the multiple point fault detection interval In practical words the latent fault is a combination of a fault in a safety mechanism that by itself will NOT cause the violation of the safety goal function and a fault in the mission logic supervised by that safety mechanism Despite the lack of definition for latent fault metrics in IEC 61508 the robustness of a design against latent is considered as a key point in the safety community The following reported methods mainly address latent fault for the fo
35. such technique refer to safety mechanism CPU SM 1 in Control flow monitoring in application software CPU SM 1 ARM Cortex M3 Hardfault exceptions FLASH SM 2 Hardfault exception raise is an intrinsic safety mechanism implemented in ARM Cortex M3 core mainly devoted to intercept systematic faults that are due to software limitations and or error in software design leading for example to the execution of undefined operations unaligned address access This safety mechanism is therefore able to detect hardware random faults both permanent and transient that affect the system Flash memory cells and address decoder bringing to such described abnormal operations Option byte write protection FLASH SM 3 This safety mechanism prevents unintended writes on the option byte it addresses therefore systematic faults in software application and not hardware random faults affecting the option byte value during running time The use of this method is encouraged to enhance end application robustness for systematic faults DoclD026823 Rev 2 Ly UM1814 3 6 3 3 Reference safety architecture System SRAM memory Periodical software test for SRAM memory RAM SM 0 To address permanent faults affecting SRAM data cells and the address decoder it is required to execute a periodical software test on the system RAM memory The selection of the algorithm ensures the target SFF coverage for both the RAM cells and the address decoder The e
36. together are intended to be applied all together DoclD026823 Rev 2 Safety mechanisms separated by or word are alternative safety mechanism listed 81 90 Change impact analysis for other safety standards C 4 3 Work products UM1814 Table 14 provides the list of work products that are required by the IEC 60730standard and their mapping with the work products from the IEC 61508 compliance activity Table 14 IEC 60730 work product grid IEC 60730 5 2 Information to be provided IEC 60730 Part Clause STM32F1 series IEC 61508 document Purpose of control Tab 1 6 Construction of control and whether the control is electronic Tab 1 6a Which of the terminals for external conductors are for a wider range of conductor sizes than those indicated in the Tab 1 18 table of 10 1 4 For screw less terminals the method of connection and Tab 19 disconnection a End user responsibility Details of any special conductors which are intended to be i Tab 1 20 connected to the terminals for internal conductors Method of mounting control Tab 1 31 Method of providing earthing of control Tab 1 31a Method of attachment for non detachable cords Tab 1 32 Details of any limitation of operating time Tab 1 34 SIM32F 1 series satety manual Type 1 or Type 2 action Tab 1 39 Additional features of Type 1 or Type 2 actions Tab 1 40 Reset characteristics for cut out action Tab 1
37. up sensitivity measurement le Successful completion of the product qualification plan le Secure product deliveries on advanced technologies using stress methodologies to detect potential weak parts le Successful completion of electrical characterization le Global evaluation of new product performance to guarantee reliability of customer manufacturing process and final application of use mission profile le Final disposition for product test control and monitoring DoclD026823 Rev 2 MS33637V1 11 90 STM32F1 series microcontroller development process UM1814 2 2 12 90 Yogitech fRMethodology process Yogitech fRMethodology is the white box approach for safety design exploration proprietary of Yogitech including tools and methodology to FMEA FTA analysis and fault injection of integrated circuits Appendix A Overview of fRMethodology reports additional information Yogitech contribution to IEC 61508 compliance of STMicroelectronics development process can be summarized in these key elements e Failure rate estimation based on multiple industry standards as well as STMicroelectronics manufacturing data e Application of Yogitech fault injection techniques tools to validate the safety metrics claimed for STMicroelectronics devices belonging to STM32 program DoclD026823 Rev 2 3 UM1814 3 3 1 3 2 3 2 1 Reference safety architecture Reference safety architectu
38. 22 2 control functions which are intended to prevent an unsafe state of the controlled equipment Failure of the control function will not lead directly to a hazardous situation A pressure limiting and a door lock control are Class B control functions e Class C SH 2 22 3 control functions which are intended to prevent special hazards such as explosion or which failure could directly cause a hazard in the appliance Automatic burner controllers are one example of Class C functions For those systems implementing their control function by software the standard in SH 2 16 defines the set of applicable architectures The following list summarizes typical solutions for the design of Class B control functions e Single channel with functional test SH 2 16 5 A single CPU executes the software control functions as required A functional test is performed as the software starts It guarantees that all critical features are properly working e Single channel with periodic self test SH 2 16 6 A single CPU executes the software control functions but embedded periodical tests check the various critical functions of the system without impacting the performance of the fully planned control tasks e Dual channel homogeneous with comparison SH 2 16 3 The software is designed to execute identical control functions on two independent CPUs Both CPUs compare internal signals for fault detection before starting any safety critical task An exampl
39. 4 Reference safety architecture Information redundancy techniques on messages USB SM 2 The redundant information technique is used to protect the USB communications by detecting both the permanent and transient faults There are two different approaches to implement this method e Multiple sending of the same message with comparison of the received results e Addition by the sender of a checksum field to the message to be verified by the receiver In case the checksum field approach is adopted the selection of the algorithm for checksum computation shall ensure a similar protection against message corruption as the one ensured by a full redundancy Theoretic demonstrations on coverage capability are admitted the use of CRC coding is anyway suggested also looking to the availability of a quick hardware support on the MCU platform The above reported approaches are equivalent an additional criteria for the selection is the evaluation of the computation capability of the external device with which the STM32F1 will exchange data If the message is transferred by the DMA the implementation of this safety mechanism takes into account also the overlap of DMA related safety mechanism related to the message exchange inside the MCU and therefore its use is highly recommended Ethernet Media Access Control MAC Periodical read back of configuration registers ETH SM 0 This diagnostic measure that is typically referred to a
40. 43 Any limitation to the number or distribution of flat push on Tab 1 45 receptacles which can be fitted End user responsibility Any Type 2 action shall be designed so that manufacturing deviation and drift of its operating value operating time or operating sequence is within the limit declared in Tab 1 46 requirements 41 42 and 46 of Table 1 7 2 of the previous edition Extent of any sensing element Tab 1 47 Operating value or values or operating time Tab 1 48 mM seh T senos satoby manual Control pollution degree Tab 1 49 Rated impulse voltage Tab 1 75 Temperature for the ball pressure test Tab 1 76 End user responsibility Tab 1 78 Maximum declared torque on single bush mounting using thermoplastic material 82 90 DoclD026823 Rev 2 d UM1814 Change impact analysis for other safety standards Table 14 IEC 60730 work product grid continued IEC 60730 5 2 STM32F1 series Information to be provided IEC 60730 Part Clause EC 61508 document Pollution degree in the micro environment of the creepage or clearance if cleaner than that of the control and how this Tab 1 79 is designed Rated impulse voltage for the creepage or clearance if Tab 1 80 different from that of the control and how this is ensured The values designed for tolerances of distances for which Tab 1 81 the exclusion from fault mode short is claimed For SELV or PELV circuits the ELV limits realized Tab 1 86 Val
41. BUS SM 0 addressing n gi BUS SM 1 d H 2 18 22 79 90 DoclD026823 Rev 2 Change impact analysis for other safety standards UM1814 Table 13 IEC 60730 required safety mechanism for Class B C compliance continued Software 4 Fault class ate SM for SM for Component error Definitions Class B2 Class C9 Gaps Notes BIC H 2 19 8 1 Hamming H 2 19 4 1 Nana distance 3 H 2 18 2 2 H 2 18 14 6 External communication In case of adoption of oun su DUAL SM 0 the 6 1 Data H24942 CAN SM 2 communications are Hamming H 2 18 2 1 UART SM 2 Habs Pd uiam distance 4 H 2 18 15 lIC SM2 p H 2 18 3 SPI SM 2 individual safety Dex mechanism for UE EAE E peripherals the use of CRC32 is mandatory H 2 19 8 1 H 2 19 4 1 None H 2 18 2 2 H 2 18 14 6 2 Addressing Weond and H 2 19 4 2 In case of adoption of ng H 2 18 1 1 DUAL SM 0 the multiple DUAL SM 0 Pn addressin H 2 18 15 communications are 9 H 2 18 3 managed by both cores Wrong point H 2 18 10 4 in time H 2 18 18 CPU SM_1 j Nong Wrona point H 2 18 10 3 CPU_SM_1 i Sas P H 2 18 15 or None H 2 18 3 DUAL SM 0 6 3 Timing Wron H 2 18 10 2 se E H 2 18 10 4 CPU SM 1 None 3 H 2 18 18 Wron H 2 18 10 3 CPU SM 1 s Mm H 2 18 15 or None M H 2 18 3 DUAL SM 0 80 90 DoclD026823 Rev 2 Ky UM1814 Change impact analysis for other safety standards Table 13 IEC 60730 required safety mechanism for Class B C compliance continued
42. IEC 62061 Cat B Subsystem element 1 Adet Common cause failure Subsystem element 2 Ane2 MS33696V1 Figure 17 Block diagram for IEC 62061 Cat C pssc pei 1 DC rap T pen 1 DC PFHpsc Xpssc x lh Subsystem Subsystem element 1 element n A De1 A Den Diagnostic function s Lien ie hl a iam Se a p el Fe RA aw 9 indi nd i i im DoclD026823 Rev 2 MS33697V1 69 90 Change impact analysis for other safety standards UM1814 lian 128 5e x 2x DC x T 2 Ae x 1 SDC T4 Xs PFHpssp Apssp x 1h Ape is the dangerous failure rate of subsystem element 1 or 2 DC is the diagnostic coverage of subsystem element 1 or 2 Figure 18 Block diagram for IEC 62061 Cat D a Subsystem D Subsystem element Aver Diagnostic function s Subsystem element Ave2 ommon cause failure a ee ee ee eee MS33698V1 Note The subsystem element mentioned in Figure 15 Figure 16 Figure 17 and Figure 18 is the STM32F1 series device Based on IEC 62061 86 Figure 19 shows how to proceed with the development of SRECS implementing the generic control architecture depicted in figure B 1 of the standard d 70 90 DoclD026823 Rev 2 UM1814 Change impact analysis for other safety standards C 2 2 d Figure 19 SREC
43. M O explicitly implement also execution and execution PAN the equivalent class H 2 18 5 i test as described in H 2 18 5 this test it is not needed for IEC 61508 DoclD026823 Rev 2 77 90 Change impact analysis for other safety standards UM1814 Table 13 IEC 60730 required safety mechanism for Class B C compliance continued Software 4 Fault class mts SM for SM for Component error Definitions Class B2 Class c Gaps Notes B C H 2 16 5 H 2 16 6 Stuck at H 2 48 10 4 CPU SM 0 None H 2 18 10 2 1 3 Program counter H 2 16 7 CPU SM 1 H 2 18 10 3 CPU SM 5 DC fault H 2 18 9 Ob None H 2 18 15 H 2 18 3 DUAL SM 0 H 2 18 15 H 2 18 3 H 2 18 9 DUAL SM 0 1 4 Addressing DC fault H 2 16 7 or None H 2 18 22 BUS SM 0 H 2 18 1 1 H 2 18 1 2 H 2 18 15 H 2 18 3 1 5 Data paths po fault and H 2 18 9 DUAL M instruction execution H2467 or None decoding H 2 18 22 CPU SM 0 H 2 18 1 2 No interrupt or too H 2 16 5 frequent H 2 18 10 4 NVIC SM 1 i Bone interrupts 2 Interrupt No interrupt handling and ortoo execution frequent H 2 18 15 NVIC_SM_1 interrupts H 2 18 3 or None related to H 2 18 10 3 DUAL_SM_0 different sources bai H 2 18 10 1 frequency oan CPU SM 1 None for quartz H 2 18 10 4 dm 3 Clock synchronized i clock H 2 18 10 1 harmonics H 2 18 10 4 CPU_SM_I subharmonics H 2 18 15 7 or None PA DUAL_SM_0 only H 2 18 3 as 78 90 DoclD026823 Rev 2 Ly
44. PDS SR is evaluated by the application of IEC 61508 2 So Yogitech fRMethodology results can be re mapped in this domain Yogitech fRMethodology has an intrinsic high accuracy in catching the failures modes for a certain CPU since the powerful analysis performed at the design level identifies a very detailed list of them This detailed list of failures is more representative for STM32F1 series faults than the partial and arbitrary list provided in Table D 15 of this standard Moreover the definition of the diagnostic coverage reported in IEC 61800 5 2 3 3 indicates that the estimations for DC computed from fRMethodology refer to Appendix A in this document remain still valid in the scope of this standard The same applies for SFF refer to IEC 61800 5 2 3 15 End users can directly apply results coming from Yogitech fRMethodology refer to Section 4 1 Hardware random failure safety results and FMEDA C 3 3 Work products Table 12 lists the work products required by the IEC 61800 5 2 standard and their mapping with the work products from IEC 61508 compliance activity Table 12 IEC 61800 work product grid IEC 618000 5 2 STM32F1 series Information to be provided IEC 61800 5 2 Part Clause IEC 61508 document Safety requirements specification SRS for PDS SR including safety function requirements and safety integrity requirements Verification of PDS SR safety requirements 8 2 End user responsibility specification 6 Hardware d
45. S high level diagram pur Allocated functions and integrity requirements n VI M Ie TES tput Se xeu uu iii cese o s e eee pnaka Subsystem X SRECs Subsystem elements MS33689V1 Where the microprocessor here presented is an STM32F1 series device with the adoption of the safety mechanisms as defined in Section 3 7 Conditions of use Safety metrics recomputation Again as already seen in IS013849 is still considered valid the approximation 6 7 8 2 1 NOTE2 1 MTTF Where is assumed to be 1 gt AxT The failure rate A in T is the smaller proof test interval or the life time of the subsystem But from being PFH p X 1h again 1 PFH TTF Yogitech fRMethodology provides end users with results for the STM32F1 series even if native for IEC 61508 but definitely more and more accurate for the definition of dangerous failure identifications that can be re mapped in IEC 62061 domain Thus values of A and PFHD that are reported in the FMEDA refer to Section 4 Safety results are still valid and can be used into formulas of the previous paragraph There is no need for re computation for the SFF of a microcontroller The end user uses the same value resulting from the performed safety analysis with Yogitech fRMethodology As previously discussed in Section 4 2 Dependent failures analysis in evaluating CCF for those basic architectures with an HFT 1 the end user uses the same result if ava
46. Software of Configuration Registers executes a periodical check of the configuration registers of the Reset and Clock Control logic against their expected value previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Clock Security System CSS CLK SM 1 The Clock Security System CSS detects the loss of HSE and LSE clock activity and executes the corresponding recovery action such as switch off HSE and commute on the HSI For this reason it is able to detect potential abnormal situations e Loss of external clock e Abnormal activation of HSE or LSE despite being disabled by design The CSS detection of HSE or LSE abnormal condition is considered as equivalent to hardware faults and brings to similar recovery actions by the application software As these two above situations are potential source of common cause failure the adoption of this method is highly recommended Independent watchdog CLK SM 2 The independent watchdog is fed by a dedicated oscillator therefore major failures on clock generation at system level will not affect its behavior but may lead to a violation of the IWDG window for the key value write by the application software leading t
47. TMicroelectronics product development process Figure 16 Block diagram for IEC 62061 Cat B Figure 18 Block diagram for IEC 62061 Cat D d DoclD026823 Rev 2 89 90 UM1814 IMPORTANT NOTICE PLEASE READ CAREFULLY STMicroelectronics NV and its subsidiaries ST reserve the right to make changes corrections enhancements modifications and improvements to ST products and or to this document at any time without notice Purchasers should obtain the latest relevant information on ST products before placing orders ST products are sold pursuant to ST s terms and conditions of sale in place at the time of order acknowledgement Purchasers are solely responsible for the choice selection and use of ST products and ST assumes no liability for application assistance or the design of Purchasers products No license express or implied to any intellectual property right is granted by ST herein Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product ST and the ST logo are trademarks of ST All other product or service names are the property of their respective owners Information in this document supersedes and replaces information previously supplied in any prior versions of this document 2015 STMicroelectronics All rights reserved d 90 90 DoclD026823 Rev 2
48. User manual Cv UM1814 Sf i life augmented January 2015 STM32F1 series safety manual Introduction This document describes how to use the STM32F1 series microcontrollers in the context of a safety related system specifying the user s responsibilities for installation and operation in order to reach the targeted safety integrity level This manual applies to the STM32F1 series microcontrollers and STM32 SafeSIL part number If the STM32F1 series microcontrollers are used in adherence to this manual the system designer can avoid going into the details of the functional safety design and validation to give an estimation about the impact to the overall safety function This manual is written in compliance with IEC 61508 It also indicates how to use the STM32F1 series MCUs in the context of other functional safety standards such as safety machine directives ISO 13849 This manual and FMEDA data were developed in cooperation with the safety expertise company Yogitech using their faultRobust Methodology fRMethodology The safety analysis summarized in this manual takes into account the variation in terms of memory size internal peripheral number and presence and package between the different part numbers of the ARM Cortex M3 based STM32F1 series microcontrollers This manual has to be read along with the technical documentation on related part numbers such as Reference Manuals and Datasheets available on www st com DoclD026823 R
49. W Software module test report Software system integration test report Programmable electronic hardware and software integration tests report SW verification report End User responsibility because in charge of implementing software based diagnostics App J tab J 1 SW 65 90 Change impact analysis for other safety standards UM1814 C 2 66 90 IEC 62061 2012 11 This standard is applicable in the specification design and verification validation of Safety Related Electrical Control Systems SRECS of machines SRECS is the electrical electronic control system of the machine which failure could lead to reduction loss of safety SRECS implements a Safety Related Control Function SRCF to prevent any increase of the risk With respect of the safety lifecycle the scope of this standard is limited from safety requirements allocation to safety validation IEC 62061 is the special standard for the machine domain within the framework of the more generic IEC 61508 2010 Since it is just an application standard IEC 62061 is not strict with respect to the technical solutions Moreover it is focused on electrical electronic and programmable electronic parts of safety related control systems Note that 3 2 26 and 83 2 27 in IEC 62061 apply only to SRECS in HD OM suitable for the machines domain LD equipment are still ruled by IEC 61508 requirements The close relationship with IEC 61508 2010 is synthesized by the main a
50. _STM32F1_SIL2 3 are the following e no need to prove that the software diagnostics are developed according to IEC 61508 requirement The end user only refers to fRSTL STM32F1 SIL2 3 safety manual for all the applicable safety measures In general when targeting different safety standards end users can save time by consulting the available IEC 61508 work products documentation related to the fRSTL libraries development e noneedto provide evidences on the claimed diagnostic coverage The end user simply refers to fRSTL STM32F1 SIL2 3 safety manual for the coverage of all the applicable safety measures e easy integration of the diagnostic with the end user application software The fRSTL product architecture and implementation ease the integration and implementation of DoclD026823 Rev 2 87 90 fRSTL_STM32F1_SIL2 3 product and its use in the framework of this manual 88 90 UM1814 the flow control when integrating the execution of the safety measures together with the mission software e mitigation of the software diagnostic impact on system performances code size execution time because fRSTL are optimized Optimization comes from the application of the fRMethodology that allows the removal of redundant and overlapping checks Only the safety diagnostics that have a measurable and quantifiable incremental output in terms of coverage are implemented Table 17 presents the safety mechanisms based on fRSTL STM32 SIL2 3 that ca
51. a op Ra grew UR e be ee EA A ey ee A eek Y 9 Table 3 List of safety mechanisms lise 40 Table 4 Overall achievable safety integrity levels l l 46 Table 5 List of general requirements for FFl 0002 e eee eee 47 Table 6 Level of detail in fRMethodology 0 cece eee 53 Table 7 IEC 13849 architectural categories 1 2 0 eae 60 Table 8 IEC 13849 work product grid 0 eee 64 Table 9 SIL classification versus HFT 0 0 cette 66 Table 10 IEC 62061 architectural categories 1 0 0 0 nee 67 Table 11 IEC 62061 work product grid 0 2 eee 72 Table 12 IEC 61800 work product grid 0 eee 74 Table 13 IEC 60730 required safety mechanism for Class B C compliance 77 Table 14 IEC 60730 work product grid 0 2 eee 82 Table 15 IEC 26262 work product grid 0 ce nee 86 Table 16 fRSTLs differentiation factors 2 0 Ih 87 Table 17 List of STM32F1 series safety mechanism overlapped by fRSTL STM32F1 SIL2 3 e cieee eee 88 Table 18 Document revision history lllieeeeeee n 89 ky DoclD026823 Rev 2 5 90 List of figures UM1814 List of figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 6 90 STMicroelectronics product development process
52. al with microcontrollers in the context of an ISO 26262 application Moreover Yogitech extended both IEC 61508 and ISO 26262 requirements to analogue circuits thanks to its consolidated experience in analogue design and analogue verification In essence the fRMethodology flow is intended to assist engineers in making the safety case for their designs with regard to the functional safety standards ISO 26262 and IEC 61508 It comprises e Splitting the component or system into elementary parts e _ Identifying the respective fault models and failure modes e Estimating the failure modes distribution e Using the relevant failure mode data to compute safety metrics e Performing sensitivity analyses by changing architectural and or technology parameters e Verifying the results by fault injection Figure 6 summarizes the flow and Table 6 shows the level of detail of the analysis required at each phase Figure 6 The fRMethodology flow for IEC 61508 Product Definition of Safety Initial safety Architecture initial safety assessment P o requirements first report lanning of D estimation of metrics next steps 2 DC SFF PFD H Safety identification of critical Architecture E S safety gaps amp solutions ni Z o g Specification of the Safety Safety FMEAIFTA Requirements assessment safety o high level SIRS SFRS
53. ause it can affect many MCU parts and therefore lead to not independent failures The safety mechanism to be used to mitigate this potential effect is the following e VSUP SM 3 the internal temperature read and check allow the user to quickly detect potential risky conditions before they lead to a series of internal failures Refer to Section 3 6 22 Supply voltage system for the detailed safety mechanism descriptions DoclD026823 Rev 2 49 90 List of evidences UM1814 5 50 90 List of evidences The Safety Case Database stores all the information related to the safety analysis performed to derive the results and conclusions reported in this safety manual In detail the Safety Case Database is composed of the following Safety Case with the full list of all safety analysis related documents Yogitech internal FMEDA tool database for the computation of the safety metrics including the estimated and measured values Safety Report the document that describes in detail the safety analysis executed on STM32F1 series devices and the clause by clause compliance to IEC 61508 All paper works academic studies and Yogitech internal white papers application notes quoted in the Safety Report to support the analysis Yogitech internal fault injection campaign database including Safety Verifier settings injection logs and results The above described contents are not publicly available and are available for possible competent bodies audit
54. cept recommendations reported in Section 3 6 Description of hardware and software diagnostics The conditions of use to be applied to STM32F1 series MCUs are reported in the form of safety mechanism requirements The single MCU dual MCU columns address the related architecture and have the following meaning e M this safety mechanism is always operating during normal operations no end user activity can deactivate it e tt Highly recommended being a common practice and considered in this safety manual for the computation of the safety metrics e Recommended as additional safety measure but not considered in this safety manual for the computation of safety metrics Users of STM32F1 series can skip the mechanism in case it is in contradiction with functional requirements e o optional not needed The X marker in the Perm and Trans columns in Table 3 indicates that the related safety mechanism is effective for such fault model Table 3 List of safety mechanisms Periodical software test addressing CPU SM O0 permanent faults in ARM Cortex M3 CPU t X core CPU SM 1 Control flow monitoring in application oe dk X X software p m ARM Cortex M3 CPU SM 2 Double computation in application m m X software CPU SM 3 ARM Cortex M3 HardFault exceptions M M X X CPU SM 4 Stack hardening for application software X X CPU SM 5 External watchdog 0 o X X CPU_SM_6 MPU d
55. d interrupt e In case an interrupt service routine is shared between different sources a plausibility check on the caller identity is implemented e Interrupt requests related to not safety relevant peripherals are handled with the same method here described despite their originator safety classification in order to decrease the complexity of this method implementation the use of polling instead of interrupt for not safety relevant peripherals is suggested DMA Periodical read back of configuration registers DMA SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers is implemented by executing a periodical check of the configuration registers of the DMA peripheral against its expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses the transient faults that affect the configuration registers by detecting bit flips in the registers due to these transient faults The register test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Information redundancy on data packet transferred via DMA DMA SM 1 The information redundancy required on the DMA data transfer cannot be implemented in line with the DMA concept with multiple transfers of the same data block Therefore this DoclD026823 Rev 2 23 90 Reference safety architecture UM1814 3 6 8 24 90
56. d the use of 0x0000 OxFFFF values and organized in order to allow the detection during the check of the following failures e Incomplete packed transfer e Errors in single transferred word e Wrong order in packed transmitted data The use of CRC packet protection is a way to simplify such checking operations CAN1 2 Periodical read back of configuration registers CAN SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of CAN peripheral against its expected value that is previously stored in the RAM and adequately updated after each configuration change It mainly addresses the transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The register test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Protocol error signals CAN SM 1 The CAN protocol error counters which are entirely managed by the module at hardware level despite being conceived to detect network related abnormal conditions are able to contribute to the detection of the faults that lead to error messages generation The handling at application level of such error signals is a common technique in embedded applications Their use is highly recommended 3 DoclD026823 Rev 2 UM1814 3 6 9 3 Reference safety architecture
57. decoder are addressed through a dedicated software test that checks the memory cell contents versus the expected value using signature based techniques According to IEC 61508 2 Table A 5 the effective diagnostic coverage of such techniques depends on the width of the signature in relation to the block length of the information to be protected therefore the signature computation method is to be carefully selected Note that the simple signature method IEC 61508 7 A 4 2 Modified checksum is inadequate as it only achieves a low value of coverage The information block does not need to be addressed with this test as it is not used during normal operation no data program fetch Without information over the frequency of usage of different occupied Flash sections in principle all used Flash area are assumed to be tested with a time period compatible with the IEC 61508 requirements for the relationship between PST and the diagnostic test interval 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 wrong data or instruction fetches Such wrong data and operation if able to heavily interfere with the expected flow of the application software are detected by strong control flow mechanism linked to a system watchdog For more detailed implementation guidelines for
58. e of Class B control function is the prevention of the overheating for an electrical motor The control system can be implemented by dual channel architecture with two STM32F1 series devices One channel monitors the temperature from the embedded sensor in the coils the other channel constantly measures the current of the rotor In case one channel fails the other channel is still able to perform its control function and stop the motor when overheated For Class C control functions the adequate architectural solutions are listed hereafter The comparison can be achieved by a comparator or by software e Single channel with periodic self test and monitoring SH 2 16 7 e Dual channel homogeneous with comparison H 2 16 3 e Dual channel diverse with comparison SH 2 16 2 Implementing a Class C control system based on a single channel architecture that comprises one single STM32F 1 series is possible but it requires to introduce some robust diagnostic measures to ensure that the software control function works properly Monitoring the software control function to prevent any fault is required to avoid the occurrence of the hazardous event The standard states the need for control measures see SH 11 12 2 and explains how to avoid faults errors for Class B or Class C software control functions see SH 11 12 3 DoclD026823 Rev 2 Ly UM1814 C 4 2 Change impact analysis for other safety standards Safety metrics recomputation
59. e two channels or in the shared logic Ifthe fault has been identified as a transient fault the compliant item can be reset and the safety function can continue after reset Ifthe fault has been identified as a permanent fault or if it has not been identified the compliant item is assumed to be kept de energized and the compliant item cannot be repaired that is the faulty STM32F1 MCU cannot be replaced or one of the external components cannot be replaced 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 STM32F1 user manual in order to guarantee the STM32F1 series safety integrity e Absolute maximum rating e Capacity e Operating conditions Due to the large number of STM32F1 part numbers the related user manuals datasheets are 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 d DoclD026823 Rev 2 UM1814 3 5 3 6 3 6 1 Reference safety architecture Systematic safety integrity According to the requirements of IEC 61508 2 7 4 2 2 the Route 1s has been considered in the STM32F 1 development and the techniques and measures given in IEC 61508 2 Annex F have been applied The Safety Case Database Section 5 List of evidences maintains the evidences
60. em and or assumptions on which analysis of the behavior or failure rates of the item are based Seguon 2 2 D2 2 a the failure modes of the compliant item due to random hardware failures that result in a failure of the function and that are not detected by diagnostics internal to the compliant item D2 2 b for every failure mode in a an estimated failure rate D2 2 c the failure modes of the compliant item due to random hardware failures that result in a failure of the function and that are detected by diagnostics internal Section 3 7 to the compliant item D2 2 d the failure modes of the diagnostics internal to the compliant item due to random hardware failures that result in a failure of the diagnostics to detect failures of the function D2 2 e for every failure mode in c and d the estimated failure rate D2 2 f for every failure mode in c that is detected by diagnostics internal to the compliant item the diagnostic test interval Section 3 2 2 D2 2 g for every failure mode in c the outputs of the compliant item initiated by the internal diagnostics Appendix B D2 2 h any periodic proof test and or maintenance requirements D2 2 i for those failure modes in respect of a specified function that are capable Section 3 7 of being detected by external diagnostics sufficient information shall be provided to facilitate the development of an external diagnostics capability D2 2 j the hardware fau
61. ements specification 6 10 1 Software based parameterization 6 11 2 4 Software configuration management items 6 11 3 2 2 Suitability of software development tools 6 11 3 4 1 Documentation of the application program 6 11 3 4 5 Results of application software module testing 6 11 3 7 4 Results of application software integration testing 6 11 3 8 2 Documentation of SRECS integration testing 6 12 1 3 Documentation of SRECS installation 6 13 2 2 Documentation for installation use and maintenance 7 2 Documentation of SRECS validation testing 8 2 4 Documentation for SRECS configuration management 9 3 1 End User responsibility d 72 90 DoclD026823 Rev 2 UM1814 Change impact analysis for other safety standards C 3 IEC 61800 5 2 2007 The scope of this standard is the functional safety of adjustable speed electric drive systems Part 5 2 of the IEC 61800 defines the requirements for the design development integration and validation of the safety related parts for power drive speed applications PDS SR within the framework of IEC 61508 first edition More precisely this part of IEC 61800 just limits its application to those PSD RS operating in HD CM ref to 3 10 NOTE1 implementing safety functions with a target integrity up to SIL 3 Form the architectural point of view this limitation is reflected in two tables 6 2 2 3 Tab 3 and Tab 4 for the two different types of classified devices The CPU or the whole microcontroller
62. er and performs a coherence check on the measured data at application level To reduce the potential effect of the common cause failure it is suggested for the redundant check to use a channel belonging to a different timer module and mapped to not adjacent pins on the device package DoclD026823 Rev 2 33 90 Reference safety architecture UM1814 3 6 20 34 90 Loopback scheme for PWM outputs ATIM_SM_3 This method uses a loopback scheme to detect permanent and transient faults on the timer channels used for wave generations PWM It is implemented by connecting the PWM to a separate channel either in the same or in another timer to acquire the generated waveform characteristics The guidelines for the implementation of the method are the following e Both frequency and duty cycle of PWM are measured and checked versus the expected value e To reduce the potential effect of common cause failure it is suggested to use for the loopback check a channel belonging to a different timer module and mapped to not adjacent pins on the device package This measure can be replaced under the end user responsibility by different loopback schemes already in place in the final application and rated as equivalent For example if the PWM is used to drive an external power load the reading of the on line current value can be used instead of the PWM frequency measurement GPIO PORT A B C D E F G Periodical read back of configuration re
63. er DTI in order to be able to claim the related diagnostic coverage DAC output loopback on ADC channel DAC SM 1 To address permanent faults affecting DAC modules and also to address failure modes affecting the analogue section it is required to implement a loopback scheme where the output analogue value of DAC is acquired by one channel of the ADC and checked versus its expected value This test is executed periodically each time the DAC value is updated and at least once per DTI TIM 6 7 Periodical read back of configuration registers GTIM SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of TIMER against their expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage 1002 for counting timers GTIM SM 1 This method provides a high level of coverage for both permanent and transient faults on the addressed timers The method is conceived to protect the timers used for counting features for example the timers dedicated to maintain a system time base and or to generate a timed interrupt for the execution of
64. er Section 3 3 1 Assumed safety requirements of this Manual Table 10 IEC 62061 architectural categories Block Ref Summary Basic architecture of Logic diagram Single channel architecture one MCU in 1001 n 1 Equivalent of 1001 with HFT 0 1 no diagnostic function s PFH pssa Ape Gn 6 7 8 2 2 Overall PFHpssa is the boi Figure 15 probability of dangerous failure of SILCL 1 if SFF lt 90 MCU SILCL 2 if 90 lt SFF lt 99 SILCL 3 if SFF 2 99 Dual channel architecture with two identical MCUs SILCL 1 if SFF lt 60 SILCL 2 if 6096 s SFF 9096 Equivalent to 1002 with HFT 1 SILCL 3 if SFF 2 90 a single failure does not lead to In this case a m the loss of SRCF igure Aner Aner Ane No diagnostic function s B 6 7 8 2 3 Ansa 07 B X Ag X Ty BX Ang For B factor see Section 4 2 d DoclD026823 Rev 2 67 90 Change impact analysis for other safety standards Table 10 IEC 62061 architectural categories continued UM1814 Cat Ref S Summary It is the equivalent of 1001d with a diagnostic function that initiates a reaction function as a dangerous failure happens on SRCF NOTE diagnostic function provides the Logic Solver with a diagnosis of an external subsystem e g the actuator 6 7 8 2 4 Any single failure does not lead to a loss of the SRCF it is equivalent to 1002d with HFT 1 with diag
65. erage Protocol error signals IIC_SM_1 The I2C protocol errors signals despite being conceived to detect physical layer related abnormal conditions are able to contribute to the detection of faults leading to error messages generation such as for instance the ACK assertion phase and related checks The handling at application level of such error signals being a common technique in embedded applications their use is highly recommended the adoption of SMBus protocol if available on the selected 12C module and compatible with the external connected devices is a way to get available additional hardware based error checking mechanisms Information redundancy techniques on messages IIC SM 2 The redundant information technique is used to protect the I2C communications by detecting both the permanent and transient faults There are two different approaches to implement this method e Multiple sending of the same message with comparison of the received results e Addition by the sender of a checksum field to the message to be verified by the receiver DoclD026823 Rev 2 Ly UM1814 Reference safety architecture In case the checksum field approach is adopted the selection of the algorithm for checksum computation shall ensure a similar protection against message corruption as the one ensured by a full redundancy Theoretic demonstrations on coverage capability are admitted the use of CRC coding is anyway suggested also lookin
66. ery actions e CLK SM 2 the independent watchdog has a dedicated clock source The frequency alteration of the system clock leads to the watchdog window violations by the triggering routine on the application software leading to the MCU reset by watchdog The adoption of such safety mechanism is therefore strongly recommended despite their minor contribution to the safety metrics to reach the required safety integrity level In particular the use of system watchdog WWDG increases the overall capability to keep the program flow under control Refer to Section 3 6 23 Reset and clock control subsystem for detailed safety mechanisms description DMA DMA is a widely shared resource involved in data transfers operated mainly by all peripherals Failures of DMA interfere with the behavior of the system peripherals leading to not independent failures The safety mechanisms addressing such independent failures which are described in Section 4 1 2 General requirements for Freedom From Interferences FFI guarantee the Freedom from Interference e DMA SM 0 e DMA SM 1 e DMA SM 2 The adoption of such safety mechanism is therefore strongly recommended despite their minor contribution to the safety metrics to reach the required safety integrity level Refer to Section 3 6 7 DMA for detailed safety mechanisms description Internal temperature The abnormal increase of the internal temperature is a potential source of dependent failures bec
67. es of dependent failures These are analyzed in the following sections The referred safety mechanisms are described in detail in Section 3 6 Description of hardware and software diagnostics Power supply Power supply is a potential source of dependent failures because any alteration of the power the supply can affect many parts leading to not independent failures The following safety mechanisms address and mitigate those dependent failures e VSUP SM 1 detection of abnormal value of supply voltage e VSUP_SM_2 the independent watchdog has a different supply source from the digital core of the MCU and this diversity helps to mitigate dependent failures related to the main supply alterations The adoption of such safety mechanisms is therefore strongly recommended despite their minor contribution to the safety metrics to reach the required safety integrity level Refer to Section 3 6 22 Supply voltage system for the detailed safety mechanism descriptions d DoclD026823 Rev 2 UM1814 4 2 2 4 2 3 4 2 4 d Safety results Clock System clocks are a potential source of dependent failures because alterations in the clock characteristics frequency jitter can affect many parts leading to not independent failures The following safety mechanisms address and mitigate those dependent failures e CLK SM 1 the clock security system is able to detect hard alterations stop of system clock and activate the adequate recov
68. esign on an architectural level Software design on an architectural level IEC 61508 3 Pre estimation of the probability of failure of safety functions due to random hardware failures on a level IEC 61508 2 of functional block diagrams Detailed planning of the validation of safety related PDS SR End User responsibility Hardware design STM32F1 series safety manual Software design manual Ly 74 90 DoclD026823 Rev 2 UM1814 Change impact analysis for other safety standards Table 12 IEC 61800 work product grid continued IEC 618000 5 2 STM32F1 series Information to be provided IEC 61800 5 2 Part Clause FC 61508 document Reviews of the system design Functional tests on module level 8 2 Integration and test of the safety related PDS SR Review of HW SW integration test results and 82 documentation i Develop user documentation describing PDS SR installation commissioning operation and 7 maintenance Complete software and appropriate documentation Documentation of the results of the validation tests Validation tests and procedures according to the End user responsibilit validation plan p y Documentation of the results of the validation tests Subsystem testing plan Integration testing plan Validation testing plan Configuration testing plan Detailed results of each test Any discrepancy between expected and actual results Conclusion of the
69. esults UM1814 4 2 4 2 1 48 90 Table 5 List of general requirements for FFI continued Diagnostic Description DMA_SM_1 Information redundancy on data packet transferred via DMA Information redundancy including sender receiver identifier on data packet DMA_SM_2 transferred via DMA GPIO SM 0 Periodical read back of configuration registers Dependent failures analysis The analysis of dependent failures is important for microcontrollers The main sub classes of dependent failures are the Common Cause Failures CCF Their analysis is ruled by the IEC 61508 2 annex E that lists the design requirements to be verified to allow the use of on chip redundancy for ICs with one common semiconductor substrate However based on an agreement discussed by Yogitech with T V Sud Automotive in the past the annexes E 1 and E 2 apply for HFT 1 while the Annex E 3 shall be applied to every on chip redundancy intended also in terms of diagnostic implemented on the same silicon As there is no on chip redundancy on STM32F1 series devices the CCF quantification through the BetalC computation method is not required Note that in the case of Dual MCU architectures implementing for instance1002 safety architecture the end user is required to evaluate the parameter BD which is the measure of the common cause between the two channels used in PFH computation The STM32F 1 series device architecture and structure are potential sourc
70. etection of illegal memory access o 0 X X FLASH_SM_0 Periodical software test for Flash memory X FLASH_SM_1 Control flow monitoring in application x X X System Flash software FLASH SM 2 ARM Cortex M3 HardFault exceptions M M X X System SRAM RAM SM 1 Stack hardening for application software X X FLASH SM 3 Option byte write protection M M RAM SM O0 Periodical software test for SRAM memory X Information redundancy for system variables in application software RAM SM 2 X X 40 90 DoclD026823 Rev 2 Ly UM1814 Reference safety architecture Table 3 List of safety mechanisms continued r Single Dual STM32F1 function Diagnostic Description MCU MCU Perm Trans BUS SM 0 Periodical software test for m ix X nno interconnections System interconnect BUS SM 1 Information redundancy in intra chip data m m X X Fexchanges FSMC SM 0 Control flow monitoring in application 23k m X X software FSMC SM 1 Information redundancy X X NVIC SM 0 Periodical read back of configuration m m X X registers NVIC SM 1 Expected and unexpected interrupt check nee x X X by application software CAN SM 0 Periodical read back of configuration ux T X X registers CAN CAN SM 1 Protocol error signals X X CAN SM 2 Information redundancy techniques on P m X X messages incl
71. ety analysis executed for STM32F 1 series devices and contained in this safety manual is considered to be safety relevant that is able to interfere with the safety function to all microcontroller parts with no exclusion This is in line with the conservative approach to be followed during the analysis of a general purpose microcontroller in order to be agnostic versus the final application This means that no STM32F1 series device has been declared as no part nor no effect and therefore all STM32F 1 series devices are included in SFF computations In end user applications not all the STM32F1 series parts modules are used for the implementation of the safety function Requiring the implementation of the respective safety mechanism for those parts could result in an overkill as a consequence a dedicated analysis has been done According to this analysis the end user can define the selected STM32F1 series parts as not safety relevant under the following conditions e Collect rationales and evidences that the parts play no role in safety function implementation user responsibility e Collect rationales and evidences that the parts do not interfere with the safety function during normal operation e Fulfillment of the below reported general condition for the mitigation of the intra MCU interferences Table 5 The end user is allowed for not safety relevant parts to do the following e Disable the part contribution from me
72. ev 2 1 90 www st com Contents UM1814 Contents 1 About this document i 2 x 9 b RR ETRRERXEXEREXTR AX hwo bee da wees 7 1 1 F rpose abd Scope auda qeu qa ted dd agli eh deat eo dea Rer c us ponen 7 1 2 Terms and abbreviations 0 000 eee 7 1 3 Reference normative llle 8 2 STM32F1 series microcontroller development DIOGOSS rozectekekedba su We SERENA RE ten tenet o Du Wise uos 10 2 1 STMicroelectronics standard development process 10 2 2 Yogitech fRMethodology process 0000c eee 12 3 Reference safety architecture sssss 13 3 1 IN OGUCHON au a eee d Een doe e Ies GES CE RR Red aaa ped 13 3 2 Compliant item llllllllllllllll eae 13 3 2 1 Definition of the compliant item llle 13 3 2 2 Safety functions performed by the compliant item 14 3 8 Assumed requirements llle ees 15 3 3 1 Assumed safety requirements lille lesse 15 3 4 Electrical specifications and environment limits 16 3 5 Systematic safety integrity 22 0002 e ee eee ee eee eee 17 3 6 Description of hardware and software diagnostics 17 Sod Cortex M3 CPU io oo riui Edu a abiaebad Vac quet ddl ond dh 17 3 6 2 System FLASH memory ssssses ees 20 3 6 3 System SRAM memory ssssssee en 21 3 6 4 System bus interconnect lille 22 3 6 5 Flexible Static Memory Con
73. f check testing for each MCUs and the control flow result checks for the running application software The guidelines for the implementation of this method are the following e Thetwo microcontrollers receive the same input data at the same time and individually execute the mission algorithm that is the application software It is important that the input data received from the external world is protected by the most robust methods DoclD026823 Rev 2 37 90 Reference safety architecture UM1814 3 6 28 38 90 already described in this safety manual for the system peripherals in terms of data message protection refer to safety mechanism like nformation redundancy techniques on messages including End to End safing CAN SM 2 or Information redundancy techniques on messages UART SM 2 e During the execution of the mission algorithm at every fixed time referenced here as tick each CPU interrupts the normal execution flow and executes a self test aimed at the detection of permanent faults The results are exchanged between the two MCUs by means of an external peripheral interface like USART or SPI The most efficient related safety mechanisms described in this safety manual are implemented for the peripherals used for the inter MCU information exchange Moreover with the aim of detecting transient faults the exchange of compressed results of the algorithm steps executed in the tick is performed according to the following
74. f this safety mechanism takes into account also the overlap of DMA related safety mechanism related to the message exchange inside the MCU and therefore its use is highly recommended SDIO Protocol error signals SDIO SM 0 SDIO protocol errors signals are conceived to detect abnormal conditions for the data card communication they are able to contribute to the detection of faults leading to wrong data read write For instance FIFO overrun and timeout error flags The correct management at application level of such error signals is a common technique in embedded applications and is highly recommended Information redundancy techniques on data packet SDIO SM 1 The redundant information technique is used to protect the SDIO communications with the external device card by detecting both the permanent and transient faults Data transferred from to card is protected by the addition by the application software to data block of a checksum field the checksum is verified after each read The selection of the algorithm for checksum computation shall ensure protection against message corruption similar to the protection ensured by a full redundancy Thus the use of the CRC computation is highly suggested This method is highly recommended The above mentioned safety mechanisms are addressing the SDIO interface included in STM32 MCU No claims are reported here about the addressing of hardware random faults affecting the external memory card co
75. g processing element PEv can be present in the 1002d case see again Appendix B Examples of safety architectures Informative the abstract view is the same as 1002 but with the addition of diagnostic processing elements PEd having the role of performing cross diagnostic functions and contributing to the decision of the voter PEv processes external to the compliant item are considered to guarantee functional safety such as a watchdog WDTe and voltage monitors VMONe Figure 3 Abstract view of compliant item functions VMONe MS33640V1 The role of the PEv and of the external processes WDTe and VMONe is clarified in the sections where the CoU definition of safety mechanism are detailed e WDTe refer to Independent watchdog VSUP SM 2 Control flow monitoring in application software CPU SM 1 e VMONe refer to Supply Voltage Monitoring VSUP SM 1 3 DoclD026823 Rev 2 UM1814 3 3 3 3 1 Reference safety architecture Assumed requirements Assumed safety requirements It is assumed that the concept specification the hazard and risk analysis the overall safety requirement specification and the consequent allocation has determined the following requirements for the compliant item assumed safety requirements The compliant item can be used for four kinds of safety functions Acontinuous mode high demand SIL3 safety function CM3 or Alow demand SIL3 safety function LD3
76. g to the availability of a quick hardware support on the MCU platform The above reported approaches are equivalent an additional criteria for the selection is the evaluation of the computation capability of the external device with which the STM32F1 will exchange data If the message is transferred by the DMA the implementation of this safety mechanism takes into account also the overlap of DMA related safety mechanism related to the message exchange inside the MCU and therefore its use is highly recommended Note The adoption of SMBus protocol if available on selected 12C module and compatible with the external connected devices is a way to simplify the implementation of this safety mechanism 3 6 11 SPI 1 2 3 Periodical read back of configuration registers SPI SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of SPI against their expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Protocol error signals SPI SM 1 The SPI protocol errors signals despite being conceived to detect physical layer rela
77. gisters GPIO SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of GPIO against their expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage 1002 for input GPIO lines GPIO SM 1 To address both permanent and transient faults on GPIO lines used as input it is required to implement a 1002 scheme by connecting the external safety relevant signal to two independent GPIO lines To reduce the potential impact of common cause failure it is suggested to use GPIO lines belonging to different i o ports for example PORT A and B and mapped to not adjacent pins on the device package Loopback scheme for output GPIO lines GPIO SM 2 To address both permanent and transient faults on GPIO lines used as output it is required to implement a loopback scheme connecting the output to a different GPIO line programmed as input and used to check the expected value on output port To reduce the potential impact of common cause failure it is suggested to use GPIO lines belonging to different i o ports for example PORT A and B and map
78. he analogue section it is required to execute a periodical test on the ADC acquisition section The method is implemented by acquiring either the internal reference voltage or alternatively a reference voltage coming from the external board and connected to an input pin and comparing to the expected value This test is executed periodically at least once per DTI DoclD026823 Rev 2 31 90 Reference safety architecture UM1814 3 6 17 3 6 18 32 90 1002 scheme for acquisition ADC SM 4 The presence of multiple separate ADC allows the implementation of 1002 scheme using two different ADC modules to acquire the same analog signal coming from the external world This safety mechanism ensures a high level of coverage against both permanent and transient faults Its adoption reduces the available resources on the MCU two different ADC required but its implementation has no complexity DAC1 2 Periodical read back of configuration registers DAC SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of DAC module against their expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once p
79. he compliant item is defined as a system including one or two STM32 microcontrollers MCU see Figure 2 The communication bus is directly or indirectly connected to sensors and actuators Figure 2 Definition of the compliant item actuator sensor Processing element ee Compliant item MS33681V1 Other components might be related to the compliant item like the external HW components needed to guarantee either the functionality of the STM32F1 external memory clock quartz etc or its safety for example the external watchdog voltage supervisors DoclD026823 Rev 2 13 90 Reference safety architecture UM1814 3 2 2 14 90 Safety functions performed by the compliant item In essence the compliant item architecture can be represented as composed by the following processes performing the safety function or part of it Input processing elements PEi reading safety related data from the remote controller connected to the sensor s and transferring them to the following computation elements Computation processing elements PEc performing the algorithm required by the safety function and transferring the results to the following output elements Output processing elements PEo transferring safety related data to the remote controller connected to the actuator in the case of the 1002 1002d or 2002 architecture see Appendix B Examples of safety architectures Informative a further votin
80. he 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 Terms and abbreviations Table 1 Terms and abbreviations Acronym Definition ADAS Advanced Driver Assistance System CCF Common Cause Failure CM Continuous Mode COTS Commercial Off the Shelf CoU Conditions of Use CPU Central Processing Unit CRC Cyclic Redundancy Check DC Diagnostic Coverage DMA Direct Memory Access DTI Diagnostic Test Interval ECM Engine Control Module ECU Electronic Control Unit EHSR Essential Health and Safety Requirement EUC Equipment Under Control FE Final Element that is generalized actuator FIT Failure In Time FMEA Failure Mode Effect Analysis FMEDA Failure Mode Effect Diagnostic Analysis FPU Floating Processing Unit HD High Demand HFT Hardware Fault Tolerance HW Hardware INTC Interrupt Controller ITRS International Technology Roadmap for Semiconductors LD Low Demand DoclD026823 Rev 2 7 90 About this document 1 3 8 90 UM1814 Table 1 Terms and abbreviations continued Acronym Definition MCU Microcontroller Unit MTBF Mean Time Between Failure MTTFd Mean Time to Failure OC Output Circuit PDS SR Power Drive System Safety Related PEc Programmable Electronics c
81. hitectures Note that in 1002D voter is affected by the diagnostic result e n 2002 the diagnostic section is optional d 56 90 DoclD026823 Rev 2 UM1814 B 2 3 Examples of safety architectures Informative Considerations about voter implementation The general concept of the compliant item shown in Section 3 2 2 Safety functions performed by the compliant item foresees the presence of a voter actuator PEv that could be implemented by a combination of internal voter PEvi and external voter PEve In absence of a dedicated piece of HW inside the STM32F1 series device that can take the role of PEvi the structure of the voter can be organized as shown in Figure 11 This is still a general structure in the sense that the partitioning of voting functions between PEvi and PEve shall be decided by the end customer based on the complexity of the voting algorithm to be performed Figure 11 A possible voter structure combining PEvi and PEve From PEO From WDTe MS35545V1 The advantages of the internal PEvi are the following e Possibility to operate more elaborate types of voting for example dynamic principles and or to provide conditioning signals for example synchronization signals to ease PEve process of the PEo output and simplify the external circuit that implements the PEve e Possibility to cooperate to guarantee the needed coverage of the external PEve by means of partially redundant decisions As a c
82. ilable as achieved by the IEC 61508 approach refer to IEC 61508 2010 6 Annex D Alternatively DoclD026823 Rev 2 71 90 UM1814 Change impact analysis for other safety standards the end user can apply the simplified approach from the standard refer to Annex F to calculate the B factor value to be used in formulas for PFHD C 2 3 Work products Table 11 lists the work products required by the IEC 62061 standard and their mapping with the work products from IEC 61508 compliance activity Table 11 IEC 62061 work product grid IEC 62061 1 1 Tab 8 Information to be provided IEC 62061 1 1 Clause STM32F1 series IEC 61508 document Functional safety plan 4 2 1 Specification of requirements for SRCFs 5 2 End User responsibility Functional safety requirements specification for SRCFs 5 2 3 Safety integrity requirements specification for SRCFs 5 2 4 SRECS design 6 25 STM32F1 series safety manual Structured design process 6 6 1 2 SRECS design documentation 6 6 1 8 End User responsibility Structure of function blocks 6 6 2 1 1 SRECS architecture 6 6 2 1 5 TM APE NS eer manual Subsystem safety requirements specification 6 6 2 1 7 End User responsibility Subsystem realization 6 7 2 2 Subsystem architecture elements amp their interrelationships 6 7 4 3 1 2 SHEMIGE T Senes sarely manual Fault exclusions claimed when estimating fault tolerance SFF 6 7 6 1c 6 7 7 3 Software safety requir
83. ine some standard and precise requirements about the structure of the voter in order to achieve or maintain the safe state Therefore only general Conditions of Use CoU can be defined Examples of such generic CoUs are given hereafter provide a mean to inform the PEvi and then the PEve about the error conditions that cannot be resolved by the OS e provide a mean for the WDTe to communicate with the PEve in order to achieve or maintain the safe state in case of a common cause failure in the SC logic d DoclD026823 Rev 2 UM1814 Change impact analysis for other safety standards Appendix C Change impact analysis for other safety standards The safety analysis reported in this user manual is executed according to IEC 61508 safety norm In this appendix a change impact analysis with respect to different safety standard is executed The following topics are considered for each addressed safety norm e Differences in the suggested hardware architecture architectural categories and how to map what is foreseen in the new safety norm on the standard safety architectures of IEC 61508 e Differences in the safety integrity level definitions and metrics computation methods and how to recompute and judge the safety performances of STM32F1 series devices according to the new standard e Work products required by the new safety norms and how to remap or rework if needed existing ones resulting as output of the IEC 61508 compliance activi
84. l safety concept 4 7 5 1 Safety analysis reports resulting from requirement 4 7 5 6 Hardware safety requirements verification report 5 6 5 3 Hardware safety analysis report 5 7 5 2 Analysis of the effectiveness of the architecture of the item 5 8 5 1 STM32F1 series safety to cope with the random hardware failures manual Review report of evaluation of the effectiveness of the architecture of the item to cope with the random hardware 5 8 5 2 failures Analysis of safety goal violations due to random hardware 5 9 5 1 failures UU Review report of evaluation of safety goal violations due to 5 9 5 3 random hardware failures Software safety requirements specification 6 6 5 1 Software architectural design specification 6 7 5 1 End user Responsibility Software verification report refined 6 11 5 3 Results of safety analyses 9 8 5 1 SIM34F1 series salety manual 86 90 DoclD026823 Rev 2 Ly UM1814 fRSTL_STM32F1_SIL2 3 product and its use in the framework of this manual AppendixD fRSTL_STM32F1_SIL2 3 product and its use in the framework of this manual From the list of safety mechanisms that end users implement to reach the SIL2 safety integrity level for STM32F1 series see Table 3 and Section 3 7 Conditions of use we can extract a subset of mechanisms with the following characteristics e The safety mechanisms can be implemented with dedicated periodical software test e The safety mechanisms are inhere
85. latform The above reported approaches are equivalent an additional criteria for the selection is the evaluation of the computation capability of the external device with which the STM32F1 will exchange data 3 DoclD026823 Rev 2 UM1814 3 6 16 Note 3 Reference safety architecture Analog to Digital Converters ADC Periodical read back of configuration registers ADC SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of ADC against their expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Multiple acquisitions by application software ADC SM 1 To address the transient faults that affect the ADC module it is required to implement a timing information redundancy scheme that executes multiple acquisitions of the same signal This recommendation will most probably be satisfied by design by the end user application software The usage of multiple acquisitions followed by average operations is a common technique in industrial applications where it is needed to survive with spurious EMI disturbs on
86. le Dual STM32F1 function Diagnostic Description MCU MCU Perm Trans GPIO SM 0 Periodical read back of configuration d j X X registers GPIO GPIO SM 1 1002 for input GPIO lines X X GPIO SM 2 Loopback scheme for output GPIO lines X X GPIO SM 3 GPIO port configuration lock register Periodical read back of configuration RTC SM 0 X X LI registers RTC SM 1 Application check of running RTC X X VSUP SM 0 Periodical read back of configuration aa X X registers Supply system VSUP SM 1 Supply voltage monitoring X VSUP SM 2 Independent Watchdog X VSUP SM 3 Internal temperature sensor check 0 o Periodical read back of configuration CLK SM 0 X X registers Clock and Reset CLK SM 1 CSS Clock Security System X CLK SM 2 Independent Watchdog X CLK SM 3 Internal clock cross measure X Periodical read back of configuration WDG SM 0 X X Watchdogs registers WDG SM 1 Software test for watchdog at startup 0 fe X Debug DBG SM 0 Independent watchdog X X Cross checking between two STM32F1 Dual MCU DUAL SM 0 microcontrollers Software based safety mechanism LAT SM 0 CRC self coverage X using hardware CRC Software based LAT SM 1 Independent Watchdog X safety mechanism LAT SM 2 Periodical core self test software X RS a LOCK SM O0 Lock
87. ller it is required to implement information redundancy on the safety related system variables stored in the RAM The guidelines for the implementation of this method are the following e The system variables that are safety related in the sense that a wrong value due to a failure in reading on the RAM affects the safety functions are well identified and documented e The arithmetic computation and or decision based on such variables are is executed twice and the two final results are compared Note that the implementation of this safety method shows a partial overlap with an already foreseen method for Cortex M3 CPU SM 1 optimizations in implementing both methods are therefore possible see Control flow monitoring in application software CPU SM 1 DoclD026823 Rev 2 21 90 Reference safety architecture UM1814 3 6 4 3 6 5 Note 22 90 System bus interconnect Periodical software test for interconnections BUS SM 0 The intra chip connection resources Bus Matrix AHB APB bridges need to be periodically tested for permanent faults detection Note that STM32F1 series MCUs have no hardware safety mechanism to protect these structures The test executes a connectivity test of these shared resources including the testing of the arbitration mechanisms between peripherals This method which is based on the periodical execution of software based tests is executed at least once per DTI According to IEC 61508 2 Table A 8
88. lt tolerance D2 2 k the classification as type A or type B of that part of the compliant item that Section 3 provides the function see 7 4 4 1 2 and 7 4 4 1 3 The safe failure fraction reported in this manual has been computed under the assumptions described in this document and especially according to the conditions of use described in Section 3 7 Conditions of use d DoclD026823 Rev 2 9 90 STM32F1 series microcontroller development process UM1814 2 2 1 10 90 STM32F1 series microcontroller 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 IEC 61508 2 in Annex F Techniques and measures for ASICs avoidance of systematic failures act as a guidance in tailoring the microcontroller standard design and manufacturer process to the compliance of the IEC 61508 requirements The checklist reported in the named Annex F helps to collect all related evidences of a given real process STMicroelectronics standard development process STMicroelectronics ST serves four industry domains 1 Standard products 2 Automotive products ST automotive products are AEC Q100 compliant They are subject to specific stress testing and processing instructions in order to achieve the required quality levels and product stability 3 Aut
89. mation A1 1 of the component or IP aa Sub part level based on initial design A1 2 and detailed gate flip bU database flop count estimation Accurate estimation on A2 1 F Inspection RTL and pre layout concrete design data netlist Gate level A2 2 Measured at Fault injection pre layout level A3 post layout information Gate level Measuredal Fault injection post layout level A 3 fRTools Due to the complexity of modern integrated circuits as recognized by functional safety standards like ISO 26262 the completeness of the analysis can be guaranteed only through automation For this reason fRMethodology is supported by a set of EDA tools e Safety Designer a cockpit to determine failure rates failure modes and failure modes distribution of integrated circuits This tool is specific for integrated circuits and supports the safety engineer all the way through the safety analyses from FMEA to FMEDA and FTA including dependent failure analysis e Safety Verifier a tool that covers the validation of the safety metrics safeness and diagnostic coverage of HW and SW mechanisms by managing a fault injection campaign on a device or part of it The Safety Verifier allows the user to partition the campaign according to the steps defined by the methodology and to the needs of complexity of the design It manages all the necessary simulations run by an external fault or functional simulator depending on the fault model and
90. mechanism for configuration options FFI SM 0 Unused peripherals disable Part separation no interference EFI SM 1 Periodical read back of interference i E avoidance registers The above described safety mechanism conditions of use are implemented with different levels of abstraction depending on their nature the more a safety mechanism is implemented as application independent the wider is its possible use on a large range of end user applications DoclD026823 Rev 2 43 90 Reference safety architecture UM1814 44 90 The STM32F1 series safety analysis highlights two major areas inside the MCU illustrated in Figure 5 The light blue area includes all MCU modules that are system critical meaning that each end user application will be affected from a safety point of view by an issue on these modules Each safety application addresses these modules with the adequate methods according to the safety analysis reported above Furthermore these modules being commonly used by each end user application the related methods safety mechanism as described above are mainly implemented to be application independent The orange area includes peripheral modules that could be not used by the end user application or that were used for not safety relevant tasks The related safety methods are therefore implemented mainly at application level as application software solutions and or architectural solutions
91. mpliance le Product target specification and strategy e Project manager appointment to drive product development e Evaluation of the technologies design tools and IPs to be used e Design objective specification and product validation strategy e Design for quality techniques DFD DFT DFR DFM definition e Architecture and positioning to make sure the software and hardware system solutions meet the target specification e Product approval strategy and project plan le Semiconductor design development le Hardware and application development le Software development le Analysis of new product specification to forecast reliability performance le Reliability plan reliability design rules prediction of failure rates for operating life test using Arrhenius s law and other applicable models le Use of tools and methodologies such as APQP DFM DFT DFMEA FMKM le Detection of potential reliability issues and solution to overcome them le Assessment of Engineering Samples ES to identify the main potential failure mechanisms le Statistical analysis of electrical parameter drifts for early warning in case of fast parametric degradation such as retention tests le Failure analysis on failed parts to clarify failure modes and mechanisms and identify the root causes le Physical destructive analysis on good parts after reliability tests when required le Electrostatic discharge ESD and latch
92. n RAM and adequately updated after each configuration change It mainly addresses the transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Protocol error signals HDMI SM 1 HDMI protocol errors signals despite being conceived to detect physical layer related abnormal conditions are able to contribute to the detection to faults leading to error messages generation for instance reception transmission and arbitration error flags transmission and reception under run Information redundancy techniques on messages HDMI SM 2 The redundant information technique is used to protect the HDMI communications by detecting both the permanent and transient faults There are two different approaches to implement this method e Multiple sending of the same message with comparison of the received results e Addition by the sender of a checksum field to the message to be verified by the receiver In case the checksum field approach is adopted the selection of the algorithm for checksum computation shall ensure a similar protection against message corruption as the one ensured by a full redundancy Theoretic demonstrations on coverage capability are admitted the use of CRC coding is anyway suggested also looking to the availability of a quick hardware support on the MCU p
93. n apply to the STM32F 1 series functions detailed in Section 3 7 Conditions of use Table 17 List of STM32F1 series safety mechanism overlapped by fRSTL STM32F1 SIL2 3 STM32F1 series no interference f nclioh Diagnostic Description ARM Cortex M3 CPU CPU SM O Periodical software test addressing permanent faults gt in Cortex M3 CPU inner core System Flash FLASH_SM_0 Periodical software test for Flash memory cells System SRAM RAM_SM_0 Periodical software test for SRAM memory cells System interconnect BUS_SM_0 Periodical software test for interconnections NVIC NVC_SM_0 CAN CAN_SM_0 UART UART_SM_0 I2C lIC SM 0 SPI SPI SM 0 USB USB SM 0 HDMI HDMI SM 0 ADC ADC SM 0 DAC DAC SM 0 Periodical read back of configuration registers DMA DMA SM 0 TIM6 7 GTIM SM 0 mM ATIM SM 0 GPIO GPIO SM 0 RTC RTC SM 0 Clock and Reset CLK SM 0 Watchdogs WDG SM 0 Part separation FFI SM 0 Periodical read back of interference avoidance registers For further information about fRSTL STM32F1 SIL2 3 products documentation user guide software licensing visit Yogitech website DoclD026823 Rev 2 Ly UM1814 Revision history Revision history Table 18 Document revision history Date Revision Changes 06 Oct 2014 1 Initial release Updated the applicability of the user manual to the microcontrollers of the STM32F1 series and to STM32 SafeSIL part number Updated eet Znls 2 Figure 1 S
94. nd 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 IEC 61508 requirements for the relationship between PST and the diagnostic test interval Stack hardening for application software RAM SM 1 The stack hardening method is used to enhance the application software robustness to SRAM faults that affect 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 e Pass also the redundant copy of the passed parameters values possibly inverted and execute a coherence check in the function e Pass also the redundant copy of the passed pointers and execute a coherence check in the function e 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 Information redundancy for safety related variables in application software RAM SM 2 To address transient faults affecting SRAM contro
95. ned in the following section for the HFT 1 computations the value of the process safety time is not as stringent as it is for HFT 0 architectures that is clarified further in the document The end user shall take into account that hardware random failures affecting the STM32 can compromise the MCU capability of operating properly for example failure modes affecting the program counter prevent the correct execution of software DoclD026823 Rev 2 15 90 Reference safety architecture UM1814 3 4 16 90 The base assumptions about the de energize state and the repair conditions in the computation of the PFD PFH are as follows e In the 1001 mode The system is de energized as soon as a fault is identified by the HW or SW diagnostics Ifthe fault has been identified as a transient fault the compliant item can be reset and the safety function can continue after reset Ifthe fault has been identified as a permanent fault or if it has not been identified the compliant item is assumed to be kept de energized In the 1002 1002D low demand modes The 1002 system is NOT de energized if a fault is identified in one of the two channels The faulty compliant item can be repaired that is the faulty STM32F1 MCU can be replaced or one of the external components might be replaced e In the 1002 1002D high demand or continuous modes The system is de energized as soon as a fault is identified in one of th
96. ng 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 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 ARM Cortex M3 CPU subparts devoted to mathematical computations and data access The guidelines for the implementation of the method are the following e The requirement needs be applied only to safety relevant computation that is to the computations that in case of wrong result could interfere with the system safety 3 DoclD026823 Rev 2 UM1814 Reference safety architecture functions Such computation shall be therefore carefully identified in the original application software source code e Both mathematical operation and comparison are intended as computation e The redundant computation for comparison could be implemented according to the following template Original code If VarA VarB then
97. niques on messages ETH SM 2 The information redundancy technique is used to protect the Ethernet communications by detecting both the permanent and transient faults and to adequately manage failure modes not covered by intrinsic MAC 802 3 safety features like for instance checksum field in data DoclD026823 Rev 2 29 90 Reference safety architecture UM1814 3 6 15 30 90 packet Therefore information fields are suggested to be added to message transferred by Ethernet that is sender identifier message frame counter additional checksum to correctly manage message masquerading repetition overlap The adoption of the full layers of protocols like TCP IP is a way to get available additional software based error checking mechanisms Periodical software test for Ethernet using MAC loopback ETH_SM_3 To address permanent faults affecting Ethernet MAC modules the loopback function is used to implement a periodical software test where a sequence of frames is sent through loopback and checked after receiving The software test is executed periodically at least once per DTI This method is considered as optional HDMI CEC module Periodical read back of configuration registers HDMI SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of HDMI module against their expected value that was previously stored i
98. nism linked to a system watchdog is able to detect such failures in case they interfere with the expected flow of the application software For more detailed implementation guidelines for such technique refer to safety mechanism CPU SM 1 in target9000021 Information redundancy FSMC SM 1 If FSMC is used to connect an external memory where safety relevant data is stored information redundancy techniques for stored data are able to address faults affecting the FSMC interface The possible techniques are e To use redundant copies of safety relevant data and perform coherence check before use e To organize data in arrays and compute the checksum field to be checked before use The above mentioned safety mechanisms are addressing the FSMC interface included in STM32 MCU No claims are reported here about the addressing of hardware random faults affecting the external memory connected to FSMC DoclD026823 Rev 2 Ly UM1814 3 6 6 3 6 7 Reference safety architecture NVIC and EXTI controller Periodical read back of configuration registers NVIC SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers is implemented by executing a periodical check of the configuration registers of each used system peripheral against its expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses the transient
99. nnected to SDIO USB 2 0 Universal Serial Bus interface FS module Periodical read back of configuration registers USB SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of USB against their expected value that was previously stored in the RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Protocol error signals USB SM 1 The USB protocol errors signals despite being conceived to detect physical layer related abnormal conditions are able to contribute to the detection to faults leading to error messages generation The errors are those entirely handled by hardware that is buffer overruns bit stuffing frame format violations CRC errors End users must take care of the system availability by managing adequately the protocol errors that are not related to random hardware faults but to transmission issues that can be recovered with a repetition of the message transmission The handling at application level of such error signals being a common technique in embedded applications their use is highly recommended DoclD026823 Rev 2 Ly UM1814 3 6 1
100. nostic function s NOTE diagnostic function provides the Logic Solver with a diagnosis of an external subsystem e g the actuator 6 7 8 2 5 Figure 15 ADssA r Subsystem A element 1 De1 Subsystem Basic architecture of Logic Single channel architecture one MCU in 1001 n 1 Diagnostic function is in charge of End User SILCL 1 if SFF lt 90 SILCL 2 if 90 SFF 99 SILCL 3 if SFF 9996 het Ign DC DC Diagnostic Coverage as resulting from FMEDA 1 sss Dual channel architecture with two identical MCUs Diagnostic function is in charge of End User SILCL 1 if SFF lt 60 SILCL 2 if 60 lt SFF lt 90 SILCL 3 if SFF 2 90 For B factor see Section 4 2 DC Diagnostic Coverage as resulting from FMEDA PFH pssc Apssc In this case pei pez de T2 has to be defined at Logic Solver level by End User Block diagram for IEC 62061 Cat A Adel SP as Aen PF HpssA ADssA x lA A Subsystem element n Aden Block diagram Figure 17 Figure 18 MS33695V1 68 90 DoclD026823 Rev 2 Ly UM1814 Change impact analysis for other safety standards 2 Apssg 1 B x Apel Adee x T4 BX Apei ADe2 2 B PFHpssg Apssp x 1h T4 is the proof test interval of lifetime whichever is the smaller p is the susceptibility to common cause failures Figure 16 Block diagram for
101. ntly application independent they can be implemented independently of the specific application software that runs on the STM32F 1 series final use Yogitech have developed a specific suite of fRSTL fault robust Software Test Libraries for the STM32F1 series devices The software product implements a software based diagnostics This dedicated version eases the implementation of the required safety mechanism for the STM32F1 series Table 16 lists the five main key differentiation factors of fRSTLs with other possible alternatives Table 16 fRSTLs differentiation factors Both the diagnostic coverage and the development process systematic capability are compliant with the IEC 61508 24 edition Compliant with IEC 61508 The SW test Libraries are developed and validated according to Yogitech fRMethodology This is a patented white box approach which performs functional safety analyses and safety oriented design exploration of integrated circuits Yogitech enabled The SW Test Libraries are optimized in code size and run time for Optimized real time operation The diagnostic coverage and conditions of use are not tied to any Application independent specific application The SW Test Libraries are composed by a number of independent Modular test segments that user can selectively run according to specific needs thus facilitating integration with application software The main advantages for end users who adopt fRSTL
102. o a system reset Note that the efficiency of this safety mechanism is strongly dependent on the correct window setting and handling for the IWDG The refresh of the IWDG should be implemented in order to bring alteration of the program flow able to bypass the time window limit Internal clock cross measure CLK SM 3 This method is implemented using cross check capabilities of specific TIMs to be fed by the 32 kHz RTC clock or an external clock source if available In case the selected part number is not equipped with such feature a generic input capture input can be used DoclD026823 Rev 2 Ly UM1814 3 6 24 3 6 25 3 6 26 3 6 27 Reference safety architecture A dedicated software routine is able to cross measure the internal clock and to detect any abnormal value of oscillation frequency This method despite its complexity only provides medium efficiency in clock related failure mode coverage Watchdogs IWDG WWDG Periodical read back of configuration registers WDG SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of the watchdogs against their expected value previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The
103. oduct grid continued IEC 60730 5 2 STM32F1 series Information to be provided IEC 60730 Part Clause EC 61508 document FMEA H 2202 STM32F1 series safety manual Operational test H 2 17 6 End User responsibility C 5 ISO 26262 2010 This international standard with a contribution from Yogitech in ISO working groups WGs ref to Section A 2 fRMethodology and its flow is the reference for the functional safety for the automotive domain It derives from IEC 61508 standard and includes relevant modifications Since the automotive is a mass production industry the safety validation is usually performed at a sample C D level that is close to the pre series version of the item Only the positively assessed design of the item from the functional safety point of view shall be made ready for the production in a large number of copies ISO 26262 redefines the safety integrity levels in term of Automotive SIL ASIL with a scale from A the lowest level to D the highest level A correlation matrix between SIL and ASIL values has been empirically identified by TUV SUD and is illustrated in Figure 21 Figure 21 Correlation matrix between SIL and ASIL In the ISO 26262 scope end users can rely on ASIL decomposition to define system architectures where the highest ASIL requirements are fulfilled by using lower ASILs redundant sub systems but respecting the requirements in part 9 5 Following the rules an ASIL D safety goal
104. of the compliance to the norm Description of hardware and software diagnostics This section lists all the safety mechanisms hardware software and application level considered in the safety analysis of the microcontrollers of the STM32F 1 series It is expected that users are familiar with the STM32F1 architecture and that this document is used in conjunction with the related device datasheet user manual and reference information Therefore to avoid the eventuality of mistakes and reduce the amount of information to be shown no functional details are included in this document Note that the part numbers of the STM32F1 series represent different combinations of peripherals for instance some of them are not equipped with USB 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 only The safety verification executed by Yogitech and related coverage figures reported in this manual are based on such guidelines Please read the following definitions e enduser the final user of STM32F1 that is in charge of integrating the MCU in a real application for example
105. omotive safety a subset of the automotive domain ST uses as a reference the ISO 26262 Road vehicles Functional safety standard ST supports customer 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 4 Medical products ST complies with applicable regulations for medical products and applies due diligence in the development and validation of these products 3 DoclD026823 Rev 2 UM1814 STM32F1 series microcontroller development process STMicroelectronics product development process compliant with the ISO TS 16949 standard is a set of interrelated activities dedicated to transform customer specification and market or industry domain requirements into a semiconductor device and 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 Figure 1 STMicroelectronics product development process 3 Qualification e Key characteristics and requirements related to future uses of the device e Industry domain s specific customer requirements and definition of controls and tests needed for co
106. on where the end user completely disables the DMA using therefore polling techniques in order to avoid the implementation of DMA related safety measures Unused peripherals disable FFI SM 0 This method contributes to the reduction of the probability of cross interferences caused by peripherals not used by the software application It is implemented by end users taking care of disabling by software for instance during the system boot each peripheral that is not used Periodical read back of interference avoidance registers FFI SM 1 This method contributes to the reduction of the probability of cross interferences between peripherals that can potentially conflict on the same output pins including for instance unused peripherals refer to Unused peripherals disable FFl SM 0 This diagnostic measure executes a periodical check of the below described registers against their expected value previously stored in RAM and adequately updated after each configuration change The register test is executed at least once per DTI The configuration registers to be tested with this method are those related to clock disabling features for peripherals and those related to the enabling of alternate functions on I O pins DoclD026823 Rev 2 39 90 Reference safety architecture UM1814 3 7 Bis Single Dual STM32F1 function Diagnostic Description MCU MCU Perm Trans Conditions of use Table 3 provides a summary of the safety con
107. onsequence of the requirement in IEC 61508 2 Annex E 2 b those external measures shall achieve medium effectiveness see also A 3 as minimum that is they must be implemented by means of Tests by redundant hardware Monitored redundancy etc The disadvantages of having an internal PEvi are e the possibly of more I Os to be exchanged between MCU and the PEve e the need for a separation between the software functionalities related to PEc PEo and PEvi On the other hand the advantages of not having an internal PEv that is just using the PEo outputs to drive the PEve are e a simpler overall voting mechanism e the possibly of less I Os to be exchanged DoclD026823 Rev 2 57 90 Examples of safety architectures Informative UM1814 58 90 The disadvantages of having just one external PEve are e this architecture is possible only if the voting algorithm is relatively simple like a continuous comparison between few static signals e itis more difficult to implement tests or redundancy to reach the coverage requirements for the voter itself In general with respect to the assumed requirement on the safe state described in Section 3 3 1 Assumed safety requirements one role of the PEvi and PEve shall also be to achieve or maintain the safe state of the system in case the OS cannot be informed or cannot properly react Since the safe state of the system is not very well defined it is not possible to def
108. ore PEd Programmable Electronics diagnostic PFH Probability of Failure per Hour PL Performance Level PST Process Safety Time SE Sensor Element SFF Safe Failure Fraction SIL Safety Integrity level SRCF Safety Related Control Function SRECS Safety Related Electrical Control Systems SRP CS Safety Related Parts of Control Systems SW Software Reference normative This document is written in compliance with the IEC 61508 international norm for functional safety of electrical electronic programmable electronic safety related systems The version used as reference is IEC 61508 1 7 IEC 2010 The other functional safety standards considered in this manual are the following e SO 26262 1 2 3 4 5 6 7 8 9 2011 E ISO 26262 10 2012 E e ISO 13849 1 2006 ISO 13849 2 2010 e IEC 62061 2012 11 ed 1 1 e EC 61800 5 2 2007 ed 1 0 e IEC 60730 1 2010 ed 4 0 Table 2 reports the mapping of this document content with respect to the requirements listed in the IEC 61508 2 Annex D d DoclD026823 Rev 2 UM1814 About this document Table 2 Mapping between this document content and IEC 61508 2 Annex D requirements IEC 61508 requirement part 2 annex D Reference D2 1 a a functional specification of the functions capable of being performed Section 3 D2 1 b identification of the hardware and or software configuration of the E Section 3 2 compliant item D2 1 c constraints on the use of the compliant it
109. passed parameters values possibly inverted and execute a coherence check in the function e Pass also the redundant copy of the passed pointers and execute a coherence check in the function e For the parameters that are not protected by redundancy implement defensive programming techniques plausibility check of passed values For example enumerated fields are to be checked for consistency External watchdog CPU SM 5 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 STM32F1 3 DoclD026823 Rev 2 19 90 Reference safety architecture UM1814 3 6 2 20 90 MPU detection of illegal memory access CPU_SM_6 The MPU can be programmed by end users to achieve memory space separation between different software running on the CPU For this reason MPU programming is highly recommended to achieve software robustness in terms of systematic capability The MPU is able to detect illegal memory access due not to software design errors but to hardware faults affecting program counter and or CPU data interfaces Therefore it contributes also to address both permanent and transient faults affecting CPU core System 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
110. ped to not adjacent pins on the device package GPIO port configuration lock register GPIO SM 3 This safety mechanism prevents configuration changes for GPIO registers it addresses therefore systematic faults in software application and not transient faults soft errors that can possibly cause bit flip on registers during running time The use of this method is encouraged to enhance the end application robustness for systematic faults DoclD026823 Rev 2 Ly UM1814 3 6 21 3 6 22 Caution 3 Reference safety architecture Real Time Clock module RTC Periodical read back of configuration registers RTC_SM_0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of RTC module against their expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test shall be executed at least once per DTI in order to be able to claim the related diagnostic coverage Application check of running RTC RTC SM 1 The application software implements some plausibility check on RTC calendar timing data mainly after a power up and further date reading by RTC The guidelines for the implementation of the method are the follo
111. re Introduction The STM32F1 series microcontroller described in this document is a Safety Element out of Context SEooC that is the intent is to describe a compliant item that can be used within different safety applications The aim of this section is to identify such compliant item and therefore to define the context of the analysis in terms of assumptions with respect to a reference concept definition that is with respect to reference safety requirements as also assumptions with respect to the design external to that compliant item 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 following steps of the analysis Additional details on the reference safety architecture are given in Appendix B Examples of safety architectures Informative Compliant item Definition of the compliant item According to IEC 61508 1 clause 8 2 12 a compliant item is any item for example an element on which a claim is being made with respect to the clauses of IEC 61508 series With respect to its user at the end of its development the compliant item shall be described by a safety manual In this document t
112. reseen safety mechanism at MCU level CRC self coverage LAT SM 0 The intrinsic high level of self coverage of the CRC computation unit is computed as a safety mechanism for latent fault for all STM32F1 series peripherals modules covered by the safety mechanism implemented as software check based on CRC computations Independent Watchdog LAT SM 1 Each safety mechanism implemented as periodical software testing runs on the CPU Possible faults in the safety mechanism are therefore faults in the support for the execution that is the CPU The independent watchdog is considered here as safety mechanism addressing the program counter failures due to the CPU hardware random faults DoclD026823 Rev 2 Ly UM1814 3 6 29 3 Reference safety architecture Periodical core self test software LAT SM 2 As the major part of the safety mechanism described in this safety manual is implemented by software the periodical core self test software execution able to detect faults in the ARM Cortex M3 CPU acts as safety mechanism for latent faults For implementation details refer to the description reported in Periodical core self test software CPU_SM_O for CPU SM O0 Disable and periodic cross check of unintentional activation of unused peripherals This section reports the safety mechanism that addresses peripherals not used by the safety application or not used at all Note that itis possible to use these methods to manage applicati
113. s Read Back Periodic by Software of Configuration Registers is implemented by executing a periodical check of the configuration registers of Ethernet against its expected value that was previously stored in the RAM and adequately updated after each configuration change It mainly addresses the transient faults that affect the configuration registers by detecting bit flips in the registers due to these transient faults The register test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Due to the complexity of implementation and to the overlap of this safety mechanism with other listed in current section its adoption is optional Physical protocol error signals ETH SM 1 The Ethernet protocol errors signals are conceived to detect abnormal conditions for the physical layer they contribute to the detection of faults in the hardware leading to error messages generation The errors are those entirely handled by hardware like for instance buffer overruns bit stuffing frame format violations CRC errors End users must take care of the system availability by managing adequately the protocol errors that are not related to random hardware faults but to transmission issues that can be recovered with a repetition of the message The correct management at application level of such error signals is a common technique in embedded applications and his use is highly recommended Information redundancy tech
114. s Refer to Section 3 Figure 13 Overall DC is low CCF shall be Compliant item s MTTFd high evaluated MTTFd can range from low to TE is in charge of End User PL d high allowing up to PL d 60 90 DoclD026823 Rev 2 Lyr UM1814 Change impact analysis for other safety standards Table 7 IEC 13849 architectural categories continued Cat Ref Summary Designated architecture of Logic Block diagram With respect to category 1 it is expected to have fault detection mechanisms and Double channel architecture two any single fault occurrence does not lead identical MCUs in 1002 or 2002d the loss of the safety function Overall DC Refer to Section 3 Figure 14 is low CCF shall be evaluated for the Continuous testing monitoring channels MTTFd can range from low to Compliant item s MTTFd high high allowing up to PL d With respect to category 1 it is expected Double channel architecture two to have fault detection mechanisms and_ dentical Meus in 1002 or 2002d any single fault occurrence does not lead Refer to Section 3 the loss of the safety function Overall DC Continuous testing monitoring gurea is high CCF shall be evaluated for the Compliant item s MTTFd high channels MTTFd is high allowing PL e PLe achievable Figure 12 Block diagram for IEC 13849 Cat B and Cat 1 im Interconnecting means l Input device e g sensor L Logic o Ouput device e g main contactor
115. s test is executed at least once per DTI in order to be able to claim the related diagnostic coverage 1002 for counting timers ATIM SM 1 This method provides a high level of coverage for both the permanent and transient faults on the addressed timers The method is conceived to protect the timers used for counting features for example the timers dedicated to maintain a system time base and or to generate a timed interrupt for the execution of service routines like for instance general timing counters update increase The guidelines for the implementation of the method are the following e n case of timer use as a time base use in the application software one of the timer as timebase source and the other timer just for check In that case the coherence check for the 1002 is done at application level e In case of interrupt generation usage use the first timer as main interrupt source for the service routines and use the second timer to activate a checking routine that cross checks the coherence between timers 1002 for input capture timers ATIM SM 2 This method based on 1002 scheme provides a high level of coverage for both the permanent and transient faults on the addressed timers It is conceived to protect the timers used for external signal acquisition and measurement like input capture and encoder reading The implementation is easy as it simply requires to connect the external signals also to the redundant tim
116. selected as further detailed in the following sections of this document In the block diagrams S represents the part of the compliant item performing the safety function D the one performing a separate diagnostic function and NS the non safety related function s For the 1002 architecture SC1 and SC2 represent the same safety function but redundant Figure 8 The HF T 0 1001 and 1001d architectures 1001 HFT 0 com pliant item compliant item MS33678V1 c As shown further in this document the redundancy can shall be implemented by means of diverse functions But they still perform the same safety function DoclD026823 Rev 2 55 90 Examples of safety architectures Informative UM1814 Figure 9 The HFT21 1002 and 1002d architectures 1002 HFT 1 com pliant item com pliant item MS33679V1 Figure 10 The HFT 1 2002 architecture 2002 compliant item MS33680V1 The following considerations apply e Itis assumed that only one safety function is performed or if many all functions are classified with the same SIL and therefore they are not distinguishable in terms of their safety requirements e The D functions can be implemented using a level or layered approach as further discussed in the following of this document e Itis assumed that there are no not safety relevant functions mixed with the safety functions e The voter is not shown in 1002 1002D 2002 arc
117. service routines like for instance general timing counters update increase 3 DoclD026823 Rev 2 UM1814 3 6 19 Note 3 Reference safety architecture The guidelines for the implementation of the method are the following e n case of timer use as a time base use in the application software one of the timer as timebase source and the other one just for check In that case the coherence check for the 1002 will be done at application level e In case of interrupt generation usage use the first timer as main interrupt source for the service routines and use the second timer to activate a checking routine that cross checks the coherence between the timers TIM1 2 3 4 5 8 9 10 11 12 13 14 15 16 17 as the advanced timers are equipped with many different channels each independent from the others and possibly programmed to realize different features the safety mechanism is selected individually for each channel Periodical read back of configuration registers ATIM SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of TIMERS against their expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The register
118. ssumption that the design of complex electronic components as subsystems or elements of subsystems has to be compliant with requirements of IEC 61508 2010 part 2 Route 1H ref to 7 4 4 2 Coming from the IEC 62061 definition 3 2 8 natively a microprocessor has to be considered as a complex component For this reason the previously obtained results of the application of fRMethodology for the STM32F1 series item refer to Section 4 Safety results in the scope of IEC 61508 are still applicable also in the machines context ruled by IEC 62061 End users can effectively adopt the STM32F 1 series compliant item to design SRECS suitable for the achievement of SIL2 or SIL3 by adopting two STM32F1 series MCUs machines control loops The standard defines as subsystem refer to 83 2 5 the level of parts for a system architecture where a dangerous failure could lead to the loss of the safety function Concerning the integrity levels achievable for subsystems the standard suggests a classification based on HFT and SFF as shown in Table 9 Table 9 SIL classification versus HFT Not allowed SIL 1 SIL2 60 9096 60 9996 29096 SIL3 SIL3 SIL3 SIL3 SIL 3 is the highest requirement for SRCF in this context SIL 4 is out of scope since the final outcome of the development is a control system for one machine only For the designer the SIL values listed in the table has to be seen as the SILCL for
119. t this method The adoption of an external monitoring power supply device outside the MCU ensures additional protection against potential common cause failures the internal PVD will have limited efficiency in detecting an overvoltage condition therefore it is highlighted recommended the end users respect the absolute maximum ratings for voltage see Section 3 4 Electrical specifications and environment limits Independent watchdog VSUP SM 2 The independent watchdog is fed directly by Vpp therefore major failures in the 1 8 V supply for digital logic core peripherals will not affect its behavior but may lead to a DoclD026823 Rev 2 35 90 Reference safety architecture UM1814 3 6 23 36 90 violation of the IWDG window for the key value write by the application software leading to a system reset Internal temperature sensor check VSUP SM 3 The internal temperature sensor shall be periodically tested in order to detect abnormal increase of the die temperature hardware faults in supply voltage system may cause excessive power consumption and consequent temperature rise This method also mitigates the eventuality of common cause affecting the MCU and due to too high temperature Refer to the device datasheet to set the threshold temperature Reset and clock control subsystem Periodical read back of configuration registers CLK SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by
120. ted abnormal conditions are able to contribute to the detection to faults leading to error messages generation such as for instance FIFO overrun and Mode error flags The handling at application level of such error signals being a common technique in embedded applications their use is highly recommended Information redundancy techniques on messages SPI SM 2 The redundant information technique is used to protect the SPI communications by detecting both the permanent and transient faults There are two different approaches to implement this method e Multiple sending of the same message with comparison of the received results e Addition by the sender of a checksum field to the message to be verified by the receiver In case the checksum field approach is adopted the selection of the algorithm for checksum computation shall ensure a similar protection against message corruption as the one ensured by a full redundancy Theoretic demonstrations on coverage capability are admitted the use of the hardware CRC computation unit built into SPI module is highly suggested The above reported approaches are equivalent an additional criteria for the selection is the evaluation of the computation capability of the external device with which the STM32F1 will exchange data 3 DoclD026823 Rev 2 27 90 Reference safety architecture UM1814 3 6 12 Note 3 6 13 28 90 If the message is transferred by the DMA the implementation o
121. test either it has been passed or the reasons for failure C 4 IEC 60730 1 2010 This IEC 60730 1 2010 version 4 0 standard is applicable to the electrical electronic control systems for household equipment building automation appliances that have a rated power supply voltage lt 690 V and a current lt 63 A that guarantee safety and reliability Electrical and or electronic devices intended for the public usage but not in normal households are out of scope of this standard Nowadays these control systems are largely based on complex electronics parts such as embedded systems with microcontrollers and software implemented control functions Annex H of the standard defines specific requirements for electronics controls HW and SW which are mandatory when designing safe compliant electronics parts of control systems d DoclD026823 Rev 2 75 90 Change impact analysis for other safety standards UM1814 C 4 1 76 90 Architectural categories In this standard the proposed architectures refer to S H 11 12 1 are mainly classified on software basis where specific suggestions are given at software level to avoid systematic faults IEC 60730 1 2010 H 2 22 defines three classes of compliance for the performed control functions e Class A SH 2 22 1 control functions which are not intended to be relied upon for the safety of the application Room temperature control is a typical Class A control function e Class B SH 2
122. the subsystem where SILCL is the maximum SIL claimable fora SRECS subsystem as defined in IEC 62061 3 2 24 DoclD026823 Rev 2 Ly UM1814 Change impact analysis for other safety standards C 2 1 Architectural categories The standard in 6 7 8 2 defines a set of basic system architectures to be used for the design of SRECS implementing their SRCFs A key point is the definition of subsystem refer to 83 2 5 as the level of parts for a system architecture where a dangerous failure could lead to the loss of the safety function Focusing on the microcontrollers IEC 62061 proposed architectures are here quickly summarized for supporting end users in the development of their Logic Solver units usable as subsystems for the implementation of a SRCF The assumptions for the correct understanding of the architectures are listed hereafter 1 The SRCF is completely in the scope of the end user 2 The STM32F1 series device with the adoption of safety mechanism described in this safety manual as single compliant item is by itself suitable for applications up to SILCL 2 3 Two identical STM32F1 series devices with the adoption of safety mechanism described in this Manual shall be used for achieving HFT 0 when required by basic architectures 4 For a microcontroller the parameter T1 mentioned in the standard as the minimum between service life or proof test is intended as the lifetime mission time assumed equal to 20 years as p
123. trics computations in FMEDA e Notimplement the related safety mechanisms listed in Table 3 List of safety mechanisms General requirements for Freedom From Interferences FFI A dedicated analysis has highlighted a list of general requirements to be followed by end users in order to be authorized to declare selected STM32F1 series parts as not safety relevant The analysis considers two situations the part that is not used at all disabled or the part is used for a function that is not safety related for example a GPIO port driving a power on signaling led on the electronic board and considers the possible interferences due to hardware random faults affecting not safety relevant parts The requirement for the end user is to implement the safety mechanism detailed in Section 3 6 Description of hardware and software diagnostics despite any evaluation about their contribution for the safety metrics computations Those safety mechanisms are reported in Table 6 Table 5 List of general requirements for FFI Diagnostic Description FFI SM 0 Unused peripheral disable FFI SM 1 Periodical read back of interference avoidance registers BUS SM 0 Periodical software test for interconnections NVIC SM 0 Periodical read back of configuration registers NVIC SM 1 Expected and unexpected interrupt check by application software DMA SM 0 Periodical read back of configuration registers DoclD026823 Rev 2 47 90 Safety r
124. troller FS MC sess 22 3 6 6 NVIC and EXTI controller llli 23 3 6 7 DMA ett tieeutwd cami dais ie mo Re 23 3 6 8 CANT1 2 1 1 4 09 eal phe RR ert aha ei noe Rang eat ae Re os des 24 3 6 9 USART 1 2 3 4 5 ur vue a eG ne eu a ee AE PEE are 25 3 0 10 120 1 2 ale Sieh dap ace Wx oC ROS ae eX RR OR RARUS aR RR Rn 26 3 0 14 SPI 2I3 uis aere ipu ate RE ae ete naa Rd DUET pi 27 3 0912 SDIO ECCL 28 3 6 13 USB 2 0 Universal Serial Bus interface FS module 28 2 90 DoclD026823 Rev 2 Ly UM1814 Contents 3 6 14 Ethernet Media Access Control MAC 0 00000 eee eee 29 3 6 15 HDMI CEC module 0 000 eee 30 3 6 16 Analog to Digital Converters ADC 0 0 00 cee ee 31 3 66 17 DACW2 2c vadan veces apace wide decane ghee ERO SR Pu ERR eee eS 32 3 6 19 TIM 6 7 izle veda weed eeieithiatere ead IDE WE yea 32 3 6 19 TIM1 2 3 4 5 8 9 10 11 12 13 14 15 16 17 2 ee 33 3 6 20 GPIO PORT A B C D E F G 000 0 cece 34 3 6 21 Real Time Clock module RTC 0000 35 3 6 22 Supply voltage system 0 eile 35 3 6 23 Reset and clock control subsystem 0000 eee 36 3 6 24 Watchdogs IWDG WWDG 0 2000 cee eee 37 3 0 2 b Debug 2 2 iduuten usb e eger eg uc Dg edad 37 3 6 26 Cyclic Redundancy Check module CRC 0 0c eee ee 37 3 6 27 Dual MCU architecture 0 2 2 eee 37 3 6 28 Latent fault detection
125. ty The safety standards examined within this change impact analysis are the followings e SO 13849 1 2006 ISO 13849 2 2010 Safety of machinery Safety related parts of control systems e EC 62061 2012 11 ed 1 1 Safety of machinery Functional safety of safety related electrical electronic and programmable electronic control systems e EC 61800 5 2 2007 ed 1 0 Adjustable speed electrical power drive systems Part 5 2 Safety requirements Functional IEC 60730 1 2010 ed 4 0 Automatic electrical controls for household and similar use Part 1 General requirements e SO 26262 2010 Road vehicles Electrical and or electronic E E systems C 1 ISO 13849 1 ISO 13849 2 The ISO 13849 1 is a Type B1 standard It offers applicable solutions for the machinery domain of those safety general aspects outlined in the IEC 61508 standard This ISO standard provides a guideline for the development of safety related parts of control systems SRP CS including programmable electronics hardware and software requirements here supplied are compatible with the methodology of design defined in IEC 62061 Table 1 in ISO 13849 1 standard identifies the technologies which are used for the implementation of control systems for machines in the scope of ISO 13849 1 or IEC 62061 It results that complex electronics is restricted to those architectures defined in 6 2 of the ISO standard and with the achievable integrit
126. uding End to End safing UART SM 0 Periodical read back of configuration T nae X X s registers UART UART SM 1 Protocol error signals X X UART SM 2 Information redundancy techniques on ox m X X messages IIC SM 0 Periodical read back of configuration dd X X registers 12C IIC_SM_1 Protocol error signals X X IIC SM 2 Information redundancy techniques on EE messages X X Periodical read back of configuration registers SPI SPI SM 1 Protocol error signals X X Information redundancy techniques on SPI SM 0 X X SPI SM 2 X X o messages ETH SM 0 Periodical read back of configuration T X X registers ETH_SM_1__ Physical protocol error signals X X Ethernet MAC i ETH SM 2 Information redundancy techniques on m T X X messages Periodical software test for Ethernet using ETH_SM_3 mac loopback E a LSZ DoclD026823 Rev 2 41 90 Reference safety architecture UM1814 Table 3 List of safety mechanisms continued r Single Dual STM32F1 function Diagnostic Description MCU MCU Perm Trans USB SM 0 Periodical read back of configuration m j X X adi registers USB USB SM 1 Protocol error signals X X USB SM 2 Information redundancy techniques on 34 EF X X Hmessages HDMI SM 0 Periodical read back of configuration m X X registers HDMI SM 1 Protocol error signals X X
127. ue of accessible voltage of SELV PELV circuit if different from 8 1 1 product standard referred to for the Tab 1 87 application of the control in which standard s the E End user responsibility accessible SELV PELV level s is are given The minimum parameters of any heat dissipater for example heat sink not provided with an electronic control H 7 52 but essential to its correct operation Software sequence documentation H 7 66 Program documentation H 7 67 Software fault analysis H 7 68 Software class es and structure H 7 69 Analytical measures and fault error control techniques H 7 70 employed STM32F1 series safety H 7 71 manual and End User Responsibility Software fault error detection time s for controls with software classes B or C Control response s in case of detected fault error H 7 72 Software safety requirements H 11 12 3 2 1 Software architecture H 11 12 3 2 2 Module design and coding H 11 12 3 2 3 Design and coding standards H 11 12 3 2 4 Testing H 11 12 3 3 End user responsibility Inspection H 2 17 5 Walk through H 2 17 9 Static analysis H 2 17 7 1 Dynamic analysis H 2 17 1 Hardware analysis H 2 17 3 Hardware simulation H 2 17 4 STM32F1 series safety Failure rate calculation H 2 17 2 manual Ly DoclD026823 Rev 2 83 90 Change impact analysis for other safety standards UM1814 Table 14 IEC 60730 work pr
128. ural categories 0 0 0 ec eee 60 C 1 2 Safety metrics recomputation 0 000 cee eee 62 C 1 3 Work products 00 000 es 63 C 2 IEC 62061 2012 11 lllsssssssleeeeeeee ees 66 C 2 1 Architectural categories 0 00 eee 67 C 2 2 Safety metrics recomputation 0 000 cee eee 71 C 2 3 Work products 0 0000 cee s 72 C 3 IEC 61800 5 2 2007 lsssssseeeeeeee ss 73 C 3 1 Architectural categories 20 0 ee eee 73 C 3 2 Safety metrics recomputation llli eee 74 C 3 3 Work products o ege eee ie bide PR ERR p e e eus 74 C 4 IEC 60730 1 2010 2 20 20 0 75 C 4 1 Architectural categories 0 ee eee 76 C 4 2 Safety metrics recomputation llli eee 77 C 4 3 Work products eco eg a ek Roe dad eee d D ede 82 C 5 ISO 26262 2010 suits ex e Mad ed tee n Kk CR 84 C 5 1 Architectural categories 0 0 0 ee eee 85 C 5 2 Safety metrics recomputation 0 000 cee eee 85 C 5 3 Work products aired bee b ex x ee E REX Rue ee ERAS aa eu 86 Appendix D fRSTL STM32F1 SIL2 3 product and its use in the framework of this manual 87 Revision history c lt cetandcceterscceteede ERRARE REKERAZASSR RANA dha as oe 89 4 90 DoclD026823 Rev 2 3 UM1814 List of tables List of tables Table 1 Terms and abbreviations 2 0 0 ce tees 7 Table 2 Mapping between this document content and IEC 61508 2 Annex D requirements 2c ee e
129. wing e RTC backup registers are used to store the coded information and detect the absence of Vgar during power off period e RTC backup registers are used to periodically store compressed information on date time and allow the application software to execute minimal consistence checks for date reading after power on that is detect past date time retrieve Supply voltage system Periodical read back of configuration registers VSUP SM 0 This diagnostic measure that is typically referred to as Read Back Periodic by Software of Configuration Registers executes a periodical check of the configuration registers of the Power Control logic against their expected value that was previously stored in RAM and adequately updated after each configuration change It mainly addresses transient faults affecting the configuration registers detecting bit flips in the registers due to transient faults The registers test is executed at least once per DTI in order to be able to claim the related diagnostic coverage Supply Voltage Monitoring VSUP SM 1 It is required to detect early the under voltage and overvoltage conditions that are potential sources of failure at MCU level The power supply values close to the operating limits reported in device datasheet are considered at the same level as hardware faults and lead to similar recovery actions by the application software The use of internal Programmable Voltage Detector PVD helps to implemen
130. y manual 64 90 DoclD026823 Rev 2 d UM1814 UM1814 Change impact analysis for other safety standards Table 8 IEC 13849 work product grid continued ISO 13849 1 Information to be provided ISO 13849 1 Part Clause Computer aided design tools capable of simulation or analysis Simulation Safety related specification for machine control Definition of the control architecture STM32F1 series IEC 61508 document G 3 Measures for avoidance of systematic failures End user responsibility App J tab J 1 SW End user responsibility Software descriptions Function block modeling Encoding comments in the code Encoding re reading sheets Correspondence matrix Test sheets DoclD026823 Rev 2 Software User Guide End User responsibility because in charge of implementing software based diagnostics App J tab J 1 SW SW requirements specification End User responsibility because in charge of implementing software based diagnostics App J tab J 1 SW Code inspection results End User responsibility because in charge of implementing software based diagnostics App J tab J 1 SW Software module test specification Software system integration test specification Programmable electronic hardware and software integration tests specification End User responsibility because in charge of implementing software based diagnostics App J tab J 1 S
131. y level here defined as Performance Level PL up to PLr d that is SIL2 HD CM On the contrary complex electronics in the scope of IEC 62061 is suitable up to SIL 3 HD CM since this standard is properly focused on the electrical electronic part of controls The 6 2 of ISO 13849 identifies five categories for the basic parameters DC MTTFd and CCF reflecting the expected resistance to faults of SRP CS under design and needed to achieve the required PLr For each category the standard suggests a typical architecture that meets the related requirements DoclD026823 Rev 2 59 90 Change impact analysis for other safety standards UM1814 C 1 1 Architectural categories The section 6 2 of ISO 13849 identifies five categories for the basic parameters DC MTTFd and CCF reflecting the expected resistance to faults of SRP CS under design and needed for achieving the required PLr For each category the standard suggests a typical architecture that meets the related requirements Considering the ISO 13849 architectural categories defined in 6 2 and focusing on microcontrollers Table 7 presents a summary for end users willing to develop Logic Solver units suitable for safety critical channels and performing a defined safety function The assumptions are listed hereafter 1 The safety function is realized by combining in series the elements SRP CS input system signal processing unit output system 2 The SRP CSs elements may

STM32F1 series safety manual

Contents

Download Pdf Manuals

Related Search

Related Contents