Performing ‘POSTs’ in safety-related embedded systems
On this page, we present a ‘checklist’ that we have found useful when developing (and reviewing) software for safety-related embedded systems in compliance with standards such as ISO 26262 and IEC 61508.
This checklist is concerned with ‘Power-On Self Tests’ (POSTs).
This checklist is intended primarily for use with designs that are implemented using a TT software architecture.
[This page was last updated: 2017-08-25]
- use an independent clock source to check the oscillator frequency;
- use a suitable library to test RAM memory and CPU registers;
- use a ‘Golden Signature’ to check the executable code;
- test the memory areas used to store Register Variables;
- test the internal WDT (iWDT);
- use the (tested) iWDT to check the Scheduler operation;
- perform startup checks on all peripherals used in the application;
- perform checks on the eWDC, if present;
- perform checks on the MoniTTor;
- perform checks on the PredicTTor;
- perform key environmental checks, such as measuring the ambient temperature and the Processor operating voltages;
- use a WarranTTor unit to check for security infringements, if this is deemed to be necessary;
- use a second Processor (in multi-Processor designs) to perform additional checks on the Platform, including the Schedulers / interrupt system and operating frequencies.
What do we do if we fail one of the POSTs?
The key question that we are trying to answer through the use of low-level POSTs is as follows: ‘Do we have an operational Processor to work with?’
If the answer is ‘no’, then all we can do is try to enter a Fail-Safe Processor State.
If our Platform is based on a single Processor and this fails a POST, it is difficult to be confident that this PROCESSOR will be able to perform the operations that are needed in order ‘fail safely’.
If we have only one Processor in the Platform and failure of the POSTs could result in a dangerous situation, then we will almost certainly need to consider adding: an external Watchdog Controller unit or a WarranTTor unit; or an additional Processor to the Platform.
This issue must be considered carefully during the development process.
Learn more about POSTs in ‘ERES2’
The Second Edition of ‘The Engineering of Reliable Embedded Systems’ (ERES2), documents an industry-proven approach to the development of software for reliable, real-time embedded systems, based on the use of ‘Time Triggered’ (TT) architectures.
What distinguishes TT approaches is that it is possible to model the expected system behaviour precisely. This means that: [i] during the development process, we can demonstrate that all of the requirements have been met; and [ii] at run time, we can detect problems very quickly.
The end result is that we can have a high level of confidence that a TT system will either: [i] operate precisely as required; or [ii] move into an appropriate state if a problem occurs.
The above characteristics mean that appropriately-implemented TT systems provide a particularly effective means of meeting the requirements of various international safety standards.