Sequential Behavioral Modeling for Scalable IoT Devices and Systems Ege Korkan1, Sebastian Kaebisch2, Matthias Kovatsch2, Sebastian Steinhorst1 1 Technical University of Munich, Germany, Email: fege.korkan, [email protected] 2 Siemens AG, Germany, Email: fsebastian.kaebisch, [email protected] Abstract—The Internet of Things (IoT) enables connectivity be- tween devices, thereby allowing them to interact with each other. A recurring problem is the emergence of siloed IoT platforms due to proprietary standards. Recently, the World Wide Web Consortium (W3C) proposed a human-readable and machine- System understandable format called Thing Description (TD). It allows to uniformly describe device and service interfaces of different IoT TD 2 TD 2 4 standards with syntactic and semantic information, and hence 1 3 Thing A Thing B 1 3 enables semantic interoperability. However, describing sequential behavior of devices, which is essential for many cyber-physical systems, is not covered. In this paper, we propose a systematic X TD Contents: asd way to describe such sequential behavior as an extension within Possible TD ­ Identification TDs, thereby increasing their semantic expressiveness through Interaction: Thing C possible, valid state transitions. This enables safe and desired asda ­ Interaction List operation of devices as well as scalability by modeling systems - Property ­ Data Type as sequential compositions of Things. We show in a case study - Action 1 ­ Data Access that previously unmodelable behavior can now be expressed and - Event TD ­ Protocols the overall manual intervention requirements of state-of-the-art ­ Security implementations can be significantly reduced. Figure 1: An abstracted view of an IoT System with 3 IoT Devices each with Index Terms—Internet of Things, Thing Description, CPS, an associated Thing Description (TD). The arrows demonstrate composition Model-driven development, System Testing of greater functionality than the devices themselves, necessitating sequential behavior between devices. I. INTRODUCTION The Internet of Things (IoT) brings connectivity to electronic Consider a temperature sensor used with a cloud IoT platform devices and allows them to connect with each other. Due to the and a local ventilator. Between them, TDs enable to create a large variety of IoT devices and application scenarios, they all temperature-controlled ventilation system directly composed of bring their own properties such as different processing speed or the capabilities of these two physical devices. The advantage of range of connectivity, desired run-time or energy consumption, such interoperability for machine to machine communication is safety features etc. This creates a fragmentation in IoT, with to enable system functionality without prior knowledge about different standards to interact with the devices and to represent the interfaces between the devices. them, each optimized for a specific application area or device Such a sensor’s functional capability, data structure and type. Consequently, such fragmentation hampers composing access points will be referenced in the TD of the sensor. Hence, applications beyond the functionality of the individual devices. the ventilator will be able to access the sensor data due to the In the electronic design community, languages such as provided access points and will be able to understand the data SystemVerilog have proven to be an effective standardized due to the data structure described in the TD. representation for the entire development cycle, from design The previous ventilation system example is abstracted in to verification and for a very wide range of application areas. Fig. 1. This system has three IoT devices, each possessing a However, in the IoT domain, companies introduce siloed IoT TD. Within the system, each IoT device, to which we will in platforms that come with proprietary standards even within the following refer to as a Thing2, can read the TD of another similar application domains. Thing and interpret it to understand the information such as Consequently, there is a necessity that an IoT device can the Thing’s interactions, supported protocols, data structure, be represented with a description of capabilities which can be how to access the data etc., as described in the column on the understood and interpreted by other devices and standards. right of Fig. 1 (TD Contents). During the course of the paper, Here, a common ground can be created by enabling to an exposer Thing accepts requests provided in its TD, whereas describe an interface to different standards in a well-defined the consumer Thing reads a TD and interacts with the exposer representation. For this purpose, the Thing Description (TD) Thing. [1] was introduced recently as an open description format for An interaction is the description of a specific capability of devices with connectivity of any kind which is human-readable the Thing, representing the data structure, access protocol and and machine-understandable. The TD is not a standard to access link. For example, reading the temperature value is such replace other IoT standards, but it enables to describe them an interaction with the Thing. Similarly, rotating the fan is through syntactic and semantic information. also an interaction that acts on the physical world. In a TD, one would find a list of interactions and how to access them. With the support of the Technische Universitat¨ Munchen¨ – Institute for Advanced Study, funded by the German Excellence Initiative and the European Interactions are illustrated by numbered boxes in Fig. 1 and Union Seventh Framework Programme under grant agreement n◦ 291763. they will be explained in Section II in more detail. 978-1-5386-6418-6/18/$31.00 ©2018 IEEE. Personal use of this material is 2When the word Thing is used with a capital letter, a Thing means, an object, permitted. Permission from IEEE must be obtained for all other uses, in any either virtual or physical, that can be communicated with. current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. DOI: 10.1109/FDL.2018.8524065 In Fig. 1, Thing A has three interactions and all these Related work is discussed in Section V and Section VI interactions can be used by Thing B and C to interact with concludes. Thing A. Referring to the temperature-controlled ventilation system example, interaction 1 of Thing A can be reading the II. THING DESCRIPTION temperature value and the interaction 4 of Thing B can be rotating the fan. The Thing Description (TD) approach has been introduced Problem Statement. With the current TD standard, it is in September 2017 (First public draft) by the Web of Things possible to build the system described in Fig. 1. However, (WoT) Group of World Wide Web Consortium (W3C). This the behavior represented by arrows has to be programmed section will explain the TD approach, but most importantly, its manually which results in an implicit description of the device shortcomings and why our contribution is necessary to enable or system. TDs to describe more complex, cyber-physical systems. In An interaction can change the state of the Thing, making it the following, we will mainly focus on the relevant details accept only certain interactions (state transitions). For example, of TDs for the context of our contribution, the proposed path the red (continuous) arrow is a sequence describing such state vocabulary. transitions of Thing A. This can be requirements of sequential The path vocabulary that will be introduced in Section III, behavior, such as initializing the motor driver of the ventilator describes a series of interactions. Further information on the before setting a rotation speed. In order to execute this sequence characteristics of interactions is thus required before introducing of interactions, since such a sequence is not described in the TD, this vocabulary. In this section, we will define interactions in the person who implements the compositional system needs to order to argument the need for describing sequential behavior. have access to an operation manual of Thing A. This manual An interaction I can represent two types of messaging should describe the internal workings of the Thing (e.g. with patterns: request-response (Def. II.1) and publish-subscribe a state machine) and give meaning to the causality between (Def. II.2). interactions. Definition II.1. (Request-Response) Similarly, the green (dotted) and blue (dashed) arrows in For a request p 2 client and a q 2 server, the pair is defined Fig. 1 illustrate sequential behavior between multiple Things as follows: and are not expressed anywhere, thus need to be implemented p ) q (1) manually. For example, we would like to express that the green (dotted) arrow represents the aforementioned temperature Definition II.2. (Publish-Subscribe) control functionality in the correct order and with a causal Notifying an event only in matching subscription intervals relation: reading a temperature value and then rotating the is defined by [2] as follows: ventilator. This shows that executing multiple interactions can provide another meaning that is not previously given in a single 8e 2 nfy(x) 2 hi ) nfy(x) 2 Si(C) s:t:C(x) = >; (2) interaction. To solve this problem, a new interaction can be with implemented that provides the same meaning of executing • e, the event the subscriber subscribed to; multiple interactions. This is possible during the development • x, the information generated from the process; phase of Things, but for non-reprogrammable, legacy devices • nfy, the notification of the information; there is no such option. • h, a local computation that generated x; Contributions. In order to avoid that each interaction is • S, the interval between subscription and unsubscription; executable at any given time or multiple interactions can be • C, the subscription request by the subscriber; executed in any given order, in this paper, we propose the • >, the pattern of the event to subscribe to at the server specification of sequential behavior within TDs.