Model Based Document and Report Generation for

Systems Engineering
Christopher Delp, Doris Lam, Elyse Fosse, Cin-Young Lee
Jet Propulsion Laboratory, California Institute of Technology
4800 Oak Grove Drive
Pasadena, CA 91109
(818)319-3251
[email protected]

Abstract—As Model Based Systems Engineering (MBSE) prac- nication between Systems Engineers and other engineering
tices gain adoption, various approaches have been developed disciplines. Since other engineering disciplines are not versed
in order to simplify and automate the process of generating in Systems Engineering models, Systems Engineers still need
documents from models. Essentially, all of these techniques can to produce documents and reports as the primary way to com-
be unified around the concept of producing different views of municate with stakeholders and other engineering disciplines.
the model according to the needs of the intended audience. In
this paper, we will describe a technique developed at JPL of One of the keys to MBSE adoption at JPL has been the
applying SysML Viewpoints and Views to generate documents practice of generating documents from systems engineering
and reports. An architecture of model-based view and document models. This allows systems engineers to easily update and
generation will be presented, and the necessary extensions to ensure consistency among a set of documents as updates are
SysML with associated rationale will be explained. A survey of made to the model.
examples will highlight a variety of views that can be generated,
and will provide some insight into how collaboration and inte- This document generation technique originated from other
gration is enabled. We will also describe the basic architecture JPL efforts including Ops Revitalization [2]. Since these
for the enterprise applications that support this approach. initial innovations, MBSE at JPL has flourished in a number
of projects. In particular, the Ops Revitalization Task [3], the
Europa Study [4] and the Integrated Model-Centric Engineer-
ing effort [5] have been crucial drivers for the development
TABLE OF C ONTENTS of models, architecture, technology, and applications that
1 MBSE AND THE S TATE OF THE P RACTICE OF provide this capability.
D OCUMENT G ENERATION . . . . . . . . . . . . . . . . . . . . . . . 1
2 T HE P RINCIPLE OF C OMMUNICATION . . . . . . . . . . 2 As MBSE practice has begun to move into the mainstream,
several homegrown approaches have been developed around
3 A RCHITECTURE FOR E XTENDING S YS ML the use of the DocBook standard for publishing [6]. In gen-
V IEWPOINT AND V IEW . . . . . . . . . . . . . . . . . . . . . . . . . . 2 eral, these approaches involve the use of a SysML profile for
4 M ODEL BASED E NGINEERING E NVIRONMENT . 6 DocBook to produce a model of a document. The document
5 R EALIZING S OFTWARE AND A PPLICATIONS . . . 8 model is then linked to other SysML models and diagrams to
6 C ONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 produce the document.
ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
These approaches are effective at generating the basic struc-
R EFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 ture of the document with injected model information. How-
B IOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 ever, they lack the semantics and patterns to describe how the
model is projected into a document structure. Each existing
implementation has attempted different ways to support this,
1. MBSE AND THE S TATE OF THE P RACTICE but none of these applications provides a comprehensive set
OF D OCUMENT G ENERATION of capability. They also lack a more fundamental concept
and foundational support for describing how to extract infor-
Several projects at JPL have now embraced Model Based mation from the model in such a way so that analysis and
Systems Engineering (MBSE). As a result, JPL has de- editing of that information can be integrated with external
veloped an institutional approach to MBSE. This approach applications.
is based on Systems Modeling Language (SysML) [1] and
formal ontology expressed in the terminology and lexicon of MGSS Ops Revitalization [7] and the Europa Mission Study
each engineering domain. MBSE promises to alleviate the [8] have deployed full-scale project models in SysML. Sev-
difficulty systems engineers face in communicating across eral other efforts across industry are engaged in MBSE with a
engineering disciplines primarily in terms of completeness similar scale of modeling effort [9]. Modeling at an enterprise
and consistency. By describing these systems in a formal scale requires enterprise computing environment capable of
way using domain specific terms, models can be checked supporting collaboration among a variety of users working
for completeness and consistency. These models can also be with large models and data sets. Web technologies have been
analyzed to answer questions about the system such as input used extensively in these efforts to realize such a scalable
to simulations or other engineering analysis. enterprise computing environment.
At the core of realizing these benefits is effective commu- This paper describes the fundamental concept of Viewpoint
and View as the foundation for providing a comprehensive
978-1-4673-1813-6/13/$31.00 c 2013 IEEE. capability for generating Views of models. The architecture
1 IEEEAC Paper #2233, Version 2, Updated 5/1/2013. for Viewpoint and View and its extensions in SysML are

