N. G. Leveson and P. R. Harvey. Analyzing software safety. IEEE Transactions on Software Engineering, SE-9(5):569--579, September 1983.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....severity and danger. Design for safety is concerned with design principles that will reduce the likelihood and risk of hazardous states. Techniques such as interlocks, lockouts, and firewalls can be adapted from conventional system safety engineering [9] Software Fault Tree Analysis (SFTA) [8] is a method for analyzing software in order to identify unduly hazardous states. It is an adaptation to software of a technique that was developed and first applied in the late 60 s in order to minimize the risk of inadvertent launch of a Minuteman missile. The first step, as in any safety ....

N. G. Leveson and P. R. Harvey. Analyzing software safety. IEEE Transactions on Software Engineering, SE-9(5):569--579, September 1983.

....This paper describes a development environment that facilitates the construction of LSL specifications, including a graphical interface to theorem proving and syntax checking tools. 1 Introduction As software is increasingly used to control critical systems, program correctness becomes paramount [1, 2, 3, 4, 5, 6, 7]. A small change in the implementation of software can have a large and perhaps disastrous impact on its behavior [8] Formal methods focus a software development effort on an accurate and precise specification of what a software system or component is to achieve. This type of specification, when ....

Nancy G. Leveson. Formal Methods in Software Engineering. IEEE Transactions on Software Engineering, 16(9):929--930, September 1990.

....Department of Computer Science University of Kentucky Lexington, KY 40506 0027 fmarek,mirekg cs.engr.uky.edu 1 Introduction Nonmonotonic logics were introduced in the late 70s as knowledge representation formalisms. Default logic [Rei80] circumscription [McC80] autoepistemic logic [Moo85, Lev90] and logic programming with negation [ABW88, GL88, Apt90] turned out over the years to be most widely studied and most influential in the development of the area. To serve as a knowledge representation tool, a formal system must offer an expressive language with well understood semantics, and a ....

N.G. Leveson. Formal methods in software engineering, special issue on. IEEE Transaction on Software Engineering, 16:929--1103, 1990.

....to primitive programming language constructs, Seed is capable of synthesizing recursive and non recursive procedures and functions, and abstract data types. 1 Introduction Research concerning the use of formal methods in software tools seeks to facilitate the development of correct software [14, 8, 11, 13]. Our objective is to build a software development environment consisting of tools that will support the use of formal methods in all phases of the development of large software products, including design, specification, implementation, and maintenance. In the first stage of this project, we have ....

Nancy G. Leveson. Formal Methods in Software Engineering. IEEE Transactions on Software Engineering, 16(9):929--930, September 1990.

....recursive and non recursive procedures and functions, as well as abstract data types. Keywords: Formal methods, proofs of correctness, formal specifications, procedural abstraction 1 Introduction As software is used increasingly to control critical systems, correctness becomes paramount [1, 2, 3, 4]. Research into the development of software tools that support the use of formal methods is aimed at simplifying and providing assistance during the development of correct software. The objective of this project is to build a software development environment (SDE) comprising tools that supports ....

Nancy G. Leveson. Formal Methods in Software Engineering. IEEE Transactions on Software Engineering, 16(9):929--930, September 1990.

....[5] and a recent NRC Aeronautics and Space Engineering Board report [6] additionally motivate the use of error reducing and defect detection software development techniques. The benefits of formal methods in requirementsdriven software development ( forward engineering ) is well documented [7, 8, 9, 10]. One advantage to using rigorous approaches to software engineering is that formal notations are precise, verifiable, and facilitate automated processing [11, 12, 13] We claim that maintenance of critical existing ( legacy ) code also benefits from formal methods. For example, formal ....

....Material This section briefly defines and motivates the use of formal methods. Also, the benefits of object oriented analysis and design are presented. 2. 1 Formal Methods Formal methods in software development provide many benefits in the forward engineering aspect of software development [7, 8, 9, 15]. For any specification, there can be any number of implementations that satisfy the specification [16] Due to the criticality and the volume of much of the software being developed by many agencies involved in flight systems, there are several projects incorporating formal methods into the ....

Nancy G. Leveson. Formal Methods in Software Engineering. IEEE Transactions on Software Engineering, 16(9):929--930, September 1990.

