Abstract Suitable formalisms could allow the arguments of a safety case to be checked mechanically. We examine some of the issues in doing so. 1

Static analysis tools are gaining popularity for safeguarding against the most common causes of errors in software. The main focus of these tools is on automatic bug-finding—the first stage in a two-phase process where the tool finds bugs and the human then corrects them. This article explains that such a goal is too narrow for critical software assurance (SwA). Instead, static analysis tools should adopt a broader perspective: computing properties of software. Static analysis tools (see the sidebar on page 7) are very useful for finding bugs. They go far beyond the capabilities of compilers (warnings) and coding standard checkers to which they are directly related. Like compilers when they generate warnings, static analysis tools aim to detect possible run-time errors (e.g., buffer overflow) and logic errors (e.g., variables not referenced after being assigned). Like coding standard checkers, static analysis tools sometimes allow users to define their own set of patterns to flag. But static analysis tools generally perform much more sophisticated analyses than is typically found in compilers and coding standard checkers (e.g., looking at global context and keeping track of data and control flow). The appeal of these tools is immediate, providing an almost yes/no answer to very hard problems (termed undecidable in mathematical terms). But while you’re asking Are there any bugs in this code?, the tool is actually answering a subtly different question: Have any bugs been detected in this code? Thus, when a tool answers no problems, it means that it couldn’t detect any bugs; it doesn’t mean that the code has no bugs. Further, the actual question should be: Have any shallow/common bugs been detected in this code? As explained by a team at software integrity company Coverity: “errors found with little analysis are often better” because they are clear errors that a human reviewer will more likely understand [1]. That is the catch. Static analysis tools are not compilers whose output (object code) rarely needs to be inspected. They produce results for humans to review. At the very least, a human needs to understand the problem being reported—and also, in most cases, the reason for the report—in order to assess what, if any, correction to make. Focusing on Human-Readable Output

Abstract – The level of complexity in Systems of Systems is increasing as more complex functionality emerges from the interaction of individual components. As networks become more complex it becomes more difficult for an individual to identify potential safety risks. We know, from previous accidents, that poor understanding of networks can be dangerous. In this paper, we demonstrate the potential value of incorporating a process to identify risks in a deployed network, focusing on factors concerned with the interaction of this process with a user, and the potential for new hazards.

Certifying agencies have begun to require a safety case as part of the product certification process. The standards upon which such certification regimes are built define properties that the safety case must have, e.g., “compelling, ” and “valid”, yet leave these terms undefined. Unaided judgment of these properties leaves doubt about how approval will proceed. We introduce an operational definition of these terms in the form of a comprehensive certification process for certification based upon the submission of a safety case. The process defines how certification could be conducted. The process also defines the properties that an acceptable safety case must have since successful certification with this process implies that the safety case has the desired properties. We illustrate our approach to certification using hypothetical argument fragments.