Search NASA⌕ Search

SEARCH · Search NASA

Results for “software verification”

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.

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

At least 451 records · Page 25

Rapid development of the X-31 simulation to support flight-testing

The X-31 Enhanced Fighter Maneuverability Program has been recognized to form the International Test Organization, with the NASA Dryden Flight Research Facility (NASA-Dryden) as the responsible test organization. The two X-31 research aircraft and engineering support personnel were colocated at NASA-Dryden, with flight test operations beginning in Apr. 1992. Therefore, rapid development of a hardware-in-the-loop simulation was needed to support the flight test operations at NASA-Dryden, and to perform verification and validation of flight control software. The X-31 simulation system requirements, distributed simulation system architecture, simulation components math models to the visual system, and the advanced capabilities the X-31 simulation provides. In addition, unique software tools and the methods used to rapidly develop this simulation system will be highlighted.

Mackall, Dale↗

Rapid development of the X-31 simulation to support flight-testing

The X-31 Enhanced Fighter Maneuverability Program has been recognized to form the International Test Organization, with the NASA Dryden Flight Research Facility (NASA-Dryden) as the responsible test organization. The two X-31 research aircraft and engineering support personnel were colocated at NASA-Dryden, with flight test operations beginning in Apr. 1992. Therefore, rapid development of a hardware-in-the-loop simulation was needed to support the flight test operations at NASA-Dryden, and to perform verification and validation of flight control software. The X-31 simulation system requirements, distributed simulation system architecture, simulation components math models to the visual system, and the advanced capabilities the X-31 simulation provides. In addition, unique software tools and the methods used to rapidly develop this simulation system will be highlighted.

Mackall, Dale↗

Software analysis handbook: Software complexity analysis and software reliability estimation and prediction

This handbook documents the three software analysis processes the Space Station Software Analysis team uses to assess space station software, including their backgrounds, theories, tools, and analysis procedures. Potential applications of these analysis results are also presented. The first section describes how software complexity analysis provides quantitative information on code, such as code structure and risk areas, throughout the software life cycle. Software complexity analysis allows an analyst to understand the software structure, identify critical software components, assess risk areas within a software system, identify testing deficiencies, and recommend program improvements. Performing this type of analysis during the early design phases of software development can positively affect the process, and may prevent later, much larger, difficulties. The second section describes how software reliability estimation and prediction analysis, or software reliability, provides a quantitative means to measure the probability of failure-free operation of a computer program, and describes the two tools used by JSC to determine failure rates and design tradeoffs between reliability, costs, performance, and schedule.

Computer systems design↗

Formal Methods of V&V of Partial Specifications: An Experience Report

This paper describes our work exploring the suitability of formal specification methods for independent verification and validation (IV&V) of software specifications for large, safety critical systems. An IV&V contractor often has to perform rapid analysis on incomplete specifications, with no control over how those specifications are represented. Lightweight formal methods show significant promise in this context, as they offer a way of uncovering major errors, without the burden of full proofs of correctness. We describe an experiment in the application of the method SCR. to testing for consistency properties of a partial model of requirements for Fault Detection Isolation and Recovery on the space station. We conclude that the insights gained from formalizing a specification is valuable, and it is the process of formalization, rather than the end product that is important. It was only necessary to build enough of the formal model to test the properties in which we were interested. Maintenance of fidelity between multiple representations of the same requirements (as they evolve) is still a problem, and deserves further study.

Easterbrook, Steve↗

Formal Methods for Verification and Validation of Partial Specifications: A Case Study

This paper describes our work exploring the suitability of formal specification methods for independent verification and validation (IV&V) of software specifications for large, safety critical systems. An IV&V contractor often has to perform rapid analysis on incomplete specifications, with no control over how those specifications are represented. Lightweight formal methods show significant promise in this context, as they offer a way of uncovering major errors, without the burden of full proofs of correctness. We describe a case study of the use of partial formal models for V&V of the requirements for Fault Detection Isolation and Recovery on the space station. We conclude that the insights gained from formalizing a specification are valuable, and it is the process of formalization, rather than the end product that is important. It was only necessary to build enough of the formal model to test the properties in which we were interested. Maintenance of fidelity between multiple representations of the same requirements (as they evolve) is still a problem, and deserves further study.

Easterbrook, Steve↗

Flight Guidance System Validation Using SPIN

