Minimal embedded robustness requirements analysis

Abstract

That a significant fraction of software-related accidents are due to requirements problems is no longer news. Numerous researchers have taken the trouble to sift through the available data and concluded that requirements problems are involved in between 30 to 60% of software related accidents, many of them caused by factors more prosaic than the usually domain-dependent hazards identified by a Preliminary Hazard Analysis (PHA) [1]. The focus in this paper is to build on the previous work of the author [2] and other researchers (particularly R. Lutz [3]), which has provided some “checklist”-like guidelines for reviewing software requirements for safety-critical system, but categorize and organize them in terms of the concepts and vocabulary from more traditional hazard analyses. The result, it is hoped, will be a useful definition of a basic set of hazard and robustness analyses for the software requirements for embedded systems; analyses that are applicable, indeed only possible, during or after the software requirements development phase, usually long after the PHA has been performed by domain safety experts. To set this work in the proper (limited!) context, it must be emphasized that the taxonomy and analyses here focus on identification of potential hazards. Determining whether or not a potential hazard is actually a hazard for a specific application will still require domain-specific knowledge, as will determining the appropriate additions or modifications to the software requirements to preclude or reduce the severity of such hazards. But although final resolution may require domain expertise, the identification of a broadly applicable set of potential problems need not. The taxonomy presented here starts from the conventional notions of hazards of commission (both direct and indirect) versus hazards of omission and discusses some subtleties in how these standard concepts pertain to software in embedded systems. It then extends the taxonomy further, specifically into the realm of embedded systems software.