Search NASA⌕ Search

SEARCH · Search NASA

Results for “contingency control”

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 145 records · Page 8

Operational radiological support for the US manned space program

Radiological support for the manned space program is provided by the Space Radiation Analysis Group at NASA/JSC. This support ensures crew safety through mission design analysis, real-time space environment monitoring, and crew exposure measurements. Preflight crew exposure calculations using mission design information are used to ensure that crew exposures will remain within established limits. During missions, space environment conditions are continuously monitored from within the Mission Control Center. In the event of a radiation environment enhancement, the impact to crew exposure is assessed and recommendations are provided to flight management. Radiation dosimeters are placed throughout the spacecraft and provided to each crewmember. During a radiation contingency, the crew could be requested to provide dosimeter readings. This information would be used for projecting crew dose enhancements. New instrumentation and computer technology are being developed to improve the support. Improved instruments include tissue equivalent proportional counter (TEPC)-based dosimeters and charged particle telescopes. Data from these instruments will be telemetered and will provide flight controllers with unprecedented information regarding the radiation environment in and around the spacecraft. New software is being acquired and developed to provide 'smart' space environmental data displays for use by flight controllers.

Golightly, Michael J.↗

Pointing and control system design study for the space infrared telescope facility (SIRTF)

The design and performance of pointing and control systems for two space infrared telescope facility vehicles were examined. The need for active compensation of image jitter using the secondary mirror or other optical elements was determined. In addition, a control system to allow the telescope to perform small angle slews, and to accomplish large angle slews at the rate of 15 deg per minute was designed. Both the 98 deg and the 28 deg inclination orbits were examined, and spacecraft designs were developed for each. The results indicate that active optical compensation of line-of-sight errors is not necessary if the system is allowed to settle for roughly ten seconds after a slew maneuver. The results are contingent on the assumption of rigid body dynamics, and a single structural mode between spacecraft and telescope. Helium slosh for a half full 4000 liter tank was analyzed, and did not represent a major control problem.

Lorell, K. R.↗

Skylab experiment performance evaluation manual. Appendix B: Experiment M-415, thermal control coatings (MSFC)

Performance tests to determine the thermodynamic properties of thermal control coatings for application to the Skylab corollary experiments under preflight, inflight, and postflight conditions are described. Malfunction analyses and procedures for working around contingency situations are discussed. The specifications for various sensors and instruments are presented in tables of data.

Purushotham, K. S.↗

Results of prototype software development for automation of shuttle proximity operations

The effort involves demonstration of expert system technology application to Shuttle rendezvous operations in a high-fidelity, real-time simulation environment. The JSC Systems Engineering Simulator (SES) served as the test bed for the demonstration. Rendezvous applications were focused on crew procedures and monitoring of sensor health and trajectory status. Proximity operations applications were focused on monitoring, crew advisory, and control of the approach trajectory. Guidance, Navigation, and Control areas of emphasis included the approach, transition and stationkeeping guidance, and laser docking sensor navigation. Operator interface displays for monitor and control functions were developed. A rule-based expert system was developed to manage the relative navigation system/sensors for nominal operations and simple failure contingencies. Testing resulted in the following findings; (1) the developed guidance is applicable for operations with LVLH stabilized targets; (2) closing rates less than 0.05 feet per second are difficult to maintain due to the Shuttle translational/rotational cross-coupling; (3) automated operations result in reduced propellant consumption and plume impingement effects on the target as compared to manual operations; and (4) braking gates are beneficial for trajectory management. A versatile guidance design was demonstrated. An accurate proximity operations sensor/navigation system to provide relative attitude information within 30 feet is required and redesign of the existing Shuttle digital autopilot should be considered to reduce the cross-coupling effects. This activity has demonstrated the feasibility of automated Shuttle proximity operations with the Space Station Freedom. Indications are that berthing operations as well as docking can be supported.

Hiers, Hal↗

Airline Operations Aid

C Language Integrated Production System (CLIPS), a NASA-developed expert systems program, is used by American Airlines for three purposes: as a rapid prototyping tool; to develop production prototypes; and to develop production application. An example of the latter is CLIPS' use in "Hub S1AAshing," a knowledge based system that recommends contingency plans when severe schedule reductions must be made. Hub S1AAshing has replaced a manual, labor intensive process. It saves time and allows Operations Control Coordinators to handle more difficult situations. Because the system assimilates much of the information necessary to facilitate educated decision making, it minimizes negative impact in situations where it is impossible to operate all flights.

Source record↗

Automated Software for Manned 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 private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. 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. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

Automated Software for Manned 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 private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. 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. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

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 private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. 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. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

Development of a Two-Wheel Contingency Mode for the MAP Spacecraft

