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, sydneydo@mit.edu
Olivier de Weck
Massachusetts Institute of Technology, Cambridge, MA, United States, deweck@mit.edu
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

GLEX-2012.10.2.6x12391

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 selfsustaining?
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

Page 1 of 14

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 lifecycle 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

GLEX-2012.10.2.6x12391

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 19527. 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.

Page 2 of 14

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
Beam
Fin
Fout

Support

Fin

Function
Carry
moment
and shear
forces
React
translation
forces

Fout
Architecture
Form
Representation of Form
A.
Lever

Fin

Fout

B.
Assembly

Emergent
Function
Increase
force

None

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

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.

GLEX-2012.10.2.6x12391

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

Page 3 of 14

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.
Top Level
1. Ascent 2. Check
into Orbit Out and
Injection
Deploy

3. Transfer to
Operational
Orbit

4. Perform
Mission
Operation
s

Second Level
4.1
Provide
Power
4.4 Provide
Orbital
Maintenance

4.2 Provide
Attitude
Stabilization
4.5
Receive
Command

4.3 Provide
Thermal
Control

4.6 Acquire
Payload
Data

4.7
Transmit
Data

Flight
Segment

Sensors
Electronics

Spacecraft
Interface

Spacecraft
Bus
Structure
Power

Launch
Accommodations

Mechanisms
Electrical

Thermal

Propulsion

Command
& Data

Guidance,
Navigation
& Control

Payload
Interface

Payload
Attached
Fitting
Electrical
Supply

Communications

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-

GLEX-2012.10.2.6x12391

Function

Form

SubFunction

a).
Function
Function

Function

Form

Form

Function
Sub-

Function
c).
b).
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-toOne mapping. This version is referred to as CrossFunctional, 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.

Fig 3: Functional Flow Block Diagram of a Notional

Satellite System (Adapted from Ref. 10)

Payload
Element

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

the figure below.

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.

Page 4 of 14

Tables 1 to 4 summarize the basic constructions used in

OPD.
Name
Object
Object

Process
Process

State
State

OPD Example
Human

Name
Consumption

OPD Example
Food

Object

OPL Example

Nourishing

Process

Human

Result
Nourishing

Human
Hungry

Satiated

Nourishing

Process

Nourishing

Metabolic
Energy

Object

Human can be
Hungry or
Satiated

Affect

Nourishing

Process

OPD Example

OPL Example

Decomposition

Head
Torso

Enabler

Human consists of
Head, Torso, and
Limbs

Transportation

Object

Nourishing
Consuming

Exploring

Process

Limbs

(Subcomponents)

Humans

Object

Human

Intelligent Enabler

Humans

User

Metabolizing

Nourishing
yields Metabolic
Energy
Nourishing
affects Humans
Humans affect
Nourishing
Exploring
requires
Transportation

Exploring

Process

Nourishing consists
of Consuming and
Metabolizing

Nourishing
consumes Food

or depending on
the context,

Table 1: OPM Basic Elements

Name

OPL Example

Exploring is
handled by
Humans

Table 3: OPM Procedural Links

Human

Exhibition

Gender
Height

Human exhibits
Gender, Height,
and Weight

OPD Example
Explicit Form
Humans
Hungry

Frequency
Quantity
Human

Specialization

Infant
Adult
Nourishing

(is a Variant of)

Eating
Drinking

Instantiation

Human
John

Nourishing exhibits
Frequency and
Quantity
Infant is a type of
Human
Adult is a type of
Human

John is an instance
of Human
Mary is an instance
of Human

(is an Instance
Mary
of)
Table 2: OPM Structural Links. Terms in parentheses
can be considered as descriptions of the class of items
stemming from the given link

GLEX-2012.10.2.6x12391

Satiated

Nourishing

Affect Link
Nourishing
Humans

Suppressed
Representation
Nourishing
Humans

Eating is a type of
Nourishing
Drinking is a type
of Nourishing

Explicit Form
Exploring

Invocation

Nourishing

(Attributes)

Representing Function

Weight

Humans
Hungry

Satiated

Nourishing

OPL Example
Nourishing changes
Humans from Hungry to
Satiated
Nourishing affects
Humans
or depending on the context,

Humans affect Nourishing

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

Human Nourishing
(Noun + Verb + ing)
Exploring is handled by
Humans.
Nourishing changes
Humans from Hungry to
Satiated

Invocation Link
Exploring

Nourishing
Humans

Exploring invokes
Nourishing Humans

Table 4: Equivalent Representations in OPM

Page 5 of 14

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 4 th
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
OPD Representation
Object
Representation:
U
U
dU = U2-U1 =Q-W
OPL Representation:
Energy
Energy Conserving changes
Conserving
Object from U1 to U2.
Energy Conserving affects
Heat Reservoir and Work
Heat (Q)
Work (W)
Reservoir
Reservoir
Reservoir
Fig. 5: OPM of the First Law of Thermodynamics9
1

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
Food
Nourishing
Metabolic
Energy

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:
Exploring

Nourishing
Consuming

Food

Humans

Sustainably
Mars

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.
Humans

Exploring

Exploration
System
Sustainably

Zoomed-In
Mars

Performing
Science
Transporting

Robots

Transportation

Bolus

Digesting

Nutrients

Metabolizing

Metabolic
Energy

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

GLEX-2012.10.2.6x12391

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.

