Engineering topics

Crocker, Alan

Publications and source records attributed to Crocker, Alan.

6 records

NASA NTRS2015

LADEE Preparations for Contingency Operations for the Lunar Orbit Insertion Maneuver

The Lunar Atmosphere and Dust Environment Explorer (LADEE) spacecraft was launched on September 7, 2013 UTC, and completed its mission on April 17, 2014 UTC with a directed impact to the Lunar Surface. Its primary goals were to examine the lunar atmosphere, measure lunar dust, and to demonstrate high rate laser communications. The mission objectives, much of which can be attributed to careful LADEE mission was a resounding success, achieving all planning and preparation. This paper discusses the specific preparations for fault conditions that could occur during a highly-critical phase of the mission, the Lunar Orbit Insertion (LOI). highly critical phase of the mission.

failure analysis↗

NASA NTRS2015

LADEE Preparations for Contingency Operations for the Lunar Orbit Insertion Maneuver

The Lunar Atmosphere and Dust Environment Explorer (LADEE) spacecraft was launched on September 6, 2013, and completed its mission on April 17, 2014 with a directed impact to the Lunar Surface. Its primary goals were to examine the lunar atmosphere, measure lunar dust, and to demonstrate high rate laser communications. The LADEE mission was a resounding success, achieving all mission objectives, much of which can be attributed to careful planning and preparation. This paper discusses the specific preparations for fault conditions that could occur during a highly-critical phase of the mission. To get to the Moon, the spacecraft traversed multiple phasing loops around the Earth, and then executed a breaking maneuver to achieve lunar orbit. This Lunar Orbit Insertion (LOI) maneuver was perhaps the most time-critical phase of the entire mission. The LOI maneuver had to occur within a twenty minute window in order to achieve lunar orbit with an acceptable amount of propellant remaining. Missing this window would have likely resulted in a loss of the entire mission. An additional challenge of the maneuver was that spacecraft was out of view for approximately one hour prior to the main thruster burn, with the burn needing to occur within five minutes after coming into view. These conditions resulted in unique challenges for ground operations and the fault management system. Early in the planning stages of the mission, the criticality and challenges of this maneuver were evident to the system designers. The major concern was that any triggering of the on-board fault management system, whether it is in response to a true fault or a false positive, would result in an unacceptable delay to the burn. Therefore the flight software was designed with a flexible fault management system, such that any or all of the fault management responses could be disabled for the lead up and execution of the maneuver. Later, a triage was conducted to develop a list of fault responses, mapped to various parts of the timeline of the maneuver. Some of these contingency responses were solely ground-based if the time to detect, diagnose, and respond were adequate. Other responses were automated on-board if the response time from the ground would have been inadequate. For instance, in order to recover from a system reboot, on-board automation would have automatically reconfigured the spacecraft for the burn and reoriented the spacecraft to the burn attitude.These contingency responses were practiced, over and over, during numerous rehearsals. Although the LOI maneuver was executed without having to use any of these contingencies, the LADEE team was adequately prepared for this highly critical phase of the mission.

Cannon, Howard↗

NASA NTRS2011

The Planning Execution Monitoring Architecture

The Planning Execution Monitoring (PEM) architecture is a design concept for developing autonomous cockpit command and control software. The PEM architecture is designed to reduce the operations costs in the space transportation system through the use of automation while improving safety and operability of the system. Specifically, the PEM autonomous framework enables automatic performance of many vehicle operations that would typically be performed by a human. Also, this framework supports varying levels of autonomous control, ranging from fully automatic to fully manual control. The PEM autonomous framework interfaces with the core flight software to perform flight procedures. It can either assist human operators in performing procedures or autonomously execute routine cockpit procedures based on the operational context. Most importantly, the PEM autonomous framework promotes and simplifies the capture, verification, and validation of the flight operations knowledge. Through a hierarchical decomposition of the domain knowledge, the vehicle command and control capabilities are divided into manageable functional "chunks" that can be captured and verified separately. These functional units, each of which has the responsibility to manage part of the vehicle command and control, are modular, re-usable, and extensible. Also, the functional units are self-contained and have the ability to plan and execute the necessary steps for accomplishing a task based upon the current mission state and available resources. The PEM architecture has potential for application outside the realm of spaceflight, including management of complex industrial processes, nuclear control, and control of complex vehicles such as submarines or unmanned air vehicles.

