HAB.NET – An Integrated Framework for Analyzing the Sustainability of Planetary Habitats

GLEX-2012.10.2.6x12391 Page 1 of 14 Page 1 of 14

GLEX-2012.10.2.6x12391

HAB.NET AN INTEGRATED FRAMEWORK FOR ANALYZING THE SUSTAINABILITY OF PLANETARY HABITATS

Sydney Do

Massachusetts Institute of Technology, Cambridge, MA, United States, [email protected]

Olivier de Weck

Massachusetts Institute of Technology, Cambridge, MA, United States, [email protected]

In recent years, NASA has significantly increased its pursuit of developing the capability to sustain humans on Lunar

and Martian surfaces, with the development path taken to achieve this based primarily on experience from the Apollo

and International Space Station programs. Although these have provided a wealth of knowledge, neither program

was originally architected to achieve long-term life-support in an environment void of regular resupply. To address

this, we propose Hab.Net an integrated framework for architecting and modeling crewed planetary habitation systems. We develop the framework using the Object Process Methodology, upon a foundation based on the

underlying themes of human space exploration extracted from the past two decades of U.S. space policy. By

developing Hab.Net exclusively within the functional domain, we show the capability of the framework in capturing

and modeling a broad range of concepts aimed at addressing different functional areas within the Mars habitation

problem. Finally, we discuss the incorporation of the Three Es model of sustainability into Hab.Net, and discuss how

it can be used to quantify the sustainability of habitat architectures on Earth and in space.

I. INTRODUCTION

Since the cancellation of the Constellation program in

2010, NASA has adopted a capability-driven approach

to its human spaceflight program, where the

development of the key technologies required for

human exploration beyond low Earth orbit (LEO)

determines the Flexible-Path of destinations chosen. This represents a fundamental shift away from the

traditional approach of choosing a target in space, and

building the systems to support transportation to, and

habitation at, the given destination. While the reliance

of this new approach on pushing technological

development makes it inherently uncertain, it provides

an opportunity for us to explore new ways of

architecting the complex engineering systems that will

enable sustained human spaceflight beyond LEO. This

paper presents Hab.Net an integrated framework for conceptualizing and modeling such complex

engineering systems, based on the Object Process

Methodology1,2

. In particular, we focus on modeling a

Mars habitation system from the human-centric

standpoint, with the intent of understanding how the

behavior of sustainability emerges from the interactions

between the basic elements required to support human

life. There are two primary reasons for choosing this

case, being that:

It is widely agreed upon that a sustained presence on Mars is the ultimate goal for human space

exploration3. We argue that in order to make the

most informed decision regarding the choice of

transportation and surface architecture required to

enable this, it is necessary to understand what it

takes to achieve this final goal. This will become

particularly important when addressing the phasing

problem: That is, what is the best way to transition a

Martian habitat system from one that is primarily

reliant on periodic resupply, to one that is self-

sustaining?

There are several parallels between developing a sustainable colony on Mars (and extreme

environments in general), and on Earth. In both

scenarios, the basic physiological and psychological

needs of the human must be considered, as well as

the effects of the local environment on these needs.

In studying the requirements for sustainability on

Mars, we gain insight into one of the most

challenging problems we face on Earth today How do we transition to a sustainable society which

fosters economic development and technological

progress, while protecting the environment, and

accommodating the basic needs of all?

Rather than attempting to address these problems

directly, this paper aims to present a framework for

modeling and analyzing the enabling systems. This is

based on using the inherent functional interactions

within the problem to inform the conceptual phase of

systems architecting, as well as the structure of the

corresponding model. Section II provides a theoretical

background and motivation for this approach and the

methods used to implement it. Section III presents the

functional decomposition used as the basis for Hab.Net.

Here, we use the atmosphere managing function to

demonstrate the ability of the framework to incorporate


models of different concepts that span different levels

within the functional hierarchy. Finally, in Section IV,

we provide concluding remarks and discuss potential

applications of the framework beyond the systems

architecting and modeling domain.

II. BACKGROUND AND MOTIVATION

One of the key motivations for this work is the

realization that in an environment where the system

requirements are driven by multiple stakeholders with

uncertain needs and goals, the only approach to

architecting the system is to Middle-Out4. As demonstrated in Figure 1, this approach consists of

developing a set of architectures to inform both the

upstream needs and goals of the stakeholders, as well as

the downstream influences on the operations and life-

cycle properties of the system.

Fig 1: Middle-Out Architecting Process (adapted from

Ref. [4])

This approach contrasts significantly to the more

traditional top-down approach, typically employed in

the commercial sector. Usually, a need is identified in

the market, goals are developed based on a corporate

and market strategy, and corresponding requirements

are generated and fed into the systems engineering

process. For the current development of human

exploration systems however, the needs for such

endeavors are still under debate, the near term goals are

uncertain, and this results in an undefined input to the

system architecting process. In spite of this, there are

two common themes that can be extracted from the U.S.

national space policy of the past twenty years, being:

The desire for a sustained human space exploration program.

The notion of sustained exploration first appeared

explicitly in President Bush Sr.s Space Exploration Initiative announcement in 1989, with the statement

that We must commit ourselves anew to a sustained program of manned exploration of the solar system

and, yes, the permanent settlement of space5. Since then, each presidential space policy announcement

has made a reference to a sustained human presence

