Search NASA⌕ Search

SEARCH · Search NASA

Results for “automated command”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

Estimating Software Reliability for Space Launch Vehicles in Probabilistic Risk Assessment (PRA)

It is acutely recognized in the Probabilistic Risk assessment (PRA) field that software plays a defining role in overall system reliability for all modern systems across a wide variety of industries. Regardless if the software is embedded firmware for working components or elements, part of a Human-Machine-Interface, or automated command and control logic, the success of the software to fulfill its function under nominal and off-nominal environments will be a dominant contributor to system reliability. It is also recognized that software reliability prediction and estimation is one of the more challenging and questionable aspects of any PRA or system analyses due to the nature of software and its integration with physics based systems. Irrespective of this dichotomy, any incorporation of software reliability methods requires that the contributions are accountable, quantitative, and tractable. This paper provides a brief overview of software reliability methods, establishes some minimum requirements that the methods should incorporate for completeness, and provides a logic structure for applying software reliability. Model resolution will be discussed that supports current testing plans and trade studies. We will provide initial recommendations for use in the NASA PRA and present a future dynamic option for software and PRA. Space Launch Vehicle Software is recognized to be reliable in static conditions, yet relatively vulnerable to a set of failure modes in changing environments/flight phases. Two quantitative methods were chosen to incorporate software reliability into a Space Launch Vehicle PRA accounting for phase adjustments. One method predicts latent software failure using statistical methods, and the second provides estimates of coding errors and software operating system failures based on test and historical data, respectively. Software uncertainty will also be discussed. We determined that recommendations for PRA software reliability should be modeled at the software module level where multiple software components compose a module and combinations of the software architecture can lead to a functional failure.

Novack, Steven↗
NASA NTRS2018

Estimating Software Reliability for Space Launch Vehicles in Probabilistic Risk Assessment (PRA)

It is acutely recognized in the Probabilistic Risk Assessment (PRA) field that software plays a defining role in overall system reliability for all modern systems across a wide variety of industries. Regardless of whether the software is embedded firmware for working components or elements, part of a Human-Machine-Interface, or automated command and control logic, the success of the software to fulfill its function under nominal and off-nominal environments will be a dominant contributor to system reliability. It is also recognized that software reliability prediction and estimation is one of the more challenging and questionable aspects of any PRA or system analyses due to the nature of software and its integration with physics based systems. Irrespective of this dichotomy, any incorporation of software reliability methods requires that the contributions are accountable, quantitative, and tractable. This paper provides a brief overview of software reliability methods, establishes some minimum requirements that the methods should incorporate for completeness, and provides a logic structure for applying software reliability. Model resolution will be discussed that supports current testing plans and trade studies. We will provide initial recommendations for use in the National Aeronautics and Space Administration (NASA) PRA and present a future dynamic option for software and PRA. Space Launch Vehicle software is recognized to be reliable in static conditions, yet relatively vulnerable to a set of failure modes in changing environments/flight phases. Two quantitative methods were chosen to incorporate software reliability into a Space Launch Vehicle PRA accounting for phase adjustments. One method predicts latent software failure using statistical methods, and the second provides estimates of coding errors and software operating system failures based on test and historical data. Software uncertainty will also be discussed. It is determined that recommendations for PRA software reliability should be modeled at the software module level where multiple software components compose a module and combinations of the software architecture can lead to a functional failure.

Steven D. Novack↗
NASA NTRS2022

Space Communications Responsive to Events Across Missions (SCREAM): An Investigation of Network Solutions for Transient Science Space Systems

Space Communications Responsive to Events Across Missions (SCREAM): An Investigation of Network Solutions for Transient Science Space Systems The National Academies have prioritized the pursuit of new scientific discoveries using diverse and temporally coordinated measurements from multiple ground and space-based observatories. Networked communications can enable such measurements by connecting individual observatories and allowing them to operate as a cohesive and purposefully designed system. Timely data flows across terrestrial and space communications networks are required to observe transient scientific events and processes. Currently, communications to space-based observatories experience large latencies due to manual service reservation and scheduling procedures, intermittent signal coverage, and network capacity constraints. If space communications network latencies could be reduced, new discoveries about dynamic scientific processes could be realized. However, science mission and network planners lack a systematic framework for defining, quantifying and evaluating timely space data flow implementation options for transient scientific observation scenarios involving multiple ground and space-based observatories. This dissertation presents a model-based systems engineering approach to investigate and develop network solutions to meet the needs of transient science space systems. First, a systematic investigation of the current transient science operations of the National Aeronautics and Space Administration’s (NASA) Tracking and Data Relay Satellite (TDRS) space data network and the Neil Gehrels Swift Observatory resulted in a formal architectural model for transient science space systems. Two methods individual missions may use to achieve timely network services were defined, quantitatively modeled, and experimentally compared. Next, the architectural model was extended to describe two alternative ways to achieve timely and autonomous space data flows to multiple space-based observatories within the context of a purposefully designed transient science observation scenario. A quantitative multipoint space data flow modeling method based in queueing theory was defined. General system suitability metrics for timeliness, throughput, and capacity were specified to support the evaluation of alternative network data flow implementations. A hypothetical design study was performed to demonstrate the multipoint data flow modeling method and to evaluate alternative data flow implementations using TDRS. The merits of a proposed future TDRS broadcast service to implement multipoint data flows were quantified and compared to expected outcomes using the as-built TDRS network. Then, the architectural model was extended to incorporate commercial network service providers. Quantitative models for Globalstar and Iridium short messaging data services were developed based on publicly available sources. Financial cost was added to the set of system suitability metrics. The hypothetical design study was extended to compare the relative suitability of the as-built TDRS network with the commercial Globalstar and Iridium networks. Finally, results from this research are being applied by NASA missions and network planners. In 2020, Swift implemented the first automated command pipeline, increasing its expected gravitational wave follow-up detection rate by greater than 400%. Current NASA technology initiatives informed by this research will enable future space-based observatories to become interoperable sensing devices connected by a diverse ecosystem of network service providers.

