SysML modeling of service-oriented system-of-systems

Abstract

The success of the ongoing fourth industrial revolution largely depends on our ways to cope with the novel design challenges arising from a combination of an enormous increase in process and product complexity, as well as the expected autonomy and self-organization of complex and diverse industrial hardware–software installments, often called systems-of-systems. In this paper, we employ the service-oriented architectural paradigm, as materialized in the Eclipse Arrowhead framework, to represent modern systems engineering principles and their open structural principles and, thus, relevance to flexible and adaptive systems. As for adequately capturing the structural aspect, we propose using model-based engineering techniques and, in particular, a SysML-based specialization of systems modeling. The approach is illustrated by a real-life use-case in industrial automation.

1 Introduction

In the new era of industrial digitalization, engineers are facing a new set of diverse challenges. Essentially, these challenges arise as a combination of (1) an increased scale and complexity in industrial engineering and automation processes, as well as in the partaking hardware and software systems and products, (2) an accompanying expectation toward those systems to organize, adapt and optimize themselves autonomously along flexible architectural principles, and, finally, (3) a desire to maintain or even strengthen the use of rigorous design practices and standards while devising these complex systems and processes, thus, retaining a comprehensive overview of the components of the overall industrial scenario, regardless of their individual behavior and their modes of interaction. Notice that the crux of this novel kind of challenges lies within the contradictory nature of those wishes and goals, in short, (1) complexity, (2) autonomy, and (3) modelability. (In particular, (3) appears to be in opposition to the first two.) It is now crucial to achieve a thorough understanding of the interplay of these conceptual points: the success of the ongoing fourth industrial revolution, often called Industry 4.0, depends on finding the right ways to harmonize the aforementioned goals.

The present paper proposes an approach to live up to these challenges by identifying an adequate conceptual domain for each of the three goals, and then examining their combination in the light of the state-of-the-art in each of those domains, as well as a current, real-life industrial case study.

As for complexity of industrial installments, we refer to the more and more prevalent notion of System-of-Systems (SoS) [1,2,3], denoting complex software and hardware (i.e., often, cyber-physical) systems, as well as their large-scale, dynamic compositions. In addition, not unrelated to the layered, diverse and inter-domain nature of SoS, instantiations of this concept are expected to exhibit a level of autonomy and self-organization not seen before. Recently, a structuring and communication concept called service-oriented architecture (SOA) has drawn much attraction, representing a promising compromise between tractable, well-founded design principles and the flexibility and adaptability of the (systems of) systems emerging from SOA design processes.

As for modellability, the complex and critical nature of systems engineering activities still necessitates a well-founded methodology for the design of complex systems and SoS, from understanding their requirements to deploying and maintaining them according to design-time expectations.

A go-to methodology for designing and maintaining complex systems, model-based systems engineering (MBSE) [4] offers a comprehensive yet practical foundation for such activities. However, a number of open questions remain around the application of MBSE techniques and, in particular, the SysML modeling language as a conceptual basis, in Industry 4.0 scenarios involving industrial SoS applications. Furthermore, the engineering of SoS-based solution architectures is currently largely based on experience, tools and toolchains primarily adopted for legacy architectures. Thus, we perceive an enormous potential for cross-fertilization between SoS engineering and MBSE.

Summarizing, the present paper offers a crossover approach: we present an MBSE approach to design SOA-based SoS.

Specifically, we rely on the standard language of MBSE, the systems modeling language (SysML) [5, 6] maintained by the Object Management Group (OMG), which is intensively used for large-scale, comprehensive industrial systems modeling activities. In this paper, we address both the current, industrially established SysML version (v1.6, Sects. 3 and 4) and the upcoming new major version, SysML v2, constituting a fundamental change in the internal and external structure of SysML (Sect. 5).

As for the technological frame of our work, we build upon the concepts of Eclipse Arrowhead, an SOA-based industrial IoT framework, also considering its reference implementation.¹

In this paper, we report the following specific contributions:

• we propose a SysML v1.6 profile for modeling service-oriented SoS, inspired by Arrowhead design principle but being generic in nature (Sect. 3);

• we demonstrate how that profile is utilized to create a full-fledged model library of the so-called core systems of the arrowhead architecture (Sect. 4);