1
described using examples from the projects at JPL sponsoring If VP is defined to be the homomorphism that represents a
this work. Models of this size require enterprise scalability. viewpoint then:
Finally we describe the current implementation of a Model
Based Engineering Environment and the document genera- VP : D(VP) → R(VP)
tion support and applications for generating documents and
reports for Systems Engineering. where D(VP) is the set of integrated model elements that
are within scope for the Viewpoint (e.g., the domain of the
Viewpoint) and R(VP) is set of view elements that is the
2. T HE P RINCIPLE OF C OMMUNICATION image of D(VP). (e.g., the range of the Viewpoint). It follows
then that:
Systems Engineers and Architects produce products that must
communicate with a diverse group of customers including View : {VP(ME) : ME in D(VP)}
different engineering disciplines, managers, organizational
and business roles. This diverse group each has a different
point of view with respect to how they understand the system. where ME corresponds to a model element. In other words, a
This motivates a principle of communication that will ensure Viewpoint is the homomorphism that transforms a subset of
that the system is described from each the point of view of model elements into View elements.
each of these stakeholders. 2-way communication asserts
that person communicating report what they heard the other
person request as well as there response. The ISO/IEC 42010
[10] definition of Viewpoint and View is consistent with
this principle. Viewpoint and View can be used to provide
a platform that can describe different aspects of a model
according to the rules for describing those different aspects
of the model. Viewpoint describes what the stakeholder point
of view and View represents the depiction of the model of the
system according to the Viewpoint.

Figure 2. Mathematical representation of Viewpoint and

View

Representing Viewpoint and View mathematically provides

a theoretical foundation for the semantics - the implication
being that the mathematical theory provides constraints for
the implementation.

3. A RCHITECTURE FOR E XTENDING S YS ML

V IEWPOINT AND V IEW
Using the Viewpoint and View definitions in SysML it is pos-
sible to define a model of Views that will provide a linearized
description of models referenced by the Views. SysML
Figure 1. Metamodel of Basic Viewpoint and View Viewpoint and View have roots in ISO/IEC 42010 so most
of the elements in SysML come directly from the ISO/IEC
Generating documents and reports using Viewpoints and 42010 meta-model. The current SysML implementation does
Views has been demonstrated at JPL as an effective way not treat all of these elements as first-class model elements.
Table 1 identifies the concepts in SysML related to Viewpoint
to communicate across disciplines using models to ensure and how they are expanded to facilitate View generation.
completeness and consistency of the system architecture and
design. The current technique employed at JPL uses SysML Models, Views and Viewpoints
Viewpoint and View to specify a model for communicating
different aspects of a system model. The SysML defini- Most MBSE practitioners at JPL link their Views together
tions of Viewpoint and View are consistent with ISO/IEC to linearize a particular description of a model or models.
42010. Figure 1 illustrates the basic semantics for relating Modeling the relationships between Views in this way allows
elements of the model to the model View. The conformance for a clickable navigation through the model as well as
relationship expresses the requirement that the View of the provides a structure that can be used to generate documents
model be consistent with the methods and rules expressed and other formatted output based on the content of the model.
by the Viewpoint. It is often necessary to communicate a
certain set of Views in a particular order. These collections Figure 3 illustrates how Views can be linked together with
can be represented as familiar document structures such as dependencies to model the precedence order for reading the
sections and subsections in a document as well as slides, Views. Views import models of any sort or type. These
tables, worksheets or other forms typical in office reporting models may be SysML models, ontologies, structured data
software. from a database or website, and notional illustrations, just
to name a few. In principle, the Viewpoint is even capable
The semantics of Viewpoint and View are represented mathe- of describing Views that exist outside of software, such as
matically by stating that a Viewpoint morphs the elements of renderings from a 3D printer or clay models of a concept
a model into contents of the View as seen in Figure 2. automobile or building.
2
 Table 1. Extensions to SysML

SysML Element Metaclass Metaclass Change Description