in space, with the most recent being made by

President Obama in April 2010: Our goal is the capacity for people to work and learn and operate

and live safely beyond the Earth for extended

periods of time, ultimately in ways that are more

sustainable and even indefinite6

Human settlement of Mars is the ultimate goal Plans for human missions to Mars have been

conceived since before the dawn of the space age,

originating most notably with Wernher von Brauns Das Projekt in 1952

7. In the past two decades,

NASA has periodically released a Mars Design

Reference Mission, which has been used to both

inform and respond to U.S. space policy

announcements. The most recent of these is the

NASA Design Reference Architecture 5.08, which

was developed as part of the Constellation program

effort. With the redirection of the agency following

Obamas April 2010 announcement, new approaches for Martian surface systems architecting are

currently being explored

These two themes guide the overarching middling-out

architecting process that forms the basis of the proposed

framework.

II.A. Theory of System Architecture

In this section, we define some of the terms used in this

paper, and discuss the underlying theory. A system is a

set of entities that interact with each other to accomplish

a function that could not be accomplished by the sum of

the functions of the individual entities. This

phenomenon is referred to as emergence.

An architecture is a representation of an instance of a

system. That is, it is a system where the individual

entities, their individual functions, and the emergent

functions do not change. In Figure 1, it is represented by

everything shown in the gray circle. Crawley defines it

as the embodiment of concept, and the allocation of physical/informational function to elements of form,

and the definition of interfaces among the elements and

with the surrounding context9. Here the surrounding context refers to the upstream and downstream

influences discussed earlier, and also represented in

Figure 1.

Form refers to the physical or informational

embodiment of the entities of the system, and their

arrangement; while function is what the system does,

and is the action for which an element of form exists.

Finally, a concept is defined as the mapping from

function to form. Developing a concept is sometimes

referred to as the art of systems architecting, since there is no fixed method of doing this. It requires

imagination and creativity to make the leap from the

functional to the formal domain.


Finally, we define the term value as being benefit at

cost. Given this, it is important to note that benefit is

derived from the function of a system, while cost is

derived from its form. We shall now use an example to

illustrate these ideas.

Elements/Entities

Form Representation of Form Function

Beam

Carry

moment

and shear

forces

Support

React

translation

forces

Architecture

Form Representation of Form Emergent

Function

A.

Lever

Increase

force

B.

Assembly

None

Fig 2: Function versus Form example

Consider the elements of form depicted in Figure 2.

Represented here are a beam, whose elemental function

is to carry moment and shear forces; and a support,

whose elemental function is to react to translation

forces. When these elements are arranged in a manner

exhibited by Architecture A, the function of increasing force emerges. The resulting form that corresponds to this arrangement is typically called a lever. Note however, that if these elements were arranged in any

other way, a different function would emerge from the

interaction of their elemental functions. This is depicted

in Architecture B, where the support is placed atop the

beam, rather than beneath it. In this scenario, no

emergent function results, as no interaction occurs

between the individual functions of the elements.

Because this is the case, we can conclude that

Architecture B is not a system, whereas Architecture A

is, due to the emergent function that it exhibits.

There are a few insights that can be gained from this

simple example, namely:

The arrangement of form (i.e. structure) enables a system to exist; however, emergence arises from the

interaction between the individual functions of the

elements of form. That is, emergence occurs within

the functional domain.

The benefit of an architecture is derived from the emergent function, while its cost is derived from the

elements of form. It is clear that the arrangement of

Architecture A yielded an added benefit which was

not obtained by Architecture B. However, since both

architectures contained the same elements, and the

connections between their elements were very

similar, it can be assumed that their costs are

essentially the same. Given the definition of value

discussed earlier, it can be concluded that

Architecture A has more value than Architecture B.

The aggregation of form occurs in a linear manner, whereas the emergence of form does not. This is

illustrated by the fact that describing the form of

both of the architectures represented above is

relatively straightforward. One could define a

reference coordinate system on both the beam and

support and describe where they connect.

Contrastingly, this is not the case within the

functional domain. Summing the functions of

carrying shear and moment forces and reacting translation forces without consideration of the corresponding elements of form, has no clear result.

Moreover, the fact that function does not aggregate

in a predictable manner reinforces the need for

creativity and imagination when determining the

underlying concept - the mapping of function to

form

Given these insights, it can be concluded that the

value of an architecture lies in its emergent function.

When architecting a system, a concept must be

conceived which maps the emergent function to some

arrangement of form.

The typical approach to accomplishing this is to

decompose the emergent function into elemental

functions, and to develop concepts to accomplish each

of these. The result is often a one-to-one mapping of

function to form, and arises partly because function and

form are represented in their own domains during this

process. For space systems, this typically entails firstly

deriving a Concept of Operations, decomposing this

from the operations perspective using a Functional Flow

Block Diagram (FFBD) (see Figure 3), defining

requirements for each block of the FFBD, and engineering a subsystem based on these requirements.

As this is occurring, the form of the system is typically

represented by a Product Breakdown Structure (PBS)

(see Figure 4), and is updated as each set of functional

requirements is being addressed.

A potential outcome of this process is that the

parallel development of FFBDs and PBSs creates an

environment where the set of concepts employed are

implicitly assumed, to ensure that the two

representations are synchronized. In many cases, this

concept selection occurs on a one-to-one basis, and is

