Systems Engineering Interfaces: A Model Based

Approach
Elyse Fosse, Christopher L. Delp
Jet Propulsion Laboratory, California Institute of Technology
4800 Oak Grove Drive
Pasadena, CA 91109
[email protected]

Abstract—The engineering of interfaces is a critical function of as existing industry standards for specific kinds of interfaces.
the discipline of Systems Engineering. Included in interface SysML[1] provides a precise model based representation for
engineering are instances of interaction. Interfaces provide the specifying the interfaces of parts and integration between
specifications of the relevant properties of a system or com- parts through those interfaces. The language also allows for
ponent that can be connected to other systems or components domain-specific semantics to be applied as an extension to the
while instances of interaction are identified in order to specify
the actual integration to other systems or components. Current basic modeling capability of SysML.
Systems Engineering practices rely on a variety of documents
and diagrams to describe interface specifications and instances The interface engineering work performed by the Opera-
of interaction. The SysML[1] specification provides a precise tions Revitalization (Ops Rev) Task[2], sponsored by the
model based representation for interfaces and interface instance Multimission Ground Systems and Service Office of NASA,
integration. This paper will describe interface engineering utilized a model based approach to represent the interfaces
as implemented by the Operations Revitalization Task using and interactions required for a Mission Operations System
SysML, starting with a generic case and culminating with a (MOS). Mission Operations Systems Engineering concerns
focus on a Flight System to Ground Interaction. The reusability with interfaces begin with the Flight-Ground Interface. The
of the interface engineering approach presented as well as its
extensibility to more complex interfaces and interactions will be interface focuses on the interaction between the Flight Sys-
shown. Model-derived tables will support the case studies shown tem and the Ground System. Within the Ground System the
and are examples of model-based documentation products. MOS must interface with ground stations, networks, and a
host of organizations. Within the MOS, Mission Services,
Operations Roles, and Software must interface with each
other.
TABLE OF C ONTENTS
This paper will describe the key Viewpoints used to define
1 I NTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 the patterns for modeling MOS interfaces. These Viewpoints
2 I NTERFACE PATTERNS AND P OINTS OF V IEW . . 1 will then be complemented by examples from the MOS 2.0
3 M ODELING I NTERFACES WITH S YS ML . . . . . . . . . 2 Architecture [2]. Beginning with the Flight-Ground Interface,
4 O PERATIONS R EVITALIZATION I NTERFACE examples from these models will be used to illustrate specifi-
E NGINEERING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 cation of Interfaces, Interactions between Interfaces, and the
limitations and operational contexts of those interactions.
5 S UMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
R EFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. I NTERFACE PATTERNS AND P OINTS OF
B IOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 V IEW
Ops Revitalization is building a model of a Mission Opera-
tions System (MOS). The interfaces for Mission Operations
1. I NTRODUCTION Systems cover a broad range of systems, software, hardware,
The topic of Interfaces is at the heart of the multi-disciplinary and human interactions. In order to model this broad range
nature of Systems Engineering. This area covers what is of interfaces and interactions, it is useful to describe the
necessary in order to connect the individual pieces of the system from different points of view [3]. Ops Revitalization
System together into a working System. To accomplish the has developed the Mission Service Architecture Framework
connection the relevant properties and behavior of each part (MSAF) [4]. The MSAF defines the atomic interface en-
of the System must be specified. It is also necessary to specify gineering components (Table 1) as well as a set of patterns
the particular connections between each part and the nature for modeling this broad set of integrated systems and other
of those connections in terms of limitations, protocols, and patterns in the MOS. These basic Views can be used to
various operational conditions or scenarios. describe the different interfaces related to the MOS.