• we describe how our arrowhead-related endeavors serve as a major SOA validation case study in the development of SysML v2 (Sect. 5);

• additionally, a real-life, comprehensive industrial use case is presented in both SysML v1.6 and v2 fashion (Sect. 6); and

• we discuss to what extent our profile captures the standard, generally accepted principles of the two underlying conceptual frameworks, namely SOA and SoS (Sect. 7).

A SysML profile for SOA-based SoS, inspired by the Eclipse Arrowhead base architecture, has been devised. This profile is then used to devise a comprehensive model library of the Eclipse Arrowhead core system. This development is now impacting the SysML v2 standardization. As a first verification, an industrial case is been modeled using both versions of SysML.

2 Background

In this section, we provide an overview of the relevant technologies and concept models related to the industrial use of service-oriented architectures (SOA) from a more technical perspective, being the conceptual backbone of our proposal and its industrial utilization through the Eclipse Arrowhead framework.

In the following, we provide a brief overview (including related work) on SOA, solution architectures and concepts, and their engineering methods.

2.1 Service-oriented architectures

SOA, introduced by IBM in the mid 1990s [7], is often referred to as micro-service architecture. From a more fundamental perspective, these terms are considered equivalent [8]. In this context, a micro-service is produced/consumed by a micro-system. A SOA reference model has been published by OASIS [9]. The key properties of SOA/micro-service architectures are:

• Look-up

• Late binding

• Loose coupling

often referred to as the 3 Ls.

Further, important properties are as follows:

• A micro-system performs its function independently.

• A micro-system can be

  • stateful and is then responsible for storing its own state; or

  • stateless.

Fulfillment of these properties requires a “service registry” and an “orchestration capability.” A prominent early usage of these fundamentals was the Jini add-on package to Java [10]. Unfortunately, this approach did not experience wide acceptance.

SOA is currently the main approach for achieving automation and digitalization architectures and their reference implementations and platforms for concrete solution implementation. Examples include FiWare [11], Eclipse BaSyx [12], and Eclipse Arrowhead [13, 14]. A comparison of the current most relevant initiatives related to automation and digitalization can be found in [15].

For the implementation of SOA, there is a wide range of protocols that can be considered service protocols, e.g., HTTP (REST), CoAP, MQTT, DDS, and AMQP [16].

2.2 Solution architectures and concepts

The design and development of complex industrial automation and digitalization solutions is currently based on older, structured and more rigid architectures, such as the ISA-95 standard [17]. With the emergence of Industry 4.0, the demand for and complexity of such solutions is expected to grow substantially. Accordingly, there is an increasing need for approaches to reduce costs and design and engineering time for such solutions. Here, appropriate implementation architectures, reference platforms and implementation frameworks, and associated tools and toolchains become highly important.

SOA is a major approach to implement automation and digitalization solutions following Industry 4.0 architectures such as RAMI4.0 [18] and IIRA [19]. Their implementations are often achieved using an SOA/micro-service approach and principles, properties and terminologies based on SoS and the IoT. Some SoS fundamentals have been formulated by Maier [1, 2] and then updated and extended by Boardman and Sauser [3]. A further extension to the biology of systems has been proposed by Sauser et al. [20]. Therefore, the SoS properties that must be captured in modeling can be summarized as follows:

• Operational independence/autonomy of the elements The constituent systems can operate independently in a meaningful way and are useful in their own right.

• Belonging The autonomous constituent systems choose to belong to the SoS because they see value for themselves to give up some of their autonomy to receive benefits.

• Connectivity To let the constituent systems interact, they must be connected, and unless they provide sufficiently generic interfaces, they must be modified to provide such interoperability. Connectivity in an SoS is, thus, dynamic, with interfaces and links forming and vanishing as the need arises.

• Diversity Whereas many other systems strive to minimize diversity to simplify the system, increased diversity in an SoS gives it the ability to better address unforeseen situations during its life-cycle.

• Emergent behavior appears in any system, and in many systems, this is deliberately and intentionally designed in and tested. In an SoS, emergent behavior is not restricted to what can be foreseen. Instead, the system should have the capability to detect (in an early stage) and eliminate bad behavior that emerges.

• Managerial independence of the elements The constituent systems not only can but do operate independently, even while being part of the SoS. Further, elements can be added individually to the SoS.

