Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “integrated testing”

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 829 records · Page 46
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗
NASA NTRS2018

Imaging X-Ray Polarimetry Explorer (IXPE) Risk Management

The Imaging X-ray Polarimetry Explorer (IXPE) project is an international collaboration to build and fly a polarization sensitive X-ray observatory. The IXPE Observatory consists of the spacecraft and payload. The payload is composed of three X-ray telescopes, each consisting of a mirror module optical assembly and a polarization-sensitive X-ray detector assembly; a deployable boom maintains the focal length between the optical assemblies and the detectors. The goal of the IXPE Mission is to provide new information about the origins of cosmic X-rays and their interactions with matter and gravity as they travel through space. IXPE will do this by exploiting its unique capability to measure the polarization of X-rays emitted by cosmic sources. The collaboration for IXPE involves national and international partners during design, fabrication, assembly, integration, test, and operations. The full collaboration includes NASA Marshall Space Flight Center (MSFC), Ball Aerospace, the Italian Space Agency (ASI), the Italian Institute of Astrophysics and Space Planetology (IAPS)/Italian National Institute of Astrophysics (INAF), the Italian National Institute for Nuclear Physics (INFN), the University of Colorado (CU) Laboratory for Atmospheric and Space Physics (LASP), Stanford University, McGill University, and the Massachusetts Institute of Technology. The goal of this paper is to discuss risk management as it applies to the IXPE project. The full IXPE Team participates in risk management providing both unique challenges and advantages for project risk management. Risk management is being employed in all phases of the IXPE Project, but is particularly important during planning and initial execution-the current phase of the IXPE Project. The discussion will address IXPE risk strategies and responsibilities, along with the IXPE management process which includes risk identification, risk assessment, risk response, and risk monitoring, control, and reporting.

IXPE↗
NASA NTRS2018

NASA Advanced Explorations Systems: 2018 Advancements in Life Support Systems

The NASA Advanced Exploration Systems (AES) Life Support Systems (LSS) project strives to develop reliable, energy-efficient, and low-mass spacecraft systems to provide envi-ronmental control and life support systems (ECLSS) critical to enabling long duration human missions beyond low Earth orbit (LEO). Highly reliable, closed-loop life support systems are among the capabilities required for the longer duration human space exploration missions planned in the mid-2020s and beyond. The LSS Project is focused on three life support areas: air revitalization, wastewater processing/water management and environmental monitoring. Building upon the International Space Station (ISS) LSS systems (where applicable), the three-fold mission of the LSS Project is to address discrete LSS technology gaps, to improve the reliability of LSS systems, and to advance LSS systems toward integrated testing aboard the ISS. This paper is a follow on to the AES LSS development status reported in 2017 and provides additional details on the progress made since that publication with specific attention to the status of the Aerosol Sampler ISS Flight Experiment, the Spacecraft Atmosphere Monitor (SAM) Flight Experiment, the Brine Processor Assembly (BPA) Flight Experiment as well as the progress of the terrestrial development in air, water and environmental monitoring technologies.

trace contaminant control↗
NASA NTRS2015

Development of the Resource Prospector Planetary Rover

