**FINAL REPORT**

**Workshop on**

**Advanced System Integration and Control for Life Support**

**(ASICLS)**

Monterey Plaza Hotel

26 -- 28 August 2003

Monterey, CA

Issued: January, 2005

JPL clearance CL#05-0540

JPL document D-30410

Exploration Systems Mission Division

Life Support & Habitation Program

National Aeronautics and Space Administration

Washington, DC 20546-0001

######   {#section .unnumbered}

###### Table of Contents

1\. Preface [1](#preface)

1.1 Charter [1](#charter)

2\. Executive Summary [1](#executive-summary)

3\. Introduction AND BACKGROUND [3](#introduction-and-background)

3.1 Description of Advanced Life Support Systems
[3](#description-of-advanced-life-support-systems)

3.2 Description of Exploration Missions
[4](#description-of-exploration-missions)

4 Results and Discussion [5](#results-and-discussion)

4.1 Day One -- Presentations [5](#day-one-presentations)

4.2 Group 1: Ground-Based Human-Rated Test Facility
[6](#group-1-ground-based-human-rated-test-facility)

4.2.1 Day Two -- Breakout Sessions: Scenarios
[6](#day-two-breakout-sessions-scenarios)

4.2.1.1 Identification of Needs, Problems, and Challenges
[7](#identification-of-needs-problems-and-challenges)

4.2.1.2 Scenarios [7](#scenarios)

4.2.1.3 Discussion and Relevance [8](#discussion-and-relevance)

4.2.2 Day Three -- Breakout Sessions: Topics
[8](#day-three-breakout-sessions-topics)

4.2.2.1 Categorization of Problem Space
[9](#categorization-of-problem-space)

4.2.2.2 Identification of Solutions, Technologies, or Research Areas
[9](#identification-of-solutions-technologies-or-research-areas)

4.2.2.3 Existing Technologies Addressing a Particular Need
[10](#existing-technologies-addressing-a-particular-need)

4.2.2.4 Discussion and Relevance [10](#discussion-and-relevance-1)

4.3 Group 2: Mars Transit Vehicle [11](#group-2-mars-transit-vehicle)

4.3.1 Day Two -- Breakout Sessions: Scenarios
[11](#day-two-breakout-sessions-scenarios-1)

4.3.1.1 Identification of Needs, Problems, and Challenges
[11](#identification-of-needs-problems-and-challenges-1)

4.3.1.1.1 Programmatic Issues [12](#programmatic-issues)

4.3.1.1.2 Mission Architecture for Autonomy
[13](#mission-architecture-for-autonomy)

4.3.1.1.3 Control for Long-Term Operation
[14](#control-for-long-term-operation)

4.3.1.1.4 Human Issues [15](#human-issues)

4.3.2 Day Three -- Breakout Sessions: Topics
[15](#day-three-breakout-sessions-topics-1)

4.3.2.1 Integrated Systems Modeling [15](#integrated-systems-modeling)

4.3.2.2 Online Monitoring and Diagnosis
[16](#online-monitoring-and-diagnosis)

4.3.2.3 Control Systems Architecture for Integrated Control
[17](#control-systems-architecture-for-integrated-control)

4.3.2.4 Software Methodologies [17](#software-methodologies)

4.3.2.5 Integrating Human Expertise [17](#integrating-human-expertise)

4.3.2.6 Programmatic Issues [18](#programmatic-issues-1)

4.4 Group 3:  Martian Planetary Exploration
[18](#group-3-martian-planetary-exploration)

4.4.1 Day Two -- Breakout Sessions: Scenarios
[18](#day-two-breakout-sessions-scenarios-2)

4.4.1.1 Identified Needs Based on Scenario
[19](#identified-needs-based-on-scenario)

4.4.1.2 Identified Needs by Areas [20](#identified-needs-by-areas)

4.4.1.3 Finding Existing Technologies Applicable for Spaceflight
[23](#finding-existing-technologies-applicable-for-spaceflight)

4.4.2 Day Three -- Breakout Sessions -- Topics
[24](#day-three-breakout-sessions-topics-2)

4.4.2.1 Grouping of Identified Technologies by Topic
[24](#grouping-of-identified-technologies-by-topic)

4.4.2.1.1 System Design [24](#system-design)

4.4.2.1.2 System Operation and Control
[25](#system-operation-and-control)

4.4.2.1.3 Coordination and Integration of a Distributed Control System
[26](#coordination-and-integration-of-a-distributed-control-system)

4.4.2.1.4 Determining and Predicting System State and Diagnosing Faults
[27](#determining-and-predicting-system-state-and-diagnosing-faults)

4.4.2.1.5 Resource Management [27](#resource-management)

4.4.2.1.6 Human Interfaces [28](#human-interfaces)

4.5 Group 4: Mars Planetary Base [28](#group-4-mars-planetary-base)

4.5.1 Day Two -- Breakout Sessions: Scenarios
[28](#day-two-breakout-sessions-scenarios-3)

4.5.1.1 Identified Needs [28](#identified-needs)

4.5.1.1.1 Reliable Sensors [28](#reliable-sensors)

4.5.1.1.2 Early-Detection of Off-Normal Processes
[29](#early-detection-of-off-normal-processes)

4.5.1.1.3 Communication/Network (Earth - Vehicle & Devices - Vehicle)
[29](#communicationnetwork-earth---vehicle-devices---vehicle)

4.5.1.1.4 Crew Training [29](#crew-training)

4.5.1.1.5 Comprehension of Complex System Interaction/Compatibility
[30](#comprehension-of-complex-system-interactioncompatibility)

4.5.1.1.6 Management of Change [30](#management-of-change)

4.5.1.1.7 Transition Between Operational Stages
[30](#transition-between-operational-stages)

4.5.1.1.8 Common Technical Language and Symbology
[31](#common-technical-language-and-symbology)

4.5.1.1.9 Off-Nominal Data [31](#off-nominal-data)

4.5.1.1.10 Biomass Production Unit Robustness
[31](#biomass-production-unit-robustness)

4.5.1.1.11 Methodology to Proof Positive
[32](#methodology-to-proof-positive)

4.5.1.1.12 Useful, Appropriate Models for Every Component and the System
as a Whole
[32](#useful-appropriate-models-for-every-component-and-the-system-as-a-whole)

4.5.1.1.13 System Readiness Level (SRL)
[32](#system-readiness-level-srl)

4.5.1.1.14 Well Designed Experiments [32](#well-designed-experiments)

4.5.1.1.15 Tools/Resources for Testing/Validation of Processes and
Control strategies and for Technology Selection
[32](#toolsresources-for-testingvalidation-of-processes-and-control-strategies-and-for-technology-selection)

4.5.1.1.16 Standard Control Architecture
[33](#standard-control-architecture)

4.5.1.1.17 Selection and Assignment of Control Strategies/Decision
Processes
[33](#selection-and-assignment-of-control-strategiesdecision-processes)

4.5.1.1.18 Planetary Protection [33](#planetary-protection)

4.5.1.2 Existing Technologies be Adapted to Spaceflight
[33](#existing-technologies-be-adapted-to-spaceflight)

4.5.2 Day Three -- Breakout Sessions: Topics
[33](#day-three-breakout-sessions-topics-3)

4.5.2.1 Solutions [33](#solutions)

4.5.2.1.1 Good Data and Modeling (off-nominal/nonlinear interactions)
[34](#good-data-and-modeling-off-nominalnonlinear-interactions)

4.5.2.1.2 Information Processing and Decision Making/Support Algorithms
[35](#information-processing-and-decision-makingsupport-algorithms)

4.5.2.1.3 Process and System Design [35](#process-and-system-design)

4.5.2.1.4 Methodologies and Guidelines
[35](#methodologies-and-guidelines)

4.5.2.1.5 Things that Must be Managed/Supervised
[36](#things-that-must-be-managedsupervised)

4.5.2.1.6 Programmatic Decisions [36](#programmatic-decisions)

4.5.2.1.7 Human/Computer Interaction [36](#humancomputer-interaction)

4.6 Group 5: Ground-Based Human-Rated Test Facility and Mars Planetary
Base
[37](#group-5-ground-based-human-rated-test-facility-and-mars-planetary-base)

4.6.1 Day Two -- Breakout Sessions: Scenarios
[37](#day-two-breakout-sessions-scenarios-4)

4.6.1.1 Identification of Needs, Problems, and Challenges
[37](#identification-of-needs-problems-and-challenges-2)

4.6.2 Day Three -- Breakout Sessions: Addressing the Solutions
[40](#day-three-breakout-sessions-addressing-the-solutions)

4.6.2.1 Identification of Solutions, Technologies, or Research Areas
[40](#identification-of-solutions-technologies-or-research-areas-1)

4.6.2.2 Top Needs, Problems, and Challenges and Identification of
Solutions and Existing Technologies
[40](#top-needs-problems-and-challenges-and-identification-of-solutions-and-existing-technologies)

5 Conclusions [50](#conclusions)

5.1 Programmatic and Technical Findings
[50](#programmatic-and-technical-findings)

5.2 Workshop Strengths and Weaknesses
[53](#workshop-strengths-and-weaknesses)

6 Future Directions [53](#future-directions)

7 Acronym List [55](#acronym-list)

8 References [58](#references)

APPENDIX A -- WORKSHOP AGENDA

APPENDIX B -- PARTICIPANT LIST

APPENDIX C -- BREAKOUT GROUPS & ORGANIZERS

APPENDIX D -- ADVANCED LIFE SUPPORT SYSTEM DESCRIPTION

APPENDIX E --SCENARIOS & QUESTIONS

APPENDIX F -- PRESENTATION ABSTRACTS

# Preface

The Workshop on Advanced System Integration and Control for Life Support
(ASICLS) was conceptualized in 2003 as a method to bring together NASA,
academic, and industrial experts in the areas of spacecraft human life
support, environmental monitoring, control systems, and process control.

The workshop was implemented by the focused effort of many individuals.
These included the workshop NASA management team, the workshop
organizers who implemented the event, and the many workshop
participants. The NASA Advanced Human Support Technology (AHST) Program
elements of Advanced Environmental Monitoring and Control (AEMC) and
Advanced Life Support (ALS) worked together to create the ASICLS
Workshop.

## **Charter**

Future long-duration, human space exploration missions will rely upon
tightly integrated regenerative life support systems that will operate
with small margins for error and limited capacities. The goal of
controlling these future missions challenges many areas of research
whose products must be integrated into a coherent, safe, and reliable
system that runs day after day for years and that can effectively and
efficiently interact with crewmembers who place their lives in its
hands. These control strategies must deal with continuous and discrete,
biological and chemical processes and handle dynamic interactions
between the multiple systems that impact regenerative life support. The
control system must also be capable of interacting with its human crew
with varying degrees of autonomy, as is appropriate in the context of
the situation.   In some cases this means that the control system must
adapt to new situations, solve problems, and take opportunistic actions.
The design process for such a reconfigurable integrated system will be
multi-disciplinary, involving advanced controls development, systems
modeling and integration, data acquisition, data analysis, embedded
systems design, systems architecture, and information systems design.

The workshop will address how NASA will develop and implement a highly
integrated regenerative life support system with a reliable and
self-sufficient automated control system.  It will identify the issues,
problems, and challenges associated with using available technology and
identify technological gaps that require investment and development. The
results of the workshop will help NASA in creating a strategic plan and
associated roadmap for the development of advanced system integration
and control system design strategies and operational interfaces for
regenerative life support systems in future human exploration missions.

# Executive Summary

This objective of this workshop was to identify life support system
integration and control issues, problems, and challenges associated with
using available technology and identify technological gaps that require
investment and development. To address these issues, breakout discussion
groups were formed along the lines of future mission scenarios. Since
the meeting occurred prior to the President's Vision for Space
Exploration (also known as VSE, announced January 2004), the assumed
mission set, as follows, is slightly different from VSE in that it omits
a lunar scenario: Ground-based Human-Rated Test Facility, Mars Transit
Vehicle, Mars Planetary Exploration, and Mars Planetary Base.

Important findings of the breakout groups are as follows: Ground based
testing is an interative process. A major usage, for example, will be to
transition technologies from low to high TRL. The facility should
therefore be made able to support small, iterative tests.
Reconfigurability is a must, and in order to attain enough data to
diagnose failures it must be allowable to run technology and processes
to their breaking points. It will be efficient to mirror the hardware
facility with a software-based "cyber" facility. The overall facility
must be able to emulate various levels of ground control, communications
latencies, and adjustable autonomy.

Much technology can be leveraged from the industrial process control
community. However, most industrial operations do not undergo unplanned
transitions. Furthermore, almost all control systems assume a process
which transforms known inputs into known outputs. While components of a
life support system operate this way, the overall life support system is
closed loop, a new and unique requirement for which there is no readily
available solution. Industrial solutions may be driven by economics
rather than flexibility or stability. Space exploration missions, and
therefore the ground facility, will have to deal with transitions such
as transit mode to orbit mode. The orbit mode may operate in a resource
saving mode while the crew is on the surface, but will also need to
transition to operational status when the crew returns. The system must
be flexible enough to operate stably during unplanned scenarios such as
a seriously ill crew. The human interface to mission control and to the
crew will have many levels of accommodation. Data from past, present,
and future experiences in human space flight needs to be appropriately
captured for use in modeling.

By the conclusion of the workshop, a broad consensus was reached on the
following recommendations to NASA:

-   Advanced System Integration and Control for Life Support needs to be
    recognized as a real need and a critical gap in current programs.

-   Keeping the system testbed activities alive and for use in testing
    and validating both controls approaches and methodologies is of
    paramount importance.

-   A *Virtual* Testbed facility should be developed to make data and
    models widely available to researchers, to permit development of a
    \"theory-experiment\" process to transition technologies through the
    TRL\'s, and to benchmark new technologies.

# Introduction AND BACKGROUND

When facing a challenge of the scale of controlling the life support
system of a future interplanetary mission, it is efficient to address
that challenge well in advance, by bringing together expertise from
around the country, both within and outside NASA. Furthermore, under the
One NASA spirit, it is timely to grow the relationships between NASA's
life support community and its experts in advanced control research.
This workshop takes on both the technical challenges of the future and
task of nurturing the organizational underpinnings that support those
challenges.

In advance of the workshop, background material and a conceptual
framework for the workshop discussions were provided to all participants
by the NASA Advanced Human Support Technology (AHST) Program. This
material included a description of spacecraft advanced life support
requirements and systems, as detailed in Appendix D, Advanced Life
Support Systems Description. It also included a description of four
conceptual missions that fit within NASA's long-term strategy of
developing the capability to carry out human exploration missions beyond
low Earth orbit, contained in Appendix E.

## **Description of Advanced Life Support Systems**

During a human space flight mission, artificial supplies of air, water,
and food are critical to the crewmembers' life, health, and performance.
A human requires substantial amounts of oxygen, water and food to
sustain life. These consumables inevitably become waste products,
requiring storage if not recycled. One estimate of the resupply mass
requirements of a long duration space habitat with an open-loop life
support system is about 33 kg per person-day, which includes crew
supplies, gas leakage to space and maintenance items. Over a one-year
period, a single crewmember requires about 12 metric tons of consumable
materials. Minimizing initial launch mass and reducing the need for
resupply are essential to the economic and logistical feasibility of
long duration exploration missions.

Life support systems are described as \"open-loop\" or \"closed-loop,\"
depending on the flow of material resources through, or within, the
system. Open-loop life support systems provide all required resources,
such as water, oxygen, and food, from storage or resupply, and store
waste materials for disposal or return to Earth. In an open-loop system,
the resources required increase proportionally as mission duration and
crew size increase. Closed-loop life support systems require an initial
supply of resources but then process waste products, such as carbon
dioxide, urine, and wastewater, to recover useful resources, such as
oxygen or water for reuse, thus reducing dependence on resupply. Both
open-and closed-loop systems require energy from outside the system. The
ultimate combination of technologies will be chosen based on results of
system trade-offs to determine the optimal degree of closure, which is
defined as the percentage of the total required resources provided by
recycling.

Advanced regenerative life support systems are under development by the
NASA Advanced Human Support Technology (AHST) Program to meet the
requirements for human life support on long duration space missions,
while using significantly less input of consumable materials. These
systems will be composed of combinations of biological and/or
physico-chemical technologies to recycle waste products back to
consumable inputs. Major functions of a regenerative life support system
include atmosphere revitalization (oxygen production, carbon dioxide and
trace contaminant removal), water purification, solid waste processing,
thermal control (ventilation, temperature and humidity control, and heat
rejection), and food production (crop growth, processing, and storage).

The advanced life systems in future long duration spacecraft will rely
on sophisticated monitoring and control systems, to ensure high
availability of all critical life support functions over the entire
mission.

## **Description of Exploration Missions**

Four mission architectures were defined to provide a context for the
workshop. Each architecture included a description of a conceptual ALS
system. This provided a basis for small, structured groups of
participants to discuss control systems challenges and potential
solutions.

### 

**Mission Architecture: Ground-based Human-rated Test Facility**

It has been proven repeatedly that pre-mission, integrated systems
testing is the only effective way to address complex integration issues
of space hardware and software. Including humans in the ground testing
of the hardware and software needed for environmental control and life
support, and testing of these systems for a duration equivalent to that
of the space mission add rigor that can greatly reduce risk and cost
later. Ground-based human-rated test facilities will be required to
design, develop and test the advanced life support systems that will
ultimately be used for long-duration human exploration missions. Unlike
flight systems, the ground-based facilities will be reconfigurable,
supporting multiple configurations of candidate ALS system hardware and
control software, test protocols and operational methods. Such
facilities will be designed to support rapid reconfiguration of both the
ALS hardware and control system between tests.

**Mission Architecture: Mars Transit Vehicle**

Transit missions between Earth and Mars are characterized by very
limited power resources and little or no extravehicular activity (EVA).
The life support systems consist of tightly integrated physico-chemical
hardware, with little or no biological life support hardware. Food will
be principally sent from Earth and will be shelf-stabilized. A small
vegetable growth unit is anticipated, to augment the crew diet with
fresh food. The life support system will consist of partially closed air
and water systems. Solid wastes will be stabilized and stored. The
one-way communication transit time from Earth to Mars can be as long as
20 minutes. Therefore, the control system must be designed to meet the
varying constraints of ground controllers, crew, and equipment
maintenance/control system requirements.

**Mission Architecture: Martian Planetary Exploration**

Planetary exploration missions are the initial planetary surface stays
by humans. Earth-based Mission Control will continue to possess the bulk
of the expertise about the mission hardware, software, and operations.
The life support system consists mostly of tightly integrated
physico-chemical hardware. ALS biological systems, however, are
expected, with perhaps small bioreactors and/or vegetable growth units.
The system must support daily EVA of 4-hour duration. The system has
some open and some partially closed material loops.

**Mission Architecture: Mars Planetary Base**

A planetary base is ultimately established, and its crews are rotated
from Earth every two years. There are daily EVA excursions, some
extended to several days in duration. The ALS system has integrated
physico-chemical and biological processes. There are inflatable
greenhouses on the Martian surface that take advantage of the ambient
sunlight. Food is harvested from both the greenhouses and vegetable
growth units within the crew habitat area.

# Results and Discussion

The workshop was held on August 26-28, 2004 in Monterey, California, and
was hosted by the Advanced Environmental Monitoring & Control (AEMC) and
Advanced Life Support (ALS) elements of the AHST Program. It assembled
approximately 50 individuals from multiple NASA enterprises, five NASA
centers, nine academic institutions, and several industrial firms to
define both challenges and potential solutions for the development of
advanced control systems technologies for spacecraft life support. In
plenary sessions the participants described relevant historical
experiences, the current state of technology, and issues for future
space missions.

The mission scenarios described in section 3.0 were used to focus the
subsequent discussions in structured breakout group sessions. Each group
included NASA and external participants, providing an environment for
defining current technology issues and future solutions.

The first day consisted of a series of background presentations and
discussion. Breakout groups were convened on the following two days,
with reporting at the end of each day.

## **Day One -- Presentations**

The plenary session was opened by Darrell Jan of NASA/JPL, the lead for
the AEMC technology area, and Jitendra Joshi from Universities Space
Research Association, the AHST Program deputy lead from NASA
Headquarters. Dr. Jan described the **vision** for the workshop:

> NASA will develop and implement a highly integrated regenerative life
> support system with a reliable and self-sufficient automated control
> system. 

The **Objective** of the workshop was described as follows:

> This workshop will identify the issues, problems, and challenges
> associated with using available technology and identify technological
> gaps that require investment and development.

Breakout group members were to identify the major challenges on the
first breakout day, and enumerate solutions to these challenges, and the
status of these solutions, on the following day. Attendees were
encouraged to be creative and thoughtful, but to leave behind personal
agendas.

The first day presentations are summarized below. The complete workshop
agenda can be found in Appendix A.

International Space Station (ISS) environmental control and life support
systems (ECLSS) design and operational experiences were presented by Jay
Perry, the NASA/MSFC ECLSS representative. Advanced life support system
architectures and control challenges were described in a presentation by
Richard Boulanger and Harry Jones from the NASA/ARC life support systems
branch. Exploration missions and related ground testing were presented
by Dan Barta, the NASA/JSC deputy manager for ALS.

Challenges and opportunities of ALS systems analysis and modeling were
presented by K. C. Ting of The Ohio State University. ALS control
metrics and the concept of equivalent system mass (ESM) were presented
by Alan Drysdale of the Boeing Company. Advantages of hierarchical,
centralized architectures for controlling real-world systems were
presented by David Kortenkamp of Metrica, Incorporated. David Overland
of NASA/JSC presented ALS integrated control challenges. Daniel Cooke of
Texas Tech University gave a presentation on orchestrating control
systems solutions. Debra Schreckenghost of Metrica, Incorporated
presented crew/ground control interface requirements. Jane Malin of
NASA/JSC provided a presentation of reliability, safety, and error
recovery for advanced control software. Jon Erickson of Berkley Street
Consulting presented challenges for the future of ALS monitoring and
control.

For representation of the community outside NASA, industrial process
measurement and control technologies were presented by R. Russell
Rhinehart of the Oklahoma State University. David Musliner of Honeywell
Laboratories described research directions in industrial process
control, and Francisco Maturana of Rockwell Automation presented an
example reconfigurable autonomous agent architecture for shipboard
automation.

Carl Ruoff from NASA/JPL presented control approaches for NASA's robotic
missions. Barney Pell from NASA/ARC described autonomous control with
the Remote Agent architecture for the Deep Space One mission. On Day 2,
Peter Bonasso from Metrica described control issues in water processing,
and David Kortenkamp presented an ALS simulation for integrated controls
research.

## **Group 1: Ground-Based Human-Rated Test Facility**

### **Day Two -- Breakout Sessions: Scenarios**

Group 1 investigated the controls & automation challenges of a
ground-based, human-rated test facility, such as a "bio-dome." The
facility is an enclosed ecosystem that is used to design, develop and
test the advanced life support (ALS) systems that will ultimately be
used for long-duration human exploration missions. Prior facilities were
designed to support one experiment at a time, each of which could last
several months. NASA is considering a new facility that could be
reconfigured to support multiple experiments ongoing simultaneously.

#### **Identification of Needs, Problems, and Challenges**

Previous facilities evaluated life support systems in monolithic, long
duration-tests. The panel felt that the design and analysis of life
support processes, technologies, and controls is an iterative process,
but that the single-experiment approach of previous facilities
discouraged this. ALS technologies and processes will mature faster if
the facility also supported smaller, iterative tests and simplified
access to the facility from the ALS community. Access includes
integration of new technologies and processes, design of experiments,
and access to experimental data.

Access challenges/desirements included:

-   Ability to access test data remotely

-   Ability to identify integration and process issues early, perhaps
    via analysis or simulation, before attempting high-cost,
    short-schedule integration.

-   Need for standard interfaces & integration standards

-   Ability to reconfigure the facility quickly for various tests

-   Ability to run multiple tests simultaneously (lower-risk tests, and
    more opportunities to run tests reduces the "entry cost" and
    increases availability to the ALS community).

Usability issues included:

-   Ability to reconfigure facility for tests

-   Having enough data to diagnose failures

-   Risk posture that allows technology & processes to be run to their
    breaking point (where one learns the most)

The panel concluded that many of these needs would best be addressed by
mirroring the reconfigurable ground-based test facility with a "cyber"
facility. The cyber facility (a set of simulations and data exploration
utilities) would provide a way to validate new ALS technologies and
processes prior to integration, would provide a standard integration
interface, provide the ALS community remote access to experiment data,
and provide knowledge management tools for diagnosing, understanding,
and archiving test results.

The facility is to be used to test new ALS technologies and to mature
them through the technology readiness levels. A transition path from
cyber to the physical facility to space flight needs to be developed in
conjunction with the test facilities.

#### **Scenarios**

The group feels that in addition to the facility's use to certify new
technologies, it can also be employed to shadow actual space flight
missions. The facility would be "overly instrumented" and may be capable
of finding states hidden in the presumably less instrumented space borne
systems. Therefore, it and the cyber facility could be used to diagnose
problems and to perform other forms of post-mortems when systems do not
operate correctly or otherwise fail.

*The scenarios also included plug and play test articles that could be
switched in and out of the test facility while multiple tests were
underway. Ideally, these article switches could be switched with minimal
interruptions to the other experiments being conducted. A capability to
rollback the facility to earlier states was viewed as an enabling
capability for plug and play features.*

#### **Discussion and Relevance**

Discussions of these needs and scenarios revealed consensus among the
members of the group. The utility of a cyber and physical facility was
brainstormed and revealed a number of excellent uses and motivations for
the facility. For example, the group held the opinion that the facility
could be an excellent experimental and test facility to transition new
technologies from low to high TRL's. By providing secure access to
actual test data, researchers could test their low TRL approaches
against real test data through secure access to the Internet. In fact,
these tests could be used to compare a remote researcher's approach
against other approaches in order to identify new candidates for cyber
and physical tests in order to pull technologies from remote labs. The
use of the facility for support in helping to identify new projects for
research program funding seems clear.

The potential utility of these facilities before, during, and for
post-mortems after missions is very high. Before missions the facility
can be used to perform multiple experiments at the same time, through a
desirable plug and play capability, together with an ability to "roll
back" the facility to earlier points when, e.g., the air lock is
breached to change out experimental devices. The facility can be used to
pull technology from remote labs, through TRLs towards flight
certification. Finding the breaking point of technologies was seen to be
a particularly excellent use of the facility. Data archiving facilities
can be used for analyses to determine causal links among data in
experiments and tests. Secure internet access to "live" test data can be
used by remote researchers. During missions the facility can be used to
shadow actual missions to provide greater insights into problems that
may occur. It is assumed that the ground facility will be overly
instrumented to "fill in the gaps" in flight data. Clearly, there is
significant need for efficient policies to manage the configuration of
these facilities in order to preserve the integrity of the systems.

After missions are completed, the ground facility can be used for
post-mortems in order to determine problems and to run "what-if" tests
for future missions.

### **Day Three -- Breakout Sessions: Topics**

The solution space includes significant hardware and software advances
that provide a revolutionary environment for the testing of ALS control
systems. These advances will require standards for interfacing hardware
and software articles, simulating hardware and software capabilities, an
ability to model the discrete and continuous features of an environment
and the effects of systems on the environment, a scientific process to
facilitate theoretical and experimental validation of technologies that
assures confidence in the results of tests, thresholds and barriers in
which mission planners have confidence for advancing technologies
through TRLs, and new approaches for expressing software and hardware
solutions.

#### **Categorization of Problem Space**

The problem space includes the need for theoretical advances that will
express the continuous and discrete aspects of a system. The paradigm
will need to accommodate the impact and interactions of complicated
chemical and biological processes. The paradigm will also need to be
capable of predicting the impact of individual control systems on the
facility's environment and upon other control systems. The theoretical
advance will provide for the experimental testing of the effect of new
test articles. See figure 1.1 for the solution space.

The ability to plug and play with new technologies in the test facility
or in the cyber facility is an important need requiring the development
of standards for interfacing systems as well as new approaches to
expressing software control systems at a reasonably high level of
abstraction.

The cyber facility, physical facility, and space-borne systems will need
to mirror one another in a manner that inspires the confidence of
mission planners. Therefore, besides a need to validate theoretical
predictions for ALS scientists, the theory-experiment cycle needs to
facilitate the movement of technologies through the Technology Readiness
Levels. In addition to ALS scientists, the audience of these validation
steps will be mission planners.

In many ways the problems NASA faces in controlling environmental
factors is unique. However, in addition to past and present NASA ALS
systems, technologies developed for nuclear submarines as well as
approaches taken in support of chemical processing plants should provide
baselines.

#### **Identification of Solutions, Technologies, or Research Areas**

The categories of research include theoretical/mathematical definitions
to combine discrete and continuous models, science process research,
technology transition research, standards development based in part upon
ontological research, software architecture research, and simulation
research and development.

Results in the research areas are required for the development of the
physical, ground test facility and the cyber facility that mirrors the
ground test facility. These facilities are to have these features, which
define the target solution space:

-   Identify subsystem to augment to be a demonstrator

-   Demonstrate experimental process to evaluate ALS controls

    -   Processes, tools, & instrumentation that enable flexible control
        of experiment, data collection, and post-hoc exploration

-   Demonstrate robust controls that handle challenges

    -   Explore full operating range (nominal to breaking point)

    -   Respond to/prevent systemic, cascading failures.

-   Demonstrate ability to "plug-and-play" new components

    -   Challenges: standards, modeling, integration, data creation

-   Demo cyber system that mirrors physical subsystem

    -   To evaluate new control strategies, algorithms, and processes

    -   Coordinated simulators at multiple levels & types

    -   To explore & access data for forensic analysis

-   Demonstrate secure, remote access to subsystem & data

Figure 1.1

#### **Existing Technologies Addressing a Particular Need**

Existing technologies include tools for software architecture support
such as CORBA, existing process technologies like those found in the
chemical industries, and other newer software technologies that may
further support plug and play components. Critical enabling technologies
will require research support to develop the theoretical and
experimental capabilities required for the facilities and process
research for science and technology transfer processes.

#### **Discussion and Relevance**

Discussions in the group tended to stay firmly on topic and were of a
type that promoted brainstorming and developed consensuses among the
group. There were few, if any, contentious points raised.

## **Group 2: Mars Transit Vehicle**

### **Day Two -- Breakout Sessions: Scenarios**

Transit missions are characterized by very limited power resources,
little or no extra-vehicular activity (EVA), and life support systems
that consist of tightly integrated physico-chemical hardware, with
little or no biological life support hardware. There will likely be a
small salad machine to augment the crew diet with fresh food. Food will
be shelf-stabilized. The life support system will consist of partially
closed air and water systems. Solid wastes will be stabilized and
stored. The one-way communication transit time from Earth to Mars can be
as long as 20 minutes.

The scenarios presented in the Mission architecture document highlighted
some of the unique features that the transit vehicle may face during its
mission. Some of these are summarized below.

-   *Responding to alarms*. The task of separating false alarms from
    alarms that are caused by failure and degradation of components and
    subsystems. The role of the ground station, crew on board, and the
    on board autonomous monitoring, diagnosis, and control system in
    analyzing the scenario and responding to the situation.

-   *Dealing with Operational Transitions*. The transit vehicle goes
    through a number of operational scenarios: launch, near earth travel
    or orbit, progressively increasing its distance from earth (which
    will make ground control operations less effective), injecting
    itself into Mars orbit where the crew transfers to the
    ascent/descent vehicle and the transit vehicle is put into a sleep
    mode, and the reactivation of the vehicle systems once the crew
    return for the journey back to earth. Therefore, the Mars transit
    vehicle monitoring and control systems have to be designed to take
    care of a variety of scenarios, where communication delays and the
    effectiveness of earth-based control decrease progressively with
    time, the systems and crew on board have to deal with different
    gravity situations (Earth and Mars gravity plus microgravity
    situations during transit), and the vehicle has to operate in a
    hibernation (or sleep) mode for an extended period of time, while
    the crew is involved in activities on the Martian surface. The
    vehicle has to reactivate itself, and return to a correctly
    functioning mode when the crew return for the journey back to Earth.

#### **Identification of Needs, Problems, and Challenges**

A concerted effort was made by discussion group two to identify and
categorize problem areas associated with a hypothetical Mars Transit
Vehicle as described in the scenario documentation. The committee
decided not to be limited by the specific aspects of the scenarios in
discussing design, implementation, testing, and deployment issues for
the transit vehicle. The document was used to foster discussion in
broader terms. The ideas generated by the committee can be categorized
under four areas:

-   Programmatic Issues,

-   Mission Architecture for Autonomy,

-   Control for Long-term Operation, and

-   Human Factors Issues.

##### **Programmatic Issues**

The committee identified many issues that were beyond the scope of its
charter to recommend solutions for. These were categorized as
programmatic issues that management should be made aware of. These were
further subdivided into the a) *Use of Commercial-Off-The-Shelf (COTS)
Technologies,* b) *Integrated Testing of Technologies,* c) *ALS System
Design and Development, and* d) *Operations Development.* Solution of
many of these challenges would require NASA policy changes or active
participation of NASA management.

**Use of Commercial-Off-The-Shelf (COTS) Technologies**

The committee was concerned that use of COTS technologies was vital to
the success of any future space mission. The challenges revolved around
allowing the research, design and development processes to move forward
while still enabling the use of evolving COTS technologies. There was
considerable discussion about how NASA might partner with industry to
foster the development of the technologies and standards it requires.
Not all COTS solutions will always be practical, however. The example of
radiation hardening of commercial electronics was given as a specific
stumbling block in the use of COTS technologies for actual missions.

**Integrated Testing of Technologies**

It was recognized that in order for missions beyond Low Earth Orbit to
succeed, considerable testing must occur. Testing in a suitable
environment (microgravity) is an essential to validate ALS operations,
which include a lot of flow processes. It was determined that currently
the ISS is the only platform suitable for long-duration testing of such
systems. Furthermore, there needs to be recognition on the part of
program management that failures during such long-duration missions are
inevitable, and that success should be defined as detecting failures
early, and recovering from them without significant damage to the
spacecraft, loss of life and compromising mission objectives.

**ALS System Design and Development**

Design of an integrated ALS system is technologically challenging. There
was, however, considerable discourse that similar types of control
problems in the industrial controls world were being routinely addressed
and solved. The consensus of the committee was that major technological
gaps existed in the areas of

-   High-speed, real-time monitoring and control especially in unknown
    environments, which may make system behavior difficult to predict,

-   Integration of the ALS system with other vehicle subsystems, such as
    power generation, communication, etc.,

-   Testing and validation of integrated systems with advanced controls,

-   The lack of systematic design, analysis, and verification tools for
    such multi-paradigm (physico-chemical and biological), multi-modal
    (system operates in various modes and configurations during mission)
    systems. Similarly, there is are no well-established techniques for
    iterative design of complex control systems, and

-   Integrated design, implementation, and testing of complex hardware
    and software systems (i.e., embedded systems), which need to satisfy
    a number of hard constraints, such as real-time requirements,
    performance guarantees, and the ability to work seamlessly with
    ground control and the crew on board under widely varying
    conditions.

**Operations Development**

A Mars transit vehicle will change the current spacecraft operations
paradigm. The communications delays and latencies alone will drive the
design requirement away from strong ground control towards greater
autonomous control and operation of the spacecraft. The operations
concept clearly needs to be evolved prior to flight. The three primary
players in this scenario are: (i) mission control on Earth, (ii) the
human crew on board the spacecraft, and (iii) the spacecraft control
system. To get a better understanding of the most effective way of
combining the roles of these three groups to achieve reliable and
efficient spacecraft operation, a number of different scenarios will
have to be studied. These scenarios should be based on parameters, such
as (i) communication latencies, (ii) the nature of the faults and their
potential effects on long-term operation of the mission, and (iii) crew
schedules. Scenarios should also be developed to test human factors
issues for collaborative analysis and action. These issues may not only
play a role in system and controller design and implementation, but also
in training mission control and crew in the operation of such complex,
autonomous systems over long periods of time. The range of gravity
levels needs to be decided early to determine any constraints on ALS
flight hardware design.

##### **Mission Architecture for Autonomy**

The committee expanded on the design and operation of autonomous
spacecraft for Mars transit and identified several key challenges. The
overarching needs fall into two primary categories: (i) designing a
control architecture that is evolvable, multi-paradigm, and multi-level,
and (ii) addressing the human-machine communication and collaboration
issues for a system that is autonomous, intelligent, and comprehensive.
Given that this is a project with a long time-scale, both the hardware
technology and software tools will advance as the system design and
implementation of sub systems is in progress. It is important that the
system architecture be designed to be evolvable to ensure that
technology employed in subsystems does not become obsolete by the time
the system is ready for deployment. As discussed earlier, the overall
ALS system will include a wide variety of physical processes, and
different control paradigms may be suitable for the different
subsystems. Further, it makes sense that the system and control
architecture be developed as distributed but interacting modules. All of
these present significant challenges that have not been fully addressed
in research work or industrial practice in the past.

The committee also discussed in more detail several key challenges that
are listed below.

-   Determining and testing the effectiveness of autonomous systems. An
    interesting paradigm that was presented was whether the
    effectiveness of the autonomous system could be tested early in the
    mission, and depending on the results, guidelines could be evolved
    for autonomous monitoring and control, and the interactions between
    ground stations, the crew, and the control system. There also was
    discussion about autonomy being fully exercised from the very start
    of the mission, as opposed to being gradually phased in, as was
    suggested in Scenario 3 for the Mars Transit vehicle.

-   Determining the scope of autonomy in different situations. As
    discussed earlier, the transit vehicle will go through distinct
    operational modes through various stages of the mission. This
    implies the need for adjustable autonomy. The challenge is how to
    define the scope of autonomy for various situations. A particularly
    intriguing challenge is how to deal with the transit vehicle while
    it operates in an unmanned orbit around Mars. Other issues that were
    discussed had to do with how much were humans were integrated into
    the monitoring, diagnosis, and control tasks. When unusual
    situations were detected, what is reported and to whom? To what
    extent should the system rely on human expertise and intervention,
    and under what conditions should it seek such intervention as
    opposed to operating autonomously?

-   Addressing design issues for the interface between humans and
    autonomous systems,

-   How do communication delays affect autonomous control,

-   What degree of commonality is needed across transit and base
    systems? This is important especially in situations where humans and
    the autonomous control will have to collaborate to make joint
    decisions.

-   How to deal with problems as they occur. In other words, there is a
    need for online, real time, monitoring and decision-making systems.
    Implementing these in a large, distributed system brings up a number
    of theoretical, logistic, and computational challenges.

There has been some work on the design of hybrid controllers and
reconfiguration control to handle a variety of situations, but the
application to a Mars Transit vehicle will require dealing with
significant complexity and scaling-up issues.

##### **Control for Long-Term Operation**

A discussion of the relevance and implementation of model-based
techniques for monitoring and diagnosis and model-predictive control
dominated a large portion of the committee's time. Several key issues
and challenges were identified:

-   Design and automation challenges associated with closed, embedded
    systems -- in addition to online, and near real-time monitoring,
    diagnosis, and decision making, the software must reason about
    resource availability and spares,

-   Models will have to evolve over time as the system evolves. This is
    because component performance will degrade with time, and
    characteristics may change as the environment of operation changes.

-   Monitoring the system and environment changes and degradations over
    time,

-   Determining if a system has a nominal signature and using that
    signature to predict failure,

-   Optimal sensing, placement and number, redundancy and the effects of
    varying gravity and microgravity (possibly artificial gravity) on
    sensors,

-   Recovery from catastrophic events, systems that operate under a wide
    variation of conditions, both nominal and off nominal.

Again, there is preliminary work on tracking, fault diagnosis and
fault-adaptive control of hybrid embedded systems, but significant
scaling up issues will have to be addressed in applications to the
transit vehicles. Design of verifiable advanced controllers is also an
open and unsolved research problem.

##### **Human Issues**

The committee identified two principle human / control system issues:

-   What impact or design constraints are likely given the impact
    radiation has on both human health and equipment operation?

-   How can crew and ground personnel be effectively trained with an
    autonomous control system and its interfaces as that system evolves
    over the life of the mission?

### **Day Three -- Breakout Sessions: Topics**

#### **Integrated Systems Modeling**

As discussed earlier, ALS systems are complex, contain multiple
physio-chemical and biological processes, and are made up of
distributed, but interacting subsystems. Building computationally
efficient models for such systems is a nontrivial task, because it
brings in multiple research issues: modeling of hybrid and distributed
systems, systems with complex nonlinear behaviors, and systems whose
characteristics change over time. Building and validating ALS subsystem
models will be a significant challenge.

Related to this, there exists an immediate need for the application of
hybrid modeling tools (e.g., MatLAB, Simulink, StateFlow) to model
combinations of discrete and continuous behaviors). Also, there is need
to build models that integrate hardware subsystems with software
controllers, i.e., embedded systems. There was some concern that
modeling of hardware *operations is* critical, and it is NOT being done.
Similarly, it is critical to develop integrated testbeds for studying
embedded systems behaviors. Preliminary work on building ALS subsystem
models for monitoring, diagnosis, and control tasks are now in progress
\[Kortenkamp, et al.; Biswas, et al.\]. There is preliminary discussion
on building a testbed at NASA JSC, INTEGRITY, for testing, integrated
distributed systems that include hardware, software, and the networking
layers.

Possible modeling environments that were suggested:

-   FIIPA -- Foundation Infrastructure for Intelligent Physical Agents
    -- inter-agent communication standards.

```{=html}
<!-- -->
```
-   HSIF -- Hybrid Systems Interchange Format.

The advantage of adopting these modeling paradigms early is that it then
makes available a number of tools that can be employed for analysis of
various aspects of the system.

Another important task is the construction of models that are geared
toward online monitoring and diagnosis tasks. Presumably for such
complex systems, controller synthesis techniques will also have to be
developed, therefore, integrating controller models into the system
modeling scheme is critical.

#### **Online Monitoring and Diagnosis**

This task requires building of hybrid observer systems for tracking
system behavior, fault detection schemes that are tuned to be sensitive
to small deviations in the system, while avoiding false alarms, and
robust and efficient diagnosis schemes for fault isolation and
identification. There has been some work on monitoring and diagnosis of
complex nonlinear systems and hybrid systems, but a lot needs to be done
before their effectiveness is proven for real applications. The tasks
are also further complicated when one has to deal with heterogeneous,
coupled systems. The group identified a number of important problems
that would have to be solved for online monitoring and diagnosis
systems.

-   Tuning fault detection systems to achieve the right balance between
    sensitivity and false alarm rates.

-   Developing the right diagnosis methodologies to find the faults.
    Faults can occur in many different forms. The easiest to detect and
    isolate are complete failures of components, and the hardest are the
    intermittent faults. In between, there is a spectrum of fault
    profiles from abrupt changes to slow incipient changes (that can be
    attributed to degradation). Fault isolation methods can be
    model-based or pattern-based. Model-based techniques can be
    qualitative, quantitative, and stochastic. A combination of fault
    isolation methods may have to be employed to cover a variety of
    possible fault scenarios that may occur.

-   Diagnosis of coupled distributed systems. The ALS is made up of a
    number of subsystems that are interdependent. Presumably, each
    subsystem will have its own models, and their own monitoring,
    diagnosis, and control modules. However, when faults occur, their
    effects may propagate to different subsystems. Fault isolation and
    then performing corrective actions online becomes a very challenging
    task.

-   What kind of fault-adaptive control technologies need to be
    incorporated into the controller design schemes? Recently, there has
    been significant work done in robust model-predictive control, and
    this has been applied to a number of industrial processes,
    especially in the chemical industry. However, a more autonomous
    control system with fault-adaptation capabilities would need to
    include intelligence and a suite of tools, such as controller
    retuning, controller reconfiguration, and system reconfiguration to
    handle a variety of different fault situations and scenarios.

-   Reconfiguration requires a global view of the system, and analysis
    of the effects of reconfiguration over a long projected time
    horizon. Keeping humans informed about reconfigurations being
    performed, and getting them to adjust to changes in the system is
    another critical problem that needs to be addressed as part of the
    system design, implementation, and analysis.

#### **Control Systems Architecture for Integrated Control**

Controllers for complex, distributed systems are necessarily
multi-paradigm and hierarchical. A high-level controller description
language needs to be evolved to capture hierarchical controller
specifications, and interactions among multiple controllers. System
design will necessarily take on a layered approach, and vertical
composition techniques will have to be developed across a general n-tier
control architecture.

Such safety-critical and reliable systems may need to incorporate a
**safety executive** -- an independent authority from the primary
controller, whose sole task is to monitor system operations and compare
them against mission goals to minimize the effects of risk. This is
similar to work in hybrid control, where the goal is to ensure the
system is in "safe" region of control. The safety executive will deal
with performance issues, such as how quickly can the problem be caught,
pre-empted and recovered from? For long-duration missions, safety has to
be a very important part of the control requirement. Another suggestion
is that safety may be broken down into long- and short horizons.
Short-term safety should be handled primarily by the autonomous control
system, and long-term safety decisions may involve collaborative what-if
analysis between the human crew, mission control, and the autonomous
controller.

Again, strong emphasis was laid on designing for autonomy through the
mission, not just for situations where the transit vehicle is in the
communication shadow or as it moves sufficiently far away from earth
orbit. The complexity of the tasks and the need to push beyond the
current state-of-the art require a strong emphasis on building
integrated test beds on Earth, as well as to use the Space Shuttle and
the ISS for testing and data collection purposes.

#### **Software Methodologies**

There was discussion on the need for advanced software design and
synthesis methodologies, and the need for verification and validation
methods to ensure the reliability and robustness of the software. The
software tools developed should be designed to support all elements of
the mission (ground support, transit, base, etc).

#### **Integrating Human Expertise**

The need to allow for and enable smooth and transparent human
intervention through the various control system layers is another
critical requirement for such missions.

Two very important issues that were discussed were the concepts of
situational awareness and adjustable autonomy.

-   Situational awareness

    -   Human guided machine learning to recognize situations

    -   Visualization of the situation in the context of the task --
        interpretation of data for the user; physical models as well as
        data: finding useful patterns for the human

```{=html}
<!-- -->
```
-   Adjustable autonomy

```{=html}
<!-- -->
```
-   Transfer of control responsibility implied. Allocation of
    responsibility dynamically between humans and autonomous control.
    Adjust based on plan, individual, workload, situation, etc.
    Investigate robotics overlap in research. Smoothness of control
    transfer.

-   Scope of control: recognize where conflicts in activities exist.

-   Component level intelligence would enable adjustable autonomy.

-   Requirements / performance evaluation of autonomous control

-   Metrics for autonomous control systems (effectiveness evaluation for
    early TRL)

-   Technology for tracking of human activities: (human-human,
    human-automation, human-stores)

-   ISS/Shuttle for operations research \-- simulation of transit
    mission with prototype of transit LSS (Undersea tests?)

-   Multi-modal interfaces crosscuts both Situational Awareness and
    Adjustable Autonomy

-   Do not expect the crew to know less, expect crew to know more.

-   Just in time training indicated.

#### **Programmatic Issues**

Last, some of the programmatic issues that were discussed on the
previous day were revisited. The two primary points that were discussed
at some length are summarized below.

-   Research funding and technology selection models

    -   Consider DARPA model. Drives integration with industry early on
        by defining testbed requirements. Fund from TRL level 1-8.
        Technology selection required. Diverse fundamental: expands
        scope.

    -   Non-profit consortium model. Form a consortium with industry to
        create requirements for system design. Increases diversity of
        agencies.

```{=html}
<!-- -->
```
-   Radiation hardening of commercial electronics

    -   Inevitable. Still research issues. No radiation hard
        non-volatile memory available. Being done for a current mission
        and can leverage for Mars transit.

## **Group 3:  Martian Planetary Exploration**

### **Day Two -- Breakout Sessions: Scenarios**

Group 3 identified a wide range of needs, problems and challenges. These
ranged from system design and integration to real-time control to human
interfaces. The challenges were grouped into six broad categories: 1)
system design, which focuses on making pre-deployment decisions about an
optimal system configuration; 2) system operation and control, which
focuses on controlling the system during a mission to achieve mission
success; 3) coordination and integration of a distributed control
system, which focuses on bringing temporally and spatially disparate
parts of the control system together; 4) determining and predicting
system state and diagnosing faults, which focus on using sensory
information and system knowledge to understand the state of system such
as where is it going and what is going wrong with it; 5) resource
management, which focuses on tracking and assigning resources in the
system; and 6) human interfaces, which focuses on how the crew, ground
controllers and system experts can understand the system's state and how
decisions affect its performance.

#### **Identified Needs Based on Scenario**

The six broad areas identified as "needs" were: 1) system design; 2)
system operation and control; 3) coordination and integration of a
distributed control system; 4) determining and predicting system state
and diagnosing faults \[Hoo et al 2003; Kosanovich et al 1994\]; 5)
configuration control; and 6) human interfaces. These mapped onto the
scenarios as follows:

**Scenario 1**

Remote habitat deployment and checkout

Identified areas: 1) system design 2) system operation/control 3)
coordination/integration of distributed system.

The control system must be able to perform system checkout, system
startup, coordination/integration of the distributed systems \[Vasbinder
et al 2004\].

From the scenario described: checkout (areas 1 and 5), interface with
ground controllers (areas 2, 3, and 5), transition \[Tian et al 2003\]
from startup to continuous operation (areas 1, 2 and 3)

**Scenario 2**

ALS Physico-chemical subsystem failure

Identified areas: 1) system design 2) system operation/ control
solutions 4) determining/ predicting system state and fault diagnosis 5)
control configuration 6) human interaction with the system.

In the scenario described, system reliability must be established
(area 1) in concert with determining the state of the system. Once the
state is known diagnosing the root cause or possible cause of the
failure follows (area 2). Once determined, risk planning and
contingencies (alternatives) must be identified quickly (areas 1, 2, and
5) with input from the crew (area 6). Some contingencies may be
time-based, thus some means of iterative analysis is necessary to derive
a robust set of contingencies.

Aspects from the scenario described: limited bandwidth (area 5), human,
machine remote interactions and communications (areas 2, 4, 5, and 6),
possible reconfiguration (areas 2 and 6)

**Scenario 3**

Food handling and preparation

Identified areas: 1) system design 2) system operation/ control
solutions 6) human interaction with the system.

Aspects from the scenario described: assist the crew in meal preparation
(areas 2 and 6), address variable loads (area 1)

To the question is there an industrial analogue for variable loads --
the answer is affirmative. Industrial plants that have a biopond or
water recovery and cleanup must plan for unusual loads and loads whose
composition vary from nominal design. Model-based control and adaptive
control methods are used.

**Scenario 4**

Scheduling of mission critical activities

Identified areas: 1) system design 2) system operation/ control
solutions control 3) coordination/integration of distributed system

To the question is there an industrial analogue -- the answer is
affirmative. Government regulations force re-planning for unexpected
toxic releases. Redundant sensors and inferential estimates are
routinely part of the system design to discover critical weaknesses;
estimation, monitoring, and detection strategies are part of the system
design and control strategy.

To the question about scheduling tools, software and algorithms -- Gantt
charts, statistical process control charts, and LP optimization.

**Scenario 5**

Extended operation at reduced power levels

Identified areas: 1) system design 2) system operation/ control
solutions control 3) coordination/integration of distributed system 4)
determining/ predicting system state and fault diagnosis 5) control
configuration

Tools needed: intelligent adaptive control \[Tian et al 2003\], model
predictive control \[Krishan et al 1999\], intelligent reasoning, and
accurate data reconciliation \[Kosanovich et al 1994\], rapid means to
initialize and analyze "what-if" cases.

All of the identified needs cut across the various missions, although
they do so to varying degrees. For example, transit missions will also
have to deal with distributed operations, but the time lag will be
minimal at the beginning of the mission and considerable at the end of
the mission. Also, transit missions will not have EVA considerations.
There is much overlap among the scenarios but almost all cannot be
achieved if the system design did not permit resiliency, flexibility,
switchability and stability \[Vasbinder et al 2004\].

#### **Identified Needs by Areas**

**System Design**

Existing concepts include concurrent engineering design, the integration
of conceptual design and control structure synthesis concepts being
explored by \[Vasbinder et al 2004\], system-theoretic analysis for
control, and life cycle concepts.

Modeling -- different levels of abstraction (black to grey to white box
models) and the use of hybrid (mixture of fundamental and empirical)
modeling. Many paradigms exist to accommodate a range (deterministic to
stochastic) of model abstraction. Hybrid models and multi-scale models
\[Krishnan et al 1999\] are needed to represent ALS systems. Need models
at several levels of detail. Consider models from the hybrid systems
community (augmented finite state machines) which were used in Deep
Space One \[Muscettola 1998\]. Model-checking with such systems has come
a long way (Henzinger at UC Berkeley, and Ed Clarke at CMU).

**System Operation and Control**

Regulatory and advanced control structures include: model-based \[Zheng
et al 2002\], feedback/feedforward control types, centralized and
decentralized control configurations \[Vasbinder et al 2004\], machine
learning \[Kortenkamp, Bonasso & Subramanian 2001\], control-relevant
models \[Zheng et al 2003\], hybrid control, and stability analysis --
Lyapunov direct and indirect, linear analysis \[Tian et al 2003\]. Risk
management theory and contingency planning.

Architectures developed in the artificial intelligence community offer
solutions to higher level control, planning and execution. These include
3T \[Bonasso et al 1997\], Remote Agent \[Muscettola 1998\], CIRCA
\[Musliner et al 1995\], IDEA \[Muscettola 2000\], etc., which are all
roughly at TRL 1 to 6. 3T in particular has been applied to advanced
life support system tests \[Bonasso et al 2003; Schreckenghost et al
2002\].

Verification and validation \-- Testing software by model checking
(Clarke at CMU and Henzinger at Berkeley) should be considered. Software
model checking is a booming business with a demonstrated track record in
verifying complex hardware and software systems: these tools are in
routine use in industry like Intel and IBM. Since the control policies
for coupled systems like the BioPlex are quite complex, it is clear we
will need testing tools like reinforcement learning which exercise (in
the limit) all state space trajectories, to supplement verification
tools like model checkers (which can effectively find counter-examples
for given control policies).

**Coordination and Integration of a Distributed Control System**

Very few standards or formalisms exist for distributed control
architectures. However, there is a great deal of integrity checking,
hard safety components, redundant sensors (mostly same type), supply
chain management, etc. in industry. There is a fundamental issue in
coordination of distributed elements -- that is, to use a centralized
control scheme or a distributed control scheme (DCS). The former are
more traditional (military operations or NASA's mission control), while
the latter take their inspiration from market economies and advocate
local decision-making and control \[Wellman 1995\] and the DCS is
practiced widely by the chemical and refining industries. CICT (Computer
Information & Communication Technologies) is funding some work through
its Mobile Agents project (PI: Bill Clancey) that addresses coordination
between ground, base and EVA \[Clancey 2003\], which is still at TRL
1-3.

Data distribution amongst the distributed control components is an
issue. Current techniques include choosing in advance what data are
returned, returning only off-nominal data, various compression and
abstraction schemes and more knowledge-based summarization of data.
Integration of distributed software systems (even those that are
co-located) currently relies on standards and customization.
Verification and validation of distributed systems from the perspective
of software integrity is a significant research area \[Tsai et al
1996\]. From the perspective of hardware integrity, the chemical
industries have resorted to redundant systems, and there is always the
approach of using hard interlocks. Data integrity is addressed by
dedicated historians (this too is redundant).

**Determining and Predicting System State and Diagnosing Faults**

Existing tools for predictions when sensors are not available rely on
inferencing. Multivariate statistics, artificial neural networks \[Hoo
et al 2001; Gurumoorthy et al 1998\], understanding of the underlying
principles of the problem, Kalman filter, observers. Fault diagnosis
begins with steady state data reconciliation, projection of current
operations on pre-determined normal operating range (sweet spot -- word
coined by Piovoso and co-workers \[Kosanovich et al 1994\] based on
statistics) to detect situations different from "normal", trend analysis
based on model predictions.

Most industrial operations do not undergo transitions \[Tian et al
2003\] that are not planned. Unplanned transitions do occur but they are
usually due to parameter uncertainty and large unexpected disturbances.
The quality of the monitoring, detection and isolation of faults is not
rigorous. Some of the top companies are resorting to six-sigma tactics
to improve monitoring, tightening statistical control limits to recover
economic profits once considered unattainable \[Hoo et al 2003\]. With
the availability of high performance platforms, large LP optimization
problems are now tractable in real time and nonlinear model-based
control (nonlinear optimal control solution over a horizon) is now a
reality. Statistical approaches are also common including Partially
Observable Markov Decision Processes (POMDP), Baysian networks, neural
networks and radial basis function networks \[Gurumoorthy et al 1998\].
Time series analysis is appropriate for well-defined state spaces.

Reasoning over qualitative system models has also been used for fault
detection and prediction, including Livingstone and Titan \[Williams
etc.\] and work by Gautam Biswas \[Biswas et al 2003\]. Results have
been applied to life support \[Malin et al 2000\] and deep space
missions \[Muscettola et al 1998\].

Many of the approaches described above can also be used to predict
future system states under specific assumptions. There is forecasting
and trend extrapolation software available that use pattern recognition
to detect trends. Current methods have difficulty at unplanned
transition points and with unknown reference trajectories. "What-if"
analysis relies on prediction of future system states and will play an
important role in control of ALS systems.

**Resource Management**

Resource management includes knowing what resources you have. Current
industry approaches rely on RF tracking (emit and store information) for
inventory coupled with a database. Crew time is also a precious resource
for current flight models (this may not be true for all future missions.
What for example does the crew do during a Mars transit?) and currently
scheduling crew time on space station is a mostly manual process \[Korth
& LeBlanc 2002\]. Research into interactive planning and scheduling
tools for crew activities is on-going.

**Human Interfaces**

Human interfaces is a large research area in industry, government and
academia. Natural language understanding and speech understanding are
both being investigated by significant research groups. NASA has
investment in these areas as well, including the RIALIST group at NASA
ARC. Chemical, power, and refining industries have used the intelligent
systems tools available from Gensym (Cambridge, MA) that can reason
about faults and comes with a written natural language interface. The
vocabulary of the language is based on these industries. Bonasso et al
at NASA JSC have linked typed language to control knowledge in the
advanced water recovery system. Dialog management (i.e., managing an
on-going conversation between automation and humans) is an area of
academic research with expected benefits such as historical event
logging for fault detection and monitoring. Ontologies (as presented by
Overland) represent the organization of world knowledge -- control
systems and humans need to have shared ontologies. \[Probably need to
look at co-development of ontologies.\] Projects at NASA JSC have looked
at customizable/adaptable interfaces conditioned on location, role,
skills, etc. \[Schreckenghost et al 2002\]. Human factors research plays
a key role in interfaces between automation and humans and excellent
work is on-going in this area both at NASA and elsewhere \[Roth et al
1996\].

Another aspect of human interaction is maintaining crew and ground
expertise/knowledge. Current approaches include just-in-time (JIT)
training, including searchable databases and reference materials. This
area also includes procedure development and execution, including
procedures that are customizable to crew skill levels and procedure
assistance software (e.g., \[Bonasso et al 1997\]. Virtual reality and
continual training approaches also play a role in this area. Medical
procedures are of particular importance because there is some concern
that medical emergencies may occur and there will not be adequate
resources to deal with the problem. There is a heightened awareness due
to the expected communication delays. It is concluded that interaction
of medical procedures with the life support systems is something that
must be given adequate priority so that it is handled appropriately.

#### **Finding Existing Technologies Applicable for Spaceflight**

The existing technologies form a strong starting point (no need to
re-invent the wheel). What needs to be in place is a technology team
with a solid background in these areas -- solid in control theory and
implementation, fundamental modeling, logic and experience. It appears
that these issues are considered solvable by software paradigms -- but
software solutions must have a basis. It is what the software represents
that is valuable. It is recognized that the maintenance of the software
is important and that some software paradigms are better than others but
what they represent from the technology point of view addresses the
needs here not the other way around.

People that have both theoretical and practical experience with similar
technologies in the chemical, nuclear, and petrochemical industries
would have knowledge on this issue.

A major obstacle to any control system is the difficulty of obtaining
performance data on current systems. Sometimes the data is not
collected. Sometimes it is not available to researchers. Thus, there is
no realistic data set to develop applications on. Even ALS funded
research tends to use ad-hoc control systems rather than having
documented requirements. There is no evolving body of corporate
knowledge in the areas that the group is familiar with (mostly related
to bioregeneration).

If no such technology exists, or it is at a very low TRL, seek
researchers, universities and companies who are working on it, on
similar problems, or whose work could be adapted to the problem. As a
starting point, seek collaborations from some of the academics with
chemical industrial experience that were invited to the workshop. At
least two of the universities have an industrial consortium and at least
three of the chemical industries invitees have more than five years of
real industrial experience. A word of caution, the team needs a
diversity of experience.

### **Day Three -- Breakout Sessions -- Topics**

#### **Grouping of Identified Technologies by Topic**

##### **System Design**

System design refers to the pre-mission development of an integrated
life support system. This means choosing and sizing components,
determining appropriate automation and conducting experiments and tests.
Challenges in this area include integrating all process knowledge,
including effects of actions on processes and knowledge of global flows.
Lack of system performance data, model complexity and limited testbeds
impede progress in this area. Criteria for judging system design are
currently too simplistic and have difficulty reflecting the influences
of control automation and information technology. Defining the optimal
mix (and judging optimal) of automation and human tasks is a challenge,
as is the integration of physical automation with the overall control
system.

In any design one wants to achieve the optimal or best design. The
characterization of the best design among alternative designs is based
on tradeoffs between competing objectives such as economics versus
stability or operability \[Vasbinder et al 2004\]. The chemical
industries for instance, choose the best plant design based solely on
economic considerations, thus design of the plant is a steady state
exercise. This does not necessarily yield the most flexible, stable, or
robust plant design. Hence, the paradigm of concurrent engineering is
recommended. Concurrent engineering can be interpreted to be a design,
develop, test, and operate cycle \[Vasbinder et al 2004\]. Moreover, it
was stressed that these serial steps include the control configuration,
control strategy, and controller type selection. This necessarily
requires the development of dynamic rather than steady state models to
validate the performance of the closed-loop system. Concurrent
engineering does not negate the validation of the open-loop system.
Additionally, criteria (hazard analysis, contingency planning) for
performance validation must be carefully selected and testing must be
carefully planned. In other words, ad hoc testing/verification are not
recommended. Rather, rigorous testing and measures for acceptable risk
management must be planned to validate the system design and control
architecture.

Modeling activity is almost always used to represent the system
response. The typical model development usually yields a
phenomenological (fundamental) quantitative model that is parametric.
Hence, the outputs are highly susceptible to parametric uncertainties,
modeling assumptions, input distribution assumptions, and the functional
forms used. Propagation of errors due to these assumptions should be
quantified for mission readiness. Models of other types are equally
useful -- these include behavioral models developed from symbolic
reasoning and input/output models that represent stochastic nature of
the system. It is recommended that these models be integrated into a
common environment (perhaps a vertical alignment) as specialized end
users may wish to analyze a different performance (actual energy
consumption on a minute basis, trend of energy consumption predicted
over week). It is also recommended that models of human behavior be
developed and validated.

Other recommended integration aids include: hardware and virtual
testbeds and pilot plants and dissemination of data, lessons learned,
and mission scenarios. Data fidelity is a requirement for validation of
the models, verification of the performance measures, and for historical
event analysis.

##### **System Operation and Control**

The challenge in system operation and control is to minimize required
crew oversight of and involvement in the operation of the life support
system. It is expected that the crew may face many unusual operating
conditions, some life challenging. Thus, they must be able to respond in
a timely fashion, and the control system must also respond to
mitigate/regulate the situation without conflicting with crew decisions.
Because there may be more than one operating issue there must be a means
of prioritizing among them from one time shift to the next. What
constitutes an emergency may shift between sampling times; thus
priorities need to be updated dynamically. In addition, what may
constitute a solution at the current sample time may no longer be an
option at the next sample time due to changing resources or criticality
of the situation. Thus, tools are needed to provide prioritization and
risk analysis continuously. Such tools are already available and are
being used by chemical and nuclear industries. For instance, decision
theory, eigenvalue/singular value analysis, life cycle analysis,
environmental burden measures, etc. These tools may have to be modified
to include interactive components as the crew may wish to add symbolic
information available from visual measurements, which may not be
available to these tools in the usual measurement signal format.

Other tools may have to be developed to accommodate contingency
planning, risk assessment, and reactive and adversarial planning. The
ability to predict failures by assessing trends in the data is another
characteristic of such tools. Other approaches such as neural networks
and binary fault tree analysis can provide satisfactory predictions.
Other means to assess trends or signatures in multiple data streams
include: multivariate statistical analysis, wavelet (multi-scale)
theory, and multi-resolution theory.

Since missions are very intensive events, minimizing crew oversight and
involvement in life systems support are imperative objectives. (Although
some group members argued that there may be plenty of crew time on
certain missions such as transit to Mars). To wit, estimating the
optimal autonomous control/human control balance is essential. This
requires a planning model that allows for task scheduling and dynamic
adjustments as tasks are completed or higher priority tasks subsume
lower priority tasks. There are scheduling tools that are being used in
industries such as the automobile industry and discrete event
manufacturing that may provide a very good start at developing a more
specific tool for mission crew. However, the tool must balance active
constraint handling, and time to reach a solution, in the reasoning
approach so that the new schedule or re-appropriation of tasks is
balanced. In fact, scheduling in the chemical industry for large complex
system is often achieved using steady state optimization on a frequency
of weeks rather than minutes.

Machine learning and hybrid systems that use adaptation and
reinforcement learning may provide robust solutions in the case of total
or partial reconfiguration of the system. This situation may be
envisioned as switching to a new operating state when the setpoints and
the inputs to attain this state are not known a priori. By collecting
data and continuous learning from the data, parameter adaptation can be
achieved to determine feasible reference trajectories, speed of
response, and accuracy of response. Of course stable adaptation has to
be assured with an intelligent adaptation scheme.

The overall issue of autonomy must be integrated with system stability
\[Tian et al 2003; Zheng et al 2002\]. Closed and open loop stability
must be guaranteed for all possible autonomous configurations. These
issues are routinely addressed in chemical, nuclear and petrochemical
industries. Currently, linear system-theoretic analysis is applied.
Nonlinear analysis is more difficult to perform analytically and thus
numerical simulation of stability, robust control theory and the
Lyapunov direct method are used to establish stability.

Tools should be developed starting from this basis with customization or
modification for mission limits, constraints, and objectives.

##### **Coordination and Integration of a Distributed Control System**

The control system for an advanced life support system will be
distributed, both in time and in space. Some control components will
reside in the Mars base, some on Earth, some on EVA vehicles, etc.
Communication and coordination of tasks for mission success is shared by
EVA components, the base, the Earth, etc. \[4\]. Issues for a
distributed system are far more complex. Indeed, from a control
perspective is it better to employ centralized or decentralized control
structures considering autonomy, multiple time scales, and shared
resources? Should there be a vertical hierarchy with more autonomy
designated for the high level tasks especially those having to do with
risk management? How should communication and computing be distributed
-- grids for instance? There does not appear to be a COT available. The
only paradigm that comes close (relative) is the one used in the
chemical industry to complete a plant design that involves several
contractors located in different countries. Time is not an issue in this
paradigm while for the space mission, time is essential to critical
decision-making and to contingency planning and communications lags can
be many minutes in duration.

Other related issues -- how to handle data distribution efficiently when
there is an obvious delay in communication that with current technology
cannot be dismissed. The software format itself is not available and
must be developed to address synchronization, off-nominal information,
compression, abstraction, and poor signal-to-noise ratio.

##### **Determining and Predicting System State and Diagnosing Faults**

The location, type, and number of sensors are critical to the
effectiveness of any control scheme and to related applications such as
monitoring, detection and fault diagnosis. Sensor data are also used for
model validation and collectively are used to identify the state of the
system. Currently sensor type is dependent on what is to be measured,
the number of redundant or dissimilar sensors is application dependent,
and the location selected is not necessarily optimal. Tools are needed
to determine the optimal sensor network as a function of the criticality
of the measurement, cost, etc. The system-theoretic state of being
observable can be used to determine if a given set of measurements is
enough to characterize the observed behavior of the system.

In those cases where the reliability of the measurement device is
questionable (sometimes such sensors require heavy maintenance) or the
measurement is not possible, an inferential or soft sensor can be
developed. Usually the inference is obtained from an analysis of other
data \[6\]. Typical tools used to develop this inference range from very
simple, hand-written algorithms to time-series analysis, multivariate
statistical analysis, and even artificial neural networks \[Hoo et al
2001, Gurumoorthy et al 1998\].

While determining the current state of the system is important, the
ability to predict future system states and in particular trends for
faults is also equally important. In the case where the system is not
completely observable, estimates of the state can be obtained using
tools such as Kalman filter, Luenberger observer and other linear and
nonlinear observer methods. Existing tools that can assist with the
development of the observer or filter include Matlab by Mathworks
(Natick, MA).

It is also desirable to have a means to pose "what-if" questions when
studying fault propagation and risk analysis. Most often this is
achieved with numerical simulations (random using Monte Carlo simulation
or Latin hypercube sampling simulations).

##### **Resource Management**

Resource management means knowing where things are, how they are
connected, how much of them you have, what you can make, etc. The
discussion centered on database, sensing, and RF tracking. Data source,
type and fidelity will impact control configuring in terms of
connectivity, autonomy, scheduling, etc. Data fidelity can be improved
using dynamic data reconciliation and multi-resolution theory, data
sparseness can be improved using numerical simulation output or Monte
Carlo simulations, missing data may be replaced with predictions from
artificial neural networks, data analysis can be done with multivariate
statistical analysis. Understanding feasible real-time control (not the
creation of control software) objectives is what is needed here.
Communication is important for obtaining a critical response,
determining controller action in real-time or estimating bounds on
variables.

Resources are not limited to consumables like food and water, but
include crew time, EVA activities, planting, crew abilities and skills.
Thus, interactive scheduling of these kinds of resources with crew and
ground control input is essential. Also necessary are tools to help
manage dynamic resource needs like variable crew sizes and resupply
opportunities. Finally, software configuration and version control for
an advanced life support mission is essential and needs addressing.

##### **Human Interfaces**

Clearly, new paradigms are necessary to permit human interaction with
the hardware and software components of the system. Humans communicate
using all their senses. Some means of translating the output of these
senses (quantitative and qualitative) into a general knowledge
representation and vocabulary (ontology) that can be used readily by the
machine parts of the systems is necessary. In addition, other
communication means such as colors, touch screens, customizable
interfaces (as a function of skill set and role of the user), and other
human factors must be considered in the development of the human
interface. In the chemical, nuclear, electric and pulp and paper
industries, the tool marketed by Gensym (Cambridge, MA) is one tool that
has a knowledge representation parser and interface to their intelligent
reasoning tool. Although still primitive (it does not contain all the
requirements that maybe needed here) it is a starting point well worth
investigating.

*Adjustable autonomy* is a key requirement for autonomous control
systems. Adjustable autonomy means designing a system that minimizes the
necessity for human interaction, but maximizes the capability to
interact. Adjustable autonomy allows a system to operate with
dynamically varying levels of independence, intelligence and control.
This can involve changes in the complexity of commands the system
executes, the resources (including time) consumed by its operation, the
circumstances under which it will either override or allow manual
control, the circumstances under which it will request user information
or control and the number of subsystems that are being controlled
autonomously. NASA has taken the lead in research into adjustably
autonomous systems and a number of prototypes have been designed
\[Dorais et al 1998; Dorais and Kortenkamp 2001; Bonasso et al 1997\].

## **Group 4: Mars Planetary Base**

### **Day Two -- Breakout Sessions: Scenarios**

#### **Identified Needs**

##### **Reliable Sensors**

Under the Mars Base scenario with consideration to the other scenarios,
reliable sensors were identified as a need to ensure quality data
collection by detecting sensor failures, by correcting and adapting for
failures, by self-calibration and recalibration, and by adjusting for
drift. Reliability of a system of sensors will depend on the synergy
between different types of sensors (chemical, environmental,
bio-sensors, etc.) through the use of sensor fusion, data validation
procedures, and data reconciliation. Inferential/soft sensing could also
be critical in this realm. To improve reliability, it is necessary to
develop and implement consistent methodologies and techniques for data
validation, reconciliation, outlier detection, and replacement. This
could include extended Kalman filtering along with other pattern
recognition and signal processing techniques. These technologies should
also be able to asynchronously process independent sensor inputs.
Reliable sensors will likely involve the use of small sensors
(microsensors, nanosensors) and involve the use of
Micro-Electromechanical (MEM) sensors. Such sensors may be considered
miniature laboratories. Other topics to consider include sensor
placement, analysis of failures and accuracy, and minimization of
consumables during recalibration.

##### **Early-Detection of Off-Normal Processes**

Under the Mars Base scenario, early-detection of off-normal processes
was identified as a need to ensure timely correction of batch processes
(e.g., crop harvests, biological waste treatment, cooking) so that
systems are less likely to completely fail. The control system and model
performance monitoring should be used for early detection, so that
astronauts don't have to detect and identify off-normal processes. The
control system should monitor the process and predict the batch state.
The control system should then make any necessary corrections to the
process to enable recovery. The system should also predict and schedule
maintenance. Early detection will likely involve computer perception
(vision, auditory, olfaction, etc.), machine reasoning, machine
learning, and knowledge of the environment, along with modeling and
estimation. These technologies must recognize trends, drifts, and
inconsistencies in the data and be able to separate knowns from
unknowns. Modeling will be critical, and updates to models will be
necessary. It will be important to know when and how to make a
correction per a specific anomaly. To do this, there must also be
knowledge on how to instrument the processes and what data to collect.
Early-detection should be designed to work even if all of the desired
sensors are not available or working. There should be a way to reset
some systems (e.g., reset computer) should the off-normal process be
uncorrectable. However, not all systems, such as crop production, can be
reset.

##### **Communication/Network (Earth - Vehicle & Devices - Vehicle)** 

Under the Mars Base scenario, the need for a communication network to
enable distributed control for redundancy and to provide
guidelines/protocols for command and data exchange was identified. It
must be scalable with distance and will need to include a standard
control architecture and data historian as a fundamental part of the
system. This network must work for Earth to the Mars base, Mars Base to
the remote team, remote team to Earth, and for remote control
situations.

##### **Crew Training**

Under the Mars Base scenario along with consideration of the other
long-term scenarios, crew training was identified as a need. During a
two-year mission on Mars, systems will change through human intervention
to continuously improve operation and through general on-site tinkering.
The crew must be trained to operate the processes and the control
systems. The crew must be trained in what they need to know to maintain
a nominally-operating system. The algorithms used in the process and
control systems are highly specialized and the crew will need to
understand how they work to handle unknown situations that might not be
simulated in training. They must respond to these unknowns through
problem solving by understanding the life support system and its control
and how the algorithms perform optimization, model prediction, and
scheduling. Lessons learned and corporate knowledge will need to be
archived and used in crew training to aid in training new people. This
will involve capturing how decisions were made and something of the
personalities of those decision makers. This also will involve
management of change, which is discussed later.

##### **Comprehension of Complex System Interaction/Compatibility**

For the Mars Base and other scenarios, a comprehension of complex system
interaction and system compatibility was determined to be a need for
control system design and to determine the sharing of functional
responsibility for conflict resolution. It involves data collection,
modeling, simulation, and local versus global optimization.

##### **Management of Change**

For all the mission scenarios, management of change was identified as a
need. It is a set of procedures to ensure that mistakes are not made by
human naivety. It involves knowing if a change or fix is right. It also
involves knowing and trusting the intent of the person making the
change. For example, if the person is suffering from depression or
madness, the change might not be desirable. Management of change is
important to the safety and success of the mission. For it to work, it
will require a consensus for the change so that one person can't be
solely responsible. There is an issue as to whether this consensus
should be entrusted to a few or to all involved in the mission. It will
require keeping Earth ground control informed, but there must also be
remote autonomy due to the distance and delays in communication. Other
aspects that must be included in management of change are protocols,
training, record keeping (activity log), documentation, common language
definitions, and human factors.

##### **Transition Between Operational Stages**

For multi-stage missions such as transit to Mars and decent to Mars
Base, a well-planned transition between operational stages was
identified as a need to ensure system stability. This involves the
start-up or restart of one stage while shutting down another.
Transitions involve the transfer of processing between stages, requiring
interfaces to the control system that would handle parameter changes of
one operation to another. The systems in the next stage must be verified
that they are working correctly. For example, one operation stage could
be an unmanned Mars base and another stage could be the manned version
of that base. Stages would progress from full-up automation to human
habitation with manual control. The reverse would be the case when
humans leave. Since control parameters change when people show up,
simulation of human presence must be included in each unmanned stage.
For example during the transition, systems could be taken out of sleep
mode and the communication networks could be revived. When landing on
Mars, this involves transition between micro-gravity to Martian gravity
(1/3 g). It could also involve keeping existing plants growing between
the conditions of no human presence and human presence. Transition
involves design of the system architecture, modeling, simulation,
distributed computing, logistics, resource allocation and scheduling,
and building functional redundancy into the systems.

##### **Common Technical Language and Symbology**

To improve communications between contractors, cross-disciplines teams,
multinational groups, and a mix of institutions, a common technical
language and symbology was identified as a need for all the mission
scenarios. This common technical language and symbology would include
ontologies, standards, common definitions, unit conventions (SI,
English, CGS to MKS scaling, etc.), and specifications. Such a language
would result in increased precision in communications. It must be
inherent to program management and must reside on a shared database. It
must handle the subtleties between different disciplines. It must be
included in all documents, manuals, and training.

##### **Off-Nominal Data**

Because there is a lack of off-nominal data and because most experiments
push for best or nominal conditions, identifying and collecting
off-nominal data was identified as a need for all the mission scenarios.
Off-nominal data is necessary to generate models that mimic off-nominal
behavior and to develop sensors and controls that will recognize and
respond to those behaviors. This will involve the use of well-designed
experiments, modeling, simulation, physical processes, pilot lab scale
processes, testing and verification, failure mode analysis, and life
cycle testing.

##### **Biomass Production Unit Robustness**

Under the Mars Base scenario and possibly other long-term mission
scenarios, biomass production unit robustness was identified as a need.
This involves ensuring the stability of the crop production system and
its by-products. The biomass production system must be insensitive to
upsets and model uncertainties, or it must be able to recover from
upsets. Upsets can be abrupt or gradual. Problems from upsets can be as
simple as poor taste, to serious problems such as low nutrition and bad
yields, to critical problems such as entire crop failure. In industry,
robustness is ensured by cultivating a combination of crops. On Mars,
other approaches may be required.

The development of a robust biomass production unit will require
well-designed experiments, modeling, and simulation. The models must
consider that a biomass system is a tightly coupled system. The model
must take into account how events affect nutrition and determine ways
for the plants to produce what is needed. The items that need to be
monitored must be identified as well as the data needs for lab analysis.
It must be verified that the models represent the real biomass system.
Finally, models must scale upwardly to a large-scale production of
plants. Other things to consider are the external effects on the biomass
of low gravity, zero gravity, low light levels, no magnetic field, dust
storms, and meteors.

##### **Methodology to Proof Positive**

Under the Mars Base scenario but applicable to all missions, a
methodology to proof positive was identified as a need. This methodology
would be used to develop a high confidence that the processes and
control systems are reliable. It will require an understanding as to
whether the process or control is a data or algorithm problem. It will
require an understanding of the assumptions and a way to verify results.
It also requires knowing how to mature technology. By using experimental
testing and extensive fault/hazard/reliability analysis along with
heuristic knowledge, this methodology would determine when something
worked, at what level of success, and why. This involves verification
and validation of the methodology, including the use of standard
software methodologies and standardization of software coding.

##### **Useful, Appropriate Models for Every Component and the System as a Whole**

Based on the Mars scenario, useful and appropriate models for every
component were identified as a need. These component models would be
used for scheduling, design, training, control, prediction,
optimization, and fault diagnosis, and they must be linked together
(particularly because life support subsystems tend to be very
integrated). To build these models will require well-designed
experiments, cause and effect analysis, and system analysis. The models
must be well documented to make sure assumptions and parameter ranges
within which the models are applicable are known. There must be a way to
continually evolve human knowledge by adding new levels of detail to the
models. Meta-knowledge of the components, systems, and models (i.e.,
knowing "what you know" and "what you don't know") is also important.

##### **System Readiness Level (SRL)**

Based on all of the mission scenarios, development of a system readiness
level to complement the existing technology readiness level (TRL) was
identified as a need. In all the mission scenarios, subsystems must
integrate and it is necessary to know when they are ready for
deployment. The SRL should be a more objectively and quantitatively
defined scale than TRL, and it would be oriented to the system level.
This will require well-designed experiments to test at the component,
subsystem, and system levels. It will also involve defining the SRL
requirements.

##### **Well Designed Experiments**

Under the Mars Base scenario with consideration to other scenarios, a
technical need for well-designed experiments was identified. A good
experimental design will test the limits and generate knowledge of the
space encapsulated by those limits. It includes finding the starting
points to define the requirements and finding a way to get the data
needed to mature the technology. This will involve ground-based
experiments to determine what works and what fails to drive out the
requirements.

##### **Tools/Resources for Testing/Validation of Processes and Control strategies and for Technology Selection**

Under the Mars Base scenario as well as many of the others, testing and
validation was identified as a technical need. Such testing and
validation is necessary for the advancement of technologies for the
missions of focus. Also, crosscutting technologies that apply to
multiple missions or provide multiple functions must be identified.

##### **Standard Control Architecture**

Based on several of the scenarios, a standard control architecture was
identified as a technical need. A standard control architecture would
minimize difficulties with the integration of components into larger
system. It must be based on an open architecture and be amenable to
plug-and-play components.

##### **Selection and Assignment of Control Strategies/Decision Processes**

Based on all of the scenarios, a process or methodology for selecting
and assigning the control strategies and decision processes was
identified as a technical need. The methodology would determine how to
pick and choose the appropriate control strategy and decision process
for the specific application. This is needed because every vendor will
indicate that theirs is the best technique.

##### **Planetary Protection**

Under the Mars Base scenario, planetary protection measures were
identified as a technical requirement, both to control Earth biological
contamination (e.g., via microorganisms) of Mars and to control possible
contamination of Earth and the Mars Base itself. Based upon policy
directives and science goals in place at the time of the mission, a
protocol may be needed for managing all materials that could potentially
contain biological markers. If astronauts will potentially contact areas
of Mars that may support martian life, the life support system should be
capable of providing sequestration of areas exposed to novel martian
materials, as well as being capable of taking conservative measures with
respect to biological marker contamination.

#### **Existing Technologies be Adapted to Spaceflight**

In many cases, existing technologies can be adapted for spaceflight. In
many of the cases technologies still need to advance. This can be done
both inside and outside of NASA, but NASA needs to be a driver to ensure
the needed technologies are matured at the appropriate times.

### **Day Three -- Breakout Sessions: Topics**

#### **Solutions**

Out of the Mars Based mission scenario, seven solution areas were
identified:

-   Good Data and Modeling (off-nominal/nonlinear interactions),

-   Information Processing and Decision Making/Support Algorithms,

-   Process and system Design,

-   Methodologies and Guidelines,

-   Things that Must be Managed/Supervised,

-   Programmatic Decisions, and

-   Human/computer interaction.

##### **Good Data and Modeling (off-nominal/nonlinear interactions)**

This solution area centers on the need for good data that represents
real systems and includes off-nominal conditions for use in developing
accurate models of integrated subsystems. This solution is of the most
critical importance and has the potential to benefit all areas of life
support controls. Many of the needs mentioned in previous sections would
benefit from well-planned data collection and modeling efforts, as would
many technical needs that were not explicitly stated in previous
sections. Effective data collection and modeling must be done for the
entire realm of both nominal and off-nominal operating space.
Additionally, because of the possible high degree of interaction between
life support subsystems, data on potentially interacting parameters must
be collected in order to identify any significant interactions. All data
collection efforts should be carried out according to proven quality
assurance/quality control (QA/QC) practices and made available to
modelers in the life support community. While derived from Mars base
discussions, it is applicable to all missions. This area covers
identified needs for early-detection and correction of off-normal
processes; computer perception where computers use
visual/auditory/olfactory sensing for making predictions analogous to
human sensing analog; comprehension of complex system interaction and
compatibility; reliable sensors; off-nominal data; useful and
appropriate models for every component and the system as a whole; and
transition between operational stages. Solutions to these problems and
needs include the following:

-   Data archiving - This is mature.

-   Inferential sensors - This area is mature for physical-chemical
    processes but could require research for biological processes.

-   Data validation - This currently needs a lot of human intervention.

-   MEMs - These are currently in development.

-   Generation of models - There is confidence in existing
    physical-chemical models. Research is needed for biological systems.
    There is a clear need for test facilities and experiments designed
    to collect the data of nonlinear dynamic interactions and
    off-nominal processes.

-   System models - Currently there is a need to study hidden
    interactions and incorporate these into the models.

-   Diagnostic tools - These tools currently are poor on cause and
    effect relationships.

-   Automate generation of causal models from Data - This is currently a
    largely manual process.

-   Six Sigma Techniques - This is mature in industry.

-   Computer Perception that includes visual, auditory, olfaction, and
    machine intelligence. This is currently in development.

-   Data Mining - It is established with linear techniques, but
    currently does not incorporate cause and effect. This is an area for
    development. Also, realistic data is needed.

-   Shared Data Base - Realist data is needed.

-   Distributed Processors - This area is a development area.

-   Best Practices in Industry - Look to examples that are well
    established in industry (e.g. DuPont).

##### **Information Processing and Decision Making/Support Algorithms** 

This solution area, derived from Mars base discussions though more
widely applicable, covers identified needs for human-free techniques for
scheduling and optimizing in constrained, nonlinear problems/situations
and exploration of near or off-optimum solutions. Solutions to these
problems and needs include the following:

-   Hardening

-   Autonomous agents - Look at what is commercially available - This
    hasn\'t started yet at NASA.

-   Multi-objective/Pareto optimization - This topic is in research
    development.

-   Evolutionary Computation (e.g, genetic algorithms, stochastic
    techniques) - This is in research and development with some
    industrial use.

##### **Process and System Design**

This solution area looks at process and system design and draws heavily
on standard practices of industry. While derived from Mars base
discussions, it is more widely applicable and covers identified needs
for communication/network; biomass production and physical-chemistry
process and control system robustness; and transition between
operational stages. Solutions to these problems and needs include the
following:

-   Deploy distributed processing to provide some redundancy. For
    example, fly four units each a third of the needed capacity and run
    three of four units during the mission with one saved for backup --
    This is mature in industry and is commonly applied.

-   Use a distributed computing over the network instead of hierarchical
    computing -- This is mature in industry.

-   Perform "what if" analysis for hazard and transition events -- This
    is mature and common practice in industry.

-   Employ SCADA (supervisory control and data acquisition) systems --
    This is mature in many industries.

-   Employ advanced control techniques -- This is mature in industry.
    They use a variety of techniques including feedforward, cascade,
    ratio, select, multivariable control, model predictive, neural
    network, fuzzy logic, expert systems, etc.

-   Prioritize tasks -- This is standard and mature in industry, but is
    currently a human-performed task in NASA.

##### **Methodologies and Guidelines**

This solution area, derived from Mars base discussions though more
widely applicable, covers the following identified needs:

-   Common technical language and symbology;

-   Management of change;

-   Standard control architecture;

-   Definition of a System Readiness Level;

-   Tools and resources for test/validation of processes and control
    strategies and technology selection;

-   Selection and assignment of control strategies and decision process.

Solutions to these problems and needs include the following:

-   Getting involved in industry consortiums -- This is a mature area.

-   Adapt NASA internal language to industry standard -- This area needs
    work.

-   Revise the system engineering process to define SRLs -- This has not
    started.

-   Engage systems engineering at early stage.

-   Engage control community at early stage.

-   Engage the process design community in NASA efforts (e.g.,
    engineering and construction community, CH2MHill, Bechtel, etc.) --
    This has not started.

-   Identify challenge problems -- This requires a culture change, but
    is common in other areas.

##### **Things that Must be Managed/Supervised**

This area covers things that need to be managed and supervised. It was
derived from Mars base discussions but is more widely applicable.
Example areas that it covers include selection of crew skill set and
training to perceive interaction effects and interpret problems; the
transition between operational stages, and the evolution of operational
strategies. Solutions to these problems and needs include the following:

-   Standardizing all procedures and algorithms including scheduling,
    optimization, and diagnostics.

-   Engaging training experts to train people effectively.

-   Using an operator training simulator -- This is mature technology.

-   Using a training room for problems within Advanced Life Support
    (ALS).

-   Using open standards -- This is a developing area for ALS but it is
    mature in many places.

##### **Programmatic Decisions** 

This solution area involves decisions at the programmatic level.
Although the discussions were derived from the Mars base scenario, this
topic is widely applicable. Example areas that require programmatic
decisions include planning for planetary protection needs and resource
sharing between concurrent programs (e.g. an orbiter may provide you
information that you need for future planning, resulting in value
added). Solutions to these problems and needs include the following:

-   Cross Program reference missions -- This is an evolving area.

-   General set of possible requirements for planetary protection,
    including scientific and political needs

-   International collaboration

-   Advanced controls advisory group made up of experts

##### **Human/Computer Interaction**

This solution area was derived from Mars base discussions, though more
widely applicable, covers identified needs in how humans and computers
interact such as virtual advisors and a common human interface
presentation and actions. A virtual advisor is an adaptive/self-learning
agent that observes what is happening, provides causes and suggests
investigation approaches/likelihoods. The common human interface
presentation includes visual, auditory, and touch. Solutions to these
problems and needs include the following:

-   Cross Program reference missions -- This is an evolving area.

-   General set of possible requirements for planetary protection,
    including scientific and political needs

-   International collaboration

-   Advanced controls advisory group made up of experts

-   Machine learning -- This is a research topic.

-   Human centered computing -- This is at the prototype stage.

-   Assistant agent technology -- This is at the prototype stage.

-   Other simulators such as flight, chemical plant, shuttle, and
    military simulators -- This is mature for commercial areas, but not
    for ALS.

-   Usability engineering -- This is a mature area.

-   Human factors engineering -- This is currently at the research stage
    but with much work in specific areas including industrial plants,
    software, etc.

-   Build a Mars flight simulator (including ALS) and place it on
    Internet for students to play with (e.g., Bioblast) to test and
    develop interfaces

-   Abnormal situation management, which uses existing expertise in
    dealing with off-nominal cases in control room and operating room
    interfaces (e.g., alarms, prioritizing events) -- This is mature in
    industrial areas (e.g., Honeywell, Invensys, Rockwell, Emerson,
    etc.), but not in ALS.

## **Group 5: Ground-Based Human-Rated Test Facility and Mars Planetary Base**

### **Day Two -- Breakout Sessions: Scenarios**

#### **Identification of Needs, Problems, and Challenges**

During the breakout session on day two, Group 5 focused on
identification of needs, problems and challenges facing advanced system
integration and control for life support relating to two mission
scenarios: ground-based human-rated test facilities and a Mars planetary
base. The group began by brainstorming, in which group members
identified top problems; most were given in the form of questions.
Initially, 40 problem areas were identified, which were later reduced to
35 by combining and merging those that were judged to be conveying the
same idea. Problem areas for the two scenarios were combined into one
list, as it was perceived that ground-based test facilities would be
developed to ultimately evaluate planetary base architectures, and so
the two scenarios had similar challenges. The problem areas were then
ranked by voting, with each group member choosing ten problem areas that
were felt to be most important. A ranking score, a value from 1 to 7,
with lower values being more important, was assigned to each based on
the number of votes received. The problem areas were then grouped into
eight natural categories: Modeling, Simulations and Knowledge; Planning
& Scheduling; Robustness & Fault Protection; Situation Assessment and
Awareness; Systems Analysis; Testing and Verification; Control System
Architecture; and Crew Autonomy.

1.  **Ranked Needs, Problems, and Challenges**

This section provides a listing of needs, problems and challenges that
were developed by Group 5 during the Day Two breakout session. The
needs, problems and challenges are grouped into one of eight categories
(Modeling, Simulations and Knowledge; Planning & Scheduling; Robustness
& Fault Protection; Situation Assessment and Awareness; Systems
Analysis; Testing and verification; Control System Architecture; and
Crew Autonomy). Within each category, the needs, problems and challenges
are listed in priority order. Those that ranked within the top 11 out of
35 are listed in italics. Detailed discussion of the highest ranking
problems were performed during the breakout groups on the third day of
the workshop.

**Modeling, Simulations and Knowledge**

-   What systems can be used to capture corporate knowledge gained from
    long duration integrated test facilities and off-Earth facilities?
    What is the best way to capture and transfer knowledge between NASA,
    contractors (who have private interests) and international partners?

-   How can the amount of required modeling work for an advanced control
    system be minimized, given the expected diversity and complexity of
    all elements, each with different requirements and needs: hardware,
    low level control systems simulation, artificial intelligence
    models, etc.

-   Developers of life support hardware need to have defined
    requirements for information that is to be provided to control
    system designers for development of control systems involving their
    technologies, including models and simulations.

**Planning & Scheduling**

-   How does a control system manage and plan for the long time
    constants of certain biological processes that lead to changes days,
    even months later? How does a control system reconcile between
    discrete events, continuous processes and systems with a wide range
    of time constants?

-   How can a control system be set up to support strategic mission
    decisions, such as launch readiness, mission abort/return home
    decisions and procedures?

**Robustness & Fault Protection**

-   How can autonomous software be set up to learn from what goes wrong,
    since mission designers can't always predict before hand all failure
    scenarios and required control system responses prior to flight?

-   How robust does the control system need to be (stability;
    insensitivity to external and internal stimulus)?

-   Control system modes for safe haven vs operations?

-   How will the life support control system compensate for off nominal
    power, energy and thermal fluctuations, with reference to
    physicochemical and/or bioregenerative systems, including crop
    systems?

-   How can the control system detect, diagnose and adjust to network
    failures?

-   How can we provide adequate, robust, state-of-the-art computing
    power in the space environment, including fault tolerance, spares,
    distributed architectures?

**Situation Assessment and Awareness**

-   Human situation awareness in a largely unattended situation.

-   Develop real time prognostic capabilities to predict failures before
    they occur and sense degradations before they have impact.

-   In very large and complex systems, how can we synchronize system
    states across subsystems?

-   What is the best balance of approaches to confirm reliability of
    data from sensors? Three general approaches have been identified: 1)
    sensor redundancy; 3) in situ calibration; 3) indirect analytical
    methods to confirm sensor function and accuracy through measurement
    of other process characteristics and parameters. Are expected values
    for sensor measurements calculable using other data that is
    available?

-   What integrated system characteristics and conditions need to be
    sensed to make control decisions or to inform crew?

**Systems Analysis**

-   What is the correct balance and trades between buffers and controls
    to ensure safe & reliable operation of an advanced life support
    system?

-   What is the correct balance between added launch mass for
    replacement parts, spares and other consumable maintenance materials
    against planned repair and novel maintenance functions performed
    real-time during missions? How can maintenance and repair functions
    be accommodated by the control system? What are the interfaces and
    interferences?

-   What important control parameters and functions are limited by lack
    of sensors? Sensors can't be everywhere. How can the choice of and
    location for sensors be optimized?

-   Is there a quantitative way to measure the performance of a control
    system that will support control system development and control
    system trade studies, including evaluation, comparison, design and
    real-time adaptation?

-   Is special life support for "sick" crewmembers required (specialized
    environments, isolation, enriched oxygen, hypo/hyperbaric chambers)?
    Is it a control problem? Is it a life support systems or medical
    requirement?

**Testing and verification**

-   How can we get useful results during integrated human tests when
    human life and safety is at stake? Such tests have often been
    success oriented and limited to technology demonstration within
    conservatively safe boundaries of hardware operation. Pushing
    systems to their limits by pushing the envelope, limiting resources
    and injecting real faults may be necessary to gain the most
    knowledge but may put the crew at risk or cause the tests to fail.
    Systems may need to be put through planned multiple failures to
    obtain the most information.

-   How can we verify software to reliability levels for human safety?

-   How can the ground based test bed control system mimic conditions,
    faults and constraints that may be imposed by the planetary
    environment of Moon or Mars for more realistic simulation, including
    mimicking leakage from large delta pressures, EVA use of airlock and
    associated gas losses, thermal impacts and energy availability?

-   How can gas dynamics, sensing and distribution be monitored and
    controlled for cases where the space vehicles and or ground-based
    test facilities are compartmented, resulting in physical separation
    of gas volumes?

-   How are combinations of technologies to be selected for evaluation
    in ground-based scenarios given test opportunities will be both
    limited and expensive? What are the advantages and disadvantages of
    conducting a few long term tests vs many short term tests?

**Control System Architecture**

-   How do we design an effective control system with flexibility,
    modularity, growth potential and anti-obsolescence to accommodate
    new, varied and unknown test articles, using standardized hardware
    interfaces?

-   How do you plug & play hardware and software without adversely
    affecting the running system?

-   What are the control interfaces between ECLSS control systems and
    the control systems for thermal, electrical power, communications
    and other systems that interface with ECLSS?

**Crew Autonomy**

-   Ground/mission control -- when do you want it, why do you want it?
    What is the role for Earth-based mission control?

-   How do we enable the crew to do a safe and effective manual
    over-ride, including case without mission control

-   How do we incorporate the crew as components of the control system?

-   What are the criteria to determine the level of autonomy or human
    involvement in control?

-   What is role for ground based systems to support flight and how do
    we deal with divergences between ground and flight systems?

### **Day Three -- Breakout Sessions: Addressing the Solutions**

#### **Identification of Solutions, Technologies, or Research Areas**

During the breakout session on day three, Group 5 focused its attention
on identification of solutions to the top problem areas facing advanced
system integration and control for life support relating to the two
mission scenarios considered by the group: ground-based human-rated test
facilities and a Mars planetary base. The approach taken was to step
through each problem area, in ranked order from most important to least
important, conduct a general discussion to further define the problem,
identify the status and state of the art especially with respect to
industrial solutions and list examples if available. Due to time
constraints, the group was only able to discuss the top 11 needs,
problems, and challenges.

#### **4.6.2.2 Top Needs, Problems, and Challenges and Identification of Solutions and Existing Technologies** 

This section provides a summary of discussions of the top 11 needs,
problems, and challenges in ranked order from highest to lowest
importance. For each need, problem or challenge, the general discussion
is summarized, with notes on the state of the art (with emphasis on
industrial solutions) and examples, if available.

-   How do we design an effective control system with flexibility,
    modularity, growth potential and anti-obsolescence to accommodate
    new, varied and unknown test articles, using standardized hardware
    interfaces?

Ground-based human-rated test facilities should not be used solely to
evaluate the integration of prototype hardware used to provide the basic
functions of advanced life support, but also evaluate potential software
and hardware used to control the integrated systems. Thus the control
system needs to be considered to be a test article as well.
Historically, control systems implemented in test facilities have
provided basic control functionality, are fixed on an infrastructure of
a particular suite of control and communications hardware and software
and are thus relatively inflexible, and are designed for test operations
rather than development.

Setup for new test configurations and test articles can be a laborious
process, requiring extensive control system software recoding,
restringing data and communication lines and altering test article
hardware interfaces for compatibility with the facility control system.
It is desirable for the test facility control system infrastructure,
including control system hardware, software and data networks to be
flexible and modular, provide for control system growth and
anti-obsolescence, and allow for substitution of new control
technologies as they are developed. In addition, the control systems
must be flexible to accommodate future test articles and test
configurations which will be ever changing and have unknown
requirements. Interfaces to the control system need to be fixed and
defined so that developers of test articles can easily integrate their
hardware into the test facility. This requirement for defined and fixed
interfaces will be a challenge given the almost opposite requirement for
control system flexibility, changeability and reconfigurability. For
example during some tests it is expected that even the interfaces
between the control system and test articles could be under evaluation.

Preventing control system obsolescence will also be a challenge. New and
more powerful control system hardware becomes commercially available on
a daily basis. What is the correct approach and set of requirements for
the design or selection of generic, flexible and reconfigurable control
software? How do we gather information for and what tools are available
to support trade studies for control system decisions, including whether
to develop and manufacture hardware in-house or buy commercial
off-the-shelf (COTS) hardware, or whether to write unique control code
or buy COTS control software?

The commercial process control industry faces similar challenges
relative to control system obsolescence, reconfigurabiltiy and
upgradeability. Control hardware is an investment. Hardware is
entrenched in plants and continues to be serviced by the control
industry tens of years later. Backward compatibility generally exists in
control hardware. New hardware trends on the horizon include smaller,
faster, and more distributed systems and sensor networks. There is a
plethora of hardware available with standardized protocols. What are the
new trends in standardization? MIL-STD-1773 defines a communications
bus, widely used for on-board command and telemetry transfer between
military spacecraft components, subsystems and instruments, and within
complex components themselves. Deep Space One used a "publish and
subscribe" architecture. Communications middleware can eliminate
incompatibilities and substitute for lack of standardization in hardware
and software. Commercial compatibility is on the lowest level, the
function, device and firmware controller level, which are often
distributed and disparate. Less compatibility is on higher levels, the
network, visualization and applications levels. Communications
middleware is used to provide compatibility and interoperability between
the two levels, allowing heterogeneity in hardware, firmware, software,
networks, applications and operating systems. Control system
reconfiguration and plug and play is still in the research stage.

-   Human situation awareness in a largely unattended situation.

During long duration planetary exploration missions it is expected that
crew time will be at a premium. Crews will need to have a high level of
productivity and will need to be focused at accomplishing the objectives
of the mission, including tasks associated with science and discovery.
Life support and other spacecraft systems will need to function
autonomously in the background, with minimal real-time crew involvement.
When human involvement or intervention is required, it must be focused
and facilitated by the control system. Providing the right amount of the
correct information at the right time to the crew will be critical for
optimal productivity and to reduce information overload.

This is an active research area for both industry and the government.
Work in this area includes modeling tasks by tracking or by anticipating
roles and responsibilities and associating the information necessary to
perform those tasks. Human situation awareness is a topic area that
addresses this question and is addressed in the fields of man-machine
interaction, human interface design, industrial psychology, supervisory
control and C^3^I (Command, Control, Communications and Intelligence).
Human situational awareness is an important research area in aviation,
including air traffic control. To perform any difficult control task
such as flying an aircraft, operating a chemical plant, controlling a
power grid, or exercising military command it is necessary to have a
grasp of the overall situation. Government organizations active in this
area include the Defense Advanced Research Projects Agency (DARPA) and
NASA through the Space Human Factors Engineering element of the Advanced
Human Support Technology Program. The goal of Augmented Cognition
(AugCog), sponsored by DARPA, is to extend the information management
capacity of the human-computer integral by developing quantifiable
enhancements to human cognitive ability in diverse, stressful,
operational environments, ultimately improving human performance. AugCog
seeks to improve the way humans interact with computer-based systems,
advance systems design methodologies, and fundamentally revolutionize
decision making. NASA and military mission control systems use
variations of C^3^ architectures that include situational awareness but
are structured for remote centralized command and control.

-   *How does a control system manage and plan for the long time
    constants of certain biological processes that lead to changes days,
    even months later? How does a control system reconcile between
    discrete events, continuous processes and systems with a wide range
    of time constants?*

An advanced life support system will be an implementation of multiple
component processes within discrete subsystems that are integrated into
larger systems that function as integrated processes. A classic
illustration of potential system complexity is the CELSS reference
configuration. Each process will have individual time constants and
specific interface requirements. Individual processes may be carried out
in batch or continuous modes. Control will be implemented on the
component, subsystem and system levels. Time constants for each
component, subsystem or system process will range from extremely rapid
(milliseconds to seconds) for many discrete events (e.g., operation of
valves, sensing states and conditions), intermediate (minutes to hours)
for many physicochemical processes and multistage tasks (e.g.,
adsorption and desorption of beds, refilling tanks) and long (days to
months) for many biological processes (e.g., bioreactors & crop
production systems). The multitude of tasks, the varied time constants,
and the limited availability and dependency of resources, products and
byproducts poses a significant challenge to control system design.

This is an active area of research and development and has been applied
more completely in government applications than industry. A primary area
of focus is that of development of layered software architecture, where
the various levels have different functions and information is
abstracted. Two examples of this architecture in government applications
are Remote Agent and Three-Tier (3T) Autonomous Control Architecture.
Remote Agent was developed for command and control of autonomous
spacecraft systems and was flown on Deep Space 1 as a technology
validation flight experiment. Remote Agent is made up of three
components which each play a significant, integral role in controlling
the spacecraft: 1) The Planner and Scheduler (PS) produces flexible
plans, specifying the basic activities that must take place in order to
accomplish the mission goals; 2) The Smart Executive (EXEC) carries out
the planned activities; 3) The Mode Identification and Recovery (MIR)
component monitors the health of the spacecraft and attempts to correct
any problems that occur.

The 3T Control Architecture was developed at NASA's Johnson Space Center
and demonstrated for control of gas transfer and water recovery systems.
3T consists of three concurrently operating tiers of closed-loop control
processing, which permits execution monitoring and reactive replanning
and reconfiguration in response to dynamic changes in the environment.
The top layer (the "planner") incorporates models and predicts the
control tasks required to achieve control objectives. The middle layer
(the "sequencer") reactively selects and orders procedures to accomplish
the planned tasks passed to it by the top tier. This is accomplished by
decomposing high-level planned tasks into low-level procedural steps
appropriate for the particular control situation. The bottom tier (the
"skill manager") interfaces with the hardware to execute basic
monitoring and control actions passed to it by the middle tier.
Industrial applications of layered architecture have been limited.
Implementations have generally not incorporated more than two layers and
don't allow operation outside of nominal boundaries.

Biological systems offer a particular challenge to model-based control.
Crop plants pose a particularly difficult modeling problem. Currently,
Advanced Life Support is investigating approximately 15 unique crops.
Each may have multiple choices of cultivars, each which respond
differently to 5 cardinal factors and13 mineral nutrients, creating
complicated multivariate response surfaces. On the other hand,
biological systems are responsive, can easily be throttled up or down,
and may be self-healing. Crop systems that utilize artificial light will
be significant users of electrical power which will impose requirements
for real-time systems optimization and resource scheduling upon the
control system.

-   Develop real time prognostic capabilities to predict failures before
    they occur and sense degradations before they have impact.

It is desirable for a control system to have prognostic capability to
predict failures before they occur and to sense degradations in
performance before they have impact so that preventative maintenance or
other steps can be performed to maintain systems operation and
performance continuously with minimal perturbation. Implementation of
this may be model, anomaly or learning based, and may include mining of
historical data to learn trends or signatures of pre-failure states or
to characterize hardware and component life and reliability.

Use of system models may be vital for prediction of the response,
interactions, performance, trends and states for crop production
systems, biological systems including waste processors, physicochemical
systems, and the cabin environment. Modelers will need data to develop
models. Some data may be available from integrated testing (such as the
Lunar Mars Life Support Test Project) and flight programs (such as ISS
and Shuttle) but will likely be insufficient, either because it may be
incomplete, not addressing all factors, or may not be accessible to
other groups. It needs to be determined what level of detail of models
will be necessary and how such as system can be validated

This is an active research area and has been implemented in industry.
Within NASA, Integrated Vehicle Health Management (IVHM) systems are
being developed for the Second Generation Reusable Launch Vehicle (RLV),
crew, and cargo transfer vehicles. These highly integrated systems will
likely include advanced smart sensors, diagnostic and prognostics
software for sensors and components, model based reasoning systems for
subsystem and system level managers, advanced on-board and ground-based
mission and maintenance planners, and a host of other software and
hardware technologies. The NASA Aviation Safety Program is investing in
aviation system modeling with the goal to reduce accident rates.
Technologies under study at NASA will alert pilots of loss of control in
time to take action-or take action for them. Vast amounts of data
available within the aviation system are being used to identify and
correct aircraft system problems before they lead to accidents. It
includes examination of data from flight data recorders and other
cockpit resources for model development and error detection using the
Crew Activity Tracking System (CATS). Boeing has a commercially
available safety management system.

-   *How can a control system be set up to support strategic mission
    decisions, such as launch readiness, mission abort/return home
    decisions and procedures?*

Should a control system perform strategic decisions normally reserved
for mission controllers, such as launch, mission abort and associated
procedures? There may be cases where a remote crew is isolated from
mission control or when a crew is unable to make these decisions due to
lack of training or incapacitation. In some scenarios, the crew may not
be able to respond quickly enough. What decisions are appropriate to be
taken over by a control system? Would it be better for a control system
to serve in decision support mode, providing information and
recommendations to support a decision by the crew? How would a control
systems decision or recommendations be validated? Mission critical
decisions require many trade-offs, may have many alternatives and there
may be no right or wrong answer. Information necessary will include
system history, current states, probabilities, models to predict and
characterize various outcomes. This topic is in the discipline area of
decision theory. It is a specialized field, limited to experts in
consulting positions using analytical tools. One aerospace application
is launch plume analysis prior to launch.

-   In very large and complex systems, how can we synchronize system
    states across subsystems?

Large and complex systems such as regenerative life support systems will
have many simultaneous integrated processes and will require multiple
decisions to be performed simultaneously. How can all systems,
subsystems and components be provided with current states and values in
real-time? This is a question relating to distributed systems and
networking. Data latency must be accommodated within the design. Network
or communication failures may isolate sections of distributed systems.
Systems must be able to function when communication has lapsed and
recover smoothly once communications are re-established.

Techniques to synchronize data and recover from communication faults
exist, but may be hard to implement. In deep space missions, protocols
exist for communication data transfers. Buffers in spacecraft are not
deleted until ground confirms the transfer. Parallels exist in
communications between Mission Control and the ISS -- communication is
not continuous and orbit synchronization issues exist. A Distributed
Collaboration and Interaction (DCI) system has been developed by NASA to
address difficulties in human-agent interaction and to create an
environment in which humans and mostly-autonomous software agents
together can form an integrated multi-agent system. In this system,

different decision making components get different levels of data to
make decisions.

-   *What is the correct balance and trades between buffers and controls
    to ensure safe & reliable operation of an advanced life support
    system?*

This question addresses the need for physical buffers (such a process
water tanks, gas reservoirs, etc.) between systems, subsystems and
component technologies of an advanced life support system and how an
advanced control system could be used to reduce the need or size of
these buffers. Buffers are often exploited if one or more processes with
interdependence on resources such as source or product streams have
different time constants or occur at different rates and cannot be
throttled. Also, if certain resources are limited and sharing must occur
serially rather than concurrently, holding tanks or similar buffers must
be utilized to pass products from one intermittent process to another.
An advanced control system may replace the need for buffers by carefully
orchestrating all processes simultaneously, but will likely do so with
narrow envelopes of performance and little room for error. This is
easier when the rates of component processes can be adjusted. Buffers
are more important for batch processes than continuous processes and
provide operating margin for when rates of component performance decline
or when certain failures occur. Buffers offer a level of insensitivity
to anomalies and system instability and a level of protection from
unknown events. In industry, buffers are inventory and holding inventory
is costly. Resources are carefully scheduled and reduced to minimum
levels.

One solution to eliminate buffers between individual component
technologies is to combining several functions into a single technology.
For example, integration of the ISS Carbon Dioxide Removal System (CDRS)
with the Sabatier Carbon Dioxide Reduction System (CRS) requires a
compressor and accumulator between the two units, in-part because each
as a different operating cycle. The Temperature Swing Absorption
Compressor (TSAC) might be configurable to serve simultaneously as both
a carbon dioxide removal system and compressor and to operate on the
same duty cycle as the CRS.

Crop systems are multifunctional, revitalizing the air through
photosynthesis and purifying water through transpiration while producing
food. Crops and other biological technologies are tunable systems --
growth rates can be ramped up or down, but depend on the availability of
power for lighting and temperature control. Adjusting crop growth rate
to meet short term requirements such as air revitalization will affect
the quantity and timing of yield and so must not be done except in a
systems optimization context. Biological systems act as buffers and can
contain a considerable quantity of standing biomass. Waste products can
be considered buffers if components are recoverable and not deadlocked.
Buffers may be required in some cases. Water processing systems need
tanks to hold product water because human usage of potable and hygiene
water is intermittent and because tests to certify water to potable
specifications using conventional microbiological tests can take several
days. If real-time potable water sensors are available, the size of
holding tanks could potentially be reduced.

-   *What is the correct balance between added launch mass for
    replacement parts, spares and other consumable maintenance materials
    against planned repair and novel maintenance functions performed
    real-time during missions? How can maintenance and repair functions
    be accommodated by the control system? What are the interfaces and
    interferences? \[4\]*

Flexibility of the control system is provided, to accommodate changeout
or repair of hardware during the mission, without impacting the
essential life support functions. Appropriate applications are made of
component redundancy and/or other methods of accommodating this hardware
changeout. Human involvement is, in most cases, required to change
components or make repairs.

Planned maintenance is designed for in life support systems, in order to
maintain high functional reliability. However, life support systems are
also designed for recovery from unforeseen breakdowns and accidents. The
resulting need to replan to accommodate unplanned maintenance requires
replanning automation. Model-based control systems allow this automated
replanning, in that control is not modified but the model is modified to
adapt to the unplanned situation.

Biological systems have a degree of capability for self repair, which is
modelable. Such models need to be extended in terms of the bounding
factors for biological systems, to accommodate anomalous conditions.

Multiple smaller parallel processors constitute a control systems trend
to be utilized. If one of these processor units is lost there is less
upset to the life support system. This strategy also allows handling of
capacity variations through scaling of processes.

Burn in of electrical components is a method used to detect early
failures before operational use in a mission. During the mission,
component monitoring can be used to predict component failure, but this
requires the collection of specialized monitoring information.

Commercial practice in process control systems is to provide "k out of
n" redundancy at the component level. Commercial chemical plants cannot
afford to shut down, and hardware-based reliability solutions are
practiced.

Reprogramming of controls during space missions is practiced to an
extent. The Cassini, Remote Agent, and Deep Space One systems include
managers that track system health, have knowledge of control
alternatives, and use configuration management for changes in system
configuration. Error detection and correction are performed within
onboard software for single point upsets. Control system flexibility is
in place with current deep space robotic missions, but this remains an
area for further research. The Reliable Systems Community is a resource
to be accessed. Support for novel repairs in life support systems is an
open challenge.

-   *What important control parameters and functions are limited by lack
    of sensors? Sensors can't be everywhere. How can the choice of and
    location for sensors be optimized? \[4\]*

Improved sensors within life support systems can be employed to design
control systems that allow decreased fluid buffers, thus reducing system
mass. In microgravity, without natural convective flow mixing, there is
a greater potential for spatial differences in fluid qualities,
necessitating a greater degree of spatial sensing.

Currently we lack adequate sensing of trace contaminants in life support
systems fluid flows, both air and water, to ensure human safety under
all expected mission conditions. This includes sensing of pathogens that
affect humans and those that affect higher plants and bioreactor
microorganisms used in bioregenerative life support systems.

Improvements to existing sensors for parameters such as oxygen
concentration and atmospheric humidity may use instruments such as mass
spectrometers that add more complex maintenance and input requirements.

In-place self calibration and/or long-term stability of sensors are
issues that must be addressed for remote human missions. Water sensors
have particular difficulties in this area when subjected to low flow and
biofouling.

The NASA AEMC program element is tasked to develop new spacecraft
environment and life support system sensors. An example is the tunable
diode laser, in development as a solution for atmospheric trace
contaminant monitoring. A related recent effort, Sensors 2000, was
conducted by the Fundamental Space Biology Program.

On the horizon is the technology of sensor nets. It is anticipated that
the process control industry will develop this technology, including
sensor development and networking.

-   *What systems can be used to capture corporate knowledge gained from
    long duration integrated test facilities and off-Earth facilities?
    What is the best way to capture and transfer knowledge between NASA,
    contractors (who have private interests) and international partners?
    \[4\]*

Knowledge management is a programmatic challenge to be met by the AEMC
program element. Today, knowledge management systems exist within
various programs, but there is a lack of consistency. Procedures will be
put in place to ensure that knowledge generated under AEMC is
identified, captured, managed, and transferred to appropriate user
programs. The specific requirements for this knowledge management
process must be described. A key aspect will be the development of
technical standards.

Among NASA research and technology programs, the Engineering for Complex
Systems Program and the KSC Biomass Production Chamber project are
examples of employing knowledge management principles. Other government
program examples include the Aviation Safety and Security Program.
Industry examples include products from IBM, Documentum, Plumbtree, and
Verity.

-   *Ground/mission control -- when do you want it, why do you want it?
    What is the role for Earth-based mission control? \[4\]*

On a planetary exploration mission, it is anticipated that crew
autonomy, the ability for the spacecraft crew to conduct the mission
without realtime support from Earth personnel, will be critical to
mission success. Development of this capability requires a large change
in programmatic strategy from the Space Shuttle, ISS, and even the
Apollo programs. Some support from Earth mission control will still be
essential, even when the exploration crew is at Mars, with
speed-of-light communications delays of 6 to 40 minutes roundtrip.
Non-realtime support will continue to be important to mission success.

To fully address the issue of Earth-based support to the mission, a
systems analysis of the entire ground-spacecraft-crew system must be
performed. This would consider the roles of ground personnel, space crew
personnel, and automation in carrying out mission functions. It is
anticipated that this systems analysis will show that mission control
should be used as an extension of the crew with shifting involvement and
flexible allocation of tasks over the duration of a Mars mission, versus
the currently inflexible task allocations made for low Earth orbit
missions. The analysis will also involve modeling and planning crew
involvement in mission tasks from a systems optimization point of view.
This will lead to an understanding of the need for spacecraft life
support control system autonomy to maintain a reasonable crew workload.

The Brahms system is a simulation program for modeling work
practices\--the combination of facilities, organization, tools, and
processes by which work gets done, in contrast with system dynamic
models that aggregate agent behaviors and process simulation models that
idealize functions and logistics. Brahms has been used to develop
model-based, distributed architectures that integrate diverse components
in a system designed for lunar and planetary surface operations, created
as a distributed 'multiagent system\'.

> (References:
> <http://www.agentisolutions.com/documentation/papers/FLAIRS03WClancey.pdf>
> <http://www.agentisolutions.com/documentation/papers/Clancey02FallAAAI.pdf>
> <http://homepage.mac.com/WJClancey/~WJClancey/WJCBrahms.html> )

Planetary analog studies are numerous and involve the use of terrestrial
facilities and environments to simulate planetary missions. Subsea,
polar, desert, and other environments are often used in these studies,
when environmental factors are most important to the research efforts.
Built facilities such as closed environment chambers at NASA or other
institutional locations are also used often, when the aspects of human
confinement and human-machine systems integration are most important to
the research.

Systems analysis of complex systems, including humans and machines is
currently performed by NASA and other agencies. Substantial research has
been conducted on mission autonomy, including its programmatic aspects,
human autonomy, machine autonomy, ground versus spacecraft trade
studies, and trades of crew involvement versus automated control system
autonomy. Implementing a truly flexible / adjustable autonomy remains a
challenge to be researched.

A major challenge for this control system is to achieve a flexible and
adjustable autonomy that allows the crew insight into the automated
system's workings and varying levels of direct crew control when
necessary.

# Conclusions

##  **Programmatic and Technical Findings**

Several programmatic and technical needs were identified:

1\. Funding. Efforts to formalize and understand controls architectures
are needed. In support of the formalisms, better definitions of hybrid
systems that capture the discrete and continuous aspects of control
systems are needed. The development of high fidelity physical and cyber
systems that mirror each other and can operate in shadow mode for actual
missions are the tall poles. Controls needs to have funding and a
project plan rather than being peripheral to other areas.

2\. A technology team with a solid background in the areas of control
theory, implementation/industrial experience, fundamental/empirical
modeling, statistics and logic, software creating
validation/verification, information theory, and cognitive science.

3\. Criteria for controller performance, system performance,
communication performance, etc.

4\. Pilot processes to study real-time responses, garner data for
parameter estimation, model validation, and optimization, realize
scale-up issues, and gain experience with systems.

5\. A suite of verification scenarios.

6\. A baseline concept.

7\. Preparation of a challenge problem (with associated data and/or
simulations) that is carefully worded and disseminated to the community
to garner new ideas and foster new collaborations.

8\. Program focus. Current efforts are not focused on the right set of
problems. Currently funded research is not based on an analysis of the
problem space, a review of existing technology (differentiated from
existing research), nor have NASA administrators vetted it. Very few
NRAs have targeted the controls domain, and no proposals have been
reviewed by controls experts. Automation, while a necessary part of the
long-term solution, is neither the hardest part, nor the primary part.
Current research is prioritized differently than the actual priorities
of the domain. Although integrating plants into the regenerative life
support systems is the hardest problem posed by ALS, we are decades away
from being able to grow plants on Mars (or the Moon) for food. There are
a large number of other technological and engineering problems that must
be solved before then, one of the greatest being the difficulties
associated with simply managing, developing, testing and integrating
currently available controls technology into a mission context.

Many of the problems identified in the workshop are intrinsic to the
systems engineering aspects of software development.

Software engineering problems, and system engineering problems are much
more critical to the actual development of advanced control software
than recognized R&D categories. No money is spent on developing either
software engineering technology (methods and tools) or on building the
technological infrastructure required. Some of the major long poles are
not research issues at all, but require basic engineering efforts such
as trade studies and standards evaluations. The research programs do not
fund these types of efforts; in fact these efforts are entirely
unfunded. Advanced Control Software also performs an integration
function across all the ALS subsystems as well as providing the
architecture for integrating local autonomous control, crew control, and
ground (mission) control functionality. As such, solutions do not
decompose cleanly across subsystem or organizational boundaries. This is
markedly different from previous human space flight programs. The agency
must first identify, and then solve these problems before undertaking
exploration-class missions.

Several \"long poles\", critical gaps in needed technology that must be
addressed now, have been identified. Although definitive studies haven't
been performed, enough work has been done to enable definition of some
fundamental problems.

Long Pole #1a - Problem Space is undefined. Identify the problems
associated with advanced control systems for long-duration human space
flight. This encompasses more than control software for life-support
subsystems; however control of closed-loop life support is unique to
human space flight missions and complex enough to provide a solution
space of architectures and methodologies that will support the other
systems. This requires a set of studies, scenarios and simulations to
bound and characterize the problem space, then to do the trades to
identify which problems have solutions and which don't, to determine how
to apply known solutions to the problem space, etc. This needs to be a
funded activity -- it will not happen without a supported and focused
interdisciplinary effort. If this is to be funded under the research
codes, the definition of R&D needs to be broadened to encompass what is
fundamentally an engineering process.

Long Pole #1b - Infrastructure undefined. Identify the infrastructure or
architecture necessary to support both advanced life support and other
mission functions. This is related to LP#1a; a controls solution that
doesn't co-exist with the mission architecture is not a viable solution.
This constraint, the mission operations concept, is part of the bounding
of the solution space described in LP#1a. This is a NASA unique
requirement, and is also unique to human missions, i.e. the solution is
different for human exploration missions than for unmanned missions or
for Low Earth Orbit. This includes standards definitions, ontology
definitions, protocol selection, information architecture, process
definition, etc.

Long Pole #2 - Closed Loop control. From the perspective of control
software there are unknowns associated with closed-loop systems. Almost
all control systems are designed as transformative systems, i.e. they
control a process that transforms known inputs into known outputs.
Although components of closed-loop systems act his way, overall the
system has no inputs and outputs. The controls must balance a very
dynamic set of interrelated processes into something resembling an
overall stable equilibrium. This is both a unique and new requirement
for which there is no ready available solution. In other words this is a
new research area that AFAIK we are not addressing. This problem is
independent of the trades associated with biological versus
physicochemical processes, however the solution may be different
depending on the ALS technology under consideration. We don't know
enough.

Long Pole #3 - Lack of data for control system development. Models,
simulations and operational tests need to be developed to generate
off-nominal and failure data necessary to develop control regimes for
ALS processes. Potential control solutions need to be tested and
evaluated, similar to hardware R&D performance and evaluation testing.
This type of technology maturation currently falls under no NASA
program.

Long Pole #4 - Engineering Methodologies. The capability for developing
software for large heterogeneous projects depends more on engineering
methodologies than on new software technology. The current agency
experience base doesn't support large software projects very well,
particularly when the software is mission infrastructure. Traditional
separation of concerns conflicts with the type of complex standards and
commonality necessary to use software as an integration function. We
need to evaluate and use methodologies that support the types of systems
that must be developed for exploration missions. To do that we need to
build an experience base inside the agency.

Problems unique to NASA were identified.

Everything, even mature technologies, needs to be evaluated in the
context of the mission goals, architecture and operations. Most NASA
activities are unique enough to stress even well understood solutions,
so even COTS solutions are not free of risk or cost.

Identification of mature technologies that could be adapted (from
section 4.3.2 - Group 4)

Distributed control

Hazard analysis

Supervisory Control And Data Acquisition

Advanced control techniques including feedforward, cascade, ratio,

select, multivariable control, model predictive, neural network,

fuzzy logic, expert systems, etc.

Task prioritization

Industry Consortiums

Identification of challenge areas

Open Standards

Operator training simulator

Standardization

Useability engineering

Identification of mature technologies that could be applied to current
programs

This is problematic as current programs have already made choices on
infrastructure and operations which would be very hard to overcome or
undo, and which were designed to prevent any kind of onboard control
automation or data integration between systems. Existing program
management methodologies prevent the introduction of any but the
simplest software, relying on human procedures for integration across
systems.

Conceptual system design needs to be integrated with dynamics
operational and control issues. Obtain individuals with real knowledge
about operating chemical plants, control theory, and practice. Determine
what is acceptable (system, controllers, risks, safety, communications)
versus what is achievable and affordable. Develop a challenge problem to
bring new ideas to the table.

## **Workshop Strengths and Weaknesses**

The Breakout groups were invited to comment on the workshop itself. The
following are comments from the groups:

*The meeting was very productive. Presentations on the first day ran a
bit too long, which led to meeting fatigue. More time outside of the
scheduled meetings should have been available during which more informal
exchanges could take place while on walks, etc. The breakout group
meetings were excellent. Good dialogues took place allowing all involved
to understand the issues from varying perspectives. All in all an
excellent meeting.*

*A major strength was the openness to permit different opinions
especially from attendees who do not have NASA connections. Bravo to
Darrell Jan and the organizers. The weakness will be in what happens
after the workshop. Will teams with a diversity of backgrounds be
assembled to carry out the recommendations or is it back to business as
usual with the current teams? Will NASA put this subject on the back
burner so that no funds or too few funds are allocated to pursue this?*

# Future Directions

First and foremost, Advanced System Integration and Control for Life
Support needs to be recognized as a real need and a critical gap in the
programs. Initial funding needs to be focused on identifying and
prioritizing needs, and to laying out a roadmap for filling the gaps.
The Workshop was a start, but insufficient for a definitive or
authoritative roadmap and subsequent plan. Because this is an
integrating technology, it does not exist apart from the systems that
are to be integrated. In other words, it cannot be developed in the
absence of real-world data, models, equipment or testing. This effort
needs to be tied to the ALS, AEMC and SIMA work, both influencing and
being influenced by them. A Systems Engineering view needs to be taken.
Models, simulations and hardware tests need to be developed and
validated to support not only software and methodology, but also hazard
analysis, operations concepts, procedures, infrastructure, training, and
technology maturation.

In parallel with this, the Virtual Testbed concept could be started
relatively inexpensively by making data and models available to
researchers through a website. This should be developed with the intent
of eventually making the interface interactive, even providing command
and data interfaces to the real test facility someday. The virtual
facility would permit development of a \"theory-experiment\" process
that will transition new technologies through the TRL\'s. At the lowest
TRL\'s researchers should have secure access to real simulation and
ultimately mission data in order to run experiments with their
technologies in order to benchmark results for comparison.

Keeping the existing testbed project alive and using it to test and
validate both controls approaches and methodologies is of paramount
importance. In previous human life support tests we have learned more
than we ever could by developing systems individually. And because of
the dependence of controls technology and software engineering
methodologies on actual projects, the argument could be made that these
technologies (which are mandatory for exploration missions) can not be
developed any other way, and by themselves justify the facility for
NASA.

# Acronym List

AEMC Advanced Environmental Monitoring and Control

AHST Advanced Human Support Technology

ALS Advanced Life Support

ALSS Advanced Life Support Systems

ARC Ames Research Center

ARS Atmosphere Revitalization Subsystem

ASICLS Advanced System Integration and Control for Life Support

BLSS Bioregenerative Life Support Systems

C^3^I Command, Control, Communications and Intelligence

CATS Crew Activity Tracking System

CDRS Carbon Dioxide Removal System

CELSS Closed Ecological Life Support System

CGS Centimeter, Gram, Second

CICT Computer Information & Communication Technologies

COTS Commercial-Off-The-Shelf

CPI Chemical Process Industries

CRS Carbon Dioxide Reduction System

CWS Chilled Water System

DARPA Defense Advanced Research Projects Agency

DCI Distributed Collaboration and Interaction

DCS Distributed Control Scheme

ECLSS Environmental Control and Life Support Systems

ESM Equivalent System Mass

EVA Extravehicular Activity

EXEC Executive

ISS International Space Station

IVHM Integrated Vehicle Health Management

JIT Just-in-Time

JPL Jet Propulsion Laboratory

JSC Johnson Space Center

KSC Kennedy Space Center

LMLSTP Lunar/Mars Life Support Test Program

M&C Monitoring and Control

MEM Micro-Electromechanical

MIR Mode Identification and Recovery

MKS Meter, Kilogram, Second

MSFC Marshall Space Flight Center

NASA National Aeronautics and Space Administration

NRA NASA Research Announcement

POMDP Partially Observable Markov Decision Processes

PS Planner and Scheduler

QA/QC Quality Assurance/Quality Control

R&D Research and Development

RF Radio Frequency

RLV Reusable Launch Vehicle

SCADA Supervisory Control and Data Acquisition

SI Systeme Internationale

SRL System Readiness Level

TRL Technology Readiness Level

TSAC Temperature Swing Absorption Compressor

3T Three-Tier

WRS Water Recovery System

# References

Biswas, G., G. Simon, N. Mahadevan, S. Narasimhan, J. Ramirez, and G.
Karsai. 2003. A Robust Method for Hybrid Diagnosis of Complex Systems.
*Proc.* *Safeprocess*. Washington, DC, June.

Bonasso, R. Peter, David Kortenkamp and Troy Whitney. 1997 Using a Robot
Control Architecture to Automated Space Shuttle Operations. *Proceedings
of the 9^th^ Conference on Innovative Applications of Artificial
Intelligence*.

Bonasso, R. P., R. J. Firby, E. Gat, D. Kortenkamp, D. Miller, and M.
Slack. 1997. Experiences with an architecture for intelligent, reactive
agents. *J. Experimental and Theoretical AI*. 9(1).

Bonasso, R. P., David Kortenkamp and Carroll Thronesbery. 2003.
Intelligent Control of a Water Recovery System. *AI Magazine,* 24(1).

Clancey, William J. 2003. Roles for Agents Assistances in Field Science:
Understanding Personal Projects and Collaboration. To appear in *IEEE
Transactions on Systems, Man and Cybernetics* special issue on
Human-Robot Interaction (also available at
[http://bill.clancey.name](http://bill.clancey.name/)).

Dorais, Greg, R. Peter Bonasso, David Kortenkamp, Barney Pell and Debra
Schreckenghost. 1998. Adjustable Autonomy for Human-Centered Autonomous
Systems on Mars. *Proceedings of the Mars Society Conference*.

Dorais, Greg, and David Kortenkamp. 2001 Designing Human-Centered
Autonomous Agents. *PRICAI Workshop Reader LNAI 2112*, editors. R.
Kowalcyk, S.W. Lake, N. Reed, G. Williams, editors. Springer-Verlag, New
York.

Gurumoorthy, A. and K. A. Kosanovich, 1998. Improving the Prediction
Capability of Radial Basis Function Networks. *Ind. & Eng. Chem. Res*.
37(10):3956-3970.

Hoo, K. A., M. J. Piovoso, and E. D. Sinzinger. 2001. Improving the
Predictions of Neural Networks. *J. Process Control*. 12(1):193-202.

Hoo, K. A., M. J. Piovoso, P. D. Schnelle, and D. A. Rowan. 2003.
Process and Controller Performance Monitoring: Overview with Industrial
Application. *J. Adaptive Control & Signal Processing*. 17(7-9):635-662.

Kosanovich, K. A. and M. J. Piovoso. 1994. Applications of Multivariable
Statistical Methods to Process Monitoring and Controller Design. *Int.
Journal Control*. 59(3):743-765.

Krishnan, A. and K. A. Hoo. 1999. A Multi-Scale Model Predictive Control
Strategy. *Ind. & Eng. Chem. Res*. 38(5):1973-1986.

Kortenkamp, David, R. Peter Bonasso, and Devika Subramanian. 2001.
Distributed, Autonomous Control of Space Habitats. *IEEE Aerospace
Conference*.

Korth, David H. and Troy P. LeBlanc. 2002. International Space Station
Alpha Operations Planning. *In* Proceedings of the *3^rd^ International
NASA Workshop on Planning and Scheduling for Space*, (available from
[www.systems.org](http://www.systems.org/)).

Malin, Jane et al \[Please write out all authors.\]. 2000. Multi-agent
Diagnosis and Control of an Air Revitalization System for Life Support
in Space. *Proceedings of the IEEE Aerospace Conference*.

Muscettola N. et al \[Please write out all authors.\]. 2000. A Unified
Approach to Model-based Planning and Execution. *Proceedings of the
Sixth International Conference on Intelligent Autonomous Systems*.

Muscettola, Nicola, P. Pandurang Nayak, Barney Pell, and Brian Williams.
1998. Remote Agent: To boldly go where no AI system has gone before.
*Artificial Intelligence Journal*. 103(1):5-47.

Musliner, David, Ed Durfee and Kang Shin. 1995. CIRCA: A Cooperative,
Intelligent, Real-time Control Architecture. *IEEE Transactions on
Systems, Man and Cybernetics*, 23(6):1561-1574.

Roth, E., Jane Malin, and Debra Schreckenghost. 1996. Paradigms for
Intelligent Interfaces. *In* The Handbook of HCI. M. Helander, editor.
Elsavier, New York.

Schreckenghost, Debra, Carroll Thronesbery, R. Peter Bonasso, David
Kortenkamp, and Cheryl Martin. 2002. Intelligent Control of Life Support
for Space Missions. *IEEE Intelligent Systems Magazine*. 17(5).

Schreckenghost, Debra, Cheryl Martin, David Kortenkamp, Tod Milam, and
Carroll Thronesbery. 2002. Supporting group interactions among humans
and autonomous agents. *Connection Science*. 14(4):361-369.

Tian, Z. and K. A. Hoo. 2003. Transition Control Using State-Shared
Model Approach. *Compt. & Chem. Engng*. 27(11: 1641-1656.

Tsai, J., Y. Bi, S. Yang, and R. Smith. 1996. *Distributed Real-Time
Systems: Monitoring, Visualization and Analysis*, Wiley & Sons, New
York.

Vasbinder, E. M. and K. A. Hoo. 2003. A Decision-Based Approach to
Plantwide Control Structure Synthesis. *Ind. & Eng. Chem. Res*.
42:4586-4598.

Vasbinder, E. M., K. A. Hoo, and U. Mann. 2004. Synthesis of Plantwide
Control Structures Using a Decision-based Methodology. *In* The
Integration of Design and Control. P. Seferlis and M. Georgiadis,
editors. Elsevier Science, Amsterdam.

Wellman, Michael. 1995. The Economic Approach to Artificial
Intelligence. *ACM Computing Surveys*. 27:360-362.

Zheng, D., K. A. Hoo, and M. J. Piovoso. 2002. Low-order Model
Identification of Distributed Parameter Systems by a Combination of
Singular Value Decomposition and the Karhunen-Love Expansion. *Ind. &
Eng. Chem. Res*. 41(6):1545-1556.

**APPENDIX A -- WORKSHOP AGENDA**

**Tuesday, August 26, 2003**

+--------+--------+-----------------------------------+----------------+
| *      |        |                                   |                |
| *Point |        |                                   |                |
| Lobos, |        |                                   |                |
| Mo     |        |                                   |                |
| nterey |        |                                   |                |
| Plaza  |        |                                   |                |
| H      |        |                                   |                |
| otel** |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| **In   |        |                                   |                |
| troduc |        |                                   |                |
| tion** |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 8:00   | 8:05   | Welcome                           | Darrell Jan    |
| AM -   | AM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 8:05   | 8:15   | Remarks from Headquarters         | Jitendra Joshi |
| AM -   | AM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 8:15   | 8:20   | *Logistics - NPRS*                | Pauline        |
| AM -   | AM     |                                   | Burgess        |
+--------+--------+-----------------------------------+----------------+
| 8:20   | 8:35   | Objectives of Workshop            | Darrell Jan    |
| AM -   | AM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 8:35   | 8:55   | International Space Station       | Jay Perry      |
| AM -   | AM     |                                   |                |
|        |        | Environmental Control & Life      |                |
|        |        | Support:                          |                |
|        |        |                                   |                |
|        |        | Overview of System Architecture & |                |
|        |        | Control                           |                |
+--------+--------+-----------------------------------+----------------+
| 8:55   | 9:40   | Advanced Life Support:            | Richard        |
| AM -   | AM     |                                   | Boulanger      |
|        |        | System Architectures and Control  |                |
|        |        | Challenges                        |                |
+--------+--------+-----------------------------------+----------------+
| 9:40   | 10:25  | Exploration Missions,             | Daniel Barta   |
| AM -   | AM     | Architectures and Ground Based    |                |
|        |        | Test Beds                         |                |
+--------+--------+-----------------------------------+----------------+
| 10:25  | 10:55  | *\-\-\-\-\-- Break \-\-\-\--*     |                |
| AM -   | AM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| **     |        |                                   |                |
| System |        |                                   |                |
| Integ  |        |                                   |                |
| ration |        |                                   |                |
| &      |        |                                   |                |
| C      |        |                                   |                |
| ontrol |        |                                   |                |
| D      |        |                                   |                |
| escrip |        |                                   |                |
| tion** |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 10:55  | 11:10  | Challenges and Opportunities of   | K.C. Ting      |
| AM -   | AM     | Advanced Life Support Systems     |                |
|        |        | Analysis and Modeling             |                |
+--------+--------+-----------------------------------+----------------+
| 11:10  | 11:25  | ALS Control Metrics and           | Alan Drysdale  |
| AM -   | AM     | Equivalent System Mass            |                |
+--------+--------+-----------------------------------+----------------+
| 11:25  | 11:40  | Advantages of Hierarchical,       | David          |
| AM -   | AM     | Centralized Architectures for     | Kortenkamp     |
|        |        | Controlling Real-World Systems    |                |
+--------+--------+-----------------------------------+----------------+
| 11:40  | 11:55  | ALS Integrated Control Challenges | David Overland |
| AM -   | AM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 11:55  | 12:55  | *\-\-\-\-\-- Lunch \-\-\-\--*     |                |
| AM -   | PM     |                                   |                |
|        |        | ###### Lower Terrace              |                |
+--------+--------+-----------------------------------+----------------+
| *      |        |                                   |                |
| *Point |        |                                   |                |
| Lobos, |        |                                   |                |
| Mo     |        |                                   |                |
| nterey |        |                                   |                |
| Plaza  |        |                                   |                |
| H      |        |                                   |                |
| otel** |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 12:55  | 1:10   | Putting It All Together:          | Richard        |
| PM -   | PM     |                                   | Boulanger      |
|        |        | Orchestrating Control Solutions   |                |
+--------+--------+-----------------------------------+----------------+
| 1:10   | 1:25   | Crew/Ground Control Interfacial   | Debra          |
| PM -   | PM     | Requirements                      | Schreckenghost |
+--------+--------+-----------------------------------+----------------+
| 1:25   | 1:40   | Reliability, Safety and Error     | Jane Malin     |
| PM -   | PM     | Recovery for Advanced Control     |                |
|        |        | Software                          |                |
+--------+--------+-----------------------------------+----------------+
| 1:40   | 2:10   | The Future of ALS Monitoring and  | Jon Erickson   |
| PM -   | PM     | Control: Challenges               |                |
+--------+--------+-----------------------------------+----------------+
| 2:10   | 2:40   | *\-\-\-\-\-- Break \-\-\-\--*     |                |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| **Ex   |        |                                   |                |
| amples |        |                                   |                |
| of     |        |                                   |                |
| C      |        |                                   |                |
| ontrol |        |                                   |                |
| R&D**  |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 2:40   | 3:00   | Industrial Process Measurement    | R. Russell     |
| PM -   | PM     | and Control                       | Rhinehart      |
+--------+--------+-----------------------------------+----------------+
| 3:00   | 3:20   | Research Directions in Industrial | David Musliner |
| PM -   | PM     | Control                           |                |
+--------+--------+-----------------------------------+----------------+
| 3:20   | 3:40   | Reconfigurable Autonomous Agent   | Francisco      |
| PM -   | PM     |                                   | Maturana       |
|        |        | Architecture for Shipboard        |                |
|        |        | Automation                        |                |
+--------+--------+-----------------------------------+----------------+
| 3:40   | 4:00   | *\-\-\-\-\-- Break \-\-\-\--*     |                |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 4:00   | 4:20   | Control in Unmanned NASA Missions | Carl Ruoff     |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 4:20   | 4:40   | Autonomous Control with the       | Barney Pell    |
| PM -   | PM     | Remote Agent in Deep Space One    |                |
+--------+--------+-----------------------------------+----------------+
| 4:40   | 5:00   | Control Issues in Water           | Peter Bonasso  |
| PM -   | PM     | Processing                        |                |
+--------+--------+-----------------------------------+----------------+
| 5:00   | 5:10   | An Advanced Life Support          | David          |
| PM -   | PM     | Simulation for Integrated         | Kortenkamp     |
|        |        | Controls Research                 |                |
+--------+--------+-----------------------------------+----------------+
| 5:10   | 5:20   | Charge to the Group, Breakout     | Darrell Jan    |
| PM -   | PM     | Assignments                       |                |
+--------+--------+-----------------------------------+----------------+
| 5:20   | 6:20   | *\-\-\-\-\-- Break \-\-\-\--*     |                |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 6:20   | 7:50   | *\-\-\-\-\-- Dinner & Speaker     | Ken Arnold     |
| PM -   | PM     | \-\-\-\--*                        |                |
|        |        |                                   |                |
|        |        | **Monterey Bay**                  |                |
|        |        |                                   |                |
|        |        | Distributed Design vs.            |                |
|        |        | Reliability                       |                |
+--------+--------+-----------------------------------+----------------+

**Wednesday, August 27, 2003**

+--------+--------+-----------------------------------+----------------+
| *      |        |                                   |                |
| *Point |        |                                   |                |
| Lobos, |        |                                   |                |
| Mo     |        |                                   |                |
| nterey |        |                                   |                |
| Plaza  |        |                                   |                |
| H      |        |                                   |                |
| otel** |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 8:30   | 8:40   | *Briefing, Logistics*             | Darrell Jan,   |
| AM -   | AM     |                                   |                |
|        |        |                                   | Pauline        |
|        |        |                                   | Burgess        |
+--------+--------+-----------------------------------+----------------+
| Group  |        |                                   |                |
| #1 Big |        |                                   |                |
| Sur 1  |        |                                   |                |
|        |        |                                   |                |
| Group  |        |                                   |                |
| #2 Big |        |                                   |                |
| Sur 2  |        |                                   |                |
|        |        |                                   |                |
| Group  |        |                                   |                |
| #3 Big |        |                                   |                |
| Sur 3  |        |                                   |                |
|        |        |                                   |                |
| Group  |        |                                   |                |
| #4 RLS |        |                                   |                |
| 1      |        |                                   |                |
|        |        |                                   |                |
| Group  |        |                                   |                |
| #5 RLS |        |                                   |                |
| 2      |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 8:40   | 10:10  | Breakout Discussions, by ALS      | All groups     |
| AM -   | AM     | Scenarios:                        | meeting in     |
|        |        |                                   | breakout rooms |
|        |        | Ground-based Testbed, Transit     |                |
|        |        | Mission, Planetary Surface,       |                |
|        |        | Planetary Base                    |                |
+--------+--------+-----------------------------------+----------------+
| 10:10  | 10:30  | *\-\-\-\-\-- Break \-\-\-\--*     |                |
| AM -   | AM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 10:30  | 12:00  | Continue Breakout Discussions     | All            |
| AM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 12:00  | 1:00   | *\-\-\-\-\-- Lunch \-\-\-\--*     | All            |
| PM -   | PM     |                                   |                |
|        |        | **Lower Terrace**                 |                |
+--------+--------+-----------------------------------+----------------+
| 1:00   | 2:30   | Breakout: Converge on Key Areas   | All            |
| PM -   | PM     | and Prepare Materials for         |                |
|        |        | Presentation to the Assembly      |                |
+--------+--------+-----------------------------------+----------------+
| 2:30   | 3:00   | *\-\-\-\-\-- Break \-\-\-\--*     |                |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| *      |        |                                   |                |
| *Point |        |                                   |                |
| Lobos, |        |                                   |                |
| Mo     |        |                                   |                |
| nterey |        |                                   |                |
| Plaza  |        |                                   |                |
| H      |        |                                   |                |
| otel** |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 3:00   | 3:20   | Breakout Presentation #1          | Group #1       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 3:20   | 3:40   | Breakout Presentation #2          | Group #2       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 3:40   | 4:00   | Breakout Presentation #3          | Group #3       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 4:00   | 4:20   | Breakout Presentation #4          | Group #4       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 4:20   | 4:40   | Breakout Presentation #5          | Group #5       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 4:40   | 5:00   | Assignment to Topic Groups for    | Darrell Jan    |
| PM -   | PM     | Next Day                          | and all        |
+--------+--------+-----------------------------------+----------------+
| 5:00   | 5:15   | Charge to the Group for Day 3     | Darrell Jan    |
| PM -   | PM     |                                   | and all        |
+--------+--------+-----------------------------------+----------------+

Thursday, August 28, 2003

+--------+--------+-----------------------------------+----------------+
| *      |        |                                   |                |
| *Point |        |                                   |                |
| Lobos, |        |                                   |                |
| Mo     |        |                                   |                |
| nterey |        |                                   |                |
| Plaza  |        |                                   |                |
| H      |        |                                   |                |
| otel** |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 8:30   | 8:40   | *Briefing, Logistics & NPRS       | Darrell Jan    |
| AM -   | AM     | Survey*                           |                |
|        |        |                                   | Pauline        |
|        |        |                                   | Burgess        |
+--------+--------+-----------------------------------+----------------+
| Group  |        |                                   |                |
| #1 Big |        |                                   |                |
| Sur 1  |        |                                   |                |
|        |        |                                   |                |
| Group  |        |                                   |                |
| #2 Big |        |                                   |                |
| Sur 2  |        |                                   |                |
|        |        |                                   |                |
| Group  |        |                                   |                |
| #3 Big |        |                                   |                |
| Sur 3  |        |                                   |                |
|        |        |                                   |                |
| Group  |        |                                   |                |
| #4 RLS |        |                                   |                |
| 1      |        |                                   |                |
|        |        |                                   |                |
| Group  |        |                                   |                |
| #5 RLS |        |                                   |                |
| 2      |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 8:40   | 10:10  | Breakout Discussions, by Topic:   | All groups     |
| AM -   | AM     |                                   | meeting in     |
|        |        | Modeling, Integrated System       | breakout rooms |
|        |        | Control, Dynamically              |                |
|        |        | Reconfigurable Systems, Software  |                |
|        |        | Methodologies, Integrating Human  |                |
|        |        | Expertise                         |                |
+--------+--------+-----------------------------------+----------------+
| 10:10  | 10:25  | *\-\-\-\-\-- Break \-\-\-\--*     |                |
| AM -   | AM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 10:25  | 11:55  | Continue Breakout Discussions     | All            |
| AM -   | AM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 11:55  | 12:55  | *\-\-\-\-\-- Lunch & Speaker      | Daniel Cooke   |
| AM -   | PM     | \-\-\-\--*                        |                |
|        |        |                                   |                |
|        |        | **Monterey Bay**                  |                |
|        |        |                                   |                |
|        |        | Proofs and Paths from The Book of |                |
|        |        | Mars                              |                |
+--------+--------+-----------------------------------+----------------+
| 12:55  | 2:25   | Breakout: Converge on Tools &     | All            |
| PM -   | PM     | Gaps                              |                |
|        |        |                                   |                |
|        |        | and Prepare Presentations to the  |                |
|        |        | Assembly                          |                |
+--------+--------+-----------------------------------+----------------+
| 2:25   | 2:40   | *\-\-\-\-\-- Break \-\-\-\--*     |                |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| *      |        |                                   |                |
| *Point |        |                                   |                |
| Lobos, |        |                                   |                |
| Mo     |        |                                   |                |
| nterey |        |                                   |                |
| Plaza  |        |                                   |                |
| H      |        |                                   |                |
| otel** |        |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 2:40   | 3:00   | Breakout Presentation #1          | Group #1       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 3:00   | 3:20   | Breakout Presentation #2          | Group #2       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 3:20   | 3:40   | Breakout Presentation #3          | Group #3       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 3:40   | 4:00   | Breakout Presentation #4          | Group #4       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 4:00   | 4:20   | Breakout Presentation #5          | Group #5       |
| PM -   | PM     |                                   |                |
+--------+--------+-----------------------------------+----------------+
| 4:20   | 5:20   | Conclusions and Consensus         | Darrell Jan    |
| PM -   | PM     |                                   | and all        |
+--------+--------+-----------------------------------+----------------+

**APPENDIX B -- PARTICIPANT LIST**

+-----------------------------------+-----------------------------------+
| > **Mr. Ken Arnold**              | > **Dr. Christopher Assad**       |
| >                                 | >                                 |
| > EventMonitor, Inc.              | > Jet Propulsion Laboratory       |
| >                                 | >                                 |
| > Lexington, MA 02421             | > Pasadena, CA 91109-8099         |
| >                                 | >                                 |
| > arnold@moonhill.org             | > Christopher.Assad@jpl.nasa.gov  |
+-----------------------------------+-----------------------------------+
| > **Dr. Daniel Barta**            | > **Dr. Gregory Bearman**         |
| >                                 | >                                 |
| > NASA Lyndon B. Johnson Space    | > Jet Propulsion Laboratory       |
| > Center                          | >                                 |
| >                                 | > Pasadena, CA 91109-8099         |
| > Houston, TX 77058               | >                                 |
| >                                 | > gbearman@jpl.nasa.gov           |
| > daniel.j.barta1@jsc.nasa.gov    |                                   |
+-----------------------------------+-----------------------------------+
| > **Dr. Gautam Biswas**           | > **Mr. Peter Bonasso**           |
| >                                 | >                                 |
| > Vanderbilt University           | > NASA JSC/Metrica Inc.           |
| >                                 | >                                 |
| > Nashville, TN 37212             | > Houston, TX 77059               |
| >                                 | >                                 |
| > Bi                              | > r.p.bonasso@jsc.nasa.gov        |
| swas@eecsmail.vuse.vanderbilt.edu |                                   |
+-----------------------------------+-----------------------------------+
| > **Mr. Richard Boulanger**       | > **Mr. Paul Campbell**           |
| >                                 | >                                 |
| > NASA Ames Research Center       | > NASA JSC/Lockheed Martin        |
| >                                 | >                                 |
| > Moffett Field, CA 94035-1000    | > Houston, TX 77058               |
| >                                 | >                                 |
| > rboulanger@mail.arc.nasa.gov    | > paul.d.campbell1@jsc.nasa.gov   |
+-----------------------------------+-----------------------------------+
| > **Dr. George Cheng**            | > **Dr. Daniel Cooke**            |
| >                                 | >                                 |
| > CyboSoft, General Cybernation   | > Texas Tech University           |
| > Group Inc.                      | >                                 |
| >                                 | > Lubbock, TX 79409-3104          |
| > Rancho Cordova, CA 95670        | >                                 |
| >                                 | > Daniel.Cooke@coe.ttu.edu        |
| > gscheng@cybosoft.com            |                                   |
+-----------------------------------+-----------------------------------+
| > **Dr. Taher Daud**              | > **Dr. Alan Drysdale**           |
| >                                 | >                                 |
| > Jet Propulsion Laboratory       | > Boeing                          |
| >                                 | >                                 |
| > Pasadena, CA 91109-8099         | > Titusville, FL 32780-8046       |
| >                                 | >                                 |
| > Taher.Daud@jpl.nasa.gov         | > alan.e.drysdale@boeing.com      |
+-----------------------------------+-----------------------------------+
| > **Dr. Jon Erickson**            | > **Dr. David Fleisher**          |
| >                                 | >                                 |
| > Berkley Street Consulting, Inc. | > USDA                            |
| >                                 | >                                 |
| > Houston, TX 77089-4326          | > Beltsville, MD 20905            |
| >                                 | >                                 |
| > JErick5481@aol.com              | > dfleishe@asrr.arsusda.gov       |
+-----------------------------------+-----------------------------------+
| > **Dr. Michael Gelfond**         | > **Dr. Karen Gundy-Burlet**      |
| >                                 | >                                 |
| > Texas Tech University           | > NASA Ames Research Center       |
| >                                 | >                                 |
| > Lubbock, TX 79409-3104          | > Moffett Field, CA 94035         |
| >                                 | >                                 |
| > mgelfond@cs.ttu.edu             | > kgundyburlet@mail.arc.nasa.gov  |
+-----------------------------------+-----------------------------------+
| > **Dr. Karlene Hoo**             | > **Dr. Darrell Jan**             |
| >                                 | >                                 |
| > Texas Tech University           | > Jet Propulsion Laboratory       |
| >                                 | >                                 |
| > Lubbock, TX 79409-3121          | > Pasadena, CA 91109              |
| >                                 | >                                 |
| > Karlene.Hoo@coe.ttu.edu         | > djan@mail2.jpl.nasa.gov         |
+-----------------------------------+-----------------------------------+
| > **Dr. Harry Jones**             | > **Dr. Jitendra Joshi**          |
| >                                 | >                                 |
| > NASA Ames Research Center       | > NASA Headquarters/USRA          |
| >                                 | >                                 |
| > Moffett Field, CA 94035-1000    | > Washington, DC 20546            |
| >                                 | >                                 |
| > hjones@mail.arc.nasa.gov        | > jjoshi@hq.nasa.gov              |
+-----------------------------------+-----------------------------------+
| > **Dr. Paul Keller**             | > **Dr. Mark Kliss**              |
| >                                 | >                                 |
| > Washington State University     | > NASA Ames Research Center       |
| >                                 | >                                 |
| > Richland, WA 99352              | > Moffett Field, CA 94035         |
| >                                 | >                                 |
| > pekeller@yahoo.com              | > Mark.H.Kliss@nasa.gov           |
+-----------------------------------+-----------------------------------+
| > **Dr. David Kortenkamp**        | > **Mr. Wen-Ching Lee**           |
| >                                 | >                                 |
| > NASA JSC/Metrica Inc.           | > Lockheed Martin Space           |
| >                                 | > Operations Co.                  |
| > Houston, TX 77058               | >                                 |
| >                                 | > Houston, TX 77058-3799          |
| >                                 | >                                 |
|  david.m.kortenkamp1@jsc.nasa.gov | > wen-ching.lee@lmco.com          |
+-----------------------------------+-----------------------------------+
| > **Ms. Julie Levri**             | > **Mr. Jim Luth**                |
| >                                 | >                                 |
| > NASA Ames Research Center       | > Rockwell Software               |
| >                                 | >                                 |
| > Moffett Field, CA 94035         | > Mayfield Village, OH 44144      |
| >                                 |                                   |
| > jlevri@mail.arc.nasa.gov        |                                   |
+-----------------------------------+-----------------------------------+
| > **Dr. Jane Malin**              | > **Dr. Francisco Maturana**      |
| >                                 | >                                 |
| > NASA Lyndon B. Johnson Space    | > Rockwell Automation             |
| > Center                          | >                                 |
| >                                 | > Mayfield Heights, OH 44124      |
| > Houston, TX 77058               | >                                 |
| >                                 | > fpmaturana@ra.rockwell.com      |
| > jane.t.malin@nasa.gov           |                                   |
+-----------------------------------+-----------------------------------+
| > **Dr. Robert McCann**           | > **Dr. Cary Mitchell**           |
| >                                 | >                                 |
| > NASA Ames Research Center       | > Purdue University               |
| >                                 | >                                 |
| > Moffett Field, CA 94036         | > West Lafayette, IN 47907-1165   |
| >                                 | >                                 |
| > rmccann@mail.arc.nasa.gov       | > mitchell@hort.purdue.edu        |
+-----------------------------------+-----------------------------------+
| > **Dr. Charles Moore**           | > **Dr. David Musliner**          |
| >                                 | >                                 |
| > University of Tennessee at      | > Honeywell Laboratories          |
| > Knoxville                       | >                                 |
| >                                 | > Minneapolis, MN 55418           |
| > Knoxville, TN 37996-2200        | >                                 |
| >                                 | > musliner@htc.honeywell.com      |
| > cfmoore@utk.edu                 |                                   |
+-----------------------------------+-----------------------------------+
| > **Dr. Seza Orcun**              | > **Dr. David Overland**          |
| >                                 | >                                 |
| > Purdue University               | > NASA Lyndon B. Johnson Space    |
| >                                 | > Center                          |
| > West Lafayette, IN 47907-1283   | >                                 |
| >                                 | > Houston, TX 77058               |
| > orcun@ecn.purdue.edu            | >                                 |
|                                   | > david.overland1@jsc.nasa.gov    |
+-----------------------------------+-----------------------------------+
| > **Dr. Charles Pecheur**         | > **Dr. Joseph Pekny**            |
| >                                 | >                                 |
| > NASA Ames Research Center       | > Purdue University               |
| >                                 | >                                 |
| > Moffett Field, CA 94035         | > West Lafayette, IN 47907-2100   |
| >                                 | >                                 |
| > pecheur@ptolemy.arc.nasa.gov    | > pekny@ecn.purdue.edu            |
+-----------------------------------+-----------------------------------+
| > **Dr. Barney Pell**             | > **Mr. Jay Perry**               |
| >                                 | >                                 |
| > NASA Ames Research Center/RIACS | > NASA Marshall Space Flight      |
| >                                 | > Center                          |
| > Moffett Field, CA 94035-1000    | >                                 |
| >                                 | > Marshall Space Flight Center,   |
| > pell@email.arc.nasa.gov         | > AL 35812                        |
|                                   | >                                 |
|                                   | > Jay.L.Perry@nasa.gov            |
+-----------------------------------+-----------------------------------+
| > **Mr. Bill Poe**                | > **Dr. Marco Quadrelli**         |
| >                                 | >                                 |
| > Invensys                        | > Jet Propulsion Laboratory       |
| >                                 | >                                 |
| > Houston, TX 77042               | > Pasadena, CA 91109-8099         |
| >                                 | >                                 |
| > wpoe@Foxboro.com                | > marco@grover.jpl.nasa.gov       |
+-----------------------------------+-----------------------------------+
| > **Dr. Russell Rhinehart**       | > **Dr. Luis Rodriguez**          |
| >                                 | >                                 |
| > Oklahoma State University       | > NASA Lyndon B. Johnson Space    |
| >                                 | > Center                          |
| > Stillwater, OK 74078-5021       | >                                 |
| >                                 | > Houston, TX 77058               |
| > rrr@okstate.edu                 | >                                 |
|                                   | > lrodrigu@ems.jsc.nasa.gov       |
+-----------------------------------+-----------------------------------+
| > **Dr. Carl Ruoff, Jr**          | > **Ms. Debra Schreckenghost**    |
| >                                 | >                                 |
| > Jet Propulsion Laboratory       | > NASA JSC/Metrica Inc.           |
| >                                 | >                                 |
| > Pasadena, CA 91109-8099         | > Houston, TX 77058               |
| >                                 | >                                 |
| > Carl.F.Ruoff@jpl.nasa.gov       | > ghost@ieee.org                  |
+-----------------------------------+-----------------------------------+
| > **Dr. Ben Smith**               | > **Mr. Robert Smylie**           |
| >                                 | >                                 |
| > Jet Propulsion Laboratory       | > NASA Headquarters/USRA          |
| >                                 | >                                 |
| > Pasadena, CA 91109-8099         | > Washington, DC 20546            |
| >                                 | >                                 |
| > Benjamin.D.Smith@jpl.nasa.gov   | > rsmylie@hq.nasa.gov             |
+-----------------------------------+-----------------------------------+
| > **Dr. K.C. Ting**               | > **Dr. Eugene Tu**               |
| >                                 | >                                 |
| > Ohio State University           | > NASA Ames Research Center       |
| >                                 | >                                 |
| > Columbus, OH 43210-1057         | > Moffett Field, CA 94035         |
| >                                 | >                                 |
| > ting.14@osu.edu                 | > Eugene.L.Tu@nasa.gov            |
+-----------------------------------+-----------------------------------+

**APPENDIX C -- BREAKOUT GROUPS & ORGANIZERS**

**[Group 1: Ground-Based Human-Rated Test Facility]{.underline}**

***Chair:*** Daniel Cooke ***Co-Chairs:*** Joseph Pekny, Ben Smith

***Group Members:***

Ken Arnold Christopher Assad

Jon Erickson Karen Gundy-Burlet

Jane Malin Joseph Pekny

Ben Smith

**[Group 2: Mars Transit Vehicle]{.underline}**

***Chair:*** Richard Boulanger ***Co-Chair:*** Gautam Biswas

***Group Members:***

Paul Campbell George Cheng

Taher Daud Michael Gelfond

Francisco Maturana Debra Schreckenghost

**[Group 3: Martian Planetary Exploration]{.underline}**

***Chair:*** David Kortenkamp ***Co-Chair:*** Karlene Hoo

***Group Members:***

Thomas Burke Alan Drysdale

Harry Jones Robert McCann

Seza Orcun Charles Pecheur

Carl Ruoff

**[Group 4: Mars Planetary Base]{.underline}**

***Chair:*** Paul Keller ***Co-Chair:*** Julie Levri

***Group Members:***

David Fleisher Charlie Moore

David Overland Bill Poe

Marco Quadrelli Russell Rhinehart

K.C. Ting

**[Group 5: Ground-Based Testbed and Mars Planetary Base]{.underline}**

***Chair:*** Daniel Barta ***Co-Chair:*** David Musliner

***Group Members:***

Gregory Bearman Peter Bonasso

Wen-Ching Lee Cary Mitchell

Barney Pell Jay Perry

Luis Rodriguez

**[Organizers:]{.underline}**

Darrell Jan, Jitendra Joshi, Daniel Barta, Richard Boulanger, Daniel
Cooke, Wen-Ching Lee, Chin H. Lin, David Kortenkamp, and David Overland.

**APPENDIX D -- ADVANCED LIFE SUPPORT SYSTEMS DESCRIPTION**

![](media/image1.jpeg){width="6.0in"
height="4.5in"}![](media/image2.jpeg){width="6.0in"
height="4.5in"}![](media/image3.jpeg){width="6.0in"
height="4.5in"}![](media/image4.jpeg){width="6.0in"
height="4.5in"}![](media/image5.jpeg){width="6.0in"
height="4.5in"}![](media/image6.jpeg){width="6.0in"
height="4.5in"}![](media/image7.jpeg){width="6.0in"
height="4.5in"}![](media/image8.jpeg){width="6.0in"
height="4.5in"}![](media/image9.jpeg){width="6.0in"
height="4.5in"}![](media/image10.jpeg){width="6.0in"
height="4.5in"}![](media/image11.jpeg){width="6.0in"
height="4.5in"}![](media/image12.jpeg){width="6.0in"
height="4.5in"}![](media/image13.jpeg){width="6.0in"
height="4.5in"}![](media/image14.jpeg){width="6.0in"
height="4.5in"}![](media/image15.jpeg){width="6.0in" height="4.5in"}

**APPENDIX E -- SCENARIOS & QUESTIONS**

![](media/image16.jpeg){width="6.0in"
height="4.5in"}![](media/image17.jpeg){width="6.0in" height="4.5in"}

![](media/image18.jpeg){width="6.0in"
height="4.5in"}![](media/image19.jpeg){width="6.0in" height="4.5in"}

![](media/image20.jpeg){width="6.0in"
height="4.5in"}![](media/image21.jpeg){width="6.0in" height="4.5in"}**\
\
**![](media/image22.jpeg){width="5.879861111111111in"
height="4.409722222222222in"}![](media/image23.jpeg){width="5.75in"
height="4.3125in"}

![](media/image24.jpeg){width="6.0in"
height="4.5in"}![](media/image25.jpeg){width="6.0in"
height="4.5in"}![](media/image26.jpeg){width="6.0in"
height="4.5in"}![](media/image27.jpeg){width="6.0in"
height="4.5in"}![](media/image28.jpeg){width="6.0in"
height="4.5in"}![](media/image29.jpeg){width="6.0in"
height="4.5in"}![](media/image30.jpeg){width="6.0in"
height="4.5in"}![](media/image31.jpeg){width="6.0in"
height="4.5in"}![](media/image32.jpeg){width="6.0in"
height="4.5in"}![](media/image33.jpeg){width="6.0in"
height="4.5in"}![](media/image34.jpeg){width="6.0in"
height="4.5in"}![](media/image35.jpeg){width="6.0in"
height="4.5in"}![](media/image36.jpeg){width="6.0in"
height="4.5in"}![](media/image37.jpeg){width="6.0in"
height="4.5in"}![](media/image38.jpeg){width="6.0in"
height="4.5in"}![](media/image39.jpeg){width="6.0in"
height="4.5in"}![](media/image40.jpeg){width="6.0in"
height="4.5in"}![](media/image41.jpeg){width="6.0in"
height="4.5in"}![](media/image42.jpeg){width="6.0in"
height="4.5in"}![](media/image43.jpeg){width="6.0in"
height="4.5in"}![](media/image44.jpeg){width="6.0in"
height="4.5in"}![](media/image45.jpeg){width="6.0in"
height="4.5in"}![](media/image46.jpeg){width="6.0in"
height="4.5in"}![](media/image47.jpeg){width="6.0in"
height="4.5in"}![](media/image48.jpeg){width="6.0in"
height="4.5in"}![](media/image49.jpeg){width="6.0in"
height="4.5in"}![](media/image50.jpeg){width="6.0in"
height="4.5in"}![](media/image51.jpeg){width="6.0in"
height="4.5in"}![](media/image52.jpeg){width="6.0in"
height="4.5in"}![](media/image53.jpeg){width="6.0in"
height="4.5in"}![](media/image54.jpeg){width="6.0in"
height="4.5in"}![](media/image55.jpeg){width="6.0in"
height="4.5in"}![](media/image56.jpeg){width="6.0in" height="4.5in"}

**APPENDIX F -- PRESENTATION ABSTRACTS**

**International Space Station Environmental Control & Life Support:
Overview of System Architecture & Control**

***Jay Perry, NASA Marshall Space Flight Center***

Providing a comfortable, safe environment in which one may live and work
has been a challenge since the beginning of crewed space travel.
Supplying human beings with oxygen, water, and food for their basic
survival amounts to more than 5 kg/person/day. At the same time, an
equivalent amount of waste products must be dealth with daily. These
wastes include carbon dioxide, urine, and solid waste. As crewed space
exploration expands toward longer, more complex missions, the
environmental control and life support (ECLS) system required to
maintain their comfort and safety also increases in complexity. An
overview of the ECLS system design change is presented. An example
control architecture is discussed and representative components
requiring local control are reviewed. The International Space Station
(ISS) Atmosphere Revitalization Subsystem (ARS) serves as the discussion
reference.

**Advanced Life Support: System Architectures and Control Challenges**

***Richard Boulanger, Jacobs Engineering / Sverdrup Technology at NASA
ARC***

Advanced Life Support systems consist of tightly coupled technologies
which process the material flow streams necessary to support a human
crew during spaceflight. The principle control objective is to provide
the conditions necessary to support the lives of the human crew at all
times. Life support technologies can be physicochemical or biologically
based, can be continuous, batch or semi-batch processes, or can have
widely varying time-constants, which result in systems that are
challenging, at best, to control. This presentation will familiarize the
audience with:

-   Example system architectures, which depict the material mass flows
    typical of Advanced Life Support systems,

-   The types of advanced life support technologies currently available
    for air, water, waste and food,

-   The operation and control challenges of these technologies.

**Exploration Missions, Architectures and Ground Based Test Beds**

***Daniel J. Barta, NASA Johnson Space Center***

The National Aeronautics and Space Administration\'s (NASA) 2003
Strategic Plan introduced a robust, integrated exploration strategy to
extend our sphere of human exploration far beyond the bounds of Earth.
This vision includes exploiting unique waypoints in the Earth\'s
neighborhood that may serve as gateways for future human exploration to
accessible planetary surfaces such as Mars. Through fundamental research
and strategic investment in transformational, crosscutting technologies,
capabilities will be developed to overcome the limitations of human
space travel and open new pathways for science-driven exploration and
discovery. This presentation will describe several of NASA\'s candidate
design reference missions for human exploration, requirements and
possible architectures for advanced life support systems for these
missions and how ground based test beds may be utilized for closed
integrated testing during systems development.

**Challenges and Opportunities of Advanced Life Support Systems Analysis
and Modeling**

***K.C. Ting, The Ohio State University***

Long-duration space missions require the design of advanced life support
systems (ALSS). Functionality and reliability of ALSS are of critical
importance. Each individual component, process, or database within the
system is a building block. While it is obvious that the workability of
the entire system ultimately depends on the performance of each building
block, the interrelationships among them are important concerns as well.
The identification, understanding, description, specification,
utilization, and manipulation of these relationships are the tasks of
systems studies. Computer models have been used as the main tool in
conducting systems studies. Efforts have been made to facilitate and
conduct analyses of ALSS at the systems level. The goal needs to be
achieved by establishing effective communication within the advanced
life support (ALS) community and developing methodologies/computational
tools for integrating ALS information.

Several specific challenges have been identified in systems analysis of
ALSS: (1) Attention to top-level versus process-level modeling; (2)
Emphasis on breadth versus depth; (3) Establishment of effective
information/data exchange protocol; (4) Consideration of model and
analysis expandability, compatibility, and adaptability; (5) Develop
optimum system abstraction; (6) Use of appropriate computational
platforms; (7) Identification of targeted participants and audiences;
(8) Validation of models and results of analysis; (9) Handling of
heuristic, uncertain, and incomplete information; (10) Forms of
deliverables (i.e. case-by-case versus computational tools); and (11)
Coordination of activities. Opportunities that may potentially generate
highly valuable results by building on the past experience of systems
approach include: (1) Systems approach to monitoring and control of
ALSS; (2) Systems approach to reliability analysis of ALSS; and (3)
Information and analysis environment for ALSS (i.e. the concept of
"Concurrent Science & Engineering").

**ALS Control Metrics and Equivalent System Mass**

***Alan Drysdale, Boeing***

Using KSC experience in developing control systems for large plant
chambers and in operating these chambers, relationship between controls
and ESM are explored.

ALS controls issues are identified. KSC experience is particularly
relevant due to the duration and the scale of the CELSS Breadboard
Facility compared to those of anticipated missions.

In particular, reasons for implementing controls, costs, and risks are
addressed. Recommendations based on KSC experience are identified.
Configuration control must be addressed, maintenance is an issue, and
data fusion is essential for robustness.

**Advantages of Hierarchical, Centralized Architectures for Controlling
Real-World Systems**

***David Kortenkamp, Metrica Inc. at NASA Johnson Space Center***

This talk will define a control architecture and its major features and
requirements. A brief history of hierarchical control architectures will
be given. A specific instance of a hierarchical, centralized control
architecture developed at NASA JSC, 3T, will be described in detail. 3T
has been applied to control of several advanced life support system
tests. The talk will end with discussion of the advantages and
disadvantages of a hierarchical, centralized control architecture.

**ALS Integrated Control Challenges**

***David Overland, NASA Johnson Space Center***

There are several possible control architectures for advanced life
support. Whichever architecture is eventually implemented must also
interface and interoperate with other spacecraft and ground support
systems to support mission goals. I will provide an overview of the
complexity of the functions such control systems must support, a
description of the challenges of integrating spacecraft control systems,
and reasons for using a distributed, heterarchical approach to both the
development of such control systems, and the support of mission
operations.

**Putting It All Together: Orchestrating Control Solutions**

***Richard Boulanger, Jacobs Engineering / Sverdrup Technology at NASA
ARC***

Advanced Life Support systems consist of tightly coupled physicochemical
and biological processes which interact to produce changes to material
streams (air, water, waste, etc.) in ways which are necessary to
maintain an environment which continuously supports human life. It is
critical to the success of such systems that these processes interact
with high fidelity. To achieve this degree of interdependence, common,
low-level interfaces are indicated to transport the process instrument
and meta-data which reflect the state of the subsystems, sensors, and by
extension, the ALS system itself. This presentation will familiarize the
audience with the various interfaces which have been investigated and
tested for application to ALS control systems and the results of those
tests.

**Crew/Ground Control Interfacial Requirements**

***Debra Schreckenghost, Metrica/TRACLabs at NASA Johnson Space
Center***

Our experience in developing and deploying automated control software
for extended operation during both the Phase III Lunar/Mars Life Support
Test Program (LMLSTP) manned test and the unmanned Water Recovery System
(WRS) ground tests at JSC has provided valuable insights into
requirements for human interaction with crew life support systems. The
use of control automation can remove the need for vigilant monitoring of
crew life support systems by humans. This reduces the workload of ground
controllers and enables moving ground support out of a centralized
control room into the work place, a critical capability for distributing
ground support operations. The use of control automation also can
standardize routine anomaly management, reducing the need for crew and
ground involvement in handling anticipated problems. These changes in
operations, however, will change the roles that humans fulfill in manned
space operations. New policies and protocols for interaction between
humans and automated control agents must be developed. Existing policies
and protocols for human--human interaction likewise must be adapted to
account for the change in human roles. These policies ensure that the
right people are notified of significant events regarding operations,
including events indicating that they might need to take manual action.
These policies also address consistent, reliable commanding among groups
of human and software control agents. The resulting new tasks and
changed protocols require new types of software to assist humans in
performing them. Based on our experience with advanced life support
control, we believe that such new software requires more than just good
display design. It requires developing support software to aid people in
interacting and cooperating with both the automation and the underlying
life support system as well as modifying the design of the control
systems for such interaction.

In this presentation we describe the lessons learned about human
interaction with life support systems resulting from the deployment of
control automation during life support ground tests at JSC. We also
present the Distributed Collaboration and Interaction (DCI) environment
developed to support crew and ground controllers when interacting with
life support systems that include automated control software.

**Reliability, Safety and Error Recovery for Advanced Control Software**

***Jane T. Malin, NASA Johnson Space Center***

For long-duration automated operation of regenerative life support
systems in space environments, there is a need for advanced integration
and control systems that are significantly more reliable and safe, and
that support error recovery and minimization of operational failures.
This presentation outlines some challenges of hazardous space
environments and complex system interactions that can lead to system
accidents. It discusses approaches to hazard analysis and error recovery
for control software and challenges of supporting effective intervention
by safety software and the crew.

**The Future of ALS Monitoring and Control: Challenges**

***Jon D. Erickson, Berkley Street Consulting, Inc.***

In this presentation we present a summary of the problem of Advanced
Life Support (ALS) Monitoring and Control (M&C) and goals to address
solving the problem in the future.

The following goals and challenges speak to a summary of the problem and
ways to address it:

-   To build a self-sustaining life support system for long-duration
    human space missions by replacing the large-scale, long-term
    processes and large reservoirs of Earth with small-scale, short-term
    processes, small reservoirs, and an external intelligent monitoring
    and control (M&C) system that can take dynamics into account.

-   To build an adjustably autonomous monitoring and control system for
    life support in space that supports migration from physicochemical
    to bioregenerative life support systems (BLSS) with minimal
    resupply, as the BLSS is built and is operated on a planetary
    surface. Adjustable autonomy refers to allowing humans to supervise
    and adjust the M&C agents' behavior if necessary and is required for
    safety purposes.

-   To meet the requirements for minimal crew time in ALS M&C (remember
    it is a small crew) and the requirements for M&C response in
    fractions of a second to seconds (faster than communications to
    ground control).

-   To build a combined distributed collaboration and interaction
    capability (crew and ground) with a layered intelligent, adjustably
    autonomous monitoring and control system at each level of the asset
    hierarchy (Base or Vehicle, Systems\[Life Support\], Subsystems,
    Assembly) that provides a deliberative planning and scheduling
    layer, an operations procedures layer, and a layer of situated
    skills based on sense-act loops. This distributed collaboration and
    interaction capability, consisting of active, vigilant, and tightly
    coupled external software processing as by "liaison agents," is
    required to allow the human to work effectively in a multi-agent
    world while avoiding overload of the M&C agents and degrading their
    performance on their primary tasks. This approach also provides, by
    design, pre-integration of the monitoring and control software.

Other challenges such as building and adequately testing truly
representative ALS hardware and M&C software are addressed. Some
specific next steps are also addressed to aid the workshop participants,
such as developing software-motivated ALS hardware requirements and
design guidelines so as to enable the intelligent control software to be
safer and more reliable.

**Industrial Process Measurement and Control**

***R. Russell Rhinehart, Oklahoma State University***

Control is information processing, and uses both hardware (sensors,
transmission equipment, final elements) and software (algorithms for
state estimation, transmission protocol, and decision automation).
\"Best practices\" for control within the chemical process industries
(CPI) must balance the use of best technology with practical issues of
human training, maintenance standardization, and performance/cost
analysis. Depending on the business, best practice might be either
today\'s leading technology or tried-and-true 100-year old approaches. I
will summarize the range of techniques for sensing and perception,
process measurement and analysis, decision automation, and operator
engagement currently used within the CPI; and will provide insight as to
why certain approaches are chosen.

**Research Directions in Industrial Control**

***David Musliner, Honeywell Labs***

Current industrial control systems operate quite reliably in hazardous
and mission-critical environments, using both simple PID control loops
and more advanced model-predictive optimization techniques. However, the
scale of industry and the severe consequences of even minor disruptions
mean that oil refineries alone lose over ten billion dollars each year
due to abnormal situations. Existing control systems do not operate well
during abnormal situations. In this presentation I will summarize
several causes of abnormal situations, discuss the weaknesses in
existing approaches, and overview a series of research projects we have
been investigating to reduce the frequency and costs abnormal
situations. These research projects address topics including automated
state estimation, automated adaptive response, human
interface/understanding, and mixed-initiative procedural assistance.

**Reconfigurable Autonomous Agent Architecture for Shipboard
Automation**

***Francisco Maturana, Rockwell Automation***

A multi-agent architecture is proposed to create highly distributed
autonomous control systems. The multiple distributed agents are created
with artificial social behaviors to enable component level intelligence
and cooperative decision making in highly dynamic systems. Adaptation
and auto configuration behaviors enable the intelligent agent to
configure the physical equipment to fulfill mission specific tasks while
satisfying real time constraints. Agents organize their respective views
about the system to react to changes and to discover and deploy system
capabilities. We explore the implications of using agent technology in
the design and operation of a Chilled Water System (CWS) to support the
operations of a real shipboard system. Implications such as
sustainability and survivability are addressed throughout dynamic
reconfiguration and learning. Our aim is to contribute with a set of
guidelines on how to build autonomous agents for automation using COTS
components.

**Control in Unmanned NASA Missions**

***Carl Ruoff, Jet Propulsion Laboratory, California Institute of
Technology***

NASA missions are becoming increasingly ambitious, with operational
requirements ranging from exploring remote planetary surfaces, to
imaging extrasolar planets with constellations of spacecraft, to
assuring the well-being of astronauts during planetary missions.
Successfully meeting these requirements requires sophisticated control
systems.

Using the MER and MSL missions as examples, this presentation summarizes
some of the control approaches used in planetary missions and indicates
future extensions. It also describes research in formation flying,
adaptive optics, and wavefront control being conducted for astronomical
missions, and briefly describes a trace gas sensor being developed for
life support.

**Autonomous Control with the Remote Agent in Deep Space One**

***Barney Pell, RIACS at NASA Ames Research Center***

The Remote Agent is an autonomous agent architecture for control systems
based on the principles of model-based programming, on-board deduction
and search, and goal-directed closed-loop commanding. This architecture
addresses the unique characteristics of the spacecraft domain that
require highly reliable autonomous operations over long periods of time
with tight deadlines, resource constraints, and concurrent activity
among tightly coupled subsystems. The Remote Agent integrates
constraint-based temporal planning and scheduling, robust multi-threaded
execution, and model-based mode identification and reconfiguration. The
Remote Agent was demonstrated as an on-board controller for Deep Space
One, NASA\'s first New Millennium mission, during a week-long experiment
in early 1999. During the experiment, the spacecraft was not given the
usual detailed sequence of commands to execute. Instead, the spacecraft
was given a list of goals to achieve during the experiment. In flight,
the Remote Agent flight software generated plans to accomplish the
goals, executed the plans in a robust manner, diagnosed and recovered
from simulated failures, created new plans when necessary, and provided
an interface to human operators that supported variable levels of
autonomy.

**Control Issues in Water Processing**

***Peter Bonasso, Metrica Inc. at NASA Johnson Space Center***

This talk discusses a JSC experience building and running an intelligent
control system for a NASA advanced water recovery system. We used the 3T
intelligent control architecture to produce software that operated
autonomously, 24/7 for sixteen months. The article covers our
development approach and our lessons learned from the perspectives of
autonomy and long-duration monitoring and control.

**An Advanced Life Support Simulation for Integrated Controls Research**

***David Kortenkamp, Metrica Inc. at NASA Johnson Space Center***

This talk will describe a simulation of an integrated advanced life
support system. The simulation contains models of the major components
of a life support system including crew, biomass, water recovery, air
revitalization and food processing. The simulation

models malfunctions and stochastic processes. Sensors and actuators are
modeled to allow controllers to interact with the simulation. The
simulation is designed for testing and evaluation of life support system
control approaches.

**Distributed Design vs. Reliability**

***Ken Arnold, EventMonitor, Inc.***

Ever since we could get two computers to talk, we have tried to get them
to cooperate reliably. As with computer translation of human language,
this has proven more difficult than imagined. Centralized systems can be
more controlled, and hence more stable, but they scale poorly. As more
things happen in space, more problems will become distributed problems,
and they will be increasingly critical to human safety and success. In
the hope that it will inform the design of distributed control systems
in space, this talk will give an overview of distributed computing
problems and some historical and current approaches.

**Proofs and Paths from The Book of Mars**

***Daniel Cooke, Texas Tech University***

Research and exploration have a lot in common. Drawing upon Paul
Erdos\'s notions of \"proofs from the book,\" the goal of this talk is
to demonstrate the relationship between the exploration of intellectual
and physical spaces. In the context of exploring intellectual spaces,
proofs from the book are viewed as the simplest, most elegant pathways
for achieving a goal (or hypothesis). Likewise, in the context of
exploring physical spaces there tend to be simpler approaches that may
reduce risk and cost. This talk will introduce a staged approach to Mars
exploration involving libration points, so-called interplanetary
superhighways, and telepresent exploration, all in support of the
ultimate goal: to place a light-weight human footprint on Mars. Subgoal:
To be entertaining and informative.