The describing and specifying of interfaces in a general way Table 2 identifies the Viewpoints that address important con-
is a challenging problem. Current Systems Engineering cerns with respect to the topic of interfaces. Part Interface
practices rely on a variety of documents and diagrams to Viewpoints of the system describe what interfaces the part
describe interface specifications for different Systems as well presents. The Interface Layered Viewpoints describe the
interfaces in a recursive manner and are a special case of
978-1-4577-0557-1/12/$26.00 2012
c IEEE. the Part Interface Viewpoint. In systems where software is
2012
c California Institute of Technology. Government sponsorship ac- part of the system, it is common to have logical layering
knowledged of software interfaces on top of hardware. Interface Speci-
1 IEEEAC Paper #2562, Version 2, Updated 5/1/2013. fication Viewpoints describe the individual specifications of
1
 Table 1. Interface Engineering Definitions

Term Definition
Interface The system boundary that is presented by a system for interaction with other systems.
Interface Specification Describes the nature of the boundary presented by a system or component in terms of properties
and functionality.
Interaction An instance of an operational entity (system, organization, or services) interface. The interaction
can connect to other operational entities according to its Interaction Specification.
Interaction Specification Describes how an operational entity (system, organization, or service) can effect another
operational entity when a connection exists.

Table 2. Viewpoints

Viewpoint Purpose Concern

Part Interface Identify Interfaces for a given Part. What are the interfaces for a given Part?
Layered Part Interface Specify layering of interfaces such as What is the structure of the different in-
application, protocol and data layers. formation aspects on the interface?
Interface Specification Specify a given Interface in terms of What is the detailed set of functions and
functions and properties of that interface. properties of a given interface?
Interface Connection Specify the integration of 2 or more What Parts are connected to each other?
Parts through their respective Interfaces
in terms of the specific conditions and
function occurrences that define the inte-
gration according to the Interface Speci-
fication.
Interface Object Flow Specify how objects (materials, informa- What are the flows between parts of the
tion) flow across a given integration of system?
interfaces for a set of Parts.
Interface Function Occurrence Specification for behavioral interaction How do functions occur between Parts of
across interfaces. the System?
Performance and Limitations on In- Specify constraints on interfaces such What are the expectations and limits of
terfaces as policies, agreements and performance the given integration?
constraints.

each Interface. The Part Interface, Layered Part Interface, 3. M ODELING I NTERFACES WITH S YS ML
and Interface Specification Viewpoints describe the part of The SysML specification provides a precise model-based
the system in terms of interfaces without explaining how they representation for interfaces and interactions. Interface spec-
will be integrated. Providing these views of the system allows
the Systems Engineer to evaluate and analyze parts based on ifications are described using SysML flow ports, operations,
and signals which correlate to the system or component
their interfaces separately from how they will be integrated. interface properties, as shown in Table 3.
The remaining set of Viewpoints in Table 2 refer to how Inter-
faces may be instantiated into Interactions in order to describe Table 3. Interface Specifications To SysML
context-specific integrations and behavior. Interface Connec-
tion Viewpoints identify what parts will be integrated with
each other and how they will behave when they are integrated. Interface Property SysML Property
Interface Object Flow Viewpoints describe how objects are
allowed to flow across the interfaces of the integrated parts in Functions Operations
the context with which the parts are integrated in. The objects Signals Signals
could be physical objects, like shipping a spacecraft to Cape Information I/O Flow Ports
Canaveral, or Radio Waves in deep space. The objects could
also be logical like data moving through cables. Interface Materials I/O Flow Ports
Function Occurrence Viewpoints show behavior interaction
between parts. From this vantage point the system can be
described in terms of the occurrence of functions and events A simple system will be used to describe the Ops Rev Tasks’s
among the interfaces of components. Interface Constraints SysML interface engineering implementation. The following
Viewpoints describe how the interface is constrained. This figures and tables are views into the SysML model describing
could be in the form of expected performance or operational the system shown in Figure 1, which is comprised of two
limitations. Together, these Viewpoints describe integration systems, A and B. The previously identified viewpoints will
of parts through their interfaces. be elaborated presently using System A’s interface and its
interaction with System B
2
 Note that Ops Rev utilizes the extensibility of SysML to cre-