The Resource Prospector (RP) is an In-­‐Situ Resource Utilization (ISRU) lunar rover mission under study by NASA. RP is planned to launch in 2020 to prospect for subsurface volatiles and to extract oxygen from lunar regolith. The mission will address several of NASA's "Strategic Knowledge Gaps" for lunar exploration. The mission will also address the Global Exploration Roadmap's strategic goal of using local resources for human exploration. The distribution of lunar subsurface volatiles drives the mission requirement for mobility. The spatial distribution is hypothesized to be governed by impact cratering with the top 0.5 m being patchy at scales of 100 m. The mixing time scale increases with depth (less frequent larger impacts). Consequently, increased mobility reduces the depth requirement for sampling. The target RP traverse will extend 1 km radially from the landing site to sample craters of varying sizes. Sampling craters with different ages will reveal possible volatile emplacement history. In 1 Ga, approximately 60-­70 craters of 10 m diameter form per km2. Thus, the rover will need to sample at least ten of these craters, which may require a total traverse path length of 2-­‐3 km. During 2014-­2015, we developed an initial prototype rover for RP. The current design is a solar powered, four-­wheeled vehicle, with hub motor drive, offset four wheel steering, and active suspension. Active suspension provides capabilities including changing vehicle ride height, traversing comparatively large obstacles, and controlling load on the wheels. All-­wheel steering enables the vehicle to point arbitrarily while roving, e.g., to keep the solar array pointed at the sun while in motion. The offset steering combined with active suspension improves driving in soft soil. The rover's on-­board software utilizes NASA's Core Flight Software, which is a reusable flight software environment. During 2015, we completed the initial rover software build, which provides low-­level hardware interfaces, basic mobility control, waypoint driving, odometry, basic error checking, and camera services. Development of the prototype rover has enabled maturation of many of the subsystems to TRL 5. During the next year, we will conduct integrated testing of concepts of operation, navigation, and remote driving tools. In addition, we will perform environmental tests including radiation (avionics), thermal and thermal/vacuum (mechanisms), and gravity offload (mobility).

robotics↗
NASA NTRS2018

An Implementation Analysis of Communications, Navigation, and Surveillance (CNS) Technologies for Unmanned Air Systems (UAS)

The aviation industry and government agencies face a rapidly-emerging need for integrating large-scale populations of Unmanned Air Systems (UAS) into the worldwide controlled and uncontrolled airspace. Critical components for integration include the Communications, Navigation, and Surveillance (CNS) technologies necessary for ensuring safe UAS operations. Under NASA program NNA16BD84C, our work on CNS architectural concepts for the safe operation of UAS in controlled and uncontrolled airspace has introduced CNS architectures which must be analyzed in terms of implementation readiness.Controlled airspace operations for UAS are consistent with the needs for manned aviation in the worldwide Air Traffic Management (ATM) service. Uncontrolled airspace operations are consistent with the NASA Unmanned (air) Traffic Management (UTM) concept of operations. Implementation readiness is based on the NASA concept of Technology Readiness Levels (TRLs) ranging from TRL1 (basic principles observed and reported) to TRL9 (actual system flight proven through successful mission operations). In the architecture concepts, we have introduced a number of new CNS architectural elements which need to be correlated with TRL levels. In this paper, we present our implementation analysis for communications networks, communications data links, navigation, and surveillance. Each area has been under active research and development during the course of the current NASA program which has produced studies on UAS CNS Requirements, UAS CNS Architecture for Controlled Airspace and UAS CNS Architecture for Uncontrolled Airspace. We have published our architecture concepts in major UAS-related conferences (including iCNS2017, IEEE Aerospace 2018, and iCNS2018) and will continue to seek additional publication opportunities. We look forward to continuing our work to realize a full integration testing scenario for both controlled and uncontrolled airspace operation.

Unmanned (Air) Traffic Management (UTM) service↗
NASA NTRS2019

Characterization of Flat-Plate Heat Pipe Functionality for Fuel Cell Application

For many exothermic systems such as proton exchange membrane (PEM) fuel cells, cooling is necessary to maintain consistent and uniform operating temperatures which are generally in the range of 60 to 80°C. A potential solution is a heat pipe employing the principle of conduction in combination with a phase change. The purpose of this study was to fully characterize the operation of a heat pipe with unique geometry designed for fuel cell heat removal at operating temperatures up to 100°C and to assess the suitability of the resulting performance for cooling system integration. Test variables consist of cold sink thermal contact conductance coefficient improving material usage, heat rejection temperature, contact pressure and area, heat pipe orientation, operational hours, and variability between units. The test results showed that heat pipe performance improves through increased condenser and heat sink contact pressure, thermal contact coating usage, greater condenser area utilization, and colder heat sink temperature. Higher initial heat pipe temperature and greater age or operation time reduce the heat pipe capabilities. Placing the condenser lower than the evaporator is the only heat pipe orientation that affects evaporator plate temperature. Condensing fluid in the lower section reduces heat transfer capacity as that orientation requires liquid water to transport by wicking against gravity.

Smith, Phillip J.↗
NASA NTRS2018

