SEARCH · Search NASA

Results for “Team software development”

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.

SourceResearch connectionFrom yearThrough year

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

At least 199 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRS1993

The NCC project: A quality management perspective

The Network Control Center (NCC) Project introduced the concept of total quality management (TQM) in mid-1990. The CSC project team established a program which focused on continuous process improvement in software development methodology and consistent deliveries of high quality software products for the NCC. The vision of the TQM program was to produce error free software. Specific goals were established to allow continuing assessment of the progress toward meeting the overall quality objectives. The total quality environment, now a part of the NCC Project culture, has become the foundation for continuous process improvement and has resulted in the consistent delivery of quality software products over the last three years.

Lee, Raymond H.↗

NASA NTRS1997

Innovative Educational Aerospace Research at the Northeast High School Space Research Center

Northeast High Magnet School of Philadelphia, Pennsylvania is a proud sponsor of the Space Research Center (SPARC). SPARC, a model program of the Medical, Engineering, and Aerospace Magnet school, provides talented students the capability to successfully exercise full simulations of NASA manned missions. These simulations included low-Earth Shuttle missions and Apollo lunar missions in the past, and will focus on a planetary mission to Mars this year. At the end of each scholastic year, a simulated mission, lasting between one and eight days, is performed involving 75 students as specialists in seven teams The groups are comprised of Flight Management, Spacecraft Communications (SatCom), Computer Networking, Spacecraft Design and Engineering, Electronics, Rocketry, Robotics, and Medical teams in either the mission operations center or onboard the spacecraft. Software development activities are also required in support of these simulations The objective of this paper is to present the accomplishments, technology innovations, interactions, and an overview of SPARC with an emphasis on how the program's educational activities parallel NASA mission support and how this education is preparing student for the space frontier.

Audra Luyet↗

NASA NTRS2004

Aura Atmospheric Data Products and Their Availability from NASA Goddard Earth Sciences DAAC

NASA's EOS-Aura spacecraft was launched successfully on July 15, 2004. The four instruments onboard the spacecraft are the Microwave Limb Sounder (MLS), the Ozone Monitoring Instrument (OMI), the Tropospheric Emission Spectrometer (TES), and the High Resolution Dynamics Limb Sounder (HBDLS). The Aura instruments are designed to gather earth sciences measurements across the ultraviolet, visible, infra-red, thermal and microwave regions of the electromagnetic spectrum. Aura will provide over 70 distinct standard atmospheric data products for use in ozone layer and surface UV-B monitoring, air quality forecast, and atmospheric chemistry and climate change studies (http://eosaura.gsfc.nasa.gov/). These products include earth-atmosphere radiances and solar spectral irradiances; total column, tropospheric, and profiles of ozone and other trace gases, surface W-B flux; clouds and aerosol characteristics; and temperature, geopotential height, and water vapor profiles. The MLS, OMI, and HIRDLS data products will be archived at the NASA Goddard Earth Sciences (GES) Distributed Active Archive Center (DAAC), while data from TES will be archived at NASA Langley Research Center DAAC. Some of the standard products which have gone through quick preliminary checks are already archived at the GES DAAC (http://daac.nsfc.nasa.gov/) and are available to the Aura science team and data validation team members for data validation; and to the application and visualization software developers, for testing their application modules. Once data are corrected for obvious calibration problems and partially validated using in-situ observations, they would be made available to the broader user community. This presentation will provide details of the whole suite of Aura atmospheric data products, and the time line of the availability of the rest of the preliminary products and of the partially validated provisional products. Software and took available for data access, visualization, and data mining will also be discussed.

Ahmad, S.↗

NASA NTRSDate not supplied

Advances in High-rate Delay Tolerant Networking On-board the International Space Station