ate a Domain Specific Language (DSL) by extending SysML
Block to “Interface Specification” and SysML operation to
“Interface Operation”, as seen as stereotypes (enclosed by
guillemets) for their respective elements in Figure 2. Ex-
tending SysML and creating the appropriate customization
classes allows for any properties or relationships that are
true for any interface specification or interface operation to
be created once and be reused by applying the appropriate
stereotype. For example, if all interface specifications have
some property that identifies the time for which the specifica-
tion is valid, then this property can be a part of the block that
is associated with the customization class for the “Interface
Specification” stereotype. When the stereotype is applied
to another element, the element will already have the time
Figure 1. System Identification property associated with it.
Extending SysML in this manner also allows Systems En-
gineers implementing the interface pattern to now work and
Interface Specification Viewpoint implement SysML elements that make sense for their domain,
Every system or component that is intended to be composed such as “Interface Specification” or “Interface Operation”.
into a greater system has some functionality that the com-
prising system needs. The functionality is a property of the Table 4. System A Operation I/O
system or component, independent from whom the system
or component is intended to interact with. The Interface
Specification Viewpoint focuses on identifying the function- Operation Inputs Outputs
ality properties as operations owned by a SysML block. The Do Something Raw Input Manipulated Output
functionality identified is the generic set of functionality that
is available to any system or component when an interaction
exists.
Table 5 identifies the type of information parameters used
in System A interface operations. The parameter types are
themselves SysML Blocks and can have properties specific
to them such that when applied as the type of a parameter
that parameter has those same properties. The overall pattern
that is emerging is that SysML provides the ability to spec-
ify properties in a recursive fashion (an interface has some
information property which in turn has some other defining
property, and so on). A Systems Engineer is able to identify
and define properties at any level of fidelity that is necessary.
For example, currently the “Information Specification” block
that types the functional inputs and outputs has no properties
explicitly identified, which is assumed to be the correct level
of fidelity. If at a later point in time a Systems Engineer
identifies some property that is true for all “Information
Specifications” the property can be added to the element in a
single place in the model and all other elements that are typed
Figure 2. Functionality Specification by the “Information Specification” will receive that update.

Table 5. Operation I/O Information Types

Figure 2 illustrates that an interface element named “System
A Interface Functionality Specification” is used to describe Function Input/Output Type
the functionality of System A. The functions that are available
for use by other systems or components during an interaction Raw Input Information Specification
are shown on the interface element as operations. The param- Manipulated Output Information Specification
eters of the operation are suppressed in Figure 2 for the sake
of readability and are instead shown in Table 4. Notifications
are also specified on the interface element and are accessible
during an interaction with System A. The model-derived figures and tables described in this section
comprise a interface specification view for System A. This
The “System A Interface Functionality Specification” is real- view could be incorporated into supporting interface docu-
ized by the “System A Interface Specification” which means ments or presentations by a Systems Engineer to provide an
accurate and explicit definition of the interface functionality
that the functionality identified is available for use when a of System A.
SysML port is typed with the “System A Interface Specifica-
tion” block. Describing the functionality in this way allows Layered Interface Viewpoint
for the reusability of the interface specification. Any SysML
port that is typed by the “System A Interface Specification” SysML flow ports on an interface specification prescribe
will automatically have the functionality specified. some sort of logical layering which the Systems Engineer
3
 Figure 3. Information Interface Layer

Figure 4. System A Interface