NOS3: NASA Operational Simulator for Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of open-source software tools to aid in areas such as software development, integration & test (I&T), mission operations/training, verification and validation (V&V), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, operational interface/ground software, dynamics and environment simulations, and software-based hardware models. NOS3 has just recently been open-sourced by NASA and is available for immediate use. It enables the development of flight software (FSW) early in the project life cycle when hardware availability is limited. Small satellite development suffers from extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETUs). To alleviate the need to provide a hardware test-bed for each developer/tester, NOS3 hardware models are based upon characteristic data or manufacturer's data sheets for each individual component. The NOS3 hardware models' fidelity is such that FSW executes unaware that physical hardware is not present. This allows FSW binaries to be compiled for both the simulation environment and the flight computer without changing the FSW source code. For hardware models that provide data which is dependent upon the environment and spacecraft dynamics, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulator) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for V&V of larger missions such as James Webb Space Telescope (JWST). As hardware is selected and becomes available, drivers can be added to the NOS3 environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. NOS3 was actively used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat and the Lunar IceCube CubeSat. As NOS3 matures, hardware models have been added for common small satellite components such as GPS receivers, electrical power systems and batteries, and antenna systems.

Suder, Mark↗
NASA NTRS2018

PACE Technical Report Series, Volume 5: Mission Formulation Studies

This chapter summarizes the mission architecture for the Plankton, Aerosol, Cloud, ocean Ecosystem (PACE) mission, ranging from its scientific rationale to the history of its realized conception to itspresent-day organization and management. This volume in the PACE Technical Report series focuses ontrade studies that informed the formulation of the mission in its pre-Phase A (2014-2016; pre-formulation:define a viable and affordable concept) and Phase A (2016-2017; concept and technology development).With that in mind, this chapter serves to introduce the mission by providing: a brief summary of thescience drivers for the mission; a history of the direction of the mission to NASA's Goddard Space Flight Center (GSFC); a synopsis of the mission's and instruments' management and development structures; and a brief description of the primary components and elements that form the foundation ofthe mission, encompassing the major mission segments (space, ground, and science data processing) and their roles in integration, testing, and operations.

Cetinic, Ivona↗
NASA NTRS2018

An Implementation Analysis of Communications, Navigation, and Surveillance (CNS) Technologies for Unmanned Air Systems (UAS)

The aviation industry and government agencies face a rapidly-emerging need for integrating large-scale populations of Unmanned Air Systems (UAS) into the worldwide controlled and uncontrolled airspace. Critical components for integration include the Communications, Navigation, and Surveillance (CNS) technologies necessary for ensuring safe UAS operations. Under NASA program NNA16BD84C, our work on CNS architectural concepts for the safe operation of UAS in controlled and uncontrolled airspace has introduced CNS architectures which must be analyzed in terms of implementation readiness.Controlled airspace operations for UAS are consistent with the needs for manned aviation in the worldwide Air Traffic Management (ATM) service. Uncontrolled airspace operations are consistent with the NASA Unmanned (air) Traffic Management (UTM) concept of operations. Implementation readiness is based on the NASA concept of Technology Readiness Levels (TRLs) ranging from TRL1 (basic principles observed and reported) to TRL9 (actual system flight proven through successful mission operations). In the architecture concepts, we have introduced a number of new CNS architectural elements which need to be correlated with TRL levels.In this paper, we present our implementation analysis for communications networks, communications data links, navigation, and surveillance. Each area has been under active research and development during the course of the current NASA program which has produced studies on UAS CNS Requirements, UAS CNS Architecture for Controlled Airspace and UAS CNS Architecture for Uncontrolled Airspace. We have published our architecture concepts in major UAS-related conferences (including iCNS2017, IEEE Aerospace 2018, and iCNS2018) and will continue to seek additional publication opportunities. We look forward to continuing our work to realize a full integration testing scenario for both controlled and uncontrolled airspace operation.

Ponchak, Denise↗
NASA NTRSDate not supplied

Lightning Protection System