The High-rate Delay Tolerant Networking (HDTN) project at the NASA John H. Glenn Research Center (GRC) is developing a performance optimized Delay Tolerant Networking (DTN) implementation which is able to provide reliable multigigabit per second automated network communications for near-Earth and deep space missions. To that end, this paper provides an overview of the testing and integration efforts culminating in a high-rate DTN demonstration onboard the International Space Station (ISS). Over several years, the HDTN team has performed a series of end-to-end tests between the Software Development and Integration Laboratory (SDIL) at the Lyndon B. Johnson Space Center (JSC) and Marshall Space Flight Center’s Huntsville Operations Support Center (HOSC). The testing has focused on a realistic emulation of the ISS Ku-band RF link, which operates at a maximum of 500 Mbps downlink with a 600 ms round-trip time. In this environment, the HDTN onboard gateway has been tested for interoperability with ISS payload nodes and the DTN ground gateway, store and forward capability, reliable transport using the Licklider Transmission Protocol (LTP), and successful recovery from unexpected loss of signal. In addition to integration testing, HDTN has developed a series of software engineering practices to ensure the stability and maturity of the implementation. As the result, HDTN has successfully demonstrated high-rate DTN services onboard the ISS. This paper concludes with a summary of preliminary flight testing results from the Integrated LCRD LEO User Modem and Amplifier Terminal networking experiments.

Delay tolerant networking↗

NASA NTRS2006

Version 5 Release Status and Plans: AIRS Science Team

This viewgraph presentation reviews the development of version 5 of Atmospheric Infrared Sounder (AIRS) software. The overarching goal for version 5 is to enhance AIRS software to expand its utility for climate research and to improve the impact on weather forecasting.

focus group↗

NASA NTRS2006

A Core Plug and Play Architecture for Reusable Flight Software Systems

The Flight Software Branch, at Goddard Space Flight Center (GSFC), has been working on a run-time approach to facilitate a formal software reuse process. The reuse process is designed to enable rapid development and integration of high-quality software systems and to more accurately predict development costs and schedule. Previous reuse practices have been somewhat successful when the same teams are moved from project to project. But this typically requires taking the software system in an all-or-nothing approach where useful components cannot be easily extracted from the whole. As a result, the system is less flexible and scalable with limited applicability to new projects. This paper will focus on the rationale behind, and implementation of the run-time executive. This executive is the core for the component-based flight software commonality and reuse process adopted at Goddard.

Wilmot, Jonathan↗

NASA NTRS2016

CASIS Fact Sheet: Hardware and Facilities

Vencore is a proven information solutions, engineering, and analytics company that helps our customers solve their most complex challenges. For more than 40 years, we have designed, developed and delivered mission-critical solutions as our customers' trusted partner. The Engineering Services Contract, or ESC, provides engineering and design services to the NASA organizations engaged in development of new technologies at the Kennedy Space Center. Vencore is the ESC prime contractor, with teammates that include Stinger Ghaffarian Technologies, Sierra Lobo, Nelson Engineering, EASi, and Craig Technologies. The Vencore team designs and develops systems and equipment to be used for the processing of space launch vehicles, spacecraft, and payloads. We perform flight systems engineering for spaceflight hardware and software; develop technologies that serve NASA's mission requirements and operations needs for the future. Our Flight Payload Support (FPS) team at Kennedy Space Center (KSC) provides engineering, development, and certification services as well as payload integration and management services to NASA and commercial customers. Our main objective is to assist principal investigators (PIs) integrate their science experiments into payload hardware for research aboard the International Space Station (ISS), commercial spacecraft, suborbital vehicles, parabolic flight aircrafts, and ground-based studies. Vencore's FPS team is AS9100 certified and a recognized implementation partner for the Center for Advancement of Science in Space (CASIS

Solomon, Michael R.↗

NASA NTRS2022

Simulating Mars: Enabling Testing of the Perseverance Rover Sampling and Caching Subsystem on Earth

