Keywords

1 Introduction

Industrial companies are facing complex challenges to adapt their sensor/actuator and computing systems to new business models to maintain competitiveness. The fast move towards digital transformation, pulled by retail, social and media companies (e.g., Amazon, Facebook, Netflix), as well as the objectives highlighted by Industry 4.0, put pressure on traditionally conservative industrial systems not only to adhere but also to evolve their technology landscapes to offer advanced management and operations intelligence. However, such trend is complex and difficult to make effective since current approaches still lack a clear systemic structuration. In fact, such traditional approaches consider the incorporation of software parts to improve specific features of a system or the development of independent applications to automate specific processes, without a well-founded systems’ engineering approach. Hence, there is an urgent need to evolve towards a systems’ thinking paradigm, in order to be able to effectively develop complex composites of collaborative components.

In this paper, we address the challenges faced by a maritime terminal silos operator when deciding about the strategy to integrate multi-supplier things following the Internet of Things (IoT) trends [4], owing both to the legacy of its current solutions and the expectations of an agri-industry silos concessionaire. Such legacy solutions lack an automatic procedure for the loading of trucks for the transport of bulk products from silos conveyor structures to factories or intermediary logistics infrastructures that is able to smoothly cope with complex collaborative interactions. The challenge is how to structure such cyber-physical components into manageable systems so that they can be part of more complex systems or system of systems (SoS) [19].

The main expectation of this project, named SITL-IoT, is to develop a technology strategy evolve to a higher integration level of legacy and new technical systems. An utmost challenge is how to organize such complex technology systems/elements into integrated vendor agnostic and reliable composites or aggregations. By composites, we mean elements of a system under the same responsibility domain (e.g., from a single vendor or integrator). By aggregation, we mean an agreement between responsibilities under different responsibility domains. Aggregation is important to reduce the governance risks of existing computing related technology landscapes [3]. As a contribution to modularity abstractions, we consider the concept of “informatics system” as a composite of computing centric elements, establishing a well-bounded responsibility. We consider a cyber-physical system as a composite of computing and physical interacting elements involving contributions from Informatics Engineering and Electrical Engineering [9].

In another dimension, the SITL-IoT project addresses the need to coordinate processes involving business stakeholders. The legacy processes involve truck drivers that need to interact with self-service kiosks to operate bulk product transports. These processes are expected to evolve to electronic interactions, making the transport more efficient based on automatic scheduling and authorizations of truck or train operations. The IoT perspective needs to consider a cross border scope, since we need to cope with a diversity of business stakeholders, including telecom operators, vehicle owners and manufacturers, manufacturers of the micro embedded connected devices, etc. On the other side there are organizations like the silos concessionaire, a user organization that needs such things framed to be reliable (responsibility), integrated (in system of systems and collaborative networks), cost-effective (vendor agnostic) and manageable, maintainable, and supported by integrated models. Integration is a complex endeavour, since the interdependence of responsibilities tends to be difficult to manage. In many cases, user organizations have independent 24 h/7 days support for each critical system even when they are under aggregation mechanisms.

The SITL-IoT is an integrating project joining: (1) an agri-food industry maritime terminal concessionaire SDL, aiming to evolve for integrated and collaborative operations and management of their supervision, control, and business processes; (2) a technology company FORDESI, already a supplier of a silos management system (SIGSIL product), which is committed to offering a vendor agnostic and advanced integrated and collaborative technology system and solutions; and (3) research organizations POLITEC&ID&ISEL and UNINOVA, which provide an open model driven systems engineering (MDEOS) framework.

The paper is organized in five main sections. Section 2 positions the problem and the main research questions. Section 3 summarizes and discusses research and industry contributions to the area. Section 4 presents and discusses the SITL-IoT project case and the proposed approach. The last section draws some conclusions and outlines open questions for further research.

2 Problem Domain and Main Research Questions

The SITL-IoT project aims to define an approach for agile integration of physical sensors and actuators under an IoT and cloud computing strategy, as depicted in Fig. 1.

Fig. 1.
figure 1

SITL-IoT systems vision for logistics terminal and products flow

Full size image

The agri-food silos operator company has a terminal concession of the port of Leixões/Porto Portugal, managing a complex network of technological systems and interacting with networked business partners. The aims of the project fit well with the industry 4.0 and digital transformation trends [7]. The Silo business ecosystem supervises and manages IoT/cyber-physical (mechanical, electrical, automation and computing) artefacts that need to be considered under a unified and single collaborative responsibility.

The agri-food silos ecosystem is under operation, and supported by five main systems (informatics or cyber-physical), as depicted in Fig. 2:

Fig. 2.
figure 2

