1 Introduction

The Internet of Things (IoT) is the result of technological progress in many parallel and often overlapping fields, including those of embedded systems, ubiquitous and pervasive computing, mobile telephony, telemetry and machine-to-machine communication, wireless sensor networks, mobile computing, and computer networking. In essence, IoT combines the concepts “Internet” and “Thing” and the provided definitions in the literature can be interpreted how these have addressed these two concepts. What is important is that IoT adds a new dimension “anything” to the current communication technologies (ICTs), which already provide “any time” and “any place” communication.

To support the design of IoT systems, various reference architectures have been provided in the literature. In general, IoT architecture is represented as a layered architecture with various set of layers representing a grouping of modules that offer a cohesive set of services. Based on the literature [1,2,3,4] we provide the reference architecture as shown in Fig. 1.

Fig. 1.
figure 1

IoT reference architecture

Full size image

The reference architecture consists of seven layers including Device Layer, Network Layer, Session Layer, Cloud Layer, Application Layer, Management Layer, and Security Layer [5]. Usually these layers can be distributed in different ways over the different nodes in the IoT system. Using the IoT reference architecture various different IoT systems can be designed. Each such IoT system integrates the various devices within the same network. Yet, the scope of an IoT system is often within a particular scope and the integration with other IoT systems or non-IoT systems is not a trivial task.

Cleary the IoT has a pervasive impact on the society and an increasing number of systems are now based on IoT. One of the key challenges in IoT is coping with the heterogeneous set of systems and the integration of these systems in the same communication network. Several studies have focused on this integration aspect and addressed this at different levels of abstraction. Unfortunately, the different approaches are scattered and fragmented over the different studies and it is not clear how to cope with the integration concern within a single IoT system but also across multiple IoT systems that need to be integrated. To this end this chapter provides a comprehensive and systematic approach for identifying the key integration concerns in the IoT system architecture and describing the currently provided solutions. For this we adopt a pattern-based approach in which generic architecture solution structures are provided to these recurring integration concerns. We illustrate our approach for addressing the integration of IoT based systems within the context of smart city engineering.

The remainder of the paper is organized as follows. Section 2 presents the case study together with the problem statement. Section 3 presents the integration framework together with the adopted integration patterns. Section 4 presents the adopted process for preparing and designing an integrated IoT system. Section 5 illustrates the application of the approach for smart city engineering context. Section 6 concludes the paper.

2 Case Study: Smart City Engineering

In this section, we define a case study that will be used to illustrate the problem statement and the approach in further sections. The case study that we consider is within the context of smart city engineering [6]. One of the important applications in smart city engineering includes the development of smart traffic system (STS). STS provides different capabilities such as traffic light management, congestion detection, traffic regulation, shared parking platform, etc. The high-level reference architecture of STS is depicted in Fig. 2 [7].

Fig. 2.
figure 2

Conceptual architecture for smart traffic system

Full size image

Although the above case integrates many different entities it still deals with the design of a single system, in this case an STS. Very often it is required though to integrate the STS with other systems in the smart city engineering context, such as city energy consumption system, the weather information system, the security system, the air quality control system, the smart lighting system etc. (Fig. 3).

Fig. 3.
figure 3

Integration of different IoT-based systems in the context of smart city engineering

Full size image

Integrating all these systems in a coherent manner is not trivial and requires careful consideration. We will elaborate on this in the next sections.

3 Integration Framework

The integration of IoT systems can be considered at different abstraction levels. We will discuss the integration based on the four layers of the architecture as defined in Fig. 1. To illustrate this need for integration at different levels Fig. 4 shows the integration of different IoT systems.

Fig. 4.
figure 4

System integration of IoT-based systems in different layers

Full size image

As shown in Fig. 4 we distinguish the following types of integration in IoT systems (1) Session Layer Integration: (1a) Protocol Integration via IoT Gateway (1b) Protocol Integration via Middleware, (2) Cloud Layer Integration, and (3) Application Layer Integration. For describing the integration solutions, we will adopt a design pattern-based approach. A design pattern represents a generic solution to recurring problems. Design patterns play an important role in the engineering design process and can be applied at the different levels in the lifecycle including the architecture design, detailed design, and the code. In this paper, we will mainly focus on architectural patterns which focus on the gross-level structure of the system and its interactions [8]. In the following, for each level we will describe the possible architectural patterns that can be used in the integration of IoT systems. Hereby we will also shortly indicate the advantages and disadvantages of the adopted architecture design pattern.