The development of the Sampling and Caching Subsystem (SCS) on the JPL Perseverance Rover lies at the intersection of testing, robotics, and geology. The SCS team established three primary system test campaigns and venues to aid in the development of SCS through verification and validation testing – Qualification Model Dirty Testing (QMDT) to provide a venue for testing in a Martian environment, Vehicle System Testbed (VSTB) for testing while integrated with the mobility subsystem on Martian-like terrain, and the Flight Software Testbed (FSWTB) for conducting tests using the flight motor controllers and software system on a hexapod which had the ability to simulate rover tilt. Each venue contributed a vital piece to the SCS building blocks. However, the QMDT venue operating within a 10-ft diameter Thermal Vacuum chamber to simulate Martian environment provided a sui generis opportunity to fine tune the entire sampling and caching process while building the team’s knowledge base about rock drillability, system life, and target selection. On Earth, because Martian rocks are not readily available, the development team must utilize geoanalogs to the rocks and regolith on Mars. Geologists on the team helped establish a set of standard rock types to use for Mars missions, like Basalt, Sandstone, Mudstone, Gypsum, and other related geoanalogs. These geoanalogs are characterized with a standard suite of tests for density, compressibility, and other characteristics to categorize potential drillability. This concept of drillability is what links the geoanalogs on Earth to the samples we collect on Mars. With the simulant characteristics defined, these geoanalog rocks are ready to be drilled into as we do on the Martian surface. A key aspect of interacting with the surface on Mars is rock target identification and selection. The Perseverance robotic system uses the on-board cameras, instrumentation, and software to collect enough information to identify potential scientific targets. With the targets identified, SCS can place the Corer and abrade the surface or collect a sample. For a ground test activity like QMDT, the test team did not have all of the camera and instrumentation systems that the rover does, so the team developed ground test equivalents to process a rock, build a target map, and define the target. The team constructed a Rock Scanning Station to build a 3D point cloud of the rock. This point cloud was then processed and evaluated with predefined and programmed criteria in a Target Downselect Tool. A primary output of the Target Downselect Tool is a defined target that can be uploaded directly to the robotic software system to simulate and build the robotic sequences used in tests. With these insights and programmatic definition of targets, the QMDT test team was able to make the same decisions that the Perseverance surface operations team does. In addition, valuable lessons learned from developing the target selection ground tools and using them were implemented into the tools used for surface operations.

Kim, Junggon↗

NASA NTRS2015

Big Software for SmallSats: Adapting CFS to CubeSat Missions

Expanding capabilities and mission objectives for SmallSats and CubeSats is driving the need for reliable, reusable, and robust flight software. While missions are becoming more complicated and the scientific goals more ambitious, the level of acceptable risk has decreased. Design challenges are further compounded by budget and schedule constraints that have not kept pace. NASA's Core Flight Software System (cFS) is an open source solution which enables teams to build flagship satellite level flight software within a CubeSat schedule and budget. NASA originally developed cFS to reduce mission and schedule risk for flagship satellite missions by increasing code reuse and reliability. The Lunar Reconnaissance Orbiter, which launched in 2009, was the first of a growing list of Class B rated missions to use cFS. Large parts of cFS are now open source, which has spurred adoption outside of NASA. This paper reports on the experiences of two teams using cFS for current CubeSat missions. The performance overheads of cFS are quantified, and the reusability of code between missions is discussed. The analysis shows that cFS is well suited to use on CubeSats and demonstrates the portability and modularity of cFS code.

Open Source↗

NASA NTRS2012

Simulation Tools Model Icing for Aircraft Design

Here s a simple science experiment to try: Place an unopened bottle of distilled water in your freezer. After 2-3 hours, if the water is pure enough, you will notice that it has not frozen. Carefully pour the water into a bowl with a piece of ice in it. When it strikes the ice, the water will instantly freeze. One of the most basic and commonly known scientific facts is that water freezes at around 32 F. But this is not always the case. Water lacking any impurities for ice crystals to form around can be supercooled to even lower temperatures without freezing. High in the atmosphere, water droplets can achieve this delicate, supercooled state. When a plane flies through clouds containing these droplets, the water can strike the airframe and, like the supercooled water hitting the ice in the experiment above, freeze instantly. The ice buildup alters the aerodynamics of the plane - reducing lift and increasing drag - affecting its performance and presenting a safety issue if the plane can no longer fly effectively. In certain circumstances, ice can form inside aircraft engines, another potential hazard. NASA has long studied ways of detecting and countering atmospheric icing conditions as part of the Agency s efforts to enhance aviation safety. To do this, the Icing Branch at Glenn Research Center utilizes a number of world-class tools, including the Center s Icing Research Tunnel and the NASA 607 icing research aircraft, a "flying laboratory" for studying icing conditions. The branch has also developed a suite of software programs to help aircraft and icing protection system designers understand the behavior of ice accumulation on various surfaces and in various conditions. One of these innovations is the LEWICE ice accretion simulation software. Initially developed in the 1980s (when Glenn was known as Lewis Research Center), LEWICE has become one of the most widely used tools in icing research and aircraft design and certification. LEWICE has been transformed over the years from strictly a research tool to one used routinely by industry and other government agencies. Glenn contractor William Wright has been the architect of this development, supported by a team of researchers investigating icing physics, creating validation data, and ensuring development according to standard software engineering practices. The program provides a virtual simulation environment for determining where water droplets strike an airfoil in flight, what kind of ice would result, and what shape that ice would take. Users can enter geometries for specific, two-dimensional cross sections of an airfoil or other airframe surface and then apply a range of inputs - different droplet sizes, temperatures, airspeeds, and more - to model how ice would build up on the surface in various conditions. The program s versatility, ease of use, and speed - LEWICE can run through complex icing simulations in only a few minutes - have contributed to it becoming a popular resource in the aviation industry.

