Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software Certification”

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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS2004

James Webb Space Telescope: Supporting Multiple Ground System Transitions in One Year

Ideas, requirements, and concepts developed during the very early phases of the mission design often conflict with the reality of a situation once the prime contractors are awarded. This happened for the James Webb Space Telescope (JWST) as well. The high level requirement of a common real-time ground system for both the Integration and Test (I&T), as well as the Operation phase of the mission is meant to reduce the cost and time needed later in the mission development for re-certification of databases, command and control systems, scripts, display pages, etc. In the case of JWST, the early Phase A flight software development needed a real-time ground system and database prior to the spacecraft prime contractor being selected. To compound the situation, the very low level requirements for the real-time ground system were not well defined. These two situations caused the initial real-time ground system to be switched out for a system that was previously used by the Bight software development team. To meet the high-!evel requirement, a third ground system was selected based on the prime spacecraft contractor needs and JWST Project decisions. The JWST ground system team has responded to each of these changes successfully. The lessons learned from each transition have not only made each transition smoother, but have also resolved issues earlier in the mission development than what would normally occur.

Detter, Ryan↗
NASA NTRS1994

User type certification for advanced flight control systems

Advanced avionics through flight management systems (FMS) coupled with autopilots can now precisely control aircraft from takeoff to landing. Clearly, this has been the most important improvement in aircraft since the jet engine. Regardless of the eventual capabilities of this technology, it is doubtful that society will soon accept pilotless airliners with the same aplomb they accept driverless passenger trains. Flight crews are still needed to deal with inputing clearances, taxiing, in-flight rerouting, unexpected weather decisions, and emergencies; yet it is well known that the contribution of human errors far exceed those of current hardware or software systems. Thus human errors remain, and are even increasing in percentage as the largest contributor to total system error. Currently, the flight crew is regulated by a layered system of certification: by operation, e.g., airline transport pilot versus private pilot; by category, e.g., airplane versus helicopter; by class, e.g., single engine land versus multi-engine land; and by type (for larger aircraft and jet powered aircraft), e.g., Boeing 767 or Airbus A320. Nothing in the certification process now requires an in-depth proficiency with specific types of avionics systems despite their prominent role in aircraft control and guidance.

Gilson, Richard D.↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink (R)

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the vali-dation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aero-space Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and as-cent. The GLASS framework utilizes the off-the-shelf Mathworks ® Simscape Multibody® toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparisons demonstrate that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check cases and verifies the GLASS core framework dynamics and the correct implementation of the check case scenario models.

6-Dof↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the validation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aerospace Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and ascent. The GLASS framework utilizes the off-the-shelf Mathworks (R) Simscape (TM) Multibody (TM) toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparison demonstrates that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check-cases and verify the GLASS core framework dynamics and the implementation of the check case scenario models.

6-Dof↗
NASA NTRS2001

Market Assessment of Forward-Looking Turbulence Sensing Systems

In recognition of the importance of turbulence mitigation as a tool to improve aviation safety, NASA's Aviation Safety Program developed a Turbulence Detection and Mitigation Sub-element. The objective of this effort is to develop highly reliable turbulence detection technologies for commercial transport aircraft to sense dangerous turbulence with sufficient time warning so that defensive measures can be implemented and prevent passenger and crew injuries. Current research involves three forward sensing products to improve the cockpit awareness of possible turbulence hazards. X-band radar enhancements will improve the capabilities of current weather radar to detect turbulence associated with convective activity. LIDAR (Light Detection and Ranging) is a laser-based technology that is capable of detecting turbulence in clear air. Finally, a possible Radar-LIDAR hybrid sensor is envisioned to detect the full range of convective and clear air turbulence. To support decisions relating to the development of these three forward-looking turbulence sensor technologies, the objective of this study was defined as examination of cost and implementation metrics. Tasks performed included the identification of cost factors and certification issues, the development and application of an implementation model, and the development of cost budget/targets for installing the turbulence sensor and associated software devices into the commercial transport fleet.

Kauffmann, Paul↗
DOE OSTI2025