In the event of a failure of one of MAP's three reaction wheel assemblies (RWAs), it is not possible to achieve three-axis, full-state attitude control using the remaining two wheels. Hence, two of the attitude control algorithms implemented on the MAP spacecraft will no longer be usable in their current forms: Inertial Mode, used for slewing to and holding inertial attitudes, and Observing Mode, which implements the nominal dual-spin science mode. This paper describes the effort to create a complete strategy for using software algorithms to cope with a RWA failure. The discussion of the design process will be divided into three main subtopics: performing orbit maneuvers to reach and maintain an orbit about the second Earth-Sun libration point in the event of a RWA failure, completing the mission using a momentum-bias two-wheel science mode, and developing a new thruster-based mode for adjusting the inertially fixed momentum bias. In this summary, the philosophies used in designing these changes is shown; the full paper will supplement these with algorithm descriptions and testing results.

Starin, Scott R.↗

Apollo Soyuz mission planning and operations

The paper describes the Apollo Soyuz project from the points of view of working group organization, mission plan definition, joint operations concept, and mission preparation. The concept for joint operations considered contingency situations as well as nominal operations. Preparations for the joint flight included cooperative tracking tests and combined training of the flight crews and mission control personnel.

Frank, M. P., III↗

The design and fabrication of the Centaur neutral buoyancy trainer and related hardware

Two full scale mockups of the Centaur upper stage were designed, fabricated and delivered to NASA. One was the Centaur Weightless Environment Training Facility (WETF) trainer and the other was the Centaur 1-G mockup. The Centaur upper stage booster is designed to carry the spacecraft Galileo to Jupiter, and the spacecraft Ulysses to an orbit around the Sun after launch from the Space Shuttle. The flight vehicle has several Extravehicular Activity (EVA) contingency tasks that require crew training. This need for crew training generated the requirement for the Centaur WETF crew trainer, which is high fidelity in areas of expected crew interface. During the production of the Centaur WETF crew trainer, the need for a jumper cable from Centaur to the Orbiter was identified. This EVA contingency task would be the installation of a cable from the Orbiter cargo bay sill to various command data boxes on Centaur to allow crew control deployment should a failure occur. This task required the upgrading of volumetric boxes on the trainer to a high fidelity configuration including electrical connector installation and cable routing.

Ware, Alan S.↗

ECLS resupply for Space Station Freedom

The design of logistics carriers is presented emphasizing the use of cost-effective pressurized and nonpressurized versions to resupply consumable fluids and provide on-orbit support for the Space Station Freedom. The requirements for the Environmental Control and Life Support (ECLS) system include high-pressure oxygen and nitrogen as well as consumables that do not require pressurization. The nominal and contingency requirements are given for logistics carriers designed to support various mission scenarios by resupplying and servicing fluid systems on-orbit. The resulting design overview for the logistics carriers describes the cryogenic-nitrogen storage during launch and operation of the unpressurized version and the flexible payload-support capacity of the pressurized version. The carriers are characterized as lightweight and versatile, and the resupply of cryogenic nitrogen is a flight-proven capability.

Higginbotham, Keith↗

Multi-Maneuver Clohessy-Wiltshire Targeting

Orbital rendezvous involves execution of a sequence of maneuvers by a chaser vehicle to bring the chaser to a desired state relative to a target vehicle while meeting intermediate and final relative constraints. Intermediate and final relative constraints are necessary to meet a multitude of requirements such as to control approach direction, ensure relative position is adequate for operation of space-to-space communication systems and relative sensors, provide fail-safe trajectory features, and provide contingency hold points. The effect of maneuvers on constraints is often coupled, so the maneuvers must be solved for as a set. For example, maneuvers that affect orbital energy change both the chaser's height and downrange position relative to the target vehicle. Rendezvous designers use experience and rules-of-thumb to design a sequence of maneuvers and constraints. A non-iterative method is presented for targeting a rendezvous scenario that includes a sequence of maneuvers and relative constraints. This method is referred to as Multi-Maneuver Clohessy-Wiltshire Targeting (MM_CW_TGT). When a single maneuver is targeted to a single relative position, the classic CW targeting solution is obtained. The MM_CW_TGT method involves manipulation of the CW state transition matrix to form a linear system. As a starting point for forming the algorithm, the effects of a series of impulsive maneuvers on the state are derived. Simple and moderately complex examples are used to demonstrate the pattern of the resulting linear system. The general form of the pattern results in an algorithm for formation of the linear system. The resulting linear system relates the effect of maneuver components and initial conditions on relative constraints specified by the rendezvous designer. Solution of the linear system includes the straight-forward inverse of a square matrix. Inversion of the square matrix is assured if the designer poses a controllable scenario - a scenario where the the constraints can be met by the sequence of maneuvers. Matrices in the linear system are dependent on selection of maneuvers and constraints by the designer, but the matrices are independent of the chaser's initial conditions. For scenarios where the sequence of maneuvers and constraints are fixed, the linear system can be formed and the square matrix inverted prior to real-time operations. Example solutions are presented for several rendezvous scenarios to illustrate the utility of the method. The MM_CW_TGT method has been used during the preliminary design of rendezvous scenarios and is expected to be useful for iterative methods in the generation of an initial guess and corrections.