Source record↗

NASA NTRS1998

MAMI: Modeling of the Magnetosphere-Ionosphere-Atmosphere System

Major emphasis of the investigation was the development of theoretical and numerical models of the aurora and of high latitude ionospheric processes. In particular: (1) the NCAR TIGCM (Thermosphere-Ionosphere Global Circulation Model) was updated to include mid and low latitude electrodynamics (this version is called TIE-GCM); (2) the NCAR TIE-GCM was modified to include a more realistic representation of the aurora; (3) the UAF auroral electron transport model was modified to include local acceleration processes; (4) a local ionospheric and auroral model (AURORA) was developed to allow detailed studies of the aurora; (5) a proton-hydrogen transport code has been developed to model proton aurora; and (6) a theory for the production of suprathermal atoms and ions in the upper atmosphere was developed and applied to studies of atomic nitrogen transport and helium escape on open field lines. These models enable us to devise schemes for tile interpretation and quantitative analysis of data obtained by the POLAR spacecraft. Parameterizations were formulated and are available to the GGS investigators. The UVI and VIS teams have adopted these parameterizations and include them in their data analysis. We have developed software for the quantitative interpretation of UVI and VIS images. After the launch of the POLAR satellite we used the image data from UVI and VIS in combination with ground based data from SuperDARN and incoherent scatter radars, magnetometers, and in situ observations from DMSP and NOAA satellites to characterize the state of the ionosphere. A number of event studies have been carried out in cooperation with other CGS theory teams.

Source record↗

NASA NTRS2017

Launch Control System Software Development System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.

Automation↗

NASA NTRS2022

Building a Transdisciplinary, Exascale-Capable Workforce for Geospace Science

Key Points: ●First-principles, self-consistent geospace modeling will require at least exascale-level computing capabilities; however, the technical skills necessary to develop such simulation codes are not taught as part of Heliophysics training/PhD programs. ●Developing exascale Heliophysics codes will require transdisciplinary collaborations between physicists, computer scientists, software engineers, data scientists, and applied mathematics. Such teams must be persistent and formed around specific skills, not specific problems. ●We must have stable, positive long-term career outcomes for Heliophysics scientific developers in order to retain knowledge of and promote future innovation in scientific algorithm development and advanced computing techniques. One such way to do this is by funding long-term scientific programming groups, akin to Heliophysics DRIVE Centers. ●We must have a balance between promoting innovation via funding short-term closed-source development and allowing the open-source community to benefit from and build on the newest scientific modeling techniques.

C Bard↗

NASA NTRS2003

Monte Carlo Methods in Materials Science Based on FLUKA and ROOT

A comprehensive understanding of mitigation measures for space radiation protection necessarily involves the relevant fields of nuclear physics and particle transport modeling. One method of modeling the interaction of radiation traversing matter is Monte Carlo analysis, a subject that has been evolving since the very advent of nuclear reactors and particle accelerators in experimental physics. Countermeasures for radiation protection from neutrons near nuclear reactors, for example, were an early application and Monte Carlo methods were quickly adapted to this general field of investigation. The project discussed here is concerned with taking the latest tools and technology in Monte Carlo analysis and adapting them to space applications such as radiation shielding design for spacecraft, as well as investigating how next-generation Monte Carlos can complement the existing analytical methods currently used by NASA. We have chosen to employ the Monte Carlo program known as FLUKA (A legacy acronym based on the German for FLUctuating KAscade) used to simulate all of the particle transport, and the CERN developed graphical-interface object-oriented analysis software called ROOT. One aspect of space radiation analysis for which the Monte Carlo s are particularly suited is the study of secondary radiation produced as albedoes in the vicinity of the structural geometry involved. This broad goal of simulating space radiation transport through the relevant materials employing the FLUKA code necessarily requires the addition of the capability to simulate all heavy-ion interactions from 10 MeV/A up to the highest conceivable energies. For all energies above 3 GeV/A the Dual Parton Model (DPM) is currently used, although the possible improvement of the DPMJET event generator for energies 3-30 GeV/A is being considered. One of the major tasks still facing us is the provision for heavy ion interactions below 3 GeV/A. The ROOT interface is being developed in conjunction with the CERN ALICE (A Large Ion Collisions Experiment) software team through an adaptation of their existing AliROOT (ALICE Using ROOT) architecture. In order to check our progress against actual data, we have chosen to simulate the ATIC14 (Advanced Thin Ionization Calorimeter) cosmic-ray astrophysics balloon payload as well as neutron fluences in the Mir spacecraft. This paper contains a summary of status of this project, and a roadmap to its successful completion.