To verify the requirements for the mode control logic of a Flight Guidance System (FGS) we applied SPIN, a widely used software package that supports the formal verification of distributed systems. These requirements, collectively called the FGS specification, were developed at Rockwell Avionics & Communications and expressed in terms of the Consortium Requirements Engineering (CoRE) method. The properties to be verified are the invariants formulated in the FGS specification, along with the standard properties of consistency and completeness. The project had two stages. First, the FGS specification and the properties to be verified were reformulated in PROMELA, the input language of SPIN. This involved a semantics issue, as some constructs of the FGS specification do not have well-defined semantics in CoRE. Then we attempted to verify the requirements' properties using the automatic model checking facilities of SPIN. Due to the large size of the state space of the FGS specification an exhaustive state space analysis with SPIN turned out to be impossible. So we used the supertrace model checking procedure of SPIN that provides for a partial analysis of the state space. During this process, we found some subtle errors in the FGS specification.

Naydich, Dimitri↗

RIACS Workshop on the Verification and Validation of Autonomous and Adaptive Systems

The long-term future of space exploration at NASA is dependent on the full exploitation of autonomous and adaptive systems: careful monitoring of missions from earth, as is the norm now, will be infeasible due to the sheer number of proposed missions and the communication lag for deep-space missions. Mission managers are however worried about the reliability of these more intelligent systems. The main focus of the workshop was to address these worries and hence we invited NASA engineers working on autonomous and adaptive systems and researchers interested in the verification and validation (V&V) of software systems. The dual purpose of the meeting was to: (1) make NASA engineers aware of the V&V techniques they could be using; and (2) make the V&V community aware of the complexity of the systems NASA is developing.

Pecheur, Charles↗

Space Computing Systems Validation Challenges

To examine the challenges of spaceborne computing systems and the past, present and future approaches to verification and validation in hardware and software systems.

Commercial Orbital Transportation Services (COTS)↗

Human Factors Engineering Requirements for the International Space Station - Successes and Challenges

Advanced technology coupled with the desire to explore space has resulted in increasingly longer human space missions. Indeed, any exploration mission outside of Earth's neighborhood, in other words, beyond the moon, will necessarily be several months or even years. The International Space Station (ISS) serves as an important advancement toward executing a successful human space mission that is longer than a standard trip around the world or to the moon. The ISS, which is a permanently occupied microgravity research facility orbiting the earth, will support missions four to six months in duration. In planning for the ISS, the NASA developed an agency-wide set of human factors standards for the first time in a space exploration program. The Man-Systems Integration Standard (MSIS), NASA-STD-3000, a multi-volume set of guidelines for human-centered design in microgravity, was developed with the cooperation of human factors experts from various NASA centers, industry, academia, and other government agencies. The ISS program formed a human factors team analogous to any major engineering subsystem. This team develops and maintains the human factors requirements regarding end-to-end architecture design and performance, hardware and software design requirements, and test and verification requirements. It is also responsible for providing program integration across all of the larger scale elements, smaller scale hardware, and international partners.

Whitmore, M.↗

Mending the Gap, An Effort to Aid the Transfer of Formal Methods Technology

Formal methods can be applied to many of the development and verification activities required for civil avionics software. RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, gives a brief description of using formal methods as an alternate method of compliance with the objectives of that standard. Despite this, the avionics industry at large has been hesitant to adopt formal methods, with few developers have actually used formal methods for certification credit. Why is this so, given the volume of evidence of the benefits of formal methods? This presentation will explore some of the challenges to using formal methods in a certification context and describe the effort by the Formal Methods Subgroup of RTCA SC-205/EUROCAE WG-71 to develop guidance to make the use of formal methods a recognized approach.

Hayhurst, Kelly↗

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con-trol its next near term behavior. We present a high-level view of the automated flight rule checker FRC for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there-fore be verified with a trace analysis tool. FRC is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con-text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

LADEE↗

Importance of Requirements Analysis & Traceability to Improve Software Quality and Reduce Cost and Risk

The goal of this paper is to emphasize the importance of developing complete and unambiguous requirements early in the project cycle (prior to Preliminary Design Phase). Having a complete set of requirements early in the project cycle allows sufficient time to generate a traceability matrix. Requirements traceability and analysis are the key elements in improving verification and validation process, and thus overall software quality. Traceability can be most beneficial when the system changes. If changes are made to high-level requirements it implies that low-level requirements need to be modified. Traceability ensures that requirements are appropriately and efficiently verified at various levels whereas analysis ensures that a rightly interpreted set of requirements is produced.

