Search NASA⌕ Search

SEARCH · Search NASA

Results for “flight software 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 415 records · Page 23

Test/score/report: Simulation techniques for automating the test process

A Test/Score/Report capability is currently being developed for the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) system which will automate testing of the Goddard Space Flight Center (GSFC) Payload Operations Control Center (POCC) and Mission Operations Center (MOC) software in three areas: telemetry decommutation, spacecraft command processing, and spacecraft memory load and dump processing. Automated computer control of the acceptance test process is one of the primary goals of a test team. With the proper simulation tools and user interface, the task of acceptance testing, regression testing, and repeatability of specific test procedures of a ground data system can be a simpler task. Ideally, the goal for complete automation would be to plug the operational deliverable into the simulator, press the start button, execute the test procedure, accumulate and analyze the data, score the results, and report the results to the test team along with a go/no recommendation to the test team. In practice, this may not be possible because of inadequate test tools, pressures of schedules, limited resources, etc. Most tests are accomplished using a certain degree of automation and test procedures that are labor intensive. This paper discusses some simulation techniques that can improve the automation of the test process. The TASS system tests the POCC/MOC software and provides a score based on the test results. The TASS system displays statistics on the success of the POCC/MOC system processing in each of the three areas as well as event messages pertaining to the Test/Score/Report processing. The TASS system also provides formatted reports documenting each step performed during the tests and the results of each step. A prototype of the Test/Score/Report capability is available and currently being used to test some POCC/MOC software deliveries. When this capability is fully operational it should greatly reduce the time necessary to test a POCC/MOC software delivery, as well as improve the quality of the test process.

Hageman, Barbara H.↗

Avoiding Human Error in Mission Operations: Cassini Flight Experience

Operating spacecraft is a never-ending challenge and the risk of human error is ever- present. Many missions have been significantly affected by human error on the part of ground controllers. The Cassini mission at Saturn has not been immune to human error, but Cassini operations engineers use tools and follow processes that find and correct most human errors before they reach the spacecraft. What is needed are skilled engineers with good technical knowledge, good interpersonal communications, quality ground software, regular peer reviews, up-to-date procedures, as well as careful attention to detail and the discipline to test and verify all commands that will be sent to the spacecraft. Two areas of special concern are changes to flight software and response to in-flight anomalies. The Cassini team has a lot of practical experience in all these areas and they have found that well-trained engineers with good tools who follow clear procedures can catch most errors before they get into command sequences to be sent to the spacecraft. Finally, having a robust and fault-tolerant spacecraft that allows ground controllers excellent visibility of its condition is the most important way to ensure human error does not compromise the mission.

guidance and control↗

Space Communications and Navigation (SCaN) Network Simulation Tool Development and Its Use Cases

In this work, we focus on the development of a simulation tool to assist in analysis of current and future (proposed) network architectures for NASA. Specifically, the Space Communications and Navigation (SCaN) Network is being architected as an integrated set of new assets and a federation of upgraded legacy systems. The SCaN architecture for the initial missions for returning humans to the moon and beyond will include the Space Network (SN) and the Near-Earth Network (NEN). In addition to SCaN, the initial mission scenario involves a Crew Exploration Vehicle (CEV), the International Space Station (ISS) and NASA Integrated Services Network (NISN). We call the tool being developed the SCaN Network Integration and Engineering (SCaN NI&E) Simulator. The intended uses of such a simulator are: (1) to characterize performance of particular protocols and configurations in mission planning phases; (2) to optimize system configurations by testing a larger parameter space than may be feasible in either production networks or an emulated environment; (3) to test solutions in order to find issues/risks before committing more significant resources needed to produce real hardware or flight software systems. We describe two use cases of the tool: (1) standalone simulation of CEV to ISS baseline scenario to determine network performance, (2) participation in Distributed Simulation Integration Laboratory (DSIL) tests to perform function testing and verify interface and interoperability of geographically dispersed simulations/emulations.

Jennings, Esther↗

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a unique private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed along with evolution of the system in preparation for the second uncrewed test flight. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies.

Robert C. Dempsey↗

Verification of the Space Shuttle entry GN&C system

The certification procedures for the initial Shuttle flight are discussed. Particular attention is paid to the entry guidance, navigation, and control (GNC) verification, comprising tests, analysis, demonstration, inspection, and simulation. Flow diagrams for the verification and operational flight sequences are provided, along with a block diagram of the GNC circuitry interfaces. The development of the test matrix software for the GNC is outlined, noting the constant interplay between software verification and spacecraft reconfiguration to meet simulated performance requirements. Comparison of GNC performance predictions with actual entry flight data showed a good match in all performance areas except for sideslip excursions, bank overshoots, an area of transonic buffet, and an increased lift/drag ratio in the preflare to landing flight phase.