Viewpoint (Existing) Class No Change The element that embodies the rules for
describing a view
View (Existing) Package No Change The element representing the View pro-
duced from the model
Conforms (Existing) Dependency No Change Represents the relationship between the
View and the Viewpoint that the View is
required to conform to.
Import (Existing) Dependency No Change Links the model(s) to the Viewpoint
through the View
Stakeholder Tag Value (String) Actor The elements that represent stakeholders
(Existing) for the View
Concern (Existing) Tag Value (String) Tag Value or Class A subject of interest being addressed by the
View
Purpose (Existing) Tag Value (String) No Change A narrative description of the purpose of
the Viewpoint
Method (Existing) Tag Value (String) Activity Class Behavior model that defines the ordered
steps to making the View
Analysis Model N/A Constraint Property The individual analysis definitions used by
(New) the Viewpoint Method
View Format (New) N/A Property The rules for outputting the View in speci-
fied formats
View Presentation N/A Property The styles used to present the View
(New)
Imported Model Tag Value from Con- Reference Property The parameter that is assigned the list of
(New) form Dependency models described by the import
Model Language Tag Value (String) Property The Modeling language(s) used in the im-
(Existing) ported model.

Figure 3. View Tree

As illustrated in Figure 4, the Viewpoints can be composed to Figure 4. Viewpoint Templates

create a template for a particular set of Views in a particular
order. This has the effect of instantiating the Viewpoint
tree. It also allows a particular View tree to be compared for
conformance to the Viewpoint tree. View models that use composite Viewpoints to assert the
same precedence order.
For example, Ops Revitalization is building a series of
documents that describe processes for different engineering Viewpoint and View
disciplines in mission operations. The precedence and Views A Viewpoint is a specification of the conventions and rules for
are the same for each discipline. The only variables are the constructing and using a View for the purpose of addressing
process models. Figure 5 illustrates an example of 2 different a set of stakeholder concerns. The Viewpoint model as
3
 Figure 5. Ops Revitalization Process Documents

Figure 6. Viewpoint Model

illustrated in Figure 6 defines the properties and constraints

used to define the View. The Viewpoint also defines the
Method, which is the process for constructing the View. Figure 7. Scenario Timeline Plot Viewpoint
The Purpose, Concern and Stakeholder elements are prop-
erties that describe the point of view of the stakeholder.
The Method describes the systematic process in which the The purpose of this Viewpoint is to calculate the dry mass
of the Flight System and show a table of components and
model will be used to create the View. The Imported Models their masses. Operating on the composite model of the Fight
represent the models that the Viewpoint operates on for a
given View. The View in these models is just a proxy System through the Viewpoint renders this table. This model
describes the complete component composition of the Flight
for attaching properties and relationships. Execution of the System as well as the value and behavioral properties of the
method is necessary to render the View.
system.
An example from Ops Revitalization is illustrated in Figure 7. Domain Specific Models and Languages
This Viewpoint is defined to render a 2 dimensional Cartesian
plot of an Ops Scenario model, such that the scenario function A key piece of effectively communicating with Views is spec-
calls are plotted against time. The Ops Scenario Model is ifying the language the model is written in. Modeling lan-
a SysML sequence model with domain specific semantics guages provide the patterns and syntax used in the description
from The Mission Service Architecture Framework (MSAF). of the View. Domain Specific Modeling Languages specify
In this illustration the scenario models as well as all of the the elements expected to be represented in the View, and may
languages that are used in rendering the View are shown. be formally or informally defined. Views are descriptions
The Viewpoint is defined in terms of the analyses, method, intended to communicate, thus it is necessary to assert the
format and presentation necessary to produce the View. These allowable syntax and syntactic environments that can be used
elements are defined in Table 2. to describe them. For Viewpoint the Language specified
is allowed to be anything from natural language English to
An example from the Europa Mission Study [11] is the Mass SysML to a Domain Specific Modeling Language to a formal
Properties Viewpoint as illustrated in Figure 8 and Table 3. Mathematical notation such as MathML. Unless explicitly
4
 Table 2. Scenario Viewpoint Elements Table 3. Mass Properties Viewpoint Elements

Viewpoint Description Viewpoint Description