A new Lightning Protection System (LPS) was designed and built at Launch Complex 39B (LC-39B), at the Kennedy Space Center (KSC), Florida, in 2009, for NASA’s Space Launch System (SLS) program. A comprehensive lightning monitoring system was additionally designed and the LC-39B lightning instrumentation started incremental deployment early 2011. By March 2011, the LC-39B lightning monitoring system was activated with short outages during construction and renovations of the LC-39B. Since 2011, the LC-39B LPS has been directly struck at least once per year. The earliest and latest in a year that the LPS has been directly struck by lightning has been January 7th and October 1st (both 2017), respectively. During the summer of 2018, the Mobile Launcher 1 (ML-1) lightning monitoring system was deployed and partially active during ML-1 construction/testing. Since 2018, the ML-1 has been parked at the LC-39B for different durations of time for integrated testing. Early August 2019 (6th and 9th ) multiple lightning strikes terminated directly on the LPS at three different locations in addition to a nearby strike within the Pad perimeter and multiple nearby strikes outside the Pad Perimeter, triggering both, the LC-39B and the ML-1 lightning monitoring systems. This has been the first time direct lightning strikes have terminated on the LPS or within the LC-39B perimeter while the ML-1 has been at the LC-39B. This paper summarizes direct and close nearby lightning strikes to LC-39B from 2011 until the summer of 2019.

Angel G Mata↗
NASA NTRSDate not supplied

Going beyond reliability to robustness and resilience in space systems

The words reliability, robustness, and resilience, are often used interchangeably to describe tough and dependable systems but the distinctions between them suggest how to design more serviceable space systems. Reliability is simply the quality of consistently performing well. A system that dependably meets its design requirements in the specified environments is reliable. The designers may not consider themselves responsible for failures under unanticipated conditions. Robustness is the capability of performing without failure under a wide range of conditions, which can go beyond the expected range to include possible off-nominal conditions. Resilience is the ability to recover from or adapt to damaging events, such as failures, accidents, external disruptions, and repurposing. Such changes are usually unanticipated. They often invalidate the usual operating assumptions and cause system failure. Reliability, robustness, and resilience describe dependable performance under increasingly difficult conditions, first the specified environment, then a wider possible environment, and finally unanticipated damaging events. These three are increasingly desirable and increasingly difficult to achieve. Engineering for resilience would design systems that can ignore or repair failures, survive accidents, and recover from disruptions. Increasing the resilience of space systems, the ability to perform after unanticipated events, would greatly increase space crew safety. Improving reliability and robustness can be done by dealing with known sources of problems, but improving resilience requires implementing a general approach to reducing the impact of unknown future events. Two contrasting approaches are reducing system complexity and adding supervisory control. The need for resilience has been claimed for decades but little has been accomplished. Systems designers assume that they understand requirements, technologies, designs, architectures, integration, testing, operations, and environments. The potential problems of changes, failures, accidents, unknown environments, and unknown unknowns are ignored. Systems designers are typically overconfident and ignore the need for robustness and resilience.

Harry W Jones↗
NASA NTRSDate not supplied

Designing a Distributed Web-based Simulation Environment for Enabling Autonomous Systems Research

In the continued pursuit of creating a future with robust Urban Air Mobility (UAM) operations defined as safe and efficient air traffic operations in metropolitan environments for both piloted and autonomous systems, development of the concepts, technologies, and procedures to establish this UAM ecosystem remains an active area of research. In particular, as autonomous systems continue to grow in both complexity and use throughout UAM concepts the need for simulation environments to both test individual components and systems and to study the complex interactions between them is paramount. In this paper we address design considerations, technologies, and challenges of adapting native simulation environment application concepts to an interactive and distributed web-based framework. The proposed web-based design allows for easier and wider access for developing, testing, integrating, and studying emergent behaviors of complex autonomous systems interaction. We demonstrate the utility of the proposed approach by showing multi-agent interaction and emergent behavior in two scenarios: (1) autonomous urban air mobility vehicles flying in a convoy and (2) interaction of a convoy with a search and rescue operation.

Benjamin N Kelley↗
NASA NTRSDate not supplied

The High Density Vertiplex Advanced Onboard Automation Overview

