Editing Embedded system (section)

===Reliability===
Embedded systems often reside in machines that are expected to run continuously for years without error, and in some cases recover by themselves if an error occurs. Therefore, the software is usually developed and tested more carefully than that for personal computers, and unreliable mechanical moving parts such as disk drives, switches or buttons are avoided.

Specific reliability issues may include:
* The system cannot safely be shut down for repair, or it is too inaccessible to repair. Examples include space systems, undersea cables, navigational beacons, bore-hole systems, and automobiles.
* The system must be kept running for safety reasons. Reduced functionality in the event of failure may be intolerable. Often backups are selected by an operator. Examples include aircraft navigation, reactor control systems, safety-critical chemical factory controls, train signals.
* The system will lose large amounts of money when shut down: Telephone switches, factory controls, bridge and elevator controls, funds transfer and market making, automated sales and service.

A variety of techniques are used, sometimes in combination, to recover from errors—both software bugs such as [[memory leak]]s, and also [[soft error]]s in the hardware:
* [[watchdog timer]] that resets and restarts the system unless the software periodically notifies the watchdog subsystems
* Designing with a [[trusted computing base]] (TCB) architecture ensures a highly secure and reliable system environment<ref>{{cite journal |url=http://c59951.r51.cf2.rackcdn.com/5557-528-heiser.pdf |archive-url=https://web.archive.org/web/20141129070740/http://c59951.r51.cf2.rackcdn.com/5557-528-heiser.pdf |archive-date=2014-11-29 |url-status=live |title=Your System is secure? Prove it! |first1=Gernot |last1=Heiser |date=December 2007 |volume=2 |issue=6 |pages=35–8 |journal=[[;login:]]}}</ref>
* A [[hypervisor]] designed for embedded systems is able to provide secure encapsulation for any subsystem component so that a compromised software component cannot interfere with other subsystems, or privileged-level system software.<ref>{{cite book|last1=Moratelli|first1=C|last2=Johann|first2=S|last3=Neves|first3=M|last4=Hessel|first4=F|title=Proceedings of the 27th International Symposium on Rapid System Prototyping: Shortening the Path from Specification to Prototype|chapter=Embedded virtualization for the design of secure IoT applications|pages=2–6|date=2016|chapter-url=https://ieeexplore.ieee.org/document/7909116|access-date=2 February 2018|doi=10.1145/2990299.2990301|isbn=9781450345354|s2cid=17466572}}</ref> This encapsulation keeps faults from propagating from one subsystem to another, thereby improving reliability. This may also allow a subsystem to be automatically shut down and restarted on fault detection.
* Immunity-aware programming can help engineers produce more reliable embedded systems code.<ref name=":1">{{Cite book|last=Short|first=Michael|title=2008 IEEE/ACS International Conference on Computer Systems and Applications |chapter=Development guidelines for dependable real-time embedded systems |date=March 2008|chapter-url=https://ieeexplore.ieee.org/document/4493674|pages=1032–1039|doi=10.1109/AICCSA.2008.4493674|isbn=978-1-4244-1967-8|s2cid=14163138|url=https://figshare.com/articles/conference_contribution/Development_Guidelines_for_Dependable_Real-Time_Embedded_Systems_/10083272 }}</ref><ref>{{Cite web|last=Motor Industry Software Reliability Association|title=MISRA C:2012 Third Edition, First Revision|url=https://www.misra.org.uk/product/misra-c2012-third-edition-first-revision/|access-date=2022-02-03|language=en-GB}}</ref> Guidelines and coding rules such as [[MISRA C|MISRA C/C++]] aim to assist developers produce reliable, portable firmware in a number of different ways: typically by advising or mandating against coding practices which may lead to run-time errors (memory leaks, invalid pointer uses), use of run-time checks and exception handling (range/sanity checks, divide-by-zero and buffer index validity checks, default cases in logic checks), loop bounding, production of human-readable, well commented and well structured code, and avoiding language ambiguities which may lead to compiler-induced inconsistencies or side-effects (expression evaluation ordering, recursion, certain types of macro). These rules can often be used in conjunction with code [[Static program analysis|static checkers]] or bounded [[model checking]] for functional verification purposes, and also assist in determination of code [[Worst-case execution time|timing properties]].<ref name=":1"/>