Element Element
Scheduling This analysis reasons out the temporal Composite The constraint that asserts that the
Analysis ordering from the model Mass mass of a component is the sum of the
Scenario Transformation from SysML Scenario Constraint masses of its child components
Coordinates model to trajectories in 2D coordi- Component Model Transformation that transforms
Model Trans- nates Tree Model the SysML flight system model into a
formation Transforma- tree of flight system components
Scenario Veri- Completeness and Correctness rules tion
fication Rules for verifying Value Tree The model transformation that trans-
Scenario Plot The order for executing each analysis Model Trans- forms the flight system model into a
Method that ultimately produces the View formation tree of mass properties
Component The model transformation that trans-
Properties forms the flight system model into a
Table Map map of the trees described above
Mass Analy- The ordered steps for performing the
sis Method mass analysis

property can be used to describe any kind of analysis to be

performed on the Model. Some common uses include model
querying and filtering, asserting model verification, asserting
mathematical formulae, and model transformations. These
examples illustrate the broad range of the types of analysis
that can be defined as part of the Viewpoint. It is important
to note that the Method property described later defines how
these different suites of rules may be applied in the course of
generating the View.

The Europa study has found utility in this aspect of the

Viewpoint [12]. The Viewpoints for the Flight System Mass
Equipment List (MEL) define tables that describe the mass
Figure 8. Mass Properties Table Viewpoint needs and constraints for the Mission. Using the model
of a candidate Flight System, these Viewpoints are used to
render a View of the Flight System in terms of the MEL. The
Viewpoint defines analysis for verifying the correctness of the
prohibited, natural language documentation and narration are model, verifying the mass calculation, and transforming the
always expected to be included.
model into a simpler model of hierarchical components and
mass properties.
An example of a Domain Specific Modeling Language can
be found in the Ops Revitalization project at JPL. Ops Re-
vitalization has developed the Mission Service Architecture Transforming the model into a simpler model of hierarchi-
cal components and mass properties is an example of an
Framework (MSAF) [3] for the purposes of modeling Mis- Analysis that performs a Model Transformation. The Europa
sion Operations Systems. The MSAF is a set of modeling
elements and relationships for describing the interfaces, func- Flight System Model is built in SysML. It has a hierarchical
component structure decorated with many properties and
tions and process that make up an MOS using the lexicon of behaviors. In order to calculate the mass of a Flight System,
Mission Operations. The MSAF also defines patterns that
reflect the allowable combinations of these domain specific the Flight System Model is transformed into a simpler model
terms. The MSAF is a Domain Specific Modeling Language that consists of components, mass constraints, and mass
and as such is built as an extension to BPMN (Business properties. This new structure can then be used to solve the
mass constraints and calculate the mass of the Flight System
Process Modeling Notation) and SysML. Viewpoints defined as defined in the Mass Calculation analysis.
for the Ops Revitalization Task are typically specified in the
language of the MSAF, however sometimes SysML or BPMN Another analysis example from Ops Revitalization involves
are used. pattern analysis. The MSAF mentioned earlier describes the
Model Analysis fundamental architectural patterns for a Mission Operations
System. Viewpoints defined for the MSAF all include rules
In order to generate a View of a model, it is necessary to an- that verify usages of the framework patterns. These rules
alyze the model. The Viewpoint also defines a set of analysis compare models that have been built using the MSAF and
that can be specified. These rules provide the means to check identify conditions that are not consistent or complete with
and/or operate on the model as part of creating the View. This respect to the pattern.
5
View Format and Presentation a component is the sum of the components that compose
Stakeholders may have conventions, organizational or institu- the component. This model is then transformed into a table
tional practices, and standards that influence how the View is model. Once in the table model, the format and presentation
rules are applied. In this example, these tables have a long
to be rendered. Views of the system model that are created by list of applied formats and presentations. For reporting, the
Systems Engineers usually have very customized styles and
presentation requirements. Different organizations may addi- DocBook format is used to produce a static output of the
table in HTML and PDF. The Viewpoint also defines rules for
tionally prefer a variety of formats. Some views are generated rendering the table in an editable format for web browsers and
in Power Point slides others are tables, documents, HTML
web pages, or 3D CAD Generated animations. Additionally, Java applications. In this rule the mass values and component
names are editable so that they can be easily updated without
conventions may dictate the use of certain diagrams, tables having to open the thick model editor just to change certain
color codes, etc.
parameters in a lightweight fashion.
Utilizing these rules is key to communication. The Format
and Presentation properties can be used to capture the specific Similarly, Figure 10 from Ops Revitalization shows the
Method for transforming a scenario Model expressed using
rules for the View as part of the overall Viewpoint specifica- SysML sequence diagrams as a plot of events and states over
tion. The Format and Presentation properties of Viewpoint
provide the means of describing the styles in which the View time. First the rules for a complete and correct scenario
model are executed. Then a model transformation is used
is presented and the output formats. Different Views require to transform the SysML Sequence model into a precedence
different formats and presentation styles depending on the
stakeholder and the information being communicated. The ordered table of events. Then an analysis is performed to
determine the explicit and relative times for each event within
examples that describe this are best discussed as part of the the table. Finally the plot is produced according to the format
Method.
and presentation rules. The plot is currently produced in
Excel spreadsheets, but ideally the Viewpoint will be able to
Method utilize more robust tools such as Mathematica, Matlab, and
The method is probably the most significant expansion of Maple.
this approach. The Method is the behavior model of the
Viewpoint. It describes the ordered steps required to process
the model and render the View of the model according to the
properties of the Viewpoint. This includes when and where
to execute the analysis specified by the Viewpoint and how to
apply the format and presentation specifications. The Method
is also extensible to any other step necessary to generate the
View.

