International Journal of Advanced Engineering Research and Science (IJAERS) [Vol-6, Issue-12, Dec- 2019]

https://dx.doi.org/10.22161/ijaers.612.42 ISSN: 2349-6495(P) | 2456-1908(O)

MBSE & SysML Applied to the Development of

EGSE for Sattelites Assembly, Integration and
Testing (AIT) - A Practical Case
Marcelo Coicev1, Geilson Loureiro2
1National Institute for Space Research, INPE, Brazil
Email: [email protected]
2National Institute for Space Research, INPE, Brazil

Email: [email protected]

Abstract— This paper targets to present a proposal for the use of MBSE and SysML applied to a case study of
the analysis in a component of a typical Electrical Ground Support Equipment (EGSE) used in Satellite
Assembly, Integration and Testing (AIT).
The approach aims to describe the process flow used in the analysis, providing a methodological background for
the practical application of SysML notation for EGSE's development.
Keywords— Systems Engineering; Model Based Systems Engineering; MBSE; SysML; Electrical ground
Support Equipment; EGSE.

I. INTRODUCTION II. METHODOLOGY - MBSE APPROACH TO

Although SysML, in recent years, has become the de THE GSE INTEGRATED DEVELOPMENT
facto standard for MBSE, a supporting methodological GUIDE
basis is still needed, as SysML is just a graphical The process flow that will be used seeks to follow the
language and defines a set of diagrams, modeling major process phases of the Total Vision Framework
elements, syntax and semantics. Like any language proposed by Loureiro (2010), as shown below, as well as
(formal or informal), it can be used in many different the SysML diagrams that will be used:
ways, including inappropriate ones. Most notably, it is Table 1 - Phases of Analysis Processes and Modeling
possible to misuse the language for creating Approach
unrepresentative or even incorrect models. SysML
Phas Sub
The flow of the analysis processes used in this paper Diagram Modeling Approach
e phase
seeks to implement, as much as possible, the sequence s
presented in the GSE Integrated Development Guide
proposed by Vintecinque (2017), respecting the
Definition
Diagram
(BDD)

Type Definitions (Parts

Block
Concept of Operations

limitations imposed by the SysML notation language and

the modeling tool used. (Cameo Systems Modeller). Catalog)
1.1 - Context /

The added value of the methodology with the MBSE

approach consists of:
1. Mission Analysis

Diagram (IBD)

 To select a suitable subset of SysML diagrams and

Internal Block

Description of Structures
artifacts to be generated conveniently and (blocks), internal components,
pragmatically; relationships and interfaces
 To define semantics to ensure meaningful diagrams between Structures.
and rules to check the model for consistency;
 To define an obvious sequence of diagrams that
1.2 - Life Cycle /
Life Cycle

ensures modeling efficiency in relation to

Scenarios

Diagram
Activity

Definition of the phasing of

organizational processes, and is well understood by
processes and subprocesses.
all stakeholders throughout the life cycle;

www.ijaers.com Page | 391

 International Journal of Advanced Engineering Research and Science (IJAERS) [Vol-6, Issue-7, Jul- 2019]
https://dx.doi.org/10.22161/ijaers.67 ISSN: 2349-6495(P) | 2456-1908(O)

SysML SysML
Phas Sub Phas Sub
Diagram Modeling Approach Diagram Modeling Approach
e phase e phase
s s
Identificatio

4.4 - Functional
Stakeholder

Diagram (IBD)
Internal Block
Definition
Diagram Actors (used in Use-Case
N2 chart generated from
(BDD)

Interfaces
Block
2.1 -

Diagrams) Are created as

n

interfaces defined in
“types” in a BDD
functional scope analysis
Description of stakeholder
Stakeholder

concerns in Use-Case
Diagrams
Concerns

Use Case

4.5 - Definition

Generic table
2.2 -

of states and
diagrams, System or Interest
Tables with list of identified

modes
Organization in various
functions, modes, and states
2. Stakeholder analysis

scenarios
Stakeholder requirements and
Requiremen Requiremen
ts Diagrams

their dependencies are

2.3 - Stakeholder

State Machine
4.6 - Analysis
of functional
represented in Requirements
Requirements

behavior

Diagram
Diagrams. Refinement of states and
modes identified for functions
If there are no requirements
ts Table

dependencies, only SysML

Requirements tables can be
4.7 - Establishment

Use case diagram

of the functional
used. Establishment of control, data
architecture
MoE's are represented as value and material flows between
2.4 - Measures

Effectiveness

Parametric
Definition

types in Block Definition functions and functional

Diagram

Diagram
(BDD) /
(MoE)
Block

diagrams and allow for elements of the system. (*1)

of

simulation using external tools