Fin Fout

Fin Fout

Fin

Fout


typically influenced heavily by legacy approaches.

While this is adequate for simple and medium level

systems, we argue that complex systems require more

time to be spent in the conceptual development phase to

exploit emergent behaviors; that is, to develop concepts

which satisfy many functions with the minimal number

of elements of form. This becomes increasingly

important in the realm of space systems development,

where the immense mass, volume, power, and

budgetary constraints (all of which are costs that are

derived from elements of form) make finding even

feasible architectures almost impossible.

Fig 3: Functional Flow Block Diagram of a Notional

Satellite System (Adapted from Ref. 10)

Fig 4: Product Breakdown Structure of Notional a

Satellite System (Adapted from Ref. [10])

While the concept of multi-functional design is not new, it remains a rule of thumb in the practice of

engineering. We attempt to address this by constructing

a formal method to facilitate the development of

concepts that map functions across all levels of a

functional decomposition to elements of form in a one-

to-one and many-to-one manner. This is illustrated in

the figure below.

Fig 5: Different types of function to form mapping, as

denoted by the line with the circular tip a). One-to-One

mapping b). Many-to-One mapping. This variant is

referred to as Multi-Functional because one element of

form addresses multiple functions at the same level in a

functional hierarchy c). Another variant of the Many-to-

One mapping. This version is referred to as Cross-

Functional, since one element of form addresses

multiple functions across different levels of the

functional hierarchy. That is, it crosses the structural

boundaries within the functional hierarchy.

This idea forms the basis for the development of the

Hab.Net framework, described in Section III.

II.B. Basics of Object Process Methodology1,2

In this section, we introduce the Object Process

Methodology (OPM) - a technique that simultaneously

represents function and form, thereby facilitating a

formal process for concept exploration and

development. OPM is based on the idea that all things

can be represented as an object, or a process. Objects

can be considered to be analogous to elements of form,

with the added property that they can take on different

states of existence over some period of time.

Contrastingly, processes act to transform the state of

one or more objects. When processes are combined with

objects, functions are achieved. That is, a function

occurs when a process acts on an object to change its

state.

A unique feature of OPM is that it consists of both a

graphical and a verbal representation. The graphical

representation, referred to as an Object Process Diagram

(OPD), enables system structure and behavior to be

represented in the same medium. Moreover, OPDs

allow for the representation of a system at different

levels of abstraction using the same syntax.

Complementing OPDs is the verbal representation of

OPM, known as the Object Process Language (OPL),

which allows one to read OPDs with natural language. This removes ambiguity in the interpretation

of OPDs between users, and provides a common

language for them to communicate concepts amongst

each other. With this, we now describe the basic syntax

of OPM.

1. Ascent

into Orbit

Injection

2. Check

Out and

Deploy

3. Transfer to

Operational

Orbit

4. Perform

Mission

Operation

s

4.1

Provide

Power

4.2 Provide

Attitude

Stabilization

4.3 Provide

Thermal

Control

4.4 Provide

Orbital

Maintenance

4.5

Receive

Command

4.6 Acquire

Payload

Data

4.7

Transmit

Data

Top Level

Second Level

Flight

Segment

Payload

Element

Spacecraft

Bus

Launch

Accommodations

Electronics

Sensors

Spacecraft

Interface

Power

Structure

Command

& Data

Guidance,

Navigation

& Control

Propulsion

Mechanisms

Communications Payload

Interface

Thermal

Electrical

Payload

Attached

Fitting

Electrical

Supply

Function

Form

Function

Form

Function

Function

Form

Sub-

Function

Function

Sub-

Function

a).

b). c).


Tables 1 to 4 summarize the basic constructions used in

OPD.

Name OPD Example OPL Example

Human

Nourishing

Human can be

Hungry or

Satiated

Table 1: OPM Basic Elements


Decomposition

(Sub-

components)

Human consists of

Head, Torso, and

Limbs

Nourishing consists

of Consuming and

Metabolizing

Exhibition

(Attributes)

Human exhibits

Gender, Height,

and Weight

Nourishing exhibits

Frequency and

Quantity

Specialization

(is a Variant of)

Infant is a type of

Human

Adult is a type of

Human

Eating is a type of

Nourishing

Drinking is a type

of Nourishing

Instantiation

(is an Instance

of)

John is an instance

of Human

Mary is an instance

of Human

Table 2: OPM Structural Links. Terms in parentheses

can be considered as descriptions of the class of items

stemming from the given link


Consumption

Nourishing

consumes Food

Result

Nourishing

yields Metabolic

Energy

Affect

Nourishing

affects Humans or depending on

the context,

Humans affect

Nourishing

Enabler

Exploring

requires

Transportation

Intelligent Enabler

Exploring is

handled by

Humans

Table 3: OPM Procedural Links

OPD Example OPL Example

Rep

rese

nti

ng

Fu

nct

ion

Explicit Form

Nourishing changes

Humans from Hungry to

Satiated

Affect Link

Nourishing affects

Humans or depending on the context,

Humans affect Nourishing

Suppressed

Representation

Nourishing Humans

(Verb + ing + Noun) or depending on the context,

Human Nourishing

(Noun + Verb + ing)

Inv

oca

tio

n

Explicit Form

Exploring is handled by

Humans.

Nourishing changes

Humans from Hungry to

