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 37 records · Page 2

All sources NASA NTRS DOE OSTI

NASA NTRS1994

Experience report: Using formal methods for requirements analysis of critical spacecraft software

Formal specification and analysis of requirements continues to gain support as a method for producing more reliable software. However, the introduction of formal methods to a large software project is difficult, due in part to the unfamiliarity of the specification languages and the lack of graphics. This paper reports results of an investigation into the effectiveness of formal methods as an aid to the requirements analysis of critical, system-level fault-protection software on a spacecraft currently under development. Our experience indicates that formal specification and analysis can enhance the accuracy of the requirements and add assurance prior to design development in this domain. The work described here is part of a larger, NASA-funded research project whose purpose is to use formal-methods techniques to improve the quality of software in space applications. The demonstration project described here is part of the effort to evaluate experimentally the effectiveness of supplementing traditional engineering approaches to requirements specification with the more rigorous specification and analysis available with formal methods.

Lutz, Robyn R.↗

NASA NTRS2010

What is the Final Verification of Engineering Requirements?

This slide presentation reviews the process of development through the final verification of engineering requirements. The definition of the requirements is driven by basic needs, and should be reviewed by both the supplier and the customer. All involved need to agree upon a formal requirements including changes to the original requirements document. After the requirements have ben developed, the engineering team begins to design the system. The final design is reviewed by other organizations. The final operational system must satisfy the original requirements, though many verifications should be performed during the process. The verification methods that are used are test, inspection, analysis and demonstration. The plan for verification should be created once the system requirements are documented. The plan should include assurances that every requirement is formally verified, that the methods and the responsible organizations are specified, and that the plan is reviewed by all parties. The options of having the engineering team involved in all phases of the development as opposed to having some other organization continue the process once the design has been complete is discussed.

Poole, Eric↗

NASA NTRS1994

Experience Report: Using Formal Methods for Requirements Analysis of Critical Spacecraft Software

Formal↗

NASA NTRSDate not supplied

Verifying PLC Programs via Monitors: Extending the Integration of FRET and PLCverif

Verification of Programmable Logic Controller (PLC) programs requires reasoning about propositions qualified in terms of time. CERN’s PLCverif, an open-source tool for the analysis of safety-critical PLC systems, uses Linear Temporal Logic (LTL) for the specification of properties. Until now, PLCverif depended on third-party tools that accept LTL specifications to perform verification. However, our experience with industrial PLC programs shows that, to overcome analysis limitations, a wide range of techniques are needed to successfully verify complex properties. In this paper, we extend PLCverif to enable PLC program verification of pure-past LTL (PLTL) safety properties with assertion-based verification tools. To this end, we take an algorithm from the runtime-monitoring domain, apply it to bounded model checking of PLC programs, and implement it in PLCverif. We extend the integration of NASA’s Formal Requirements Elicitation Tool (FRET) into PLCverif to use PLTL properties generated with FRET. In addition, we leverage the program structure induced by the PLC scan-cycle for a state-space reduction. Finally, we expose the algorithm to a real-world case study of critical systems at CERN.

Formal verification↗

NASA NTRS2005

What Sensing Tells Us: Towards a Formal Theory of Testing for Dynamical Systems

Just as actions can have indirect effects on the state of the world, so too can sensing actions have indirect effects on an agent's state of knowledge. In this paper, we investigate "what sensing actions tell us", i.e., what an agent comes to know indirectly from the outcome of a sensing action, given knowledge of its actions and state constraints that hold in the world. To this end, we propose a formalization of the notion of testing within a dialect of the situation calculus that includes knowledge and sensing actions. Realizing this formalization requires addressing the ramification problem for sensing actions. We formalize simple tests as sensing actions. Complex tests are expressed in the logic programming language Golog. We examine what it means to perform a test, and how the outcome of a test affects an agent's state of knowledge. Finally, we propose automated reasoning techniques for test generation and complex-test verification, under certain restrictions. The work presented in this paper is relevant to a number of application domains including diagnostic problem solving, natural language understanding, plan recognition, and active vision.

McIlraith, Sheila↗

NASA NTRS1990

Space Station EVA System Evolution Study

Evaluation of Space Station Freedom support of manned exploration is in progress to identify SSF EVA system evolution requirements and capabilities. The output from these studies will provide data to support the preliminary design process to ensure that Space Station EVA system requirements for future missions (including the Transportation Node) are adequately considered and reflected. The study considers SSF support of future missions and the EVA system baseline to determine adequacy of EVA requirements and capabilities, and to identify additional requirements, capabilities, and necessary technology upgrades. EVA demands levied by formal requirements and indicated by evolution mission scenarios are high for the out-years of Space Station Freedom. An EVA system designed to meet the baseline requirements can easily evolve to meet evolution demands with few exceptions. Results to date indicate that upgrades or modifications to the EVA system may be necessary to meet all forseeable hangar induced EVA environments. Work continues to quantity the EVA capability in this regard. Evolution mission scenarios with EVA in and around unshielded nuclear propulsion engines are inconsistent with anthropomorphic EVA capabilities.