in Parametric Diagrams. and internal IBD)
5.3 - Trade-Off 5.2 - Function Establishment of

Block definition
diagram (BDD

System requirements and their

architectures
Requirements

Requirements

Using both types of block

physical

dependencies are represented

Diagrams
Analysis

5.1 -

diagrams for physical

---

in SysML requirements
3.

architecture proposals
5. Implementation Analysis

diagrams or requirements
tables.
environment analysis

Scenarios and circumstances

Allocation

Allocation

Through "Allocate" type

Matrix
4.1- Boundaries

Diagram (IBD)
Internal Block
identification,
interfaces and

for the product and relationships and automatic

organization of interest are generation by modeling tool
4. Functional Analysis

described as blocks and their

interfaces with the
environment.
Analysis

TBD

TBD
4.2 - Definition

Generic Table
of functions

Tables with list of flows and

events, MoEs and identified
functions
NOTES *:
1. The Guide proposes the establishment of functional
Scenarios and circumstances architecture via Data Flow Diagrams (DFD's), which
Analysis (cont.)

4.3 - Functional

are not part of SysML. Using the Use-Case Diagram

Diagram (IBD)
scope analysis

Internal Block

for the product and

4. Functional

organization of interest are instead implies implementation limitations that need

described as blocks and their to be further evaluated throughout the application of
interfaces with the the guide.
environment.

www.ijaers.com Page | 392

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol-6, Issue-7, Jul- 2019]
https://dx.doi.org/10.22161/ijaers.67 ISSN: 2349-6495(P) | 2456-1908(O)

III. CASE STUDY - UMB SCOE ANALYSIS

As proposed by Vintecinque (2017) UMB SCOE is an
element of EGSE proposed for future PMM platform
satellite missions, which allows use during both the AIT
and the Satellite launch phases, and aims to reduce the
amount and volume of equipment to be transported to the
launch base. The mission of UMB SCOE can be stated as:
"To be the only satellite-connected element of EGSE
that allows to power up, operate and monitor its vital
signs during the AIT and launch phases” Vintecinque
(2017)".
The approach in the analysis and modeling to obtain
UMB SCOE will be presented next.
a. Mission Analysis
Starting from the mission statement, the possible Fig. 3 - UMB SCOE life-cycle scenarios example
concepts of operation, as exemplified in Fig. 1, are (activity diagram).
analyzed for one of the situations. Relevant scenarios within the development effort will
be reviewed by the UMB SCOE developer organization.
d. Stakeholder Analysis
i. Identification of UMB SCOE Stakeholders
For identification of product and process stakeholders,
block definition diagrams (BDD) will be used with
SysML stereotyped actors, as illustrated in Fig. 4.

Fig. 1 - Example of UMB SCOE operation concept for

telemetry and telecommand data link in the launch tower
(internal block diagram). Fig. 4 - UMB SCOE stakeholder identification example
Elements and their interactions are described textually (block definition diagram).
through the appropriate fields of the model. Flows of ii. UMB SCOE stakeholders concerns
energy, material or information from an early point of Product and process stakeholder concerns raised
view are represented as "Information Item" stereotyped previously are analyzed together with the System or
elements, denoting the directions of the flows. It does not Organization of Interest in various scenarios.
matter at the moment the physical concept of interfaces. The result is described through Use Case diagrams
b. UMB SCOE Life-cycle stereotyped as "Concern". Fig. 5 illustrates an example of
This analysis only states and establishes the sequence how this will be done.
of expected life-cycle processes, as exemplified in Fig. 2.

Fig. 2 - UMB SCOE (activity diagram) life-cycle

example.
c. UMB SCOE life-cycle scenarios
The UMB SCO life cycle scenarios are shown in
Fig. 3. The activity diagram was used, with the inputs or
controls of the old IDEF0 being replaced by SysML
“Accept Event Action” or “Time Event” type elements.

www.ijaers.com Page | 393

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol-6, Issue-7, Jul- 2019]
https://dx.doi.org/10.22161/ijaers.67 ISSN: 2349-6495(P) | 2456-1908(O)

Technical Performance Measures (TPM) measure

