Keywords

1 Introduction

Today, several strategies are already available to implement the digital transformation processes. However, the support for a coordinated and collaborative effort for participative contributions is still lacking. Furthermore, a significant challenge is the need to update legacy systems while maintaining their proven reliable features. Whenever the changes required to migrate legacy systems compromise the system's quality, alternative strategies must be adopted. In this context, the SITL-IoT project [16] develops an open technology infrastructure for the industry agri-food sector adopting a System of Systems (SoS) framework that integrates Internet of Things (IoT) elements (a kind of IoT Bus).

Extensive work has been done regarding IoT and its corresponding platforms at different levels. One pragmatic perspective relates to connecting simple sensors through radio frequency links based on protocols like Sigfox, LoRa, and NB-IoT, popularized as low-power wide-area networks (LPWAN) [11]. More recently, the LPWAN networks got the attention of cellular phone networks and Internet providers to establish a unified WAN for connecting any device with sensor/actuator, computing, and communication capabilities. Communication between things based on limited resources often adopts LPWAN and machine-to-machine (M2M) connection, complemented by 4G LTE technologies. Lately, 5G seems to show a convergence between M2M IoT device communications and personal communications with enhanced quality [6]. This unification seems essential for cases where things cross local LAN domains, and public communication infrastructure is necessary. An extensive survey on 5G IoT [10] confirms the trend of highly available and reliable 5G wireless communications connecting IoT devices or systems. However, the IoT devices or systems do not exist in isolation, and there is a need for some framing strategy, making clear the responsibility for their lifecycle management.

The focus of our research is how to get things to be “plugged” as elements of a computing system, rather than IoT connections or the convergence between wide and local networks. Following a similar direction, the Ethernet Time-Sensitive Networking (TSN), as discussed in [7], emphasizes the convergence of Information Technology (IT) and Industrial Operations Technology (OT) as a trend-making towards open data exchange between the operations field and the enterprise systems, which is referred to as Industrial IoT (IIoT). There is some tendency to establish the concept of an IoT Bus as a facilitator to seamlessly merging specific protocols, e.g., OPC-UA, towards a symbiotic industrial technology landscape, which can be modelled as a system of systems where IoT devices plug as services. As suggested by other authors [7], both legacy communications and legacy systems need to evolve in such a way that current “manufacturer lock-in” conditions do not force the acquisition of new devices.

This paper presents a strategy to represent IoT devices in the cyber-space as services and their application to the migration of an existing legacy system named FORSIL. Under the proposed approach, the FORSIL system evolves to a combination of two systems: (1) the ISysFORSIL-PROC, responsible for the silos processes automation, and (2) the ISysFORSIL-MON, responsible for monitoring the ISysFORSIL-PROC services. The migration strategy is based on the ISoS framework [15] and consisted of revisiting the legacy FORSIL architecture towards a new modular structure. One important motivation for adopting the ISoS framework was its readiness to support collaboration processes between the silos infrastructure and its business agro-food industry partners. As any informatics system (Isystem) in the ISoS framework can be accessed both from inside and outside the organization, based on a canonical interface named I0, collaborative exchanges can go through direct invocation of the ISystem services. In other words, without the need for heavy changes, implementing service abstraction enables wrapping the legacy technology and make it evolve to comply with the ISoS pattern and, in this way, participate or plug to the adaptive IoT Bus.

The paper is organized as follows. Section 2 presents and discusses the SITL-IoT challenge for an open IoT Bus for the agro-food silo infrastructure. In Sect. 3, we clarify the IoT Bus design in the context of the ISoS model. Section 4 extends the discussion into a collaborative space, where networked organizations need to access services for business collaborations. Finally, Sect. 5 presents the main conclusions of our research work and outlines the open research challenges.

2 Collaboration Challenges in the SITL-IoT Industry Case

Current approaches to structure computing artifacts do not follow any kind of common and generic reference model or strategy. As a result, products developed by different companies usually adopt custom solutions that quite often result in proprietary architectures. The legacy FORSIL product from the FORDESI company also followed this approach. FORSIL is an enterprise software system composed of technical parts organized within a computing responsibility. Such monolithic technology solutions present fuzzy “responsibility borders”, which makes it difficult to establish accountability decisions. Those less clear responsibility borders make IT governance a complex endeavour. Such modular monolithic systems, even if agile and possible to integrate with any other system, require the development of specific adapters.