Pinsky, Lawrence↗

NASA NTRS2010

Lessons Learned on Implementing Fault Detection, Isolation, and Recovery (FDIR) in a Ground Launch Environment

This paper's main purpose is to detail issues and lessons learned regarding designing, integrating, and implementing Fault Detection Isolation and Recovery (FDIR) for Constellation Exploration Program (CxP) Ground Operations at Kennedy Space Center (KSC). Part of the0 overall implementation of National Aeronautics and Space Administration's (NASA's) CxP, FDIR is being implemented in three main components of the program (Ares, Orion, and Ground Operations/Processing). While not initially part of the design baseline for the CxP Ground Operations, NASA felt that FDIR is important enough to develop, that NASA's Exploration Systems Mission Directorate's (ESMD's) Exploration Technology Development Program (ETDP) initiated a task for it under their Integrated System Health Management (ISHM) research area. This task, referred to as the FDIIR project, is a multi-year multi-center effort. The primary purpose of the FDIR project is to develop a prototype and pathway upon which Fault Detection and Isolation (FDI) may be transitioned into the Ground Operations baseline. Currently, Qualtech Systems Inc (QSI) Commercial Off The Shelf (COTS) software products Testability Engineering and Maintenance System (TEAMS) Designer and TEAMS RDS/RT are being utilized in the implementation of FDI within the FDIR project. The TEAMS Designer COTS software product is being utilized to model the system with Functional Fault Models (FFMs). A limited set of systems in Ground Operations are being modeled by the FDIR project, and the entire Ares Launch Vehicle is being modeled under the Functional Fault Analysis (FFA) project at Marshall Space Flight Center (MSFC). Integration of the Ares FFMs and the Ground Processing FFMs is being done under the FDIR project also utilizing the TEAMS Designer COTS software product. One of the most significant challenges related to integration is to ensure that FFMs developed by different organizations can be integrated easily and without errors. Software Interface Control Documents (ICDs) for the FFMs and their usage will be addressed as the solution to this issue. In particular, the advantages and disadvantages of these ICDs across physically separate development groups will be delineated.

Ferrell, Bob A.↗

NASA NTRS2009

Architectural Analysis of Complex Evolving Systems of Systems

