Unformatted text preview:

Summary of Inspection of Safety-Critical Software Case study: Darlington nuclear power plant shutdown system Prepared by: Ke TangFor The Darlington Nuclear Generating Station shutdown systems, the hardware solutions are simple, easily studied and offer a great deal confidence. The Software solutions are more complex than hardware, but offer more intelligent system monitoring. It can offer diagnostic aids and can perform periodic testing more often. It requires less equipment. So It worth a tryThe software work begin 1983, multiple versions were development. The codes are surprisingly small, both contains about 6,000 lines of assembly code (one is 7,000 lines of FORTRAN, another is 13,000 Pascal). And the Unit testing, integrating test, random testing, software assessment and hazard analysis are performed. But when reviewed by AECB in 1987, the license was not granted. Because there exited too much doubt about whether the software implemented the requirements correctly!So AECB hired David Parnas of Queen’s University in mid of 1987. He found out that the documents are written in nature language, necessary information was hard to find, no confidence that all problems has been found. So Parnas proposed a formal mathematical inspection in Jan. 1989. And to perform this inspection, two dimension expressions, tables, were used. Helped both designers and reviewers Software requirement document.In Parnas documentations of computer system designSystem Requirement: gives a description of the environment in terms of environment state variables. It describes the relations among these state variables. It also specifies the additional relations that must be established and maintained by the computer system.System design document: identifies the computers within the system, and specifies the communications between the computers and the environment by describing the relations that will exist between the values of the environmental state variables and the values of the computer.Software Function Specification: records additional design decisions and describes the exact behavior of the softwareIn the formal mathematical inspection, the functional relations are very important. The contents of the documents are a representation of the following 5 mathematical relations:1) REQ(mt,ct) 2) IN(mt, it) 3) OUT(ot,ct) 4) NAT(mt,ct) 5) SOF(it,ot)and the folloeing mathematical relation must be satisfied. mt, it ,ot ,ct [IN(mt, it)^ SOF(it,ot)^ OUT(ot,ct)^NAT(mt,ct)]REQ(mt,ct)For systems have a large number of discontinuities that can occur at arbitrary points in the domain, the tabular formats have been found to be more practical for the description and communication of these functions between system designers and software engineers.The program function documentation: describes the precise effect of the program without describing the intermediated states. Each document contains representation of certain relations. Additional information makes the document faulty. And for the shutdown system, the multi-dimensional notation is the author’s choice.The program function documentation has the following advantages:1) Tables control the complexity of the expressions. 2) Tables parse the expression, made it easy to understand for the reader. 3) Tables eliminate many repetitions of sub expressions. 4) Each table entry applies to a small part of the functions domain, the expression in that entry can be simplifiedFollowing the proposed ideas, AECB made 4 inspection teams:1) Requirements team – produces tabular representation of the requirements.2) Code inspection team – produces program-function tables from the code.3) Comparison team – finds equivalence between requirements tables & program-function tables by showing step-by-step transformations from one to the other.4) Audit team – checks the work of the other three teams.Tables can facilitate both random and selective testing. The tables identify the discontinuities in the program functions and clearly identify the limiting and boundary cases that are known to be major sources of programming faults. Tables also identify intervals between discontinuities and help verify that all intervals have been covered by a test set.It is certain that formal documentation is a key issue in the specification, design, and review of software for critical control and safety functions. Tabular forms present great advantages over other forms of documentation techniques. Make the systematic inspection advanced. This approach (Tabular forms) is practical when reliability and trustworthiness are extremely important and the codes are relatively small. The Darlington project is costly, but built the Canada Standard, which will benefit the future developments.References:D.L. Parnas, G. Asmis and J. Madey, Assessment of Safety-Critical Software in Nuclear Power Plants, Nuclear Safety, vol. 32, no. 2, April-June 1991, pp. 189-198.P. J. Courtois, D. L. Parnas, Documentation for safety Critical software, Processing of the 15th international conference on Software Engineering, p.315-323, May 17-21, 1993Parnas D. L., Van Schouwen, A.J., Shu Po Kwan (1990) Evaluation of Safety Critical Software. Communications of the ACM, 33,6,636-648.D Parnas, Inspection of Safety-Critical Software Using Program-Function Tables, in Report No. 288, Communications Research Laboratory, McMaster University, Canada, June 1994Jeffrey Smith, Richard Bruno, Vince Fumo Inspection of safety-critical software using program-function tables..J. Dennis Lawrence, Warren L. Persons, and G. Gary Preckshot (Lawrence Livermore National Laboratory) Evaluating Software for Safety Systems in Nuclear Power PlantsCanada Nuclear websiteSummary of Inspection of Safety-Critical SoftwareCase study: Darlington nuclear power plant shutdown system Prepared by: Ke TangFor The Darlington Nuclear Generating Station shutdown systems, the hardware solutions are simple, easily studied and offer a great deal confidence. The Software solutions are more complexthan hardware, but offer more intelligent system monitoring. It can offer diagnostic aids and can perform periodic testing more often. It requires less equipment. So It worth a tryThe software work begin 1983, multiple versions were development. The codes are surprisingly small, both contains about 6,000 lines of assembly code (one is 7,000 lines of FORTRAN, another is 13,000 Pascal). And the Unit testing, integrating test, random testing, software assessment and hazard analysis


View Full Document
Download Study Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Study Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Study Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?