....us to predict whether certain types of software failure will result. EPA is related in purpose to static fault tree analysis. In software safety, Leveson has written extensively on fault tree analysis, and she has been involved in applying it to several different large programming projects [2]. Fault tree analysis traces backwards in a cause effect sequence from identified hazards we wish to avoid to conditions which would allow that hazard to occur. Fault tree analysis is traditionally done in the early stages of design, but it can be done from code. In short, EPA is a natural ....

N.G. LEVESON AND P.R. HARVEY. Analyzing Software Safety. IEEE Transactions on Software Engineering, SE-9(5):569--579, September 1983.

....methods used by software maintenance engineers are observation (i.e. test case analysis) and examination of source code. These techniques are often tedious and error prone. Formal methods in software development provide many benefits in the forward engineering aspect of software development [22, 9, 17, 14, 11]. One of the advantages to using formal methods in software development is that the formal notations are precise, verifiable, and facilitate automated processing [3] For any specification, there may be several implementations that satisfy the specification [10] There have been recent ....

Nancy G. Leveson. Formal Methods in Software Engineering. IEEE Transactions on Software Engineering, 16(9):929--930, September 1990.

....may affect critical aspects of the system behavior, such as critical variables, statements, and modules. This information might be based on safety critical or mission critical analyses (such as those proposed by the British MOD Standard 0055 0056 [BMD91a, BMD91b] or software safety analysis [LH83] Testing approaches must determine and test for the potentially catastrophic faults associated with these components. For example, in an x ray machine, the component controlling the level of radiation requires particular scrutiny, and faults that could lead to lethal doses, if possible, should ....

....can analyze this failure condition and transfer route information to determine if a hypothetical fault or state potential failure could lead to a critical failure. A failure condition leading to a critical failure is similar to the failure scenarios constructed by software fault tree analysis [LH83] Third, we may use the failure condition to direct selection of additional test data for execution. 5 Major Contributions and Summary This paper presents the Relay model of faults and failures, focusing on transfer of an incorrect intermediate state, or potential failure, from a faulty ....

Nancy G. Leveson and Peter R. Harvey. Analyzing software safety. IEEE Transactions on Software Engineering, 9(5):569--579, September 1983.

....analysis of electro mechanical devices involves the identification of the immediate pre conditions for catastrophic failure in a software (or software hardware system) and regression of those conditions back to the system inputs that will cause them. An overview of the technique is given in [Leveson and Harvey, 1983] and [Leveson, 1991] The software fault tree approach requires a priori knowledge about ways in which the software system can fail catastrophically. It is an analysis tool for improving the robustness of a system by identifying safety related weaknesses in advance. The technique is powerful ....

N. Leveson and P. R. Harvey. Analyzing software safety. IEEE Transactions on Software Engineering, SE-9(5), September 1983.

....an object oriented library of software components designed for constructing formal specification editing tools; prototype specification editors built from this library are presented. 1 Introduction The number of applications to which the reliability of software is critical continues to increase [1, 2]. Software errors have been the cause of a wide variety of problems from telephone network failures [3, 4, 5] to aircraft disasters [6] Many rigorous mathematical techniques are being developed to determine software correctness [7, 8, 9, 10, 11, 12] these techniques are collectively referred to ....

Nancy G. Leveson. Formal Methods in Software Engineering. IEEE Transactions on Software Engineering, 16(9):929--930, September 1990.

....to apply formal analysis procedures to the model in order to ensure that the software requirements model satisfies required system functional goals and constraints, including safety. Several different safety analysis procedures have been developed by members of the Irvine Safety Research Group [LH83, LS87, LCS91, JLHM91] but they work on diverse models and have not been validated on real software. Our long term goal is to develop a coherent, complete, and practical methodology for building safety critical systems. This paper concentrates on the earliest part of the methodology, i.e. ....

N.G. Leveson and P.R. Harvey. Analyzing Software Safety. IEEE Transactions on Software Engineering, SE-9(5):569--579, September 1983.

No context found.

N. G. Leveson and P. R. Harvey. Analyzing software safety. IEEE Transactions on Software Engineering, SE-9(5):569--579, September 1983.

No context found.

N.G. LEVESON AND P.R. HARVEY. Analyzing Software Safety. IEEE Transactions on Software Engineering, SE-9(5):569--579, September 1983.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC