Search NASA⌕ Search

SEARCH · Search NASA

Results for “Automated Functional 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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗
NASA NTRS1991

Optical studies in the holographic ground station

The Holographic Group System (HGS) Facility in rooms 22 & 123, Building 4708 has been developed to provide for ground based research in determining pre-flight parameters and analyzing the results from space experiments. The University of Alabama, Huntsville (UAH) has researched the analysis aspects of the HGS and reports their findings here. Some of the results presented here also occur in the Facility Operating Procedure (FOP), which contains instructions for power up, operation, and powerdown of the Fluid Experiment System (FES) Holographic Ground System (HGS) Test Facility for the purpose of optically recording fluid and/or crystal behavior in a test article during ground based testing through the construction of holograms and recording of videotape. The alignment of the optical bench components, holographic reconstruction and and microscopy alignment sections were also included in the document for continuity even though they are not used until after optical recording of the test article) setup of support subsystems and the Automated Holography System (AHS) computer. The HGS provides optical recording and monitoring during GCEL runs or development testing of potential FES flight hardware or software. This recording/monitoring can be via 70mm holographic film, standard videotape, or digitized images on computer disk. All optical bench functions necessary to construct holograms will be under the control of the AHS personal computer (PC). These include type of exposure, time intervals between exposures, exposure length, film frame identification, film advancement, film platen evacuation and repressurization, light source diffuser introduction, and control of realtime video monitoring. The completed sequence of hologram types (single exposure, diffuse double exposure, etc.) and their time of occurrence can be displayed, printed, or stored on floppy disk posttest for the user.

Workman, Gary L.↗
NASA NTRS2012

Mass Analyzers Facilitate Research on Addiction

The famous go/no go command for Space Shuttle launches comes from a place called the Firing Room. Located at Kennedy Space Center in the Launch Control Center (LCC), there are actually four Firing Rooms that take up most of the third floor of the LCC. These rooms comprise the nerve center for Space Shuttle launch and processing. Test engineers in the Firing Rooms operate the Launch Processing System (LPS), which is a highly automated, computer-controlled system for assembly, checkout, and launch of the Space Shuttle. LPS monitors thousands of measurements on the Space Shuttle and its ground support equipment, compares them to predefined tolerance levels, and then displays values that are out of tolerance. Firing Room operators view the data and send commands about everything from propellant levels inside the external tank to temperatures inside the crew compartment. In many cases, LPS will automatically react to abnormal conditions and perform related functions without test engineer intervention; however, firing room engineers continue to look at each and every happening to ensure a safe launch. Some of the systems monitored during launch operations include electrical, cooling, communications, and computers. One of the thousands of measurements derived from these systems is the amount of hydrogen and oxygen inside the shuttle during launch.

Source record↗
NASA NTRS1976

OAST Space Theme Workshop. Volume 3: Working group summary. 1: Navigation, guidance, control (E-1) A. Statement. B. Technology needs (form 1). C. Priority assessment (form 2)

The six themes identified by the Workshop have many common navigation guidance and control needs. All the earth orbit themes have a strong requirement for attitude, figure and stabilization control of large space structures, a requirement not currently being supported. All but the space transportation theme have need for precision pointing of spacecraft and instruments. In addition all the themes have requirements for increasing autonomous operations for such activities as spacecraft and experiment operations, onboard mission modification, rendezvous and docking, spacecraft assembly and maintenance, navigation and guidance, and self-checkout, test and repair. Major new efforts are required to conceptualize new approaches to large space antennas and arrays that are lightweight, readily deployable, and capable of precise attitude and figure control. Conventional approaches offer little hope of meeting these requirements. Functions that can benefit from increasing automation or autonomous operations are listed.

Source record↗
NASA NTRS1996

Experimental Optimization Methods for Multi-Element Airfoils

A modern three element airfoil model with a remotely activated flap was used to investigate optimum flap testing position using an automated optimization algorithm in wind tunnel tests. Detailed results for lift coefficient versus flap vertical and horizontal position are presented for two angles of attack: 8 and 14 degrees. An on-line first order optimizer is demonstrated which automatically seeks the optimum lift as a function of flap position. Future work with off-line optimization techniques is introduced and aerodynamic hysteresis effects due to flap movement with flow on are discussed.

Landman, Drew↗
NASA NTRS1985

Development of an Expert System for Representing Procedural Knowledge

A high level of automation is of paramount importance in most space operations. It is critical for unmanned missions and greatly increases the effectiveness of manned missions. However, although many functions can be automated by using advanced engineering techniques, others require complex reasoning, sensing, and manipulatory capabilities that go beyond this technology. Automation of fault diagnosis and malfunction handling is a case in point. The military have long been interested in this problem, and have developed automatic test equipment to aid in the maintenance of complex military hardware. These systems are all based on conventional software and engineering techniques. However, the effectiveness of such test equipment is severely limited. The equipment is inflexible and unresponsive to the skill level of the technicians using it. The diagnostic procedures cannot be matched to the exigencies of the current situation nor can they cope with reconfiguration or modification of the items under test. The diagnosis cannot be guided by useful advice from technicians and, when a fault cannot be isolated, no explanation is given as to the cause of failure. Because these systems perform a prescribed sequence of tests, they cannot utilize knowledge of a particular situation to focus attention on more likely trouble spots. Consequently, real-time performance is highly unsatisfactory. Furthermore, the cost of developing test software is substantial and time to maturation is excessive. Significant advances in artificial intelligence (AI) have recently led to the development of powerful and flexible reasoning systems, known as expert or knowledge-based systems. We have devised a powerful and theoretically sound scheme for representing and reasoning about procedural knowledge.

Georgeff, Michael P.↗
NASA NTRS2018

Ground Software Technologies – Embracing Change: Mission Drivers and Technology Opportunities to Enable Long Lived Missions

Mission lifecycles have proven to extend well beyond their original design. The benefits to this are countless but introduce challenges in today’s rapidly changing ground infrastructure and software technologies used to enable mission success. What remains constant is the risk posture missions maintain when accepting change and the use of new technologies. Larger missions are ready for change in early lifecycle development but near launch and especially in operations, few continue to evolve beyond what is set in place in phase C. This paper will discuss how the Advance Multi-Mission Operations System (AMMOS) intends to address, three driving missions concerns: Maintaining functionality (hardware/software) for decades, rapidly responding to security vulnerabilities in software, and finally the ability to quickly evolve infrastructure and software changes. These driving concerns are briefly described below: 1. Maintaining functionality (hardware/software) for decades. Hardware updates considerably faster than 10 years ago. Expectations that a system can remain in place for more than 10 years is no longer valid. Expecting to find hardware replacements for a system older than 5 years will increasingly become more and more challenging. How than do missions plan for hardware changes for long lived missions? Principle Objective: Provide abstraction by virtualizing and containerizing software abstract away any hardware dependencies and package up the application lightweight units. 2. Rapidly responding to security vulnerabilities in software. Cost is often the main impediment and largely driven by the revalidation and testing of system that undergo change. In todays, environment security updates are a major diver demanding systems remain up to date. How then do missions accept these changes and avoid large testing efforts? Principle Objective: Help reduce the cost of re-testing by automation of testing, deployment, and compartmentalizing change. 3. Ability to quickly evolve infrastructure and software changes. Responding quickly to change is similar to the second concern in this paper regarding security vulnerabilities. In this case, it address broader concerns of updating software and infrastructure on a more realistic timeline. How do missions stay up to date with the most recent versions of software and allowing for improved functionality? Principle Objective: Use continuous integration techniques at the system level to ensure rapid turnaround. This paper explores each of these concerns in more detail. It focuses the AMMOS’s current plans, challenges and current roadmap.

Giovannoni, Brian J.↗
NASA NTRS1987

Stability of IRA-45 solid amine resin as a function of carbon dioxide absorption and steam desorption cycling

The removal of CO2 from the NASA Space Station's cabin atmosphere, which may be undertaken by a solid-amine water (steam)-desorbed system, is presently evaluated with a view to long-term amine resin stability and adsorption/desorption cycling by means of an automated laboratory flow-testing facility. While the CO2-adsorption capacity of the IRA-45 amine resin used gradually decreased over time, the rate of degradation significantly decreased after the first 10 cycles. Attention is given to the presence (and possible need for removal) of trimethylamine in the process air downstream of the resin bed.