Figure 10. Scenario Viewpoint

4. M ODEL BASED E NGINEERING

E NVIRONMENT
For any non-trivial system to be successfully engineered, sig-
nificant collaboration is required amongst Systems Engineers,
Domain Engineers, Project Managers, and other related
stakeholders. Views and Viewpoints form the foundation for
Figure 9. MEL Viewpoint collaboration in a model-based engineering environment as
they describe how to communicate relevant aspects of the
system to particular stakeholders. While the Views generated
For example, the Method for the Europa Mission Study MEL from Viewpoints can take the form of familiar documents
Viewpoint is illustrated in Figure 9. It describes the steps (e.g., Interface Control Documents, Software Requirements
of expressing a SysML model of Flight System components Documents, etc.), a Viewpoint method can just as easily
and properties as a table. This is accomplished by using describe how to generate editable web views or Mathematica
model transformations to build a tree of components and notebooks. As one can imagine, these dynamic views are a
a tree of mass properties and a map that relates each set much more effective means for collaboration between engi-
of mass properties to the corresponding component. These neers than static documents.
transformations abstract out all the parts of the flight system
model that have nothing to do with the Mass Analysis. No tools currently support the vision of Views and View-
The Mass Analysis asserts the constraint that the Mass of points as the cornerstone for facilitating collaboration and
6
 Figure 11. Model Based Engineering Environment

communication between systems and domain engineers for

model based engineering. Figure 11 illustrates the Model
Based Engineering Environment or MBEE, that is currently
being developed by the Operations Revitalization and Europa
Mission tasks. The MBEE consists of a model repository Figure 12. Simplified Workflow
that serves as the single source of truth of for system models.
The repository exposes all the model elements on the web via
RESTful (REpresentation State Transfer) APIs. Any client,
be it a SysML modeling tool, Mathematica, or whatever else, may specify a View that only imports the avionics model
can then easily retrieve and update model information based elements, resulting in a PEL for the avionics subsystem.
on said APIs. This approach parallels the View/Viewpoint Domain engineers then take this information and do a more
architecture, as the repository provides the model data, clients detailed analysis of the power characteristics (perhaps adding
have viewpoints of interest, e.g., a Mathematica power usage time based loading and discharging) that requires updates to
viewpoint, which the client can then use to query out an ap- the system model. The updates can be pushed back into
propriate view, say for a particular flight system. The choice the MBEE federated repository via web editors or directly
of a RESTful architecture enables the enterprise scalability through an integrated tool. The systems engineers then create
necessary for the largest and most complex projects. a document View model (e.g., a requirements or architectural
description) that is used as the vehicle of communication
As with other web technologies, mashups of client services with other stakeholders such as project management. The
can be orchestrated and combined to achieve more sophisti- review process then follows the typical document review
cated analysis and simulation than any single client by itself processes with the only difference being that rather than
can accomplish; for example, results of power simulations making changes directly to the document, changes are made
can be used to inform thermal simulations. to the system model and the document regenerated. Not
captured in Figure 12 is the iterative nature of collaboration
The capabilities provided by this environment allow systems and document generation, as model changes from one domain
engineers and modelers to build the model using commercial may necessarily impact other domains, which requires addi-
SysML tools and also allows domain engineers to input their tional collaboration cycles.
data using more domain specific Views. For example, using
the same techniques of View generation from Viewpoints, we
can generate table Views of the model, which can then be
edited online or used for analysis with Mathematica, Excel,
NX, Maple, etc. and the results of such analysis can be fed
back into the model as necessary.

