SEARCH · Search NASA

Results for “requirement formalization”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRS2012

Architecting the Human Space Flight Program with Systems Modeling Language (SysML)

The next generation of missions in NASA's Human Space Flight program focuses on the development and deployment of highly complex systems (e.g., Orion Multi-Purpose Crew Vehicle, Space Launch System, 21st Century Ground System) that will enable astronauts to venture beyond low Earth orbit and explore the moon, near-Earth asteroids, and beyond. Architecting these highly complex system-of-systems requires formal systems engineering techniques for managing the evolution of the technical features in the information exchange domain (e.g., data exchanges, communication networks, ground software) and also, formal correlation of the technical architecture to stakeholders' programmatic concerns (e.g., budget, schedule, risk) and design development (e.g., assumptions, constraints, trades, tracking of unknowns). This paper will describe how the authors have applied System Modeling Language (SysML) to implement model-based systems engineering for managing the description of the End-to-End Information System (EEIS) architecture and associated development activities and ultimately enables stakeholders to understand, reason, and answer questions about the EEIS under design for proposed lunar Exploration Missions 1 and 2 (EM-1 and EM-2).

scheduling↗

NASA NTRS2017

UTM UAS Service Supplier Specification

Within the Unmanned Aircraft Systems (UAS) Traffic Management (UTM) system, the UAS Service Supplier (USS) is a key component. The USS serves several functions. At a high level, those include the following: Bridging communication between UAS Operators and Flight Information Management System (FIMS) Supporting planning of UAS operations Assisting strategic deconfliction of the UTM airspace Providing information support to UAS Operators during operations Helping UAS Operators meet their formal requirements This document provides the minimum set of requirements for a USS. In order to be recognized as a USS within UTM, successful demonstration of satisfying the requirements described herein will be a prerequisite. To ensure various desired qualities (security, fairness, availability, efficiency, maintainability, etc.), this specification relies on references to existing public specifications whenever possible.

UTM↗

NASA NTRS2019

Integrating Realizability Checking in FRET

Realizability (alternatively referred to as relative consistency or implementability) - checking whether a specification can be implemented by an open system - has been the subject of extensive study. Realizability can be viewed as a stronger analysis method when compared to consistency checking in that it does not only check whether the system works in some environment, but instead whether the system works in all environments. In this report, we experiment and build on the approach presented by Gacek et al. that supports checking realizability of contracts involving infinite theories using SMT solvers. In particular, we 1) extend the Formal Requirements Elicitation Tool (FRET) to support generation of Lustre contracts that can be checked for realizability with the JKind k-induction and fix point generation engines; 2) study a compositional way for checking realizability based on the notion of connected components; and 3) test our approach and the capabilities of the JKind realizability engines on a large subset of the Lockheed Martin Cyber Physical System Challenge Problems.

Kooi, David↗

NASA NTRS2019

UAS Service Supplier Specification

Rios, Joseph L.↗

NASA NTRS1997

Reuse of a Formal Model for Requirements Validation

This paper report experience from how a project engaged in the process of requirements analysis for evolutionary builds can reuse the formally specified design model produced for a similar, earlier project in the same domain.

requirements↗

NASA NTRS1996

Formalizing New Navigation Requirements for NASA's Space Shuttle

We describe a recent NASA-sponsored pilot project intended to gauge the effectiveness of using formal methods in Space Shuttle software requirements analysis. Several Change Requests (CRs) were selected as promising targets to demonstrate the utility of formal methods in this demanding application domain. A CR to add new navigation capabilities to the Shuttle, based on Global Positioning System (GPS) technology, is the focus of this industrial usage report. Portions of the GPS CR were modeled using the language of SRI's Prototype Verification System (PVS). During a limited analysis conducted on the formal specifications, numerous requirements issues were discovered. We present a summary of these encouraging results and conclusions we have drawn from the pilot project.

DiVito, Ben L.↗

NASA NTRS1997

Reuse of a Formal Model for Requirements Validation

This paper reports experience from how a project engaged in the process of requirements analysis for evolutionary builds can reuse the formally specified design model produced for a similar, earlier project in the same domain. Two levels of reuse are described here. First, a formally specified generic design model was generated on one project to systematically capture the design commonality in a set of software monitors on board a spacecraft. These monitors periodically check for faults and invoke recovery software when needed. The paper summarizes the use of the design model to validate the software design of the various monitors on that first project. Secondly, the paper describes how the formal design model created for the first project was reused on a second, subsequent project. The model was reused to validate the evolutionary requirements for the second project's software monitors, which were being developed in a series of builds. Some mismatches due to the very different architectures on the two projects suggested changes to make the model more generic. In addition, several advantages to the reuse of the first project's formal model on the second project are reported.