Satiated

Invocation Link

Exploring invokes

Nourishing Humans

Table 4: Equivalent Representations in OPM

Nourishing

Humans

Exploring

Humans

Nourishing

Hungry Satiated

Exploring

Nourishing Humans

Humans

Nourishing

Humans

Nourishing

Hungry Satiated

State

State Hungry

Human

Satiated

Humans

Exploring

User

Process

Transportation

Exploring

Object

Process

Humans

Nourishing

Object

Process

Metabolic

Energy

Nourishing

Object

Process

Food

Nourishing

Object

Process

Human

John

Mary

Nourishing

Eating

Drinking

Human

Infant

Adult

Frequency

Quantity

Nourishing

Human

Gender

Height

Weight

Nourishing

Consuming

Metabolizing

Human

Head

Torso

Limbs

Process

Process

Object

Object

Human

Nourishing


As can be seen from the tables above, processes are

represented by ellipses, and objects are represented by

rectangles in OPDs. These elements are linked together

using two classes of links: structural links and

procedural links. As the name suggests, structural links

represent physical and measurable connections between

elements, such as its components, its attributes, its

variants, and its instantiations. In almost all cases,

structural links can only be used between the same types

of elements. The only exception to this is when a

process exhibits attributes, as demonstrated in the 4th

row of Table 2.

Contrastingly, procedural links are used to relate

processes to elements of form. They represent

unidirectional changes of state (with the consume and

yield links), function (with the affect link), the role of

the user (with the intelligent enabler link), and concept

(with the enabler link).

A unique feature of OPD is that the simultaneous

representation of objects and processes allows

mathematical relationships to be expressed. Figure 5

shows an example for this, using the First Law of

Thermodynamics.

Physical Interpretation:

The change in the internal energy of a closed system is

equal to the amount of heat supplied to the system,

minus the amount of work performed by the system on

its surroundings

Mathematical

Representation:

dU = U2-U1 =Q-W

OPD Representation

OPL Representation:

Energy Conserving changes

Object from U1 to U2.

Energy Conserving affects

Heat Reservoir and Work

Reservoir

Fig. 5: OPM of the First Law of Thermodynamics9

Here we can see that in OPM, equations can be

represented by processes, and variables can be

represented by the state of the objects. Moreover, OPM

allows for the zooming-in and panning-out of systems, thus enabling layers of abstraction and detail to

be represented using the same syntax. Figure 6 depicts

an example of this.

Panned-Out

Zoomed-In

Fig. 6: Panned Out and Zoomed-In OPM Representation

Collectively, the capabilities of OPM enable an

integrated framework for conceptualizing and modeling

complex engineering systems. In the next section, we

apply the above-discussed OPM techniques to build

such a framework for a Mars habitation system.

III. THE HAB.NET FRAMEWORK

Based on the themes discussed in Section II, we

apply the OPM technique to the challenge of the

Sustainable Human Exploration of Mars, as a first step in the development of the Hab.Net framework. To

ensure that the framework can be mapped to exploring

other celestial locations, as well as addressing the

challenge of sustainability on Earth; the framework is

structured such that the local environmental influences

can be easily interchanged. Based on this, the

overarching problem statement can be converted to an

OPD, as shown below:

Fig. 7: OPD of Overarching Problem Statement

In formal OPL, the OPD in Figure 7 reads:

Exploring exhibits Mars and Sustainably, and is handled by Humans. Here, Exploring has been chosen as the overarching process to be used for

extraterrestrial environments, such as Mars.

Additionally, we have used the agent link to fix the

concept of Humans as being the primary agent of Exploring. This makes the framework human-centric, in that it focuses on the interactions between the

environment which is being explored, and the humans

who are performing the exploration. A more exhaustive

framework for Exploring would cover all enabling elements of form, such as Robots, Transportation, and Communications. Figure 8 shows a notional example of such a framework.

Fig. 8: Notional OPD of an entire Space Exploration

System

Exploring

Mars

Sustainably

Exploration

System

Transporting

Performing

Science

Communicating

Data/Findings

Robots

Transportation

Communications

Humans

Exploring

Mars

Sustainably

Humans

Nourishing

Metabolic Energy

Consuming

Metabolizing

Digesting

Bolus

Nutrients

Food Food

Nourishing

Metabolic Energy

Object

Energy

Conserving

U1 U2

Work (W)

Reservoir

Heat (Q)

Reservoir


Additionally, we note that to analyze sustainability

on Earth, the same basic OPD structure shown in Figure

7 could be employed. This is shown in Figure 9, where

the Exploring process has been replaced with Developing, and the attribute of Mars, with Earth. Through this, we can begin to observe the robustness of

the framework in capturing different environmental

effects.

Fig. 9: OPD of Sustainable Development on Earth

With the problem statement now formally

represented, we introduce the primary function that

enables humans to sustainably explore Mars: the

function of Sustaining Humans. In addition, we fix the concept that a Habitable Space is required to enable this function. Here, the term Habitable Space was chosen as a general term to encompass all

habitation options, such as rigid modules, inflatable

structures, and EVA suits. This ensures that the

framework remains solution neutral, by not implicitly

imposing any concepts a priori. In doing so, the utility

of the framework for other exploration destinations is

maintained. Two OPD representations of this function

are shown in Figure 10 one that is explicit, and one that is suppressed. In this figure, the notion of a system

