Show Menu

Safety and Reliability of Embedded Systems Cheat Sheet (DRAFT) by

Safety and Reliability of Embedded Systems

This is a draft cheat sheet. It is a work in progress and is not finished yet.


Quality Management
ensure that the develo­pment processes are suitable
Quality Assurance
ensure that the develo­pment steps provided the desired results


* Technical and organi­zat­ional means for the autonomous fulfil­lment of a task
*Generally, a system can consist of hardware, software, people (service and mainte­nance personnel) and logistic assistance
Technical System
* System where influences by people and logistics are ignored
* Degree in which the inherent (anhaf­tend, dazuge­hörend) attributes of an entitiy fulfill quality requir­ements
Quality Requir­ement
* Expect­ation or demand defined (by a customer) that is generally assumed or mandatory
Quality Charac­ter­istics
* Property of an entity on the basis of which its quality is described and estimated, but which makes no statement about the degree of fulfil­lment of the charac­ter­istic
* A quality charac­ter­istic can be refined increm­entally into partial charac­ter­istics
* Inherent attribute of a process, product or a system that relates to a quality requir­ement /DIN EN ISO 9000 05/
Quality Measure
* Measure which allows to draw conclu­sions on the fulfil­lment of specific quality charac­ter­istics. For instance, MTTF (Mean Time To Failure) is a quality measure of the quality charac­ter­istic Reliab­ility
* State where the danger of a personal or property damage is reduced to an acceptable value (DIN EN ISO 8402)
* Birolini defines safety as a measure for the ability of an item to endanger neither persons, property nor the enviro­nment
* A distin­ction is drawn between the safety of a failur­e-free system (accident preven­tion) and the technical safety of a failure afflicted system
* Absence of unacce­ptable risks /IEC 61508 98/
Safety analysis aims at proving that the actual risk is below the acceptable risk
Technical Safety
* Measure for the ability of a failure afflicted item to endanger neither persons, property nor the enviro­nment
* Correc­tness has a binary character, i.e., an item is either correct or incorrect
* A fault-free realiz­ation is correct
* An artifact is correct if it is consistent to its specif­ication
* If no specif­ication exists for an artifact, correc­tness is not defined
* A system is functional complete, if all functions required in the specif­ication are implem­ented. This concerns the treatment of normal cases as well as the interc­eption of failure situations
* Property to deliver an acceptable behavior also in except­ional situations (e.g. ability of a software to detect hardware failures)
* A correct system – as measured by the specif­ication – can have a low robust­ness, actually
* Accord­ingly, robustness is rather a property of the specif­ication than of the implem­ent­ation
* A robust program is the result of the correct implem­ent­ation of a good and complete specif­ication
* Robustness has a gradual character
* Part of the quality with regard to the behavior of an entity during or after given time periods with given working conditions (DIN 40041)
* Collective term for the descri­ption of the power concerning availa­bility and its influe­ncing factors: power concerning functi­ona­lity, mainta­ina­bility and mainta­ina­bility support (DIN EN ISO 8402)
* Property of an entity regarding its qualif­ication to fulfill the reliab­ility requir­ements during or after given time periods with given applic­ation requir­ements (DIN ISO 9000)
* Measure for the ability of an item to remain functi­onal, expressed by the probab­ility that the required function is executed failur­e-free under given working conditions during a given time period (based on Birolini, ETH)
* Measure for the ability of an item to be functional at a given time