Enabling Model-Driven Software Development Tools for the Internet of Things Karim Jahed Juergen Dingel Queen’s University Queen’s University Kingston, Ontario, Canada Kingston, Ontario, Canada [email protected] [email protected] ABSTRACT The IoT is envisioned as an infrastructure for a wide range of The heterogeneity and complexity of Internet of Things (IoT) ap- heterogeneous "things" that exchange all sort of data using a battery plications present new challenges to the software development of network protocols. Things range from simple physical objects process. Model-Driven Software Development (MDSD) is increas- embedded with sensors and actuators to traditional computing ingly being recognized as a key paradigm in tackling many of these devices and user interfaces, all the way to complex cloud services. challenges, as evident by the emergence of a significant number An IoT application typically combines several of these entities in a of MDSD frameworks targeting IoT in the past couple of years. At well-defined manner to achieve certain goals, and provide the user the heart of IoT applications are embedded and realtime systems, a with a unified, coherent experience. domain where model-driven development is well-established and The scale and complexity of envisioned IoT systems set forth many existing tools have a proven track record. Unfortunately, only new challenges for their design and development. Researchers have a handful of these tools support out-of-the-box integration with the recently begun to recognize Model-Driven Engineering (MDE) as a IoT. In this work, we discuss the different design and implementa- key-enabler in tackling many of these challenges. The most promi- tion decisions for enabling existing actor-oriented MDSD tools for nent challenge being heterogeneity in both software and hardware the IoT. Moreover, we propose an integration approach based on [6]. Not only can IoT devices differ in terms of hardware and soft- the use of proxy actors and system interfaces. The approach offers ware, but the latter itself is often expected to be deployable on a seamless and flexible integration of external IoT devices into the wide variety of hardware. The abstraction capabilities that Domain user’s model. We implement and evaluate our approach using the Specific Languages (DSL) offer, coupled with automation bymeans MDSD tool Papyrus for Realtime as a testbed. of code generation, allows the specification of software systems in a way that transcends any single platform. A remarkable number of KEYWORDS Model-Driven Development (MDD) tools for the Internet of Things has been proposed in the past couple of years [26][28][15][13] Model-Driven Development, Internet of Things, UML-RT, Papyrus- [9] [18]. RT While MDD tools for the holistic design, development, and anal- ysis of IoT systems continue to emerge, an array of tools and frame- works for the modeling real-time and embedded systems already 1 INTRODUCTION exists and have a proven track record. Unfortunately, many of these The Internet of Things (IoT) is arguably one of the biggest leaps in tools lack integration with the IoT, as in they do not provide an the evolution of the Internet since the introduction of the World explicit way to interact with third-party IoT devices. Significant Wide Web. From a technological perspective, IoT is the logical result effort has already been invested in recent years to remedy this of the proliferation of Internet-ready, non-conventional computing problem, as we demonstrate in Section 5, however, as far as we can devices, motivated in part by advances in wireless networking. tell, the literature lacks a systematic presentation and discussion of A growing number of everyday physical objects – ranging from the ’design space’, i.e., the different fundamental design decisions simple home appliances, wearables, and automotive, to complex and their advantages and disadvantages, and how to integrate code industrial pipelines – are being connected to the Internet at an created with MDD tools into IoT applications. unprecedented rate. In fact, the number of IoT devices is expected In this work, we provide such a discussion of the design space to exceed 30 billion by the year 2020 [27], doubling a 2015 estimate while also describing a specific approach that we have chosen, of 15 billion devices [23]. implemented, and evaluated. We propose a combination of proxy The IoT promises far-reaching impact that touches nearly every model-components that acts as representative for external IoT de- aspect of our lives. Home automation, health monitoring, traffic vices and are easily embeddable in the user’s model, along with management, and smart cities [36] are just a few examples of what specialized system interfaces that offer the modeller full control IoT entends to enable. The enormous amount of data generated over the communication channel. This approach has the dual bene- by hundreds of sensors embedded in our everyday lives, coupled fit of offering the complete abstraction of external devices whenthe with rapid breakthroughs in data analytics and machine learning, particular details of the communication process are unimportant, has given the promise of a trillion-dollar economy [1]. Now more as well as utmost flexibility and control over the network protocol than ever, businesses and governments are relying on data-driven when the application requires it. We describe the requirements for insights to optimize industrial processes, guide management deci- this integration at the different levels of the model-driven develop- sions, and draft public policies. ment stack and present the different design and implementation options when possible. We corroborate some of our recommenda- 2.2 Distributed Real-time Systems tions by conducting an experimental analysis using Papyrus-RT, Our application domain encompasses distributed soft-realtime sys- an MDSD tool for embedded and realtime systems, as a testbed. tems built upon message passing. In particular, we consider dis- The rest of this paper is organized as follows: in Section 2 we in- tributed applications that adopt the Actor model of concurrency [2]. troduce our intended application domain and introduce our testbed The actor concurrency model proclaims computational entities, platform. We present our main approach in Section 3 and conduct denoted actors, as first-class citizens; much like objects in Object- our experimental analysis in Section 4. We highlight other tools Oriented Programming. An actor is a unit of execution (possibly and attempts in the literature to integrate into the IoT in Section 5. only conceptual) that, in response to a message it receives, can Section 6 concludes this work. concurrently perform any sequence of three possible actions: up- date its own internal state, send messages to other actors, and 2 BACKGROUND create/destroy other actors. Actors have well-defined interfaces that abstract their internal 2.1 IoT Applications states and govern the way they interact with other actors. The in- While an IoT application can be composed of a multitude of compo- terface of an actor exposes special communication points known as nents, they can generally be grouped into five categories: physical ports. Ports are linked using channels that mediate communication objects, gateway devices, people, services, and middlewares. and dictate which actors are allowed to communicate via a given interface. Physical objects. Physical objects, or Things, are everyday de- The actor paradigm continues to prove itself as one of the premier vices augmented with sensors and/or actuators and serve a specific choices for the design of scalable and highly-distributed systems, purpose. These devices are often equipped with a short-range com- as evident by its adoption in concurrent languages such as Erlang munication chip such as RFID, Bluetooth, or ZigBee, and their com- and Scala. Its inherently concurrent, modular, decoupled, and fault- munication is restricted to immediate gateway devices. Common tolerant structure, lessen many of the problems associated with examples in a smart home application include smart light bulbs, distributed systems and alleviate the developers from having to deal electronic locks, and smart thermometers. with concurrency control and thread management. In short, the Gateway Devices. Due to their constrained nature, physical ob- actor model makes it easier to write correct concurrent and parallel jects are not typically capable of communicating with the outside programs, by design. It is therefore to no surprise that a signifi- world. Instead, they rely on gateway devices, also known as IoT cant number of model-driven development tools and languages for hubs. A gateway is a small computing device equipped with mul- real-time systems also adopts this model. Examples includes: Math- tiple radio technologies to manage Physical Objects, as well as Work’s Simulink, The Generic Modeling Environment (GME) [22], LAN interfaces, such as Ethernet or WiFi, to connect to Internet Real-Time Object-Oriented Modeling (ROOM) [32], and Ptolemy services. Gateway devices vary in capabilities, but are typically [12], just to name a few. programmable and provide an API that allows external actors to monitor and control connected Things. Examples include Sam- sung’s SmartThings Hub, Wink Hub, and Raspberry Pies running 2.3 The Model-Driven Development Stack the open source openHAB software, to name a few. In this work, In general, we can identify three components in a typical model-