This article is one of five papers on modeling and simulation (part two) to be presented exclusively on the web as part of the September 1999 JOM-e—the electronic supplement to JOM. The first part of this topic supplemented the August issue. The coverage was developed by Steven LeClair of the Materials Directorate, Air Force Research Laboratory, Wright-Patterson Air Force Base.
JOM-e Logo
The following article appears as part of JOM-e, 51 (9) (1999),
http://www.tms.org/pubs/journals/JOM/9909/Malin/Malin-9909.html

JOM is a publication of The Minerals, Metals & Materials Society

Modeling and Simulation, Part II: Overview

Using Hybrid Modeling for Testing Intelligent Software for Lunar-Mars Closed Life Support

Jane T. Malin
JOM-e Logo
TABLE OF CONTENTS
Intelligent software is being developed for closed life-support systems with biological components for human exploration of the moon and Mars. The intelligent software functions include planning/scheduling; reactive discrete control and sequencing; continuous-control management; and fault detection, diagnosis, and management of failures and errors. Four types of modeling information have been essential to system modeling and simulation to develop and test the software and to provide operational, model-based, what-if analyses: discrete-component operational and failure modes; continuous dynamic performance within component modes, modeled qualitatively or quantitatively; configuration of flows and power among components in the system; and operations activities and scenarios. CONFIG, a multipurpose, discrete-event simulation tool that integrates all four types of models for use throughout the engineering and operations life cycle, has been used to model components and systems involved in the production and transfer of oxygen and carbon dioxide in a plant-growth chamber and between that chamber and a habitation chamber with physicochemical systems for gas processing.

INTRODUCTION

Fuel production plants and closed life-support systems with biological components are being developed for human exploration of the moon and Mars. Hierarchical intelligent control software is being designed for autonomous operation of these processor systems that convert resources to products. The intelligent-control systems are composed of layers of functions, including planning/scheduling, reactive discrete control and sequencing, continuous-control management, and failure and error management. These systems accomplish four broad types of systems management: planning and scheduling for storing and transporting resources and products; discrete or continuous control of processes or processor performances; the execution of procedures and sequences for the discrete control of operational configurations and modes of processors and other components; and the management of instrumentation and control subsystems. Whether a system goal can be achieved or a hazard can be avoided, within some time and resources, depends on the capability both to establish an operating mode (often in the context of a supporting flow or power configuration) and to process or perform at a predicted rate within that target mode.

INTELLIGENT SOFTWARE FOR CONTROLLING LIFE-SUPPORT SYSTEMS

Figure 1
Figure 1. The product-gas transfer in the Phase III test.
In NASA's Lunar Mars Life Support Test Program (LMLSTP) Phase III's 90 day manned test, a three-tiered (3T) hierarchical autonomous-control architecture was tested.1 The 3T software provided integrated monitoring and control (IMC) of product gas transfer between a plant-growth chamber, a crew chamber, and an incinerator.2 The basic configuration of chambers for the test is shown in Figure 1. Four crew members lived in the 6 m chamber for 90 days. A physicochemical air revitalization system (ARS) in the chamber included a four-bed molecular sieve (4BMS) to remove CO2 from the chamber and a CO2 removal system (CRS) and O2 generation system (OGS) that worked together to add O2 to the chamber. The variable pressure growth chamber (VPGC) housed plant trays for growing staged crops of wheat. The airlock was connected to the VPGC and the incinerator. The incinerator periodically converted human waste and paper products into CO2 and H2O. The IMC software managed the configuration of the CO2 supply for transfer to the VPGC for plant photosynthesis and O2 production and managed the systems for concentrating, storing, and transferring the O2 produced by the plants.

The IMC software managed the configuration of the O2 supply for transfer to the airlock for incineration or to the crew chamber. The software flexibly reconfigured and transferred gas among multiple reservoirs in response to predicted needs, observed usage, and problems with the system elements.

The uppermost tier of the 3T software is a planner that handles the management of resources and products, and the middle tier is a sequencer that provides a reactive discrete-control layer that handles event-based control, sequencing, and procedures for managing operational configurations and operation phases.3 The planner can alter the sequencer's task agenda. The lowest tier—the skill manager—handles low-level control. The skill manager interfaces with both the sequencer and the hardware and manages the continuous performance of processors and the continuous-control systems. The discrete- and continuous-control layers and a user-interface layer can manage instrumentation and control subsystems.

HETEROGENEOUS MODELS

The layered approach provides several advantages, including modularity, separation of concerns, and support for multiple levels of intervention. However, these layers relate to distinct engineering approaches associated with the four types of system-management goals, and a conceptual framework is needed to integrate the diverse approaches. The system-management framework helps bridge the gap between conventional continuous models and analyses and discrete symbolic models for autonomous-systems control.4 In the LMLSTP case, the resources and products are CO2 and O2. To support planning and scheduling, systems of simplified processing-rate models are typically used to analyze resources and balances in scenarios. The LMLSTP processors are wheat plants, crew, the CRS/OGS, and the incinerator. Differential and algebraic models are used, based on analytic or empirical data, to support control and sizing analysis. To support managing configurations (e.g., flow paths, valves, pumps, fans, injectors, chambers, tanks, and processors) for operations, models are typically systems of connected state-transition models. To support managing instrumentation and control subsystems (gas concentration control, processor control, flow and pressure control, and valve control), state-transition models are used for modes of control or control regimes.

