=Paper=
{{Paper
|id=Vol-1300/paper8
|storemode=property
|title=Interface Management in Concurrent Engineering Facilities for Systems and Service Systems Engineering: A Model-based Approach
|pdfUrl=https://ceur-ws.org/Vol-1300/ID08.pdf
|volume=Vol-1300
|dblpUrl=https://dblp.org/rec/conf/ciise/GianniDSGLS14
}}
==Interface Management in Concurrent Engineering Facilities for Systems and Service Systems Engineering: A Model-based Approach==
https://ceur-ws.org/Vol-1300/ID08.pdf
INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014)
Rome, Italy, November 24 – 25, 2014
Interface Management in Concurrent Engineering
Facilities for Systems and Service Systems
Engineering: A Model-based Approach
Daniele Gianni(1), Volker Schaus(2), Andrea D’Ambrogio(3) , Andreas Gerndt (2) , Marco Lisi(4) , Pierluigi De
Simone(4)
(1) (2)
Consultant at EUMETSAT Deutsches Zentrum für Luft-und Raumfahrt (DLR)
Darmstadt, Germany Braunschweig, Germany
danielegmail-icml@yahoo.it {Volker.Schaus, Andreas.Gerndt}@dlr.de
(3) (4)
Dept. of Enterprise Engineering European Space Agency
University of Rome TorVergata (Rome), Italy Noordwijk, The Netherlands
dambro@uniroma2.it {Pierluigi.DeSimone, Marco.Lisi}esa.int
Copyright © held by the authors.
Abstract. Concurrent
engineering
facilities
(CEFs)
are
successfully
used
in
the
aeropsace
sector
to
design
systems
and
services
that
that
fulfill
the
requirements.
Model-‐based
systems
engineering
(MBSE)
enables
the
effective
(i.e.,
unambiguous)
communication
in
the
collaborative
activities
within
concurrent
engineering
and
service
systems
engineering
facilities.
The
advantages
obtained
by
the
MBSE
approach
can
be
further
scaled
up
by
an
innovative
approach
that
take
into
explicit
account
the
representation
of
the
inter-‐systems
aspects,
i.e.,
those
aspects,
namely
interfaces,
that
stay
in
between
the
system,
its
sub-‐systems
and
external
entities
(other
systems
and
organizations).
Such
an
approach,
briefly
denoted
as
a
Model-‐based
Interface
Engineering
(MBIE),
brings
several
benefits
to
the
CEF
activities.
This
paper
illustrates
the
integration
of
the
Interface
Communication
Modelling
Language
(ICML)
into
the
existing
MBSE
methods
for
the
CEF
software
framework
VirSat,
by
identifying
the
business
needs
driving
the
use
of
MBIE
approaches
and
showing
example
application
scenarios.
INTRODUCTION
Traditionally,
the
design
of
a
complex
system
relies
on
a
systems
engineering
process
that
makes
use
of
text
documents
and
engineering
data
in
multiple
formats.
The
inherent
limitations
of
the
document-‐based
manual
approach
have
been
targeted
by
the
model-‐based
systems
engineering
(MBSE)
approach,
promoted
by
the
International
Council
on
Systems
Engineering
(INCOSE),
which
defines
MBSE
as
"the
formalized
application
of
modeling
to
support
system
requirements,
design,
analysis,
verification,
and
validation
activities
beginning
in
the
conceptual
design
phase
and
continuing
throughout
development
and
later
life
cycle".
The
MBSE
approach
has
been
successfully
deployed
as
enablers
for
the
effective
(i.e.,
unambiguous)
communication
in
the
collaborative
activities
within
concurrent
engineering.
The
concept
of
concurrent
engineering
found
its
way
to
system
design
in
the
late
ninenties.
It
has
been
successfully
applied
in
the
aerospace
sector
by
various
organizations
(e.g.,
NASA,
ESA,
DLR)
that
have
provided
so-‐called
concurrent
engineering
facilities
(CEFs),
i.e.,
large
rooms
where
a
selected
team
of
experts
come
together
and
specify/design
a
service
or
a
system.
Due
to
the
inherent
complexity
of
systems
and
service
to
be
designed,
as
well
as
to
the
complexity
of
their
interfaces,
in
a
typical
study
carried
out
within
a
CEF
the
team
work
in
several
sessions
and
each
member
of
the
team
is
assigned
to
a
specific
discipline,
such
as
structure,
power,
propulsion,
or
orbit.
In
each
session,
the
team
members
work
separately
or
in
small
groups
and
after
a
session
they
review
the
results,
discuss
individual
problems
or
prepare
work
for
the
next
session.
This
process
repeats
to
iteratively
converge
to
a
global
concept/design
that
fulfills
the
system
requirements,
in
a
timeframe
that
ususally
spans
over
two
or
three
weeks.
In
such
a
context,
the
advantages
obtained
by
the
MBSE
approach,
in
terms
of
enhanced
communications,
reduced
development
risks,
improved
quality,
increased
productivity
and
enhanced
knowledge
transfer,
can
be
further
scaled
up
by
innovative
approaches
that
take
into
explicit
account
the
representation
of
the
inter-‐systems
aspects,
i.e.,
those
aspects,
namely
interfaces,
that
stay
in
between
the
system,
its
sub-‐systems
and
external
entities
(other
systems
and
organizations).
The
same
approaches
can
be
successfully
exploited
in
a
service
systems
engineering
context.
Service
systems
focus
on
the
delivery
of
services
that
satisfy
the
needs
and
expectations
of
customers.
Such
systems
are
characterized
by
the
value
that
results
from
the
interaction
and
the
interoperability
of
service
systems
entities,
from
both
a
technical
and
an
organizational
point
of
view.
It
is
thus
essential
to
exploit
model-‐based
approaches
that
contribute
to
formally
define
the
interfaces
of
a
service
system,
in
order
to
match
them
with
internal
and
external
counter-‐interfaces.
The
rest
of
the
paper
specifically
focuses
on
CEF
studies,
in
which
the
interfaces
are
key
specifications
for
cross-‐functional
and
cross-‐enterprise
systems
integrations
[1].
Currently,
interfaces
are
commonly
maintained
in
document-‐based
forms,
therefore
leaving
the
interface
engineering
method
behind
with
respect
to
the
MBSE
state
of
the
art.
Moreover,
as
the
system
complexity
increases,
more
and
more
specialized
knowledge
is
required
for
the
individual
parts
of
a
CEF
study,
for
independent
functional
domains
and/or
for
segments/sub-‐parts
of
the
full
system.
This
can
be
particularly
exacerbated
in
those
cases
were
no
internal
know-‐how
or
resources
are
available
for
the
full
system
engineering.
In
these
cases,
functional
studies,
or
part
of
the
systems
engineering
activities,
may
need
to
be
outsourced
or,
more
critically,
the
final
system
may
have
to
integrate
with
existing
or
to-‐be-‐designed
third-‐party
systems
(conventional
systems
or
systems
of
systems).
In
these
cases,
using
a
Model-‐based
Interface
Engineering
(MBIE)
method
(as
a
sub-‐set
of
MBSE),
several
benefits
can
be
brought
to
the
CEF
activities
as
this
method
provides
key
capabilities
for:
1)
Supporting
the
communication
for
integration-‐specific
aspects,
similarly
to
what
has
been
currently
achieved
by
state-‐of-‐the-‐art
MBSE
for
systems
in
CEFs;
2)
Contributing
to
define
restricted
views
on
what
is
strictly
necessary
to
share
with
project
partners
for
systems
and
functional
domain
integrations;
3)
Maintaining
traceability
between
interface
elements
and
system
models;
4)
Providing
means
for
the
identification
of
the
impact
of
interface
modification
on
the
internal
system
functional
and
physical
design.
In
this
paper,
we
propose
the
integration
of
the
Interface
Communication
Modelling
Language
(ICML)
(https://sites.google.com/site/icmlmodellinglanguage/)
[2]
into
the
existing
MBSE
methods
for
the
CEF
software
framework
VirSat
[3].
In
particular,
we
identify
the
business
needs
driving
the
use
of
model-‐based
interface
specification.
And
we
show
possible
CEF
scenarios
and
how
that
could
benefit
from
such
an
approach
for
the
Galileo
programme
[4][5].
We
also
show
preliminary
example
applications
of
interface
modelling
to:
Galileo
receivers
engineering,
for
supporting
the
reuse
of
existing
hardware
(HW)
and
software
(SW)
resources
[6];
and
Service
Systems
Engineering
for
Galileo
Early
Services,
for
the
exploitation
of
Galileo
services
through
integration
of
the
Galileo
SoS
(System
of
Systems)
with
end-‐user
and
third-‐party
service
provider
segments
[7].
BACKGROUND
The
CEF
this
paper
refers
to
is
the
one
setup
in
2008
by
the
German
Aerospace
Center
(DLR)
to
support
the
early
design
studies
of
new
spacecraft
systems.
The
CEF
layout
is
closely
based
on
that
of
ESA’s
concurrent
design
facility
(CDF).
The
parameters
of
the
spacecraft
that
are
set
and
discussed
in
the
CEF
studies
are
stored
in
a
so-‐called
Integrated
Design
Model
(IDM),
which
has
to
be
maintained
consistent
and
be
shared
across
all
engineers
of
a
session.
The
IDM
was
initially
implemented
by
use
of
a
document-‐based
approach
and
to
overcome
the
aforementioned
problems
of
such
approaches,
the
DLR
and
other
institutions
have
started
to
move
toward
modern
model
based
approaches
[9].
The
successor
of
the
initial
IDM,
proposed
by
the
European
Cooperation
for
Space
Standardization
(ECSS)
in
the
Technical
Memorandum
(TM)
10-‐25,
consists
of
the
Space
Engineering
Information
Model
(SEIM)
that
can
be
shared
on
a
central
server
using
a
web
interface,
and
the
Space
Engineering
Reference
Library
(SERDL)
that
suggests
a
set
of
parameters
to
describe
a
spacecraft
in
the
early
design
phases.
In
parallel
to
ESA’s
approach,
DLR
started
with
its
own
approach
with
Virtual
Satellite
(VirSat)
intending
to
use
a
data
model
for
the
spacecraft
design
going
beyond
the
early
planning
phase,
by
accessing
and
reusing
the
parameters
of
the
first
early
studies
to
allow
for
further
analysis
in
later
phases.
VirSat
is
a
software
that
allows
the
engineers
to
abstract
the
spacecraft
into
a
digital
data
model.
Using
a
top
down
hierarchical
approach,
the
engineers
decompose
the
spacecraft
starting
from
the
overall
system,
down
to
individual
parts.
The
shared
data
model
is
synchronized
using
a
centralized
version
control
system
and,
similarly
to
software
development,
only
the
local
work
copy
is
modified.
Model-based Interface Engineering
MBIE
is
the
application
of
MBSE
methods
and
technologies
to
the
interface
specification.
Similarly
to
systems,
an
interface
specification
consists
of
concepts
and
relationships
that
can
be
formulated
in
natural
language
or
in
a
(semi-‐)
formal
graphical
language.
In
systems
and
service
systems
engineering
activities,
the
introduction
of
MBIE
is
motivated
by
the
following
observations:
1)
A
relevant
part
of
the
documents
concerns
interface
specification
(ICDs);
2)
There
may
be
no
needs
to
share
internal
details
of
sub-‐systems
(“can-‐understand”
principle);
3)
Confidentiality
issues
may
limit
the
distribution
of
internal
sub-‐systems
module
(e.g.
when
reusing
third-‐party
system);
4)
Confidentiality
issues
may
limit
the
access
rights
to
the
stakeholders
of
the
interface
models
(“Need-‐to-‐know”
principle
in
multi-‐partner
projects);
5)
Support
for
the
verification
activities
with
more
effective
verification
campaigns,
reducing
risks
in
the
transition
to
user
activities
(primarily
in
systems
engineering);
6)
Service
performance
may
also
depend
on
external
service
performance
besides
from
the
internally
measured
process
Key
Performance
Indicators
(KPIs)
(primarily
in
service
systems
engineering);
7)
Interface
models
are
critical
to
ensure
a
seamless
transition
of
a
SoS
configuration
between
two
phases,
involving
different
partners,
e.g.
from
validation
to
operation
with
external
users
(primarily
in
service
systems
engineering);
Similarly
to
MBSE,
MBIE
can
be
supported
by
the
definition
of
modelling
languages
and
technologies
that
can
be
used
to
represent
interface
specifications
(i.e.
interface
control
document)
and
to
exploit
the
interface
models
within
systems
and
service
systems
engineering
activities,
which
are
typically
performed
in
CEF
for
large
and
complex
projects.
In
theory,
an
interface
modelling
language
can
be
defined
in
any
available
technology.
In
practice,
however,
most
of
the
MBSE
methods
rely
on
UML-‐derived
technologies
and
therefore
one
cannot
disregard
UML
when
defining
an
interface
modelling
language.
However,
the
core
issue
is
not
about
conforming
to
a
set
of
technologies
to
offer
a
seamless
exploitation
to
the
end
user.
The
core
issue
is
rather
to
ensure
that
an
interface
model
can
be
integrated
with
system
and
service
systems
models
(typically
in
UML-‐based
technologies).
This
allows
interface
elements
to
be
traced
onto
systems
and
service
systems
models
and
will
therefore
contribute
to
provide
a
more
comprehensive
view
of
the
systems
and
services
being
designed.
Interface Modelling Communication Language (ICML)
Basing
on
the
above
observations,
we
have
introduced
ICML
(Interface
Communication
Modelling
Language),
a
modelling
language
for
the
representation
of
interface
specification
using
UML-‐based
technologies.
ICML
is
defined
as
UML
profile
and
can
integrate
with
system
specifications
based
on
compliant
technologies.
However,
ICML
is
still
in
a
prototypal
form
and
reviews
are
undergoing
for
improvements
and
extensions.
The
prototypal
version
has
been
implemented
[8]
and
has
been
made
available
under
the
GPL
v3.0
license
from
the
ICML
project
website
and
can
be
immediately
deployed
in
TopCased
(http://www.topcased.org/),
one
of
the
most
popular
UML
and
SysML
open
source
modelling
tool.
An
ICML-‐based
interface
specification
is
structured
in
the
layout
shown
in
Figure
1.
The
specification
covers
the
definition
of
both
the
message
structure
and
conversion
processes.
The
message
structure
consists
of
five
abstraction
levels,
and
describes
how
the
data
is
structured
within
the
message.
The
conversion
processes
describe
how
the
data
values
are
transformed
between
adjacent
levels
of
the
message
specification.
The
message
structure
is
defined
at
five
levels:
Data
Definition,
Binary
Coding,
Logical
Binary
Structure,
Physical
Binary
Coding,
and
Physical
Signal,
each
covering
specific
aspects
of
the
Signal-‐In-‐Space
interface
specification.
For
example,
the
Data
Definition
level
covers
the
specification
of
the
logical
data
structure,
which
includes
the
data
items
composing
the
message
information.
A
data
item
is
either
of
application
or
control
type.
An
application
data
item
represents
a
domain
specific
concept
that
conveys
the
information
expected
by
the
message
recipient.
Differently,
a
control
data
item
represents
a
domain
independent
concept
that
can
support
the
correctness
and
integrity
verification
of
the
associated
application
data
items.
A
data
item
can
also
be
associated
to
semantic
and
pragmatic
DataDefinition2 Data Definition Logical definitions.
The
former
specifies
the
Level 5 BinaryCoding
CP5to4 Application Data Control Data
Level meaning
of
the
data
item
and
the
latter
BinaryCoding2
specifies
the
contextual
interpretation
BinaryCoding2 Binary Coding
Level 4 LogicalBinary Custom Refs to International
DataDefinition
(CP4to5) for
the
semantic
definition.
(CP4to3) Specification Standard
Analogously,
the
Binary
Coding
level
Level 3 LogicalBinary2
Logical Binary Structure LogicalBinary2
BinaryCoding covers
the
specification
of
the
binary
Custom Refs to International
PhysicalBinary
(CP3to2) Specification Standard
(CP3to4)
Physical coding
for
each
of
the
data
item
Level defined
at
the
above
level.
For
a
data
PhysicalBinary2
Physical Binary Coding
LogicalBinary
Refs to International Standard (CP2to3) item,
the
binary
coding
is
represented
Level 2
Custom Specification as
binary
sequence
and
it
includes
at
PhysicalBinary2 Binary Data Synchronization
PhysicalSignal
(CP2to1)
Signals Signals least
a
sequence
identifier,
the
semantic
definition,
and
the
pragmatic
PhysicalSignal2
Physical Signal PhysicalBinary
(CP1to2)
definitions.
Similarly
to
the
above
level,
Refs to International Standard
Level 1 the
semantic
and
pragmatic
definitions
Custom Specification
Data Signals Carrier Signals enrich
the
interface
specification,
contributing
to
convey
accurate
representation
of
the
binary
coding.
Figure
1
Layout
of
ICML-‐based
interface
specification
[2]
The
conversion
processes
describe
the
activities
to
be
performed
for
deriving
message
values
between
adjacent
levels
of
the
above
structural
specification.
As
shown
in
the
above
figure,
eight
processes
(depicted
as
CPs,
Conversion
Processes)
should
be
defined
to
specify
all
the
conversions
between
adjacent
levels.
For
example,
the
DataDefinition2BinaryCoding
process
defines
the
activities
to
be
performed
for
the
derivation
of
the
logical
binary
sequences
representing
data
values.
Similarly,
the
LogicalBinary2PhysicalBinary
process
defines
the
activities
for
the
implementation
of
convolution
or
encryption
algorithms
on
the
logical
binary
sequence.
However,
these
processes
do
not
always
need
to
be
explicitly
defined.
In
particular,
if
a
process
is
of
trivial
or
standard
implementation,
a
textual
note
referring
to
an
external
document
may
suffice
for
the
specification
purposes.
Only
for
exemplification
purposes,
we
show
a
simplified
part
of
a
Galileo-‐like
OS
(Open
Service)
interface
concerning
the
above-‐defined
level
3
and
level
1.
Figure
2
shows
a
detail
of
the
specification
for
a
reduced
F/NAV
(Freely
Accessible
Navigation)
message
structure.
This
structure
consists
of
one
Data
Frame
that
in
turn
consists
of
F/NAV
Subframe
1
and
F/NAV
Subframe
2.
Figure
3
details
the
specification
of
F/NAV-‐like
Page
1.
In
particular,
this
page
consists
of
four
sequences:
Eccentricity
and
Omegadot—representing
application
data;
Type
Field
and
Cyclic
Redundancy
Check
(CRC)—representing
control
data.
Each
of
these
sequences
are
also
associated
to
a
number
of
properties
(not
displayed
by
the
tool)
that
describe
further
details,
such
as
the
sequence
length,
the
associated
scale
factors
and
offsets,
for
instance.
The
specification
also
links
these
sequence
specifications
to
the
respective
sequences
at
level
4.
Integration in Concurrent Engineering Facilities
MBIE
can
bring
similar
and
complementary
benefits
to
those
provided
by
MBSE
deployed
in
CEFs.
For
example,
in
CEFs,
MBIE
can:
further
support
the
communication
on
integration-‐specific
aspects
for
systems,
sub-‐systems,
and
service
systems;
contribute
to
define
restricted
views
on
systems
models
that
are
strictly
necessary
to
share
with
project
partners
for
systems
and
functional
domain
integrations;
maintain
traceability
between
interface
elements
and
system
models;
provide
means
for
the
assessment
of
the
impact
of
interface
modification
on
the
internal
system
functional
and
physical
design.
Figure
2
Example
ICML-‐based
specification
of
a
F/NAV-‐like
Message
Structure
at
Level
3
[6]
Figure
3
Example
ICML-‐based
specification
of
a
F/NAV-‐like
Page
1
Structure
at
Level
3
[6]
When
integrating
MBIE
into
the
Concurrent
Engineering
(CE)
approach,
three
dimensions
are
to
be
considered:
Physical
domain—which
regards
the
discipline
partitioning
(e.g.
thermal,
mechanical,
electric,
etc.);
Sub-‐/System—which
regards
the
physical
partitioning
of
the
system,
sub-‐systems,
or
SoS;
Enterprise
context—which
regards
the
scope
of
responsibility
and
of
authority
across
the
project
scope.
Moreover,
each
of
the
above
dimensions
identifies
a
distinguishing
aspect
in
MBIE:
Physical
Domain
identifies
interface
models
using
the
same
physical
quantities;
Sub-‐/System
identifies
interface
models
related
to
physically
adjacent
components;
and,
Enterprise
context
identifies
limitation
on
sharing
of
interfaces
models
and
of
traced
system
models
These
dimensions
have
a
different
relevance
to
the
typical
actors
(domain
experts,
systems
engineer,
end-‐users,
project
partners,
or
third-‐party
service
providers)
participating
in
a
CEF
study.
Table
1
collects
the
initial
identification
of
the
concerns
(and
of
their
intrinsic
relevance)
that
each
CEF
actors
may
have
towards
each
dimension.
Following
all
the
above
observations
(1-‐7)
and
the
review
in
terms
of
“enterprise”
use
(i.e.
spanning
several
organisational
boundaries)
of
a
CEF
activity,
we
have
sketched
an
integration
diagram
that
could
extend
the
VirSat
CEF
software
to
embed
also
MBIE
capabilities
in
Figure
5.
The
diagram
is
structured
in
four
viewpoints:
CEF
Integration
viewpoint,
Service
viewpoint,
Platform
viewpoint,
and
Stakeholder
viewpoint.
The
Stakeholder
viewpoint
concerns
the
identification
of
the
possible
actors
in
a
VirSat
environment
that
can
support
also
MBIE
and
that
can
leverage
interface
models
to
enrich
also
its
current
capabilities.
Besides
the
existing
VirSat
actors
of
Team
Leader,
System
Engineer,
Domain
Expert,
and
Verification—which
are
shown
at
the
bottom
and
bottom-‐left
sides
of
the
diagram
for
visual
analogy
with
the
existing
VirSat
integration
layout—other
actors
become
of
relevance
in
the
context
of
MBIE
in
CEF
for
systems
and
service
systems
engineering:
System
Integration
Engineering,
SoS
Integration
Engineering,
Third-‐Party
Service
Provider,
Overlay
Service
Provider,
and
Direct
(or
end
interface)
User.
The
Platform
viewpoint
concerns
the
platforms
that
the
newly
considered
CEF
actors
can
use
to
access
interface
models,
primarily,
and
the
traced
system
model,
eventually
and
conditionally.
Currently,
three
types
of
platforms
are
identified:
Rich
Client
VirSat
(i.e.
the
current
VirtSat),
Web
VirSat
(i.e.
a
web-‐enabled
version
of
VirSat),
and
Web
and
Mobile
VirSat
(i.e.
a
light
version
that
can
be
access
through
Web-‐mobile
interfaces).
The
Service
viewpoint
illustrates
the
enriched
services
that
can
be
introduced
as
consequence
of
the
availability
of
interface
models
as
limiting
and
tracing
proxies
for
system
models.
Basing
on
the
above
observations,
we
foresee
that
service
architecture
based
on
three
levels:
Enterprise
VirSat
User
Credential
Management—which
addresses
the
observations
related
to
the
model
audience
identification
for
the
controlled
distribution
and
access
of
interface
and
traced
system
model;
Design
and
Integration
Tools—which
addresses
the
observations
related
to
integration
and
verification
activities,
under
the
assumption
of
limited
system
model
access;
Model
Distribution
Access
Control—which
address
the
definition
and
the
verification
of
system
model
distribution,
including
also
capabilities
for
the
definition
of
data
policies
for
models,
on
the
example
presented
in
[9].
Finally,
the
CEF
Integration
viewpoint
specifically
concerns
the
technical
details
for
embedding
the
ICML
language
in
VirSat.
In
this
viewpoint,
the
modelling
facilities
as
well
as
the
model
storing
facilities
for
interface
specifications
are
introduced
along
side
the
existing
one
for
system
models.
Moreover,
this
viewpoint
also
shows
the
links
for
the
traceability
between
interfaces
and
systems
models,
the
interdependencies
between
local
interfaces
and
external
systems,
and
between
external
interfaces
and
internal
systems.
Table
1
Dimension
relevance
to
CEF
Actors
CEF
Actors
Physical
Domain
Sub-‐/System
Enterprise
Context
(Within)
(Between)
(Within)
Thermal,
Mechanical,
Sensor,
Instrument,
Core
Team,
Project
Team,
SoS
Electronics,
etc.
Satellite,
Ground
Configuration,
Public
Service
Segment,
etc.
Domain
Expert
For
workload
partitioning
Possible
only
for
Not
directly
interested.
May
be
among
experts
of
the
same
transducer
components
subjected
to
model
sharing
domain,
over
distinct
restrictions,
depending
on
the
components
system
/
service
interfaces
with
external
world
Systems
Engineer
Not
interested
For
system
integration
For
system
integration
when
the
when
all
the
components
components
are
designed
by
are
designed
by
the
same
different
organisations
(sharing
organisation
conditions
may
apply
on
interface
and
system
models)
Users,
Project
Not
directly
interested,
Not
directly
interested,
For
system
integration
and
service
Partners,
or
except
for
the
system
and
except
for
the
interfaces
consumption
(sharing
conditions
Third-‐party
service
interfaces
related
to
related
to
the
integration
may
apply
on
interface
models)
Service
Providers
the
integration
with
the
with
the
external
world
external
world
Possible Applications
MBIE
approaches
based
on
ICML
can
have
a
wide
application
to
systems
and
service
systems
in
CEF,
far
beyond
the
space
domain.
However,
in
the
context
of
this
experimental
activity,
we
have
initially
focussed
on
the
space
domains
and
we
have
identified
two
possible
applications
to
the
Galileo
receivers
and
to
the
Galileo
early
services.
In
both
applications,
ICML
can
bring
the
MBSE
benefits
toall
the
stakeholders,
from
systems
engineers
to
the
interface
users.
For
example,
ICML
can:
1)
provide
a
reference
guideline
for
structuring
the
specification
data
and
thus
facilitating
the
communication
between
the
Galileo
SIS
designers
and
the
receivers
producers,
and
more
generally
all
the
interface
users
(including
also
overlay
service
providers);
2)
ease
visual
inspection
of
the
specification,
for
verification
purposes;
3)
support
syntactical
model
validation
using
existing
tools;
4)
support
for
future
advance
exploitation
by
means
of
a
machine-‐readable
data
format.
In
particular,
the
availability
of
a
machine-‐readable
format
is
also
the
base
for
advanced
use
cases
that
can
exploit
the
capabilities
of
modern
computer
technologies,
such
as
model-‐based
verification
and
model-‐driven
simulation
engineering
with
data-‐driven
experiments.
Application
to
Galileo
Receivers
Specifically,
for
the
Galileo
receivers,
we
identified
three
possible
exploitation
scenarios
in
the
physical
domain
“Electronics”,
sub-‐/system
“Instrument”,
and
enterprise
context
“Project
Team”
(Figure
5):
• Scenario
1:
identification
of
the
receiver
requirements
that
are
introduced
or
modified
by
the
Galileo
OS
SIS,
with
respect
to
existing
GPS
receivers.
• Scenario
2:
linking
between
the
ICML
specification
and
the
receiver
functional
schema
to
identify
how
a
Galileo
receiver
will
differ
from
existing
GPS
solutions.
• Scenario
3:
a
development
of
Scenario
1
and
Scenario
2,
in
which
the
physical
schema
definition
and
the
Stakeholder
Viewpoint
System SoS Third-party Overlay Direct
integration integration Service Service User
engineer engineer Provider Provider
Rich Client Rich Client Web Web Web and Mobile Platform
VirSat VirSat VirSat VirSat VirSat
Viewpoint
Enterprise
VirSat
User
Credential
Management
Design
and
Integration
Tools
Interoperability
Service
Level
Service
Interface
Modification
SoS
Simulation
Other
and
Compatibility
Agreement
tools
Viewpoint
Impact
Analysis
Tool Tools
Evaluation
Tool Generation
Tool
Data
Model
Distribution
Access
Control Policy Model
Definition Distribution
ICML Policy
Customer
ICMLThird-Party
Interface Model Depending
Interfaces
Central Interface Model
Repository Repository
VirSat
Implementing
/ Us
Depending
in g
S
yst
Systems em
s Concurrent
Physical
System Model Engineering
Domain
(any) System Model Facility
Domain experts Central
Central Integration
Repository
Repository Viewpoint
VirSat
VirSat
VirSat
Verification expert
Enterprise
Context
(Project
Team) Team leader Systems engineer
Figure
4
Sketch
of
Integration
Diagram
with
VirSat
CEF
Facility
physical
components
identification
(HW
and
SW)
may
further
exploit
the
ICML-‐based
approach
for
supporting
the
reuse
of
existing
GPS
components.
In the context of this paper, for the sake of brevity, we only present Scenario 2, which is however underpinning
both Scenario 1 and Scenario 2.
In
this
scenario,
we
exemplify
the
tracing
of
interface
elements
on
the
RF
(Radio
Frequency)
Front
End
functional
schema.
Similarly
to
the
above
diagrams,
the
diagrams
below
are
introduced
for
exemplification
purposes
only,
to
show
the
ICML
potential
benefits.
Indeed,
these
diagrams
are
not
to
be
considered
fully
realistic
and
detailed
for
real
Global
Navigation
Satellite
System
(GNSS)
receivers.
Moreover,
only
the
above
defined
ICML
level
1
and
level
3
elements
are
considered.
Figure
5
Graphical
Insight
on
the
Exploitation
Scenarios
for
Galileo
receivers
Figure 6
shows
the
above
RF
Front
End’s
Internal
Block
Diagram
(IBD)
on
the
left
hand
side,
and
the
the
Navigation
Data
Decoder’s
Block
Definition
Diagram
(BDD)
in
conjunction
with
ICML
level
3
elements
(in
white)
on
the
right
hand
side.
A
preliminary
number
of
relationships
are
drawn
in
red,
including
the
respective
relationship
<>
qualifier.
This
qualifier
indicates
that
the
originating
block
inherently
depends
on
the
connected
ICML
element.
The
dependency
mainly
concerns
the
value
of
the
block’s
properties,
although
refined
and
extended
semantics
may
be
introduced.
For
example,
the
<