Van Hoften, J. D. A.↗

Flight Test Design and Implementation for Airspace Independent Surveillance Through a Distributed Ground Based Sensor Network

The paper presents a system architecture for distributed sensing, networking and computing, its hardware implementation, and execution of initial flight experiments to validate theoretical findings. It induces development of distributed sensing requirements, framework, and architecture, development of distributed ground node hardware prototypes, integration of all nodes and testing of baseline functionalities, integration of in-house developed perception, migration and tracking software packages, establishing flight scenario and flyable path for a selected UAS, flying the air vehicle along the path, recording sensors measurements, pre-processing them and transferring the resulting data to an optimal computing center. It also addresses the challenges related to pre-flight hardware calibration, clock synchronization, sensor registration and establishing a communication network. Sensors data processing results demonstrate the functionality of the presented distributed architecture and satisfactory performance of the applied technologies.

Target tracking↗

Flight Test Design and Implementation for Independent Surveillance of an Airspace Through a Distributed Ground Sensing Network

The paper presents a system architecture for distributed sensing, networking and computing, its hardware implementation, and execution of initial flight experiments to validate theoretical findings. It induces development of distributed sensing requirements, framework, and architecture, development of distributed ground node hardware prototypes, integration of all nodes and testing of baseline functionalities, integration of in-house developed perception, migration and tracking software packages, establishing flight scenario and flyable path for a selected UAS, flying the air vehicle along the path, recording sensors measurements, pre-processing them and transferring the resulting data to an optimal computing center. It also addresses the challenges related to pre-flight hardware calibration, clock synchronization, sensor registration and establishing a communication network. Sensors data processing results demonstrate the functionality of the presented distributed architecture and satisfactory performance of the applied technologies.

Distributed sensing↗

Autonomous Inspection of Electrical Transmission Structures with Airborne UV Sensors - NASA Report on Dominion Virginia Power Flights of November 2016

The report details test and measurement flights to demonstrate autonomous UAV inspection of high voltage electrical transmission structures. A UAV built with commercial, off-the-shelf hardware and software, supplemented with custom sensor logging software, measured ultraviolet emissions from a test generator placed on a low-altitude substation and a medium-altitude switching tower. Since corona discharge precedes catastrophic electrical faults on high-voltage structures, detection and geolocation of ultraviolet emissions is needed to develop a UAV-based self-diagnosing power grid. Signal readings from an onboard ultraviolet sensor were validated during flight with a commercial corona camera. Geolocation was accomplished with onboard GPS; the UAV position was logged to a local ground station and transmitted in real time to a NASA server for tracking in the national airspace.

Moore, Andrew J.↗

A Methodology for Flight-Time Identification of Helicopter-Slung Load Frequency Response Characteristics Using CIFER

Helicopter slung load operations are common in both military and civil contexts. The slung load adds load rigid body modes, sling stretching, and load aerodynamics to the system dynamics, which can degrade system stability and handling qualities, and reduce the operating envelope of the combined system below that of the helicopter alone. Further, the effects of the load on system dynamics vary significantly among the large range of loads, slings, and flight conditions that a utility helicopter will encounter in its operating life. In this context, military helicopters and loads are often qualified for slung load operations via flight tests which can be time consuming and expensive. One way to reduce the cost and time required to carry out these tests and generate quantitative data more readily is to provide an efficient method for analysis during the flight, so that numerous test points can be evaluated in a single flight test, with evaluations performed in near real time following each test point and prior to clearing the aircraft to the next point. Methodology for this was implemented at Ames and demonstrated in slung load flight tests in 1997 and was improved for additional flight tests in 1999. The parameters of interest for the slung load tests are aircraft handling qualities parameters (bandwidth and phase delay), stability margins (gain and phase margin), and load pendulum roots (damping and natural frequency). A procedure for the identification of these parameters from frequency sweep data was defined using the CIFER software package. CIFER is a comprehensive interactive package of utilities for frequency domain analysis previously developed at Ames for aeronautical flight test applications. It has been widely used in the US on a variety of aircraft, including some primitive flight time analysis applications.

Sahai, Ranjana↗

Integration Test and Evaluation (IT&E) Flight Test Series 6 Live Virtual Constructive - Distributed Environment (LVC-DE) Test Report

