Towards the adoption of OMG standards in the development of SOA-based IoT systems

Highlights

• We propose a fully OMG-compliant modeling framework to support the design and analysis of SOA-based IoT systems.

• A proof-of-concept shows how the framework can help the software engineers.

• Results from a study with software engineers from industry demonstrate the easy of use and usefulness of our proposed framework.

Abstract

A common feature of the Internet of Things (IoT) is the high heterogeneity, regarding network protocols, data formats, hardware and software platforms. Aiming to deal with such a degree of heterogeneity, several frameworks have applied the Model-Driven Development (MDD) to build IoT applications. On the software architecture viewpoint, the literature has shown that the Service-Oriented Architecture (SOA) is a promising style to address the interoperability of entities composing these solutions. Some features of IoT make it challenging to analyze the impact of design decisions on the SOA-based IoT applications behavior. Thus, it is a key requirement to simulate the model to verify whether the system performs as expected before its implementation. Although the literature has identified that the SOA style is suitable for addressing the interoperability, existing modeling languages do not consider SOA elements as first-class citizens when designing IoT applications. Furthermore, although existing MDD frameworks provide modeling languages comprising well-defined syntax, they lack execution semantics, thus, are not suitable for model execution and analysis. This work aims at addressing these issues by introducing IoTDraw. The framework provides a fully OMG-compliant executable modeling language for SOA-based IoT systems; thus, its specifications can be implemented by any tool implementing OMG standards.

Introduction

Heterogeneity is an intrinsic feature in the Internet of Things (IoT) systems, regarding several aspects such as network protocols, data formats, hardware and software platforms (Buyya and Dastjerdi, 2016). Such a degree of heterogeneity poses challenges to develop IoT applications when following traditional approaches, as the node-centric programming (Pathak and Prasanna, 2011), which has been widely used in the context of Wireless Sensor Networks (WSN) (Yang, 2014), a subset of IoT. In such an approach, applications are developed in a platform-dependent way, with experts in embedded systems programming the tasks required for individual nodes, as well as the interactions between them, by using general-purpose programming languages. As shown by Patel and Cassou (2015), although traditional approaches allow complete and fine-grained control over individual nodes, it is not easy to apply them in the context of IoT applications due to the scale factor and high heterogeneity of devices (Patel et al., 2014). In addition to these factors, programming using traditional approaches requires low-level knowledge of the hardware-specific operating systems of the sensor nodes. The proliferation of sensors and applications that make use of their data has led to the desire to increase the learning curve for building sensing-based systems and to promote the reuse of generated software artifacts. Aiming at addressing the limitations of traditional approaches, several frameworks were proposed (such as (de Farias et al., 2016, Rodrigues et al., 2015b)) applying the Model-Driven Development (MDD) (Brambilla et al., 2012) to build IoT and large-scale WSN applications.

MDD is a development paradigm that uses models as the primary artifact of the development process. With MDD approaches, models specifying the systems are created by using Domain-Specific Modeling Languages (DSML), or DSL for short. A DSL provides high-level abstractions related to the domain of interest expressed through inter-connected textual or graphical symbols. In the context of IoT, existing DSLs allow identifying the heterogeneous entities composing the applications through general concepts. As suggested by the literature (e.g., de Farias et al., 2016, Thramboulidis and Christoulakis, 2016, Rodrigues et al., 2015a), considering its key principles, such as abstraction, separation of concerns, reusability and automation, MDD is a promising paradigm to support the development of IoT solutions.

From the software architecture point of view, the heterogeneous nature of IoT requires structuring the applications by considering the interoperability of different software components and hardware devices. This critical issue has led the researchers to investigate architectural patterns or styles that most favor the communication of the inter-connected entities in an IoT system. In this sense, many studies (e.g., Bassi et al., 2013, Spiess et al., 2009) have shown that the Service-Oriented Architecture (SOA) (Erl, 2005) is one of the most suitable architectural styles to address the interoperability in IoT applications. Interoperability is about the degree to which two or more systems can usefully exchange meaningful information via interfaces in a given context (ISO/IEC, 2011, Bass et al., 2012). SOA is an architectural pattern structured as a collection of loosely coupled, distributed components that provide and/or consume services through well-defined interfaces (Bass et al., 2012). In the SOA-based IoT applications, the devices’ capabilities (e.g., sensing, actuating) are provided as software services through such well-defined interfaces, thus allowing the entities that compose an IoT providing their capabilities and consuming the required services in a standardized manner. For example, the authors in Guinard et al. (2010) applied SOA in real-world scenarios with multiple heterogeneous devices, ensuring interoperability across all devices and components. Furthermore, Cloud platforms are widely used as back-end for IoT given their huge processing and storage capabilities. The synergistic integration of IoT with Cloud has given rise to the recent paradigm known as Sensor-Cloud or Cloud of Things, which aims to make the most of both technologies. IoT-generated data that requires a lot of processing or long-term storage can be sent to the cloud, which in turn extends its service portfolio to encompass sensing and actuation capabilities. Cloud platforms follow a service-based resource provisioning model. Cloud platforms providing infrastructure for IoT systems naturally adopt the services approach (e.g., Microsoft, 2019, Amazon, 0000). In a recent survey that investigated middleware technologies for Cloud of Things (Farahzadi et al., 2018), the authors have identified that SOA is the main architectural style in CoT-based Middleware, due to is capability of promoting interoperability and reusability in IoT systems.