Rouen, Michael N.↗

NASA NTRS1990

Space Station Freedom extravehicular activity systems evolution study

Evaluation of Space Station Freedom (SSF) support of manned exploration is in progress to identify SSF extravehicular activity (EVA) system evolution requirements and capabilities. The output from these studies will provide data to support the preliminary design process to ensure that Space Station EVA system requirements for future missions (including the transportation node) are adequately considered and reflected in the baseline design. The study considers SSF support of future missions and the EVA system baseline to determine adequacy of EVA requirements and capabilities and to identify additional requirements, capabilities, and necessary technology upgrades. The EVA demands levied by formal requirements and indicated by evolutionary mission scenarios are high for the out-years of Space Station Freedom. An EVA system designed to meet the baseline requirements can easily evolve to meet evolution demands with few exceptions. Results to date indicate that upgrades or modifications to the EVA system may be necessary to meet the full range of EVA thermal environments associated with the transportation node. Work continues to quantify the EVA capability in this regard. Evolution mission scenarios with EVA and ground unshielded nuclear propulsion engines are inconsistent with anthropomorphic EVA capabilities.

Rouen, Michael↗

NASA NTRS1997

Experiences Using Lightweight Formal Methods for Requirements Modeling

This paper describes three case studies in the lightweight application of formal methods to requirements modeling for spacecraft fault protection systems. The case studies differ from previously reported applications of formal methods in that formal methods were applied very early in the requirements engineering process, to validate the evolving requirements. The results were fed back into the projects, to improve the informal specifications. For each case study, we describe what methods were applied, how they were applied, how much effort was involved, and what the findings were. In all three cases, formal methods enhanced the existing verification and validation processes, by testing key properties of the evolving requirements, and helping to identify weaknesses. We conclude that the benefits gained from early modeling of unstable requirements more than outweigh the effort needed to maintain multiple representations.

Easterbrook, Steve↗

NASA NTRS1996

Experiences Using Formal Methods for Requirements Modeling

This paper describes three cases studies in the lightweight application of formal methods to requirements modeling for spacecraft fault protection systems. The case studies differ from previously reported applications of formal methods in that formal methods were applied very early in the requirements engineering process, to validate the evolving requirements. The results were fed back into the projects, to improve the informal specifications. For each case study, we describe what methods were applied, how they were applied, how much effort was involved, and what the findings were. In all three cases, the formal modeling provided a cost effective enhancement of the existing verification and validation processes. We conclude that the benefits gained from early modeling of unstable requirements more than outweigh the effort needed to maintain multiple representations.

Easterbrook, Steve↗

NASA NTRS2022

Integrating FRET with Copilot: Automated Translation of Natural Language Requirements to Runtime Monitors

Runtime verification (RV) enables monitoring systems at runtime, to detect property violations early and limit their potential consequences. To provide the level of assurance required for ultra-critical systems, monitor specifications must faithfully reflect the original mission requirements, which are often written in ambiguous natural language. This paper presents an end-to-end framework to capture requirements in structured natural language and generate monitors that capture their semantics faithfully. We leverage NASA’s Formal Requirement Elicitation Tool (FRET), and the RV system Copilot. We extend FRET with mechanisms to capture additional information needed to generate monitors, and introduce OGMA, a new tool to bridge the gap between FRET and Copilot. With this framework, users can write requirements in an intuitive format and obtain real-time C monitors suitable for use in embedded systems. Our tool chain is available as open source.

FRET↗

NASA NTRS2009

Progress of the NASA/USGS Lunar Regolith Simulant Project

