Engineering topics
Publications and source records attributed to Crocker, Alan R..
Small spacecraft play a major role in earth, lunar, planetary, stellar, and interstellar discoveries. As technologies improve, instruments scale down in size, and their advantages in reduced cost and development time continue to attract investment, small satellites1 will play an even more important role. Today, the growth rate of small spacecraft utilization is limited by the availability of affordable launch opportunities.
This is a summary visualization of the LADEE mission from received telemetry.
Immersive simulation is a staple of training for many complex system operators, including astronauts and ground operators of spacecraft. However, while much has been written about simulators, simulation facilities, and operator certification programs, the topic of how one develops simulation scenarios to train a spacecraft operator is relatively understated in the literature. In this paper, an approach is presented for using control theory as the basis for developing the immersive simulation scenarios for a spacecraft operator training program. The operator is effectively modeled as a high level controller of lower level hardware and software control loops that affect a select set of system state variables. Simulation scenarios are derived from a STAMP-based hazard analysis of the operator's high and low level control loops. The immersive simulation aspect of the overall training program is characterized by selecting a set of scenarios that expose the operator to the various inadequate control actions that stem from control flaws and inadequate control executions in the different sections of the typical control loop. Results from the application of this approach to the Lunar Atmosphere and Dust Environment Explorer (LADEE) mission are provided through an analysis of the simulation scenarios used for operator training and the actual anomalies that occurred during the mission. The simulation scenarios and inflight anomalies are mapped to specific control flaws and inadequate control executions in the different sections of the typical control loop to illustrate the characteristics of anomalies arising from the different sections of the typical control loop (and why it is important for operators to have exposure to these characteristics). Additionally, similarities between the simulation scenarios and inflight anomalies are highlighted to make the case that the simulation scenarios prepared the operators for the mission.
Traditional software is developed as monolithic applications that are typed and create boundaries around their domains. ARC, working with JSC, developed an object oriented user interface that reduced domain boundaries in software. We used agile participatory design to develop a solution with our customer in mission control.
As we push toward new and diverse space transportation capabilities, reduction in operations cost will become increasingly important. Achieving affordable and safe human spaceflight capabilities will be the mark of success for new programs and new providers. This paper reviews NASA s history in developing and operating human rated spacecraft, reviewing the key aspects of spacecraft design and their resultant impacts on operations phase complexity and cost. Specific examples from current and past programs are provided to tie together early program requirements, design implementation and resulting real-time operations experience into a complete "story" of design decisions and operational results. Based on these experiences, recommended techniques are outlined to enable earlier and more effective assessment of operations concerns during the design process.
As we push toward new and diverse space transportation capabilities, reduction in operations cost becomes increasingly important. Achieving affordable and safe human spaceflight capabilities will be the mark of success for new programs and new providers. The ability to perceive the operational implications of design decisions is crucial in developing safe yet cost competitive space transportation systems. Any human spaceflight program - government or commercial - must make countless decisions either to implement spacecraft system capabilities or adopt operational constraints or workarounds to account for the lack of such spacecraft capabilities. These decisions can benefit from the collective experience that NASA has accumulated in building and operating crewed spacecraft over the last five decades. This paper reviews NASA s history in developing and operating human rated spacecraft, reviewing the key aspects of spacecraft design and their resultant impacts on operations phase complexity and cost. Specific examples from current and past programs - including the Space Shuttle and International Space Station - are provided to illustrate design traits that either increase or increase cost and complexity associated with spacecraft operations. These examples address factors such as overall design performance margins, levels of redundancy, degree of automated failure response, type and quantity of command and telemetry interfaces, and the definition of reference scenarios for analysis and test. Each example - from early program requirements, design implementation and resulting real-time operations experience - to tell the end-to-end "story" Based on these experiences, specific techniques are recommended to enable earlier and more effective assessment of operations concerns during the design process. A formal method for the assessment of spacecraft operability is defined and results of such operability assessments for recent spacecraft designs are provided. Recent experience in applying these techniques to Orion spacecraft development is reviewed to highlight the direct benefits of early operational assessment and collaborative development efforts.
In 2006, NASA Ames Research Center's (ARC) Intelligent Systems Division, and NASA Johnson Space Centers (JSC) Mission Operations Directorate (MOD) began a collaboration to move user applications for JSC's mission control center to a new software architecture, intended to replace the existing user applications being used for the Space Shuttle and the International Space Station. It must also carry NASA/JSC mission operations forward to the future, meeting the needs for NASA's exploration programs beyond low Earth orbit. Key requirements for the new architecture, called Mission Control Technologies (MCT) are that end users must be able to compose and build their own software displays without the need for programming, or direct support and approval from a platform services organization. Developers must be able to build MCT components using industry standard languages and tools. Each component of MCT must be interoperable with other components, regardless of what organization develops them. For platform service providers and MOD management, MCT must be cost effective, maintainable and evolvable. MCT software is built from components that are presented to users as composable user objects. A user object is an entity that represents a domain object such as a telemetry point, a command, a timeline, an activity, or a step in a procedure. User objects may be composed and reused, for example a telemetry point may be used in a traditional monitoring display, and that same telemetry user object may be composed into a procedure step. In either display, that same telemetry point may be shown in different views, such as a plot, an alpha numeric, or a meta-data view and those views may be changed live and in place. MCT presents users with a single unified user environment that contains all the objects required to perform applicable flight controller tasks, thus users do not have to use multiple applications, the traditional boundaries that exist between multiple heterogeneous applications disappear, leaving open the possibility of new operations concepts that are not constrained by the traditional applications paradigm.
The design of a human rated spacecraft is a complex and costly process requiring the integrated assessment of many individual criteria. Historically, it has been difficult to include in that integrated assessment the design s full impact on the flight operations community and its costs. The unique "operability requirements" have not been well understood, nor has there been a well-defined set of criteria for assessing operability. As a result, flight operations organizations and program managers are often faced with difficult and costly operations phase implementations. In response, the Mission Operations Directorate at NASA s Lyndon B. Johnson Space Center has established a formal technique to evaluate and communicate the operational characteristics of spacecraft system designs for the Constellation Program. This process is not intended to replace or replicate other critical assessments such as risk, reliability and safety assessments. Instead, this new technique adds to the assessment toolset a means to address the concerns and potential cost drivers that are unique to the operational phase of a program and the flight operations community. This paper describes the implementation and application of this "Spacecraft Flight Operability Assessment Scale" in supporting vehicle design efforts. The six key factors of flight operability are defined, with guiding principles and goals stated for each factor. A standardized rating technique provides feedback that is useful to both the operations and program management communities. Sample assessments of legacy spacecraft, including the Space Shuttle and International Space Station systems, are provided to provide real world examples of this technique s application.
While simulating a complex set of repair tasks to be performed by EVA crewmembers on an upcoming mission, flight controllers and astronauts determine that the repair will take much longer than originally anticipated. All equipment in the vicinity of the worksite must be powered off to maintain a safe environment for the astronauts. Because heater power will be unavailable, several critical components will now be at risk of freezing and permanent damage. If an impending thermal violation is detected, Mission Control will have very limited time to react. Therefore, flight controllers must not only modify their procedures to account for these risks, they must also incorporate into their displays outputs from thermal models, alternate temperature measurements, new alarm limits, and emergency power-on commands to enable the detection and response to freezing conditions. Current software for mission control systems makes scenarios like this difficult to address. Given the time frame for modifying software, operations teams are left with labor-intensive operational workarounds as their only options. NASA Ames Research Center (ARC) and NASA Johnson Space Center (JSC) are collaborating on the development of a flexible software system for mission operations that will enable greater user flexibility than has been available to date. Using composable software, end users in the scenario described above could recompose procedures and command and control displays to allow flight controllers to monitor temperature measurements, identify time-critical conditions, and execute the procedures required to respond to these conditions before flight hardware is permanently damaged.
The Purdue University Get Away Special Project (PUGAS) is a student-run organization dedicated to preparing payloads for flight on NASA's space shuttle. The first such payload (PUGAS I) flew on Challenger in 1983. The second payload (PUGAS II) should be ready by the end of 1988 and will include three experiments. The first experiment will involve the production of tin metal foam under microgravity conditions. The second experiment will focus on the desorption of water from carbon-epoxy composite materials. The third experiment will use a solid polymeric material to detect radiation in space.