wants to abide by. Layering interfaces contributes to the sep-
aration of concerns methodology driven out by Viewpoints.
In particular it is possible to create ports on an interface spec- redefinition involves redefining port and operation properties
ification, thus creating nested ports. The ports nested upon to meet the specific needs of the interaction. The assertion is
the interface specification concern themselves with properties that all instances contain a subset of the properties defined in
that provide greater detail about the specification. the interface specification. Mathematically, let S be the set
of interface properties specified by an interface specification
Figure 3 illustrates how the “System A Interface Specifi- 0
cation” further derives properties about the types of infor- and let S be the set of interaction properties specified by an
mation System A expects or provides in order to fulfill its interaction specification. Based on SysML redefinition rules,
0
functionality. It follows then that the information identified it follows then that, S ⊆ S.
as ports are related to the functional parameters identified
(refer back to Table 5). This relation at the simplest level Figure 5 shows that the System A interface specification is
could be an equivalent, but could also be a subset relationship specialized to be an interaction specification for the exchange
where the information inputs and outputs for the functions between System A and System B. For completeness all prop-
could be a subset of the information actually expected or erties of the interface need to be inherited as well and as a
provided on the port. The implication then is that there is result the functionality of System A’s interface is specialized
some system functionality that is not used by another system to be specific for the exchange. “Functionality for System
or component, but is needed for that system to meet its B” redefines the interface operation found on “System A In-
objectives. terface Functionality Specification”. The redefinition means
that the the properties of the “Functionality For System B”
Interface Viewpoint interface operation, such as its parameters, are either of the
same type as the redefined interface operation “Do Some-
The properties designated by an interface specification are thing” or have a type that further refines the type that is being
applied to a system’s interface in SysML by assigning the redefined. The information implemented in the interaction
type of the interface port to be that of the interface speci- specification is a specialization of the block used to type
fication element. This means that the system specification
has the details of the interface, regardless of with whom the information in the interface specification. Similarly, the
information property “schema” refines the generic property
system is expected to interact. Decoupling the system’s inter- “information property”. Completing the redefinition involves
action(s) and interface in this way allows a systems engineer
to describe the concerns of the interface without convolving creating a new port on the System A block and having that
port redefine the “System A Interface” port. Additionally,
those concerns with that of interactions. The implication is the new port is typed with the newly instanced interaction
that a system’s interface can be identified and specified once
with as many instantiations as needed to achieve the expected specification. System A now has the port needed to fulfill its
need to interact with System B.
interactions.
Figure 4 shows that the System A port stereotyped “Interface” Creating the interface and interaction with this model based
approach allows a Systems Engineer the ability to implement
is typed by the “System A Interface Specification” that was automation (exploiting the patterns and stereotypes used) in
previously defined. The assignment means that “System A order to completely and rapidly redefine an interface for each
Interface” has all of the functionality and information proper- necessary interaction. The automation employs the DSL to
ties as defined by the “System A Interface Specification.” The
interface for System A has been fully defined with no regard capture and replicate (e.g., specialize) inheritance, composi-
tion, and dependency relationships and the affiliated model
to System A’s interactions. As interactions with System A elements, thus ensuring that all interactions are implemented
are identified, the “System A Interface” is instantiated and
refined to meet the explicit needs of the specific interaction. in a similar manner and thereby removing any ambiguity
from their specifications or descriptions.
Interface Connection Viewpoint
Figure 6 and Table 6 together describe the functionality
The method of instancing an interface involves redefining the occurrences in System A’s interaction with System B. The
interface specification into an interaction specification. The figure shows explicitly that there is a connector between the
4
 information flows completes the interaction definition. It can
be seen then that an interaction is comprised of two or more
interface instances with conveyed information connections.

Figure 5. Complete Interface Instance

Table 6. Interaction Functionality Description

Interaction Spec Inputs Outputs

Sys A - Sys B Interaction Spec
Functionality for System B I.P. B I.P. A
Sys B - Sys A Interaction Spec Figure 7. System Information Interaction
System B Interface Operation I.P. A I.P. B

two interface instances. The table implements a nested table

technique such that the interface is identified and, indented Table 7. Interaction Information Description
within the next row, are the functional properties of the
interface as well as the operation’s corresponding inputs and
outputs. For conciseness, “I.P.” means “Information Product” Interaction Spec Inputs Outputs
and “Spec” means “Specification”. Sys A - Sys B Interaction Spec I.P. B I.P. A
Sys B - Sys A Interaction Spec I.P. A I.P. B