Beginning in 2004 personnel at MSFC began serious efforts to develop a new generation of lunar simulants. The first two products were a replication of the previous JSC-1 simulant under a contract to Orbitec and a major workshop in 2005 on future simulant development. Beginning in 2006 the project refocused its efforts and approached simulant development in a new and more comprehensive manner, examining new approaches in simulant development and ways to more accurately compare simulants to actual lunar materials. This led to a multi-year effort with five major tasks running in parallel. The five tasks are Requirements, Lunar Analysis, Process Development, Feed Stocks, and Standards. Major progress has been made in all five areas. A substantial draft of a formal requirements document now exists and has been largely stable since 2007. It does evolve as specific details of the standards and Lunar Analysis efforts proceed. Lunar Analysis has turned out to be vastly more difficult than anticipated. After great effort to mine existing published and gray literature, the team has realized the necessity of making new measurements of the Apollo samples, an effort that is currently in progress. Process development is substantially ahead of expectations in 2006. It is now practical to synthesize glasses of appropriate composition and purity. It is also possible to make agglutinate particles in significant quantities. A series of minerals commonly found on the Moon has been synthesized. Separation of mineral constituents from starting rock material is also proceeding. Customized grinding and mixing processes have been developed and tested are now being documented. Identification and development of appropriate feedstocks has been both easier and more difficult than anticipated. The Stillwater Mining Company, operating in the Stillwater layered mafic intrusive complex of Montana, has been an amazing resource for the project, but finding adequate sources for some of the components remains a difficult problem. For example the ratio of clino- to ortho-pyroxenes in the Stillwater is not an exact match for lunar materials. One of the sources being examined as an alternative pyroxene source is the Bushveld Complex in South Africa. Standards have been a major success for the project. The Figure of Merit algorithms have been created, tested, and are being considered for an ISO standard. Agreement has been reached in the community about how to make many of the critical measurements. There remains much work to do: (1) driving down the cost of simulants remains a major obstacle; (2) documentation and cost data analysis have not kept up with progress; (3) educating users in the complexity of the lunar regolith and the use of simulants remains a major task. In summary the project has made enormous progress and is successfully placing simulant development and use on a rigorous, scientifically defensible, engineering basis.

Rickman, Doug↗

NASA NTRS1996

Experiences Using Formal Methods for Requirements Modeling

This paper describes three case studies in the lightweight application of formal methods to requirements modeling for spacecraft fault protection systems.

spacecraft↗

NASA NTRS2010

Coverage Metrics for Requirements-Based Testing: Evaluation of Effectiveness

In black-box testing, the tester creates a set of tests to exercise a system under test without regard to the internal structure of the system. Generally, no objective metric is used to measure the adequacy of black-box tests. In recent work, we have proposed three requirements coverage metrics, allowing testers to objectively measure the adequacy of a black-box test suite with respect to a set of requirements formalized as Linear Temporal Logic (LTL) properties. In this report, we evaluate the effectiveness of these coverage metrics with respect to fault finding. Specifically, we conduct an empirical study to investigate two questions: (1) do test suites satisfying a requirements coverage metric provide better fault finding than randomly generated test suites of approximately the same size?, and (2) do test suites satisfying a more rigorous requirements coverage metric provide better fault finding than test suites satisfying a less rigorous requirements coverage metric? Our results indicate (1) only one coverage metric proposed -- Unique First Cause (UFC) coverage -- is sufficiently rigorous to ensure test suites satisfying the metric outperform randomly generated test suites of similar size and (2) that test suites satisfying more rigorous coverage metrics provide better fault finding than test suites satisfying less rigorous coverage metrics.

Staats, Matt↗

NASA NTRS2024

Moon to Mars (M2M) Cross Program Utilization Payload Safety Process

It is the goal of Moon to Mars (M2M) to establish a single consolidated set of safety requirements and a safety review process for utilization payloads that will cross program vehicle hatches or operate externally on multiple program vehicles during transport or operation that satisfies Exploration Ground Systems (EGS), Orion, EVA, and Human Surface Mobility Program (EHP), Gateway (GW), and Human Landing System (HLS) programs. This document defines the Cross Program Utilization Payload (xPUP) safety review process for mission effectivity of Artemis III and beyond. This review process will help ensure protection of the overall Moon to Mars integrated system from potential hazards created by cross program payloads that either cross a program vehicle hatch or can interface with more than one M2M lunar exploration program vehicle. The process will identify payload hazards and controls that will protect ground personnel, flight crew, the integrated vehicle, ground equipment, or facilities. This process is also applicable to samples that cross hatches between vehicles including for return to Earth. The xPUP safety review process will be led by one of the M2M programs' integration safety panels, chosen on a per-payload basis. After the lead integration safety panel is determined, the common safety process is established, based on pre-determined criteria, which includes ad-hoc members from other stakeholder programs. Stakeholder programs are those that interface with the utilization payload in any way (e.g., operating on a lunar exploration vehicle or crossing program vehicle hatches). The xPUP will execute this safety review process for flight and ground utilization payload hardware design, its ground support equipment, and landing and recovery in accordance with the applicable safety requirements as specified in M2M-30043: Moon to Mars Cross Program Utilization Payload Safety Requirements. The xPUP safety process will follow the lead integration safety panel’s safety process requirements. Formal agreements will be communicated with the payload developer using the payload integration processes documented in M2M-30037, Artemis Payload Integration Implementation Plan.

payloads↗

NASA NTRS2021

Compositional Realizability Checking within FRET