The legacy systems at the silos operator

Full size image
  1. i.

    The Monitoring System, responsible for collecting events from temperature sensors and energy consumption instrumentation;

  2. ii.

    The SCADA, which is a supervision and control system;

  3. iii.

    The SIGSIL, a product and a central responsibility of FORDESI, which is composed of a customer portal, a mobile portal, and an operations portal, with interoperation to the WS Mobile and OPCS systems;

  4. iv.

    The WS Mobile Portal System for managing the interaction of SDL’s operators and truck drivers from ubiquitous user interface devices;

  5. v.

    The OPCS system, which is responsible for the management of the domain processes control.

These legacy systems are not integrated under a common technology framework. For instance, the Monitoring System does not process events from the other systems. Moreover, the two systems on the left (Monitoring System, and SCADA) are from two competing suppliers, while the three on the right (SIGSIL, WS Mobile, and OPCS) are from FORDESI. It is interesting to note that no interactions exist between the two systems on the left; they are isolated “islands” [5].

Technically, suppliers agree on some interaction strategy, e.g., based on an enterprise integration bus. The difficulty lies in the fact that the new system responsible for establishing such an enterprise bus raises additional research questions, since another system needs to be managed. So, the question is if the right strategy to create higher integration levels should be delegating on current suppliers to agree on interoperation mechanisms or to adopt open and vendor-agnostic infrastructures.

To meet this later goal, the challenge is to find an approach for establishing a sustainable multi-supplier technology framework, where systems from different vendors interact under an integrated system-of-systems framework. One key problem is to find the right modularity division of responsibilities, considering that a sustainable technology solution is the one that gets advantage from market competition for each elementary responsibility [5, 16]. Another concern is the design and validation of an appropriate structuration of collaborative responsibilities.

3 Related Research

The SITL-IoT project is conceptually aligned with Industry 4.0 or smart manufacturing [7]. It does not involve a manufacturing execution system, but it considers systems responsible for the execution of the SDL processes and, at the base, it involves a distributed cyber-physical system. Such system comprehends multiple embedded devices positioned at different sites that operate as actuators or perform data acquisition through sensors, which we can consider as elements positioned at “Field Level” [2]. One example of such elements is a Truck Weighting physical infrastructure to obtain position and weight of trucks.

The smart city concept and the emergence of sensor data available under open data models have motivated research and industry contributions to make huge amounts of sensor data available through cloud services [1]. While the idea is interesting for a more “citizen-centric and participatory mobility model” [21], the authors point for a backbone leveraged by ICT and open data. In fact, in the smart-city concept, the IoT has been the driver for new services offered by computing elements, contributing to data to be analyzed based on cloud systems [13]. While emphasizing the value of IoT and cloud computing, the mentioned work adopts an open infrastructure for sharing data sets and understand the interdependencies in such complex dynamic systems. Interdependencies appear as one of the recurrent problems in constructing enhanced intelligent mobility and friendly cities. The Open Data maturity report from the European Commission [8] positions cities like Lisbon in a high ranking, as open data is concerned. However, from the presented list of recommendations, it seems that it is lacking a technology strategy in terms of infrastructure responsibilities. The question is whether we need a kind of “city operating system” (what in [12] is called Urban Operating System) to provide an integrated ICT technology strategy for the coordination and integration of the complex system of systems.

In [12], the authors establish a parallel with corporate enterprise resource planning (ERP) to question the need for structuring consistent concepts towards the idea of Urban Operating System. The work discusses experiences of smart-city architectures of IBM, Microsoft, and Hitachi, pointing the need to “view the city as an experimental site for the transmutation of corporate integrated information systems into an urban context” [12]. We find this discussion interesting because it corroborates our hypothesis for the need of a novel technology strategy for answering business requirements under complex evolving ubiquitous computing elements as composites or aggregations of things (IoT), crossing infrastructure elements to business or control process automation systems. As in the SITL-IoT case, the IoT sensors and actuators need to interoperate, not only as sources of open data but also as elements composed or aggregated into cyber-physical or informatics systems. Despite the number of available standards, e.g., internet engineering task force (IETF) CoAp/REST or MQTT messaging protocol on the application layer of a communication stack, the huge number of open and proprietary specifications makes interoperability an unsolved challenge [1].

The relevance of IoT for SITL-IoT deserves a discussion about relevant IoT platforms like OpenMTC, FIWARE, Site-Where, and Amazon Web Services IoT, as established in [10]. In that work, the authors proposed a reference architecture as an abstraction for the discussed platforms, depicted in Fig. 3.

Fig. 3.
figure 3

(adapted from [10])

IoT reference architecture