The goal of this collaborative project between FC-MD, APL, and GSFC and supported by NASA IV&V Software Assurance Research Program (SARP), was to develop a tool, Dynamic SAVE, or Dyn-SAVE for short, for analyzing architectures of systems of systems. The project team was comprised of the principal investigator (PI) from FC-MD and four other FC-MD scientists (part time) and several FC-MD students (full time), as well as, two APL software architects (part time), and one NASA POC (part time). The PI and FC-MD scientists together with APL architects were responsible for requirements analysis, and for applying and evaluating the Dyn-SAVE tool and method. The PI and a group of FC-MD scientists were responsible for improving the method and conducting outreach activities, while another group of FC-MD scientists were responsible for development and improvement of the tool. Oversight and reporting was conducted by the PI and NASA POC. The project team produced many results including several prototypes of the Dyn-SAVE tool and method, several case studies documenting how the tool and method was applied to APL s software systems, and several published papers in highly respected conferences and journals. Dyn-SAVE as developed and enhanced throughout this research period, is a software tool intended for software developers and architects, software integration testers, and persons who need to analyze software systems from the point of view of how it communicates with other systems. Using the tool, the user specifies the planned communication behavior of the system modeled as a sequence diagram. The user then captures and imports the actual communication behavior of the system, which is then converted and visualized as a sequence diagram by Dyn-SAVE. After mapping the planned to the actual and specifying parameter and timing constraints, Dyn-SAVE detects and highlights deviations between the planned and the actual behavior. Requirements based on the need to analyze two inter-system communication protocols that are representative of protocols used in the Aerospace industry have been specified. The protocols are related: APL s Common Ground System (CGS) as used in the MErcury Surface, Space ENvironment, GEochemistry, and Ranging (MESSENGER) and the Radiation Belt Space Probes (RBSP) missions. The analyzed communications were implementations of the Telemetry protocol and the CCSDS File Delivery Protocol (CFDP) protocol. Based on these requirements, three prototypes of Dyn-SAVE were developed and applied to these protocols. The application of Dyn-SAVE to these protocols resulted in the detection of several issues. Dyn-SAVE was also applied to several Testbeds that have previously been used for experimentation earlier on this project, as well as, to other protocols and logs for testing its broader applicability. For example, Dyn-SAVE was used to analyze 1) the communication pattern between a web browser and a web server, 2) the system log of a computer in order to detect offnominal computer shut-down behavior, and 3) the actual test cases of NASA Goddard s Core Flight System (CFS) and automatically generated test cases in order to determine the overlap between the two sets of test cases. In all cases, Dyn-SAVE assisted in providing insightful conclusions about each of the cases identified above.

Lindvall, Mikael↗

NASA NTRS1984

A representational basis for the development of a distributed expert system for Space Shuttle flight control

A new representation of malfunction procedure logic which permits the automation of these procedures using Boolean normal forms is presented. This representation is discussed in the context of the development of an expert system for space shuttle flight control including software and hardware implementation modes, and a distributed architecture. The roles and responsibility of the flight control team as well as previous work toward the development of expert systems for flight control support at Johnson Space Center are discussed. The notion of malfunction procedures as graphs is introduced as well as the concept of hardware-equivalence.

Helly, J. J., Jr.↗

NASA NTRS2022

Run Time Assurance for Electric Vertical Takeoff and Landing Aircraft

NASA is conducting research to demonstrate and evaluate the application of Run Time Assurance (RTA) as a means to assure safety in Electric Vertical Takeoff and Landing (eVTOL) aircraft with highly automated or autonomous flight capability supervised by a single onboard pilot. The work described in this report demonstrates an application of RTA and examines the implications for design and analysis of aircraft functions and systems; aircraft safety hazards; safety assurance; development assurance; and pilot tasks and performance. This research effort also seeks to assess the efficacy of the combined application of traditional Functional Hazard Analysis (FHA) and the more modern System Theoretic Process Analysis (STPA) techniques to perform hazard analyses on aircraft with complex automated and autonomous systems and an onboard pilot. During the research effort we developed architectural designs of two alternate eVTOL aircraft, generally following the process characterized in the SAE standards ARP4754 and ARP4761. The design has focused on the control architectures of these aircraft, which are identical except that one incorporates RTA techniques to reduce the criticality of some key software components. Artifacts of this process include a taxonomy of aircraft-level functions, aircraft-level architecture diagrams, aircraft-level functional hazard assessments (AFHA), function allocations onto aircraft systems and subsystems, functional block diagrams for a select set of control-related functions, and system-level functional hazard assessments (SFHA) for those functions. This project has highlighted the notion that DAL D is something of a sweet spot for low-confidence controllers in an RTA-based design. Among the many activities described in DO-178C, the activities related to requirement verifiability, algorithmic accuracy, and test coverage can be the most challenging for the kinds of advanced control techniques that may be desirable in novel UAM designs, such as adaptive control, machine-learning, artificial intelligence, numerical search, and Monte Carlo based algorithms. Moreover, the standard requires that development teams demonstrate that errors leading to unacceptable failure conditions have been removed from the software. The RTA architecture, which cordons off the low-confidence function, makes it much easier to show this for these kinds of algorithms. With regard to the use of STPA and FHA as complementary hazard analysis techniques, our research effort led us to the conclusion that STPA should be used to derive requirements for hardware and software systems and/or components. Also, STPA is a natural complement to other processes in ARP4754A involving design studies and iteration.

Run-time assurance↗