Four heterogeneous types of models have been essential for developing, testing, and maintaining intelligent-control software for space life-support systems and providing operational model-based what-if analyses: discrete functional operational and failure modes of components; continuous dynamic performance within component modes, modeled qualitatively or quantitatively; configurations of flows and power among components in the system; and operations activities, schedules, and scenarios. The CONFIG simulation tool has provided the necessary integration of all four types of models,5–8 making it a suitable testbed for dynamic, interactive, simulation-based testing of the LMLSTP IMC application of the 3T-layered control software.9

HYBRID DISCRETE-EVENT SIMULATION

CONFIG was developed to support design of systems and their operations and extends discrete-event simulation with capabilities for continuous-system modeling. The purpose of these enhancements is the application of discrete-event technology for model-based prediction to support the design and evaluation of intelligent software for control and fault management. Although discrete-event simulation has typically been used for stochastic analyses of scenarios, CONFIG simulations are deterministic for specific states and inputs.

CONFIG uses a state-transition-system formalism in a system model composed of a set of connected components, or devices, structured within a configuration or flow path. The direction of physical flows and the effects of flow reconfigurations are efficiently analyzed during simulations. Two of the basic building blocks of a CONFIG model are devices (e.g., pumps, valves, tanks, and condensers) and activities. Devices model the behavior of system-hardware components and activities model actions in procedures or software. Device relations represent the connections between system components. Activity-device relations are used to relate activities to system components for control and monitoring purposes.

The modular discrete-event modeling approach provides a framework for organizing and managing the application of more detailed knowledge. In device models, time-related behavior models are embedded within modes that are within state-transition systems. For example, two modes of a simple valve might be open and closed. The way a device interacts with connected devices can depend on the current mode. Failures can be modeled as modes or as factors that precipitate or prevent transitions. Transitions between device modes can be determined by control variables, variable changes propagated through interdevice connections, or changes in system flows. The model structure can be recomposed during a simulation as the direction and activation of interconnections changes.

Activity models are also state-transition models. Several levels of control can be modeled as activities (e.g., an activity might be used to control the positioning of a set of valves). States of activity models, called activity phases, have embedded control behaviors, which can represent discrete- or continuous-control regimes or elements of schedules or simulation scenarios.

Life-support-system applications require the accurate accounting of resource inventories transferred by continuous flow at variable rates to various locations within the modeled system. In CONFIG, two operators, Integrate and Apply-When, are used to periodically compute states or time advances that depend on continuous changes. The Apply-When operator calls external algebraic functions to determine the time advance for a rate-dependent event. The Integrate operator uses a discrete-time approach, providing periodic updates of variables based on a rate, which may be changed dynamically by external inputs. Complex behavior emerges from the interaction of devices that have simple models of internal continuous processes.

CONFIG provides an object-oriented and graphical environment for building models and managing simulation tests. This environment supports incremental model development, maintenance, and reuse.

VALIDATING AUTONOMOUS-CONTROL SOFTWARE

CONFIG simulations were used to validate IMC software that provided control during the LMLSTP Phase III 90 day manned test. IMC-sequencer software monitored and controlled the model rather than the skills layer and hardware. The model included diverse components and systems for processing O2 and CO2 gases in a plant-growth chamber, crew chamber, and incinerator, and for storing gases and transferring them between chambers.10 Figure 2 shows the product gas transfer (PGT) system model during a simulation. Rectangles are devices, and elongated ovals are activities. Modes are indicated by the text in the rectangles and ovals, or by icons that indicate device modes.

Figure 2
Figure 2. The product gas-transfer system model.
The modeled devices include the chambers, various gas processors that convert O2 to CO2 or vice versa, gas concentrators, and PGT hardware that directs and regulates flow and pressure. The modeled activities include discrete and continuous control of the hardware that directs and regulates flow and pressure, schedules for crops and human activities, and some manual procedures. The activity models represent control by the 3T planning or skills tiers, local controllers, or human operators. There are only two continuous feedback controllers in the 3T skills tier; the rest of the control is discrete, based on deadbands and schedules.

Simulation-based testing followed unit testing and hardware-integration testing by the software developers. The interactive simulation-based testing used multiple long-duration scenarios running at about 20 times real time. The testing verified software activities during nominal operations in a system context and tested software response to hardware problems and imbalances. The testing, which is documented in References 9 and 11, uncovered some software problems and some issues concerning software requirements. The most interesting issue was observed in the context of a complex interaction including elements of the crew chamber and the plant-growth chamber. It is not likely that this type of software problem would have been found during conventional software testing because it involved a sequence of interactions of multiple devices and controllers in the system that would be difficult to conceive of or emulate in conventional software testing.