Any DSL must provide a coherent set of concepts related to the domain of interest (Brambilla et al., 2012). That is, the DSL must be expressive, aiming to allow the precise identification of multiple aspects regarding the application domain. Otherwise, if the DSL lacks essential elements of the underlying domain, the models may be at least ambiguous, or the modelers may not be able to represent all components of the applications. Although the literature has identified the suitability of the SOA style for addressing the interoperability in the IoT domain, to the best of our knowledge, there is no DSL tailored for the modeling of SOA-based IoT applications. SOA is a proven architectural pattern, with a well-known set of concepts. Existing DSLs for IoT (e.g., UML4IoT Thramboulidis and Christoulakis, 2016 and ThingML Morin et al., 2017) do not fully contemplate such concepts, which impacts on the architectural design of IoT applications following the SOA approach. This is a critical problem since even crucial but straightforward design questions related to SOA style cannot be answered by the model, such as, “What are the services, and by which interface they are exposed?”, “Who are the provider/consumer participants that are part of the application?”, “How the participants interact with each other?”, “What is the choreography of the services?”, or “What is the protocol used by the interfaces”. A DSL that does not provide concepts to allow answering these design questions possibly hampers the design of SOA-based IoT applications.

Another important design issue refers to the simulation and analysis of IoT systems. In the domain of Software and Systems engineering, a rule of thumb states that the best system representation is the simplest model that answers a set of design questions (Reussner et al., 2016). This means that, besides identifying precisely the multiple components, another reason for modeling a system is to support the architectural decision-making process (Reussner et al., 2016, Clements et al., 2010). Otherwise, the system model would serve only as documentation and would not support a more in-depth analysis, which may not justify the modeling effort. A modeling approach helps to answer design questions and supports the architectural decision-making process by its ability to predict, at design-time, the properties of an artifact based on its design. This prediction is possible when the DSL allows its compliant models to be executed and simulated. When specifying IoT systems, some features of the IoT domain makes challenging to analyze the impact of design decisions on the system behavior. Examples of such features are the resource constraints of devices and multiple deployment scenarios. An IoT application can be composed of tens, hundreds, or even thousands of devices, many of them being powered by limited batteries and with constrained resources (in terms of processing speed and memory size), which may impact on the availability or performance of the IoT application (Buyya and Dastjerdi, 2016). On the other hand, the multiple components of an application may be deployed on different platforms (varying from resource-constrained devices to Cloud computing platforms), which result in a considerable number of eligible deployment scenarios. Since each deployment scenario has a different impact on application requirements and system performance, it may become humanly infeasible to identify the best deployment alternative. These issues hamper making proper design decisions, being necessary to execute and simulate the model to verify whether the specified application performs as expected before its implementation. Otherwise, if problems caused by wrong design decisions are found only after the system implementation or deployment, it may result in financial loss or, worse, risks to human lives, for instance in failures in e-Health applications.

Considering the system verification and the problems that may occur whether it is not realized at design time, a typical analysis that must be performed refers to non-functional or Quality of Service (QoS) properties. The study of Udoh and Kotonya (Udoh and Kotonya, 2018) presents a comprehensive review of existing IoT application frameworks and toolkits. An interesting finding of such study is that existent frameworks ignore the support of verification of Quality of Service (QoS) properties at design time. Another study (Libelium, 2019) has shown that only around 2% of the companies that are developing IoT solutions are able to test the specified systems before undertaking the system deployment.

Aiming to tackle the abovementioned issues, the core contribution of our work is proposing an MDD framework, which we called as IoTDraw. The framework provides a fully OMG-compliant executable modeling language (DSL), SoaML4IoT (Costa et al., 2019), for SOA-based IoT systems; thus, its specifications can be implemented by any tool implementing OMG standards. The DSL was built on the Service-oriented architecture Modeling Language (SoaML) (OMG, 2012), the Object Management Group (OMG) standard for designing SOA solutions. SoaML consists of an extension of UML (OMG, 2017b) (i.e., a UML profile), which was conceived through the collaboration of experts from academia and industry. As stated by the SoaML specification, the modeling language focuses on the basic service modeling concepts, and the intention is to use it as a foundation for further domain extensions. Thus, based on our experience and proven domain models for IoT (e.g., IoT-ARM Bassi et al., 2013, WSO2 Fremantle, 2014), we extended this language with concepts of the IoT domain, allowing the identification of the multiple entities composing SOA-based IoT applications.