3.1 Protocol Integration via IoT Gateway

Multiple session layer protocols exist in the IoT domain to integrate the different things in the IoT as shown in Table 1 [5]. The issue of heterogeneous devices adopting different communication protocols impedes the integration of these devices in the same IoT systems. An IoT gateway acts as a portal between two elements of one or multiple IoT systems, allowing them to share information by communicating between the adopted IoT protocols. An IoT gateway, as such, bridges the gap between devices, cloud, and the computer or mobile device providing a communication link between the devices and cloud.

Table 1. Characteristics of the IoT session layer protocols
Full size table

Figure 5 shows the different gateway patterns used for integration of IoT systems. In the classical protocol integration hardware/software gateways are used to format and translate data coming from one protocol type to a different protocol type as given in Fig. 5a. This type of protocol integration is successful as long as the number of devices to be integrated is not excessive. However, for a large-scale set of devices it is not easy to handle all the heterogeneous protocols and technologies of the IoT and design a suitable gateway without causing anomalies such as timing and collusion problems. With the possible addition of even more protocols and technologies developed in IoT domain, this problem will become even less manageable [9]. In order to solve the scalability problems and to provide more efficient gateways the following solutions are proposed in the literature.

Fig. 5.
figure 5

Different gateway patterns for integration in IoT systems

Full size image

Distributed Multi-gateway Approach

In this approach multiple gateways are used to cope with the different set of protocols in the IoT system in Fig. 5b [9]. Hereby, the protocols are treated singularly or as a subset of the selected protocols in each gateway. Each gateway translates its protocol to a common shared protocol. The gateways themselves can communicate using the common protocol. By combining gateways dedicated to different technologies multi-protocol scenarios can be generated.

Web-Service Multi-protocol

Instead of having a gateway for each protocol it is also possible to provide a central gateway that is connected to a central conversion server. This so-called web-service multi-protocol pattern is shown in Fig. 5c [9]. In this approach, gateways receive raw data from sensors which are translated to a shared format by connecting with a web-service. In contrast to the distributed multi-gateway there is only one gateway which does the translation among the protocols.

Intelligent Gateways

For translating to different protocols, the gateway can be provided the required translation functionality as shown in Fig. 5d. In this case the gateway will not depend on a separate central server such as in the case of web-service multiprotocol gateway but include the functionality for translating the protocols. Hence, we can indicate this as an intelligent gateway solution. This solution is, for example adopted by Diaz-Cacho et al. [10] and Al-Fuqaha et al. [11]. In these solutions intelligent gateways convert the incoming protocol data to a common shared protocol data which is in this case is extended MQTT. However, the intelligent gateway can in principle also provide different kind of functionality and mapping of the protocols.

3.2 Protocol Integration via Middleware

The alternative way of overcoming the protocol heterogeneity other than using a gateway is the use of a middleware to be used as an abstraction layer. This pattern is shown in Fig. 6. This goes beyond the intelligent gateway solution that includes only functionality for translation among the protocols. In case of a middleware solution also additional functionality such as naming and directory services, security aspects, reliability and other functional and quality services can be also provided. The primary aim of using middleware is to provide seamless integration of systems by hiding the communication and various low-level acquisition aspects [12].

Fig. 6.
figure 6

Integration of the protocols using middleware

Full size image

There are studies offering the use of an IoT middleware to integrate IoT-based systems in the literature. Ngu et al. [13] provides a survey about IoT middleware integration. Lomotely et al. [14] proposes a middleware to be used as an abstraction layer to address variation in device semantic and protocols that limit the interoperability of the systems. The proposed middleware uses enhanced environment features to match the appropriate communication protocol to aid pushing data from sensors to cloud infrastructure.

3.3 Integration in the Cloud