Wood, Peter C.↗
NASA NTRSDate not supplied

cFS Test Framework (CTF)

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

Aly I Shehata↗
NASA NTRS1998

Orbital Fluid Transfer System

An automated fluid and power interface system needs to be developed for future space missions which require on orbit consumable replenishment. Current method of fluid transfer require manned vehicles and extravehicular activity. Currently the US does not have an automated capability for consumable transfer on-orbit. This technology would benefit both Space Station and long duration satellites. In order to provide this technology the Automated Fluid Interface System (AFIS) was developed. The AFIS project was an advanced development program aimed at developing a prototype satellite servicer for future space operations. This mechanism could transfer propellants, cryogens, fluids, gasses, electrical power, and communications from a tanker unit to the orbiting satellite. The development of this unit was a cooperative effort between Marshall Space Flight Center in Huntsville, Alabama, and Moog, Inc. in East Aurora, New York. An engineering model was built and underwent substantial development testing at Marshall Space Flight Center (MSFC). While the AFIS is not suitable for spaceflight, testing and evaluation of the AFIS provided significant experience which would be beneficial in building a flight unit. The lessons learned from testing the AFIS provided the foundation for the next generation fluid transfer mechanism, the Orbital Fluid Transfer System (OFTS). The OFTS project was a study contract with MSFC and Moog, Inc. The OFTS was designed for the International Space Station (ISS), but its flexible design could used for long duration satellite missions and other applications. The OFTS was designed to be used after docking. The primary function was to transfer bipropellants and high pressure gases. The other items addressed by this task included propellant storage, hardware integration, safety and control system issues. A new concept for high pressure couplings was also developed. The results of the AFIS testing provided an excellent basis for the OFTS design. The OFTS meet the servicing requirements for ISS and could also provide the automated fluid and power interface system needed for on orbit consumable resupply of spacecraft into the new century.

Johnston, A. S., (Nick)↗
NASA NTRS1990

Expert systems and advanced automation for space missions operations

Increased complexity of space missions during the 1980s led to the introduction of expert systems and advanced automation techniques in mission operations. This paper describes several technologies in operational use or under development at the National Aeronautics and Space Administration's Goddard Space Flight Center. Several expert systems are described that diagnose faults, analyze spacecraft operations and onboard subsystem performance (in conjunction with neural networks), and perform data quality and data accounting functions. The design of customized user interfaces is discussed, with examples of their application to space missions. Displays, which allow mission operators to see the spacecraft position, orientation, and configuration under a variety of operating conditions, are described. Automated systems for scheduling are discussed, and a testbed that allows tests and demonstrations of the associated architectures, interface protocols, and operations concepts is described. Lessons learned are summarized.

Durrani, Sajjad H.↗
NASA NTRS2004

Using Generative Representations to Evolve Robots

Recent research has demonstrated the ability of evolutionary algorithms to automatically design both the physical structure and software controller of real physical robots. One of the challenges for these automated design systems is to improve their ability to scale to the high complexities found in real-world problems. Here we claim that for automated design systems to scale in complexity they must use a representation which allows for the hierarchical creation and reuse of modules, which we call a generative representation. Not only is the ability to reuse modules necessary for functional scalability, but it is also valuable for improving efficiency in testing and construction. We then describe an evolutionary design system with a generative representation capable of hierarchical modularity and demonstrate it for the design of locomoting robots in simulation. Finally, results from our experiments show that evolution with our generative representation produces better robots than those evolved with a non-generative representation.

Hornby, Gregory S.↗
NASA NTRS2008

Aquarius's Instrument Science Data System (ISDS) Automated to Acquire, Process, Trend Data and Produce Radiometric System Assessment Reports

