Design Invariants

Sports

Our IoT service platform model can be applied in several application scenarios like sports or leisure activities. In a sport activity like running, one can use a smart phone application to track position, speed, distance, and other relevant parameters. The person that uses the Application would create a Shared Hybrid Virtual Place on IoT platform and register the smart phone as a Thing. The smart phone application would upload this data to the Hybrid Virtual Place called for example “running place”. This person would be the Place Master and could add to this running place his/her online social relationships interested in running. The Place Master and his online social relationships (i.e. People) would share their running activities on IoT service platform. In addition, a software Application on IoT service platform could be created to analyze performances, competitions, time for activities, and suggestions for new running paths by analyzing statistics of People within the running place.

Product Management

The model can be applied in product management. For example in the smart product application scenario [17]. In this scenario, an employee from supermarket would be the Place Master. He/she would create a Virtual Place called for example virtual supermarket with public access. The Place Master would register products (Things) to the virtual supermarket. Customers could use an application on their smart phones to read the tags on products and obtain extended information about products from virtual supermarket. This information could include vendor specification, customer ratings, comments and other. In addition, software Applications on IoT service platform can be used in order to

analyze customer satisfaction or to compare prices with similar virtual supermarkets.

Waste Management

The model can be used for optimization of waste management in the cities. In the “Smart Urban Waste Management” application scenario [17] product packages are tagged with RFID technologies. At the waste disposal, each bin can be scanned with RFID readers and its content can be analyzed. This information can be stored on IoT service platforms in order to analyze and optimize the garbage collection through the city. In this application scenario the Things are tagged objects, the Hybrid Virtual Place contains several physical places and is created by person in charge of waste management i.e. Place Master. Software Applications can be developed by the local authority that would analyze the waste disposal and plan the route for its collection.

Design properties of Web based IoT service platform validate our general framework. However, platform development provides an insight regarding the fact that one IoT service platform cannot be unique service for connecting People, Things, and Applications. If we consider that in our instance of scenario

“friendly TV watching”, the smart TV at home is connected to one IoT service platform and the smart TV at work to another (Figure 26) our model has to be extended.

Figure 26: Scenario instance on distributed IoT platforms

In this scenario, a software Application is registered on two IoT service platforms. It should perform separate request to each platform in order to create a service. Consequently, there should be a mechanism on each platform allowing Applications to perform requests at the platform level instead of Virtual

Places. That means that the platform should aggregate and provide information about all Virtual Places where an Application is registered and instances within Virtual Places. The above figure shows an Application that should present requests to two IoT service platforms in order to get the Virtual Places (i.e.

virtual context) and receive the digital information that the Virtual Places contain.

Each request should be presented separately and would be described as follows:

Precondition: Application is registered on IoT service platforms Normal Flow: READ (Platform 1, VP1-n), READ (Platform 2, VP1-n)

On Application request, each platform would treat request as follows:

Precondition: Application is registered by Place Masters in each Virtual Place VP1-n

Normal Flow: READ (VP1-n, P, VT)

Response from the platforms should contain collections of Virtual Places with collection of tuples <People, Virtual Things>. This request should also be treated by ACL manager module on IoT service platform in order to ensure that the Application gets the Virtual Places only where the Place Masters registered this Application.

In order to get relevant digital information, these requests can be extended by adding the date or location attributes:

Precondition: Application is registered by Place Masters in each Virtual Place VP_1-n

Normal Flow: READ (VP1-n, date, location, P, VT)

The IoT service platform should return collections of Virtual Places with the collection of People and associated Virtual Things having the date and location specified in the request.

We implemented this extension of general framework in our platform prototype.

The first tests confirmed that it is possible to extend the platforms with these features and that access to Virtual Places specified by Place Masters is respected.

By logical reasoning, we argue that our solution is also valid in other IoT scenarios where real time communication between Things and People is not of

major importance. Real time communication is required in ambient environments where Things are reacting autonomously at People’s presence. Typically, home automation systems would need a local communication and coordination system. In this scenario, Things connected locally over a short range of wireless communication use a local gateway in order to orchestrate interactions in a timely way. The reason for this architecture is lower power consumption and the need for real time reaction of Things to People’s actions. For example, a person at home, moving from one room to another while the system has to adjust to her/his presence. In this case (and in similar scenarios), using our Web based IoT service platform would not be adapted. Communication delay that can occur over the Web might result in activating the system in a room when the person has already passed through.

Another scenario can be theft control in groceries using RFID tags. In this scenario, at the exit of a grocery RFID readers are used to read the tags from products and to verify if these products have been paid. In the case of a product that is not registered as paid, a sound alarm notifies the possibility of theft. As several customers might be passing through the tag reader in very short time, the speed of alarm reaction is of major importance. Using Web based IoT service platform for these systems might result in delays that trigger the alarm when the next person is already passing through the reader. That would result in the control of the wrong person at the exit of the grocery. Hence, these errors would invalidate People’s trust in the system. From these two scenarios, we can conclude that a Web based IoT service platform is not adapted when real time actions are required.

In spite of the lack of real time reactivity, our platform can be used as an extension for local systems. Local environments can be connected to our platform in order to upload the interaction logs. IoT service platform can be used afterwards in order to perform analysis of interactions and aggregate results into user models [62]. IoT service platform can store and aggregate history of user’s actions into a “user model” that is afterwards used to predict user behavior and preferences. It would allow for better personalization of services that could be platform could afterwards use this model in order to personalize products’ offers.

The services on our platform are based on the third party, Applications. This model allows for a high extensibility of the model for various domains of applications. Conclusively, the model is valid in most of scenarios where real time communication between <People, Things, Applications> is not of major importance. More so, our IoT service platform model is valid and general enough

for IoT ecosystem. The general framework and the platform prototype narrowed our attention to design properties of IoT service platforms. We can now take an outlook and analyze the impact of this model on user empowerment in the IoT.