![](bg3.png)
related entities, owned values, as well as its represen-
tation of an equipment type related with discipline-
specific engineering data. In addition, the equipment
types have to be own objects which shall be reused
in further projects whereby the system elements are
project-specific. This enforces some kind of multiple-
type object to reflect the different facets of a system
element and fulfill ECSS-E-TM-10-23 conformity in
all details. Feasibility of implementing these concepts
is enforced by enhancing a CDM by needed items.
This will be called implicit knowledge.
Another category of type change during spacecraft
evolution is introduced by adding data management
functions’ data to system data. Taken the use case
that after creating a system element it shall be added
to a configuration control system, the system element
type has to be enhanced. It has to become a config-
uration item to store all information needed for con-
figuration control, like revision number, commit mes-
sage, and some more. Additionally, the meta-model
for function-specific data has to be aligned with the
CDM which implies that the function meta-model
has to be conform to the used technology-specific
data model. Consequently, function-specific aspects
are woven into the technology-specific data model or
even in a CDM to ease up function integration.
During development of a spacecraft the evolution
of system data may lead to an update of a system el-
ement, where its type is adjusted. This is for instance
the case when a battery of a spacecraft is represented
by a single system element in an early version of the
system data. During system data evolution it will
make sense at a certain point to break down the bat-
tery into multiple system elements to properly repre-
sent the individual parts of it, such as energy storage,
controller, and structure. This change leads to a type
change of the system element representing the over-
all battery from equipment to subsystem which influ-
ences the handling of this system element by overall
system data analysis, like system-wide data consis-
tency checking.
Project-specific tailoring is a central functional-
ity in SRDB implementations to enable inter-project
reuse of knowledge and engineering data. There-
fore, some parts of a CDM have to be adjusted to
reflect project specifics. This enforces some kind
of data container being configured in SRDB itself
to handle domain-specific system element properties,
like weights, sizes, temperatures, voltages, and so
on. Data analysis of these dynamic data containers is
challenging especially regarding overall system con-
straints, like total spacecraft mass constraints. Be-
sides, a manually adjustment of SRDB is applied to
face with project-specific data importer and exporter,
because it is currently not feasible to handle them oth-
erwise.
2.2 Related Work on
ECSS-E-TM-10-23
Implementations
The ECSS-E-TM-10-23 CDM has been implemented
in multiple projects, like Virtual Spacecraft De-
sign (VSD, 2012), Functional System Simulation in
Support of MBSE (Fischer et al., 2014), European
Ground Systems Common Core (Pecchioli et al.,
2012), and RangeDB (Eisenmann et al., 2015), an
Airbus DS in-house development project which sig-
nificantly improved this CDM by evolution and re-
finement of several areas.
Nevertheless, the concepts specified by ECSS-E-
TM-10-23 have not been realized in its entirety by
any of its implementations, especially due to miss-
ing multiple classification concepts in state-of-the-art
software development frameworks and its ramifica-
tions. Even the usage of interfaces is not sufficient
to realize multiple instantiation, because dynamic ad-
dition and removing of types cannot be realized as all
instances already implement all possible types. Thus
it is not possible to filter objects by type using inter-
faces. Additionally, project-specific tailoring requires
handling of types being created during runtime.
In contrast, knowledge representation languages,
like the Web Ontology Language (OWL)(Hitzler
et al., 2012), explicitly support multiple classifica-
tion and other knowledge management concepts. Al-
beit, available frameworks for these languages, like
Prot
´
eg
´
e, do not provide data management functions
as needed for MBSE.
2.3 Drawbacks of State-of-the-art
Frameworks
EMF: provides a powerful tool chain from model
definition, through application generation, to instance
model support. Furthermore, a great number of plug-
ins has been developed to add further functionality to
EMF. As a result, EMF became the de facto-standard
for model-driven software development in many com-
panies
1
. However, Ecore – EMF’s meta-model – is
not sufficient to fulfill the needs of a data model as
required by an implementation of an ECSS-E-TM-10-
23 compliant CDM. The main reason is the absence of
semantically strong modeling constructs which have
been left out intentionally to keep the complexity of
EMF manageable (Merks, 2010).
1
http://www.eclipse.org/org
SEMF â
˘
A¸S The Semantic Engineering Modeling Framework - Bringing Semantics into the Eclipse Modeling Framework for Space Systems
Engineering
295