Engineering Papers⌕ Search

NASA NTRS · 20140009161

Helping System Engineers Bridge the Peaks

Abstract

In our experience at NASA, system engineers generally follow the Twin Peaks approach when developing safety-critical systems. However, iterations between the peaks require considerable manual, and in some cases duplicate, effort. A significant part of the manual effort stems from the fact that requirements are written in English natural language rather than a formal notation. In this work, we propose an approach that enables system engineers to leverage formal requirements and automated test generation to streamline iterations, effectively "bridging the peaks". The key to the approach is a formal language notation that a) system engineers are comfortable with, b) is supported by a family of automated V&V tools, and c) is semantically rich enough to describe the requirements of interest. We believe the combination of formalizing requirements and providing tool support to automate the iterations will lead to a more efficient Twin Peaks implementation at NASA.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Rungta, Neha, Tkachuk, Oksana, Person, Suzette, Biatek, Jason, Whalen, Michael W., Castle, Joseph, Castle, JosephGundy-Burlet, Karen. 2014-06-01. Helping System Engineers Bridge the Peaks. https://ntrs.nasa.gov/citations/20140009161

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related reports

Landsat Instrument Suite (LandIS) Sensor Design for the Landsat 10 Mission

Landsat 10 will be the upcoming mission in the 50+ year Landsat series of Earth observation platforms. The centerpiece of the observatory will be a super-spectral imager known as the Landsat Instrument Suite (LandIS). The sensor will feature 26 spectral channels from the visible through near-, short-wave, and thermal infrared wavelengths with spatial resolutions of 10, 20, and 60 meters on the ground, depending on the band. These enhancements over the legacy Landsat instruments will ensure data continuity with the existing archive and will expand upon the core Landsat capabilities to enable new applications in Earth science. After a competitive procurement, NASA selected the design submitted by the Raytheon Company for the LandIS instrument. The innovative Raytheon instrument concept utilizes an advanced whiskbroom architecture to fulfill the strict radiometric, spatial, and geometric image quality requirements demanded by the Landsat 10 mission and fits within restrictive mass, volume, and power constraints. The instrument will continue the Landsat directive to image all daylit land and near-shore water areas, along with select nighttime imaging. On-board calibration source data will ensure high radiometric and geometric accuracy and stability consistent with previous missions to enable continuity in data products available to users. This paper discusses the driving requirements for LandIS and provides a description of the chosen design and operations concept of the instrument.

Requirements↗

Wildfire-fighting Use Case Requirements to Monitor

In this technical report, we provide requirements for a wildfire-fighting use-case, towards the Safety Demonstrator 1. The use case will incorporate ground and airborne assets operating in a coordinated fashion, and will comprise five activities, from detection to the execution of the initial attack. Depending on the activity and the data involved, the requirements identified may be non-probabilistic or probabilistic. In both cases, we first identify some of the requirements we wish to monitor, and then present a formalization using the language of requirements of the NASA requirements elicitation tool FRET. To formalize probabilistic requirements, we use a novel extension to FRET’s requirements language that incorporates notions of probability, and discuss how requirements can be translated into existing probabilistic temporal logics like PCTL. We exemplify how some of the requirements presented can be monitored using the existing tools Ogma and Copilot. We close with a summary and future directions.

Requirements↗

Integrating Safety and Mission Assurance into Systems Engineering Modeling Practices

During the early development of products, flight, or experimental hardware, emphasis is often given to the identification of technical requirements, utilizing such tools as use case and activity diagrams. Designers and project teams focus on understanding physical and performance demands and challenges. It is typically only later, during the evaluation of preliminary designs that a first pass, if performed, is made to determine the process, safety, and mission quality assurance requirements. Evaluation early in the life cycle, though, can yield requirements that force a fundamental change in design. This paper discusses an alternate paradigm for using the concepts of use case or activity diagrams to identify safety hazard and mission quality assurance risks and concerns using the same systems engineering modeling tools being used to identify technical requirements. It contains two examples of how this process might be used in the development of a space flight experiment, and the design of a Human Powered Pizza Delivery Vehicle, along with the potential benefits to decrease development time, and provide stronger budget estimates.

Requirements↗