Another integral component of the IoT is cloud computing. In general, three types of cloud computing models are defined including Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) [15,16,17]. The IaaS model shares hardware resources among the users. Cloud providers typically bill IaaS services according to the utilization of hardware resources by the users. The PaaS model is the basis for the computing platform based upon hardware resources. It is typically an application engine similar to an operating system or a database engine, which binds the hardware resources (IaaS layer) to the software (SaaS layer). The SaaS model is the software layer, which contains the business model. In the SaaS layer, clients are not allowed to modify the lower levels such as hardware resources and application platform. Clients of SaaS systems are typically the end-users that use the SaaS services on-demand basis. For adopting cloud-based integration the different clients are considered the individual systems in the overall IoT system. The integration pattern based on the IaaS, PaaS, or SaaS in the cloud layer is shown in Fig. 7a.

Fig. 7.
figure 7

Cloud-based integration of different IoT systems

Full size image

An important benefit of IoT is the generation of data that can be further used to derive information to support the decision-making process. The data is typically stored in the cloud which can be used to support analytical and computational tasks on these data allowing centralized access to the generated IoT services [18].

Figure 7b shows the pattern for the data integration in the cloud. Hereby, the integration of the systems is primarily based on the integration of the data from the different IoT systems. Since each IoT system can use its own type of data platform and the corresponding data structures and formatting, the integration will need to support data interoperability. For this it is needed to adopt a common data format and platform that is adopted at a central cloud node. Incoming data from different nodes will be typically mapped to a shared data format. Subsequently a data fusion and/or data conversion process will be carried out to synthesize the data. The cloud node will typically include analytics modules for processing the data for descriptive, diagnostic, predictive or prescriptive analytics.

3.4 Integration in Application Layer

Besides of integration at the gateway or middleware level we can also achieve the integration of IoT systems at the application layer level. Much has been written about application integration and likewise we will borrow from the earlier concepts to define the integration of IoT systems. In the literature dozens of architecture patterns have been published regarding application integration [19,20,21,22,23,24]. In the following we will consider only those patterns that can be directly used for supporting the integration of systems, and in the context of this chapter, in particular the integration of IoT systems.

Peer-to-Peer

In the peer-to-peer architectural pattern, peers (IoT Systems) connect to each other directly, and there is no intermediate component between the IoT systems. The conceptual model is shown in Fig. 8a. The elements in the system are autonomous, equal peers that are both providers and consumers of data and processing power. Further, the primary content is provided by peers, are there are no central components providing content. In addition, peers can be added and removed from the system at any time.

Fig. 8.
figure 8

Patterns for integration at the application layer

Full size image

Client-Server

The Client-Server architectural pattern is a very common and well-known pattern for network-based applications. The conceptual model this pattern is shown in Fig. 8b. Hereby some systems play the role of Clients, while other adopts the role of a Server. One or multiple Client components initiate a request to a Server, which then performs some computations and responds to the Clients. Only clients can initiate communication, while servers only respond to requests from clients. If needed server components can be clients to other servers. Clients cannot communicate to each other. As we will see in the later sections this is different from the Event-Based and Streaming invocations since the Client decides itself when to initiate a request.

Event-Based

The conceptual diagram of the event-based software architectural pattern is given in Fig. 8c. This pattern is based on implicit invocations which are induced by events, i.e., when a certain event takes place it triggers the function calls. Event can be defined as a significant change in state. Typically, event-based systems are composed of event producers, event consumers and event channels. The events are sent to the listeners over the network even they are not on the same hardware. So, this pattern is well-suited for real-time applications, message-oriented middleware, and point-to-point communications. Further, the event-based pattern supports parallel execution of tasks and scalability.

Publish-Subscribe

This pattern is shown in Fig. 8d. It consists of mainly three elements including Publishers, Subscribers, and Topics. Publishers write to Topics and Subscribers read from the Topics on which they are registered. One Publisher can write to many Topics and one Subscriber can read from many Topics. Unlike the event-based pattern described above, the subscribers in this pattern are all interested in a type of event happening without knowing the publisher of the event. The adopted communication pattern provides space decoupling, time decoupling and synchronization decoupling [25]. The decoupling of producer and consumer participants increases scalability by removing explicit independencies between communicating parties. Removing these dependencies together with the asynchronous communication feature of this infrastructure makes this pattern well-suited for even large scale IoT systems.

Service Oriented Architecture (SOA)