Wang, Lui↗

NASA NTRS2010

A Technique for the Assessment of Flight Operability Characteristics of Human Rated Spacecraft

In support of new human rated spacecraft development programs, the Mission Operations Directorate at NASA Johnson Space Center has implemented a formal method for the assessment of spacecraft operability. This "Spacecraft Flight Operability Assessment Scale" defines six key themes of flight operability, with guiding principles and goals stated for each factor. A standardized rating technique provides feedback that is useful to the operations, design and program management communities. Applicability of this concept across the program structure and life cycle is addressed. Examples of operationally desirable and undesirable spacecraft design characteristics are provided, as is a sample of the assessment scale product.

Crocker, Alan↗

NASA NTRS2006

ISHM Implementation for Constellation Systems

Integrated System Health Management (ISHM) is a capability that focuses on determining the condition (health) of every element in a complex System (detect anomalies, diagnose causes, prognosis of future anomalies), and provide data, information, and knowledge (DIaK) "not just data" to control systems for safe and effective operation. This capability is currently done by large teams of people, primarily from ground, but needs to be embedded on-board systems to a higher degree to enable NASA's new Exploration Mission (long term travel and stay in space), while increasing safety and decreasing life cycle costs of systems (vehicles; platforms; bases or outposts; and ground test, launch, and processing operations). This viewgraph presentation reviews the use of ISHM for the Constellation system.

Figueroa, Fernando↗

NASA NTRS2006

Fault Management Techniques in Human Spaceflight Operations

This paper discusses human spaceflight fault management operations. Fault detection and response capabilities available in current US human spaceflight programs Space Shuttle and International Space Station are described while emphasizing system design impacts on operational techniques and constraints. Preflight and inflight processes along with products used to anticipate, mitigate and respond to failures are introduced. Examples of operational products used to support failure responses are presented. Possible improvements in the state of the art, as well as prioritization and success criteria for their implementation are proposed. This paper describes how the architecture of a command and control system impacts operations in areas such as the required fault response times, automated vs. manual fault responses, use of workarounds, etc. The architecture includes the use of redundancy at the system and software function level, software capabilities, use of intelligent or autonomous systems, number and severity of software defects, etc. This in turn drives which Caution and Warning (C&W) events should be annunciated, C&W event classification, operator display designs, crew training, flight control team training, and procedure development. Other factors impacting operations are the complexity of a system, skills needed to understand and operate a system, and the use of commonality vs. optimized solutions for software and responses. Fault detection, annunciation, safing responses, and recovery capabilities are explored using real examples to uncover underlying philosophies and constraints. These factors directly impact operations in that the crew and flight control team need to understand what happened, why it happened, what the system is doing, and what, if any, corrective actions they need to perform. If a fault results in multiple C&W events, or if several faults occur simultaneously, the root cause(s) of the fault(s), as well as their vehicle-wide impacts, must be determined in order to maintain situational awareness. This allows both automated and manual recovery operations to focus on the real cause of the fault(s). An appropriate balance must be struck between correcting the root cause failure and addressing the impacts of that fault on other vehicle components. Lastly, this paper presents a strategy for using lessons learned to improve the software, displays, and procedures in addition to determining what is a candidate for automation. Enabling technologies and techniques are identified to promote system evolution from one that requires manual fault responses to one that uses automation and autonomy where they are most effective. These considerations include the value in correcting software defects in a timely manner, automation of repetitive tasks, making time critical responses autonomous, etc. The paper recommends the appropriate use of intelligent systems to determine the root causes of faults and correctly identify separate unrelated faults.

O'Hagan, Brian↗