This interplay between systems and domain engineers needs

to be a managed and repeatable process. As the tooling
and software infrastructure for MBEE has been developed
at JPL, multiple projects have converged on the process
shown in Figure 12. Initially, the systems engineers create
a preliminary system model. Then, with inputs from domain
engineers and other stakeholders, experienced modelers de-
fine the Viewpoints that express the aspects of interest to the
stakeholders. For example, a Power Equipment List (PEL)
Viewpoint can be defined that exposes the power charac-
teristics to power subsystem engineers. Systems engineers
then create View definitions that conform to the defined
Viewpoints as the starting point of collaboration with domain Figure 13. Current MBEE Components
engineers. Continuing the PEL example, systems engineers
7
 5. R EALIZING S OFTWARE AND a sequence of stereotyped actions specify how to analyze,
A PPLICATIONS transform, and present the elements imported from the View.
All stereotypes are defined in the DocGen profile as part
At JPL we have developed several tools and applications of the DocGen plugin, and the activity is essentially the
which implement the first version of this enterprise environ- behavior of the Viewpoint. An example is shown in Figure
ment. An overview is shown in Figure 13. While these tools 16. This simple Viewpoint results in a View that is an ordered
were constructed in an exploratory fashion, many projects list, where each list item would show the documentation of
have already incorporated them in their document generation some model element that is an ”Essential” class, which can
workflows as they adopt MBSE practices. In particular, the be found under the namespace of elements imported from
Ops Revitalization project, sponsored by MGSS, generates the View that conforms to this Viewpoint. The stereotypes
all of its architectural documents from models using this on these actions effectively map to the rules, analyses, or
framework and software that supports it. transformations for that Viewpoint. For example, filtering
actions can be interpreted as a rule that only certain elements
DocGen that pass a test will be shown in the View. Since we are using
UML activities to model the method, we have reused certain
UML elements like Fork, Join, and Merge to represent actions
with those same semantics. Given a library of these actions,
one can then build up a library of Viewpoints for specific
documents. These Viewpoints would essentially become the
document templates. When one wants to generate a document
from a model using a specific template, one can simply create
a conforming view that imports the desired model elements as
arguments to the template.

Figure 14. DocGen Components

Figure 15. Example of a generated table of key term defi-

nitions for Ops Revitalization’s Mission Service Architecture
Framework

DocGen is a plugin for the MagicDraw [13] modeling tool

used at JPL. The major components involved and the artifacts
produced are shown in Figure 14. It provides a profile that Figure 16. Viewpoint Method that generates a list of model
implements the Viewpoint method specifications described in elements and their documentation
Section 3 and the capability to parse and execute Viewpoint
models constructed using this profile. As shown in Figure 1, it The library of actions can include any type of analysis or
uses existing UML import semantics to indicate which model transformation relevant to the organization. We have found
elements should be imported by the View, which would then that the most basic actions include following model rela-
be passed to the Viewpoint it conforms to. tionships or properties to other elements, filtering collections
of model elements by metaclasses or stereotypes, running
An activity model captures the Viewpoints method, where custom analyses and validation rules, and displaying tables,
8
paragraphs, lists, or images. One very common viewpoint
is generating a table of model elements and their documen-
tation, whose resulting HTML output is shown in Figure
15. More sophisticated transformations can include parsing
a model structure like composition or inheritance trees into
graphs for further processing. The stereotypes are defined
with tags that provide options that are relevant to that action,
for example, depth, include or exclude flags, etc. Example of
these tags are also shown in Figure 16. Projects can also add
actions that can call user specified scripts that contain more
project specific rules for checking the model and constructing
a custom display, like doing mass or power rollups for flight
systems and reporting on errors found.

Figure 18. View Editor Components

neers can update the model online through HTML formatted