boundary is introduced. This represents everything that

the system architect has control over when architecting

the system. The influence of the exploration

environment on the elements within the system

boundary will become apparent in the next section.

Furthermore, for the remainder of this paper, we will

use the explicit representation of the function of

Sustaining Humans to emphasize the importance of the human. For all other derived functions, unless

otherwise noted, the suppressed representation of

functions is used in the interest of ensuring readability

of the corresponding OPD.

Fig. 10: a). Explicit; and b). Suppressed Representations

of the Sustaining Humans function

III.A. Functional Decomposition

With the overarching structure now established, a

decomposition of function is performed on the OPD

represented in Figure 10a) to investigate lower levels of

interaction inherent to the problem. Figure 11 shows the

first layer of this decomposition.

Exploring

Mars

Sustainably

Sustaining Habitable

Space

Humans

Ill-Conditioned Healthy

Exploring

Mars

Sustainably

Sustaining Humans

Habitable Space

System Boundary

System Boundary a).

b).

Developing

Earth

Sustainably

Humans

Exploring

Sustaining

Volume Physiologically

Sustaining

Psychologically Sustaining

Contingency Scenario Sustaining

Mars

Habitable Space

Internal Arrangement

Wall Material Configuration

Number of Crew

Mission Duration

Humans


Human Consumables

Metabolic Waste

Metabolic Output

Shape

System Boundary

Sustainably

Internal Objects

Fig. 11: First Level Decomposition of the Concept of Sustaining Humans on Mars with a Habitable Space


Here, it can be seen that:

The Sustainably attribute of Exploring has been further characterized by the two independent

variables: Number of Crew and Mission Duration. In the space exploration context, these two variables

drive the entire architecting process, and were hence

included. As will be discussed in Section III-C, these

two variables can also act as proxy metrics for

sustainability

The Sustaining process has been decomposed into the processes of Physiologically Sustaining, Psychologically Sustaining, and Contingency Scenario Sustaining. These are broad classes for sustaining humans which roughly map to the levels

of Maslows hierarchy of needs

The Internal Objects have been introduced, which interact with the Sustaining sub-processes to enable the Sustaining Humans function. These consist of Human Consumables, Metabolic Output, and Metabolic Waste. In OPL, these interactions can be described as: Physiologically Sustaining consumes Human Consumables, affects

Metabolic Output, and yields Metabolic Waste.

Psychologically Sustaining affects Human

Consumables. Contingency Scenario sustaining

consumed Human Consumables

The Habitable Space has been characterized by the attributes of: Volume, Shape, Internal Arrangement, and Wall Material Configuration. It was found that all low level functions required to

sustain a human crew in an extreme environment

were affected by some combination of these four

characteristics of a habitable space. Indeed, it is

these four characteristics which are typically used to

initiate the habitat design process

Note that only a decomposition in the functional

domain has been performed here, rather than the formal

domain. This was intentionally performed so as to not

implicitly enforce a concept to address a given set of

functions. This is particularly important because the

intent of this framework is to be capable of capturing all

concepts that could possibly be conceived to address the

Mars habitation problem. At the current level of

decomposition however, many key interactions are

suppressed, thus prompting the need for the current

OPD to be further decomposed. The result of this is

shown in Figure 12.

In Figure 12, the significant increase in complexity

resulting from the additional layer of functional

decomposition can be immediately observed. This is

primarily due to the characterization of the Martian

environment, the decomposition of each of the classes

of Sustaining, and the decomposition of each of the internal objects.

In order to make this OPD more readable, we have

introduced some additional notation. This is described

as follows:

A solid box enclosing a set of objects indicates a characterization relationship to all elements within the box. For example, Sustainably is characterized by Number of Crew and Mission Duration

A dotted box enclosing a set of objects indicates a decomposition relationship. For example, Metabolic Output consists of Metabolic Energy and Heat

A colored procedural link connecting a process to a box of the same color indicates that the given link

exists for all objects within the box. That is, these

represent a one-to-many process-to-object

relationship

Moreover, we have chosen to gray-out all procedural

links except those that represent one-to-many process-

to-object relationships and those that are connected to

the Atmosphere Managing function. This Atmosphere Managing function will be the basis of a case study performed in Section III-B, to demonstrate

the utility of this framework in capturing existing

engineering concepts.

With this added layer of fidelity, we can make

several observations regarding the lower interactions

inherent to the Mars habitation problem. These include:

The interactions between the Martian environment and the Physiologically Sustaining functions. Here, we observe that the majority of

Physiologically Sustaining functions are present due to the effect of the environment on the human.

Interestingly, there is almost a one-to-one mapping

between each environmental attribute and each

function required to address it.

The weak interaction between the environmental attributes and the Psychologically Sustaining and Contingency Scenario Sustaining functions. This is due to the fact that these classes of sustaining are

derived from mostly environment-invariant

elements. For example, the major source of vibration

and noise in a closed environment is typically from

machinery used to enable functions other than

Noise Managing and Vibration Managing.

The presence of the environment-invariant functions. These are represented in a lighter shade of blue, and

are required to sustain humans regardless of their

local environment. One can view these as guidelines

for leading a balanced and healthy lifestyle. That is,

one should eat well (Nourishing), exercise regularly,

avoid bacterial infection, sleep enough hours, find