Fermilab's Transition to Token Authentication

Fermilab is the first High Energy Physics institution to transition from X.509 user certificates to authentication tokens in production systems. All the experiments that Fermilab hosts are now using JSON Web Token (JWT) access tokens in their grid jobs. Many software components have been either updated or created for this transition, and most of the software is available to others as open source. The tokens are defined using the WLCG Common JWT Profile. Token attributes for all the tokens are stored in the Fermilab FERRY system which generates the configuration for the CILogon token issuer. High security-value refresh tokens are stored in Hashicorp Vault configured by htvault-config, and JWT access tokens are requested by the htgettoken client through its integration with HTCondor. The Fermilab job submission system jobsub was redesigned to be a lightweight wrapper around HTCondor. The grid workload management system GlideinWMS which is also based on HTCondor was updated to use tokens for pilot job submission. For automated job submissions a managed tokens service was created to reduce duplication of effort and knowledge of how to securely keep tokens active. The existing Fermilab file transfer tool ifdh was updated to work seamlessly with tokens, as well as the Fermilab POMS (Production Operations Management System) which is used to manage automatic job submission and the RCDS (Rapid Code Distribution System) which is used to distribute analysis code via the CernVM FileSystem. The dCache storage system was reconfigured to accept tokens for authentication in place of X.509 proxy certificates. As some services and sites have not yet implemented token support, proxy certificates are still sent with jobs for backwards compatibility, but some experiments are beginning to transition to stop using them.

Dykstra, Dave [Fermilab] (ORCID:0000000326539015)↗
NASA NTRS2026

Integrated Computational Materials Engineering (ICME) Capability Maturity Levels for Ecosystems Enabling Digital Transformation

Digital engineering (DE) and integrated computational materials engineering (ICME) are widely recognized as critical enablers of faster, more affordable, and more reliable aerospace systems. However, many organizations have struggled to realize the promised return on investment (ROI) from digital initiatives. A primary reason is the absence of a shared, decision-focused framework that distinguishes simple digitization of existing workflows from true digital transformation that fundamentally changes how engineering decisions are made. This paper introduces an ICME capability maturity framework that fills this gap. The framework defines six cumulative ICME capability maturity levels (CMLs), explicitly tied to decision authority, engineering integration, optimization, and uncertainty management across material, process, structure, and performance scales. It is designed to complement established readiness metrics such as technology readiness levels (TRLs), manufacturing readiness levels (MRLs), and integration readiness levels (IRLs), by addressing a missing dimension: the conditions required for model-informed decision authority across scales. A unifying figure and capability table illustrate the six-level ICME Capability Maturity Framework, showing how organizations progress from digitization—with limited or negative ROI—to true digital transformation, where ICME-enabled workflows deliver measurable improvements in decision quality, cycle time, risk reduction, and reuse. The framework is intended for both technical practitioners and executive leadership, providing a common language to assess current state, guide roadmaps, align software ecosystem investments, and set realistic expectations for digital transformation outcomes. A regulatory-relevant statement clarifying the relationship between ICME capability and existing certification frameworks is provided.

ICME↗
DOE OSTI2024

Fermilab s Transition to Token Authentication

Fermilab is the first High Energy Physics institution to transition from X.509 user certificates to authentication tokens in production systems. All of the experiments that Fermilab hosts are now using JSON Web Token (JWT) access tokens in their grid jobs. Many software components have been either updated or created for this transition, and most of the software is available to others as open source. The tokens are defined using the WLCG Common JWT Profile. Token attributes for all the tokens are stored in the Fermilab FERRY system which generates the configuration for the CILogon token issuer. High security-value refresh tokens are stored in Hashicorp Vault configured by htvault-config, and JWT access tokens are requested by the htgettoken client through its integration with HTCondor. The Fermilab job submission system jobsub was redesigned to be a lightweight wrapper around HTCondor. For automated job submissions a managed tokens service was created to reduce duplication of effort and knowledge of how to securely keep tokens active. The existing Fermilab file transfer tool ifdh was updated to work seamlessly with tokens, as well as the Fermilab POMS (Production Operations Management System) which is used to manage automatic job submission and the RCDS (Rapid Code Distribution System) which is used to distribute analysis code via the CernVM FileSystem. The dCache storage system was reconfigured to accept tokens for authentication in place of X.509 proxy certificates. As some services and sites have not yet implemented token support, proxy certificates are still sent with jobs for backwards compatibility but some experiments are beginning to transition to stop using them. There have been some glitches and learning curve issues but in general the system has been performing well and is being improved as operational problems are addressed.