The goals of the Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) (also UAS-NAS) Project are to reduce the barriers for UAS access and its integration into the NAS. The UAS-NAS project and industry stakeholders conducted a series of flight tests integrating technologies from the Modeling & Simulation (M&S), Human Systems Integration (HSI), and Communication and Control (C2), and Integration, Test & Evaluation (IT&E) research areas. The last of the flight test series, Flight Test Series 6 (FT6) was conducted in late 2019 and focused on evaluating the interaction of the airborne non-cooperative surveillance system and the Detect and Avoid (DAA) technology. The DAA system generated conflict alert and guidance for pilots using a Research Ground Control System (RGCS) to avoid intruder aircraft. The conflict alerting and guidance information was presented on the RGCS’s display using symbology developed by the human factors team. The objective of FT6 was to investigate the interoperability of Low Size, Weight, and Power (Low SWaP) sensors with the DAA alerting, guidance, and display requirements. To support this goal, the distributed test environments (DTE) were developed at Ames Research Center (ARC) and Armstrong Flight Research Center (AFRC) and securely linked over a Virtual Private Network (VPN). These environments took advantage of existing Live Virtual Constructive (LVC) technologies to support research observation at both Centers with the insertion of live UAS and manned intruder aircraft into a simulated NAS environment with Air Traffic Control (ATC) and constructive manned aircraft. The experiment was distributed between AFRC flight operations and research facilities and the Distributed Simulation Research Laboratory (DSRL) and Software Development Laboratory (SDL) in building N243 at ARC. The Air Traffic Controller and pseudo pilots operated from the DSRL and SDL, respectively, using the Multi-Aircraft Control System (MACS). The test subject and researchers operated from the Research Ground Control Station (RGCS) at AFRC using the Vigilant Spirit Control Station (VSCS) and associated DAA software and displays. Flight Operation for the unmanned aircraft (UA) and manned intruder traffic was conducted at AFRC. Virtual traffic was managed by ARC. Voice distribution was accomplished using a combination of disparate communication systems at ARC and AFRC. The purpose of this document is to record the development, design, and execution of activities in support of the FT6 efforts from the perspective of the ARC IT&E team. Furthermore, the Armstrong IT&E team has published a thorough FT6 Test Report, with emphasis on flight test support, facilities and vehicle development; this report complements the Armstrong report. Analysis of collected FT6 data will be conducted and reported by the M&S and HSI teams and will be published in separate reports.

UAS-NAS↗

Flight Software Math Library

The flight software (FSW) math library is a collection of reusable math components that provides typical math utilities required by spacecraft flight software. These utilities are intended to increase flight software quality reusability and maintainability by providing a set of consistent, well-documented, and tested math utilities. This library only has dependencies on ANSI C, so it is easily ported. Prior to this library, each mission typically created its own math utilities using ideas/code from previous missions. Part of the reason for this is that math libraries can be written with different strategies in areas like error handling, parameters orders, naming conventions, etc. Changing the utilities for each mission introduces risks and costs. The obvious risks and costs are that the utilities must be coded and revalidated. The hidden risks and costs arise in miscommunication between engineers. These utilities must be understood by both the flight software engineers and other subsystem engineers (primarily guidance navigation and control). The FSW math library is part of a larger goal to produce a library of reusable Guidance Navigation and Control (GN&C) FSW components. A GN&C FSW library cannot be created unless a standardized math basis is created. This library solves the standardization problem by defining a common feature set and establishing policies for the library s design. This allows the libraries to be maintained with the same strategy used in its initial development, which supports a library of reusable GN&C FSW components. The FSW math library is written for an embedded software environment in C. This places restrictions on the language features that can be used by the library. Another advantage of the FSW math library is that it can be used in the FSW as well as other environments like the GN&C analyst s simulators. This helps communication between the teams because they can use the same utilities with the same feature set and syntax.

McComas, David↗

UAS Service Supplier Checkout: How UTM Confirmed Readiness of Flight Tests with UAS Service Suppliers

NASA collaborated with industry partners to develop and test the small Unmanned Aircraft System (sUAS) Traffic Management (UTM) research platform, a software prototype used for developing airspace integration requirements for sUAS operations. The lessons learned from these activities will help inform the Federal Aviation Administration (FAA) on what is needed to safely manage sUAS operations. A core component of the UTM platform is the UAS Service Supplier (USS), which acts as a communications bridge to meet the regulatory and operational requirements. As the UTM partners began USS flight tests, NASA found that it was difficult to get all USSs functioning at comparable quality levels to ensure successful flight tests. Also, NASA anticipated that the FAA would encounter similar challenges when they begin to register USSs for operational use. These realizations led to the development of USS Checkout, a set of processes and tools designed to increase flight test efficiency. We learned that a good USS Checkout process is balanced for simplicity versus test coverage, and is amenable to automation. We also learned that when USS Checkout is a USS prerequisite for flight tests, flight tests were more efficient and effective.

Smith, Irene Skupniewicz↗

Flight flutter testing technology at Grumman