While many studies have been performed examining Urban Air Mobility (UAM) operations from UAM Maturity Level (UML) UML-1 to UML-4, [1, 2] some uncertainty exists regarding the integration and role of onboard autonomous systems, airspace management systems, ground control and fleet management systems, and how they integrate with vertiport automation systems to ensure safe high-density future operations. One thrust of the Advanced Air Mobility (AAM) High Density Vertiplex (HDV) sub-project is to perform rapid prototyping and assessment of an Urban Air Mobility (UAM) Ecosystem within the terminal operational area to help inform future research investments and technology development. Another thrust within HDV is to perform integration, testing, and safety risk assessments required to acquire operational credit for several NASA small Unmanned Aerial Systems (sUAS) beyond visual line of sight (BVLOS) enabling technologies to expand test capabilities and to expedite technology transfer and ultimate effective usage. Both thrusts leverage sUAS to serve as surrogates for the highly-technologically-similar envisioned UAM aircraft as well as to provide significant contributions to sUAS Part-135 operators. This report provides an overview of the activities accomplished within the Advanced Onboard Automation (AOA) schedule work package of HDV.

Human Factors, Simulation↗
NASA NTRSDate not supplied

Challenges of Building, Launching, and Operating The Curiosity SAM Instrument on Mars

The Sample Analysis at Mars (SAM) Suite Investigation onboard the Mars Science Laboratory (MSL) Curiosity rover is currently roving up Mt Sharp in Gale Crater on Mars. It is investigating the present and past habitability of Mars by exploring molecular and elemental chemistry relevant to life. SAM is a suite of three instruments, a Quadrupole Mass Spectrometer (QMS), a Gas Chromatograph (GC), and a Tunable Laser Spectrometer (TLS). As Curiosity climbs Mt. Sharp, SAM’s instrument suite search for and measure the abundances of carbon, oxygen, hydrogen, and nitrogen - elements that are associated with life as we know it. SAM quantitatively addresses the habitability of Mars, an essential step in the search for past or present life on Mars. This talk provides a behind-the-scenes look at the vignettes of the engineering challenges of building, integrating, testing, launching, and the SAM’s team’s initial experiences of operating SAM on Mars.

Florence Tan↗
NASA NTRSDate not supplied

Transforming any Facility for Meeting Strict Cleanliness Requirements

Over the life of the James Webb Space Telescope (JWST), Integration & Test (I&T) has taken place in areas that needed considerable work to make the facility itself and/or the protocols used while working in the rooms suitable to meet JWST percent area coverage (PAC) and molecular accumulation requirements. In addition to normal particulate matter, JWST had a uniquely significant challenge: fibers! Fibers not only cause much higher PAC levels, but they also risk damaging the angstrom sized Near Infrared Spectrometer (NIRSpec) microshutter array (MSA), which is critical to NIRSpec instrument performance. The primary emphasis of this paper is to address particulate and fiber contamination. The success of the JWST mission required effective cleanrooms, protocols, and mitigations in non-cleanroom areas that were pressed into service to house contamination-sensitive optics and scientific instruments. Some presented profound challenges. These included: NASA’s 60-year-old Johnson Space Center (JSC) Chamber A, which had never been used for anything contamination-sensitive, and the European tropical launch facilities, which were designed to meet International Standard Organization (ISO) Class 8 processing for communication satellites. The final challenge for JWST, as if to stare us in the face and say, “I dare you to try and make me clean enough,” was preparing the 4 areas in the Centre Spatial Guyanais (CSG) Final Assembly Building (BAF) located in French Guiana, a building in which one entire side opens for Ariane 5 rocket ingress and egress. This paper will describe our initial evaluation processes and the actual work undertaken to transform even the most challenging areas into first class cleanrooms that met JWST particulate and fiber requirements.

James Webb Space Telescope↗
NASA NTRSDate not supplied

Preliminary Application of Formal Verification to An Autonomy Architecture for Unmanned Aircraft