Dykstra, David↗
NASA NTRSDate not supplied

Verification and Validation of Safety-Critical Aircraft Systems Operating under Off-Nominal, Contingency, and Emergency Conditions

Verification and validation (V&V) of safety-critical technologies developed for loss of control (LOC) prevention and recovery and other aviation safety concerns pose significant challenges. Aircraft LOC can result from a wide spectrum of hazards, often occurring in combination, which cannot be fully replicated during evaluation. Technologies developed for LOC prevention and recovery must therefore be effective under a wide variety of hazardous and uncertain conditions, and the verification and validation of these technologies must provide some measure of assurance that the new vehicle safety technologies do no harm (i.e., that they themselves do not introduce new safety risks). V&V technologies must also enable the identification of system limitations and constraints, as well as enable the identification of safe and unsafe operating conditions (and their boundaries). Additionally, the V&V of complex, increasingly autonomous systems is a fundamental concern. Scalable, reproducible and cost-effective techniques for the assurance of safety critical systems during their design and operation is a key barrier to fielding new systems or updating current systems. Moreover, these techniques need to provide artifacts that enable a comprehensive evidence-based approach to certification. This briefing summarizes research performed under NASA’s Aviation Safety Program and follow-on research for the V&V of safety-critical aircraft system technologies developed for LOC prevention and recovery and increasingly autonomous systems, and for a broad assurance capability in both current and emerging aviation applications. Note that, in this briefing, the term “validation” refers to a confirmation that the system implementation (e.g., algorithms etc.) is performing the intended function(s), as well as an affirmation of effectiveness in these functions. “Verification” refers to a confirmation that the system implementation in the software and hardware meets its (hopefully validated) specifications (e.g., correctly executes algorithms as designed).

Validation↗
NASA NTRS2005

Development of Advanced Verification and Validation Procedures and Tools for the Certification of Learning Systems in Aerospace Applications

Adaptive control technologies that incorporate learning algorithms have been proposed to enable automatic flight control and vehicle recovery, autonomous flight, and to maintain vehicle performance in the face of unknown, changing, or poorly defined operating environments. In order for adaptive control systems to be used in safety-critical aerospace applications, they must be proven to be highly safe and reliable. Rigorous methods for adaptive software verification and validation must be developed to ensure that control system software failures will not occur. Of central importance in this regard is the need to establish reliable methods that guarantee convergent learning, rapid convergence (learning) rate, and algorithm stability. This paper presents the major problems of adaptive control systems that use learning to improve performance. The paper then presents the major procedures and tools presently developed or currently being developed to enable the verification, validation, and ultimate certification of these adaptive control systems. These technologies include the application of automated program analysis methods, techniques to improve the learning process, analytical methods to verify stability, methods to automatically synthesize code, simulation and test methods, and tools to provide on-line software assurance.

Jacklin, Stephen↗
NASA NTRS2022

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗
NASA NTRS2022

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗
NASA NTRS2020

Unified Analysis of Aerospace Structures through Implementation of Rapid Tools into a Stress Framework

Rapid structural analysis tools have become an important part of the design cycle for aerospace companies for the last several decades. As these tools have been developed over time, there is often little consideration for shared software infrastructure between the tools, which makes design and analysis cumbersome due to a lack of commonality in input and output data and reporting, as well as poor traceability of results. Under the Rapid Tools task of the Advanced Composites Consortium (ACC), four aerospace tools were recently implemented or enhanced in the HyperSizer stress framework and then evaluated by this consortium of industry and government organizations. The framework provides an automated software environment for executing the rapid tools for analysis and sizing, quantifying margins of safety for thousands of load cases, and generating reports in support of FAA certification. This paper describes the process by which the tools were enhanced or implemented in the stress framework under the ACC project, and the evaluation conducted by industry consortium members.

