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