There is a desire to design autonomous systems in such a way that capabilities can be easily added or re- combined to produce new behaviors while preserving their safety properties. ICAROUS, a prototype software architecture for building safety-centric autonomous unmanned aircraft applications, is designed to support this type of extensibility and re-configurability. In ICAROUS, core capabilities are implemented as individual soft- ware services, so that enabling access to new capabilities simply requires adding new services. To make use of these capabilities, ICAROUS includes a specialized service that provides a general framework for config- uring the relative priorities, conditions, and rules that govern how different modules should be engaged and disengaged during flight. The inherent complexity of coordinating multiple modules under changing conditions makes it difficult to determine whether a particular configuration could have erroneous behaviors in certain circumstances. A robust set of integration tests can help discover errors, but testing can only realistically cover a relatively small proportion of total system behaviors. Developing good tests and interpreting the results to pinpoint the cause of errors when they arise can also be very time-consuming. To supplement testing, formal methods can be used to model and analyze complex systems, achieving better coverage and simplifying the process of finding, understanding, and fixing errors. To demonstrate these benefits, this paper explores the ap- plication of formal methods to ICAROUS. In particular, the Spin model checker is used to specify requirements for and model portions of the system, then verify whether the model satisfies the requirements and find and fix errors when it does not.

Formal Methods↗
NASA NTRS2024

High Level Architecture (HLA) as a Research Tool for Advanced Air Mobility (AAM)

In this document, a NASA investigation into the High-Level Architecture (HLA) standard for distributed simulation as a means of furthering Advanced Air Mobility (AAM) research is illustrated along with a description of the evolution of distributed simulation leading to the HLA standard. HLA enables efficient definition and insertion of components and participants in simulation sessions. Novel concepts can be added or removed as the work evolves. A general history of the HLA standard is described to show past needs for improved methods of distributed simulation, particularly among participating laboratories in separate locations, as well as previous applications of HLA simulation to airspace research. These examples from the past illustrate how new and emerging concepts can be simulated by layering notional ideas over simulated current-day systems and capabilities in a controlled environment for examination. In the 1990s, the Federal Aviation Administration (FAA) and the MITRE Corporation performed joint research into then-emergent capabilities in the National Airspace System (NAS). In the early 2000s, the MITRE Corporation developed an open, extendable set of objects and protocols designed for global and collaborative aviation research called AviationSimNet, which has HLA as its foundation. This led to NASA and the FAA using AviationSimNet to connect laboratories for AAM research, resulting in the NASA/FAA Laboratory Integrated Test Environment (NFLITE). The underlying capabilities of HLA enabled testing a notional interaction between AAM and legacy ATC systems that resulted in AAM vehicles receiving beacon codes for identification on ATC screens in Class C airspace. The potential next steps in this work include defining and examining notional interactions between AAM and legacy ATC systems within Class B airspace.

UAM↗
NASA NTRSDate not supplied

Preliminary Application of Formal Verification to An Autonomy Architecture for Unmanned Aircraft

There is a desire to design autonomous systems in such a way that capabilities can be easily added or re-combined to produce new behaviors while preserving their safety properties. ICAROUS, a prototype software architecture for building safety-centric autonomous unmanned aircraft applications, is designed to support this type of extensibility and re-configurability. In ICAROUS, core capabilities are implemented as individual soft- ware services, so that enabling access to new capabilities simply requires adding new services. To make use of these capabilities, ICAROUS includes a specialized service that provides a general framework for config- uring the relative priorities, conditions, and rules that govern how different modules should be engaged and disengaged during flight. The inherent complexity of coordinating multiple modules under changing conditions makes it difficult to determine whether a particular configuration could have erroneous behaviors in certain circumstances. A robust set of integration tests can help discover errors, but testing can only realistically cover a relatively small proportion of total system behaviors. Developing good tests and interpreting the results to pinpoint the cause of errors when they arise can also be very time-consuming. To supplement testing, formal methods can be used to model and analyze complex systems, achieving better coverage and simplifying the process of finding, understanding, and fixing errors. To demonstrate these benefits, this paper explores the ap- plication of formal methods to ICAROUS. In particular, the Spin model checker is used to specify requirements for and model portions of the system, then verify whether the model satisfies the requirements and find and fix errors when it does not.

Formal Methods↗