Craig S Collier↗
NASA NTRS2020

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Evan J Anzalone↗
NASA NTRS2020

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Thomas Park↗
NASA NTRS1999

Geospatial Education and Research Development: A Laboratory for Remote Sensing and Environmental Analysis (LaRSEA)

Old Dominion University has claimed the title "University of the 21st Century," with a bold emphasis on technology innovation and application. In keeping with this claim, the proposed work has implemented a new laboratory equipped for remote sensing as well as curriculum and research innovations afforded for present and future faculty and students. The developments summarized within this report would not have been possible without the support of the NASA grant and significant cost-sharing of several units within the University. The grant effectively spring-boarded the university into major improvements in its approach to remote sensing and geospatial information technologies. The university has now committed to licensing Erdas Imagine software for the laboratory, a campus-wide ESRI geographic information system (GIS) products license, and several smaller software and hardware utilities available to faculty and students through the laboratory. Campus beneficiaries of this grant have included faculty from departments including Ocean, Earth. and Atmospheric Sciences, Political Science and Geography, Ecological Sciences, Environmental Health, and Civil and Environmental Engineering. High student interest is evidenced in students in geology, geography, ecology, urban studies, and planning. Three new courses have been added to the catalog and offered this year. Cross-cutting curriculum changes are in place with growing enrollments in remote sensing, GIS, and a new co-taught seminar in applied coastal remote sensing. The enabling grant has also allowed project participants to attract external funding for research grants, thereby providing additional funds beyond the planned matching, maintenance and growth of software and hardware, and stipends for student assistants. Two undergraduate assistants and two graduate assistants have been employed by full-time assistantships as a result. A new certificate is offered to students completing an interdisciplinary course sequence in remote sensing and coastal environments. Subsequent phases of the project are under planning. including seminars for regional coastal managers and public dissemination of remote sensing science through the local media and university publications.

Allen, Thomas R., Jr.↗
NASA NTRS1994

On the use of the systems approach to certify advanced aviation technologies

The field of human factors is as varied and diverse as the human subject itself. But one of its most important applications is the facilitation of safety and efficiency in a particular working environment through the implementation of paradigms known about humans and their working relationship with machines and systems. During the period since World War II (which is often viewed as the birth of Human Factors) no area has been the subject of more human factors research than aviation. And in no time during that epoch is the influence of human factors more important, nor more imperative than it is today. As technology driven designs have been finding their way into the national airspace system (NAS), there has been growing concern within the aviation industry itself, the Federal Aviation Administration (FAA), and the general public for a means by which to certify complex systems and the advanced aviation technologies that will be responsible for transporting, directing, and maintaining our airborne travel. While it is widely agreed human factors certification is desirable, the philosophy that will underlie the approach is debatable. There are, in general, two different approaches to certification: (1) the top-down or systems approach; and, (2) the bottom-up or monadical approach. The top-down approach is characterized by the underlying assumption that certification can be best achieved by looking at the system as a whole, understanding its objectives and operating environment, then examining the constituent parts. In an aircraft cockpit, this would be accomplished by first examining what the aircraft is supposed to be (e.g., fighter, general aviation, passenger), identifying its operating environment (IFR, VMC, combat, etc.) and looking at the entire working system which includes the hardware, software, liveware and their interactions; then, evaluative measures can be applied to the subsystems (e.g., individual instruments, CRT displays, controls). The bottom-up approach is founded on the philosophy that the whole can be best served by first examining it constituent elements. This approach would perform the above certification completely antithetically, by looking at the individual parts and certifying good human factors applications to those parts under the basic assumption that the whole is equal to the sum of its parts.

Wise, Mark A.↗