Analyzing Safety Requirements for Process-Control Systems

  • Authors:
  • Rogério de Lemos;Amer Saeed;Tom Anderson

  • Affiliations:
  • -;-;-

  • Venue:
  • IEEE Software
  • Year:
  • 1995

Quantified Score

Hi-index 0.01

Visualization

Abstract

An alarming trend is appearing in the development of safety-critical systems: Demands for dependability are rising faster than what can currently be achieved, especially for complex systems. For these systems, the software's functional criticality is increasing in tandem with its complexity, posing a major challenge for software developers.1 As the trend continues, researchers are looking more closely at the requirements phase as the solution for managing errors. Experience shows that mistakes made during this phase can easily introduce faults that lead to accidents, so preventing faults during this phase should produce more dependable systems. However, in safety-critical systems, you cannot assess the adequacy of software safety requirements except with respect to overall system risk. This means that you must also conduct a safety analysis of the resulting safety specifications to ensure that the software's contribution to system risk is acceptable. Safety-requirements analysis is typically conducted either ad hoc or with the unbridled use of formal methods. At the University of Newcastle upon Tyne, we have investigated these issues and have developed an approach that comprises safety-enhancing methods and techniques for identifying safety requirements and analyzing them. The methods and techniques are targeted to safety-critical process-control systems, which include domains such as power generation, aerospace, and transportation. Our approach provides for a systematic analysis of system requirements to determine mission and safety requirements, an analysis of safety requirements, the recording of safety specifications, and a safety analysis of safety specifications. This approach offers the freedom to mix formal and traditional engineering methods and apply them at different abstraction levels to give a higher assurance that the software's contribution to system risk is acceptable. We have demonstrated the feasibility of our approach by applying it to a chemical batch-processing plant. We believe our approach increases the visibility of the requirements process by partitioning the analysis into distinct phases that are based on the domains of analysis established from the system structure. Freedom to tailor a technique to a specific domain of analysis and perspective ensures that the most appropriate techniques are applied. Formally recording the safety specifications helps in building and comparing safety strategies. Finally, using both qualitative and quantitative techniques gives a precise picture of the specification's contribution to overall system risk.