The Aquarius Radiometer, a subsystem of the Aquarius Instrument required a data acquisition ground system to support calibration and radiometer performance assessment. To support calibration and compose performance assessments, we developed an automated system which uploaded raw data to a ftp server and saved raw and processed data to a database. This paper details the overall functionalities of the Aquarius Instrument Science Data System (ISDS) and the individual electrical ground support equipment (EGSE) which produced data files that were infused into the ISDS. Real time EGSEs include an ICDS Simulator, Calibration GSE, Labview controlled power supply, and a chamber data acquisition system. ICDS Simulator serves as a test conductor primary workstation, collecting radiometer housekeeping (HK) and science data and passing commands and HK telemetry collection request to the radiometer. Calibration GSE (Radiometer Active Test Source) provides source choice from multiple targets for the radiometer external calibration. Power Supply GSE, controlled by labview, provides real time voltage and current monitoring of the radiometer. And finally the chamber data acquisition system produces data reflecting chamber vacuum pressure, thermistor temperatures, AVG and watts. Each GSE system produce text based data files every two to six minutes and automatically copies the data files to the Central Archiver PC. The Archiver PC stores the data files, schedules automated uploads of these files to an external FTP server, and accepts request to copy all data files to the ISDS for offline data processing and analysis. Aquarius Radiometer ISDS contains PHP and MATLab programs to parse, process and save all data to a MySQL database. Analysis tools (MATLab programs) in the ISDS system are capable of displaying radiometer science, telemetry and auxiliary data in near real time as well as performing data analysis and producing automated performance assessment reports of the Aquarius Radiometer.

Source record↗
NASA NTRS2012

Model-Based Fault Diagnosis: Performing Root Cause and Impact Analyses in Real Time

Generic, object-oriented fault models, built according to causal-directed graph theory, have been integrated into an overall software architecture dedicated to monitoring and predicting the health of mission- critical systems. Processing over the generic fault models is triggered by event detection logic that is defined according to the specific functional requirements of the system and its components. Once triggered, the fault models provide an automated way for performing both upstream root cause analysis (RCA), and for predicting downstream effects or impact analysis. The methodology has been applied to integrated system health management (ISHM) implementations at NASA SSC's Rocket Engine Test Stands (RETS).

Figueroa, Jorge F.↗
NASA NTRS1989

Expert systems for automated maintenance of a Mars oxygen production system

A prototype expert system was developed for maintaining autonomous operation of a Mars oxygen production system. Normal operation conditions and failure modes according to certain desired criteria are tested and identified. Several schemes for failure detection and isolation using forward chaining, backward chaining, knowledge-based and rule-based are devised to perform several housekeeping functions. These functions include self-health checkout, an emergency shut down program, fault detection and conventional control activities. An effort was made to derive the dynamic model of the system using Bond-Graph technique in order to develop the model-based failure detection and isolation scheme by estimation method. Finally, computer simulations and experimental results demonstrated the feasibility of the expert system and a preliminary reliability analysis for the oxygen production system is also provided.

Ash, Robert L.↗
NASA NTRS2013

Acoustic Emission Analysis Applet (AEAA) Software

NASA Glenn Research and NASA White Sands Test Facility have developed software supporting an automated pressure vessel structural health monitoring (SHM) system based on acoustic emissions (AE). The software, referred to as the Acoustic Emission Analysis Applet (AEAA), provides analysts with a tool that can interrogate data collected on Digital Wave Corp. and Physical Acoustics Corp. software using a wide spectrum of powerful filters and charts. This software can be made to work with any data once the data format is known. The applet will compute basic AE statistics, and statistics as a function of time and pressure (see figure). AEAA provides value added beyond the analysis provided by the respective vendors' analysis software. The software can handle data sets of unlimited size. A wide variety of government and commercial applications could benefit from this technology, notably requalification and usage tests for compressed gas and hydrogen-fueled vehicles. Future enhancements will add features similar to a "check engine" light on a vehicle. Once installed, the system will ultimately be used to alert International Space Station crewmembers to critical structural instabilities, but will have little impact to missions otherwise. Diagnostic information could then be transmitted to experienced technicians on the ground in a timely manner to determine whether pressure vessels have been impacted, are structurally unsound, or can be safely used to complete the mission.

Nichols, Charles T.↗
NASA NTRS2010

A Near-Term Concept for Trajectory Based Operations with Air/Ground Data Link Communication