Kapoor, Manju M.↗

A survey of program slicing for software engineering

This research concerns program slicing which is used as a tool for program maintainence of software systems. Program slicing decreases the level of effort required to understand and maintain complex software systems. It was first designed as a debugging aid, but it has since been generalized into various tools and extended to include program comprehension, module cohesion estimation, requirements verification, dead code elimination, and maintainence of several software systems, including reverse engineering, parallelization, portability, and reuse component generation. This paper seeks to address and define terminology, theoretical concepts, program representation, different program graphs, developments in static slicing, dynamic slicing, and semantics and mathematical models. Applications for conventional slicing are presented, along with a prognosis of future work in this field.

Beck, Jon↗

Development and Testing of Automatically Generated ACS Flight Software for the MAP Spacecraft

By integrating the attitude determination and control system (ACS) analysis and design, flight software development, and flight software testing processes, it is possible to improve the overall spacecraft development cycle, as well as allow for more thorough software testing. One of the ways to achieve this integration is to use code-generation tools to automatically generate components of the ACS flight software directly from a high-fidelity (HiFi) simulation. In the development of the Microwave Anisotropy Probe (MAP) spacecraft, currently underway at the NASA Goddard Space Flight Center, approximately 1/3 of the ACS flight software was automatically generated. In this paper, we will examine each phase of the ACS subsystem and flight software design life cycle: analysis, design, and testing. In the analysis phase, we scoped how much software we would automatically generate and created the initial interface. The design phase included parallel development of the HiFi simulation and the hand-coded flight software components. Everything came together in the test phase, in which the flight software was tested, using results from the HiFi simulation as one of the bases of comparison for testing. Because parts of the spacecraft HiFi simulation were converted into flight software, more care needed to be put into its development and configuration control to support both the HiFi simulation and flight software. The components of the HiFi simulation from which code was generated needed to be designed based on the fact that they would become flight software. This process involved such considerations as protecting against mathematical exceptions, using acceptable module and parameter naming conventions, and using an input/output interface compatible with the rest of the flight software. Maintaining good configuration control was an issue for the HiFi simulation and the flight software, and a way to track the two systems was devised. Finally, an integrated test approach was devised to support flight software testing at both the unit- and build-test levels using the HiFi simulation to generate data for performance verification. Another benefit of the simulation and code-generation application used on the MAP project is that it supported bringing flight software and test data into the HiFi simulation environment. It was possible to integrate parts of the hand-coded flight software into the HiFi simulation, and also possible to import flight software test data for comparison and performance verification. This capability was used to incorporate the flight software Kalman filter into the HiFi simulation. This enabled us to greatly increase the amount of testing that could be done on the filter, because we could exert a greater degree of control over the software-only simulation than over the flight software test environment. Also, since the simulation could be used to run the Kalman filter faster than real time, our testing efficiency was greatly increased. We will conclude our discussion with a summary of the lessons learned thus far using automatically- generated code for the MAP project, and the spacecraft status as we work towards our scheduled launch in the year 2000.

ODonnell, James R., Jr.↗

Simulator verification techniques study. Integrated simulator self test system concepts

Software and hardware requirements for implementing hardware self tests are presented in support of the development of training and procedures development simulators for the space shuttle program. Self test techniques for simulation hardware and the validation of simulation performance are stipulated. The requirements of an integrated simulator self system are analyzed. Readiness tests, fault isolation tests, and incipient fault detection tests are covered.

Montoya, G.↗

The Role of Independent V&V in Upstream Software Development Processes

This paper describes the role of Verification and Validation (V&V) during the requirements and high level design processes, and in particular the role of Independent V&V (IV&V). The job of IV&V during these phases is to ensure that the requirements are complete, consistent and valid, and to ensure that the high level design meets the requirements. This contrasts with the role of Quality Assurance (QA), which ensures that appropriate standards and process models are defined and applied. This paper describes the current state of practice for IV&V, concentrating on the process model used in NASA projects. We describe a case study, showing the processes by which problem reporting and tracking takes place, and how IV&V feeds into decision making by the development team. We then describe the problems faced in implementing IV&V. We conclude that despite a well defined process model, and tools to support it, IV&V is still beset by communication and coordination problems.

Easterbrook, Steve↗