=Paper=
{{Paper
|id=Vol-2739/paper_10
|storemode=property
|title=Bringing Clouds down to Earth: Modeling Arrowhead Deployments via Eclipse Vorto
|pdfUrl=https://ceur-ws.org/Vol-2739/paper_10.pdf
|volume=Vol-2739
|authors=Géza Kulscár,Sven Erik Jeroschewski,Kevin Olotu,Johannes Kristan
|dblpUrl=https://dblp.org/rec/conf/sam-iot/KulscarJOK20
}}
==Bringing Clouds down to Earth: Modeling Arrowhead Deployments via Eclipse Vorto==
https://ceur-ws.org/Vol-2739/paper_10.pdf
Bringing Clouds Down to Earth: Modeling
Arrowhead Deployments via Eclipse Vorto
Géza Kulcsár Sven Erik Jeroschewski, Kevin Olotu, Johannes Kristan
IncQuery Labs Ltd. Bosch.IO GmbH
Budapest, Hungary Berlin, Germany
geza.kulcsar@incquerylabs.com {name.surname}@bosch.io
Abstract—The design and development of interconnected in- convenient baseline for introducing a new level of dynamicity
dustrial production facilities, which integrate aspects of the for system (of system) architectures. MBSE arguably provides
Internet of Things (IoT) or, more specifically, the Industrial IoT a great compromise between domain-specific expectations and
(IIoT), often deals with complex scenarios involving dynamic
System of Systems (SoS), resulting in immense development and rigorous design on the one hand, and a flexible, accessible
deployment efforts. The Arrowhead community aims at deliv- modeling approach on the other hand. Besides, SysML is
ering mechanisms and technologies to cope with such complex an excellent base for formulating and validating the well-
scenarios. In particular, the concept of local clouds constitutes a formedness of complex systems.
service-oriented architecture (SOA) framework for IIoT. Here, Consequently, the Arrowhead approach to IIoT modeling
a central challenge is the conceptual modeling of such use-
cases. SysML is widely established as a standardized modeling relies on SysML for specifying local cloud architectures. A
language and framework for large-scale systems engineering and, major challenge of such a modeling scenario is to integrate
thus, for Arrowhead local cloud designs. However, SysML and the abstract architecture models created in design-time with the
its Arrowhead profile lack a canonical way to support actual actual IoT deployments, more precisely, with their digital twin
platform modeling and device involvement in heavily distributed representations. Naturally, the device-specific and deployment-
IIoT scenarios. The Eclipse Vorto project is ideal for filling
this gap: it provides a modeling language for IoT devices, a specific details of these representations are out of scope in
set of modeling tools, and already existing reusable templates abstract SoS (local cloud) models. The very metaphor in the
of device models. In this paper, we propose an approach to title of the paper, bringing clouds down to earth, unites two
integrating Eclipse Vorto models into Arrowhead SysML models. key points of this conceptual hiatus: (1) while those platform-
We illustrate the concept with a realistic yet comprehensible and hardware-independent local cloud plans lack a connection
industrial scenario and also present a prototype to emphasize
the benefits of our novel integration platform. to their future embodiment, and thus, still have to be brought
Index Terms—System Modeling, SysML, Eclipse Vorto, Eclipse down to earth, (2) such a device-oriented addition allows the
Arrowhead, IoT, IIoT expression of those real communication channels which have
to be established between the systems taking part in a given
I. I NTRODUCTION cloud architecture.
Many IoT and, especially, industrial IoT (IIoT) scenarios As for existing approaches to IoT deployment modeling,
introduce high complexity in all phases of their life cycle. VORTOLANG from the Eclipse Vorto1 project is one of
Reasons for this are, among others, the use of multiple the most relevant and prevalent examples. Other benefits of
hardware and software platforms or heterogeneous protocols Eclipse Vorto are that it allows the reuse of existing models
and data formats. With the recent trends of the increasing through shared repositories and provides plugins for code
volume and complexity of such scenarios, it becomes more generation to integrate with other projects and platforms. As a
difficult and more expensive to model, operate, and manage consequence, it seems promising to use Eclipse Vorto to ease
such complex Systems of Systems (SoS) [1]. The Arrowhead the modeling of local clouds by mapping those resources into
initiative aims at overcoming these issues using a holistic, SysML models. In this paper, we investigate this approach
comprehensive methodology and mindset. One of the central further. In particular, the main contribution of this work,
facets of Arrowhead, also being highly relevant for the present with potential industrial relevance, is an integration concept
paper, is the application of the concepts of Service-Oriented for coping with the design complexity of industry-scale IoT
Architectures (SOA). In turn, Arrowhead introduces local installations through an integrated modeling approach. As
clouds for service-providing and service-consuming system an additional benefit, a baseline arises for a bilateral cross-
resources that can be grouped logically or geographically. fertilization: we extend Eclipse Vorto towards functional and
In turn, a novel kind of architectural and design challenges architectural design, and systems modeling towards detailed
arises in this context of SoS design combined with dynamic, device platform specifications.
service-oriented orchestration principles, calling for new meth- Therefore, we first introduce the Eclipse Vorto project and
ods to cope with them. However, established techniques within
model-based systems engineering (MBSE) [2] serve as a 1 https://www.eclipse.org/vorto/
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
72
its VORTOLANG in Sect. II and give an example use case
in Sect. III to which we later apply our modeling approach.
Sect. IV introduces the Arrowhead Framework while Sect. V
presents the current model-based system engineering process
in the Arrowhead Framework with SysML. In Sect. VI, we
explain our approach for a mapping between SysML and
Eclipse Vorto. This mapping is then illustrated in Sect. VII.
II. E CLIPSE VORTO
Eclipse Vorto [3] is an open-source project for modeling
digital twins. The goal of the project is to provide platform-
independent and vendor-neutral tools to model digital twins
and to make use of the models by supplying plugins to ease
the integration in existing IoT ecosystems. The project consists
of 4 main components:
• VORTOLANG : a domain specific language (DSL) to de-
scribe digital twins
• Repository: a repository to create, manage and distribute
models Fig. 1. A simplified model of VORTOLANG
• Plugins: transform Vorto models into source code, request
templates or other representations
• Telemetry Payload Mapping: maps the telemetry data sent offering for device manufacturers and IoT solution developers
by a device using a mapping specification based on a to develop and publish re-usable models of their devices /
Vorto model digital twins in a standardized way. However, it is also possible
to self-host a Vorto repository (e.g. for on-premise solutions
A. VORTOLANG - The Vorto Language
without internet access). The repository offers several features
VORTOLANG is the domain specific language used to de- to interact with the Vorto models:
scribe digital twins. It consists of four different kinds of
elements: • UI and APIs to interact with the repository and the models
• Information Model (IM): describes a digital twin and its • A web editor to create and edit models
capabilities • A review and release process for models
• Function Block (FB): describes a set of capabilities that • Different levels of visibility (private / public)
are implemented by the digital twin. Function Blocks can • Import and export functionality of models
be designed hierarchically by extending other Function • Direct integration with Vorto plugins
Blocks. The individual capabilities are grouped into the • Java client that can interact directly with the APIs of the
following property groups: repository
– Status: contains properties of the digital twin that can
only be read (read-only)
– Configuration: contains properties of the digital twin
that can be both read and set (read-write)
– Event: contains events that can be emitted by the
digital twin
– Operation: contains functions that can be invoked on
the digital twin
– Fault: contains fault states that can occur on the
digital twin
• Data Type (DT): describe complex data types or enumer-
ations that can be assigned to Function Block properties
• Mapping: describes platform-specific or implementation-
specific information that can be added to a generic
Information Model or Function Block.
B. Vorto Repository
The committers of Eclipse Vorto host an official public
Fig. 2. Screenshot of the landing page of the public Eclipse Vorto repository
instance of the repository2 . The official repository is an (https://vorto.eclipse.org/#/, accessed 04.08.2020)
2 https://vorto.eclipse.org
73
C. Vorto Plugins Local Cloud Off-Setter Machine
Vorto Plugins can be used to process Vorto models to
transform them into different formats, representations, source Demo Machine /offset
code, and request templates. Currently, there are five officially
supported plugins: /currentItem
/opshours
• Eclipse Hono Plugin: transforms Vorto models into
source code to connect devices to Eclipse Hono via
MQTT
• Eclipse Ditto Plugin: transforms Vorto models into /distance
Eclipse Ditto Digital Twin representations (JSON or
OpenAPI) Arrowhead mandatory core services
Distance Measurement Machine
• JSON Schema Plugin: transforms Vorto models into a
JSON Schema representation
Fig. 3. Demo Setup
• OpenAPI Plugin: transforms Vorto models into an Ope-
nAPI YML representation
• Bosch IoT Suite Plugin: transforms Vorto models into
is to collect and centrally store data from the various units and
source code to connect to the Bosch IoT Suite or into a to perform basic control operations between the machines.
request template to provision devices The local cloud has three machines. One of them is a demo
In addition to the officially supported plugins, several ex- machine for which we created a custom Vorto model. The
perimental plugins offer other transformations. Experimental starting point of the modeling approach is the information
plugins are managed in a separate Github repository.3 All model in Listing 1.
plugins can be used either as local run applications or as AWS
Lambda functions. The public Vorto repository is integrated Listing 1. Information model for demo machine
with the official plugins as AWS Lambda functions and can 1 vortolang 1.0
thus be used directly from the Vorto Repository UI. One can 3 namespace org.arrowhead.demo
also use the plugin API to develop custom plugins. 4 version 1.0.0
5 displayname "demo-machine"
D. Vorto Telemetry Payload Mapping 6 using org.arrowhead.demo.CurrentItem ; 1.0.0
7 using org.arrowhead.demo.OpsHours ; 1.0.0
The Vorto Telemetry Payload Mapping engine is a stan-
dalone application to map telemetry data that is sent by a 9 infomodel DemoMachine {
device. To use the mapping application, one needs to create 11 functionblocks {
a payload mapping configuration, to understand the source 12 currentItem as CurrentItem
format used by the device and the desired normalized target 13 opsHours as OpsHours
14 }
format. The payload mapping engine offers a canonical JSON 15 }
target format and the Eclipse Ditto JSON format. The normal-
ized payload data can then be used to build applications with In our case, this machine tracks its operation hours and which
normalized APIs based on the Vorto models. item it currently processes. For both aspects, we defined
separate function blocks. Listing 2 shows the function block
III. E XAMPLE M ODELS for the operational hours. Here the assumption is that the
In the following, we define an artificial example use case to machine tracks it operational hours and produces events when
showcase the capabilities of the Eclipse Vorto models. Later in it reaches a maintenance window (line 19 to 21) or requires
this paper, we use these models for an example mapping of the that it gets moved (line 15 to 18) depending on the operation
Vorto meta-model to an Arrowhead SysML Profile. Figure 3 time. We assume that one needs to move the demo machine to
gives an overview of the use case. In the depicted setup, we avoid it from wearing out when operating in the same position
assume a production facility with several units like conveyors for too long. The operator can further set the duration of the
and an assembly robot. A server back end system allows maintenance window and the window until the next movement,
the collection of production data by providing connectivity, which we model with the configuration block in lines 9 to 12.
a digital twin device abstraction, and storage e.g. through
Listing 2. Function block for operation hours
instances of Eclipse Hono4 , Eclipse Ditto5 and a database. 1 vortolang 1.0
The back-end server also hosts Arrowhead core services to
provide the infrastructure for a local cloud with the mentioned 3 namespace com.eclipse.arrowhead
4 version 1.0.0
machines and software systems. The objective of the use case 5 displayname "Operation Hours"
6 description "Operating hours"
3 https://github.com/eclipse/vorto-examples/tree/master/vorto-generators
4 https://www.eclipse.org/hono/
8 functionblock OpsHours {
5 https://www.eclipse.org/ditto/ 9 configuration {
74
10 turnWindow as long IV. E CLIPSE A RROWHEAD
11 mandatory largeMaintanceWindows as long
12 } Eclipse Arrowhead 6 is a newly founded open-source project
in incubation at the Eclipse Foundation, which offers methods
14 events { and tools to bring concepts of service orientation to the
15 moveTimeReached {
16 mandatory timestamp as long Industrial Internet of Things. The Arrowhead initiative has
17 mandatory offset as long a strong focus on fostering interoperability via service and
18 } interface descriptions between systems and components [5].
19 maintenanceReached {
20 mandatory timestamp as long The Arrowhead community originated from a joint European
21 } effort of more than 80 industrial and academical partners to
22 } bridge the interoperability gaps for applications and tools in
23 }
IoT-based automated industrial scenarios. Currently, there are
multiple projects following up on the promising results, the
Then there is also a function block for the currently processed
two most important, large-scale consortial endeavors being
item depicted in Listing 3. Here the item is identified by an
Productive 4.0 and Arrowhead Tools. Productive 4.0 explicitly
id. Since one can only read but not write this value from the
aims at putting Arrowhead concepts into industrial production
item we modeled this as status.
in the context of Industry 4.0 [6]. In contrast, the goal of
the Arrowhead Tools project, started in 2019, is to establish a
Listing 3. Function block for the currently processed item mature software and tooling landscape around the Arrowhead
1 vortolang 1.0
core to foster even broader and more efficient adoption of
3 namespace com.eclipse.arrowhead Arrowhead technology in the industry. It is in the context
4 version 1.0.0 of Arrowhead Tools that the initially proposed Arrowhead
5 displayname "Current Item"
Framework has started its journey in the Eclipse universe.
7 functionblock CurrentItem { As for its principles, the whole Arrowhead ecosystem bases
8 status { on a service-oriented architecture (SOA) [7]. However, in
9 mandatory id as string
10 }
contrast to classical SOA, the Arrowhead Framework does
11 } not explicitly employ an enterprise service bus (ESB) as a
central messaging point. Instead, it uses service-to-service
Another machine can move the first machine to a given communication as proposed for micro-services instead. The
offset. The capability of this off-setter machine can be modeled Arrowhead Framework introduces the concept of local clouds,
as an operation in a function block corresponding to Listing 4. which encapsulate geographically connected processes, such
We do not show the information model for the second machine as production facilities. Delsing et al. [5] define five substantial
because it has strong similarities with the information model requirements, which local clouds have to meet: (i) Low latency
of the demo machine. guarantee for real-time use cases; (ii) a high degree of scalabil-
ity of automation systems; (iii) multi-stakeholder integration
and operations agility; (iv) security and safety measures; and
Listing 4. Model for offset movement
1 vortolang 1.0 (v) ease of application engineering. As long as the listed
criteria are met, the Arrowhead local cloud concept does not
3 namespace com.eclipse.arrowhead define the underlying architecture. However, especially latency
4 version 1.0.0
5 displayname "Offset Movement" and security requirements, depending on how important they
are for the respective use-case, might require a complete IoT
7 functionblock Offset { setup involving edge deployments [5]. The local clouds contain
8 operations {
9 moveToOffset(offset as long) all necessary components to operate on their own. Generally,
10 } each local cloud consists of three kinds of entities:
11 }
1) Devices are the hardware foundation of each local cloud
and are hosts to one or multiple systems. A device is not
One had to describe the already mentioned machines in bound to a specific performance threshold. Hence, small
particular models. However, as shown in Figure 6 the modeled and constrained hardware can be part of the local cloud,
Arrowhead local cloud shall also contain a third machine, as well as more powerful machines.
which measures distances e.g. between objects on a conveyor. 2) Systems are the software artifacts executed on the un-
For this machine, it is possible to reuse the distance sensor derlying devices, forming a logical unit of semantically
model obtainable from the public Vorto repository [4] and thus coherent tasks. These systems autonomously register
integrate the distance measurement machine into the model of themselves and their provided services at a service
the local cloud with minimal additional effort. This integration registry. Besides service provision, a system is also
also highlights the benefit of having a central source for more capable of consuming services of other systems.
or less generic models to foster reuse and adoption of existing
models to decrease overall engineering overhead. 6 https://projects.eclipse.org/projects/iot.arrowhead
75
3) Services are functional representations of systems to- on certain systems (cf. Sect. IV). In particular, IDDs
wards the outside world. They are the primary artifacts contain operation signatures representing service func-
in connecting services according to SOA principles: tionality. A single IDD can be used as a service “type”
provided services get consumed by other systems (which for modeling both provider and consumer behavior.
might, e.g., depend on specific inputs for their opera- • A central Arrowhead notion is that of devices; thus,
tion). There is no technical specification concerning the there is a corresponding stereotype, serving as a mere
choice of protocol or payload format. Since this is part placeholder (better said, a canonical integration point) in
of the interface definition of each service and beyond the the original version of the profile. The present paper is, in
scope of the Arrowhead specification. For instance, the fact, an actualization of such an integration, which results
system might employ web technology or broker-based in filling that stereotype with life and details.
communication patterns. • A local cloud configuration is modeled via deployed en-
In the following section, we turn ourselves to a founded ap- titites, represented as specialized SysML part properties.
proach of capturing such local cloud architectures via systems This part configuration is the place where platform mod-
modeling techniques. eling gets realized on a (conceptual) deployment level—
the next section demonstrates this through examples.
V. M ODELING A C LOUD : A RROWHEAD T OOLS AND
This profile and modeling approach is referred to as
S YSTEMS M ODELING
SoSysML in the rest of the paper. Figure 4 shows an overview
The notion of model-based systems engineering (MBSE) of the SoSysML representation of our example local cloud
plays an important, even crucial role in holistic engineer- (cf. Sect. III); in particular, the upper row of the diagram
ing workflows involving large-scale, complex, dynamic sys- consists of system design descriptions (SysDDs), representing
tems [2]. However, MBSE and its primary modeling language, design templates for the three system kinds involved in the
SysML [8] are arguably recognized for capturing monolithic use-case. SysDDs also play a significant role as the hosts for
systems with a more fixed (though probably complex) archi- actual interfaces. This is materialized by their ports (the small
tecture. Recently, there has been a growing interest around the rectangles at the edge of the SysDD boxes). The essential
best ways to employ systems modeling in modern, dynamic, logical structure of SoSysML lies here: SysDDs are brought
even cloud-based scenarios. together with IDDs (abstract service and interface descriptions
As for modeling Arrowhead local clouds, we rely on the not explicitly depicted here) by using IDDs as types of ports on
aforementioned established systems modeling language and SysDDs. Thus, a SysDD represents an object (a system) while
methodology, SysML. SysML is a dialect of the well-known its ports express its behavior (via the typing IDDs). Details on
Unified Modeling Language (UML), tailored to meet the spe- IDDs are out of scope here—for the present paper, it suffices
cific needs of systems engineering activities. In turn, modeling to conceive of them as operation collections.
Arrowhead local clouds requires a custom-tailored approach The bottom row, in turn, contains the SysML representations
with a considerable amount of flexibility to adequately capture of those device kinds, whose instances the actual system
the diverse set of entities as introduced above. SysML is the instances will be allocated to. These device templates come
canonical language of choice for such endeavors. Also, SysML in two fashions: in some cases like the distance sensor in our
excels at language extensibility (being a primary concern) and running example, an already modeled device can be readily
has mature, feature-rich tooling and an active community. The used and, thus, directly imported from the Eclipse Vorto
language provides several different diagram types to represent repository, while in other cases, the design process might
the facets of the system to be modeled, from requirements necessitate the modeling of new devices. The next section
to static structures to communication protocols. For further covers details of this instantiation and allocation.
general details, there is a large variety of textbooks available
— e.g., for practical information of SysML, refer to the
comprehensive book of Friedenthal et al. [8].
Recently, there has been a proposal for a concrete,
Arrowhead-centered approach for modeling service-oriented
applications, i.e., Arrowhead Systems of Systems [9], extending
and refining the Arrowhead documentation approach proposed
earlier [10]. The solution is a standard UML/SysML mecha-
nism to enlarge and tailor the modeling language for a specific
domain. In short, a profile is an organized collection of stereo-
types, i.e., domain-oriented specializations of generic SysML
language concepts. We refer the interested reader to [9]; here,
we focus on those parts which have direct relevance to the
present integration approach: Fig. 4. SoSysML Overview: The Smart Assembly Use-Case (Sect. III)
• The so-called interface design descriptions (IDD) can be
conceived as the realization blueprints for certain services Note that the above figure is an excerpt from an actual
76
model realization as available in MagicDraw, an industrially
established and widely used systems modeling tool. Thus,
the integration presented as the essential contribution of this
paper in the following Section VI also reveals an industrial
potential w.r.t. base technologies involved here: it seems that
while IoT device/deployment models are addressed in the
Eclipse ecosystems, abstract systems modeling and platform-
independent design have a home in the NoMagic7 (Magic-
Draw, Cameo Systems Modeler, Teamwork Cloud, ...) tool
infrastructure. The prototype serving as the practical baseline
for the present contribution constitutes an important step
towards integrating these two platforms/ecosystems (having
some conceptual touching points which we can rely on) and,
thus, we find that this “mismatch” is more a benefit than Fig. 5. Example Use-Case: SoSysML-Vorto Integration
an impediment. Moreover, the underlying implementation of
our MagicDraw plugin is based on VIATRA, an established
Eclipse model transformation engine.8 We will continue to illustrated through our example in Fig. 5. The upper region
build upon this combined ground in the future. As for the above the horizontal dashed line (Deployed systems) is the
future potential of the current approach, we also remark that way to organize non-allocated, abstract, platform-independent
this approach is very likely to play a leading role in the future system instances into a local cloud in SoSysML: each box
of systems modeling as well. Currently, the upcoming new represents a system instance to be deployed, where the string
major release of the systems modeling standard, SysML v2, before the colon is its proper name, while the string after the
considers the Arrowhead SoS profile mentioned as a candidate colon indicates its type, which is, in turn, a SysDD (cf. Fig. 4).
for SOA modeling standardization. This typing provides each system with an interface (port)
structure. The structure is turned into an abstract, design-
VI. VORTO , S YS ML, A RROWHEAD : T HE I NTEGRATION time local cloud representation by the connectors (solid lines)
A PPROACH attaching provided interfaces to consumed interfaces (the latter
As a culmination and summary of the ideas introduced denoted by the same type name depicted with a tilde prefix).
above, we turn ourselves to the primary concept of this paper: Notice the resemblance of this part of the figure to the intuitive
the integration of Eclipse Vorto device models with SoSysML, scenario depiction in Fig. 3.
i.e., our Arrowhead-specific SysML-based design approach to The extended, integrated local cloud representation (includ-
device-independent SoS (local cloud) modeling. ing the lower region of Fig. 5) now contains Vorto devices
On a conceptual level, Table I summarizes the essence as well. These are represented, again, by boxes with typed in-
of the integration approach. As it has already been hinted stances (using the same label convention)—but here, the types
at in the previous section, the main observation behind the come from a set of Vorto device descriptions (represented as
integration is a direct correspondence, i.e., a mapping, between Information Models, cf. Table I). In turn, these information
concepts from SoSysML and VORTOLANG. In particular, models might originate from two different sources (cf. also
Device in SoSysML serves as a topmost container for any the bottom line of Fig. 4), both considered by our MagicDraw
device descriptions, thus corresponding to the topmost VOR - Vorto Importer module:
TOLANG elements, Information Models. The IDDs correspond • they either directly come from the Vorto repository itself;
to the actual functional specifications, the Function Blocks of to this end, the importer browses the online catalog and
VORTOLANG. This concise table also indicates that below this the user can automatically create a SysML representation
level, the two modeling languages become equivalent: their of such information models, if she or he thinks that
Operation concept represents the same abstraction level. one of them would fit their design (the case of the
DistanceSensor in our example); or
TABLE I • if the desired functionality is not yet represented by any
S O S Y S ML TO VORTOLANG CONCEPT MAPPING
“stock” solution, the user can choose to write his or her
SoSysML VORTOLANG own Vorto specification with any preferred local workflow
IDD Function Block conforming to VORTOLANG. For example, they can use
Device Information Model
Operation Operation
the Vorto IDE or the web modeler, and might even reuse
already predefined function blocks.
Based on the Vorto models users may also use one of the
The essence of our contribution, i.e., the actual integration
various code generators and plugins to generate integration
of SoSysML local cloud models and Vorto digital twins is
code for different back-end systems. We implemented both of
7 https://www.nomagic.com/ the aforementioned model input sources in our implementation
8 https://www.eclipse.org/viatra/ of the MagicDraw Vorto Importer, a plugin of the established
77
systems modeling tool MagicDraw9 (or its SysML-equipped e) Generate Connectivity Code: As the device models
distribution Cameo Systems Modeler, the difference being are available as Vorto information models also the code gener-
immaterial for our purposes). The prototype features a user- ators of Eclipse Vorto can be used to generate the connectivity
friendly manner, where the built-in Import menu is extended code (lower part of Fig 6). In our example, the machines
by two further options one for browsing the Vorto repository connect to an Eclipse Hono instance. So we need code for the
and choosing information models to import, the others to connectivity with Eclipse Hono. The Vorto generator plugin
browse locally for user-created Vorto model packages. From for Hono directly generates connectivity code stubs in C
this point on, the usage of the imported information models (Arduino), Java, and Python that can be integrated into the
is the same regardless of the source, as detailed above. connectivity stack of the machine or an attached gateway.
f) Perform Arrowhead Wiring: As the SoSysML model
VII. A PPLYING THE I NTEGRATION A PPROACH has all the required data, the actual Arrowhead wiring, i.e.,
registration of the services at the Service Registry and con-
In the previous section, we presented our integration ap- figuration of the Arrowhead Orchestrator can happen semi-
proach. Now we demonstrate its use in an engineering work- automatically utilizing another plugin.10
flow using our running example from Sect. III. As our
metaphor in the title suggests, our integration approach fills
SoSysML models of Arrowhead local clouds with device
details, i.e., relates the cloud model with the bare metal devices
(or their abstractions).
To realize the scenario described in Sect. III, the following
steps have to be carried out.
a) Model System of Systems Model: Here the initial
Model of the SoS scenario, i.e. the Arrowhead local cloud,
has to be modeled. In the example case depicted in Fig. 6,
one has to create a SysML model for the three Systems and
their relationships, as shown in Fig. 4. This step is not unique
to our mapping approach but is more a prerequisite.
b) Select Devices in Repository: With the SoSysML Fig. 6. Applying Vorto models in an engineering process
model available, the modeler can turn to fill the modeled
abstract devices with life. As the Vorto repository already
VIII. R ELATED W ORK
contains a considerable number of different models, the first
step should be to browse it and check if an information model The integration approach pursued in the paper touches on
of the required device already exists. In our example, this is various industrial concepts and frameworks of high relevance;
the case for the distance sensor modeled for machine three. however, due to the rising interest around such topics, it is not
c) Model Device: If a model does not already exist in the typical in IIoT and Industry 4.0 to have widely established
repository, the modeler can still use VORTOLANG to model industrial solutions. We perceive an abundance of often non-
the device capabilities. In our example, this is done with public domain-specific architectural solutions. The EU has
the devices described in Listings 1–4. Those models can be started to establish an industrial reference architecture frame-
imported into the SoSysML as well. Using VORTOLANG has work, RAMI4.0 [11], which represents a much higher abstrac-
the advantage that the whole infrastructure provided by the tion than our present contribution, and a direct comparison
Eclipse Vorto project can still be applied. For example, one can is, therefore, out of scope here. We mention some related
integrate existing function blocks into an information model. approaches in the most relevant fields in the following.
It is then possible to publish the models later on in the Vorto First, service-oriented architectures already have a standard
repository if they are stable and of broader use. modeling language called SoaML [12] which is also a dialect
of UML (just as SysML). The concepts which SoaML relies on
d) Import Device Models: With the device models at
are more orthogonal to the SysML-based design pursued here.
hand, the modeler can now import the Information models into
However, our flexible setup allows an integration of various
the SoSysML models (upper part of Fig 6). The device models
further diagram and representation types, even SoaML. SoaML
provide the SoSysML model with the concrete capabilities of
also lacks a device modeling aspect and one therefore would
the devices, which in turn allows for fine-grained modeling
have to refactor the Vorto integration in that case too. For an
of processes and procedures. An example is the conveyor
overview of other SOA standards, refer to [13].
maintenance procedure described in Sec. III.
The topic of platform modeling and the clear distinction
With that step, the actual integration of Eclipse Vorto and
between a platform-independent and a platform-specific model
SysML is complete but there are some further steps possible.
(PIM/PSM) is a fundamental concept in the OMG standard
9 https://www.nomagic.com/products/magicdraw 10 https://github.com/IncQueryLabs/arrowhead-tools
78
Model-Driven Architecture [14]. Arguably, our integration 826452 (Arrowhead Tools project, https://www.arrowhead.eu)
approach embodies this concept, SoSysML models being and from the partners’ national funding authorities.
representing the PIM, and their Vorto mapping the PSM part Project no. 2019-2.1.3-NEMZ ECSEL-2019-00003 has
of a comprehensive platform model. Other European industrial been implemented with the support provided from the National
digitalization projects have investigated well-founded platform Research, Development and Innovation Fund of Hungary, fi-
modeling, such as the OpenCPS11 endeavor. nanced under the 2019-2.1.3-NEMZ ECSEL funding scheme.
As for IoT architecture design, there is no industrially Project no. 16ESE0367 has been implemented with the
accepted general solution, framework, or workflow yet; i.e., support from the Federal Ministry of Education and Research
every domain builds its specific modeling solution. However, of Germany.
the Eclipse IoT Working Group aims at providing generic
technologies to enable end-to-end IoT solutions [15]. As for
other European approaches, Krčo et al. [16] had a look into the
various IoT endeavors within Europe. They identified several
projects and organizations, which either define different IoT
reference architectures or provide reference implementations R EFERENCES
for IoT core systems. Further, they describe a landscape of IoT [1] M. Jamshidi, System of systems engineering: innovations for the twenty-
activities in Europe in which the Arrowhead framework fits first century. John Wiley & Sons Incorporated, 2009, vol. 58.
[2] P. Micouin, Model Based Systems Engineering: Fundamentals and
quite well and for which the described integration approach, Methods. John Wiley & Sons, 2014.
with adjustments, could be of use, too. [3] The Eclipse Vorto project, “Eclipse Vorto,” accessed: 2020-07-17.
As for combining Vorto with SysML, Pfenning and Roth [Online]. Available: https://www.eclipse.org/vorto/
[4] A. Edelmann, “Distance Sensor - Informationmodel,” 2019, accessed:
[17] present an approach to generate Vorto Information Models 2020-07-17. [Online]. Available: https://vorto.eclipse.org/#/details/org.
from existing SysML models. The objective is to generate eclipse.vorto.tutorial:DistanceSensor:1.0.0
digital twin implementations from existing SysML models of [5] J. Delsing, P. Varga, L. Ferreira, M. Albano, P. P. Pereira, J. Eliasson,
O. Carlsson, and H. Derhamy, “The arrowhead framework architecture,”
the Product Lifecycle Management (PLM) via model trans- in IoT Automation. CRC Press, 2017.
formation techniques. The authors make use of the existing [6] D. Kozma, P. Varga, and G. Soós, “Supporting digital production,
generator implementations of Eclipse Vorto to obtain digital product lifecycle and supply chain management in industry 4.0 by
the arrowhead framework–a survey,” in 2019 IEEE 17th International
twin implementations for different IoT-Platforms. Thus, their Conference on Industrial Informatics (INDIN), vol. 1. IEEE, 2019, pp.
approach is the inverse of our method described in this paper. 126–131.
[7] M. Bell, SOA Modeling patterns for service-oriented discovery and
IX. C ONCLUSION AND F UTURE W ORK analysis. John Wiley & Sons, 2009.
[8] S. Friedenthal, A. Moore, and R. Steiner, A practical guide to SysML:
In this paper, we have presented a novel integration ap- the systems modeling language. Morgan Kaufmann, 2014.
proach to combine System-of-Systems modeling and a device [9] G. Kulcsár, K. Kadosa, T. Szvetlin, B. Péceli, A. Horváth, Z. Micskei,
modeling ecosystem into a comprehensive industrial IoT plat- and P. Varga, “From models to management and back: Towards a system-
of-systems engineering toolchain,” in Proc. of IEEE NOMS Workshop
form design solution. In particular, building on ongoing work on Management for Industry 4.0, 2020.
in Arrowhead Tools, we extend the SysML-based modeling [10] F. Blomstedt, L. L. Ferreira, M. Klisics, C. Chrysoulas, I. M. de Soria,
approach SoSysML with a capacity to represent devices B. Morin, A. Zabasta, J. Eliasson, M. Johansson, and P. Varga, “The
Arrowhead approach for SOA application development and documenta-
within the models in a tightly integrated fashion, resulting tion,” in IECON 2014 - 40th Annual Conference of the IEEE Industrial
in full-fledged, compact platform models. Moreover, we have Electronics Society, 2014, pp. 2631–2637.
created and presented an importer tool prototype, not only to [11] T. Bangemann, M. Riedl, M. Thron, and C. Diedrich, “Integration of
classical components into industrial cyber–physical systems,” Proceed-
demonstrate feasibility, but also to emphasize the integration ings of the IEEE, vol. 104, no. 5, pp. 947–959, 2016.
potential between the NoMagic modeling ecosystem on the [12] B. Elvesæter, C. Carrez, P. Mohagheghi, A.-J. Berre, S. G. Johnsen, and
one hand, and the Eclipse Vorto ecosystem on the other hand. A. Solberg, “Model-driven service engineering with soaml,” in Service
Engineering. Springer, 2011, pp. 25–54.
An immediate item for future work is to investigate tooling [13] H. Kreger and J. Estefan, “Navigating the SOA open standards landscape
extensions by reaching deeper into both main ecosystems around architecture,” Joint Paper, The Open Group, OASIS, and OMG,
involved here. On the one hand, we might consider the 2009.
[14] J. Bézivin and O. Gerbé, “Towards a precise definition of the omg/mda
Eclipse-native, but little less SysML centered modeling tool framework,” in Proceedings 16th Annual International Conference on
Eclipse Papyrus.12 On the other hand, the NoMagic modeling Automated Software Engineering (ASE 2001). IEEE, 2001, pp. 273–
ecosystem has built-in model repository features that resemble 280.
[15] The Eclipse IoT Working Group, “The three software
the shape of the Eclipse Vorto offering; such features could stacks required for iot architectures,” Eclipse Foun-
allow for building a repository system for IIoT. dation, https://iot.eclipse.org/community/resources/white-
papers/pdf/EclipseTech. Rep., 2017.
ACKNOWLEDGMENT [16] S. Krčo, B. Pokrić, and F. Carrez, “Designing iot architecture (s): A
european perspective,” in 2014 IEEE World Forum on Internet of Things
The research has received funding from the EU ECSEL (WF-IoT). IEEE, 2014, pp. 79–84.
JU under the H2020 Framework Programme, JU grant nr. [17] M. Pfenning and A. Roth, “Systemmodellierung für das internet der
dinge – transformation von systemmodell in iot-plattform im kontext
11 https://www.opencps.eu/ später produktlebenszyklusphasen,” in Tag des Systems Engineering, S.-
12 https://www.eclipse.org/papyrus/ O. Schulze and C. Muggeo, Eds., GfSE. Hanser, 2016, in German.
79