The service-oriented architecture deals with composing applications by integrating distributed, separately maintained components aiming vendor and technology independence. This integration composed of three essential loosely coupled parts which are registry, service providers, and service requestors as shown in Fig. 8e. In this integration type, service publishes its description to the service registry that keeps the list of all services with their locations and functionalities. When a service requester requires a service, it gets the required information from the registry and communicates with the requested service over a standardized communication.

This type of decoupled integration is especially suitable for heterogeneous distributed systems supporting evolvability and interoperability. The disadvantage of this integration pattern is the complexity.

Pipes and Filters

This pattern is composed of two basic elements: pipes and filters as shown in Fig. 8f. Filters are connected to each other by pipes. Filters transform the data received from another filter into a new form and output this transformed data to the following filter. Pipes are the routes of data streams. Although filters are independent of each other and might execute parallel, they must use the data type agreed with pipe in order to communication takes place. This simple communication mechanism makes the pattern scalable and reusable supporting evolvability. On the other hand, this batch-type data processing cannot handle interactivity well and latency causes performance degradation.

4 Overall Approach

Table 2 shows the summary of the previously defined patterns that can be used to support integration of the concerns in the IoT system. Obviously, it is clear that for integrating multiple IoT systems many different issues need to be taken into account. To guide and support the integration of the IoT systems we propose the process as shown in Fig. 9.

Table 2. Identified list of patterns that can be used in the integration process
Full size table
Fig. 9.
figure 9

BPMN model representing the steps for integrating multiple IoT systems

Full size image

The first step in the process is the identification of the individual IoT systems that need to be integrated. The second step in the process includes the identification of the concerns for the integration. This will require checking the needs and the overall purpose for the SoS. Hereby it is important to describe the added value that is created using the integration of these systems. In the third step we identify the patterns that can be used for the integration. These will include the patterns that we have described in the previous section. For this we will adopt the criteria and consider the constraints, the advantages and disadvantages of the corresponding patterns. Once the patterns have been identified we apply and compose the patterns. In principle, more than one pattern can be applied which will require design decision for the composition. In the final step we evaluate the overall architecture of the SoS with respect to the initial objective and the stakeholder concerns in the SoS.

5 Integrating the Smart City Engineering Systems

In order to illustrate our approach, we will consider the smart city engineering case study as defined in Sect. 2. The provided solution is given in Fig. 10. Here it is assumed that Air Quality System and Weather Monitoring System reside at the same location, which are integrated using a smart gateway that realizes the translation of the adopted different protocols in these systems. The Smart Building and Smart Office are also considered in the same location. Hereby, a multi-protocol gateway solution has been used in which multiple gateways for different protocol translations are adopted. The Smart Traffic System, Smart Lighting System, and City Energy Consumption system are considered to be connected over a local area network and communicate through a middleware platform. The middleware provides the translation services and additional network and communication services. All the systems are integrated in the City cloud in which all the cloud integration patterns including SaaS, PaaS, IaaS and data integration is used. This is one solution in which different patterns have been applied to meet the requirements. For different other requirements other patterns can be used to integrate the IoT systems.

Fig. 10.
figure 10

Example pattern-based integration of smart city engineering systems

Full size image

6 Conclusion

One of the key challenges in IoT is coping with the heterogeneous set of systems and the integration of these systems in the same communication network. Based on a layered reference architecture for IoT we have indicated that the integration can be at different layers including session layer, cloud layer and application layer. Further we have shown that the integration is typically carried out based on well-defined patterns, that is, generic solutions structures for recurring problems. We have not provided any new integration solution but rather systematically compiled and structured the integration patterns as defined in the literature. Our study has resulted in 15 different patterns which can be used in different combinations. To guide the application of the patterns we have provided a general process represented using the BPMN. The process and the patterns have been successfully applied to a smart city case study. Hence, we have shown that the systematic structuring of the integration patterns is useful for developing IoT systems that need to integrate heterogenous elements. Although we have identified and described the key patterns in the literature, this study could be further extended by considering other patterns. In our future work we will consider other type of IoT reference architectures and based on these enhance the set of patterns that we have described in this paper. Further, we will also consider IoT patterns beyond the integration concern such as security and safety patterns.