Full size image

The proposed reference architecture raises a few questions related to how to frame the approach into a complex system of systems perspective. The Gateway seems to be necessary only if the “things” cannot cope with the proposed communication protocols and related stack layers (HTTP or MQTT, and JSON or XML for payload). It is suggested that IoT Integration Middleware “may comprise all kinds of functionality that are required by a certain cyber-physical system, for instance, a rules engine or graphical dashboards,” but the proposed architecture still includes an upper Application layer. Although the approach has some interesting features, we argue that dealing with all existing specific technologies and protocols is not realistic. Hence, in our perspective, an adaptive strategy is needed to plug the elements to the systems and to support the interactions between the systems [4].

The IoT is being materialized on a diversity of ecosystems (smart-cities, transports, mobility, home automation, healthcare), making possible the mobile ubiquity sensing and computing. The convergence of communication infrastructures, currently evolving fast to the 5G (fifth generation), also raises the need for a novel approach to the fast-upcoming Everything Integrated and Collaborative. The question is whether we need an IoT Manager, as proposed in [6], or a strategy to make IoT things pluggable to (aggregation) or into (composition) higher level constructors (systems and elements of systems), sourced from a diversity of technology and process cultures and under clear administrative boundaries.

4 The SITL-IoT Approach Under ISoS and ECoNet Frameworks

Given the initial problem formulation proposed by FORDESI, a decision was taken to adopt the MDEOS strategy [16] as a (co)-development effort based on the CEDE collaborative development environment [16] and the ISoS framework [11], towards an open technology landscape for SDL. Figure 4 depicts the ISoS framework and the collaborative business relations of SDL and FORDESI as a technology supplier under the ECoNet framework and platform.

Fig. 4.
figure 4

The vision behind the SITL-IoT project

Full size image

This research project gives an opportunity to rethink the legacy modularity, since both the Monitoring System and the SCADA functions are supposed not only to be maintained but also to evolve.

The adoption of the right modularity strategy is another issue, not only from the technical perspective but also from the vision and interests of the suppliers of the other legacy systems. The existing “things” and sub-systems provided by competing suppliers must evolve and be adapted to the ISoS framework. From our previous research [11, 15, 17], and considering the commitment of the SDL, we believe that other suppliers will adhere to the open specifications model, taking the advantage of being prepared to adopt open solutions.

4.1 The Isystem of Isystems (ISoS) and ECoNet Models

As depicted in Fig. 4, the extended SDL ecosystem comprehends warehouses, factories, and transport organizations and involves FORDESI as a supplier and support organization. The interactions flow through the Isystem ECoM [18], specialized in establishing collaborations and responsible for managing the data and coordination exchanges. Specialized collaboration contexts are to be designed and developed to establish short and long term collaboration relations [7]. Using ECoM to establish an ECoNet collaborative network has the advantage of following a unified technology approach. Based on the simple infrastructural mechanisms, each specific collaboration case, e.g., the exchanges with port authorities to access port community system, needs a specialized collaboration context to be installed [18]. The advantage is that the Isystems from all the organizations interacting in the context of a port community system share the same interchange mechanism.

ECoM is an Isystem integrated with the remaining Isystems of SDL through a new meta-Isystem that is designed and developed as the main entry point for the SDL technology landscape. The Isystem concept is part of the ISoS framework [11], where an Isystem0 (the mentioned meta-Isystem) is the entry point to access and introspect about the installed Isystems. This entry point establishes a secure and authenticated access to a self-awareness() web service. It assumes that any Isystem developer can implement the access to the selfAwareness() service, since it follows web services standards. Through the Isystem0 it should be possible to access the other Isystems, under the assumption that any computational responsibility is “wrapped” into an Isystem concept.

One important research item in the SITL-IoT project is the (re)construction of the modularity in SDL considering a revision of business processes, both internal and collaborative, in order to establish the Isystem structuration that better fits activity needs.

An Isystem is structured as a composite of Cooperation Enabled Services (CES) elements [14]. Access to the CES services follows a strategy like the one adopted for an Isystem. A CES is accessed and introspected through the selfAwareness() web service, which is the entry point to obtain the implemented services and the information necessary to access them. A service can be implemented in any legacy or new technology. A Generic Modelling Entity object holds the necessary information encoded/decoded by a predefined MIME tag. This means that no restrictions are imposed to developers of CES elements, since they are free to adopt the technologies considered to be most appropriate. The ISoS approach aims to reduce the risks of having innovation hampered by vendor lock-in situations.