Communicating
Data/Findings

Communications

Fig. 8: Notional OPD of an entire Space Exploration

System

Page 6 of 14

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.
Developing

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.

Humans

Humans

Exploring

Sustainably

Earth

Habitable
Space

Sustaining

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

Mars

Healthy

Ill-Conditioned

Sustainably

System Boundary

a).
Sustaining
Humans

Exploring

Sustainably

b).

Mars

Habitable
Space

System Boundary

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.
Humans

Exploring

Ill-Conditioned

Sustaining

Healthy

Habitable
Space

Sustainably
Physiologically
Sustaining
Number of Crew
Mission Duration
Mars

Psychologically
Sustaining
Contingency Scenario
Sustaining

Human
Consumables
Metabolic
Output
Metabolic
Waste
Internal Objects

Volume
Shape
Internal
Arrangement
Wall Material
Configuration

System Boundary

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

Page 7 of 14

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.

GLEX-2012.10.2.6x12391

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 processto-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.

Page 8 of 14

Human Crew

Exploring

Ill-Conditioned

Sustainably
Number of Crew

Sustaining

Healthy

Habitable
Space

Mission Duration

Water
Nourishing
0.38G Gravity

Low Density
Atmosphere

Surface Solar
Radiation Density:
600-700W/m2
~95% CO2
Atmosphere
High Dust
Environment
Surface Solar Particle
Event Exposure
Surface Galactic
Cosmic Ray Exposure

Cardiovascular
Deconditioning
Preventing

Heat

Bone
Degeneration
Preventing

Bacterial
Infection
Preventing

Thermal
Managing

Respiration
Products
Liquid Waste
Products
Solid Waste
Products

Atmosphere
Managing

Habitable Space
Attributes

Radiation
Protecting

Volume

Micrometeoroid
Protecting

Shape

Psychologically Sustaining
(Stress Managing)

Entertaining

Micrometeoroids
Lighting
Noise
Managing

Sleep
Accommodating

Internal
Arrangement
Wall Material
Configuration

Food

Connecting to
Family/Friends

Vibration
Managing

Water

Contingency Scenario
Sustaining

System Boundary

Medical Caring

N2

Dental Caring

O2

Human Consumables

Sol: 24h, 39m,

35.244s

Metabolic
Energy

Metabolic Waste

Wind Speeds
up to 30m/s

Exercising

Metabolic
Output

-120C to -20C
Surface Temperature

Breathable
Air

Muscle Atrophy
Preventing

Human
Consumables

Mars

Food

Physiologically
Sustaining

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

Page 9 of 14

 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

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.

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

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

Internal Objects

Physiologically
Sustaining

Nourishing
Thermal
Managing
Atmosphere
Managing

Human
Consumables
Metabolic
Waste

Thermal Management
System
Atmosphere
Management System

Food
Providing
Water
Providing
Atmosphere
Providing
Waste
Managing
Powering

Psychologically
Sustaining

Connecting to
Family/Friends

Value Delivering
Functions

Communications

Value Enabling
Objects

Communications
Providing

Supporting
Functions

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

Page 10 of 14

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 crossfunctional. 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

Habitable
Space
Breathable
Air

Physiologically
Sustaining

Ideal Multifunctional Concept

Notional Element
of Form
Respiration
Products

Atmosphere
Managing

Liquid Waste
Products

Radiation
Protecting

Solid Waste
Products

Micrometeoroid
Protecting

Metabolic Waste

Thermal
Managing

Bacterial
Infection
Preventing

Heat

Habitable Space
Attributes
Volume

Psychologically Sustaining
(Stress Managing)

Shape

Internal
Arrangement

System Boundary

Wall Material
Configuration

Fig. 14: The Ideal, Multi-Functional Concept

GLEX-2012.10.2.6x12391

Page 11 of 14

Atmosphere
Managing
Pressure
Controlling
Makeup Gas
(O2/N2)
Providing

Breathable
Air
pO2

Physico-Chemical
CO2

Airflow

Water

Humidity

Ventilating

Solid Amine Water

Desorption (SAWD)

Adsorbing &
Desorbing

Temperature
Temperature
& Humidity
Controlling

CO2
Removing

Water Vapor

Water

CO2 Scrubbed Air

Atmospheric
Composition
Monitoring

Respiration
Products

Bioregenerative
CO2

Contaminant
Removing
CO2
Removing

Water Vapor
& Gas Mixture

Water
Light

CO2

Nourishing
Nutrients

Inorganic &
Organic
Particulate
Removing

Inorganic &
Organic
Particulates

Trace
Contaminant
Removing

Trace
Contaminants

Plant
Growing

Plants
Food

Fig. 15: Two Layers of Decomposition

Atmosphere Managing Function

O2

of

the

Water Vapor

Exercising
Medical
Caring
Dental
Caring

Inedible Biomass

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 CO 2
from an atmosphere. Such methods include physicochemical 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

GLEX-2012.10.2.6x12391

Fig. 16: OPD of Physico-Chemical and

Bioregenerative CO2 Removing Concepts
form, we can classify this concept as being crossfunctional.
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

Page 12 of 14

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 Development13

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

GLEX-2012.10.2.6x12391

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 multifunctional, 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

Page 13 of 14

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.

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 SP2001-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

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:

GLEX-2012.10.2.6x12391

Page 14 of 14