SoaML4IoT-compliant models are meant to be executed based on the language execution semantics. The execution semantics of SoaML4IoT is defined following the fUML (Foundational Subset for Executable UML Models) (OMG, 2017a), the OMG standard for model execution. This specification provides a semantic model that formalizes the execution of a subset of UML, that is, classes (structure) and activities (behavior). Therefore, fUML allows defining an interpreter or execution engine to execute the system described in the model. However, if the UML model has an applied profile (e.g., SoaML), the semantics of this latter does not influence the execution. Aiming to allow the execution of SoaML4IoT models, we extended the fUML semantic model with concepts of our proposed DSL and implemented it as a prototype on Moka (2015), a Papyrus module that includes an execution engine complying with fUML.

By allowing the execution of SoaML4IoT-compliant models, our proposed framework aims to help answering design decisions that are hard to answer even for simple IoT applications. Some of these questions are, for example: “In which platform should I deploy this component?” or “Considering the availability requirement of the application, is there any component I should deploy to a different platform after a link failure?”. By supporting answering these questions, IoTDraw aids modelers to make more successful architectural decisions and to verify their impact on the IoT application behavior/performance.

We claim that our proposal is useful for supporting engineering activities potentially for all IoT application domains, including the field of Industrial Internet of Things (IIoT) systems (Sadiku et al., 2017). As identified by Koziolek and colleagues (Koziolek et al., 2018), distributed control systems are currently evolving towards IIoT. However, the initial network configuration, application-specific device configuration, and integration with other devices are cumbersome and laborious nowadays. Such tasks are referred to as commissioning, and engineers still suffer from complex commissioning process that incurs high costs, not only from investments on hardware components but, also from manual labor to engineer and set them up (Großmann et al., 2013). The number of heterogeneous devices (hundreds or even thousands) composing the system, the specificity of communication protocols, as well as the eventual reconfiguration of devices can result that the commissioning process takes several months, which is costly and delays time-to-market. The most common structure of control systems follows the ANSI/ISA95 (ISA, 2019) standard, which splits the systems into four levels, namely, Level 4: Business Planning & Logistics (plant production scheduling, operational management); Level 3: Manufacturing Operations & Control (dispatching production, detailed production scheduling, reliability assurance); Level 2: Supervision and Controller (workstations for supervision by human operators and for engineering of devices and processes); and Level 1: Devices (sensors and actuators that directly interface with the machines executing the industrial process). The IoTDraw can be used in the commissioning process, specifically, in the levels 1 to 3 of the ANSI/ISA95 standard. In Level 1, the SoaML4IoT allows the engineers to specify the configuration of devices through UML elements thus, abstracting hardware-specific details. Such device models can be organized into model libraries and re-used by other projects. In Level 2, the controllers and their network connection to the devices are also modeled by using UML. By applying SOA standard, the distributed components are structured as providers and consumers, which expose their functionalities through well-defined interfaces, promoting interoperability. Finally, the operations of Level 3 are specified as behavior UML diagrams (i.e. UML Activity Diagram) in such a way that it is possible to execute the model at design-time. Thus, engineers can verify and test the system before its implementation and deployment. Such verification can reduce the cost of fixing errors that would be only detected in the production.

IoT applications interact with the physical world through different models, such as, periodic, event-driven, or initiated-by-the-actor (i.e., request–response) (Buyya and Dastjerdi, 2016, Delicato et al., 2013). In the periodic model, the devices sense data (e.g., temperature, lighting) or actuate on the physical objects (e.g., turning on/off, updating configurations) continuously, at a rate predefined by the application. In the event-driven model, the devices continuously monitor the physical objects or environment variables, but report information or perform actuation only if an event of interest for the application occurs. The event-driven model requires asynchronous communication, for example, based on the Publish–Subscribe pattern (Bass et al., 2012). With such a pattern, the applications register for events of interest only once and receive the required sensing data upon the occurrence of these events. Finally, in the request–response model, the applications send requests for sensing data or actuating capabilities to the devices, which perform the required tasks and respond to the applications with the required data or actuating confirmation. The request–response model is based on synchronous communication, in which the devices report their data in response to a synchronous request issued by the application. The focus of IoTDraw is on periodic applications, which, as indicated by Gascon and Asin (2018), is adopted in several domains and IoT solutions.

In summary, the contributions of our work aim to benefit both the IoT and MDD fields. In the IoT domain, we bridge the gap of existing DSLs that do not provide concepts as first-class citizens for the precise representation of periodic IoT systems following the services approach and thus, lack support for specifying and simulating SOA-based periodic IoT applications. Considering the MDD field, our work is one of the first endeavors towards defining the execution semantics for UML profiles by extending the fUML semantic model. Since IoTDraw is fully OMG-compliant, its specifications can be implemented by any tool implementing UML and fUML.

The remainder of this paper is organized as follows. Section 2 establishes the background underlying this work. Section 3 describes a Smart City IoT system that will be used as a running example of this study. Section 4 introduces the IoTDraw modeling framework. In Section 5 we present the evaluation of our proposal. In Section 6 we analyze the related work. Finally, Section 7 revisits the contributions and presents perspectives for future work.