Lutz, Robyn R.↗

NASA NTRS1993

Towards the formal specification of the requirements and design of a processor interface unit

Work to formally specify the requirements and design of a Processor Interface Unit (PIU), a single-chip subsystem providing memory interface, bus interface, and additional support services for a commercial microprocessor within a fault-tolerant computer system, is described. This system, the Fault-Tolerant Embedded Processor (FTEP), is targeted towards applications in avionics and space requiring extremely high levels of mission reliability, extended maintenance free operation, or both. The approaches that were developed for modeling the PIU requirements and for composition of the PIU subcomponents at high levels of abstraction are described. These approaches were used to specify and verify a nontrivial subset of the PIU behavior. The PIU specification in Higher Order Logic (HOL) is documented in a companion NASA contractor report entitled 'Towards the Formal Specification of the Requirements and Design of a Processor Interfacs Unit - HOL Listings.' The subsequent verification approach and HOL listings are documented in NASA contractor report entitled 'Towards the Formal Verification of the Requirements and Design of a Processor Interface Unit' and NASA contractor report entitled 'Towards the Formal Verification of the Requirements and Design of a Processor Interface Unit - HOL Listings.'

Fura, David A.↗

NASA NTRS2001

Fast Formal Analysis of Requirements via "Topoi Diagrams"

Early testing of requirements can decrease the cost of removing errors in software projects. However, unless done carefully, that testing process can significantly add to the cost of requirements analysis. We show here that requirements expressed as topoi diagrams can be built and tested cheaply using our SP2 algorithm, the formal temporal properties of a large class of topoi can be proven very quickly, in time nearly linear in the number of nodes and edges in the diagram. There are two limitations to our approach. Firstly, topoi diagrams cannot express certain complex concepts such as iteration and sub-routine calls. Hence, our approach is more useful for requirements engineering than for traditional model checking domains. Secondly, out approach is better for exploring the temporal occurrence of properties than the temporal ordering of properties. Within these restrictions, we can express a useful range of concepts currently seen in requirements engineering, and a wide range of interesting temporal properties.

Menzies, Tim↗

NASA NTRS1993

Towards the formal verification of the requirements and design of a processor interface unit

The formal verification of the design and partial requirements for a Processor Interface Unit (PIU) using the Higher Order Logic (HOL) theorem-proving system is described. The processor interface unit is a single-chip subsystem within a fault-tolerant embedded system under development within the Boeing Defense and Space Group. It provides the opportunity to investigate the specification and verification of a real-world subsystem within a commercially-developed fault-tolerant computer. An overview of the PIU verification effort is given. The actual HOL listing from the verification effort are documented in a companion NASA contractor report entitled 'Towards the Formal Verification of the Requirements and Design of a Processor Interface Unit - HOL Listings' including the general-purpose HOL theories and definitions that support the PIU verification as well as tactics used in the proofs.

Fura, David A.↗

NASA NTRS1976

NASA software specification and evaluation system design, part 1

The research to develop methods for reducing the effort expended in software and verification is reported. The development of a formal software requirements methodology, a formal specifications language, a programming language, a language preprocessor, and code analysis tools are discussed.

Source record↗

NASA NTRSDate not supplied

Dynamic Assurance of Autonomous Systems Through Ground Control Software

Assurance cases have emerged as a way to build trust in complex autonomous systems. Many assurance case justifications for such systems need to be constantly reevaluated based on the current system context and performance. Autonomous systems, especially those deployed in remote environments, often have a ground control system that enables monitoring and remote operations. In this paper, we propose a dynamic assurance framework that aims at connecting the assurance case with the ground control system. We use the ground control system to facilitate dynamic evaluation of quantitative assurance measures that support various justifications in the assurance case. We demonstrate the proposed dynamic assurance framework on the NASA Ames Research Center project Troupe. We use a combination of in-house and external tools to identify the assurance measures, formalize the related requirements, and generate monitors that feed the data to the external ground control system.

dynamic assurance case↗

NASA NTRS1994

The detailed balance requirement and general empirical formalisms for continuum absorption

Two general empirical formalisms are presented for the spectral density which take into account the deviations from the Lorentz line shape in the wing regions of resonance lines. These formalisms satisfy the detailed balance requirement. Empirical line shape functions, which are essential to provide the continuum absorption at different temperatures in various frequency regions for atmospheric transmission codes, can be obtained by fitting to experimental data.

Ma, Q.↗

NASA NTRS1996

Formalizing Space Shuttle Software Requirements

This paper describes two case studies in which requirements for new flight-software subsystems on NASA's Space Shuttle were analyzed, one using standard formal specification techniques, the other using state exploration. These applications serve to illustrate three main theses: (1) formal methods can complement conventional requirements analysis processes effectively, (2) formal methods confer benefits regardless of how extensively they are adopted and applied, and (3) formal methods are most effective when they are judiciously tailored to the application.

