Representing Internet of Things device semantics
Master Thesis
Master Software Engineering
University of Amsterdam
Supervisor: Paul Griffioen
Supervisor email: p.r.griffioen@cwi.nl
Host organisation: Triggi B.V.
Host contact: Markus Pfundstein
Contact function: Software Engineer
Contact email: markus.pfundstein@triggi.com
Ger Krijnen
Student number: 6052134
Email: ger.krijnen@triggi.com
Contents
1 Introduction 3
2 IoT Background 6
2.1 Current Research . . . 6
2.2 IoT applications . . . 7
2.2.1 Transportation and logistics . . . 8
2.2.2 Healthcare . . . 9
2.2.3 Smart environment . . . 10
2.2.4 Personal and social . . . 11
3 Research Questions 12 4 API Research 14 5 Representing IoT systems as state transition systems 19 5.1 Device Representation . . . 19 5.2 System Representation . . . 22 6 Domain model 25 7 Proof of concept 29 7.1 go-EFSM . . . 29 7.2 go-IoTDM . . . 32 8 Analysis 34 8.1 EFSM’s . . . 34 8.2 Domain Model . . . 40 9 Conclusion 42 9.1 Future Research . . . 43 10 Appendix 45
1
Introduction
The purpose of this thesis is to research the possibility of a generic Internet Of Things (IoT) device representation. The purpose of this representation is to al-low sharing of device semantics while at the same time alal-lowing control over the device through its API. Representing semantics is historically a hard problem in Software Engineering. However, the IoT field has the luxury of dealing mainly with stateful devices. The states within these devices convey information about semantics, which can be extracted. A generic description of IoT device’s with semantics should reduce the custom work that needs to be done to couple to each device’s API for people and organisations looking to integrate with mul-tiple IoT devices. Therefore, the main research question of this thesis is: can a semantical description of IoT devices reduce the development time and increase the maintainability of IoT solutions?
Literature research into the domain has shown that there is currently no gener-ally accepted domain model or ontology, which could have been used to provide insight into the IoT domain. However, research by Atzori et al.[3] divides the domain into four areas. These four areas, which are listed below, are used to research the spectrum of IoT applications.
• Transportation and logistics • Healthcare
• Smart environment • Personal and social
This research is used to construct a prototypical domain model that can serve information about the semantics of IoT devices. It does so by providing a database of profiles. A profile is a low-level capability, expressed as variable, that multiple devices have in common. For example, a lockable profile would contain a single boolean variable called locked. Furthermore, the domain model also provides conversion of values within numeric ranges
The finite nature of these stateful IoT devices causes state transition systems to be a good fit for representing most IoT devices functionally. A description language for state transition systems has been developed in order to be able to instantiate them at runtime. Furthermore, this description allows us to couple these systems to the domain model and the device’s API. We conducted research on 25 popular API’s which has shown that JSON is the prevalent description language for API’s, therefore the description is based on JSON.
Philips Hue Lights1 are used as a running example of an IoT system to
clar-ify some key points. Figure 1 shows how the Philips Hue system and state transition systems are integrated.
In the figure there are three lamps that use a bridge to connect to the API. The Hue Lamp Model is a specific instance of a description in the aforemen-tioned description language. This description is then used to fetch all instances of the lamps and create an individual state transition system for each of them. Note that each instance has its own connection to the domain model in order to provide conversions between the API’s representation of variables and the domain model’s.
Figure 1: Philips Hue and state transition system integration example
A prototype of the system from figure 1 has been built. This prototype proves that it is possible to generate state transition systems for IoT systems with API’s in such a way that the system’s semantics can be obtained.
This thesis is hosted by Triggi B.V.1. Triggi is a company that aims to
be-come a one-stop-shop for IoT devices. All the devices that you connect through Triggi can be controlled through custom made rules, e.g if my thermostat goes to the away mode, turn off the lights in the living room. Triggi stands to ben-efit profusely from a generic IoT device representation with information about device semantics. This would mean that third parties could provide all the infor-mation necessary to automatically create a connection to their devices. Whilst giving Triggi the opportunity to inform their users about the capabilities of the device, without having to read documentation on every device that is coupled. The rest of the thesis is organised as follows. The next section gives an introduc-tion into the current state of research regarding the IoT and its applicaintroduc-tions. Section 3 presents the main and supporting research questions. Section 4 is
about the previously mentioned research into API’s that was performed. Sec-tion 5 concentrates on representing IoT systems as state transiSec-tion systems. Section 6 describes the domain model. Section 7 & 8 respectively handle the proof of concept of the Extended Finite State Machine (EFSM) and domain model that was made and the resulting analysis. Finally, section 9 contains the conclusion and suggestions for future work.
2
IoT Background
The IoT has been a huge point of interest lately. A lookup of news articles on newslookup.com reveals that there have been roughly 67000 news articles about the IoT from the start of 2016 to mid-may. A market analysis shows that the projected size of the IoT is between 20 and 50 billion devices in 2020 [16]. The same analysis shows that the potential economic impact of the IoT is likely to be between $2.7 trillion and $6.2 trillion per year.
2.1
Current Research
‘The Internet of Things: A survey’ by Atzori et al. highlights the most important scientific activity in the IoT field [3]. It shows that there are three main areas of research:
1. Standardisation
2. Addressing and networking 3. Privacy and security
In terms of standardisation most of the work is being done in coming up with standardised solutions for identification and networking. There is surprisingly little research to be found regarding domain models, ontologies and service/de-vice discovery. Interesting as well is that most standardisation efforts view the IoT as an extension of RFID technologies. This is most likely because the main use cases of RFID , namely authentication and localisation, are also functions that are expected of IoT devices.
Addressing focuses on the unique identification of smart objects. With a pro-jected size of 20-50 billion devices within the next couple of years, this is one of the major issues to overcome if the IoT wants to become a mainstream technol-ogy. One of the main focus points for networking is finding suitable alternatives to the TCP protocol. The TCP protocol, while a global standard, is not very appropriate for the IoT. The buffers and overhead imposed by TCP, are ex-pected to provide significant strain on these units that have very little memory and processing power. Furthermore, keeping TCP sessions alive will also use more power. A lot, if not the majority, of IoT devices are expected to be bat-tery powered. So this could be a big issue. Unfortunately there are no clear-cut solutions for this problem at the time of writing.
The privacy and security research field is occupied with authentication and data integrity. Since most IoT devices are not meant to be supervised and are usually located in remote areass, attacks like the man-in-the-middle attack are fairly simple to perform. Furthermore, IoT devices have limited computing capabilities and (battery) power. This means that using strong and complex encryption schemes to protect user data can provide to be very challenging.
These three approaches concentrate on what the IoT could become. Mean-while there is already an upcoming IoT scene. With the advent of technologies like Lora and initiatives based on it, such as LoraWAN1, IoT has become an accessible field for hobbyists. Providers like The Things Network2 or Lorio T3 can provide coverage for entire cities on a limited budget. For example The Things Networks states the following on their website: ‘The city of Amsterdam was covered with only 10 gateways at the cost of 1200 dollars each.’
Aside from Lora most currently available IoT devices (e.g Philips Hue Lights, Nest Thermostats, Netatmo Weather Stations) use WiFi or LAN to connect to the internet. There is no clear standard on how users can interact with their devices, but virtually all manufacturers offer their own implementation of an HTTP based API.
Another observation is that the bulk of this research is focused on how IoT devices communicate. As stated before, there is a lack of information regarding domain models and ontologies for the IoT. The closest thing that is available is the IoT Domain Model from the book ‘Enabling Things To Talk’ by the IoT Architecture group [5], displayed in figure 11 on page 46. However, the main purpose of this model is to give insight into the communication flow between devices, servers and users. There is no clear domain ontology about the capa-bilities of IoT devices. That is why the next section focuses on the spectrum of applications that the IoT can host.
2.2
IoT applications
In the introduction of their book: ‘The internet of things in an enterprise con-text’ Haller et al. state that the IoT has its roots in the RFID technology [9]. This means that current applications of RFID, mainly in the object tracking and identification domains, are likely to be popular choices for a conversion to an IoT based approach.
Because there is no universally accepted definition and the broad scope im-plied by its name, there are many applications that consider themselves IoT applications. These applications will be identified based on two staple papers that have examined the IoT domain. The first being ‘The internet of things: A survey’ by Atzori et al. [3]. The second paper is ‘Internet of things: Applica-tions and challenges in technology and standardization’ by Bandyopadhyay et al. [4]. Atzori et al. have grouped these applications into five main categories:
1. Transportation and logistics 2. Healthcare
1https://www.lora-alliance.org/What-Is-LoRa/Technology 2
http://thethingsnetwork.org/ 3https://www.loriot.io/
3. Smart environment 4. Personal and social 5. Futuristic
They have also created the overview in figure 2. While the paper does not go down to the low level information about device functions that is needed to create a Domain Model, it is still a helpful guide to examine the application domains. Therefore this section will explore the domain according to those categories. Note that the Futuristic category has been disregarded, as it is not really a do-main as much as a time frame. Furthermore, the way in which those applications are expected to use the IoT is not significantly different from the applications in the other four categories.
Figure 2: IoT application domains [3] 2.2.1 Transportation and logistics
Bandyopadhyay et al. foresee two important example applications regarding transportation [4]. Firstly, IoT can help the aviation industry with problems caused by suspected unapproved parts. These are parts that are not guaranteed to conform to the stringent safety regulations of the aviation industry. Bandy-opadhyay et al. suggest creating an IoT system based on RFID in which the parts can be authenticated against a decentralized database of approved parts at install time. Thus using the IoT to extend an RFID solution with the power of the internet.
Secondly, they envisage that the automotive industry will use the IoT to cre-ate better Intelligent Transportation Systems (ITS). The concept of ITS covers
almost any computer based solution that helps with transportation, but in the automotive and IoT industry it makes sense to view these systems as one of two types. Internal and external systems. Internal systems are systems that run within cars, e.g a system that monitors the distance to other cars together with its own location on the road and communicates that to other cars so all cars can be aware of their surroundings. External systems are IoT solutions that are located outside of vehicles, e.g camera’s that monitor traffic density so that route planning applications can better estimate the quickest route.
Atzori et al. describe an industrial picture of real-time supply chain manage-ment [3]. The concept is fairly simple. At certain points in the supply chain, the product, or its subparts, are scanned and entered into a database. This database can then be accessed to look up information about the product throughout its lifecycle.
Related to this application are the Track & Trace systems offered by major package shippers like FedEx1, DHL2 and UPS3. The package shippers handle only a limited part of the supply chain, since they only deal with shipping a product. However their system is similar to a complete supply chain manage-ment system, as the package is scanned at different parts of its journey after which the data is made available to the customer through an API.
2.2.2 Healthcare
Bandyopadhyay et al. predict three main applications within the healthcare industry [4].
Firstly, they believe that there will be an implantable IoT device that can serve as a digital health record. This device can then be accessed during a medical emergency to find out if a person has any special conditions that need to be taken into account.
Secondly, the IoT could assist elderly people with independent living. De-vices could be made that monitor vital signs and register when someone falls. The IoT application can then alert caretakers and family when the elderly per-son needs assistance.
Finally, the pharmaceutical industry stands to benefit from the IoT as well. Counterfeit drugs are a big problem in this industry. An application like ‘sus-pected unapproved parts’ solution for the aviation industry can be used in this domain too. Allowing for your drugs to be scanned at a pharmacy to confirm that they are legitimate. Another application can be a smart medicine cabinet that is aware of its contents. The cabinet can then monitor if a patient is taking their drugs on the prescribed schedule and order new drugs at the pharmacy if the current supply is due to run out soon.
1http://www.fedex.com/us/developer/web-services/index.html
2http://www.dhl-usa.com/en/express/resource_center/integrated_shipping_ solutions.html
Atzori et al. identify four subcategories of applications for the healthcare do-main: tracking of objects and people, identification and authentication of people, automatic data collection and sensing [3].
Tracking of people and objects is intended to provide hospitals insight into the flow of everything within their walls. If personnel urgently needs a certain machine, the nearest (free) one can be located. Or if a patient with a certain condition needs assistance, the closest staff member with knowledge about their condition can be alerted.
Identification and authentication is used to grant staff access to locations and equipment. Which helps against medicine that mysteriously ‘disappears’. Another use case is to authenticate a patient before surgery to prevent mix-ups in surgeries or with drug dosages.
Data collection is meant to automatically collect and aggregate data on patients, providing the opportunity for medical dossiers with more detail than previously possible/feasible.
Sensing is closely related to the previous point, it relates to the usage of IoT devices to automatically collect the data about patients that will be aggregated by the data collection application.
2.2.3 Smart environment
Atzori et al. mention three different types of smart environment: comfortable homes and offices, industrial plants and smart leisure environments [3].
Comfortable homes and offices is the domain in which most of the IoT devices that are available to the consumer these days reside. These devices are intended to make the consumer’s life easier by automatically performing certain tasks for them. Examples include presence monitors that can automatically enable lights at night to simulate presence when there is actually no one home. Or garage door that automatically opens when you get home.
Industrial plants are expected to use RFID tags in nearly all the steps of their manufacturing process, enabling logging and measuring of every step in the process. This can open up new possibilities for process improvement.
Smart leisure environments provide new ways of interaction in public envi-ronments. Examples given are smart thermostat control in museums, so that exhibitions regarding the ice age are colder than those dealing with the dinosaurs for example. Or an automatically adjusting machine in the gym. The machine can identify the user and pre-set the weights to their level potentially reducing injuries due to trying to lift weights that are too heavy. And also giving the opportunity to share the user’s results with their personal trainer.
Bandyopadhyay et al. add to this an IoT system that can help with agricul-ture [4]. Every animal on a farm could have an IoT device implanted to provide real-time information on their location. This could be helpful during outbreaks of contagious diseases. Furthermore, many agricultural subsidies are (amongst other things) dependent on the number of animals in a herd. If every animal on a farm can be identified with an IoT system, counting them becomes easier and fraud harder to commit.
2.2.4 Personal and social
Atzori et al. present four major application types: Social networking, historical queries, losses and thefts [3].
Social networking IoT applications could post updates to social networks. For example automatically checking in on foursquare when you enter a restau-rant.
With historical queries, a personal application could be built that stores its data in a cloud calendar, which can later be used to review what a person was doing on a certain date. This definition by Atzori et al. stretches the meaning of IoT, because it is more related to regular cloud applications.
Losses could be prevented by tagging all important and/or expensive per-sonal objects with a small IoT device that regularly pushes its position to an application. If a user then forgets the location of one of those devices, the database can be consulted to retrieve the object.
Thefts could be identified and hopefully solved sooner by a similar system. In this case when a personal object is more than a certain distances removed from its owner, the owner can be alerted.
3
Research Questions
The previous section identified the different types of applications within the IoT domain. These applications can be divided into two additional categories. Firstly, applications which have a complete flow from input to output. In other words applications that gather data, if needed, and use that to perform some kind of output. Secondly, gathering applications. These gather sensor data and push it to some sort of database. This database is then manually analysed later or accessed by some other application.
These database oriented applications are not the intended target of this the-sis, since the states of database systems represent the complete collection of data that is present within the system. This is different from the applications that perform output, as their states represent what kind of action the device is currently performing. Thus if we create a model of this database we would get information about measurements that are taken, instead of behaviour of an IoT system.
The objective of this study is to find out if a semantical description of IoT devices can reduce the development time and increase the main-tainability of IoT solutions. As stated in the previous section, most man-ufacturers of IoT devices offer an API to allow access to their data. Therefore parties that wish to make IoT solutions will need to couple with an API for each device they wish to add to their solution. These connections are quite time consuming to construct as it takes in depth knowledge of a device to know exactly what data can be extracted and how to do so. As such in this thesis we research a generic description of IoT devices that can be used to access device semantics.
Because there is no common definition for the IoT, a custom definition needs to be made in order to set a scope for this project. For the purpose of this thesis, we view the IoT as a collection of systems featuring devices that can be manipulated through an HTTP API. The final solution will be checked against the use cases that were identified in the previous section.
Questions that are raised by these definitions are what constitutes systems and devices. A device within this context means a piece of hardware (usually a sen-sor, actuator, or combination of those two) that is connected to the internet. And a system is the collection of devices bundled under an API that serve a single user. A more detailed explanation can be found in section 5.
To be able to answer this research question the following supporting questions have been devised:
1. What is the spectrum of functionality that is supported by IoT systems? This question has already been answered by the previous
sec-tion. The most significant discovery that was made in this section is that some IoT systems’ sole purpose is to store data in a database. Since the semantics of these systems are defined by the data they store, as opposed to the actions they perform, they are a bad fit to the state based approach of this thesis.
2. How are API’s structured? Insight into API structure and different technologies that are being used will be used to scope the solution so that a majority of the API’s is supported.
3. Can IoT systems be represented by state transition systems? Because of the statefulness of the IoT applications that we are targeting, state transition systems are an interesting choice to represent them. Finite State Machines leave out a lot of complexity that is introduced in the higher order models of computation, like turing machines. If this class can be used to represent semantics of the majority of IoT systems then the representation is guaranteed to be simpler than if we used a higher order model of computation.
4. How can IoT system semantics be exposed? Information about device semantics only is of real value if there is a shared frame of refer-ence. This might be confusing, as this shared frame of reference is what linguistics studies usually refer to as semantics. Note that semantics in this thesis is meant only as the actions a device can perform.
This shared frame of reference can be used to know that a capability of device A is similar to that of device B. Take for example a reference called set temperature. Likely devices to contain this capability are thermostats, freezers and ovens. This information can then be used to for example, automatically generate a UI which allows a user to choose a temperature on the Fahrenheit or Celsius scale. As such these shared references can be used to automatically provide meaningful interaction with devices. The main challenge with these references is that a device usually has more than one function, so we need to create a structure that allows to easily represent devices that have multiple functions, all of which can be shared functionalities with other devices.
4
API Research
When we look at figure 1 from the introduction we can see that the API layer is a key part of the whole system. It performs the job of facilitating the com-munication between third party applications and the hardware. Since it is a part of the system that third parties have no control over it is important to understand how API’s are built, so that we can make sure that our solution can communicate with many different types of API’s.
To get this insight we have conducted a research which compared 25 API’s to find out commonalities between them. The results from this research have been compiled into table 3 on Page 45 in the Appendix. The API’s have been taken from a couple of different domains.
Firstly, there are the current IoT devices (Philips Hue, Eneco Toon, etc.) because they represent the API’s that are specifically targeted by this thesis.
Also included are Social Media platforms like Twitter and Facebook. These have been added because their API’s are amongst the most widely used in the world, and are therefore likely to be very mature.
The final category of API’s are services. Services represent external parties that could integrate with IoT devices, for example Weather Underground can be used to provide weather data for IoT applications.
Output
What quickly becomes apparent is that every single researched API supports JSON output. While there are undoubtedly some examples to be found of API’s that do not support JSON, it is obvious that JSON is an incredibly popular choice as API output format.
Encryption
Furthermore, out of all the researched API’s only two do not support HTTPS. However, both of these API’s do not have any user specific data. These ser-vices expose geolocation information and weather data. This means that these services are usually not called directly from a user app, instead the data is usually retrieved through an intermediate server. This means that HTTPS is not strictly necessary there, as it is harder to do a man-in-the-middle attack on servers than it is on mobile devices. Even if such an attack succeeds, the only sensitive data that could be retrieved is the API access token as these API’s do not serve any user specific data.
HTTP Methods
This subsection analyses the RESTful HTTP methods used by API’s. Which usually are atleast GET, PUT, POST and DELETE. In some cases PATCH is also used as a RESTful method. Analysis of the used HTTP methods reveals
that very few API’s support PATCH requests. And the ones that do have an implementation that does not conform to the PATCH standards. The standards state that a PATCH request must contain instructions on how to modify a certain result. However, the researched API’s handled their PATCH like this:
Listing 1: Typical PATCH request PATCH / v1 / c o m p a n i e s / [ i d ]
{ ”name ” : ”new company name” }
This looks more like a partial PUT request than a PATCH request, as the operation that is being performed is completely implicit. A way of implementing PATCH that adheres to the standard is to implement JSON PATCH1. This is
however a more complicated system, and probably one of the reasons that most companies do not implement PATCH at all or implement it in the way shown above.
Also there are not a lot of API’s implementing the PUT method. Most of these API’s use POST for pushing updated resources instead. However, they do not always use POST in the right way. As stated by the IETF2: ”The
fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. ... In contrast, the URI in a PUT request identifies the entity enclosed with the request ”[7]. In other words. A POST request is supposed to be made to an URI like the following.
Listing 2: IETF Compliant POST URI POST / a p i / v1 / r e s o u r c e
Where the body of the request contains information about what instance of the resource it means, if it already exists. Whereas a PUT request will have an URI like this.
Listing 3: IETF Compliant PUT URI PUT / a p i / v1 / r e s o u r c e / i d
However, most of the API’s researched that did not have PUT for updates used the second style of requests together with the POST method.
Authentication
Of all the researched API’s 64% support OAuth2.0[12], note that Tesla’s API is not counted as supporting OAuth2.0. Tesla’s implementation only supports obtaining tokens by directly passing them the user credentials. This is fairly logical seeing as the API documentation is reverse engineered from their app. Storing credentials on the phone is not uncommon for apps. However, as ex-ternal service we should not need to store the users’ credentials for third party
1
http://tools.ietf.org/html/rfc6902 2http://www.ietf.org
apps, as this leads to all kinds of security risks. Therefore Tesla’s API does not count as a valid OAuth2.0 implementation.
Another 16% of the API’s use OAuth1.0a [11], which is an older and less pop-ular variant of the OAuth spec. However, it is generally agreed that OAuth1.0 is safer than OAuth2.0. A (controversial) blog post by the former lead developer of the spec Eran Hammer [10] elaborates the differences between the two specs. OAuth2 tries to be simpler by delegating the encryption of token to TLS[6], but at the same time it introduces expiring tokens. Which Hammer argues to be just as much of a hassle to manage as signing the requests.
In a few other cases HTTP Basic or keys contained in query parameters are used as authentication method. These methods are not secure when used unencrypted, however it should be noted that these API’s do not contain any end-user specific data. So no OAuth-like mechanism is needed to grant fine-grained control to third parties.
API Structure
The structures of the URL’s within the API’s was analysed. There are a few different categories that we discovered.
• Object Oriented (OO), which has url’s that explicitly describe the ob-ject that is being manipulated, e.g /thermostat/$id/setTemperature. • Flat, which only describe the function that is being performed, e.g
/set-Temperature
• Versioned, which have a version tag somewhere in the URL. This helps with backwards compatibility, as breaking changes can be pushed to a new tag. Giving developers more time to update their API bindings. An example is: /api/v2/endpoint.
• Firebase1, is a technology that was bought by google in 2014. It provides
a database with two-way data binding, automatically pushing updates to API consumers. It is an alternative to standard web-based HTTP API’s, removing need for a lot of manual polling of API’s for updates. Of all the researched API’s only the Nest Thermostat, unsurprisingly also a Google product, used this technology.
• Single endpoint, Flickr uses this style, where there is only a single HTTP URL and different actions are selected by changing the body of the request that is sent to the API.
Of all the API’s that we researched, the Object Oriented & Versioned is by far the most popular style of structuring API’s/
API Description Languages
All of the previous information needs to be represented in the final EFSM model. There are multiple standards that provide an API definition language out of the box. Notable examples are:
• RSDL (RESTful Service Description Language)1
• WSDL2
• Open API Specification (formerly: The Swagger Specification)3
• RAML (RESTful API Modeling Language)4
• Mashery IO Docs5
• Open Data Protocol6
• API Blueprint7
The languages were all compared on the following characteristics: Format (JSON, XML, YAML, etc.), Popularity (based on StackOverflow tags) and well-known companies that use the language. Table 1 shows a comparison of the aforemen-tioned API Description languages. All data in this table was gathered on the 21st of April 2016.
Out of all the different languages, WSDL is by far the most popular. It is also one of the oldest and most mature languages out there, WSDL has been created in September 2000. However it also uses XML as underlying format, which is rather verbose. This does not matter much for parsers, but it does reduce the readability for humans. Which makes it harder for developers to
1http://www.balisage.net/Proceedings/vol10/html/Robie01/BalisageVol10-Robie01.html 2https://www.w3.org/TR/wsdl20-primer/ 3https://github.com/OAI/OpenAPI-Specification 4http://raml.org 5https://github.com/mashery/iodocs 6http://www.odata.org/ 7https://apiblueprint.org/
Name Format Popularity Example Users
RSDL XML 0 Red Hat Enterprise Virtualization
WSDL XML 7230 Salesforce, Atlassian
Open API Specification (Swagger) JSON/YAML 1616 Google, IBM, Microsoft, PayPal
RAML YAML 118 Spotify, Cisco, VMware
Mashery IO Docs JSON 19 Best Buy, Comcast, TomTom Open Data Protocol JSON 3844 Microsoft, Citrix, IVM, Red Hat
API Blueprint Format 154 Bloomberg, GoPro, Akamai Table 1: API Description Languages
manually write their API definitions. YAML and JSON are better in this re-gard. YAML is a superset of JSON, the most notable change between the two is that YAML removes brackets to denote structure and instead uses indentation. In this regard the Open API Specification presents itself as a good option, having support for both JSON and YAML, and providing the tools to translate between the two natively within the bundled editor and on the server through libraries. The popularity of the Open API Specification is quite remarkable, considering that at the time of performing this research the project was only live for 5 months. Furthermore, it also has the most big software companies backing the technology of any of the options.
The Open Data Protocol supports JSON as well and is the second most popular. However it is also older than the Open API Specification. Development started in 20071and the current version (4.0) was released in 2014.
Both the Open Data Protocol and Open API Specification are excellent can-didates for a JSON based API description language. However, due to previous experience in working with the Open API Specification in past projects we chose it as our preferred specification for this project.
5
Representing IoT systems as state transition
systems
This section will explain how to represent IoT systems as a collection of state transition systems in a bottom-up approach. First the representation of a single IoT device is explored and then this is expanded to represent entire systems. We define an IoT device as a single piece of hardware that is connected to the internet, it does not matter if there is a bridge in between or not.
We define a system as the collection of devices and services which a single user of the API can access. In this case, we define a service as an API endpoint which does not directly control a device. For example: the groups endpoint in the Philips Hue API, which allows users to group their lights together and send commands to the entire group with a single action. As groups are purely virtual entities, this endpoint is a service.
This definition implies that entities like RFID tags are external to the system, since they have no internet connection. On the other hand the sensor that reads RFID tags and communicates with other devices is a part of the system. This means that RFID and similar technologies can be represented as a simple connected sensor.
5.1
Device Representation
Most of the IoT applications in the section 2.2 are composed devices that per-form relatively simple actions. Actions include either taking sensor measure-ments of one variable, e.g a temperature sensor. Or performing a simple action, e.g turn on the light. Even more complicated IoT devices still use (a combina-tion of) relatively simple accombina-tions. Take for example a thermostat, a thermostat will only turn on the boiler if the desired temperature is higher than the current temperature. This is a combination of 1 sensor measurement (temperature) with 2 actions (setting the desired temperature and activating the boiler).
Furthermore, most of the IoT applications listed in section 2 are state based, e.g the smart thermostat is in a heating or idle state or the hospital employee authentication system either locks or unlocks a door.
This combination makes IoT systems a good fit for representation by a state transition system. The (arguably) most well known system to represent state transitions is a Finite State Machine (FSM). Another option that might come to mind is the usage of Hoare Logic [14]. Both Hoare Logic and FSM’s could probably be used to successfully describe IoT device behaviour. However, if we used Hoare Logic states and transition actions would be encoded into the preconditions and postconditions. This would lead to an implicit declaration of states and transitions. Whereas in FSM’s states and transitions are explicitly defined entities. Explicitly defining these entities in the system representation will make it easier to prevent mistakes.
For example, if we assume that both options are internally represented as a graph. If we have to explicitly define states in our representation, a faulty
transition can be spotted by a reference to a node that does not exist. If the states are implicitly created, this faulty reference would lead to a new node be-ing created. We would then have to analyse the graph and find disconnected sub graphs which are caused by this mistake. While this is not a very hard problem, it is certainly harder than checking for an existing reference. Therefore using FSM’s will generally lead to a better device representation.
However, there are a couple of problems that arise by representing IoT ap-plications with classical FSMs.
Firstly, while creating the proof of concept, which is described in section 7, the amount of states that had to be administered grew rapidly. There needs to be a state for every combination of variables. We illustrate this by simplifying the Philips Hue lights to only allow switching between on/off states and setting the color and brightness. According to the API there are three different ways to set the color of lights:
1. hue and saturation tuple
2. x and y coordinates in the CIE color space1
3. Mired2color temperature.
Note that this list does not mention brightness, as this is a common factor in all these color representations. For this example we will only support the most permissive representation of color, since this also covers the rest of the color ranges, which is a representation in hue and saturation. We now have the following variables and their respective ranges.
• hue: 0 - 65535 (where 0 and 65535 represent the same hue) • saturation: 0 - 254
• brightness: 1 - 254
Note that the colours of the lights can’t be changed while the light is off. So the on/off state accounts for the + 1 in the following calculation which calculates the amount of possible states the system can be in:
65535 ∗ 255 ∗ 254 + 1 = 4.244.701.951 unique light states (1) While this is technically still finite, it does take 15.8 gigabytes of memory to represent the variables within every state (2 bytes for hue, 1 byte each for satu-ration and brightness multiplied by the amount of states). So we need a solution that drastically reduces the amount of memory needed.
Secondly, for applications like the smart medical cabinet from section 2.2 one of the main functions could be: if the patient has not taken his medications
1
http://hyperphysics.phy-astr.gsu.edu/hbase/vision/cie.html 2https://en.wikipedia.org/wiki/Mired
before 12:00AM send an alert. In order to be able to correctly model this we will need timed functions.The problem is that standard finite state machines do not support the timers or variables which are needed to model time based interactions.
In the book: ‘Specification of Software Systems’ by V.S. Alagar and K. Periyasamy[1] there is a chapter dedicated to the extended finite state machine. This model adds, amongst other things, support for variables and conditional transitions based on those variables, e.g transition to the dimmed state if brightness <90%. These can be used to fix the two concerns stated earlier. To fix the first prob-lem, the color space and brightness options can be encoded as two variables. An integer variable for the brightness and a tuple of two integers for the hue and saturation. This reduces the amount of states in the state machine to two: on and off, as demonstrated in figure 3. Since the color information is now represented as a variable, it only takes 6 bytes of information. Thus giving us the massive reduction in memory footprint that we required. Note that for sim-plicity reasons we have chosen to model the variable updates as discrete events, while in reality those three variables can be set with one call to the API. This however, does not change any functionality of the system nor does it have influ-ence on the reachable states and variable values. It merely removes some of the convenience provided by the API to improve the separation of concerns within the model.
In the book they use a variable to represent a timer. The variable is as-sumed to be externally modified, so the EFSM only checks for the value of the timer and does not perform any actions increment/decrement the timer. Mod-eling IoT devices will work fine under these conditions, however there are many different application types. This will likely lead to different requirements for the timer’s resolution. Which is something that needs to be taken into account when developing the representation.
The final step in modeling devices through EFSMs is to determine a format in which to describe the EFSM itself. The choice has been made to represent the EFSMs in JSON. As shown in section 4, JSON is an incredibly popular format to exchange data, as every researched API supports it. This means that most people should hopefully have no issues with writing a JSON representa-tion. Furthermore, most programming languages have mature JSON libraries available, which makes it easy to create programmatic bindings to the JSON based representation.
Figure 3: Philips Hue Light Extended Finite State Machine
5.2
System Representation
In the previous section we discussed the representation of a single IoT device. However, IoT systems generally support more than a single device. Therefore the implementation of this system will usually have more than one active EFSM at the same time. Research by Jan van Eijck et al. [17] regarding composing multi agent models could provide an interesting option to create a single model that is composed of all these EFSM’s. The downside about this approach is that it does not map very nicely to IoT systems. IoT systems are generally easily extended with new devices. If we were to add a new device to an existing system, this would mean that the entire model has to be recreated.
Furthermore, in a production system this would also mean that every user would have his own personalised EFSM structure. If every user’s EFSM struc-ture is the same, debugging systems like this would be easier. Moreover, EFSM’s make the assumption that variables have a global scope within the state ma-chine. If we were to implement a composition of state machines, multiple in-stances of the same class of EFSM would be combined into one state machine. This will cause a clash within the variables, as both instances now control and depend on the same variable. Therefore, implementing a composition of EFSM’s has quite some interesting issues left to solve and is left as a possibility for future research.
A simpler solution to this problem is to view a system as a collection of dif-ferent EFSM classes with each of the classes containing a list of instances. This can be seen in Figure 4.
Figure 4: Simple model of an IoT system
The problem with this simplified model is that it does not account for possi-ble relations between EFSM’s. Some relations are almost trivial to implement. If we take for example the groups endpoint in the Phillips Hue API. Here the command we send is simply broadcasted to multiple lights at the same time. This means that we can simply mirror the functions of the lamps in the group devices and allow the group device to influence the variables of the lamp. Which is easy, because just as before only one variable is being changed at the same time.
But there are also devices where this will not be enough. Take for example the scenes endpoint in the Philips Hue API. A scene is a snapshot of light states that is saved so it can be reproduced later. This call creates an interesting problem. Since multiple variables are being changed by the same call, the order of the changes could matter. Take for example the EFSM from Figure 3. All changes to the brightness, hue and saturation will be invalid if the current state of the lamp is off. However, this is not a trivial problem to solve. Therefore, the choice has been made to view all calls that influence multiple devices as external to the target system. Which means that these calls will not update the EFSM’s for all affected devices directly, instead we rely on the API to give us the new state of the EFSM. Which can easily be combined with the recurring state updates that we already do to allow for other external events, like user input. This prevents models from being very complicated to construct due to having to identify every relation between each model. In most cases we can reasonably expect the device API’s to handle these circumstances correctly.
However, due to the projected size of the IoT there will undoubtedly be edge cases where a combination of multiple values can be pushed to an API that will not result in the requested behavior. Being able to know up front if a requested state & variable combination is impossible to reach will be valuable in these cases. A step that will help in calculating these external state updates is by implementing hierarchical state machines as researed by A. Girault et al [8]. By using these hierarchical state machines (a part of) the target EFSM could be embedded into the current model. This will make it easier to reason about the influence that one EFSM can exert on the other. All in all, this could prove to be an interesting direction for future research.
6
Domain model
The domain model is needed to link different devices that provide similar func-tionalities together. The model used to validate this thesis is not meant to be a complete model of all functionality. Rather it is meant to be extensible and provide a framework that can be used to reason about and provide context for IoT device semantics.
The IoT Architecture (IoT-A) group has done extensive research into how to model IoT devices and has created the model in Figure 11 on page 46 in the Appendix. The problem with this domain model is that it models the struc-ture of IoT solutions. Our research does not require a structural decomposition of the domain, but a functional one. Unfortunately, no such model has been constructed and shared yet, therefore we have to build our own solution.
Our models starts with the running Philips Hue example as base. As illus-trated in figure 1 on page 4, at the heart of the system there is the Philips Hue bridge. This bridge is more or less invisible to the user, functionality wise. Its core functionality is to relay the user’s commands that arrive from the API to the individual lights using the Zigbee[2] radio communication protocol. Because there is no real end-user functionality originating from the physical bridge we decide to leave out the bridge from the domain model. Note that while the bridge does host all virtual devices, like groups and scenes, these will be han-dled separately. In Philips’ case these virtual devices do not need a bridge, they could have been hosted in the cloud as well and therefore are worthy of their own separate entities. However, this is has to be evaluated on a system to system basis. Some bridges could provide functionality that is explicitly tied to the hardware, in that case they would have to be modeled as physical devices. At the time of writing the Philips Hue ecosystem has five different tiers of lamp functionality1:
• On/Off light • Dimmable light
• Color temperature light • Color light
• Extended color light
How these tiers influence functionality is shown in Figure 5. Note that func-tionality classes inherit all members from downstream classes. For example the Dimmable Light has all members from On / Off light plus its own members. Note for information regarding the terminology used in this figure see2.
1http://www.developers.meethue.com/documentation/supported-lights 2See footnote 1.
Figure 5: Philips Hue Light Functionality classes
The first thing that figure 5 shows, is that Philips chose a hierarchical struc-ture. The On / Off light is the most basic light that they produce and therefore contains all their basic information. Other lights provide extensions on this light and others. A problem that occurred when modeling this in the proof of concept is that this approach makes it very hard to create generic models this way. If another manufacturer adds his lights to the domain model we will need to factor out commonalities between the manufacturer’s and create a shared model that both manufacturers can inherit from.
We found that it is easier to approach this problem with a bottom-up ap-proach. Each functionality is expressed in the smallest possible container, called a profile. This profile has a name and one or more variables. The total function-ality of a device can then be constructed by a composition of profiles. This leads to a flat structure instead of a complicated multi-level inheritance structure. In this way semantics are represented by these profiles. An example of how the Philips Hue Functionality might look when using profiles is shown in figure 6.
Figure 6: Philips Hue Light Functionality classes using profiles
Looking at figure 6, we can see that this notation is more verbose than the hierarchical notation. However, this notation has the advantage of having each device as a self contained unit, we do not rely on inheritance from other devices. Another advantage of this notation is that it puts more semantics in the model. Semantics are not hidden in Philips’ documentation pages anymore,
but are exposed through well known generic profiles. For example, anyone with some education in mathematics would probably have guessed that the xy values from the Color light in figure 5 represent coordinates. But what kind of coordi-nates is the question. In the model in figure 6 the use of a profile makes clear exactly what coordinates we are expecting here.
While representing devices as a the collection of profiles they implement is a good way to capture device semantics, it does not provide a good mapping to the API syntax. For example, we can see that the Color Light from figure 6 supports the Hue Saturation Colors profile. A glance at the wikipedia page for hue1shows that hue can be represented as a value from 0 to 360 degrees on a
circle. However, Philips chose to represent it using a value between 0 - 65535, likely to map directly to the hardware in their lights as 65535 is the maximum value of an unsigned 16 bits integer. Because there are so many different ways of representing the same thing, some kind of generic mapping needs to be present for the domain model to truly capture the semantics behind the variables. Fur-thermore, this mapping also reduced the need for multiple profiles describing the same concept, e.g converting between Celsius, Fahrenheit and Kelvin for tem-perature measurements. Instead just a single profile with conversions between the different representations can be used. This could also be used to reduce the amount of profiles in figure 6, by just having one color profile and having the domain model provide translations between the different representations. Ideally this mapping would include user defined functions to correctly map the value their API provides to the format that the domain model expects. However, including external code in a program at runtime opens up all kinds of security risks and therefore needs to be carefully sandboxed. Due to the restricted time that is available for this project, this is left as a future extension of the program and only general, linear conversions between ranges are provided in the domain model.
7
Proof of concept
As stated before, there is very little information to be found about the chal-lenges in representing existing solutions in EFSMs. Therefore a small Proof of Concept(PoC) has been made. The scope of this PoC is to create a program that can parse a JSON description of the Philips Hue system and create and manipulate the resulting EFSMs. Note that this PoC uses the local Philips Hue API that is exposed by the Hue Bridge instead of the cloud based variant. This removes the need for an OAuth2.0 authentication layer in the software, resulting in a simpler PoC.
The code for this PoC is split up over two different parts. The first part, the EFSM implementation can be found at https://github.com/Gurrt/go-EFSM. While the Domain Model service can be found at https://github.com/Gurrt/ go-IoTDM. Both programs have been written in Go1, which was chosen largely for it’s first class support of parallel processing. This saved a lot of complexity in managing multiple EFSMs at the same time. This is not as much as a boon to the Domain Model service, since it operates on a single thread. But writing both programs in the same language made for easier debugging and less context switching during development.
7.1
go-EFSM
Note that as discussed in section 5.1 & 5.2 this PoC only directly deals with operations on one variable at a same time. Operations that implicitly handle more than one variable will be viewed as external to the system, i.e they do not adhere to the normal transition rules.
Due to time constraints we could not implement the Open API Specification. Instead, a custom API definition was created to cover just enough functionality to communicate with the Philips Hue API.
JSON EFSM representation
Arguably the most important part of this PoC is the resulting representation. A representation for the Philips Hue system can be found in listing 6 or the lat-est version is available at https://github.com/Gurrt/go-EFSM/blob/master/ definition.json. Note that in this description of the JSON structure the lit-eral names of JSON entities are italicised. This section expects familiarity with JSON syntax, see http://www.w3schools.com/json/json_syntax.asp for an introduction into JSON syntax. The main entities in this representation are classes, which are abstractions of IoT device classes. Every class requires five objects :
1. info 2. profiles
3. instances 4. sync 5. functions
Firstly, the info object is very straightforward. It contains metadata regarding the title and version of the EFSM description. As well as the apiBase which is prepended to all the API calls.
Secondly, the profiles object is an array containing objects representing pro-files from the IoT domain model. This array tells the program which propro-files are implemented within this EFSM, linking the semantics, in the form of variables, from the domain model to the EFSM. These profile objects contain at least one key, the id which must identify a profile from the domain model. Optionally this object contains keys with names equal to variables exposed by that profile, and values identifying which conversion needs to be done. Take for example the brightness key in listing 4. This key indicates that the brightness variable is internally represented as a value between 0-255 (uint8). This value is then con-verted by the domain model service to the representation it expects, percentages in this case.
Listing 4: Example profile object {” i d ” : ” dimmable ” , ” b r i g h t n e s s ” : ” u i n t 8 ”}
The instances object provides all the information that is needed to retrieve the instances of the EFSM. The apiPath, apiContentType and apiMethod can be defined to point the program to the right API endpoint. The idLocation entity defines the location within the resulting JSON (the only possible option for apiContentType). This is a string of keys delimited with full stops. A special character $key denotes that the keys of the current object need to be looped over. e.g instances.$key would mean that the keys of the instances dictionary on the root level of the JSON hold the id’s of the instances. Finally there is also the interval key, which defines the number of seconds between calls to update this information.
The sync array holds the data that is needed to get the information that is needed to synchronize the EFSM state with that of the physical device. The apiPath and interval variables have the same functionality as described for the instances object in the previous paragraph. There are two new objects within this structure. Firstly, the variables dictionary. This is a simple mapping from string to string that maps variables from domain profiles to their point separated location within the incoming JSON. Secondly, the states dictionary. This is a map from state name to an expression object that needs to be evaluated to determine which state the EFSM is in. Listing 5 shows an example state object for the ”on” state of the Hue EFSM. The ”off” state would be nearly the same, only the value boolean would be switched to false. Supported operators are eq (equals) and ne (does not equal) for strings, booleans and numbers. For numbers the gt (greater than), lt (lesser than), ge (greater than or equals) , le (lesser than or equals) operators are also possible.
Listing 5: State object { ” f i e l d ” : ” s t a t e . on ” , ” o p e r a t o r ” : ” eq ” , ” v a l u e ” : t r u e }
Note that while the expression object is a generic object, the fact that you can only have one of them per state binds this PoC tightly to EFSM with a state that is only determined by a single variable at a time. Ideally more complicated expressions could be constructed to determine which state the EFSM is in. Due to time constraints this could unfortunately not be realized in the PoC.
Finally, the functions array contains all the functions that this device can perform. A function object has the following parts. A name, which is a simple string to show to the user. An array of transitions, which is a simple object containing two strings under the keys from and to. This creates a list of state transitions that can be performed by the function. This list is evaluated to determine the states from which a function can be called. Furthermore, this transition object contains the previously explained apiPath, apiContentType and apiMethod types. Note that in this context the apiPath can contain a special $id keyword, which will be replaced by the id of the EFSM instance. The variable key is optional, and contains the domain model variable that this function is linked to. Finally there is the apiBody parameter, which can be added if the apiMethod is PUT or POST. This is a string containing the JSON body that needs to be sent to the server. This string can contain the keyword $var which will be replaced by the variable value that is linked to this function, if any.
API
The description from the previous part is used to generate an EFSM and keep it up-to-date through synchronisation calls. The program exposes its functionality through three different API calls.
1. /classes
2. /classes/$class id
3. /classes/$class id/$function?ids=x&value=y
The first call can be used to get the different classes of EFSM’s present in the system.
The second call can be used to get complete information about all the in-stances of EFSM’s of one class. This call will expose the current state of the instance and the values of the variables. As well as information about the func-tions that the EFSM class can execute.
The final call can be used to execute a function on one or multiple EFSM’s. The ids query parameter takes a comma separated list of instance id’s on which
to execute the function. The value query parameter is an semi-optional param-eter that only needs to be filled out if the function is linked to a variable. The values that need to be entered here need to have the format that is expected by the domain model. These are translated from and to the values that the external API expects by the Domain Model service.
Frontend
The PoC comes bundled with a simple Polymer1 based HTML frontend, as
shown in figure 7. The frontend provides a simple interface to the API. The bar on the left-hand side of the interface can be used to select an EFSM class. After selecting a class the instances will be represented by the white squares which show the variables and the current state of the EFSM.
Underneath the EFSM instance squares are buttons that can be used to invoke functions on the EFSM. There is currently no checking if a function is valid for the current state in the frontend. If an invalid function is called the API will simply reject that function for the EFSM instance.
Figure 7: EFSM Frontend
7.2
go-IoTDM
The IoT Domain Model service consists of an API that provides two distinct functions. The first is a simple interface to a MongoDB2backed document store
which contains profile information. A profile is a unique name with a collection
1https://www.polymer-project.org/1.0/ 2https://www.mongodb.com/
of typed variables. The API call performing this service is: /profiles/$profile.
The second is functionality to convert to and from variable types referenced within profiles. Conversions are aimed to convert a variable with a specific range to another range, and therefore operate solely on number based types in this PoC. Other type of conversions, like for example conversions between color representations or monetary conversions, are left as a possible future extension of the project. Integer based ranges that are current supported are 8, 16, 32 and 64 bits signed and unsigned integers. Double precision floating point based ranges that are supported are circles, percentages and permille. The API call for this service is :
/profiles/$profile/$variable/convert?from=$type&to=$type&value=$value Where either the from or to field is optional, and will be internally replaced with the default domain model type if left empty.
8
Analysis
8.1
EFSM’s
The PoC has shown that, despite having a few challenges to overcome, Philips Hue Lights can be modeled as an EFSM that is coupled to the API. The first question that arises is; how does this translate to other devices? To answer that question we have constructed table 2. This table is based on the IoT applica-tions that were identified in section 2.2. For each of the applicaapplica-tions an analysis was done to identify the compatibility with EFSM’s.
One of the outcomes of this analysis is that applications which are primar-ily meant as data storages are not good candidates to represent as an EFSM. Which, as stated in section 3, was to be expected. State machines are designed to take specific actions when a certain trigger happens. This could technically be used to create CRUD1based operations on a variable that represents a table,
thus creating a database EFSM. However, in this case the state would not reflect the contents of the database but rather the operation of the database itself.
The applications that perform analysis are however good candidates for EFSM representation. Consider the aviation unapproved parts detection. If we assume that this is an RFID reader that has a green and red light that turns on for three seconds to indicate the status of the scanned part, the resulting EFSM would look like the one in figure 8. In this fashion the states of the application are distilled to those that are noticeable to the end user.
Figure 8: Aviation unapproved parts detection Extended Finite State Machine Another observation is that some applications are too complex to have
Domain Application Compatible Comments Transportation
Aviation unapproved parts detection Yes Database would need an abstraction.
Vehicle safety systems Yes Some applications might require black-boxing. Traffic monitoring Yes Some applications might require black-boxing.
Supply chain management & Track and trace Yes Virtual Devices with states for each stage in the supply chain. Healthcare
Implantable digital health record No Application is a database, which does not translate well to EFSM’s. Vital sign monitor Yes Take continuous measurements, transit to alert state if treshhold reached. Tracking people & equipment No Application is a database, which does not translate well to EFSM’s. Staff & patient identification & authentication Yes RFID Reader and identification.
Automated data collection No Application is a database, which does not translate well to EFSM’s. Automated sensing Yes See Vital sign monitor.
Smart environment
Presence monitor Yes If no movement has been detected for x seconds transit to away state.
Smart lights Yes Proven by PoC.
Smart thermostat Yes Very deterministic, easy to capture in EFSM.
Automated gym equipment Yes RFID reader coupled with actuator to set intensity level.
Agriculture herd location No Application is a database, which does not translate well to EFSM’s. Personal and social
Automated Social Network Posts No Could be done, but requires individualised EFSM model.
Historical Queries No Application is a database, which does not translate well to EFSM’s. Loss Preventions No Application is a database, which does not translate well to EFSM’s. Geofencing Yes If fence entered/left push alert.
* - While the API generally adheres (or atleast tries) to the paradigm, some exceptions are present. Table 2: IoT application compatibility with EFSM’s
all their behavior modeled in the EFSM on the finest grained scope. Take for example an application that uses Automatic Number Plate Recognition1 (ANPR) that pushes an alert when a stolen vehicle is detected. According to the Wikipedia page on ANPR, there are seven primary algorithms needed to identify a license plate. Modeling all those seven algorithms as a state machine will likely lead to a state machine with hundreds of possible states. And only one state would be of interest to the user, the vehicle stole state. Therefore some applications could benefit greatly from treating parts of the system as a black box. In this case, the ANPR EFSM could be treated as a single abstracted state, containing two transitions. One to a nummber plate(s) found state and another to a idle state if no number plates can be found in the current image. These two points mean that an EFSM based representation of IoT devices works well on devices that provide some sort of actuation, but less so on ap-plications that only provide/store (sensor) data. An exception to this is the Supply Chain Management & Track and Trace application in the transportation domain. These are better suited to be modeled as EFSM than other database systems, since the data is state based. All of the devices within one of those systems occupy one of a limited number of states, indicating in which stage of the process that device is located. Contrary to applications like the Implantable digital health record where the data stored can take many different forms and does not move through a set order of states.
However, the primary function of databases is to store variables in the fields of some sort of table or document. Since these variables are no different from the variables in an EFSM they can be linked to the Domain Model. This could be used to create a representation of databases which can link database fields to domain variables, providing device semantics for database queries. But since this thesis concentrates on IoT devices this is left for future research.
Furthermore, the JSON description of the EFSM’s has been helpful in rapidly developing the device representations. Experience in building the EFSM’s that have been used to test the PoC shown that creating a JSON file that links API’s to EFSM’s is relatively straightforward. However, we did develop the represen-tation ourselves and have ample experience with the Philips Hue API. So this observation tells us nothing about the learning curve of this representation, but it does show that this can be a powerful tool to quickly create an EFSM based device representation in the right hands.
This is very interesting for Triggi as an IoT integrator. Currently all con-nections with manufacturers are manually made by a team of developers. This means that in an ideal case the amount of integrations that can be made within a timespan grows linearly with the amount of developers. With our JSON representation, manufacturers can create an EFSM representation of their IoT device themselves. This representation can be automatically integrated within
the Triggi platform, because the coupling with the Domain Model gives Triggi information about device semantics which can be presented to the end users in a standard way. This means that Triggi is not directly dependent on their de-velopers for creating new connections to manufacturers anymore, as such their business could grow quicker than was possible in the old situation. It does need to be noted that this does depend on the willingness of the manufacturer to do this work. Which boils down to Triggi needing to be an attractive platform for manufacturers to couple with, which poses an interesting challenge for their marketing department.
Furthermore, this also means that the Triggi platform can become more friendly to small businesses. In the current situation an integration with a man-ufacturer can only be made if it is economically feasible for Triggi, in which the developer’s salary is one of the main components. If the manufacturer can create the JSON representation of their device, Triggi has to perform less work for the connection. Which makes it cheaper for Triggi, which opens up new opportunities with small companies that do not (yet) have a large enough client base to be economically interesting in the current situation.
Another advantage of having external developers create EFSM based repre-sentation, is that graph based techniques can be used to find mistakes in the representation. Generally, if we represent an IoT device using state transition machines it means that it should never get into a state where it can not get out of, since this means that the device will not respond to any input anymore. This property can be used to find (probable) bugs in the representation. For example, take figure 9 as an example of an incorrect EFSM generated from a representation. From this graph based representation we can easily see that the door lock would get stuck in the unlocked state after it is unlocked once, which might not be that obvious to see if the connection to the hospital door lock was coded manually. This attribute can easily be found programmatically by singling out every node that does not participate in a cycle. Luckily finding cycles in graphs is a problem that has been solved for a long time already, as such an implementation of Johnson’s cycle detection algorithm[15] or a similar algorithm could be used.
Figure 9: Incorrect hospital door lock EFSM
Figure 10 serves as an example of what a correct EFSM model of this hospital door lock would look like. We can see that the unlocked state will now be left after the timer variable has reached the value of 3. Using this kind of detection can’t prove that the transitions will actually be executed by the IoT device, but it can at least prove the absence of dead states. Similar techniques can be used to find disconnected sub graphs and unreachable states, which are likely to be indicators of a buggy representation as well.
Another interesting use of these graphs is runtime analysis. When the EFSM is in a state and the user requests a certain transition which can’t be performed from this state, we can suggest the shortest sequence of actions which does allow this transition to happen. This can be done by using a pathfinding algorithm like A* [13]. Recent API response times for transitions by all EFSM’s generated from the same file could even be used to provide costs for the paths. In this manner A* can find which path is likely the quickest to perform in real-time.