The instantiation process can be reused as many times as

needed to specify all of System A’s interactions. Thus this
method allows the Systems Engineer to specify system or
component interface properties once and redefine specific
aspects as needed on an interaction-by-interaction basis. The
redefinition part of the approach can be automated such that
Figure 6. System Interaction the Systems Engineer is able to focus on the aspects of
interaction that are different and allow the automation to
While System B’s interface and interaction specifications take care of the repetitive mechanics of interface instancing.
weren’t derived explicitly, the assumption has been made that The views shown can be queried from the model such that
System B has a single interface operation and its inputs and the Systems Engineer can provide stakeholders with accurate
outputs are the exact conjugates of System A’s inputs and information about interfaces and interactions in a template-
outputs. able manner.

Interface Object Flow Performance Limitations on Interfaces Viewpoint

Figure 7 and Table 7 together provide an information ex- Almost every interaction a Systems Engineer identifies has
change view of System A’s interaction with System B. Each some sort of timing (e.g., duration or frequency) or quality
interaction is expanded to show their respective nested flow (e.g., lossless) constraint that must be met in order for the
ports, which identify the expected inputs and outputs that interaction to be successful. To accommodate this, the
occur during an interaction between the two systems. All model based approach is extended to include SysML con-
information described in Tables 6 and 7 have “Information straint blocks as agreements among two or more systems or
Product” as their type, which is also shown in Figure 7 as components. These agreements can contain all constraining
the information that is conveyed during the interaction. Con- parameters and are placed between the connectors of the
necting the interactions and typing the connections with the interaction, as seen in Figure 8.
5
 There is added complexity compared to the previous section
due to the inclusion of the Ground Domain. The Ground
Domain acts as a delegate for the MMOS interaction with
the Flight System, and as such nests the MMOS Interaction
with the Flight System onto its own interaction port with the
Flight System. That is, the Ground Domains interaction with
the Flight System specification includes a property that is the
MMOSs interaction with the Flight System specification. For
Figure 8. System Interaction with Agreement this reason, Table 8 excludes the Ground Domains interaction
specification in order to eliminate redundancy.

The properties that pertain to the agreement could include

but are not limited to the quality of the Information Products
exchanged between System A and B as well as the timeliness
with which System A expects to receive Information Products
from System B.

4. O PERATIONS R EVITALIZATION
I NTERFACE E NGINEERING
The interface and interaction modeling approach was ex-
tended by the Ops Rev Task in order to represent interfaces
and interactions required throughout mission operations as it
pertains to a Multi Mission Operations System(MMOS). The
necessary extension was for the pattern to be implemented in
a deeper nested port manner (two levels of nested interfaces
rather than one) in order to separate out control concerns
that the Ops Rev Task is addressing. A Mission Operations
Systems Engineer (MOSE) is particularly interested in how
the MMOS interacts with other systems such as a Project
or Flight System, as well as how the MMOS is organized
internally based on interaction. The following section will
show the Ops Rev Tasks implementation of the approach as
it applies to a flight system and ground interaction, which is a
high valued interaction for an MOSE to describe. Another
implementation will be shown that focuses on how two Figure 9. MMOS Functionality Interaction
Mission Services, components of the MMOS, interact with
each other in order to achieve the MMOSs over-arching goal.
The union of these implementations will show the generic Table 8. MMOS Interaction Functionality Description
approachs extensibility and reusability.
Interaction Specification Inputs Outputs
The description that follows is comprised of views, each of
which conforms to a previously described viewpoint. The ab- MMOS - FS Interaction Spec
sence of a viewpoint can be understood as future or ongoing Update Commands Cmd Telem
work for the Ops Rev Task.
Update Configuration Cfg Loads Cfg Telem
MMOS - Flight System Interface Connection View FS - MMOS Interaction Spec
The interface specification for the MMOS is assumed to N/A
be fully specified and therefore ready for instancing. The
assumptions made on the interface are that the functionality
available is delegated to the MMOS from its component MMOS - Flight System Object Flow View
Mission Services (i.e., the MMOS does not carry out the
functionality but delegates the appropriate work to the appro- Figure 9 and Table 9 provide an information exchange view
priate Mission Service), and that the functionality parameters of the MMOS’s interaction with a Flight System. There is
as well as information required or provided are types of added complexity compared to the previous section due to the
timelines[4]. The specification of the Flight System interface addition of a “MMOS-Flight System Controller Interaction”
is outside of the purview of the Ops Rev Task and as a result port. The Ops Rev Task sought to not only separate interface
the functionality is undefined. Figure 8 and Table 7 together and interaction functional and informational concerns, but
provide a functional view of the MMOSs interaction with also to further decompose information concerns as to the type
a Flight System. The functionality shown to be that of the of control trying to be achieved. A controller/controlled inter-
MMOS is delegated to the MMOS by one of its component action is one type of control that the task has identified. Note
Mission Services, the Mission Engineering Service. For that the conveyed information is an information type specific
conciseness, Cfg means Configuration, Telem means Teleme- to Mission Operations such that the notion of Timeline[5]is
try and portions of the MMOSs interaction functionality are extended to include mission operational concepts as conveyed
hidden. information between the MMOS and other systems.
6
 Figure 10. MMOS Control Information Interaction