Views that are specific to their discipline. Figure 18 shows
Figure 17. An Editable Table how this capability is built around the existing DocGen plugin
by outputting the interpreted View information in different
Since a document is composed of Views, Figure 3 shows how formats. Instead of outputting to DocBook XML, DocGen
a View hierarchy can be modeled and interpreted. From the can instead serialize and package the same information to a
”Root View” package, which denotes the root of a document, database through a REST interface. By having the software
linked list semantics are used to indicate the first child View keep track of where the content of a View comes from in the
and subsequent Views, where by default each View will be model repository, users can update specific parts of the model
interpreted as a section in the resulting document. Given a without having to know the details of how the model is put
library of Viewpoints, one can easily string together the View together or even open the modeling application. Figure 19
model and conform each View to an appropriate Viewpoint shows the web page of a View, where users can directly edit
according to the needs of each document. the contents. The View tree is also shown on the left as a
navigation pane for each of the document’s sections.
Currently, the most common use case for DocGen is to output
the results of viewpoint execution into DocBook XML, but To achieve this, DocGen packages and upload subsets of the
given the right specifications it can also show editable tables model and View information to a database that the View
within the modeling application and publish editable views Editor operates on. Users can then update selected model in-
to the web. In the case of tables, since the content in table formation through the web that gets persisted in the database.
cells ultimately come from some property of model elements, Cognizant system modelers will then import these changes
DocGen provides an edit mode - instead of rendering a static back into the model. Currently this extra layer is necessary
table, a pop up table is displayed where users can directly because of the lack of a central and accessible model reposi-
edit those model properties. Figure 17 shows an example of tory. Imagine then, if any tool can access model information
editing mass properties of a system composition. directly through a repository that houses all model, Viewpoint
and View information. Without the middleman, tools can
As this illustrates, Views are not restricted to being parts in interpret Viewpoints directly and produce appropriate Views
a static document. They can be outputted in any format, according to the formats and presentation defined for that
limited only by the format and presentation options specified tool. This technique can be used to integrate with existing
in the Viewpoint. A dynamic View like the editable table or new analysis tools. By adjusting the View format, we
significantly eases collaboration with domain engineers and are essentially defining an interface that can transmit subsets
other stakeholders who provide inputs to the model. of model data back and forth with applications like Excel,
Mathematica, Matlab, and more.
It is important to note that the DocGen implementation is
not the only way to realize the View-Viewpoint paradigm. DocWeb
Although we primarily work with SysML models, the View- To facilitate document generation and review, we have de-
point specification can theoretically be implemented in any
language and a set of rules and transformations defined for veloped a web application for requesting, scheduling, and
the target language. The steps in the Viewpoint method can archiving artifacts generated from the model. Again, the
operate on a heterogeneous set of models, such as ontological web interface and necessary additions are built around the
core DocGen plugin and the Viewpoint/View framework,
models, CAD models, as well as SysML models, as long as as shown in Figure 20. The output format is DocBook
there exists a unified way of describing these models.
XML, which can then be transformed into HTML and PDF.
CSV files from any relevant tables can also accompany the
View Editor generation, and possibly more in the future. These artifacts
Complementing DocGen are various web applications that are archived and tagged with a timestamp and can be retrieved
facilitate communication with domain engineers and stake- through a web interface, as shown in Figure 21. Options for
holders. The View Editor is an example where domain engi- on demand generation or scheduled generation, like nightly or
9
 Figure 19. View Editor Example - A view showing editable text and view navigation on the left

Figure 21. DocWeb Example - A generated document with

navigation on the left and section content on the right

address this need. This allows systems engineers to use View-

point models to describe how to extract, analyze, and present
specific information from the system model to stakeholders
and domain engineers. In addition to generating just static
artifacts, the format option in the extension also supports a
Figure 20. DocWeb Components way to specify integration with other software that can ma-
nipulate model information. We envision that a model based
engineering environment with a central repository of model
and Viewpoint information will be the key to integrating all
weekly, allow system engineers to monitor the general state the pieces needed to execute successfully in a model based
of the model and documents and be alerted in a timely manner project. We have developed software like DocGen, View
if any problems arise, such as failed generations or failed val- Editor, and DocWeb to pave the way to realizing this vision.
idations. Since the model repository houses both the system
models and Viewpoint models that describe how to create
Views, the entire generation chain can be automated to ensure ACKNOWLEDGMENTS
that documents will always be up to date and consistent with
respect to the model, no matter how frequently the model gets The work described in this paper was performed at the Jet
updated. Propulsion Laboratory, California Institute of Technology,
under a contract with the National Aeronautics and Space
Administration.
6. C ONCLUSION
As MBSE becomes mainstream, the need for a more auto- R EFERENCES
mated and streamlined approach to model based document
generation increases. We have extended the SysML concepts [1] Object Management Group, “OMG Systems Model-
of View and Viewpoint in order to create a foundation to ing Language (OMG SysMLT M ), version 1.3,” OMG,
10
 Tech. Rep. OMG document number formal/12-06-02, Doris Lam is currently a Software