time for enjoyment (Entertaining), have good

relationships with others (Connecting to

Family/Friends), and seek medical or dental

treatment when required.


Exploring

Sustaining

Volume

Physiologically Sustaining

Psychologically Sustaining (Stress Managing)

Contingency Scenario Sustaining

Mars

Habitable Space

Thermal Managing

Muscle Atrophy Preventing

Atmosphere Managing

Cardiovascular Deconditioning

Preventing

Micrometeoroid Protecting

Entertaining

Lighting

Vibration Managing

Connecting to Family/Friends

Sleep Accommodating

Noise Managing

Medical Caring

Dental Caring

Number of Crew

Mission Duration

0.38G Gravity

-120C to -20C Surface Temperature

Wind Speeds up to 30m/s

~95% CO2 Atmosphere

Surface Solar Particle Event Exposure

Surface Galactic Cosmic Ray Exposure

Micrometeoroids

High Dust Environment

Sol: 24h, 39m, 35.244s

Low Density Atmosphere

Water

Food

Respiration Products

Heat

Human Crew


Metabolic Energy

Water

Food

Liquid Waste Products

Solid Waste Products

Breathable Air



Shape

Surface Solar Radiation Density:

600-700W/m2

O2

N2

Radiation Protecting

Sustainably

Bacterial Infection

Preventing

Bone Degeneration Preventing

Habitable Space Attributes

Hu

man

Co

nsu

mab

les

Meta

bo

lic

Ou

tpu

t

Meta

bo

lic W

aste

Hu

man

Con

su

mab

les

Nourishing

Exercising

System Boundary

Fig. 12: Second Level Decomposition of the Concept of Sustaining Humans on Mars with a Habitable Space


The functions which are most heavily dependent on the Internal Objects are those which are

environment-invariant (i.e. the lighter blue

functions). This indicates that the fundamental

functions required for human survival impose almost

all requirements for consumables. Indeed, this is a

true statement, as can be observed by the contrasting

resupply needs of crewed and robotic space missions

The importance of Atmosphere Managing and Thermal Managing when sustaining humans in extreme environments. This is indicated by the

relatively high number of dependencies between the

environmental attributes and internal objects with

these functions. At this level of decomposition, all

other functions appear to be influenced only by one

object type, being either the environmental

attributes, or the internal objects. This classification

of functional dependency can be used to inform the

structure of a numerical model based on this

framework

Finally, we note that the functions of Powering and Providing Communications are not present in Figure 12. This is because they do not directly deliver

value to the Sustaining Humans function. Rather, they are considered to be supporting functions, which are

derived from elements of form required to enable the

primary value delivering functions. This is depicted in

the suppressed OPD shown in Figure 13, where

concepts for the value delivering functions of Thermal Managing, Atmosphere Managing, and Connecting

to Family/Friends has been assumed (using the Enabler link).

By distinguishing between value delivering

functions and supporting functions, we introduce the

dimension of value in the OPD. Contrasting to the

dimension of structural decomposition that exists in the

form domain (i.e. levels of decomposition), levels of

value exist purely within the functional domain. In

Figure 13, we observe a decreasing level of value as we

move from left to right, and the corresponding functions

become further separated from the fundamental function

of Sustaining Humans. It should be emphasized, however, that the value of a function is relative to the

fundamental function chosen. If we were to sustain

robots rather than humans, Powering would become a value delivering function, as robots require power to be

sustained. Conversely, providing power does not

directly sustain humans. Instead, providing power to

enable thermal and atmosphere managing is what

enables humans to be sustained.

III.B. Concept Exploration

Throughout the Hab.Net framework development

process, we have focused exclusively on the functional

domain, while intentionally avoiding any analysis of the

form domain. As was earlier mentioned, the purpose of

this is to avoid the implicit imposition of concepts

within the system, so that all potential solutions can be

captured and modeled within the framework. The added

benefit of this is that by enforcing solution neutrality, an

environment is created which encourages both multi-

Sustaining Humans


Psychologically Sustaining

Thermal Managing

Atmosphere Managing

Connecting to Family/Friends

Human Consumables

Metabolic Waste Nourishing

Thermal Management System

Powering

Communications Communications

Providing

Atmosphere Management System

Food Providing

Water Providing

Atmosphere Providing

Waste Managing

Supporting Functions

Value Delivering Functions

Value Enabling Objects

Internal Objects

Fig. 13: The Value Dimension within the Functional Domain. In this OPD, value delivery decreases from left to right


functional and cross-functional concepts to be

developed, rather than relying on those that are purely

single-functional.

We demonstrate this process with an example.

Consider the strong coupling between the Thermal Managing, Atmosphere Managing, and Bacterial Infection Preventing functions observed in Figure 12. This is a result of bacterial growth being strongly

influenced by the atmospheric humidity and temperature

in a closed environment. Given this coupling, the ideal

engineering solution would be one that maps all three

functions to one element of form, thereby yielding a

multifunctional concept. This ideal concept would

manage all internal objects linked to each of the

functions (i.e. Breathable Air, Heat, and all components

of Metabolic Waste); and would have emergent

Habitable Space Attributes which correlate well with those imposed by the Radiation Protecting, Micrometeoroid Protecting, and Psychologically Sustaining functions. These requirements can be seen

in Figure 14, which depicts the corresponding subset of