• Evolutionary development The SoS does not appear fully formed, and functions and purposes are added based on experience.

• Geographical distribution The constituent systems only exchange information and not substantial quantities of mass or energy.

• Secure and safe Malicious behavior in an SoS and its constituent systems must be detected and mitigated to ensure information, system and SoS integrity.

2.3 Solution engineering

The knowledge and experience of complex automation engineering is currently guided by a number of engineering standards, e.g., ISO 81346 and ISO 18828 [21, 22].

In the transition from legacy production architecture, such as ISA-95 [23], to Industry 4.0 architectures, such as RAMI4.0 and IIRA, SOA and micro-service based implementation architectures and platforms were pioneered by Colombo and Karnouskos [24,25,26]. Properties, principles and concepts formulated around SoS have become necessary to consider in the engineering of Industry 4.0 automation solutions.

In this context, we need to reason about capturing SoS fundamentals in an MBSE context; thus far, only a limited amount of work has been conducted in this area. In this respect, a UML-based SOA profile, SoaML, was proposed in 2009 [27]. A number of the fundamental properties and keywords of SOA were not included in the SoaML profile; thus, wide adoption did not occur.

A few SOA modeling approaches were devised in the early 2000s. The service-oriented design and development methodology (SDDM) [28, 29] provides methods and techniques used in service-oriented design and approaches the service development methodology from the perspective of both service producers and consumers. In 2004, IBM announced service-oriented modeling and architecture (SOMA) as its SOA-related methodology. Further details of this approach have been published by Arsanjani [30]. The service-oriented modeling framework, SOMF, was devised by Michael Bell as a holistic and anthropomorphic modeling language for software development that employs discipline and a universal language to provide tactical and strategic solutions to enterprise problems [31].

A recent paper by Urgese et al. [32] provides an automation solution engineering approach that extends the IEC 81346 standard. The approach models both the engineering process and the engineering tool usage in an SOA fashion. Moreover, the approach can be modeled directly using the SysML approach proposed in this paper.

Of the SoS properties listed above, operational independence, belonging, connectivity, diversity, secure and safe, and geographical distribution are potentially captured using modeling languages such as SysML. This paper discusses the SysML v1.6 and v2 approaches, enabling solution modeling of industrial automation and digitalization based on a SOA approach, where several fundamental SoS properties are addressed.

3 Concepts for system-of-systems modeling

In this section, we introduce a conceptual space for modeling complex, hierarchical SoS according to service-oriented principles, as discussed above. More concretely, we are proposing a SysML v1.6 profile for SoS modeling. (The modeling tool used for the current implementation of the profile is Cameo Systems Modeler.²)

The profile is inspired by and validated against the principles proposed in the Eclipse Arrowhead framework. Eclipse Arrowhead provides an SoS architecture approach and a reference implementation platform. The concepts we identify form a general conceptual framework and are intended to be used as reference points for modeling large-scale, dynamic entities in industrial IoT.

The notion of a profile has already been proposed in the UML language [33] and serves as its central language extension and specialization mechanism [34]. In turn, SysML has been conceived as a profile of UML. A profile is a collection of stereotypes, abstract element descriptions, which can be used for fixing the modeling vocabulary for a given (emerging) modeling domain.

Our profile is conceived to support the creation of SOA-based SoS solutions making use of the Eclipse Arrowhead framework and its reference implementation. The profile also makes use of and extends the Eclipse Arrowhead documentation structure [35].

Thus, the profile addresses the following design levels, constituting black- and white-box descriptions of SoS elements. As a convention, those concepts representing a black-box aspect have a Description suffix in their names, while their white-box counterparts end with Design Description.

Specifically, the profile captures the following layers of an SoS:

• service and interfaces,

• systems with producing and/or consuming services, and

• two different abstractions for compound SoS:

  • Local clouds [36] as basic organizational units and

  • Systems of local clouds, i.e., their compositions.

The profile also includes a basic form of design support regarding data exchange properties. The current version of the profile is available in the GitHub repository of the project.

