-
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
-
GLEX-2012.10.2.6x12391 Page 2 of 14 Page 2 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 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.
-
GLEX-2012.10.2.6x12391 Page 3 of 14 Page 3 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 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
-
GLEX-2012.10.2.6x12391 Page 4 of 14 Page 4 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.
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).
-
GLEX-2012.10.2.6x12391 Page 5 of 14 Page 5 of 14
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
Name OPD Example OPL Example
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
Name OPD Example OPL Example
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
-
GLEX-2012.10.2.6x12391 Page 6 of 14 Page 6 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 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
-
GLEX-2012.10.2.6x12391 Page 7 of 14 Page 7 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.
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
Ill-Conditioned Healthy
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
-
GLEX-2012.10.2.6x12391 Page 8 of 14 Page 8 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.
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.
-
GLEX-2012.10.2.6x12391 Page 9 of 14 Page 9 of 14
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
Ill-Conditioned Healthy
Metabolic Energy
Water
Food
Liquid Waste Products
Solid Waste Products
Breathable Air
Internal Arrangement
Wall Material Configuration
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
-
GLEX-2012.10.2.6x12391 Page 10 of 14 Page 10 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
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
Physiologically Sustaining
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
-
GLEX-2012.10.2.6x12391 Page 11 of 14 Page 11 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 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
Physiologically Sustaining
Psychologically Sustaining (Stress Managing)
Habitable Space
Thermal Managing
Atmosphere Managing
Micrometeoroid Protecting
Respiration Products
Heat
Liquid Waste Products
Solid Waste Products
Breathable Air
Internal Arrangement
Wall Material Configuration
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
-
GLEX-2012.10.2.6x12391 Page 12 of 14 Page 12 of 14
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
Respiration Products
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
-
GLEX-2012.10.2.6x12391 Page 13 of 14 Page 13 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 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
-
GLEX-2012.10.2.6x12391 Page 14 of 14 Page 14 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.
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