Dannemiller, David P.↗

Designing an Alternate Mission Operations Control Room

The Huntsville Operations Support Center (HOSC) is a multi-project facility that is responsible for 24x7 real-time International Space Station (ISS) payload operations management, integration, and control and has the capability to support small satellite projects and will provide real-time support for SLS launches. The HOSC is a serviceoriented/ highly available operations center for ISS payloads-directly supporting science teams across the world responsible for the payloads. The HOSC is required to endure an annual 2-day power outage event for facility preventive maintenance and safety inspection of the core electro-mechanical systems. While complete system shut-downs are against the grain of a highly available sub-system, the entire facility must be powered down for a weekend for environmental and safety purposes. The consequence of this ground system outage is far reaching: any science performed on ISS during this outage weekend is lost. Engineering efforts were focused to maximize the ISS investment by engineering a suitable solution capable of continuing HOSC services while supporting safety requirements. The HOSC Power Outage Contingency (HPOC) System is a physically diversified compliment of systems capable of providing identified real-time services for the duration of a planned power outage condition from an alternate control room. HPOC was designed to maintain ISS payload operations for approximately three continuous days during planned HOSC power outages and support a local Payload Operations Team, International Partners, as well as remote users from the alternate control room located in another building. This paper presents the HPOC architecture and lessons learned during testing and the planned maiden operational commissioning. Additionally, this paper documents the necessity of an HPOC capability given the unplanned HOSC Facility power outage on April 27th, 2011, as a result of the tornado outbreak that damaged the electrical grid to such a degree that significantly inhibited the Tennessee Valley Authority's ability to transmit electricity throughout the North Alabama region.

Montgomery, Patty↗

Designing an Alternate Mission Operations Control Room

The Huntsville Operations Support Center (HOSC) is a multi-project facility that is responsible for 24x7 real-time International Space Station (ISS) payload operations management, integration, and control and has the capability to support small satellite projects and will provide real-time support for SLS launches. The HOSC is a service-oriented/ highly available operations center for ISS payloads-directly supporting science teams across the world responsible for the payloads. The HOSC is required to endure an annual 2-day power outage event for facility preventive maintenance and safety inspection of the core electro-mechanical systems. While complete system shut-downs are against the grain of a highly available sub-system, the entire facility must be powered down for a weekend for environmental and safety purposes. The consequence of this ground system outage is far reaching: any science performed on ISS during this outage weekend is lost. Engineering efforts were focused to maximize the ISS investment by engineering a suitable solution capable of continuing HOSC services while supporting safety requirements. The HOSC Power Outage Contingency (HPOC) System is a physically diversified compliment of systems capable of providing identified real-time services for the duration of a planned power outage condition from an alternate control room. HPOC was designed to maintain ISS payload operations for approximately three continuous days during planned HOSC power outages and support a local Payload Operations Team, International Partners, as well as remote users from the alternate control room located in another building.

Montgomery, Patty↗

Feasibility Study of Two Candidate Reaction Wheel/thruster Hybrid Control Architecture Designs for the Cassini Spacecraft