The SITL-IoT project was motivated by the will of the FORDESI company to make FORSIL evolve towards an open IoT Bus, combined with cloud services [16]. The challenge was to (re-)structure the legacy FORSIL to make its functionalities available to other enterprise systems, both from internal and external business partners. It is interesting to identify that depending on the viewpoint of the researchers, adopted approaches emphasize either what is known as enterprise systems or the production infrastructure, where the notion of “things” prevails. An example of the second perspective is the proposal of an IoT platform as a “piece of software that works like a kind of “glue” to combine platforms and orchestrate capabilities that connect devices, users and applications/services in a “cyber-physical world” [18]. Such an idea is quite similar to the Enterprise Service Bus (ESB) concept since it combines a suite of adapters to integrate microservices [4]. However, adopting a centralized integration strategy, either an IoT platform or an ESB as an integration hub, leads to dependencies from a single responsibility or single vendor. Therefore, the proposal in [4] considers a Service Oriented Architecture (SOA) and microservices under a similar rationale. Commonly both SOA services and microservices are widely discussed as capable of abstracting independent computing entities. At the same time, the microservice concept often tends to be associated with the cloud.

When the goal is to achieve integrated process automation in complex heterogeneous collaborative contexts, one major challenge is establishing a systemic structuring strategy capable of incorporating multi-vendor and/or multi-supplier contributions while maintaining confidence in the system as a whole. Like other application domains, the SITL-IoT project addresses a critical scenario where the adopted technology arrangement needs to be reliable, as discussed in [17]. Any failure potentially harming a business function needs to be accountable for direct responsibility. However, the association of accountabilities is not simple to determine in the current diversity of technology structuration approaches since they are based on mappings between specific architectures. When integration is required, the inclusion of diverse technology architectures faces the lack of a “unified model” where independent contributions still lead to a consistent system. More than its parts, such a uniform system requires a suitable strategy to manage the various heterogeneous contributions under the same coordination and operation model. Research on integrating heterogeneous models [2] suggests the implementation of five phases: (1) pre-integration assessment, (2) preparation of models for integration, (3) orchestration of models during simulation, (4) data interoperability, and (5) testing, addressing both the physical world and enterprise business processes. Often, the discussion of interoperability does not seem to cope with the integration pressure of the digital transformation. As suggested in [12], “… we need formalization of interoperability grounded in the general system theory: the Ontology of Interoperability (OoI) …”, for instance, based on the CEN/ISO-11354 Framework for Enterprise Interoperability standard.

To contribute to this open challenge, we suggest an alternative approach that considers that, even when maintaining diversity, we need some kind of “reference framework” to model the resulting transformed system. Hence, our approach is focused on finding a balanced model for the “digitally transformed system” where independent computing responsibilities collaborate under pre-established conditions, preferably based on open standards. The strategy for such collaboration among sub-systems shall be similar, both when addressing the physical world or the automation of enterprise business processes.

3 The ISoS Model and the Open IoT Bus

To tackle the above issues in the context of the SITL-IoT project, we adopted the ISoS framework [15] as a “glue”, nonintrusive, integration reference model. The ISoS abstraction plays the role of a registry for the enterprise informatics systems (ISystems). A particular ISystem0 operationalizes the registration of any enterprise ISystem. The ISystem concept is simply a composition of Service elements, and these are, in fact, the executive entities. The Service concept refers to an independent and possibly autonomous computing entity, representing some computational responsibility. By computational responsibility, we mean the answer to the functional and the non-functional requirements through a set of capabilities. If other Service entities need to access some Service computing capabilities, the interoperability realization is in the associated metadata.

Therefore, the ISoS concept aims to establish a unified model for the enterprise system's architecture. By adopting the ISoS framework, we unify what [9] calls Application Architecture specific for each enterprise system supplier or integrator. The heterogeneous application domains comprise computing-related technology ranging from enterprise systems, which we model as an ISystem, to IoT devices with minimal computing capabilities, which we mimic as a Service entity. For example, when an IoT device is a simple sensor or actuator with minimal computing capabilities, the Service entity can be the gateway responsible for the communication with the device.