Also, the offered flexibility allows a single CES to answer under different technology implementations. The multi-technology CES approach enables the incorporation of innovative features, making the product competitive without compromising interoperability. In fact, interoperability is adaptive, since any peer can obtain information about the implementation and the necessary elements for each specific implementation, making it possible for peers to access the service.

The SITL-IoT project offers the opportunity to validate the ISoS framework under an open specifications and development initiative. An initial question is how to migrate the existing products supplied by FORDESI, since they were developed using a different technology. Considering the adopted mechanism to cope with technology diversity, the main problem would not be the “wrapping” of legacy implementations but rather the (re)design of the “would-be” architecture.

4.2 Integration of Legacy Systems and IoT Things

From our perspective, there are two main structuration lines for the “things”. On the one hand, “things” can be in the WAN space, meaning that thing’s data needs to be transported by global communication providers. On the other hand, “things” can be local to the bounded infrastructure and therefore the communication is exclusively based on the LAN. Still, there are other application domains, as the example of the vehicle-to-vehicle or vehicle-to-infrastructure communication (V2X), where the communication is hybrid [20]. The communication can use the cellular or the road operator’s G5 infrastructure, depending on availability and on mechanisms to improve reliability. In the SITL-IoT case, it seems that a hybrid approach is appropriate, since trucks, drivers and the SDL’s personal can use ubiquitous mobile devices as sensing devices, which contributes for a smarter and agile processes control.

Hence, a hybrid strategy can consider the following association cases:

  1. i.

    The IoT “things” are elements of the organization’s ISoS technology landscape, and therefore they are framed under the CES abstraction.

  2. ii.

    The IoT “things” embed mobile elements, like trucks or nomadic devices held by a truck driver or a foreign person (from a different organization), in which case the access to the sensors is through the collaborative partners’ Isystems.

  3. iii.

    The IoT “thing” of a foreign person interacts with the physical “things” in the SDL’s infrastructure. The smartcard to authenticate a foreign user is an example of such situation that requires a learning interaction phase between the Isystems of both organizations for the sharing of the necessary authentication data.

Therefore, an IoT “thing” can be the responsibility of either the ISoS [11] of SDL (a Local Thing), or a business partner interacting in the context of an operation (Collaborative Thing), as depicted in Fig. 5.

Fig. 5.
figure 5

The SysML model framing of the IoT “things” to the ISoS framework

Full size image

The hypothesis of an interaction between a truck and the silos terminal weighing infrastructure to make the weighing operation aware of truck characteristics like its tare can be considered. In this particular case, the Collaborative Thing is modelled as a service playing a surrogate role (digital twin) responsible for managing the interactions with a business partner; the owner of the IoT “thing” modelled by the ISoS service. It can be a truck IoT from different transport companies dynamically detected and associated with making the weighting process accurate. The approach needs further research and validation, owing to the difficulty to guarantee interoperation considering heterogeneous “things” embedded into trucks.

5 Conclusions and Further Research

This paper presents and discusses the initial approach of the SITL-IoT project aiming at establishing a strategy for an open technology landscape for both the user organization and the associated collaborative network. The initial formulation of the SITL-IoT vision is presented and discussed. While considering the holistic vision for the collaborative network, the paper discusses the framing of IoT elements into the proposed holistic open integration strategy. The preliminary research, based on results from previous projects, suggests the IoT elements need to be under a clear governance model. The proposed approach, while not undervaluing public communication infrastructures (communication and internet service providers), assumes that the IoT devices are elements of cyber-physical or informatics systems. With such approach, we do not discard the access to IoT through public Internet/web services, whilst at the same time we uphold the responsibility integrity led by the system concept.

Nevertheless, the proposed strategy faces many obstacles requiring further research and validation. The so far theoretical CES model needs to be demonstrated in wrapping legacy implementations, and one main question encompasses the cost and the risks of such required changes. Beyond the migration problem, the SITL-IoT faces several other challenges, among which we consider:

  • The cost of wrapping legacy systems needs to be clarified. This problem is related to decision making regarding the right Isystem or CES modularity, due to the related market competing issues. In other words, achieving the balance between the market/business interests and the openness strategies.

  • The strategy to follow making local or just-in-time access to data critical for operation. A practical example can be the case of a planned truck that needs to be replaced after a breakdown, and the new tare weight need to be obtained.

  • The design and management of both the operational processes and the collaborative processes already established based on long term contract agreements to their execution control and auditing. The collaboration contexts managed by the ECoNet/ECoM seem to be flexible enough to develop higher collaboration models of collaboration processes, but this needs to be verified.

This project is particularly relevant for this study, considering that a supplier, the FORDESI company, decided to invest on an open strategy to rethink the offered products and architecture for the integration of the overall automation solution of the agri-food silos industry.