Search NASA⌕ Search

NASA NTRS · 20140010621

Towards Requirements in Systems Engineering for Aerospace IVHM Design

Abstract

Health management (HM) technologies have been employed for safety critical system for decades, but a coherent systematic process to integrate HM into the system design is not yet clear. Consequently, in most cases, health management resorts to be an after-thought or 'band-aid' solution. Moreover, limited guidance exists for carrying out systems engineering (SE) on the subject of writing requirements for designs with integrated vehicle health management (IVHM). It is well accepted that requirements are key to developing a successful IVHM system right from the concept stage to development, verification, utilization, and support. However, writing requirements for systems with IVHM capability have unique challenges that require the designers to look beyond their own domains and consider the constraints and specifications of other interlinked systems. In this paper we look at various stages in the SE process and identify activities specific to IVHM design and development. More importantly, several relevant questions are posed that system engineers must address at various design and development stages. Addressing these questions should provide some guidance to systems engineers towards writing IVHM related requirements to ensure that appropriate IVHM functions are built into the system design.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Saxena, Abhinav, Roychoudhury, Indranil, Lin, Wei, Goebel, Kai. 2013-08-19. Towards Requirements in Systems Engineering for Aerospace IVHM Design. https://ntrs.nasa.gov/citations/20140010621

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↗