Figure 1 depicts a simplified view of the validation case with a Silos located in Leixões (SDL). Two cyber-physical systems (CPS) comprise a programmable logic controller (PLC) coordinating temperature sensors in the silos and truck weighing bridges. The CPS computational parts (a kind of digital twin) are modelled as a Service registered into the ISystem0 as SerTemperature for the temperature subsystem and SerWeighingBridge for the weighing bridges. Both SerTemperature and SerWeighingBridge are computational wrappers abstracting the interactions with the legacy physical equipment since they do not yet embed the ISoS Service entity.

Fig. 1.
figure 1

A centralized approach to IoT Bus

Full size image

Furthermore, Fig. 1 refers to a centralized approach to integrating IoT services. The model considers a classic technique where a kind of Enterprise Service Bus (ESB) manages the access to the IoT services [5]. The centralized IoT Bus is operationalized by a message broker service, in this case, implemented by the message-oriented middleware (MOM) RabbitMQFootnote 1 and the events management SerEVS. It is worth mentioning that (i) the message broker (CesEVS) and its services, and (2) the IoT services, all must be registered at the ISystem0. Any Service entity registered at ISystem0 makes us question the need for the intermediary CesEVS. Depending on the problem domain constraints, e.g., if a reliable messaging mechanism is necessary because IoT events cannot be lost, having an “intermediary” approach is an option. However, an alternative is to embed the IoT service with messaging capability and enhance the implementation with event subscriptions and other features, thus avoiding intermediary entities. Instead of adopting such a decentralized architecture, if IoT shares some advanced features, then the CesEVS mediator must be considered. A mediation strategy is also proposed in [14] for predictive streaming data processing for real-time context-aware microservice actions. Within ISoS, such mediation services can be grouped as part of a CES in a similar organization of the implemented CesEVS.

To clarify the architectural options to structure the technology artifacts that are ISoS-enabled, in Fig. 2, we depict the approach that considers reliable IoT services embedding messaging middleware features. The CesEVS component is removed, and the services SerTemperature and SerWeighingBridge are enhanced with messaging and event management features.

Fig. 2.
figure 2

A decentralized approach to IoT Bus

Full size image

It is worth mentioning that depending on the application domain, the possibility of changes to legacy systems, and reliability or dependability issues, among other aspects, the ISoS architect can decide by alternative options. Furthermore, the ISoS model accommodates offering services under both centralized and decentralized models.

According to the ISoS model, everything is an abstract ISystem, an abstract CES, or a specific Service implemented in any technology. The Service artifact models any computational entity regardless of its complexity or size. Compared to a microservice, the ISoS Service concept does not imply any size or complexity restriction nor imposes an interaction protocol. A primary challenge addressing legacy systems is to make them evolve for multi-supplier technology composites, reducing vendor lock-in problems [13]. The ISystem, CES, and Service are the ISoS constructs where a Service abstracts a single computational responsibility regardless of its size.

4 The SITL-IoT Collaborative Contexts

The Silos of Leixões (SDL) organization collaborates with agro-industry factories (denoted as FACT), managing the trucks transporting the cereals from the silos to their infrastructures. The coordination of such transports requires the ERP at a factory to interoperate with the ISyFORSIL-PROC at SDL. This kind of interdependency is growing fast as organizations move to digital and automate their business processes, i.e., internal processes and those managing actions or events from business partners. These interdependencies, typically addressed under the Collaborative Networks perspective, are challenging since the state of such interactions relies on specific adapters that are difficult to maintain and evolve [3, 17].

To address the SITL-IoT collaboration needs, we consider two complementary strategies. The currently implemented approach considers the ISoS I0 interface offered by the ISystem0 of any ISoS enabled organization to access any implemented service. A complementary approach considers the adoption of the ECoNet collaborative network infrastructure introduced in [17]. We first discuss the direct access through the ISoS I0 meta-services, followed by adopting ECoNet.

Collaboration Through the ISoS I0 Meta-service.

Internal services of an organization implementing the ISoS framework access the meta-service I0 to locate other services. Furthermore, any business partner organization can also access the meta-service I0 with the required authentication to access authorized internal services. In the current reference implementation, the ISoS I0 meta-service is located at the address endpoint isos. <organization domain>:2058 as a simple REST interface. However, even without adopting ISoS, any organization can access a computational service of an ISoS enterprise with ISystem0 running on the isos. <organization domain> server, by default at port 2058. Figure 3 depicts the SITL-IoT case where an ERP from a business partner we identify as FACT (some agro-factory) needs to access services at SDL.