the overall system OPD.

Alternatively, if the interactions between these

functions are such that it is not possible to implement

the ideal, multifunctional concept; one may resort to a

one-to-one mapping of function to form. A more

preferable scenario, however, is where many functions

at multiple levels of functional decomposition are

accomplished by one element of form. Because these

concepts cross the structural boundaries within the

functional domain, we refer to them as being cross-

functional. Conversely, multi-functional concepts are

those which address multiple functions at the same level

of decomposition, as was depicted in Figure 5.

These classes of concepts can be observed when

performing further levels of decomposition of the

atmosphere managing function. The result of this is

shown in Figure 15.

Sustaining Humans

Volume


Psychologically Sustaining (Stress Managing)

Habitable Space

Thermal Managing

Atmosphere Managing

Micrometeoroid Protecting


Heat

Liquid Waste Products

Solid Waste Products

Breathable Air



Shape

Radiation Protecting

Bacterial Infection

Preventing

Habitable Space Attributes

Meta

bo

lic W

aste

System Boundary

Notional Element of Form

Ideal Multifunctional Concept

Fig. 14: The Ideal, Multi-Functional Concept


Fig. 15: Two Layers of Decomposition of the

Atmosphere Managing Function

Here, we have chosen to further decompose the

Remove Contaminants sub-function and the corresponding Respiration Products internal object to reveal the CO2 Removing function and its interactions. There are several ways to remove CO2

from an atmosphere. Such methods include physico-

chemical processes and bioregenerative methods11

.

Instantiations of each of these are shown in the OPD

presented in Figure 16.

Here, the fact that only one element of form

addresses the function of CO2 removing indicates that

the physico-chemical concept is a one-to-one mapping

for function to form. Contrastingly, the bioregenerative

concept of Plant Growing yields objects which act to serve other value delivering functions, all of which exist

at the first level of functional decomposition. Because

multiple functions across multiple levels of the

functional hierarchy are being served by one element of

form, we can classify this concept as being cross-

functional.

III.C. Framework Metrics

In Section II, we identified the notion of

sustainability as being one of the underlying themes of

the U.S. space policy of the past two decades. It is

precisely this emergent attribute that we aim to model

and investigate using the Hab.Net framework. This

section discusses some preliminary ideas for quantifying

sustainability. Although, this effort is still a work in

progress, it is appropriate to mention the structure of the

intended output as this will drive the implementation of

the framework.

Given this, we firstly define the term: Sustainability.

The most widely accepted definition of sustainability

pO2

Atmosphere Managing

Pressure Controlling

Ventilating

Temperature & Humidity Controlling

Atmospheric Composition Monitoring

Contaminant Removing

Makeup Gas (O2/N2) Providing

Breathable Air

Airflow

Humidity

Temperature

Water


Water Vapor & Gas Mixture

CO2 CO2

Removing

Inorganic & Organic

Particulate Removing

Inorganic & Organic

Particulates

Trace Contaminant

Removing

Trace Contaminants

CO2 Removing

Adsorbing & Desorbing

Plant Growing

Solid Amine Water Desorption (SAWD)

Plants

CO2

Water

Water Vapor

CO2 Scrubbed Air

Nutrients

CO2

Water

Light

Food

Inedible Biomass

Water Vapor

Medical Caring

Dental Caring

Nourishing

Exercising

O2

Physico-Chemical

Bioregenerative

Fig. 16: OPD of Physico-Chemical and

Bioregenerative CO2 Removing Concepts


originates from the 1987 Report of the Brundtland

Commission to the United Nations, entitled Our Common Future12. Here, sustainability was defined in the concept of terrestrial development, as being

development that meets the needs of the present without compromising the ability of future generations

to meet their own needs. More recently, the Three Es model of sustainable

development has become widely adopted as a transition

from the original Brundtland definition to the domain of

engineering systems13

. As depicted in Figure 17, this

model views sustainability as being supported by three

objectives, each of which need to be satisfied in order

for the attribute of sustainability to emerge. These three

objectives are:

Environment where a system develops and operates in a manner which minimizes any adverse

effect on the surround environment, such that its

utility by future generations is not affected

Economy where a system fosters economic growth, innovation, and technological progress;

while at the same time, remaining within the

budgetary constraints of those developing it

Equity where the basic needs of all members of the population affected by the system are equally met

Fig 17: Three Es Model of Sustainable Development

13

Although these objectives were originally developed

in the context of development on Earth, they easily map

to the domain of planetary habitat system development.

One such mapping could be: minimizing the

Environmental impact of a habitat system by

minimizing the risk of human contamination and the

amount of waste produced, meeting Economic

constraints imposed by the U.S. Congress, and Equally

meeting the basic physiological, psychological, and

contingency scenario needs of the crew.

Moreover, the generality of these objectives makes

them relatively easy to implement within the Hab.Net

framework. In fact, the Environment and Equity

dimensions have already been captured, in the form of

proxy metrics embedded in the elements of the OPD in

Figure 11. Specifically, these appear as the Human

Consumables and Metabolic Waste objects for the

Environment dimension, and as the constraint values

imposed by the Human Sustaining functions for the

Equity dimension. As for the Economy dimension,

many possible proxy metrics exist; with the most

obvious being some estimate of development,

implementation, and operations costs of the system.

Since cost estimation is highly uncertain, an alternative