attributes of a system element to determine how well that
element is satisfying, or expected to satisfy, a technical
requirement.
The SysML parametric diagrams will be used for the
MoEs, MoPs and TpMs. It is desired that the measures
could be quantitatively assessed, in a form that could be
estimated or even simulated in supporting tools,
integrated with the modeling tool. In order to allow this,
the default SysML meta-model needs to be extended in
order to allow then to be expressed in Value Types, but
also in a textual description, which can be traced back to
Fig. 5 - UMB SCOE Stakeholder Concerns Example the Stakeholders Concerns and Requirements. This can be
In the UMB SCOE scenario under development achieved by a Custom Profile which extends the SysML
(Use Case Diagram). meta-model, with MoEs, MoPs and TpMs Specification
elements, as shown in Fig. 7.
iii. UMB SCOE stakeholder requirements
Stakeholder requirements derived from the concerns
raised before are analyzed and the outcome is described
through requirements diagrams or requirements table as
exemplified in Fig. 6. Dependency or trace-ability
relationships between requirements and stakeholder
concerns can be made explicit in this kind of diagram.
Additional attributes can be added to the requirements by
the use of Tagged Values provided by the SysML
notation.

Fig. 7 - MoEs, MoPs and TpMs Specification Meta-

Model.
The MoE, MoP and TpM specifications can be traced
back to its source as the example shown in Fig. 8.

Fig. 6 - UMB SCOE Product stakeholder

requirements example (Requirements Diagram).
iv. UMB SCOE measures Fig. 8 - Deriving Specification for MoEs Example.
(MoE / MoP / TpM) Finally, the Moe, MoP or TpM quantitative metrics
Measures of Effectiveness (MoE) are operational can be expressed by Value Types (Properties), as shown
measures of success closely related to the achievement of in Fig. 9.
the mission objective being evaluated and they are
derived from the mission objectives related to the
stakeholders concerns.
Measures of Performance (MoP) are measures that
characterize physical or functional attributes relating to
system operation, measured or estimated under specified
testing and/or operational environment conditions.

www.ijaers.com Page | 394

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol-6, Issue-7, Jul- 2019]
https://dx.doi.org/10.22161/ijaers.67 ISSN: 2349-6495(P) | 2456-1908(O)

Fig. 9 - Parametric Diagram for MoEs of interest. ii. UMB SCOE functions definition
e. UMB SCOE Requirements Analysis For each scenario and circumstance identified, all
From the stakeholder requirements and MoEs defined flows of energy, material and information are gathered
before, as well as the assumptions that emerged during and, from them, the system's external functions are
their analysis, the technical requirements (both for identified, which can then be listed in a generic SysML
product and organization) are derived, but now from the table, as exemplified below:
UMB SCOE point of view. Similarly, requirements Table 2 - Example of definition list of functions identified
analysis is described through requirements diagrams or for UMB SCOE (generic SysML table)
requirements table, as exemplified in Fig. 10.

iii. Scope analysis of UMB SCOE functions

Scope analysis of each function helps to identify
inputs and outputs and scope limits for previously
identified functions, as shown in Fig. 12.

Fig. 10 - UMB SCOE Product Technical Requirements

Example (Requirements Diagram).
f. UMB SCOE Functional Analysis
i. UMB SCOE boundaries/interfaces
identification and environment modeling
To identify system boundaries, relevant scenarios are
chosen within the product and organization life cycle of
Fig. 12 - F1 Function Scope Analysis Example for UMB
interest (Vintecinque, 2018).
SCOE (Use Case Diagram).
Scenarios and circumstances for the product and
organization of interest will then be described as blocks iv. UMB SCOE functional interfaces
identification
and their interfaces with the environment by using
From the analysis of the inputs and outputs of each
internal block diagram (IBD), as illustrated in Fig. 11.
function it is possible to establish the interfaces between
From the analysis of circumstances, it is possible to
the functions.
identify the events and expected responses of the system,
Normally, this is represented through an N 2 chart
as well as the associated measures of effectiveness.
(a.k.a N2 diagram) which are not part of the SysML
standard. But the main idea can be achieved through the
use of internal block diagrams (IBD), in a matrix form,
with te same rules of an N2 chart:

1. All Functions (or sub-functions) are on diagonal;

2. All Inputs are vertical (to down or to up)
3. All Outputs are Horizontal (to left or to right);
4. Inputs and outputs are items, not functions;
Fig. 11 - UMB SCOE Environment Modeling Example
during scenario U33: Launch Operation and its Fig. 13 Gives an example of this diagram used for
Circumstances (Requirements Diagram). some of the UMB SCOE functions.

www.ijaers.com Page | 395

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol-6, Issue-7, Jul- 2019]
https://dx.doi.org/10.22161/ijaers.67 ISSN: 2349-6495(P) | 2456-1908(O)

diagrams for each function external to the UMB SCOE.

The Fig. 14 shows an example of that.

Fig. 14 - UMB SCOE Function State Analysis Example