Fig. 3.
figure 3

Business collaborations between SDL and FACT organizations

Full size image

The advantage concerning the current point-to-point specific adapter interactions where the client computing service needs to know a priori the location of the peer service does not happen with ISoS. In the current approach, if, for some reason, the target service location changes, the calling business partner might face a failure if business partners did not update the new endpoint. As depicted in Fig. 3, a service of ISyERP accessing, e.g., the SerEVSWebAPI, first lookups for the service at SDL ISystem0 (ISy0) and retrieved meta-data to access the target service. We assume that at SDL, any change that occurs in any internal service the ISy0 updated.

It is worth mentioning that ISystem0 tends to play technology landscape operations and governance roles. Therefore, the model considers any independent or atomic computational entity, the Service concept, to behave according to ISoS principles.

Collaboration by Adopting ECoNet.

The SITL-IoT collaboration needs could also be successfully fulfilled by adopting the ECoNet Collaboration infrastructure [17]. However, using this infrastructure requires centralized coordination of the data and control exchanges. As depicted in Fig. 4, there is a single direct interaction between services in both organizations in this alternative approach, likewise in the implemented solution illustrated in Fig. 3. However, with ECoNet, the interactions occur exclusively through a special ISystem responsible for all the collaboration processes - the Enterprise Collaboration Manager (ECoM) - and its specific application domain, Collaboration Contexts (CoC).

Fig. 4.
figure 4

Business collaborations through ECoNet

Full size image

Compared to the first approach, where interactions go through the I0 interface of ISystem0, low-level communication and security protocols and mechanisms are shared across the ECoNet network. Furthermore, the ECoM implements the concept of Virtual Collaboration Contexts (VCC), making it possible for any ISystem to establish virtual groups of collaborating organizations. As a result, Service entities can access ECoM services to create or join a VCC and manage through CoC, multi-tenant collaboration spaces, for data and control exchanges. The advantage of adopting the CoC concept is that data exchanges in the same specific application context, e.g., transport management of agro-products from/to silos infrastructure, can be shared by an ERP, invoice management, or other informatics systems.

The migration of the legacy FORSIL product to the ISoS framework demanded the (re)thinking of its original monolithic architecture. Tightly coupled parts must be reorganized as independent Service elements. Structuring FORSIL as a composite of Service elements demonstrates the advantage of supporting the coexistence of alternative implementations for accessing implemented functionalities. As discussed, the mediation implemented by the CesEVS services composite and the integration of the mediated services as part of the IoT Bus introduced alternative interoperability mechanisms for the internal and partner organizations' informatics systems. Another significant result of the SITL-IoT project is the practical demonstration of the added value of the ISoS concepts in constructing an agile and adaptive IoT Bus made of independent Service elements managed through the ISystem0.

5 Conclusions and Further Research

In this work, we present and discuss a strategy to address the open IoT Bus formulated by the SITL-IoT research project in a partnership with the FORDESI company. From simple sensors and actuators through devices with computing capabilities and cyber-physical components to enterprise systems or (applications), different perspectives of the IoT concept are discussed towards a definition for the SITL-IoT project. Accordingly, the adoption of the ISoS framework is presented and discussed, following the evaluation of integration strategies for multi-supplier heterogeneous computing artifacts. Finally, the adoption of ISoS also considers the validation of a reference implementation for the ISystem0 of the SDL organization as a strategy to validate services developed by FORDESI and incorporating their FORSIL-PROC product.

The collaboration dimension considers the adopted approach based on direct interactions between Services in the involved organizations, which are accessed through the ISystem0 canonical I0 interface. While presenting the advantages of this approach compared to the commonly used point-to-point interactions supported on specific adapters, the adoption of the ECoNet collaborative infrastructure is also discussed.

Although the migration of the FORSIL product to comply with the ISoS framework was revealed to be quite promising, further research is necessary to consolidate the adoption of the proposed adaptive integration framework by other companies. The adoption of the ECoNet also needs further research, in particular the use of the ECoM ISystem for managing virtual collaboration contexts supporting critical business processes.