method of capturing this objective may be desired. One

option would be to quantify the value delivered by the

system. Within the Hab.Net framework, a simple proxy

for measuring this is to combine the Number of Crew and Mission Duration attributes. A mission that is able to maximize these parameters, while minimizing its

environmental impact and meeting basic human

sustainability requirements; would be more valuable

than a shorter mission with a smaller crew and the same

relative performance along the Environment and Equity

dimensions. This is based on the assumption that the

former scenario would lead to an increased science

return, and development of local infrastructure and

operational experience.

Regardless of the final parameters chosen, the final

output of the Hab.Net framework will be a set of

attributes capturing some, if not all, aspects of

sustainability. This will be enabled by the

implementation of numerical models capturing the

physics of the engineering concepts to be investigated.

With this, a multi-objective space of solutions can be

generated and explored. Although the outcome of this

analysis cannot be predicted a priori, the ability of the

Hab.Net framework to capture and integrate all possible

combinations of engineering solutions into a common

modeling environment, ensures that any insights

obtained will be of value.

VI. SUMMARY AND FUTURE WORK

Commencing with the fundamental goal of the

sustained human exploration of Mars, we have

employed the Object Process Methodology to develop

the Hab.Net framework for architecting and modeling

planetary habitat systems. This framework has been

shown to be capable of capturing and facilitating the

conceptualization and modeling of different classes of

solutions for various subsets of the Mars habitation

problem. Such solutions include those that are multi-

functional, cross-functional, and one-to-one mappings

of function to form. Moreover, the fact that the

framework was developed to handle different habitation

environments allows it to facilitate the analysis of

sustainability on Earth. To quantify sustainability, the


Three Es model was introduced, and methods for

implementing it within the framework were discussed.

Current efforts in developing Hab.Net involve its

validation with data from existing space habitat systems,

including the Extravehicular Mobility Unit and the

International Space Station. This is performed by

incorporating engineering models of existing systems

currently in use, to investigate the ability of the

framework in capturing the key interactions occurring

within these systems.

Finally, the Hab.Net framework has the potential to

be used in technology roadmapping applications, since

different concepts for a given function can be

simultaneously represented, and models for each of

these concepts can be progressively updated, as their

fidelity improves with their engineering development.

This capability also enables the framework to act as a

foundation for collaborative conceptual engineering

design among teams that are geographically distributed

a capability which is currently being investigated. Thus, by focusing on the interactions that occur within

the functional domain, we have developed a robust

framework capable of producing new insights into the

ubiquitous challenge of sustaining human life in

unforgiving resource-limited environments.

ACKNOWLEDGMENTS

The authors would like to thank Charlie Camarda,

Larry Toups, Ryan Whitley, Steve Hoffman, and Steve

Rader of NASA Johnson Space Center for their valuable

insights and feedback on the work presented in this

paper.

REFERENCES

1. Dori, D., 1995, Object-Process Analysis: Maintaining the Balance between System Structure

and Behavior, Journal of Logic and Computation, Volume 5, Issue 2, 1995, pp. 227-49

2. Dori, D., 2002, Object-Process Methodology A Holistic Systems Paradigm, Springer, New York, 2002

3. Review of U.S. Human Spaceflight Plans Committee, 2009, Seeking a Human Spaceflight Program Worthy of a Great Nation, Washington, DC

4. Crawley, E., 2007, System Architecture, IAP Lecture 3, MIT OpenCourseWare

5. Bush, G.H.W., 1989, Remarks on the 20th Anniversary of the Apollo 11 Moon Landing, sourced from [web], URL:

http://bushlibrary.tamu.edu/research/public_papers.p

hp?id=712&year=1989&month=all, [cited: June 1st,

2011]

6. White House, 2010, National Space Policy of the United States of America June 28, 2010. URL:

http://www.whitehouse.gov/sites/default/files/nation

al_space_policy_6-28-10.pdf

7. Portree, D.S.F., 2001, Humans to Mars Fifty Years of Mission Planning, 1950-2000, NASA SP-2001-4521

8. Drake, B.G. (ed.), 2009, Human Exploration of Mars Design Reference Architecture 5.0, NASA/SP-2009-566

9. Weigel, A., 2008 Introduction to System Architecture, MIT ESD.340, Fall 2008 Course Notes

10. NASA Headquarters, 2007, Systems Engineering Handbook, NASA/SP-2007-6105Rev1, Washington, DC

11. Eckart, P., Spaceflight Life Support and Biospherics, Space Technology Library, Microcosm Press, Torrance, CA, 1996

12. Brundtland, G.H., (ed.), 1987, Our Common Future - Report of the World Commission on Environment

and Development, Published as Annex to the United Nations General Assembly Document

A/42/427

13. Cutcher-Gershenfeld, J., Field, F., Hall, R., Kirchalm, R., Marks, D., Oye, K., Sussman, J., 2004,

Engineering Systems Monograph Sustainability as an Organizing Design Principle for Large-Scale

Engineering Systems, MIT Engineering Systems Division, URL:

http://esd.mit.edu/symposium/pdfs/monograph/sustai

nability.pdf

HAB.NET – An Integrated Framework for Analyzing the Sustainability of Planetary Habitats

Documents

Transcript of HAB.NET – An Integrated Framework for Analyzing the Sustainability of Planetary Habitats