| Judith Crow and Ben L. Di Vito. Formalizing Space Shuttle software requirements. In First Workshop on Formal Methods in Software Practice (FMSP '96), pages 40--48, San Diego, CA, January 1996. Association for Computing Machinery. |
.... ity [41] FDTs developed into an active research area, resulting in a wide variety of methods, many of which have been successfully applied to specifying industrial size systems [13, 15, 3, 34, 10, 43] However, the majority of applications have been confined to the safety critical domain [16,26,33], although such systems ac count for only a small fraction of the software industry. The reason has been attributed to the gap between what the academia has to offer and what the commercial software industry needs [2, 7, 37, 50] In particular, a large majority of formal methods address only the ....
J. Crow and B.L. Di Vito. "formalizing Space Shuttle Software Requirements". In Workshop on Formal Methods in Software Practice, San Diego, California, January 1996.
....in terms of state machines, which are a formal, mathematical representation that is amenable to various kinds of automated analysis. It is becoming accepted that such formal descriptions can be useful in requirements analysis and other verification and validation activities for critical systems [5]. It is also becoming accepted that state machines provide a natural representation for mental models [12] Now, if a state machine specification is available for the actual system, and if we can construct one for a plausible mental model, then we could, in principle, run the two machines in ....
Crow, J. and Di Vito, B. L. Formalizing Space Shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296--332, July 1998.
....reviews: analyses are systematic, can be checked by others, and can even be automated. Especially when automated, analyses can be more reliable and thorough than reviews, and cheaper. And they liberate human time and talent for those issues that really do require judgment and consensus (see, e.g. [4]) There are two main approaches to specifying requirements in a formal manner: one way is to describe a model system that has the characteristics required and then stipulate that an acceptable implementation must be a refinement, in some suitable sense, of that model. The other way is to specify ....
Judith Crow and Ben L. Di Vito. Formalizing Space Shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296--332, July 1998.
....in terms of state machines, which are a formal, mathematical representation that is amenable to various kinds of automated analysis. It is becoming accepted that such formal descriptions can be useful in requirements analysis and other verification and validation activities for critical systems [6]. It is also becoming accepted that state machines provide a natural representation for mental models [13] Now, if a state machine specification is available for the actual system, and if we can construct one for a plausible mental model, then we could, in principle, run the two machines in ....
Crow, J. and Di Vito, B. L. Formalizing Space Shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296--332, July 1998.
....can deal with not only integral multiplicative constraints but also arbitrarily complex (e.g. trigonometric) constraints over finite or infinite domains, provided an appropriate constraint solver is available. Abstracting a constraint as a single Boolean variable is not a new idea (e.g. CDV96] However, since infeasible combinations of constraints are not automatically detected, either the approach is incomplete for safety properties, or it requires substantial manual abstraction. Wang et al. WME93] also represent certain timing constraints in distributed real time systems as BDD ....
J. Crow and B. L. Di Vito. Formalizing space shuttle software requirements. In Proceedings of the ACM SIGSOFT Workshop on Formal Methods in Software Practice, pages 40--48, January 1996.
....13] The team combines personnel with experience in formal methods, in the domains where formal methods are being applied, in software assurance and V V, and in technology transfer. A series of studies by this team have explored formal methods on a number of NASA programs, including Space Shuttle [5], Space Station [14, 15] and Cassini [16] Throughout these studies, the emphasis has been on pragmatic application of formal methods in areas where there appears to be the greatest need. Results of these studies are described in two NASA guidebooks [17, 18] Although some development of the ....
....was jointly funded by NASA headquarters, as part of the pilot program in formal methods. The need that arose from the independent assessment dovetailed with the aims of the inter center formal methods team. We had completed some preliminary studies of Space Shuttle re engineering requirements [5], which had demonstrated the potential for formal methods as a requirements assurance technique. However, this work concentrated on analyzing change requests for an existing system. The space station work was a chance to get in early in the high level (system) requirements phase for an entirely ....
J. Crow and B. L. Di Vito, "Formalizing Space Shuttle Software Requirements," presented at Workshop on Formal Methods in Software Practice (FMSP `96), San Diego, California, January 1996.
....specified by a state machine, which is a formal, mathematical description that is amenable to various kinds of automated analysis. It is becoming accepted that such formal specifications can be useful in requirements analysis and other verification and validation activities for critical systems [3]. If a state machine specification is available for the actual system, and if we can construct one for a plausible mental model, then we could, in principle, run the two machines in parallel to see if their behaviors ever diverge from one another. What is potentially valuable about this approach ....
Judith Crow and Ben L. Di Vito. Formalizing Space Shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296--332, July 1998.
....cations [31] and through the process of formal challenges [39] where expected properties are stated of a speci cation and examined by theorem proving or model checking. PVS has been used by multiple NASA centers to analyze requirements for the Cassini Spacecraft [13] and for the Space Shuttle [9], and by the SafeFM project (University of London) in the analysis of requirements for avionics control systems [12] 4 Hardware Veri cation Applications of PVS to hardware veri cation fall into two broad classes. One class is concerned with veri cation of the complete microarchitecture against ....
Judith Crow and Ben L. Di Vito. Formalizing Space Shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296-332, July 1998.
....[12] The construct generates proof obligations to ensure that the conditions labeling the rows and columns are disjoint and exclusive. This simple capability has been found useful by colleagues at NASA and Lockheed Martin, who applied it in requirements analysis for Space Shuttle flight software [2, 18]. The capability becomes rather richer in the presence of dependent typing, and in this form it has been used to verify the accessible region in a quotient lookup table for SRT division [19] When combined with other features of the PVS specification language, the table construct provides some of ....
....Analysts (RAs) from the team at Lockheed Martin (formerly IBM) that develops this software. Running alongside what is generally considered an exemplary (though manual) process for requirements review, this experiment provides useful data on the effectiveness of automated formal analyses [2, 18]. One of the CRs focused on improving the display of flight information to Shuttle pilots guiding the critical initial bank onto the Heading Alignment Cylinder (HAC) during descent. The CR documented key portions of the required control logic in tabular form, and was readily formalized using ....
[Article contains additional citation context not shown here]
Judith Crow and Ben L. Di Vito. Formalizing space shuttle software requirements: Four case studies. Submitted for publication, 1997.
....can be understood by practitioners, such as design engineers and requirements analysts. Yet, a number of barriers exist to more widespread industrial use of formal techniques such as PVS. Although Miller notes in [25] that engineers at Collins Aviation learned to use PVS, the authors of each of [25, 8, 9, 10] concede that in general practitioners themselves may be unwilling or unable to create formal specifications or to perform analysis of the specifications using the PVS proof checker. Further, Butler et al. 8] observe that one barrier to transferring formal methods technology to industry is that: ....
....with TAME and by the third author s experience with the RPC Memory example. Thus, we believe that specialized interfaces such as TAME can solve many of the problems associated with introducing the use of PVS into industrial practice. This is consistent with the point of view of Crow and Di Vito [10], who state in that: Applying formal methods right out of the box is difficult. Tailoring the methods to the application at hand is both necessary and desirable. As noted in Section 2, TAME is based on template specifications for given system models, standard supporting theories, and special ....
Judith Crow and Ben L. Di Vito. Formalizing space shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296--332, July 1998.
....case study, which compares the TAME approach to an alternate approach which uses PVS directly. Keywords Software engineering, software requirements analysis, formal methods, verification, theorem proving. This research is funded by the Office of Naval Research. 1. INTRODUCTION Several authors [25, 8, 9, 7] have found that the PVS specification language and similar strongly typed, higher order logic languages are well suited to the formalization of system specifications. All report that appropriately structured PVS specifications can be understood by practitioners, such as design engineers and ....
....can be understood by practitioners, such as design engineers and requirements analysts. Yet, a number of barriers exist to more widespread industrial use of formal techniques such as PVS. Although Miller notes in [25] that engineers at Collins Aviation learned to use PVS, the authors of each of [25, 8, 9, 10] concede that in general practitioners themselves may be unwilling or unable to create formal specifications or to perform analysis of the specifications using the PVS proof checker. Further, Butler et al. 8] observe that one barrier to transferring formal methods technology to industry is that: ....
Judith Crow and Ben L. Di Vito. Formalizing space shuttle software requirements. In Proc. First ACM Workshop on Formal Methods in Software Practice (FMSP'96), pages 40--48, San Diego, CA, January 1996.
.... process [2] these methods to a Shuttle CR for the Heading Alignment Cylinder (HAC) revealed that several rows in one table had overlapping conditions, and that several unstated assumptions needed to be articulated before the completeness and consistency of others could be established [3]. The Shuttle requirements analysts considered discovery of the missing assumptions to be particularly valuable. Similar successes with automated completeness and consistency checking have been reported for the RSML [6] and SCR [7] requirements methods. 2.3 State Exploration and Model Checking ....
Judith Crow and Ben L. Di Vito. Formalizing space shuttle software requirements: Four case studies. Submitted for publication, 1997.
.... that combine efficient and scalable automation with adequate expressiveness [1] Applying some of 1 At an earlier stage in this activity, formal methods had detected 30 issues, including 7 considered major, compared with 4, of which 1 was considered major, for the human review based process [2]. these methods to a Shuttle CR for the Heading Alignment Cylinder (HAC) revealed that several rows in one table had overlapping conditions, and that several unstated assumptions needed to be articulated before the completeness and consistency of others could be established [3] The Shuttle ....
.... to hardware and protocols, but their application to software and to requirements is relatively new (see, for example [8] Applying them to a Shuttle CR for three engines out abort sequencing revealed 19 errors, of which only 1 (albeit the most significant) had been discovered by human review [2]. 2.4 Formal Challenges Some of the most searching examinations of requirements specifications can be performed by challenging the specification with a putative theorem: if this specification captures my intent, then the following ought to follow. Suppose, for example, that we had specified ....
Judith Crow and Ben L. Di Vito. Formalizing Space Shuttle software requirements. In First Workshop on Formal Methods in Software Practice (FMSP '96), pages 40--48, San Diego, CA, January 1996. Association for Computing Machinery.
....die Implementation festgelegt. 2.2.3 De zite dieser Vorgehensweise Der interessanteste Schritt in dieser Aufstellung sind die Tre en zur Analyse der Anfrage. Dieser Schritt vereint Studium, Verst andnis und Analyse der Anderung. Gegenw artig existieren drei grundlegende De zite in diesem Teil [1]: 1. Es existiert kein methodisches Vorgehen f ur die Analyse Wie von einem Mitarbeiter beschrieben, ist dieser Schritt unstrukturiert und sehr vom Hintergrund, der Intelligenz und Ausdauer eines Analysten abh angig . Das Shuttle Projekt ( alle Beteiligten) 3 versucht gegenw artig (1996) ....
....eine spezielle dieser Arbeiten, die GPS Anderungsanfrage, deren Formalisierung 1995 von Ben Di Vito (V GIAN, f ur NASA Langley Research Center, LaRC) Larry Roberts (Lockheed Martin) und Judith Crow (SRI) und wahrscheinlich einigen anderen) durchgef uhrt wurde. Hauptziele der Arbeit waren [1]: Die Anwendbarkeit formaler Methoden auf kritische Shuttle Software in verschiedenen Stadien der Reife zu beweisen und zu dokumentieren. Wiederverwendbare Methoden und Strategien f ur repr asentative Klassen von Shuttle Software zu entwickeln. Schl usselpunkte des Technologie Transfers zu ....
[Article contains additional citation context not shown here]
Judith Crow and Ben L. Di Vito, Formalizing Space Shuttle Software Requirements Proceedings of the ACM SIGFOFT Workshop on Formal Methods in Software Practice (FMSP'96) San Diego, CA, January 1996, pp. 40-48
....the early phases of system engineering. e.g. 6] describes the use of strong type checking, completeness and consistency checking using powerful decision procedures and model checking of PVS for requirements engineering. This has been applied in several industrial applications. For instance, [1] describes four case studies in which requirements for new flight software subsystems on NASA s Space Shuttle were analyzed. The size of the analyzed specifications ranges from 20 to 110 pages of informal description. Analysis included reachability analysis using the state exploration tool Murphi ....
J. Crow and B. Di Vito. Formalizing space shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296--332, 1998.
....specifications are crucial to the success of system developments, it seems logical to apply formal specification techniques to the requirements for ensuring their completeness and consistency. However, most successful applications of formal methods have been confined to safetycritical projects [3, 4, 7] where software correctness is the pivotal goal. In contrast, the software industry seeks practical techniques that can be seamlessly integrated into their existing processes and improve productivity; absolute quality is often a desirable but not Contact address: Department of Computer Science, ....
J. Crow and B.L. Di Vito. "Formalizing Space Shuttle Software Requirements". In Workshop Formal Methods in Software Practice, San Diego, California, January 1996.
....are crucial to the success of system developments, it seems logical to apply rigorous specification techniques to the requirements for ensuring their completeness and consistency. The majority of successful applications of formal modeling have been confined to safety critical projects [5, 13, 19] where software correctness is the pivotal goal. In contrast, the commercial software industry seeks practical techniques that can be seamlessly integrated into the existing development processes and improve productivity; absolute quality is often a desirable but not crucial objective. Although ....
J. Crow and B.L. Di Vito. "Formalizing Space Shuttle Software Requirements". In Workshop on Formal Methods in Software Practice, San Diego, California, January 1996.
....focuses on achieving the higher quality of software. After an initial investment into creating formal specifications, applying formal methods can result in better understanding of systems, lower code complexity [16] and higher quality software artifacts (e.g. requirements and implementations) [5]. These benefits logically lead to a reduction in the time and cost of the development, although they are perceived to be long term. Coupled with limitations such as generally complex notations, a lack of methodology, reduced benefits when requirements are not stable (and most of the software ....
J. Crow and B.L. Di Vito. "Formalizing Space Shuttle Software Requirements: Four Case Studies". ACM Transactions on Software Engineering and Methodology, 7(9):296--332, July 1998.
....mechanized formal verification is unlikely to be more difficult or to take longer and may be considerably easier, as well as less error prone than a comparably detailed informal examination. Much worthwhile analysis can be accomplished economically and reliably in this way (see, for example, [4], which describes analysis of tables and other requirements specifications for This work was supported by Darpa through USAF Rome Laboratory Contract No. F30602 96 C 0204, and by the National Science Foundation under contract CCR 9509931. some recent Space Shuttle software) but there is much ....
J. Crow and B. L. Di Vito. Formalizing Space Shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296--332, July 1998.
....written in Lisp and it is strongly integrated with (Gnu and X) Emacs. The source code is not freely available. PVS has been applied to several serious problems. For example to specify and design fault tolerant flight control systems, including a requirements specification for the Space Shuttle [CD96] References to more applications of PVS can be found in [Rus] Isabelle is being developed in Cambridge, UK, and in Munich. The first version of the system was made available in 1986. Isabelle uses several ideas of the LCF prover [GMW79] formulae are ML values, theorems are part of an abstract ....
Judith Crow and Ben L. Di Vito. Formalizing Space Shuttle software requirements. In First Workshop on Formal Methods in Software Practice (FMSP '96), pages 40--48, San Diego, CA, January 1996. Association for Computing Machinery.
....[1, 36] They successfully verified and falsified several temporal properties. From an informal specification of a hydroelectric power plant, Pugliese and Tronci [50] developed a process algebra specification, which was then verified with an in house BDD based model checker. Crow and Di Vito [24] analyzed the requirements for a software subsystem on the Space Shuttle of NASA, using the explicit model checker Murj [26] to verify invariants. Since symbolic representations like BDDs were not used, they manually reduced the ranges of the environment inputs to control the size of the state ....
J. Crow and B. L. Di Vito. Formalizing space shuttle software requirements. In Proceedings of the ACM SIGSOFT Workshop on Formal Methods in Software Practice, pages 40--48, January 1996.
....into NASA space programs. The team consists of researchers and practitioners from Langley, Johnson Space Center, the Jet Propulsion Lab, Loral Space Information Systems, SRI, and V iGYAN. Portions of the Space Shuttle flight control requirements and change requests have formalized and analyzed [25, 18, 24, 17, 19]. At Langley, NASA researchers continued work on refining the fault tolerant architecture developed earlier by specifying lower levels of the hierarchy and formally proving they are implementations via refinement mappings [9, 10] Miner continued work on extending the SRI clock synchronization ....
....of formal specification has been observed in nearly all of our projects and agrees with experiences gained elsewhere. It should be remarked that specifications in PVS can be typechecked 3 and they usually are. The transition from reading to writing formal specifications can be difficult [17]; but there is no reason to believe this obstacle can not be overcome through training. Langley researchers recently gave a PVS training session for Loral requirements engineers that was well received. Miller reports [64] the Collins engineers had no difficulties in learning the PVS language. ....
Judith Crow and Ben L. Di Vito. Formalizing space shuttle software requirements. In Workshop on Formal Methods in Software Practice (FMSP '96), pages 40--48, San Diego, California, January 1996.
....or previous instant. These restrictions are important for getting confidence in the feasibility of the software requirements. The state machine model is in fact adopted by many approaches to software development, including recent work with PVS on the specification of the space shuttle software [22]. The state machine model is also widely used by formalisms such as B or VDM [23] 24] which incorporate software development methods. As a whole, the data flow specification of software requirements provides a solid basis for subsequent development. Type checking ensures completeness and ....
....unambiguous. We are also confident through the use of type checking and because of the definitional style adopted that the PVS specifications are consistent. In this respect, the SafeFM case study has confirmed other authors conclusions about the value of formal specifications (for example, see [22], 27] The existence of the VDM specification and the substantial experience of the GEC Marconi engineers with the system, meant that the PVS formalization was not likely to uncover previously unknown problems. The main benefits of the formal approach were realised during the later stages of ....
J. Crow and B. Di Vito, "Formalizing Space Shuttle Software Requirements," in ACM SIGSOFT Workshop on Formal Methods in Software Practice, January 1996.
....languages, deductive analysis using powerful theorem provers is often considered less attractive than the special purpose methods. In this paper we present experimental results showing that theorem proving can be applied effectively to requirements analysis. Previous technology insertion efforts [3,20] convinced us that problem domain experts can easily learn to read formal specifications, and with a little more effort, can learn to write them. Gaining theorem proving skills, however, takes a much larger training investment. For proverbased requirements analysis to enter common practice, high ....
Judith Crow and Ben Di Vito. Formalizing Space Shuttle software requirements: Four case studies. ACM Transactions on Software Engineering and Methodology, 7(3):296--332, July 1998.
No context found.
Judith Crow and Ben L. Di Vito. Formalizing Space Shuttle software requirements. In First Workshop on Formal Methods in Software Practice (FMSP '96), pages 40--48, San Diego, CA, January 1996. Association for Computing Machinery.
First 50 documents
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