Christopher J. Roberts↗
NASA NTRS2017

Spaceport Command and Control System Automated Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administrations (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This large system requires high quality testing that will properly measure the capabilities of the system. Automating the test procedures would save the project time and money. Therefore, the Electrical Engineering Division at Kennedy Space Center (KSC) has recruited interns for the past two years to work alongside full-time engineers to develop these automated tests, as well as innovate upon the current automation process.

LCS↗
NASA NTRS2017

Spaceport Command and Control System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administrations (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This large system requires high quality testing that will properly measure the capabilities of the system. Automating the test procedures would save the project time and money. Therefore, the Electrical Engineering Division at Kennedy Space Center (KSC) has recruited interns for the past two years to work alongside full-time engineers to develop these automated tests, as well as innovate upon the current automation process.

Testing↗
NASA NTRS2012

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014. The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such a comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass, ground operations can still reduce mission costs through smaller staffing of operators and limiting their working hours. The challenge, then, for the SMAP GDS engineering team, is to formulate an automated operations strategy--and corresponding system architecture -- to minimize operator intervention during routine operations, while balancing the development costs associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS -- NASA's AMMOS Mission Data Processing and Control System (AMPCS) -- provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

soil moisture↗
NASA NTRS2012

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014.[double dagger] The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass ground operations can still reduce mission cost through smaller staffing of operators and limited work hours. The challenge, then, for the SMAP GDS engineering team is to formulate an automated operations strategy--and corresponding system architecture--to minimize operator intervention during operations, while balancing the development cost associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS--NASA's AMMOS Mission Data Processing and Control System (AMPCS)--provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

remote-sensing↗
NASA NTRS2019

Command and Control System Automated Testing

The Kennedy Space Center (KSC) has developed its own Command and Control System for the launch of the Space Launch System (SLS) and Orion capsule. The Command and Control System (CCS) is used by console engineers for the launch and system checkout of aerospace vehicles. The CCS allows console engineers to read data from the flight hardware on the launch pad and from the ground control systems and allows console engineers to issue commands, like opening a valve, to the flight hardware and ground control systems. The CCS needs to interact with thousands of devices and hardware controllers for the spacecraft and ground systems, receive data from these devices, distribute the data to console engineers in real-time, and allow console engineers to issue commands to manipulate hardware on the launch pad. The system needs to be robust, fault tolerant, responsive, and fast. In order to keep up with the pace of development of the CCS, a Test Automation System (TAS) is needed to validate the integrity of the system as a whole along with its individual components. Automated tests allow for faster development time, since tests can be ran through a Continuous Integration system and allow developers to check their code faster. Currently, the different modules, classes, and functions that make up the CCS are tested at the unit level, and the system level, with all the modules working together. My project was to implement a system for the data protocol layer of the Command Control System to be tested as a complete functional unit, with all of its classes and functions working together, but independent of the other modules of the CCS.

Automated TestingTest Automation↗
NASA NTRS2020

Command and Control System Automated Testing

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the pre-launch and launch operations. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The display software of the LCS is responsible for visualizing the various data that can be received from the hardware and software components of the LCS. Since this system is providing critical information to engineers in the firing room, the visualization of data across the system must be easy to understand, but also reliable and accurate.

Software↗
NASA NTRSDate not supplied

Timeline Assisted Commanding

The Timeline Assisted Commanding (TAC) application automates the execution of Ground Commanding Scripts based (GCS) on a pre-defined schedule of activities. It leverages the generic Data Planning and Control (DPAC) application for displaying planning events and scheduling their execution. TAC utilizes a database called Rosetta Stone to link scheduled activities with the required input parameters for commanding.

automation↗
NASA NTRS2020

Command and Control System Automated Testing

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket and the Orion capsule, designed to take humans back to the moon in 2024, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the launch. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The messaging software of LCS is responsible for handling the various data types that can be sent between the hardware and software components of the LCS. Since this system is interacting with numerous devices, controllers, and viewports in real time, the distribution of data across the system must be fast, but also reliable and accurate. To verify the accuracy and reliability of the system, developers on the project have created a set of tests to be performed that covers all operations allowed by the system. Given the extensive Application Programming Interface(API) provided by the messaging software, these unit tests are rather time-consuming and costly (in terms of man-hours) to perform. Therefore, an automated testing framework is used to perform supplemental tests automatically when updates are made to the code base.

Rebecca McFadden↗
NASA NTRS2017

Spaceport Command and Control System Automation Testing

The goal of automated testing is to create and maintain a cohesive infrastructure of robust tests that could be run independently on a software package in its entirety. To that end, the Spaceport Command and Control System (SCCS) project at the National Aeronautics and Space Administration's (NASA) Kennedy Space Center (KSC) has brought in a large group of interns to work side-by-side with full time employees to do just this work. Thus, our job is to implement the tests that will put SCCS through its paces.

Plano, Tom↗
NASA NTRS2017

Spaceport Command and Control System Automated Verification Software Development

For as long as we have walked the Earth, humans have always been explorers. We have visited our nearest celestial body and sent Voyager 1 beyond our solar system1 out into interstellar space. Now it is finally time for us to step beyond our home and onto another planet. The Spaceport Command and Control System (SCCS) is being developed along with the Space Launch System (SLS) to take us on a journey further than ever attempted. Within SCCS are separate subsystems and system level software, each of which have to be tested and verified. Testing is a long and tedious process, so automating it will be much more efficient and also helps to remove the possibility of human error from mission operations. I was part of a team of interns and full-time engineers who automated tests for the requirements on SCCS, and with that was able to help verify that the software systems are performing as expected.

Automation↗
NASA NTRS2008

Cassini's Maneuver Automation Software (MAS) Process: How to Successfully Command 200 Navigation Maneuvers

To keep Cassini on its complex trajectory, more than 200 orbit trim maneuvers (OTMs) have been planned from July 2004 to July 2010. With only a few days between many of these OTMs, the operations process of planning and executing the necessary commands had to be automated. The resulting Maneuver Automation Software (MAS) process minimizes the workforce required for, and maximizes the efficiency of, the maneuver design and uplink activities. The MAS process is a well-organized and logically constructed interface between Cassini's Navigation (NAV), Spacecraft Operations (SCO), and Ground Software teams. Upon delivery of an orbit determination (OD) from NAV, the MAS process can generate a maneuver design and all related uplink and verification products within 30 minutes. To date, all 112 OTMs executed by the Cassini spacecraft have been successful. MAS was even used to successfully design and execute a maneuver while the spacecraft was in safe mode.

Yang, Genevie Velarde↗
NASA NTRS1994

(abstract) Automated Constraint Checking of Spacecraft Command Sequences

Making certain that spacecraft command sequences do not violate any constraints is often tedious and expensive in terms of both personnel and software development. To reduce this cost, we have pursued the development of a flexible system for specifying models of spacecraft behavior in response to commands as well as constraints on that behavior. The potential need for modeling complex spacecraft behavior required that the system be designed to be usable both on a conventional workstation and a parallel supercomputer. Finally, it needed to be intuitive enough for the the intended mission operations users to easily design sets of rules and models to automate tedious, resource-consuming constraint checking of commands. We have defined a Specification And Verification Environment (SAVE) for spacecraft flight rules.

automation spacecraft command sequences constraint↗
NASA NTRS2012

Automated Operations Development for Advanced Exploration Systems

Automated space operations command and control software development and its implementation must be an integral part of the vehicle design effort. The software design must encompass autonomous fault detection, isolation, recovery capabilities and also provide "single button" intelligent functions for the crew. Development, operations and safety approval experience with the Timeliner system onboard the International Space Station (ISS), which provided autonomous monitoring with response and single command functionality of payload systems, can be built upon for future automated operations as the ISS Payload effort was the first and only autonomous command and control system to be in continuous execution (6 years), 24 hours a day, 7 days a week within a crewed spacecraft environment. Utilizing proven capabilities from the ISS Higher Active Logic (HAL) System, along with the execution component design from within the HAL 9000 Space Operating System, this design paper will detail the initial HAL System software architecture and interfaces as applied to NASA's Habitat Demonstration Unit (HDU) in support of the Advanced Exploration Systems, Autonomous Mission Operations project. The development and implementation of integrated simulators within this development effort will also be detailed and is the first step in verifying the HAL 9000 Integrated Test-Bed Component [2] designs effectiveness. This design paper will conclude with a summary of the current development status and future development goals as it pertains to automated command and control for the HDU.

Haddock, Angie T.↗