(State Machine Diagram).
vii. UMB SCOE functional architecture
establishment
Fig. 13 - UMB SCOE Functional Interfaces During functional behavior analysis, it is possible to
(Internal Block Diagram as N2 Chart). identify the possible failures in each of the flows and
v. UMB SCOE states and modes definition thereby identify preventive and protective functions for
From the functions identification, it is possible to the failures. (Vintecinque, 2017). After that, it will be
identify states and modes of each function external to possible to map how functions interact, and perform
UMB SCOE. The definition is made by State Machine functional partitioning that will provide an "allocable"
diagrams, for the purposes of tracing the states and modes generic functional architecture, allowing architectural
to the functions defined before. The final representation is decisions to be taken, for the product and organization of
made by using a generic SysML table, as the example interest. In the guide proposed by Vintecinque (2017)
shown in Table 3. DFD diagram is used. With SysML, the use case diagram
will be used, with some restrictions, use of stereotypes
Table 3 - UMB SCOE Function State Analysis Example and minor implementation differences, as illustrated in
(Generic SysML Table) Fig. 15.

Fig. 15 - UMB SCOE functional architecture example -

Command and Monitoring (Use Case Diagram).
g. Implementation Analysis
i. UMB SCOE physical architecture
establishment
At this stage, from the functional architecture,
through the two types of block diagrams from SysML
(BDD and IBD), it is possible to propose a viable generic
architecture that seeks to satisfy all that has been raised
vi. UMB SCOE functional behavior analysis before, and Fig. 16 represents this step. In the Guide
After identifying the states and modes of operation, proposed by Vintecinque (2017), the physical architecture
they are then refined using SysML state machine

www.ijaers.com Page | 396

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol-6, Issue-7, Jul- 2019]
https://dx.doi.org/10.22161/ijaers.67 ISSN: 2349-6495(P) | 2456-1908(O)

for UMB SCOE was not proposed, which will then be Structures) for the same physical architecture, with
done from now on. estimates and simulations for different vendors / data
acquisition solutions, protection systems, etc.
The approach most appropriate in this case seems to
be taking advantage of the characteristics of SysML
parametric diagrams, as well as external tools integration
and simulation, in order to simulate various scenarios of
cost, ease of implementation, material availability,
technical performance, etc., besides of morphological
charts with adequate criteria and weights for each
component in order to achieve a balanced Product
Specific Physical Architecture, but this issue is beyond
the scope of this study effort.
IV. CONCLUSION
The use of MBSE through the notation language
SysML, supported by the use of appropriate modeling
Fig. 16 - UMB SCOE Generic Physical Architecture
tools, allows to cover virtually the entire product and
Example (Use Case Diagram).
organization systems engineering life-cycle, obviously
ii. UMB SCOE physical architecture's functions
while respecting the limitations of the notation itself and
allocation
maturity of its utilization, as well as the different
Function allocation can be done through "allocate"
methodological implementations that make use of it.
SysML connectors, in block definition diagrams, which
There are still difficulties in applying the notation
do not necessarily need to be documented (they can be
fluidly with respect to the non MBSE approaches used in
temporary). From the relationships made between the
previous working frameworks, but future versions of the
functions and blocks of the physical architecture, the
notation itself, such as SysML V2, as well as its future
allocation matrix can be generated directly from the
adoption by vendor modeling tools can simplify and
modeling tool, as illustrated by Table 4.
better tailor their use more widely.
Table 4 - UMB SCOE Function Allocation Example -
(Allocation Matrix)
REFERENCES
[1] Kaslow, David & Ayres, Bradley & Cahill, Philip & Hart,
Laura. (2018). A model-based systems engineering
approach for technical measurement with application to a
CubeSat. 1-10. 10.1109/AERO.2018.8396443.
[2] Cameo Systems Modeler 19.0 LTR SP2 User Manual,
2019. 573 p. No Magic, Inc., a Dassault Systèmes
company.
[3] Loureiro, G. A system engineering and concurrent
engineering framework for the integrated development of
complex products, 1999. 530 p. Thesis (PhD in Systems
Engineering) - Loughborough University. Loughborough.
[4] Venticinque, Guilherme. Engenharia de sistemas aplicada
ao desenvolvimento do equipamento de suporte em terra -
GSE, 2017. 400 p. Dissertação de Mestrado em Engenharia
e Tecnologia Espaciais/Engenharia e Gerenciamento de
Sistemas Espaciais Instituto Nacional de Pesquisas
Espaciais.
[5] Crochet, Brad. A case study in the application of model-
based systems engineering to laboratory research science,
2017. 72p. Dissertation for the Degree of Doctor of
iii. Trade-off analysis Philosophy, Te University of Southern Mississippi - Te
This type of analysis is still open in the ongoing study. Aquila Digital Community
At first, the intention is to make the trade-off analyzes for
"product" by using several block definition diagrams with
different practical solutions (Product BreakDown

www.ijaers.com Page | 397