Following the principles of SOAs, the main ingredients of our conceptual space are services and systems. Therefore, we proceed with first introducing stereotypes used to represent services (Sect. 3.1 and then continue with systems stereotypes (Sect. 3.2). Next, we model the concept of local clouds [36] (LCs) and systems of LCs (SoLCs), originally proposed within the Arrowhead ecosystem. The present section concerns the concepts themselves; for their use, we refer to Sect. 4, with a detailed description of the Arrowhead SysML library based on the profile.

3.1 Service stereotypes

Figure 1 shows the three stereotypes (SD, SD-DD and IDD) used for service modeling in our approach, including their connection to the SysML language. (The figure comes from an actual implementation of the profile in Cameo Systems Modeler.)

Fig. 1

Stereotypes for describing services

The connection to SysML is represented by the box in the upper left, representing the Interface Block, one of the central meta-classes of SysML. An interface block, as the name suggests, is typically applied for entities representing communication or exchange interfaces between other entities (systems in our case). Therefore, it is a perfect fit for expressing service-related concepts in a service-oriented SoS model.

We distinguish between two abstraction levels: SD (Service Description) is the abstract unifying concept for services, as generally understood according to the SOA paradigm (cf. Sect. 2.1). In our setting, an SD is a general description of some functionality or data service (e.g., temperature measurements), which can be either provided or consumed by systems.

While an SD represents a black-box perspective on services, its SD-DD (Service Description–Design Description) counterpart captures the realization of a service as it is actually provided (or consumed) by a system.

The actual communication then happens via interfaces, which are represented as IDDs (Interface Design Descriptions), i.e., refinements (specializations in UML terminology) of SDs, also providing information on communication details, allowing actual communication to occur between a provider-consumer pair of systems. Here, the applied security, usage of encryption, compression, encoding, etc., are defined, along with the applied payload data model. Instances of IDDs would typically appear as contained in an SD-DD and be interpreted as actual interface endpoints belonging to single operations of an overall service definition.

3.2 Systems stereotypes

Figure 2 shows an overview of the rest of the concepts presented in this paper, namely stereotypes concerned with systems and compound entities based on them, local clouds as well as systems of local clouds.

First, note that the aforementioned concepts also constitute a three-layer composition hierarchy, as represented by the composition links (the black diamond-headed lines) between them from the top to the bottom. As for the horizontal classification, the organization of these concepts, again, follows our principle of providing black-/white-box pairs for each composition layer. As shown in the upper-left corner, each system stereotype is a specialization of Block coming from the SysML language, being its central, general stereotype.

Fig. 2

Stereotypes for describing systems and (systems of) local clouds

In the remainder of this section, we describe the system stereotypes, i.e., the elements in the bottom layer of Fig. 2.

The SysD (System Design) stereotype represents a black-box view of systems, i.e., it can be considered a generic template for (the software behavior of) a given system type in the SoS that we want to model.

In turn, the SysDD (System Design Description) stereotype represents a white-box view of systems, resulting in higher precision regarding the details of the behavior. Note, however, that these system stereotypes can be used hierarchically; i.e., there are no strict constraints on how much information has to be provided in a single SysDD, and the amount of information can be refined in further specialization blocks.

A very important, even central, usage of SysD and SysDD blocks is to hold ports (which are, again, basic SysML elements), i.e., connections with the outer world. However, in SysML, the exact interpretation of a port is left to the modeler. The interpretation in our profile is that a so-called full port is typed over an SD, representing an overall service provided or consumed by that system, while the individual interfaces of that service are modeled by IDD-typed proxy ports contained in that full port.

3.3 Stereotypes for local clouds and systems of local clouds

In this section, we elaborate on the four stereotypes remaining in Fig. 2: the pair consisting of LocalCloudDesign and LocalCloudDesignDescription (middle layer), as well as the System-of-LocalClouds-Design stereotype, together with the System-of-LocalClouds-DesignDescription (upper layer).

The concept of a local cloud [36] has been proposed in the context of Arrowhead; however, it constitutes a general-purpose organizational principle for SOA-based SoS. A local cloud is an SoS instance, where the partaking systems have a certain level of trust toward each other, enabling a more direct orchestration mechanism between them, while at the same time, the local cloud also implies a logical grouping of its constituents. (For a concrete example, cf. Sect. 6.) As expected, the LocalCloudDesign stereotype corresponds to other Design stereotypes and serves as their logical container, while the LocalCloudDesignDescription is a more detailed entity with a white-box view on design details, as represented by other Design Description stereotypes within.

Finally, the most large-scale entities in our modeling domain are the Systems of Local Clouds. Such dimensions and scenarios are the final goal of industry-scale IoT endeavors: the envisioned level of automation and autonomy is achievable only by a coordinated, yet adaptive interaction on a global scale. In our setting, this is expressed by the SoLC level: an SoLC is also an SoS instance, having a compound, more global nature. The communication between the clouds has to follow strict rules; therefore, an SoLC has a different operational nature than that of a single local cloud, despite the structural analogy. As expected, the two different stereotypes associated with systems of local clouds serve as high-level containers for the respective black-box and white-box designs of their constituents.

4 Arrowhead core system library

The profile described above has been used to create library models of a number of the core systems of the Eclipse Arrowhead framework.

Fig. 3

SysML model of the eclipse arrowhead ServiceRegistry system

Fig. 4

Left: the SysML model of a basic SoS modeled as one local cloud including a number of the eclipse arrowhead core systems. Right: a system of local clouds (SoLC)

An example of such a core system model is the Eclipse Arrowhead ServiceRegistry system. The model is shown in Fig. 3. The currently available core system models for enabling SOA solution architecting and implementation are as follows:

• ServiceRegistry system

• Orchestration system

• Authorization system

• SystemRegistry system

• DeviceRegistry system

• Onboarding system

• CertificateAuthority system

• DataManager system

• Translation system

• EventHandler system

• QoS (Quality of Service) system

• TimeManager

• GateKeepeer system (intercloud Lookup, Late binding and Authorization)

• Gateway system (intercloud secure service exchange)

• OPC-UA adaptor

• Z-wave adaptor

• MQTT broker

• LocalCloud

• System-of-LocalClouds

• Generic-application system

• Device; capable of hosting multiple systems with physical network port/s

• Network; defining the physical network layers used by Device network ports

The profile and the library enable us to design and model complex automation and digitalization solutions. A generic example of a modeled SoS use case is shown in Fig. 4. Here, a single local cloud is modeled with the Eclipse Arrowhead core system. A protected solution is created within one local cloud with SOA lookup, late binding and loose coupling properties, as implemented by the Arrowhead ServiceRegistry and Orchestration systems. Authentication and authorization security is implemented through the Arrowhead Authorization system. The required automation functionality can then be modeled as a set of application systems and their interaction with the available core systems. Application system modeling is supported through a generic application system template. Solutions using multiple local clouds are also modeled and shown in Fig. 4.

The current version of the library is available from the GitHub repository of Eclipse Arrowhead https://www.github.com/eclipse-arrowhead

The validation of the profile and the library is based on a concrete industrial automation use case, described and modeled in Sect. 6.

5 Standardization: toward next-generation systems modeling

5.1 Introducing SysML v2

SysML v2 is the emerging next version of SysML. SysML was introduced in 2005, and it seems appropriate that a successor would appear to account for the technological developments in the past 15 years. The standardization of SysML is performed in the context of OMG (Object Management Group) that also provides a number of other model-oriented technologies, such as UML [33]. The process is open in the sense that there are no restrictions on becoming a member of the OMG, but the process is not public since until the technology is available, the documents may be kept for those members that participate in related consortia. For SysML v2, however, the large consortium (and there is only one consortium in this case) has decided to make the evolving pilot implementation with documentation open source. This has made the SysML v2 process more transparent to the general public [37].

The pilot implementation is important since it represents an opportunity to experiment and a solid basis for discussion. Most discussions occur in subgroups of the large consortium, which now includes more than a hundred individual participants and close to a hundred organizations.

The development of SysML v2 has been a well-managed process in which the requirements of the new version of the language were collected and systematized in a request-for-proposals. The satisfaction of these requirements is meticulously monitored by applying the pilot implementation.

However, there were few requirements in the field of SOA. To take advantage of the new SysML v2 to support Arrowhead, we would need proper constructs to describe SOA; therefore, we proposed to provide a validation use-case in the field of SOA based on the Norwegian industrial use case in the project Productive4.0 [38], where communication is handled by Arrowhead. This scenario has turned out to be fruitful for several discussions since the example is manageable and originates from a real case in industry.

5.2 The descriptive needs of the arrowhead framework

Taking the SysML Arrowhead profile as starting point and the Norwegian Productive4.0 use-case as an example [39], we investigated how SOA could be described with the emerging SysML v2. We found some issues with describing SOA in general since there have not been many requirements originally recorded in that field, and we found that when drilling down into the details, there were other issues related more directly to Arrowhead.

• Representing a remote method call where the requiring party waits for the provided service to be performed and results to be returned.

• Sufficient information described for asynchronous signal sending and reception, potentially through a subscribe/publish approach.

• Visualization of SOA protocols with sequence diagrams where the detailed communication points appear.

These issues may at first glance appear obvious and to be topics that have been included in earlier versions of SysML version 1 and UML version 2, but this is only partially correct. SysML v2 is constructed from scratch on a foundation (KerML) that provides more precision with formal semantics. Thus, the language is not simply an enhancement of SysML v1 even though it should cover the same purposes and more. Therefore, our Arrowhead requirements must be documented with a proper rationale, such that Arrowhead and its use cases are credible grounds for discussion.

Moreover, even though operation invocation is included in UML 2, it has not been straightforward to apply operations. Built on UML 2, the SoaML profile never achieved a large audience. Therefore, our aim with SysML v2 is to cover SOA concepts in a straightforward manner and not fall into the pitfalls of the past attempts.

In September 2021 SysML v2 presented their “Revised Submission” for the OMG Technical meeting. Even though our Arrowhead needs have been on the agenda for over a year, the language still has no proper support for remote method calls. The asynchronous communication is taken well-care of, and the remote procedures can be modeled through signaling, but we want more native concepts. Hopefully, this will be doable before the final submission intended for early 2022. Basic sequence diagrams are in place, and the major improvement is that the sequences will be based on the same semantic base as the other language concepts of SysML v2. In UML 2.0 sequences, activities and states had different semantic definitions and consistency was hard to prove.

5.3 The arrowhead language extensions for SysML

SysML v2 may not receive the same kind of extension constructs as we know from UML profiles, as given in Sect.  3, but rather promises a stronger language extension mechanism inspired by how SysML v2 is built on the KerML kernel language. The big advantage is in the potential to establish a domain-specific language (DSL) based upon the SysML v2 constructs and tooling, in addition to defining the proprietary language constructs’ semantics in terms of KerML and SysML libraries. We believe that Arrowhead is the perfect candidate to implement such a language extension mechanism, and we have already performed an experimental simulation of how this could look and be defined.

5.3.1 Language extension for arrowhead in SysML v1

In UML and SysML, we apply “profiles” that define extensions of the UML or SysML basic concepts. Typically, such “stereotypes” are given meaning through code generation by the community that supports and applies the defined profile. We have defined a SysML v1 profile for Arrowhead, as shown in Figs. 1 and  2. The profile defines the basic concepts of Arrowhead, and their semantics are given by the explanation found in the Arrowhead documentation. The implementation of the profile is given by the tool providers that support the profile.

Eclipse Arrowhead also contains Arrowhead systems and services that are already developed by the open-source community, and there is a SysML v1 description of these systems and services in the form of a model library based on the profile. Excerpts of our core library are shown in Fig. 3.

5.3.2 Language extension for arrowhead in SysML v2

In SysML v2, the precise semantics refer to a basic library of concepts of execution defined by the new language KerML. Thus, the whole language semantics are built on a core library, and extensions of the concepts are defined by specializing the core concepts and redefining and subsetting the properties. This technique is well-known in object orientation but has not previously been applied as systematically as in SysML v2 [40].

We also apply this technique to tailor Arrowhead to SysML v2, and the Arrowhead profile becomes an Arrowhead Profile Library, as shown in Fig. 5.

Fig. 5

SysML v2 arrowhead profile library

Fig. 6

SysML v2 arrowhead core library (excerpts)

The Arrowhead Core library is built upon the profile library and corresponds very closely to SysML v1 description of the core systems. In Fig. 6, we focus on the Service Registry, as we did in Fig. 3. We have added some colors to show how the Arrowhead core concepts are inherited from the profile library. The service_registry (light blue) is the Arrowhead system of type SysD concept of the profile library and subsetting the set of systems defined within the LocalCloudDesign.

The service_registry defines its service serviceDiscovery (green) as a port of type ServiceDiscovery, which is inherited from library concept SD, and is a subset of the services of the SysD concept of the profile library.

This shows the design level of the core system service_registry. Now we apply the same mechanisms of inheritance, subsetting, redefinition and typing to specialize the detailed description from the design descriptions.

The service_registryDD (darker blue) is subset from service_registry, and it redefines the serviceDiscovery port to be of the type ServiceDiscoveryDD that is inherited from ServiceDiscovery, and profile type SysDD. More detail is added by a couple of nested ports representing the different protocols that can be used to communicate with this service. These nested ports (yellow) subset the idd (typed by IDD) defined within SDDD.

5.3.3 An arrowhead domain-specific language based on SysML v2

Even though the principles of specialization in SysML v2 originates from object-orientation, their application may still be slightly complicated for the creator of Arrowhead systems-of-systems. This is why we apply the profile terms in SysML v1, but SysML v2 will have an even better way to define language extensions using the library concepts and the general specialization mechanisms.

In Fig. 7, we show an excerpt of the SysML v2 definition of the core system library corresponding to Fig. 6 plus a mock-up of what that definition could look like with the generalized language extension.

We shall go through the principles by referring to the example in detail. On the very first line, we have “#service def ServiceDiscovery” in our Arrowhead notation corresponding directly to “port def ServiceDiscovery :>SD” in the plain SysML v2. This example shows how we explain the #service concept by specializing the “SD” port definition in our Arrowhead library. This is the exact same approach as that used by the whole SysML v2 language to define its semantics and is therefore possible to accommodate without unwanted side effects. Similarly, subsetting is applied for usages, as can be seen further down in the line “#localcloud ArrowheadCore” which is a usage of an Arrowhead local cloud containing a set of systems, and usages of systems are defined by “#system” keywords, and the inheriting of the SysD library concept is included in the definition of the system concept.

The SysML v2 concepts used for specialization and for all other needs can be used without restrictions.

This simple mechanism may seem like “syntactic sugar” and it can be viewed in that way, but one should not underestimate the usefulness of directly applying terms of the domain. We may also include constraints in the definitions of the #-keywords restricting the concepts even more. Moreover, ongoing work is investigating how this domain-specific notation can be visualized via domain-specific graphics similar to our Arrowhead notation shown in Fig. 8. In this way, the Arrowhead domain and use of service-oriented architecture becomes visually intuitive, corresponds directly to the Arrowhead methodology and is defined precisely through the same principles as the SysML v2 language itself.

We contribute to standardization to ensure that the modeling means of tomorrow fit our Arrowhead framework. Through active participation, some of our proposals will be included in SysML v2, but we cannot expect all our desires to be satisfied in the first version of SysML v2 for several reasons. SysML v2 has many requirements, and our focus is not the same as everyone else’s. SysML v2 will be used for a variety of systems that will not apply SOA. Therefore, some Arrowhead concepts may not be possible to include, and they may also be difficult to express with the extension mechanisms indicated in this section.

Fig. 7

Services in arrowhead DSL compared with plain SysML v2

6 Chemical factory validation use-case

In Productive4.0 [38], we used Eclipse Arrowhead as the vehicle for integrating the chemical use-case performed by the Norwegian consortium at Unger Fabrikker³. The chemical use case focused at first on reducing the time between products and thereby contributing to both less waste and higher productivity. The chemical production goes on continuously 24/7, but in this chemical plant, they make several specialized niche products and there is a need to roll over from one product into another one. Between products there is a phase where no actual product is produced and such production needs to be handled as waste. By applying machine-learning and a new non-intrusive NIR (Near Infra Red) sensor, we were able to make predictions such that the process could be tuned quicker and waste reduced.

During the project we also introduced two other use cases associated with the chemical production. On use case concentrated on improving the supply deliveries of lye and sulfur by providing the suppliers with more online information about the states of the tanks and what was expected to be used. From this, the suppliers could themselves decide when they wanted to deliver the raw material and thus improving their own logistics as well as taking some work off the purchasing staff at the chemical plant.

Finally, we also did some experiments on the product deliveries to investigate what could be the source of accidental lumping of a powder product when transported over longer distances in Europe by truck. We instrumented the big bags of powder with sensors for acceleration, temperature, humidity and location and could follow and store these data online.

Supporting all of these three use cases of the chemical plant was a data communication structure that involved several different platforms, different hardware, and the need for physical and logical firewalls with security. The sensor data from the NIR sensor was collected by the APIS system from the partner and sensor vendor Prediktor⁴ and the data from the sensors in the big bags of powder was collected via the TellUCloud gateways and software by the partner TellU⁵ before this was also placed in the APIS system before communicated to the chemical plant hub.

The unifying framework for this communication between these different platforms was the Eclipse Arrowhead. We added adaptors and analysis applications to the framework, and also took advantage of the built-in registration, orchestration and security properties. For our presentation in this paper, we have in in Fig. 8 simplified the system to highlight the unifying principles of the Eclipse Arrowhead.The real use-case is of course more elaborate [39], but the simplification demonstrate the main issues that we cover in this paper. We show the asynchronous communication between the APIS Producer and the APIS Consumer throughout the MQTT broker. We define how the data from the TellUConsumer is communicated to the APIS Producer. The complexities in the real data and the definition of the adaptors have been omitted here since this is more associated with the proprietary use-case than the open-source Eclipse Arrowhead.

Fig. 8

Simplified chemical use-case

Fig. 9

Chemical use-case modeled according to SysML 1.6

A piece of the SysML v1.6 model of the use-case is shown in Fig. 9.

Excerpts of the corresponding SysML v2 model from the current pilot implementation is shown in Fig. 10 in its textual form. Due to current limitations of the pilot implementation, all communication is defined asynchronously.

Fig. 10

Excerpts of the chemical use-case model in SysML v2 textual

Fig. 11

Normal message flow of the chemical use-case

SOA is not only a composite structure architecture with communication connections but also the behavior in terms of the protocol of messages transferred between the parts. In Fig. 11, we see the normal flow of messages in the simplified chemical use-case. Here, we show synchronous communication between TellUConsumer and APISProducer applying remote method calls as we want to achieve in the future. On the right side of the sequence diagram, we see the communication between the APISProducer and the APISConsumer using asynchronous signals using the publish/subscribe protocol MQTT via MQTTserver. All together the information passes from left to right, and this is repeated in a loop. The lifelines show the participants in the communication with details on their ports and nested ports defining the details of the data transfers. Please refer also to Fig. 10 for details of the communication and see that it is consistent with the sequence diagram for the asynchronous communication. Basic sequence diagrams are also now included in SysML v2.

7 Discussion: alignment with SOA and SoS principles

Given the basic properties of SOA/micro-service architecture and SoS provided in Sects. 2.1 and 2.2, in this section, we analyze which of those properties are captured by our proposed SysML modeling approach, as summarized in Table 1.

The SysML modeling of SOA and micro-service-based architecture can fulfill several and, eventually, most of the fundamental SoS properties discussed in the literature. A minor use-case validation of this has been performed in Sect. 6. The detailed outcome is further commented on in Table 1.

8 Conclusion and future work

With the ever-growing presence of IoT-based solutions in the industry, there is an increasing need for well-founded system design solutions to address novel challenges. Between rigorous systems modeling on the one hand and the expected level of autonomy and self-organization on the other hand, SOAs have been investigated as a promising bridge concept.

In this paper, we have presented an MBSE approach to model SOA-based SoSs, relying upon SysML, the standard MBSE language, investigating both its established baseline version, v1.6, and its upcoming new major release, SysML v2. We have presented a SysML profile (v1.6), its application to model the Eclipse Arrowhead ecosystem, and our proposed concept for adapting our ideas into SySML v2, along with a comprehensive, real-life industrial case study. We have also discussed the alignment of our concepts with the generally accepted SOA and SoS principles from the respective communities.

As for future investigations, on the conceptual side, we aim to extend our conceptual framework with an adequate representation of SOA-IoT deployments, allowing for a tighter integration with real-life Arrowhead installments. On a more practical note, we aim to experiment with different, potentially cloud-based modeling environments to increase the accessibility of our approach.

Table 1 Analysis of SOA and SoS properties modeled by SysML v1.6 and SysML v.2