• • • TEST & MEASUREMENT • • •
hardware, software, or hardware-software integration levels, different methods are recommended to guarantee that the product won’t cause issues when doing its job:
Fault injection Fault injection is a technique oriented to verify if the internal chip mechanisms designed to mitigate failures react properly. For example, in a digital chip containing memories equipped with error detection and correction (EDC), a soft-error toggling a memory cell must not have consequences if the EDC works properly. The fault injection tools user interface is much more complex than the fault simulation one, since the pass/fail criteria are not so obvious: in some cases the system requirements can stipulate that in the event of a failure, the SoC must jump to a safe state (e.g. ISO 26262), so a simple comparison with a reference good pattern is not sufficient, and some more elaborated comparison is needed. In silicon chips, the fault injection methodology must be performed at the pre-tape-out stage or at a device validation/qualification time.
Testability
In the design of high integrity SoCs there is a pitfall: what is good for reliability is not always good for testability. Indeed, the use of redundancy like the standard 3-votes TMR flip-flops (Triple Modular Redundancy) may lead to unscreened faults during the chip production, since the TMR will “correct” them. Therefore, special design measures must be taken during the design and verification phases to disable such redundancy when the chip is not in mission mode. For example, a chip using scan-path as a DFT strategy, it must treat every TMR flip-flop as three different ones.
Embedded Software Complex SoC normally contain embedded processors that manage the overall data processing flow. Internal ROM, OTP, or flash memories store the firmware image, and depending on the application, it is loaded during production or at system startup via comms devices (bootloader). Moreover, systems based on flash memories offer the possibility to upgrade the image once the application is in the field. The software development process is subject to exhaustive verification steps, and in the case of ISO 26262 ASIL D, the standard proposes difference methods, which often need the use of auxiliary tools.
Closing thoughts
Different standards tailored to different industrial contexts have been published to guide hi-rel product development, but all of them have some something in common: high integrity systems require a careful verification plan, able to reproduce critical situations that could occur at the field to ensure that the implemented safety measures do the job properly. Even if effective verification methods have been proposed, the high complexity and time-consuming nature of these tasks shows that there is still a lot of room for improvement in order to make this process more reliable and efficient.
24 ELECTRICAL ENGINEERING • OCTOBER 2024
electricalengineeringmagazine.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50