Table 9. MMOS - FS Interaction Information Description Verification

A model-driven interface engineering approach provides the
Interaction Spec Inputs Outputs Systems Engineer with some useful verification functionality.
MMOS - FS Controller Int Spec FS Telem FS Cmds When dealing with complex systems it is arduous for a
human to confidently verify that all information exchanges
FS - MMOS Controlled Int Spec FS Cmds FS Telem are appropriate and correct. Using blocks to type the flow
ports on the interfaces, as well as to type the parameters of
operations, allows the Systems Engineer to query the model
to check that all interactions have allowable types connected.
Rules can be created that identify the allowable port type
MMOS Internal Interaction Object Flow View connections. The model can then be queried and a list of
The Ops Rev Task also implemented the same interface invalid connections can be produced. Further, implementing
engineering approach to specify interfaces and implement a generalization hierarchy to the blocks used as information
interactions for MMOS components, known as Mission Ser- types, as seen in Figure 5, affords the Systems Engineer the
vices. Mission Services exert a different type of control on ability to use generic types early in the interface engineering
each other, called director/directed control. Figure 4 is a view task. These types can be later refined to include more specific
of how the MMOS’s Mission Engineering Service(MES) information types as that information becomes available, or
interacts with the MMOS’s Flight Systems Engineering Ser- as it is needed to describe the interfaces and interactions at a
vice(FSES). The information identified in the view describes prescribed level of fidelity.
information pertaining to state, which is a subset of the
information that may be conveyed between these two Mis- Interface Function Occurrence Extension
sion Services in pursuit of directional control. Information The interaction across interfaces can be specified through
pertaining to commands and activities would also need to be SysML Sequence Diagrams. A current limitation of SysML
included in this view for it to be considered complete. For is that it is difficult to associate operations on a block with
conciseness, the supporting tables are suppressed here but can functions calls on a Sequence Diagram. This limitation disal-
be queried and rendered out of the model. lows that ability to have the functionality of a system traced
across interactions. It is possible, with some adaptations and
This section has shown that the generic interface engineering extensions to SysML to extend the model based approach
approach was competent enough to be implemented in the to include function occurrences among two or more com-
context of mission operations for the Ops Rev Task. Not only ponents. These occurrence would be shown on a Sequence
was the approach sufficient, it was shown to be extensible and Diagram along with their associated timeliness and quality
reusable. The approach allows the Ops Rev Task to reduce the constraints.
amount of effort focused on creating documents , and instead
focus on specifying the interfaces and interactions in a model-
based way so that the corresponding views can be derived
in a formulaic manner. Further automation endeavors have
allowed the Ops Rev Task to capitalize on this approach by
reducing the effort needed for the instantiation of interfaces.
7
 Figure 11. MES to FSES Interaction

