Model Based Systems Engineering has recently been gaining
significant support as a means to improve the “traditional” document-based
systems engineering (DBSE) approach to engineering complex systems. There are many perceived and proposed benefits
of an MBSE approach, including enhanced communications, reduced development
risks, improved quality, and increased productivity (A Practical Guide to SysML, 2nd Ed.). However, while many groups have published
descriptions of their early modeling efforts or potential benefits from those
efforts, little analysis has been presented to determine the experienced benefits of such an
approach. The goal of this thesis summary
is to present direct examples of how developing a small satellite system model
can improve traceability of the mission concept to its requirements.
A comparison of the processes and approaches for MBSE and
DBSE was made using the NASA Ames Research Center SporeSat mission as a case
study. SporeSat, a 3U CubeSat launched
in April 2014, performed a 3-day experiment in low-Earth orbit to study fern
spore growth in varying gravity environments.
Mission concept and requirements documentation from the early mission
development phases, in the form of Microsoft Word and PowerPoint documents,
were used to create a model of the mission using the Systems Modeling Language
(SysML) standard and No Magic’s MagicDraw modeling tool. SysML’s “dependencies” depict the various
relationships between model elements.
Dependency Matrices help to analyze the completeness and consistency of
the requirements to the mission concept.
These matrices made it possible to quickly check for holes or extra
information in the mission concept and requirements.
The model consisted of different types of diagrams to
depict the structure and behavior of the SporeSat mission. The main dependencies used to relate the
mission elements include the Satisfy,
Trace, and Allocate relationships. A
process for tracking potential issues with the model’s completeness and consistency
was implemented using the Problem and
Comment stereotypes of SysML. In the following figure, the Satisfy and
Trace relationships are used to relate Activity
and Constraint model elements to
Requirements, and a Problem is linked
between a Requirement and the Activity that traces to it. The Satisfy
dependency was used to indicate that a Requirement
was properly satisfied by some structural or behavioral element of the mission
concept model. The Trace dependency worked similarly, except it indicated some sort of
problem with the relationship between the related elements. The Problem contained an explanation of the
issue suggested by the Trace dependency.
Problems
could also be tracked in a Dependency Matrix, allowing for the modeler to
quickly determine how many problems existed in the model. Interviews were conducted with the SporeSat
Lead Systems Engineer (SE) to analyze the nature of each problem and ultimately
assign each Problem a specific
designation, described below. Once a
problem had been fully understood and categorized via this designation, its
stereotype would be changed from Problem
to Comment. The Dependency Matrix could be monitored
throughout this process to determine which, and how many, Problems had yet to be analyzed.
For instance, at the time of capture, the example Dependency Matrix
below still contained two unaddressed Problems (circled in red).
A Satisfy/Trace
dependency matrix was created to track the status of all mission requirements; each
Satisfy and Trace relationship would appear on the matrix as an arrow pointing
from the mission element to the requirement it satisfied or traced to. Any requirement without at least one Satisfy
or Trace relationship tied to it would lack an arrow pointing to it, as well as
have a blank in the package summary column below it (see requirements circled
in red below).
In the span of the two-month long modeling process, a
total of 41 problems were created and addressed concerning the completeness
and/or consistency of the mission concept.
Fourteen of these were resolved, having been caused by a simple lack of
understanding of the mission or a lack of accessible information. The other twenty-seven issues were considered
“unresolved,” meaning they were real problems with the mission concept as
provided in the original documentation.
These problems were categorized as shown:
Unresolved Problems
|
Vague Implication
|
Missing, implied
information
|
2
|
Not Verifiable as Written
|
Requirement that, as written, cannot be verified
|
3
|
Redundancy
|
Model elements that
repeat each other
(usually
requirements)
|
4
|
Nomenclature
Inconsistency
|
Different terms used for the same thing,
or the same term used for different things
|
5
|
Outdated
Documentation
|
Inconsistency due to
documentation
not being updated
together
|
13
|
The SporeSat Lead SE already knew about the problems
prior to the modeling process. While the
model did not present any unknown problems, it did prove its usefulness for
identifying and highlighting potential issues with a mission concept. The dependency relationships and associated
matrices emphasized holes and extra information in the mission concept, as well
as helped to identify and track unsatisfied requirements. Though all the problems in the model were
previously identified by the team, the model highlighted the potential for issues
to exist that they were not aware of and its ability to assist the modeler in
finding those issues.
By Robin Reil
SFBAC INCOSE Secretary
