As devices, platforms, and technologies for IoT (Internet-ofThings) and robots, develop, the question of how to best specify the behavior of such systems so that it is both robust and manageable becomes central. Current practices may su ce when working with simple requirements. However, behavior speci cation given in current languages often become unwieldy as they grow to accommodate complex conditions, exceptions, and priorities. To address this, we propose to use the scenariobased programming approach, and speci cally, the graphical language of live sequence charts (LSC). This addresses one aspect of the speci cation growth issue by allowing a natural break-down of the speci cation in alignment with the requirements. The other aspect of our solution, aiming at further simplifying and shortening the speci cation, is based on subjecting these scenarios to context|a key concept in IoT and autonomous robot modeling. Speci cally, we propose additions to LSC for subjecting behavioral scenario charts to contexts and a methodology to work with these idioms.
The Internet of Things (IoT) is gaining attention from both industry and academia.
In its core, the IoT technology allows \people and things to be connected Anytime,
Anyplace, with Anything and Anyone, ideally using Any path/network and Any
service" [
Bill Wasik [
A key ingredient in rich IoT interactions is context. Contexts can be de ned as
information that can be used to characterize the situation of entities or processes in
a system [
Towards the third phase in Wasik's description of IoT evolution, we propose in this paper to use rich speci cation languages that allow scenario-based (multi-step) speci cations. Using a language that is capable of modeling complex behaviors as a composition of stand-alone scenarios, each of which introduces multiple actions and triggers, as well as constraints that a ect other scenarios, we aim at more natural speci cations that better capture the scenarios that users want to express.
The speci cation language that we propose is based on the LSC language [
Following IoT systems' characteristics by Perera [
RQ2 acting upon historical data (stateful), e.g., for reacting to sequences of events. RQ3 desired behaviors|the system core that aim at supporting various scenarios. RQ4 undesired behaviors|to specify explicitly behaviors that the system implicitly avoids. This allows for catching mistakes as a con ict between a negative behavioral requirement and a future speci cation or a code artifact.
RQ5 contexts, e.g., location, time, a sequence of events, or a particular system state. Since the behavior of IoT systems is inherently context-dependent, the context should play a major role within the speci cation.
RQ6 run-time adaptation policy that includes con ict resolution and priorities.
RQ9 be modular and allow for incremental speci cation, as the requirements are not usually known in advance and changes would be continuously introduced. RQ10 have formal semantics for simulation, formal analysis, optimization, etc. RQ11 allow the speci cation of a generic functionality/behavior, as there are many devices (or their software counterparts) with similar behavior.
RQ12 support weaving of cross-cutting concerns as security, and error handing.
The LSC language on which we base this paper already supports most of these requirements. The rest are covered by the extension we discuss in the next section.
In this section we present Contextual Live Sequence Charts (Contextual LSC),
an extension to the Live Sequence Charts (LSC) language. We explore the syntax
through an example and discuss the semantics later on. We follow an example inspired
by Samsung's ARTIK-Cloud introduction video 3 that takes place in a smart home
system. ARTIK-Cloud [
Turn on hallway light when the front door opens front door
hallway light setState(\open")
Live Sequence Charts (LSC) [
In this paper we refer to the PlayGo [
In LSC, the vertical lines, termed lifelines, represent instances of system classes, and horizontal lines represent messages (events, or method invocations) between system instances. Dashed and solid message lines represent monitored and execution messages, respectively. In our chart, for example, the scenario begins with a monitored message represented by a dashed arrow. Once it is triggered (in our example, the door sets its own state into \open", in a lower software level), the execution engine advances the program 3 https://www.youtube.com/watch?v=J9vhdt5jXf0
Name:
Turn o ce lights on/o based on motion detection light o ce
mSensor
(from the top of the chart to its bottom). The next message is a solid arrow, representing
an execution message. The engine will call the corresponding method (when it is not
forbidden by another scenario). Here, the setOn method of the hallway light object is
called. Prioritizing events and smart event selection are possible as well (addressing
RQ6), however due to lack of space, we will not elaborate on all the language features.
The reader is referred to Harel and Marelly [
Incrementality and Alignment With the Requirements. Our next
example demonstrates how each requirement of a system can be modelled in a separate
module, allowing for the two main features of LSC|incremental development and
natural alignment with the requirements (see [
Unfortunately, after the system was deployed, a aw was detected as the light turned o when a person did not move inside the room. While we can add a condition before calling setO , the scenario-based paradigm encourages us to add a new scenario for each new requirement. In this case, we add an anti-scenario, depicted in Fig. 2b. Once a motionStopped call is monitored, the scenario collects the current time, waits for three minutes and then waits for the setO event to take place. If the setO method is called before the three minutes pass|it will violate this scenario and the execution engine will not choose to execute the setO method. The scenario in Fig. 2b thus forbids the turning o of the light for three minutes. This also addresses RQ4. 3.2
Subjecting charts to contexts
As described in Section 1, a powerful context management facility is an essential tool for modeling IoT. In this section we propose an extension of the LSC syntax with idioms for handling contexts. Speci cally, we propose to handle contextual data in terms of a relational data model, addressing RQ1 and RQ5.
In typical IoT applications, it is often required to subject a behavior to a context. We propose to do this by an automatic instantiation of an LSC chart, that serves as a template, whenever an instance of the context arises. Speci cally, we propose semantics that allow to associate scenarios with a query over the context data. Using the standard dynamic binding semantics of LSC, we show in Section 4 how a new instance (called `live copy' in the LCS literature) is created to handle each instance of an answer to the query. We then say that the chart is \subjected" to a context and speci es a behavior that is attached to this context. We propose that the `select' queries and the `update' commands will be managed in a separated `query and command repository' that serves as an abstraction layer between the data-model and the charts (i.e., behavioral speci cation), giving names to contexts that can be used by charts.
Name: Turn lights on/o based
on motion detection Context: r 2 O ce room (a) Turn the lights on/o (b) Anti-scenario: Delay turning lights o
Fig. 3. O ce-room Context
The concept describe in the above paragraph is best explained by continuing our example, as follows. We now refer to an o ce building with several o ce rooms that have the same setup of a smart light and a motion sensor. We wish to de ne this setup as a template, and set prede ned scenarios for it (i.e., the scenarios in Fig. 2). Moreover, consider a smart building with various room types (e.g., as o ce, bedroom, kitchen, etc.), where all rooms of the same type|have a set of baseline scenarios. To this end we add a data type called Room to the context data model, to be used as a glue for smart home devices in one room. To the query and command repository we add the \O ce room" query, de ned as \r 2 Room: r.type=O ce" (assuming we add a `type' attribute to Room). Each of our scenarios can then be bound to the query results, thus adding room-type-based scenarios. Fig. 3 replaces the o ce lifelines of Fig. 2 with r 2 O ce room. The smart light and the motion sensor are now members of r, as well as the room type. There are two important syntax changes: 1) The dashed lifeline frame denotes that the instance identity is unknown during compile time, thus the binding is done dynamically during runtime (we bind r to each instance of the context, i.e., we apply the universal binding rule of LSC); and 2) The chart properties are now its name and the query that it must bound to prior its execution. In our example, the binding to r succeeds if and only if there is an instance of Room with the type of O ce. We say that the chart is bound to a context query, and more speci cally that it is subjected to the `O ce room' context. The explicit introduction of context to the language addresses RQ5. and RQ12, whereas its weaving to the actual behavior addresses RQ11.
In some cases we wish to re ect modes or states of our system (e.g., emergency mode, power-saving mode, etc.). Consider, for example, a case of an emergency where we wish to temporarily keep all lights on, until the emergency situation ends. Fig. 4 handles this new requirement by adding a new context data type called Emergency, and binding an anti-scenario to it. Even though the scenario does not include the Emergency lifeline, the entire scenario will be triggered only if both queries are satis ed, i.e., there exist both Emergency (a singleton in this case) and Room instances.
Sometimes, the chart needs to be bound to a dynamic environmental changes (e.g., someone is in the room, there is a meeting in this room, etc.). Consider, for example, the lights scenarios in Fig. 3. The motion sensor signaled the room that there is a motion Name: Lights During Emergency Context: r 2 Room, e 2 Emergency and the room deduced that there is someone in the room. However, there might be other ways to detect a person such as a camera or a microphone or a combination thereof. Thus, the detection that there is someone in the room should be abstracted to new scenarios (described below) that will execute `update' commands to the context data. These commands will dynamically start and end a context called `Nonempty room' (i.e., a new answer will be generated for this query). The light scenario is now cleaner, as depicted in Fig. 5. To detect the end of the `Nonempty room' context and set the lights o , a special prede ned event, `ended(<context name>)', is monitored.
We propose a translation from contextual LSC to standard LSC. This translation
provides formal semantics (RQ10) as it transforms charts that apply the new idioms
to charts that only use idioms with formally speci ed semantics. At the core of the
translation is an embedded database system that runs within the execution engine. The
execution of LSC speci cations together with external systems is well de ned (using
the super-step semantics of LSC [
We suppose that we have a (real-time) database system for maintaining context data. We assume that context `select' queries can be automatically translated to database views that allow for triggering a stored procedure whenever a record is added or removed from a view. We also assume that context `update' commands can be translated to stored procedures that, when invoked, update the database as required (by adding, deleting, and changing objects and object relations).
With these assumptions, standard LSC semantics allows for triggering an event whenever a new answer to a query becomes available. This enables us to translate contextual charts, i.e., ones that are subjected to context, as follows. For every context query the standard LSC contains a dynamically-bound lifeline (this lifeline is conveniently hidden in the original contextual LSC). The standard LSC chart then starts with monitoring the event of creating this context object, and proceeds to synchronize with all other objects in the standard chart. The message that monitors the contextcreation event points to the object that the query returns (like r in the phrase \r 2 Nonempty o ce room") as an unbound parameter. Once the event is triggered (when a new view-record appears), the chart variable is bound automatically. When a chart is subjected to multiple context queries (like \r 2 Nonempty o ce room, e 2 Emergency") its translation monitors all view-record-added events. The view-records may be created in any order, i.e., any triggering order of the monitored events needs to be detected. We thus allocated in the standard LSC a separate object with a separate lifeline per view. The context object also has a record-removed method, allowing for charts to explicitly monitor context completion. Fig. 7 depicts the translation from our contextual LSC syntax to the PlayGo LSC syntax. Since we wanted this lifeline to be hidden from the programmer, the translation also includes a chart which that is hidden altogether that monitors the record-removed event, and generates an `ended(<context name>)' event. This chart propagates the record-removed method to the involved objects. For example, The `ended' message in Fig. 5 is this propagated message.
As shown in Fig. 6a, we also propose to allow for using the query and command repository as an explicit lifeline represented by the gears symbol. The lifeline is translated to a regular LSC lifeline with an execute method that modi es the database.
In this section, towards a partial answer to RQ8, we elaborate on a methodology for using the proposed language for con guration and customization of IoT installation. We describe the methodology using a running example of specifying a smart-building system. We rst list a set of requirements and introduce the methodology and demonstrate it via these requirements. Next, we introduce additional requirements and re ne the system speci cation, demonstrating the exibility and agility o ered by the methodology.
Name: Turn on/o o ce lights
based on a person detection Context: r 2 Nonempty room
Physical : R1) The room types include o ces, kitchens, and restrooms; R2) Each room has a motion detector and a smart light; R3) An O ce has a smart air-conditioner; R4) Events are emitted when a motion starts or stops.
Behavioral : R5) In all rooms, the light should be turned on once a motion is detected, and should be turned o if there is no motion detection for three minutes; R6) In o ce rooms, the air-conditioner should be turned on once a motion is detected, and should be turned o if there is no motion detection for three minutes; R7). In emergency, lights that are on must not be turned o .
Our proposed methodology is depicted in Fig. 8. It consists of four steps that can be repeated iteratively, where the order of the steps can emerge as the development progresses. In Fig. 8 the steps are indicated as ellipses whereas the artifacts are presented as rectangles. In the following we elaborate on the various steps and artifacts.
List of Requirements
Context Specification
Context Population
Context Composition
Contextbased
Behavioral Specification Context Context Context Schema Instances Queries
LSCs Context Speci cation Following the context-oriented notion we propose in this work, we start the development with specifying the contexts in mind, in light of the given requirements. In our view, everything may be included in as context data, ranging from physical entities to logical ones. A context data type might be characterized with attributes, specifying what kind of data is needed for operating the system (addressing RQ1 and RQ2). For example, in the case of the smart building, we may de ne the following data types: originating from R1: Building, Room, Kitchen, O ce, Restroom; originating from R5 and R6: the hasPerson attribute of Room; originating from R7: Emergency. We further de ne the devices, i.e., MotionDetector, SmartLight (R2), and AirCondition (R3). We then de ne the relationships among the data types and the devices. Of coursethis is just one of the ways to de ne the schema for these requirements. Fig. 9 presents the resulting context schema. In devising the context schema, we adopt the UML class diagram notation. Other languages may be used as well. Context Population Once the context schema is designed, we populate it with the initial prede ned data. That is, associating the actual rooms to buildings, as well as, binding the devices to the speci c rooms. This can be done visually using some kind of object diagram (instantiating the class diagram) or by populating a context database. Context Composition We now turn to de ne the context query and command repository. The repository contains `select' queries and `update' commands for querying and changing the context data. Table 1 lists the queries for our example. Context-based Behavioral Speci cation In information systems, the output of database queries is often used for reports. Here, we propose to use queries' output to dynamically bind contexts to LSC charts. In our use case, e.g., the LSC that ensures that the room's light will not turn o during an emergency (Fig. 4) binds to an Emergency instance and to all Room instances.
With these steps, we outlined our vision of how contextual LSC can be used for allowing richer speci cations for IoT systems. With the right tool support, this methodology allows for better involvement of stakeholders in the speci cation of IoT behaviors, by providing them with the subject domain vocabulary needed for e cient communication.
As development evolves, new requirements may arise. In our example these include: Physical : R8) Smart speakers are installed in all rooms (in addition to R2 devices); R9) Workers can be identi ed in the system (e.g., by smartphone), while visitors cannot. Behavioral : R10) If a worker enters a room, announce her name in the room's speaker; R11) During an emergency, turn on all lights.
To cope with these requirements, we can add object types that represent new aspects of the context. To the schema, we add a Smart Speaker data type (similarly to the other devices) (R8), and a Worker data type, both associated with Room (see Fig. 10). To the queries repository we add commands for marking and un-marking that a worker has entered a room (R10) (similar to Q5-Q6). For getting a view of all workers that are inside a room (R9), we add the \Worker in a room" query, de ned as \w 2 W orker; r 2 Room: r:workers:includes(w))". Finally, we add the following LSC charts: two for detecting a worker that has entered/left a room and executing the appropriate marking/unmarking command (R9, R10); one for turning the lights on during an emergency (R11); and one for announcing the worker name (Fig. 11) (R10).
Thanks to the incrementality feature of behavioral programming paradigm, no changes to the previous speci cation are needed, we only added elements to the schema, to the query and command repository, and to the list LSC charts. Office
Restroom Kitchen
Name:
Announce workers names Context: Worker in a room Fig. 11. Announce workers names 6
We identi ed the needs and proposed a modeling language towards more robust and manageable speci cations for the behavior of IoT. We argued that IFTTT rules may become unwieldy as the complexity grows, and showed how our language allows for consolidation of several rules into a single speci cation object. We also developed a proof-of-concept tool that allows us to produce and execute the diagrams in this paper. With this experience, we proposed a methodology for specifying the behavior of IoT.
In future work, plan to quantify and validate the advantages of the proposed language in comparison to existing ones, like IFTTT, via an empirical study in which subjects will specify an IoT system in multiple ways. We also plan to integrate the language and methodology in a holistic development environment.