5. S UMMARY B IOGRAPHY [
The Ops Rev Task implemented a model-based engineering
approach to provide a more rigorous and formulaic descrip- Christopher L. Delp is the Systems Ar-
tion of interfaces and interactions. The task uses a separation- chitect for the Ops Revitalization task in
of-concerns methodology to both provide descriptions of MGSS and a Lead Systems Engineer for
the interfaces and interactions, as well as to decouple their MBSE on the Europa Mission. He is a
specifications. The implementation was shown to be reusable founder of the Modeling Early Adopters
in both a generic manner, as well as in its applicability to grass roots Model Based Engineering
engineering the Multi Mission Operations Sys- tem(MMOS) working group. Chris continues to lead
interfaces for the Ops Rev Task. Its extensibility was also the INCOSE Space Systems Working
shown through the MMOS cases presented. The efficiency Group MBSE Challenge Team for the
of the approach in terms of view generation and model INternational Council On Systems Engi-
verification has afforded the Ops Rev Task more time to focus neering. Previously he served as Flight Software Test Engi-
on the engineering of the interfaces and interactions and less neer for MSL and Software Test Engineer for the Tracking,
on document generation and narrative descriptions. Telemetry, and Command End-to-End Data Services. He
also leads the INCOSE Space Systems Working Group’s entry
in the Model Based Systems Engineering Grand Challenge.
ACKNOWLEDGMENTS Additionally, he has performed research on software verifica-
tion and tools for Service-Oriented Architecture in support of
The work described in this paper was performed at the Jet the Deep-space Information Services Architecture. Prior to
Propulsion Laboratory, California Institute of Technology, coming to JPL, he worked as a software engineer performing
under a contract with the National Aeronautics and Space DO-178b Level FAA flight qualified software development
Administration. and testing on Joint Tactical Radio System (JTRS) and the T-
55 Full Authority Digital Engine Controller (FADEC). Chris
earned a Master of Science in Systems Engineering from the
R EFERENCES University of Arizona where he studied Model Based Systems
Engineering, Simulation and Software Engineering. Previous
[1] Object Management Group, “OMG Systems Modeling to graduate studies, Chris performed his duties as a systems
Language (OMG SysMLT M ), version 1.3,” OMG, Tech. engineer on Missile Systems Verification and Validation.
Rep. OMG document number formal/12-06-02, June
2012. Elyse Fosse is a Software Systems En-
[2] D. Bindschadler, C. L. Delp, and M. McCullar, “Princi- gineer for the Ops Revitalization task
ples to Products: Toward Realizing MOS 2.0,” in Pro- in MGSS. She developed ground system
ceedings of the 12th International Conference on Space cost models for deep space and Earth
Operations, Stockholm, Sweden, June 2012. missions. She is also a member of the
Multimission Ground Data System Engi-
[3] ISO, “ISO/IEC 42010 Systems and software engineering- neering group at the Jet Propulsion Lab-
Architecture description,” Tech. Rep., 2011. oratory. Her interests include software
[4] e. a. Chris L. Delp, “Mission Service Architecture Frame- and systems architecture, applications
work: Model Based Mission Operations Systems Engi- of model-based system engineering, and
neering.” cost model implementation and analysis. Elyse is also a part
of the INCOSE Space Systems Working Group’s entry into the
[5] S. H. Chung and D. Bindschadler, “Timeline-based Mis- Model Based Systems Engineering Grand Challenge. Elyse
sion Operations Architecture: An Overview,” in Pro- earned her M.A. in Applied Mathematics from Claremont
ceedings of the 12th International Conference on Space Graduate University and her B.S. in Mathematics from the
Operations, Stockholm, Sweden, June 2012. University of Massachusetts Amherst.