As the first spacecraft to achieve orbit at Saturn in 2004, Cassini has collected science data throughout its four-year prime mission (2004-08), and has since been approved for a first and second extended mission through 2017. Cassini carries a set of three "fixed" reaction wheels and a backup reaction wheel (reaction wheel #4) is mounted on top of an articulable platform. If necessary, this platform could be articulated to orient the backup reaction wheel with the degraded wheel. The reaction wheels are used primarily for attitude control when precise and stable pointing of a science instrument such as the narrow angle camera is required. In 2001-02, reaction wheel #3 exhibited signs of bearing cage instability. As a result, reaction wheel #4 was articulated to align with reaction wheel #3. Beginning in July 2003, Cassini was controlled using wheel #1, #2, and #4. From their first use in the spring of 2000 until today, reaction wheels #1 and #2 have accumulated more than3.5 billions revolutions each. As such, in spite of very carefully management of the wheel spin rates by the mission operation team, there are some observed increases in the drag torque of the wheels' bearings. Hence, the mission operations team must prepare for the contingency scenario in which the reaction wheel #1 (in addition to wheel #3) had degraded. In this hypothetical fault scenario, the two remaining reaction wheels (#2 and #4) will not be able to provide precise and stable three-axis control of the spacecraft. In this study, we evaluate the feasibility of controlling Cassini using the two remaining reaction wheels and four thrusters to meet the science pointing requirements for two key science operational modes: the Optical Remote Sensing and Downlink, Fields, Particles, & Waves operation modes. The performance (e.g., pointing control error, pointing stability, hydrazine consumption rate, etc.) of the hybrid controllers in both operations scenarios will be compared with those achieved using an all-thruster controller design. Strength and weaknesses of the hybrid control architecture are assessed quantitatively.

Cassini↗

Teleoperator maneuvering system

The Teleoperator Maneuvering System (TMS) is a Shuttle launched, free-flying, remotely controlled reusable propulsive stage capable of performing spacecraft and payload placement services, retrieval functions, assembly/servicing support for large space systems, dexterous manipulator operations for planned or contingency satellite servicing, satellite viewing, and subsatellite science support. The basic TMS segments, subsystems and performance are described, beginning with the criteria and requirements derived from mission models. Examples of TMS benefits to the STS and user communities are demonstrated. TMS applications such as support and servicing of Space Station, materials processing and subsatellite missions are presented.

Turner, J. R.↗

Testing of Advanced Capabilities to Enable In-time Safety Management and Assurance for Future Flight Operations

In order to refine an initial Concept of Operations, explore Concepts of Use, and expose/validate requirements for future In-Time Aviation Safety Management Systems (IASMS), testing architectures were created, along with a set of capabilities and underlying information exchange protocols. These systems were conceived and developed based on hazards associated with two envisioned urban area flight domains: (1) highly autonomous small uncrewed aerial systems (sUAS) operating at low altitudes, and (2) highly autonomous air taxis. The initial scope of this development is described in [1]; this report provides an update, focusing on the subsequent developments and test activities. As stated in [1], it is important to note that there are many capabilities already in use by the industry (or soon to be in use) that will play critical roles in future IASMS designs. Those reported here were developed to address a gap in the current state-of-the-art regarding specific hazards/risks, and/or to allow for investigation of the interplay between and across hazard types — particularly regarding how overall safety risk can be reduced or managed effectively. Results of testing and development activities are organized by the operational phase wherein a particular capability would be employed (i.e., preflight, in-flight, and post-flight/off-line). Pre-flight: A set of capabilities were developed to help mitigate safety risk prior to flight (e.g., during flight and mission planning). Results of testing summarize (1) validation activities to raise the Technology Readiness Level (TRL) and (2) evaluation activities where the capabilities were applied to flight/mission planning procedures and used by operators/pilots. For the latter, flight plans were automatically assessed, and operators/pilots were notified of hazardous flight segments so as to enable adjustment of the flight plan and re-evaluation, and/or to better inform go/no-go decisions. Capabilities addressed hazards associated with power consumption, third-party risk, wind, navigation system performance, radiofrequency interference, and proximity to geo-spatial threats (e.g., buildings, trees, and no-fly zones). In-flight: Flight experiments tested capabilities that detect and respond to hazards encountered during flight. In the first series, safety hazards were monitored and assessed onboard, and system-generated mitigation maneuvers were recorded (but not acted upon by the vehicle). In the second series, mitigation maneuver commands directed the aircraft in response to safety hazards (i.e., auto-mitigation). The sUAS used for testing is described in full, as is the test architecture, which included commercial avionics, research avionics, and onboard software designed to detect, assess, and respond to hazards. The onboard system was designed as a run-time assurance framework, consistent with [2] and supportive of both supervisory and automated modes. The primary functions included: real-time risk assessment (RTRA), auto-pilot monitoring, constraint monitoring, and contingency select/triggering. RTRA performs integrated risk assessment considering data from several hazard-related monitors (e.g., battery, motors, navigation, communications, population density, and loss-of-control). Post-flight/off-line: Data monitored and recorded during flights can enable IASMS capabilities that execute after flights have completed (or “off-line”). These include: (1) the ability to identify anomalies and trends that may only be observable when comparing data spanning a number of similar flights; (2) the ability to update and validate pre-flight and in-flight capabilities and any underlying models to improve their performance; (3) the ability to report anomalies/off-nominals that may indicate design changes or maintenance actions are needed; and (4) the ability for humans involved in operations to report safety-relevant observations to help in understanding the flight data and/or the operational context of a flight. Progress on three such capabilities is summarized; the first investigates anomaly detection given a limited set of flight logs and applies an approach previously used for space operations. The second explores what could be identified using a larger set of flight logs, including from web-based forums where flight logs are posted by sUAS autopilot users. The third creates a new means of collecting information on UAS incidents and accidents via the Aviation Safety Reporting System (ASRS).

sUAS↗