June 2012. Systems Architect working in the Model
Based Engineering Environment team at
[2] M. Jackson, C. L. Delp, D. Bindschadler, M. Sarrel, JPL. She earned her B.S. in computer
R. Wollaeger, and D. Lam, “Dynamic Gate Product and science from UCLA in 2008 and joined
Artifact Generation from System Models,” in Proceed- JPL after graduating. She has worked
ings of Aerospace Conference. Big Sky, Montana: on various UML and SysML model-
IEEE, 2011. ing projects and software modernization
[3] D. Bindschadler, C. L. Delp, and M. McCullar, “Prin- tasks for the ground system.
ciples to Products: Toward Realizing MOS 2.0,” in
Proceedings of SpaceOps Conference. Stockholm, Elyse Fosse is a Software Systems En-
Sweden: AIAA, 2012. gineer for the Ops Revitalization task in
[4] T. Bayer, S. Chung, B. Cole, B. Cooke, F. Dekens, MGSS. She also develops ground system
C. Delp, I. Gontijo, and D. Wagner, “Update on the cost models for deep space and Earth
Model Based Systems Engineering on the Europa Mis- missions. She is also a member of the
sion Concept Study,” in Proceedings of Aerospace Con- Multimission Ground Data System Engi-
ference. Big Sky, Montana: IEEE, 2013. neering group at the Jet Propulsion Lab-
oratory. Her interests include software
[5] T. Bayer, M. Bennett, C. L. Delp, D. Dvorak, J. S. and systems architecture, applications
Jenkins, and S. Mandutianu, “Update - concept of oper- of model-based system engineering, and
ations for integrated model-centric engineering at JPL,” cost model implementation and analysis. Elyse is also a part
in Proceedings of Aerospace Conference. Big Sky, of the INCOSE Space Systems Working Group’s entry into the
Montana: IEEE, 2011. Model Based Systems Engineering Grand Challenge. Elyse
[6] DocBook Technical Committee, “DocBook 5,” OASIS, earned her M.A. in Applied Mathematics from Claremont
Tech. Rep., 2009, http://docbook.org. Graduate University and her B.S. in Mathematics from the
University of Massachusetts Amherst.
[7] MGSS, “Advanced Multi-Mission Operations System,”
http://ammos.jpl.nasa.gov/.
Cin-Young Lee is a Senior Software
[8] OPFM, “Europa Jupiter System Mission,” Engineer in the Mission Information
https://opfm.jpl.nasa.gov/europajupitersystemmission- Systems and Technology Development
ejsm/. Group at the Jet Propulsion Laboratory.
He earned his Ph.D. from Caltech.
[9] OMG Systems Engineering DSIG, June 2012,
http://www.omg.org/news/meetings/tc/ma-12/info.htm.
[10] ISO/IEC/IEEE, “Systems and software engineering -
architecture description,” ISO/IEC/IEEE, Tech. Rep.
ISO/IEC/IEEE 42010, December 2011.
[11] Europa Study Team, “Europa Study 2012 Report,” Na-
tional Aeronautics and Space Administration, May 1
2012.
[12] S. Chung, T. Bayer, B. Cole, B. Cooke, F. Dekens,
C. Delp, and D. Lam, “Model-Based Systems Engi-
neering Approach to Managing Mass Margin,” in 5th
International Workshop on Systems and Concurrent En-
gineering for Space Applications. Lisbon, Portugal:
ESA, 2012.
[13] NoMagic, “MagicDraw,” http://www.nomagic.com/.

B IOGRAPHY [

Christopher Delp is the Systems Archi-

tect for Ops Revitalization task in MGSS
and a Lead Systems Engineer for MBSE
on the Europa Mission. He is a member
of of the Systems Behavior and Architec-
tures Group at the Jet Propulsion Lab-
oratory. His interests includes Systems
and Software Architecture, applications
of Model-Based Systems Engineering ,
Model-Based Analysis and Enterprise
Engineering Systems. He earned his M.S. and B.S. degrees
from the U of A in Systems Engineering.
11