Crow, Judith↗

NASA NTRS2012

Automating the Generation of Heterogeneous Aviation Safety Cases

A safety case is a structured argument, supported by a body of evidence, which provides a convincing and valid justification that a system is acceptably safe for a given application in a given operating environment. This report describes the development of a fragment of a preliminary safety case for the Swift Unmanned Aircraft System. The construction of the safety case fragment consists of two parts: a manually constructed system-level case, and an automatically constructed lower-level case, generated from formal proof of safety-relevant correctness properties. We provide a detailed discussion of the safety considerations for the target system, emphasizing the heterogeneity of sources of safety-relevant information, and use a hazard analysis to derive safety requirements, including formal requirements. We evaluate the safety case using three classes of metrics for measuring degrees of coverage, automation, and understandability. We then present our preliminary conclusions and make suggestions for future work.

Denney, Ewen W.↗

NASA NTRS2020

Buckling of Thin-Walled Circular Cylinders

Recent industry and NASA experience with the development of launch vehicle structures have indicated a need for updated monographs for the design of buckling-critical structures that account for state-of-the-art structural configurations, material systems, and computational tools. This monograph provides an update to NASA SP-8007 (circa 1965, and 1968) and was prepared under the cognizance of the NASA Engineering and Safety Center (NESC). It summarizes all significant knowledge and experience accumulated from the NESC Shell Buckling Knockdown Factor (SBKF) Assessment (NESC Assessment #: 07-010-E) to date for use in the design of buckling-critical thin-walled circular cylinders. The format and terminology used in this monograph is similar to previous versions of NASA SP-8007 for ease of understanding and implementation. In addition, as with the design recommendations contained in the previous versions of NASA SP-8007, this monograph is to be regarded as a guideline to design and not as a NASA requirement, unless specified in formal program requirements. Furthermore, it is expected that the guidelines presented in this monograph will be updated as appropriate. Designers are advised to stay abreast of updates in the state-of-the-art and corresponding design criteria.

Buckling↗

NASA NTRS2005

A Formal Approach to Requirements-Based Programming

No significant general-purpose method is currently available to mechanically transform system requirements into a provably equivalent model. The widespread use of such a method represents a necessary step toward high-dependability system engineering for numerous application domains. Current tools and methods that start with a formal model of a system and mechanically produce a provably equivalent implementation are valuable but not sufficient. The "gap" unfilled by such tools and methods is that the formal models cannot be proven to be equivalent to the requirements. We offer a method for mechanically transforming requirements into a provably equivalent formal model that can be used as the basis for code generation and other transformations. This method is unique in offering full mathematical tractability while using notations and techniques that are well known and well trusted. Finally, we describe further application areas we are investigating for use of the approach.

Hinchey, Michael G.↗

NASA NTRS2008

From Informal Safety-Critical Requirements to Property-Driven Formal Validation

Most of the efforts in formal methods have historically been devoted to comparing a design against a set of requirements. The validation of the requirements themselves, however, has often been disregarded, and it can be considered a largely open problem, which poses several challenges. The first challenge is given by the fact that requirements are often written in natural language, and may thus contain a high degree of ambiguity. Despite the progresses in Natural Language Processing techniques, the task of understanding a set of requirements cannot be automatized, and must be carried out by domain experts, who are typically not familiar with formal languages. Furthermore, in order to retain a direct connection with the informal requirements, the formalization cannot follow standard model-based approaches. The second challenge lies in the formal validation of requirements. On one hand, it is not even clear which are the correctness criteria or the high-level properties that the requirements must fulfill. On the other hand, the expressivity of the language used in the formalization may go beyond the theoretical and/or practical capacity of state-of-the-art formal verification. In order to solve these issues, we propose a new methodology that comprises of a chain of steps, each supported by a specific tool. The main steps are the following. First, the informal requirements are split into basic fragments, which are classified into categories, and dependency and generalization relationships among them are identified. Second, the fragments are modeled using a visual language such as UML. The UML diagrams are both syntactically restricted (in order to guarantee a formal semantics), and enriched with a highly controlled natural language (to allow for modeling static and temporal constraints). Third, an automatic formal analysis phase iterates over the modeled requirements, by combining several, complementary techniques: checking consistency; verifying whether the requirements entail some desirable properties; verify whether the requirements are consistent with selected scenarios; diagnosing inconsistencies by identifying inconsistent cores; identifying vacuous requirements; constructing multiple explanations by enabling the fault-tree analysis related to particular fault models; verifying whether the specification is realizable.

Cimatti, Alessandro↗