During simulation tests, when the CO2 accumulator was depleted, the IMC software switched the source of CO2 from the accumulator to the facility supply as intended, except when the plant-chamber CO2 concentration was between the alert-low and alarm-low thresholds. When the plant-chamber CO2 concentration was below the alert-low level (1,000 ppm) and the CO2 accumulator on the crew chamber side was also at its alert-low limit (83 kPa), the IMC software failed to switch to the facility CO2 supply. The IMC software disabled the continuous flow into the plant chamber and gave control to the local CO2 controller in the plant chamber. The local controller then switched to the backup pulse-injection system to raise the CO2 level in the plant chamber. Because the IMC software had failed to switch the CO2 source from the accumulator to the facility supply, the backup system drew CO2 from the depleted accumulator. The CO2 level in the plant chamber continued to drop even with the backup system on.

CONCLUSION

The CONFIG models successfully represented the heterogeneous set of model types that were required for testing intelligent reactive control software. The full range of model representations was necessary for the test, especially for control and reconfiguration. For future programs, simulation-based validation testing will include more complete coverage of off-nominal scenarios. The strength of this type of simulation-based validation is the production of cascaded effects of events in a complex system to produce novel operational scenarios that intelligent software must handle. In a system as complex as the Phase III testbed, even a seemingly innocuous deviation from normal operating conditions may have more serious consequences than expected. This same type of simulation should also be used to support the analysis of operational scenarios to support requirements development. Reliability and safety engineers remind us that software problems are more often associated with a lack of system understanding or requirements errors than with coding errors. Dynamic, interactive simulation of this type can help obtain the right requirements for complex-systems management.

Current work includes CONFIG extensions to support interactive operator-in-the-loop evaluations of strategies for adjustable autonomy, which supports operator intervention at multiple levels when appropriate. An interface has been developed between CONFIG and the lowest skills layer of the autonomy software to support testing of all layers of the architecture. More models are being developed to support the engineering and operation of autonomous production plants for consumables on Mars.

References
1. P. Bonasso et al., "Experiences with an Architecture for Intelligent, Reactive Agents," J. Experimental and Theoretical AI, 9 (1997), pp. 237–256.
2. D. Schreckenghost et al., "Three Tier Architecture for Controlling Space Life Support Systems," Proc. IEEE Symposium on Intelligence in Automation and Robotics (IEEE, 1998).
3. R.J. Firby, The RAP Language Manual (Evanston, IL: Neodesic Corporation, 1997).
4. J.T. Malin, "Some Roles of Models in Monitoring and Control for BIO-Plex." SAE paper no. 981727 (Paper presented at the SAE 28th International Conference on Environmental Systems, Danvers, MA, 1998).
5. J.T. Malin, B.D. Basham, and R.A. Harris, "Use of Qualitative Models in Discrete Event Simulation for Analysis of Malfunctions in Continuous Processing Systems," Artificial Intelligence in Process Engineering, ed. M. Mavrovouniotis (San Diego, CA: Academic Press, 1990), pp. 37–79.
6. J.T. Malin and D.B. Leifker, "Functional Modeling with Goal-Oriented Activities for Analysis of Effects of Failures on Functions and Operations," Informatics & Telematics, 8(4) (1991), pp. 353–364.
7. J.T. Malin, D. Ryan, and L. Fleming, "CONFIG—Integrated Engineering of Systems and Their Operation," Proc. Fourth National Technology Transfer Conference (Houston, TX: NASA Conference Publication CP-3249, 1993), pp. 97–104.
8. J.T. Malin, D. Ryan, and L. Fleming, "Computer-Aided Operations Engineering with Integrated Models of Systems and Operations," Proc. Dual Use Space Technology Transfer Conference and Exhibition (Houston, TX: NASA Conference Publication CP-3263, 1994), pp. 455–461.
9. J.T. Malin, L. Fleming, and T. Hatfield, "Interactive Simulation-Based Testing of Product Gas Transfer Integrated Monitoring and Control Software for the Lunar Mars Life Support Phase III Test," SAE paper no. 981769 (Paper presented at the SAE 28th International Conference on Environmental Systems, Danvers, MA, 1998).
10. L. Fleming, T. Hatfield, and J. Malin, Simulation-Based Test of Gas Transfer Control Software: CONFIG Model of Product Gas Transfer System, Automation, Robotics and Simulation Division Report, AR&SD-98-017 (Houston, TX: NASA Johnson Space Center, 1998).
11. L. Fleming, T. Hatfield, and J. Malin, Simulation-Based Test of Gas Transfer Control Software: CONFIG Model of Product Gas Transfer System, Automation, Robotics and Simulation Division Report, AR&SD-98-018 (Houston, TX: NASA Johnson Space Center, 1998).

Jane T. Malin is with the Intelligent Systems Branch, Automation, Robotics and Simulation Division of NASA Johnson Space Center.

For more information, contact J.T. Malin, Intelligent Systems Branch, MC ER2, Automation, Robotics, and Simulation Division, NASA Johnson Space Center, Houston, Texas 77058-3696; e-mail malin@jsc.nasa.gov.

Copyright held by The Minerals, Metals & Materials Society, 1999

Direct questions about this or any other JOM page to jom@tms.org.

Search TMS Document Center Subscriptions Other Hypertext Articles JOM TMS OnLine