A set of requirements for a reactive system is realizable if, for any sequence of inputs that satisfy the assumptions on the environment, the guarantees always hold. Realizability checking is essential to ensure that an implementation can be constructed that satisfies the requirements. We propose a framework that supports users in the non-trivial task of developing realizable requirements. Our framework uses architectural information to automatically de-compose a set of requirements into subsets that can be analyzed separately, and therefore more efficiently. It then integrates existing algorithms in order to detect unrealizability, identify minimal sets of conflicting requirements, and compute counterexamples. The capability to focus on minimal conflict sets is key for localizing and correcting the sources of unrealizability. Our approach supports this process by enabling users to interactively visualize and explore the produced conflict sets and counterexamples. We have implemented our framework in the open-source Formal Requirements Elicitation Tool (FRET), and have used it on a variety of industrial-level case studies, showcasing the strengths of our approach in terms of raw performance, as well as diagnostic potential.

FRET↗

NASA NTRS1982

The inverse problem of constructing a gravimetric geoid

Computation of a single geoidal height from gravity acceleration data formally requires that the latter be known everywhere on the earth. A computational procedure based on linear inverse theory for estimating geoidal heights from incomplete sets of data is presented. The same scheme can be used to estimate gravity accelerations from altimetry-derived geoids. The systematic error owing to lack of data and the choice of a particular inverse operator is described by using resolution functions and their spherical harmonic expansions. An rms value of this error is also estimated by assuming a spectrum for the unknown geoid. The influence of the size of the data region, the spacing between data, the filtering applied to the data, and the model weighting function chosen are all quantified in a spherical geometry. The examples presented show that when low degree spherical harmonic coefficients are available - from satellite orbit analysis - a band-passed version of the geoid can be constructed from local gravity data, even with a relatively restricted data set.

Zlotnicki, V.↗

NASA NTRS2000

Session on High Speed Civil Transport Design Capability Using MDO and High Performance Computing

Since the inception of CAS in 1992, NASA Langley has been conducting research into applying multidisciplinary optimization (MDO) and high performance computing toward reducing aircraft design cycle time. The focus of this research has been the development of a series of computational frameworks and associated applications that increased in capability, complexity, and performance over time. The culmination of this effort is an automated high-fidelity analysis capability for a high speed civil transport (HSCT) vehicle installed on a network of heterogeneous computers with a computational framework built using Common Object Request Broker Architecture (CORBA) and Java. The main focus of the research in the early years was the development of the Framework for Interdisciplinary Design Optimization (FIDO) and associated HSCT applications. While the FIDO effort was eventually halted, work continued on HSCT applications of ever increasing complexity. The current application, HSCT4.0, employs high fidelity CFD and FEM analysis codes. For each analysis cycle, the vehicle geometry and computational grids are updated using new values for design variables. Processes for aeroelastic trim, loads convergence, displacement transfer, stress and buckling, and performance have been developed. In all, a total of 70 processes are integrated in the analysis framework. Many of the key processes include automatic differentiation capabilities to provide sensitivity information that can be used in optimization. A software engineering process was developed to manage this large project. Defining the interactions among 70 processes turned out to be an enormous, but essential, task. A formal requirements document was prepared that defined data flow among processes and subprocesses. A design document was then developed that translated the requirements into actual software design. A validation program was defined and implemented to ensure that codes integrated into the framework produced the same results as their standalone counterparts. Finally, a Commercial Off the Shelf (COTS) configuration management system was used to organize the software development. A computational environment, CJOPT, based on the Common Object Request Broker Architecture, CORBA, and the Java programming language has been developed as a framework for multidisciplinary analysis and Optimization. The environment exploits the parallelisms inherent in the application and distributes the constituent disciplines on machines best suited to their needs. In CJOpt, a discipline code is "wrapped" as an object. An interface to the object identifies the functionality (services) provided by the discipline, defined in Interface Definition Language (IDL) and implemented using Java. The results of using the HSCT4.0 capability are described. A summary of lessons learned is also presented. The use of some of the processes, codes, and techniques by industry are highlighted. The application of the methodology developed in this research to other aircraft are described. Finally, we show how the experience gained is being applied to entirely new vehicles, such as the Reusable Space Transportation System. Additional information is contained in the original.

Rehder, Joe↗

NASA NTRS2010

Figure of Merit Characteristics Compared to Engineering Parameters

A workshop held in 2005 defined a large number of parameters of interest for users of lunar simulants. The need for formal requirements and standards in the manufacture and use of simulants necessitates certain features of measurements. They must be definable, measureable, useful, and primary rather than derived. There are also certain features that must be avoided. Analysis of the total parameter list led to the realization that almost all of the parameters could be tightly constrained, though not predicted, if only four properties were measured: Particle composition, particle size distribution, particle shape distribution, and bulk density. These four are collectively referred to as figures of merit (FoMs). An evaluation of how each of the parameters identified in 2005 is controlled by the four FoMs is given.

Rickman, D.L.↗