An operating concept and required system components for trajectory-based operations with air/ground data link for today's en route and transition airspace is proposed. Controllers are fully responsible for separation as they are today, and no new aircraft equipage is required. Trajectory automation computes integrated solutions to problems like metering, weather avoidance, traffic conflicts and the desire to find and fly more time/fuel efficient flight trajectories. A common ground-based system supports all levels of aircraft equipage and performance including those equipped and not equipped for data link. User interface functions for the radar controller's display make trajectory-based clearance advisories easy to visualize, modify if necessary, and implement. Laboratory simulations (without human operators) were conducted to test integrated operation of selected system components with uncertainty modeling. Results are based on 102 hours of Fort Worth Center traffic recordings involving over 37,000 individual flights. The presence of uncertainty had a marginal effect (5%) on minimum-delay conflict resolution performance, and windfavorable routes had no effect on detection and resolution metrics. Flight plan amendments and clearances were substantially reduced compared to today s operations. Top-of-descent prediction errors are the largest cause of failure indicating that better descent predictions are needed to reliably achieve fuel-efficient descent profiles in medium to heavy traffic. Improved conflict detections for climbing flights could enable substantially more continuous climbs to cruise altitude. Unlike today s Conflict Alert, tactical automation must alert when an altitude amendment is entered, but before the aircraft starts the maneuver. In every other failure case tactical automation prevented losses of separation. A real-time prototype trajectory trajectory-automation system is running now and could be made ready for operational testing at an en route Center in 1-2 years.

McNally, David↗
NASA NTRS2023

BRAINSTACK – A Platform for Artificial Intelligence & Machine Learning Collaborative Experiments on a Nano-Satellite

As the space economy continues to expand through increasingly easy access to advanced and inexpensive technology, space missions themselves have become more ambitious with exploration targets growing ever distant while simultaneously requiring larger guidance and communication budgets. These conflicting desires of distance and control drive the need for advanced on-board intelligent decision making to reduce communication and control limitations by automating as many mission functions as possible in-situ. While the amount of research on such Artificial Intelligence and Machine Learning (AI/ML) software modules has grown exponentially, the capacity to experimentally validate such software modules in space in a rapid and inexpensive format has not. To this end, the Nano Orbital Workshop (NOW) group at NASA Ames Research Center has been at the forefront of performing initial flight evaluation tests of ‘commercially’ available bleeding-edge computational platforms via what is programmatically referred to as the BrainStack on the TechEdSat (TES-n) flight series. This on-orbit computational platform provides an evaluation laboratory where advanced software experiments are pre-loaded into memory prior to launch, then executed as payloads during mission operations with results reported back and program tweaks or new training sets uploaded as needed. Processors selected as part of the BrainStack are of ideal size, packaging, and power consumption for easy integration into a cube satellite structure. These experiments have included the evaluation of small, high-performance GPUs and, more recently, neuromorphic processors, in LEO operations. Neuromorphic processors are of particular interest due to their superior power efficiency over GPUs in intelligent automation applications. The first TES-n flight test of an Intel first-generation Loihi neuromorphic processor launched on TES-13, January 13, 2022, and continues to operate in orbit despite no significant modifications to harden the processor against the space environment. The Intel Loihi Gen-1 on TES-13 is characterized by a 14nm 128-core Spiking Neural Network (SNN) able to support on-chip training. The processor is packaged in the Kapoho Bay USB module, providing a relatively straight-forward interface to the bus avionics system. The Kapoho Bay was in turn managed by an Intel Pentium single-board computer to handle scheduling of the software application payloads and communications with the satellite’s primary computer. The recently released Intel Loihi Gen-2, able to support integer-valued spike payloads and produced using 7nm process, will form part of the continually evolving BrainStack in the upcoming three TES-n/NOW flights. The Kapoho Point unit will incorporate eight Loihi-2 processors, enabling neural networks of up to one million neurons and one billion synapsis. Additionally, it is planned to measure the radiation environment these processors experience to understand any degradation or computational artifacts caused by long term space radiation exposure on these novel architectures. This evolving flexible and collaborative environment involving various research teams across NASA and other organizations is intended to be a convenient orbital test platform from which many anticipated future space automation applications may be initially tested.

Artificial Intelligence↗