-The design and development of interconnected industrial production facilities, which integrate aspects of the Internet of Things (IoT) or, more specifically, the Industrial IoT (IIoT), often deals with complex scenarios involving dynamic System of Systems (SoS), resulting in immense development and deployment efforts. The Arrowhead community aims at delivering mechanisms and technologies to cope with such complex scenarios. In particular, the concept of local clouds constitutes a service-oriented architecture (SOA) framework for IIoT. Here, a central challenge is the conceptual modeling of such usecases. SysML is widely established as a standardized modeling language and framework for large-scale systems engineering and, thus, for Arrowhead local cloud designs. However, SysML and its Arrowhead profile lack a canonical way to support actual platform modeling and device involvement in heavily distributed IIoT scenarios. The Eclipse Vorto project is ideal for filling this gap: it provides a modeling language for IoT devices, a set of modeling tools, and already existing reusable templates of device models. In this paper, we propose an approach to integrating Eclipse Vorto models into Arrowhead SysML models. We illustrate the concept with a realistic yet comprehensible industrial scenario and also present a prototype to emphasize the benefits of our novel integration platform. Index Terms-System Modeling, SysML, Eclipse Vorto, Eclipse Arrowhead, IoT, IIoT
Many IoT and, especially, industrial IoT (IIoT) scenarios
introduce high complexity in all phases of their life cycle.
Reasons for this are, among others, the use of multiple
hardware and software platforms or heterogeneous protocols
and data formats. With the recent trends of the increasing
volume and complexity of such scenarios, it becomes more
difficult and more expensive to model, operate, and manage
such complex Systems of Systems (SoS) [
In turn, a novel kind of architectural and design challenges
arises in this context of SoS design combined with dynamic,
service-oriented orchestration principles, calling for new
methods to cope with them. However, established techniques within
model-based systems engineering (MBSE) [
Consequently, the Arrowhead approach to IIoT modeling relies on SysML for specifying local cloud architectures. A major challenge of such a modeling scenario is to integrate the abstract architecture models created in design-time with the actual IoT deployments, more precisely, with their digital twin representations. Naturally, the device-specific and deploymentspecific details of these representations are out of scope in abstract SoS (local cloud) models. The very metaphor in the title of the paper, bringing clouds down to earth, unites two key points of this conceptual hiatus: (1) while those platformand hardware-independent local cloud plans lack a connection to their future embodiment, and thus, still have to be brought down to earth, (2) such a device-oriented addition allows the expression of those real communication channels which have to be established between the systems taking part in a given cloud architecture.
As for existing approaches to IoT deployment modeling, VORTOLANG from the Eclipse Vorto1 project is one of the most relevant and prevalent examples. Other benefits of Eclipse Vorto are that it allows the reuse of existing models through shared repositories and provides plugins for code generation to integrate with other projects and platforms. As a consequence, it seems promising to use Eclipse Vorto to ease the modeling of local clouds by mapping those resources into SysML models. In this paper, we investigate this approach further. In particular, the main contribution of this work, with potential industrial relevance, is an integration concept for coping with the design complexity of industry-scale IoT installations through an integrated modeling approach. As an additional benefit, a baseline arises for a bilateral crossfertilization: we extend Eclipse Vorto towards functional and architectural design, and systems modeling towards detailed device platform specifications.
Therefore, we first introduce the Eclipse Vorto project and
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 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.
Eclipse Vorto [
VORTOLANG: a domain specific language (DSL) to describe digital twins Repository: a repository to create, manage and distribute models Plugins: transform Vorto models into source code, request templates or other representations Telemetry Payload Mapping: maps the telemetry data sent by a device using a mapping specification based on a Vorto model
VORTOLANG is the domain specific language used to describe digital twins. It consists of four different kinds of elements:
Information Model (IM): describes a digital twin and its capabilities Function Block (FB): describes a set of capabilities that are implemented by the digital twin. Function Blocks can be designed hierarchically by extending other Function Blocks. The individual capabilities are grouped into the following property groups: – 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 enumerations that can be assigned to Function Block properties Mapping: describes platform-specific or implementationspecific information that can be added to a generic Information Model or Function Block.
The committers of Eclipse Vorto host an official public instance of the repository2. The official repository is an
Fig. 1. A simplified model of VORTOLANG offering for device manufacturers and IoT solution developers to develop and publish re-usable models of their devices / digital twins in a standardized way. However, it is also possible to self-host a Vorto repository (e.g. for on-premise solutions without internet access). The repository offers several features to interact with the Vorto models:
UI and APIs to interact with the repository and the models A web editor to create and edit models A review and release process for models Different levels of visibility (private / public) Import and export functionality of models Direct integration with Vorto plugins Java client that can interact directly with the APIs of the repository
The Vorto Telemetry Payload Mapping engine is a standalone application to map telemetry data that is sent by a device. To use the mapping application, one needs to create a payload mapping configuration, to understand the source format used by the device and the desired normalized target format. The payload mapping engine offers a canonical JSON target format and the Eclipse Ditto JSON format. The normalized payload data can then be used to build applications with normalized APIs based on the Vorto models.
In the following, we define an artificial example use case to showcase the capabilities of the Eclipse Vorto models. Later in this paper, we use these models for an example mapping of the Vorto meta-model to an Arrowhead SysML Profile. Figure 3 gives an overview of the use case. In the depicted setup, we assume a production facility with several units like conveyors and an assembly robot. A server back end system allows the collection of production data by providing connectivity, a digital twin device abstraction, and storage e.g. through instances of Eclipse Hono4, Eclipse Ditto5 and a database. The back-end server also hosts Arrowhead core services to provide the infrastructure for a local cloud with the mentioned machines and software systems. The objective of the use case 3https://github.com/eclipse/vorto-examples/tree/master/vorto-generators 4https://www.eclipse.org/hono/ 5https://www.eclipse.org/ditto/
Demo Machine /currentItem /opshours /distance
Off-Setter Machine /offset
Distance Measurement Machine
Arrowhead mandatory core services is to collect and centrally store data from the various units and to perform basic control operations between the machines.
The local cloud has three machines. One of them is a demo machine for which we created a custom Vorto model. The starting point of the modeling approach is the information model in Listing 1.
Listing 1. Information model for demo machine 1 vortolang 1.0 3 namespace org.arrowhead.demo 4 version 1.0.0 5 displayname "demo-machine" 6 using org.arrowhead.demo.CurrentItem ; 1.0.0 7 using org.arrowhead.demo.OpsHours ; 1.0.0 9 infomodel DemoMachine { 11 12 13 14 15 } functionblocks { currentItem as CurrentItem opsHours as OpsHours } In our case, this machine tracks its operation hours and which item it currently processes. For both aspects, we defined separate function blocks. Listing 2 shows the function block for the operational hours. Here the assumption is that the machine tracks it operational hours and produces events when it reaches a maintenance window (line 19 to 21) or requires that it gets moved (line 15 to 18) depending on the operation time. We assume that one needs to move the demo machine to avoid it from wearing out when operating in the same position for too long. The operator can further set the duration of the maintenance window and the window until the next movement, which we model with the configuration block in lines 9 to 12.
Listing 2. Function block for operation hours 1 vortolang 1.0 3 namespace com.eclipse.arrowhead 4 version 1.0.0 5 displayname "Operation Hours" 6 description "Operating hours" 8 functionblock OpsHours { 9 configuration { Then there is also a function block for the currently processed item depicted in Listing 3. Here the item is identified by an id. Since one can only read but not write this value from the item we modeled this as status.
Listing 3. Function block for the currently processed item 1 vortolang 1.0 3 namespace com.eclipse.arrowhead 4 version 1.0.0 5 displayname "Current Item" 7 functionblock CurrentItem { 8 status { 9 mandatory id as string 10 } 11 }
Another machine can move the first machine to a given offset. The capability of this off-setter machine can be modeled as an operation in a function block corresponding to Listing 4. We do not show the information model for the second machine because it has strong similarities with the information model of the demo machine.
Listing 4. Model for offset movement 1 vortolang 1.0 3 namespace com.eclipse.arrowhead 4 version 1.0.0 5 displayname "Offset Movement" 7 functionblock Offset { 8 operations { 9 moveToOffset(offset as long) 10 } 11 }
One had to describe the already mentioned machines in
particular models. However, as shown in Figure 6 the modeled
Arrowhead local cloud shall also contain a third machine,
which measures distances e.g. between objects on a conveyor.
For this machine, it is possible to reuse the distance sensor
model obtainable from the public Vorto repository [
Eclipse Arrowhead 6 is a newly founded open-source project
in incubation at the Eclipse Foundation, which offers methods
and tools to bring concepts of service orientation to the
Industrial Internet of Things. The Arrowhead initiative has
a strong focus on fostering interoperability via service and
interface descriptions between systems and components [
As for its principles, the whole Arrowhead ecosystem bases
on a service-oriented architecture (SOA) [
In the following section, we turn ourselves to a founded approach of capturing such local cloud architectures via systems modeling techniques.
V. MODELING A CLOUD: ARROWHEAD TOOLS AND
SYSTEMS MODELING
The notion of model-based systems engineering (MBSE)
plays an important, even crucial role in holistic
engineering workflows involving large-scale, complex, dynamic
systems [
As for modeling Arrowhead local clouds, we rely on the
aforementioned established systems modeling language and
methodology, SysML. SysML is a dialect of the well-known
Unified Modeling Language (UML), tailored to meet the
specific needs of systems engineering activities. In turn, modeling
Arrowhead local clouds requires a custom-tailored approach
with a considerable amount of flexibility to adequately capture
the diverse set of entities as introduced above. SysML is the
canonical language of choice for such endeavors. Also, SysML
excels at language extensibility (being a primary concern) and
has mature, feature-rich tooling and an active community. The
language provides several different diagram types to represent
the facets of the system to be modeled, from requirements
to static structures to communication protocols. For further
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. [
Recently, there has been a proposal for a concrete,
Arrowhead-centered approach for modeling service-oriented
applications, i.e., Arrowhead Systems of Systems [
The so-called interface design descriptions (IDD) can be conceived as the realization blueprints for certain services on certain systems (cf. Sect. IV). In particular, IDDs contain operation signatures representing service functionality. A single IDD can be used as a service “type” for modeling both provider and consumer behavior. A central Arrowhead notion is that of devices; thus, there is a corresponding stereotype, serving as a mere placeholder (better said, a canonical integration point) in the original version of the profile. The present paper is, in fact, an actualization of such an integration, which results in filling that stereotype with life and details.
A local cloud configuration is modeled via deployed entitites, represented as specialized SysML part properties. This part configuration is the place where platform modeling gets realized on a (conceptual) deployment level— the next section demonstrates this through examples.
This profile and modeling approach is referred to as SoSysML in the rest of the paper. Figure 4 shows an overview of the SoSysML representation of our example local cloud (cf. Sect. III); in particular, the upper row of the diagram consists of system design descriptions (SysDDs), representing design templates for the three system kinds involved in the use-case. SysDDs also play a significant role as the hosts for actual interfaces. This is materialized by their ports (the small rectangles at the edge of the SysDD boxes). The essential logical structure of SoSysML lies here: SysDDs are brought together with IDDs (abstract service and interface descriptions not explicitly depicted here) by using IDDs as types of ports on SysDDs. Thus, a SysDD represents an object (a system) while its ports express its behavior (via the typing IDDs). Details on IDDs are out of scope here—for the present paper, it suffices to conceive of them as operation collections.
The bottom row, in turn, contains the SysML representations of those device kinds, whose instances the actual system instances will be allocated to. These device templates come in two fashions: in some cases like the distance sensor in our running example, an already modeled device can be readily used and, thus, directly imported from the Eclipse Vorto repository, while in other cases, the design process might necessitate the modeling of new devices. The next section covers details of this instantiation and allocation.
Fig. 4. SoSysML Overview: The Smart Assembly Use-Case (Sect. III) Note that the above figure is an excerpt from an actual 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 platformindependent design have a home in the NoMagic7 (MagicDraw, 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 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 build upon this combined ground in the future. As for the future potential of the current approach, we also remark that this approach is very likely to play a leading role in the future of systems modeling as well. Currently, the upcoming new major release of the systems modeling standard, SysML v2, considers the Arrowhead SoS profile mentioned as a candidate for SOA modeling standardization.
VI. VORTO, SYSML, ARROWHEAD: THE INTEGRATION
APPROACH
As a culmination and summary of the ideas introduced above, we turn ourselves to the primary concept of this paper: the integration of Eclipse Vorto device models with SoSysML, i.e., our Arrowhead-specific SysML-based design approach to device-independent SoS (local cloud) modeling.
On a conceptual level, Table I summarizes the essence of the integration approach. As it has already been hinted at in the previous section, the main observation behind the integration is a direct correspondence, i.e., a mapping, between concepts from SoSysML and VORTOLANG. In particular, Device in SoSysML serves as a topmost container for any device descriptions, thus corresponding to the topmost VORTOLANG elements, Information Models. The IDDs correspond to the actual functional specifications, the Function Blocks of VORTOLANG. This concise table also indicates that below this level, the two modeling languages become equivalent: their Operation concept represents the same abstraction level. illustrated through our example in Fig. 5. The upper region above the horizontal dashed line (Deployed systems) is the way to organize non-allocated, abstract, platform-independent system instances into a local cloud in SoSysML: each box represents a system instance to be deployed, where the string before the colon is its proper name, while the string after the colon indicates its type, which is, in turn, a SysDD (cf. Fig. 4). This typing provides each system with an interface (port) structure. The structure is turned into an abstract, designtime local cloud representation by the connectors (solid lines) attaching provided interfaces to consumed interfaces (the latter denoted by the same type name depicted with a tilde prefix). Notice the resemblance of this part of the figure to the intuitive scenario depiction in Fig. 3.
The extended, integrated local cloud representation (including the lower region of Fig. 5) now contains Vorto devices as well. These are represented, again, by boxes with typed instances (using the same label convention)—but here, the types come from a set of Vorto device descriptions (represented as Information Models, cf. Table I). In turn, these information models might originate from two different sources (cf. also the bottom line of Fig. 4), both considered by our MagicDraw Vorto Importer module: they either directly come from the Vorto repository itself; to this end, the importer browses the online catalog and the user can automatically create a SysML representation of such information models, if she or he thinks that one of them would fit their design (the case of the DistanceSensor in our example); or if the desired functionality is not yet represented by any “stock” solution, the user can choose to write his or her own Vorto specification with any preferred local workflow conforming to VORTOLANG. For example, they can use 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 various code generators and plugins to generate integration code for different back-end systems. We implemented both of the aforementioned model input sources in our implementation of the MagicDraw Vorto Importer, a plugin of the established systems modeling tool MagicDraw9 (or its SysML-equipped distribution Cameo Systems Modeler, the difference being immaterial for our purposes). The prototype features a userfriendly manner, where the built-in Import menu is extended by two further options one for browsing the Vorto repository and choosing information models to import, the others to browse locally for user-created Vorto model packages. From this point on, the usage of the imported information models is the same regardless of the source, as detailed above.
In the previous section, we presented our integration approach. Now we demonstrate its use in an engineering workflow 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 model available, the modeler can turn to fill the modeled abstract devices with life. As the Vorto repository already contains a considerable number of different models, the first step should be to browse it and check if an information model of the required device already exists. In our example, this is the case for the distance sensor modeled for machine three.
c) Model Device: If a model does not already exist in the repository, the modeler can still use VORTOLANG to model the device capabilities. In our example, this is done with the devices described in Listings 1–4. Those models can be imported into the SoSysML as well. Using VORTOLANG has the advantage that the whole infrastructure provided by the Eclipse Vorto project can still be applied. For example, one can integrate existing function blocks into an information model. It is then possible to publish the models later on in the Vorto repository if they are stable and of broader use.
d) Import Device Models: With the device models at hand, the modeler can now import the Information models into the SoSysML models (upper part of Fig 6). The device models provide the SoSysML model with the concrete capabilities of the devices, which in turn allows for fine-grained modeling of processes and procedures. An example is the conveyor maintenance procedure described in Sec. III.
With that step, the actual integration of Eclipse Vorto and SysML is complete but there are some further steps possible. e) Generate Connectivity Code: As the device models are available as Vorto information models also the code generators of Eclipse Vorto can be used to generate the connectivity code (lower part of Fig 6). In our example, the machines connect to an Eclipse Hono instance. So we need code for the connectivity with Eclipse Hono. The Vorto generator plugin for Hono directly generates connectivity code stubs in C (Arduino), Java, and Python that can be integrated into the connectivity stack of the machine or an attached gateway.
f) Perform Arrowhead Wiring: As the SoSysML model has all the required data, the actual Arrowhead wiring, i.e., registration of the services at the Service Registry and configuration of the Arrowhead Orchestrator can happen semiautomatically utilizing another plugin.10
The integration approach pursued in the paper touches on
various industrial concepts and frameworks of high relevance;
however, due to the rising interest around such topics, it is not
typical in IIoT and Industry 4.0 to have widely established
industrial solutions. We perceive an abundance of often
nonpublic domain-specific architectural solutions. The EU has
started to establish an industrial reference architecture
framework, RAMI4.0 [
First, service-oriented architectures already have a standard
modeling language called SoaML [
The topic of platform modeling and the clear distinction between a platform-independent and a platform-specific model (PIM/PSM) is a fundamental concept in the OMG standard
Model-Driven Architecture [
As for IoT architecture design, there is no industrially
accepted general solution, framework, or workflow yet; i.e.,
every domain builds its specific modeling solution. However,
the Eclipse IoT Working Group aims at providing generic
technologies to enable end-to-end IoT solutions [
As for combining Vorto with SysML, Pfenning and Roth
[
In this paper, we have presented a novel integration approach to combine System-of-Systems modeling and a device modeling ecosystem into a comprehensive industrial IoT platform design solution. In particular, building on ongoing work in Arrowhead Tools, we extend the SysML-based modeling approach SoSysML with a capacity to represent devices within the models in a tightly integrated fashion, resulting in full-fledged, compact platform models. Moreover, we have created and presented an importer tool prototype, not only to demonstrate feasibility, but also to emphasize the integration potential between the NoMagic modeling ecosystem on the one hand, and the Eclipse Vorto ecosystem on the other hand.
An immediate item for future work is to investigate tooling extensions by reaching deeper into both main ecosystems involved here. On the one hand, we might consider the Eclipse-native, but little less SysML centered modeling tool Eclipse Papyrus.12 On the other hand, the NoMagic modeling ecosystem has built-in model repository features that resemble the shape of the Eclipse Vorto offering; such features could allow for building a repository system for IIoT.
The research has received funding from the EU ECSEL JU under the H2020 Framework Programme, JU grant nr. 826452 (Arrowhead Tools project, https://www.arrowhead.eu) and from the partners’ national funding authorities.
Project no. 2019-2.1.3-NEMZ ECSEL-2019-00003 has been implemented with the support provided from the National Research, Development and Innovation Fund of Hungary, financed under the 2019-2.1.3-NEMZ ECSEL funding scheme.
Project no. 16ESE0367 has been implemented with the support from the Federal Ministry of Education and Research of Germany.