Analysis techniques used in the automated telemetry station (ATS) for on line data reduction are encompassed in a broad range of software programs. Concepts that form the basis for the algorithms used are mathematically described. The control the user has in interfacing with various on line programs is discussed. The various programs are applied to an analysis of flight data which includes unimodal and bimodal response signals excited via a swept frequency shaker and/or random aerodynamic forces. A nonlinear response error modeling analysis approach is described. Preliminary results in the analysis of a hard spring nonlinear resonant system are also included.

Perangelo, H. J.↗

Descent and Landing Triggers for the Orion Multi-Purpose Crew Vehicle Exploration Flight Test-1

The Orion Multi-Purpose Crew Vehicle (MPCV) will perform a flight test known as Exploration Flight Test-1 (EFT-1) currently scheduled for 2014. One of the primary functions of this test is to exercise all of the important Guidance, Navigation, Control (GN&C), and Propulsion systems, along with the flight software for future flights. The Descent and Landing segment of the flight is governed by the requirements levied on the GN&C system by the Landing and Recovery System (LRS). The LRS is a complex system of parachutes and flight control modes that ensure that the Orion MPCV safely lands at its designated target in the Pacific Ocean. The Descent and Landing segment begins with the jettisoning of the Forward Bay Cover and concludes with sensing touchdown. This paper discusses the requirements, design, testing, analysis and performance of the current EFT-1 Descent and Landing Triggers flight software.

Bihari, Brian D.↗

Space Communication and Navigation SDR Testbed, Overview and Opportunity for Experiments

NASA has developed an experimental flight payload (referred to as the Space Communication and Navigation (SCAN) Test Bed) to investigate software defined radio (SDR) communications, networking, and navigation technologies, operationally in the space environment. The payload consists of three software defined radios each compliant to NASAs Space Telecommunications Radio System Architecture, a common software interface description standard for software defined radios. The software defined radios are new technology developments underway by NASA and industry partners launched in 2012. The payload is externally mounted to the International Space Station truss to conduct experiments representative of future mission capability. Experiment operations include in-flight reconfiguration of the SDR waveform functions and payload networking software. The flight system will communicate with NASAs orbiting satellite relay network, the Tracking and Data Relay Satellite System at both S-band and Ka-band and to any Earth-based compatible S-band ground station. The system is available for experiments by industry, academia, and other government agencies to participate in the SDR technology assessments and standards advancements.

Reinhart, Richard C.↗

Testing, Requirements, and Metrics

The criticality of correct, complete, testable requirements is a fundamental tenet of software engineering. Also critical is complete requirements based testing of the final product. Modern tools for managing requirements allow new metrics to be used in support of both of these critical processes. Using these tools, potential problems with the quality of the requirements and the test plan can be identified early in the life cycle. Some of these quality factors include: ambiguous or incomplete requirements, poorly designed requirements databases, excessive or insufficient test cases, and incomplete linkage of tests to requirements. This paper discusses how metrics can be used to evaluate the quality of the requirements and test to avoid problems later. Requirements management and requirements based testing have always been critical in the implementation of high quality software systems. Recently, automated tools have become available to support requirements management. At NASA's Goddard Space Flight Center (GSFC), automated requirements management tools are being used on several large projects. The use of these tools opens the door to innovative uses of metrics in characterizing test plan quality and assessing overall testing risks. In support of these projects, the Software Assurance Technology Center (SATC) is working to develop and apply a metrics program that utilizes the information now available through the application of requirements management tools. Metrics based on this information provides real-time insight into the testing of requirements and these metrics assist the Project Quality Office in its testing oversight role. This paper discusses three facets of the SATC's efforts to evaluate the quality of the requirements and test plan early in the life cycle, thus preventing costly errors and time delays later.

Rosenberg, Linda↗

Building a lifeboat: MSL’s uplink and installation campaign to restore a failing backup computer

Flight software updates are among the hardest andmost dangerous activities for the Mars Science Laboratory(MSL) Curiosity team. While danger is often mitigated bybackups, fallback strategies, and incremental installation withground-in-the-loop cycles which provide a safety net for theinstallation process, the software update described in this paperwas unable to use many of the common practices due to thenature of the fault addressed by the update. The MSL rover(landed August 2012) encountered a problem with one of itscomputer’s non-volatile storage chips in 2019, requiring a swapto its backup computer and an urgent software upgrade calledR-Hope. R-Hope, a lifeboat to be used in the event of primarycomputer issues, was written, tested, and sent to the rover inlightning speed of just 19 months. Multi-mission and teamcoordination allowed the 49 flight software image files to beuplinked to the rover over a 6-week period, using multiple pathsand backup options for speedy delivery. In the end, the RHopesoftware upgrade returned the computer to operation asa backup flight computer. The flight software transition wasdesigned to impact science return as little as possible, and installationplans included science activities for the majority of MSLinstruments. This paper describes the uplink and installationcampaigns for R-Hope, and discusses the notable lessons learnedby the operations team.

Byrne, DJ↗