Test Bed of Semantic Interaction of Smart Objects in the Web of Things

Semantic interaction in the Internet of Things (IoT) is an important concept within current IoT development, given that smart things require further autonomy with greater processing, storage, and communication capacities. The problem is now becoming one of how to get these things to interact and collaborate with each other; to form intelligent environments amongst themselves and thus generate better services for users. This article explores a solution approach that consists in providing collaborative behavior to smart things, through the incorporation of an ontology and an architecture. It makes possible things that can communicate and collaborate with each other, allowing the generation of new services of interaction according to user needs. For this task, a real test bed of smart things was created, in which the proposed solution was deployed (Smart Room). Finally, it was concluded that the creation of these types of test bed is feasible, taking into account that response times and the information delivered by the different managed processes are acceptable. New challenges were encountered, however, such as problems of critical region in test beds with conflicting services and management of multiple users.


Introduction
People tend to be defined by the way they relate to the physical world.They are described by the things they own or by those things they relate to (e.g., Red Car, the Microsoft owner, Mary's husband).Things of the real world are leaving behind their inert role to become a fundamental part of the people and they organize their quality of life (an example of this is the smartphone).This trend has come to be called the Internet of Things (IoT).
By connecting things (real, physical or virtual) to the Web, digital representations can then be created of them to interact with their owners and monitor the states of real-world entities.This is known as the Web of Things (WoT).A state should be understood as the set of values that one or more properties observes at a given time, related to the entities of interest [1] of the user that are measured through sensors.For example, a webcam located at home can be monitored by the owner through the smartphone from the office and verify its state in relation to the entities of interest: e.g., the children, the family pet, etc.
Things today maintain an inherent characteristic, which is their owner.However, each Thing has an objective of interaction with its environment.Around it there are other things that are part of that environment and that may be related to the context of application of their interactions.
servers.The servers are in charge of managing the information of the objects, performing procedures that calculate and display the tasks and actions on the data presented to the users.Defining the management is the direct responsibility of the owner and developer of the application.These projects are efficient in their application context, but made to measure and hardly reusable in other contexts, additionally they relegate many configurations and decisions of the system to the user, to other human actors, or third applications.If adding new interactions is desired, the new functions have to be built almost from zero, even the implementation of new hardware.Furthermore, these works focus mainly on the interaction between objects with people, unlike the present project that focuses on the interaction among smart objects themselves.
An important piece of research for the present investigation is that of Perera, et al. [8], in which they present an in-depth analysis on understanding context in the IoT, as well as that presented in [9], which focuses on reducing the tasks that the user must perform in order to connect to the services the objects provide.The present work uses the concepts of context introduced by Perera in order to better manage the interactions between objects.
The project [10] presents a summary of smart object types characterized by three dimensions: awareness, representation, and interactivity.Awareness is a smart object´s ability to understand events and human activities.The smart object in an awareness dimension can be activity-aware, policy-aware, or process-aware.Representation refers to a smart object´s application and programming model.Interaction denotes the object´s ability to converse with the user.The present work uses the policy-aware object's approach, because the interaction with the user is based on rules to initially configure test bed interaction services.
Perera, et al. [11], also studied the possibility of applying semantic techniques to index the objects of the IoT and connect to them.To do this, they proposed the discovery and automatic configuration of the objects, from which it would be possible to later use their services.The model presented (CADDOT) and the tool developed (SmartLink) allow the use of semantic techniques for annotating information in the SSN-XG ontology [12] and its configuration in a proprietary middleware, enabling its subsequent consumption by users and applications.The weak point of the proposed solution is that it indexes the technical characteristics of the device and not its ability to be applied in different application contexts, likewise, the potentiality of each smart object in its processing and storage capacity is not exploited, since this is delegated to the centralized server or middleware, generating a possible bottleneck with respect to the scalability of the solution.Finally, the work does not address the interaction between objects, but it does offer ideas of what a dialogue of identification would look like between an object and an intelligent entity, such as SmartLink.
The Estrada-Martinez and Garcia-Macias project [13] defines how the interaction problems in the IoT can be solved, using Semantic Web technologies.For this, they define the characteristics of a smart object and its deployment in an intelligent space.Ontologies were used to model the reasoning of the information shared between the objects and their users, concluding that semantic technologies can be applied in the IoT domain to generate richer interactions.The article makes it possible to establish first-hand the basic elements that a test bed of smart objects must take into account for its deployment, including the discovery of services, common messaging for all the participants and the notification of events in order to partially solve the problems of centered interaction between the user and the smart object.These elements were taken into account in the solution presented in this proposal.Unfortunately, the article is not very clear in the architecture used and in the complete solution, since it shows examples of query and illustrations of deployment in annexes separate from the ontology.Furthermore, the evaluation of the proposed solution is more descriptive than technical.
The project of Piyare [14] increases the remote monitoring on the states of objects that are provided with sensors.To this end, an architecture was implemented where the decentralization of intelligence is proposed and must be distributed among the physical layer of sensors, the coordination layer, and the supervision layer.Thus, for our project the intelligence of the object is also decentralized, on the one hand, in the object itself and on the other as a coordinating object.This facilitates the development of services and the use of different objects with different purposes, without having to depend totally of the configurations and capacities of other elements of the system.Unlike Piyare's work, our architecture involves the use of diverse platforms and types of smart objects and not necessarily a network of wireless sensors, although its proof of concept reveals the problems that must be overcome in a network of sensors, such as an efficient and common communication protocol, as well as an adequate management of the energy used by the objects.
The project by Rosen [15] aims to provide a standard communication system between all intelligent devices in an environment, be an event handler, and allow the generation of new applications and services to manage the functions of household devices.They are divided into three layers: the device layer defines the characteristics of the devices and their interfaces; the core layer handles information traffic between devices and applications; and the application layer comprises the applications made by users.The project stores the devices in a centralized server, restricting the context to a specific and custom assembly, and the applications have predefined parameters (for example, turning down temperature, switching on lights) that limit the possibilities that can be generated within the interaction of the devices.The interesting thing about the project lies in raising the possibility of creating semantic interaction between objects of the same environment with a purpose defined by the user.
The project by Ryu [16] propose an integrated sematic service platform (ISSP) for solving three main problems.The first problem is the integrated semantic discovery in distributed IoT domains.The second problem is the dynamic semantic representation between a myriad of IoT resources in real time.The third problem is the semantic data repository to archive a large amount of data collected from IoT devices.The ISSP handles various service knowledge domains using ontologies for each domain.The domain ontologies are created by a web-based authoring tool and handled by IoT-based service integration ontology.This approach has a strong link with the present work, but the main difference is in the ontology location within the model and the request handling towards the ontology.The Ryu project centralizes these features in a cloud-based system and the present work distributes the ontology and the request handle in each object.There are also commercial solutions, such as [17][18][19], where home automation services are provided that allow the user to remotely control home devices using mobile or web applications.They feature such devices as audio equipment, video equipment, lighting, alarms, cameras, curtains, and irrigation systems.These solutions are efficient, but costly, since the development of these proposals are restricted to specific brands or closed protocols, limiting the solution to only one type of device and closed models.The devices that do not have the same protocols will not be taken into account at the moment of generating the interactions.

Architecture Deployed
In the following, an architecture is deployed to develop the test bed.The architecture is based on the Niño-Zambrano [5] approach.It presents well defined layers, is service oriented and is addressed by a WoT semantic interaction model.The architecture has these main features:

•
Distribute the information logic in the network edge ("fog computing" [20]), reducing the request time and the communication requirements.

•
Reuse context and services, these are not linked with any entity, environment or purpose.The relationships depend on the usage of the objects.

•
Allow objects linking, in order to cooperate in the new services creation.The objects can take part in different objectives.
Specific devices, protocols, and servers are named.However, depending on the design needs of the developers, this architecture can be instanced in any type of hardware that supports the mentioned characteristics of a smart object.
For a better understanding, the following basic concepts that are proposed in the architecture should be highlighted.

•
Physical representation: consisting of the material and tangible part of a device.

•
Digital representation: the information stored digitally on a physical representation of the device.
In this case it is stored in a middleware called Xively and in each smart object.

•
Resource: elements that have the objects to interact with the physical world.These can be either sensors, which examine the physical environment and capture the information that enters the system, or actuators, which perform an action on the physical environment in order to change its status.

•
Entity: representation of a person, place or thing, which is related to one or more smart objects and which are subject to measurement or action.

•
Entity of interest: an entity that is the object of an information search or an interaction by a user.

•
Basic service: the service of a smart object by default, it is associated with the original operation with which it was created.

•
Interaction service: generated by the interaction between two objects.Each interaction service is supported by an ECA and is executed by the object that contains the actuator resource.

•
ECA (event-condition-action): XML document with the information of the contract between two smart objects.The ECA contains the logic of the interaction service and informs the objects about the variables and the resources that intervene in the execution of an interaction service.The event and action are related to smart objects and the condition is defined by the user.
The architecture presented in Figure 1 organizes the different tools and elements in a service-oriented model in which six layers are defined.Entity of interest: an entity that is the object of an information search or an interaction by a user. Basic service: the service of a smart object by default, it is associated with the original operation with which it was created. Interaction service: generated by the interaction between two objects.Each interaction service is supported by an ECA and is executed by the object that contains the actuator resource. ECA (event-condition-action): XML document with the information of the contract between two smart objects.The ECA contains the logic of the interaction service and informs the objects about the variables and the resources that intervene in the execution of an interaction service.The event and action are related to smart objects and the condition is defined by the user.
The architecture presented in Figure 1 organizes the different tools and elements in a serviceoriented model in which six layers are defined.

Object Layer
The physical representation of the objects is found, and the associated resources are defined.Each object is developed on an Intel Galileo board [21] supported on Linux with Yocto distribution containing the class directory named "SmartObject.py".Each object is related to an NFC tag where

Object Layer
The physical representation of the objects is found, and the associated resources are defined.Each object is developed on an Intel Galileo board [21] supported on Linux with Yocto distribution containing the class directory named "SmartObject.py".Each object is related to an NFC tag where the unique identification of the object is stored within the system.This is done in order to allow interaction with the user intuitively through a mobile application called "Clipio".
For this test bed, three smart objects were deployed, with the following characteristics: • Temperature regulator: related to the temperature sensor resource (Arduino Grove-Temperature module), the heating system actuator (physical heater with resistance), and cooling fan actuator (USB fan).These resources define the basic service that enables a constant level of temperature to be maintained in a closed room.

•
Light regulator: related to the light sensor resource (Arduino Grove-Light module) and a light bulb actuator (table lamp).These resources define the basic service that facilitates detecting the absence of natural light in a closed room (with window) and turning on a source of artificial light.

•
Humidity regulator in houseplant: related to the humidity sensor resource (Arduino Grove-Humidity module) and an irrigation actuator (simulated with a LED).These resources define the basic service that allows a house plant to be watered when the moisture level is low.

Middleware Layer
The Xively server [22] was used as a tool to store the digital representation of the smart objects.This server presents interfaces to create digital profiles of the objects.Within each profile the channels that determine the resources are created, the unique identification of the object is obtained, and labels and descriptions are created that will be used to characterize the object semantically.This layer allows the access of data and metadata of any object using standardized schemas such as JSON and resolves the heterogeneity and connectivity problem that are presented in the object layer, since it provides an API for the most commonly used platforms in the IoT.
The Xively server was used for practical purposes when implementing the test bed, however, the architectural deployed is not limited to this server-it is possible to add other IoT middlewares that allow hosting objects and their metadata, exposing this information in such standards as XML or JSON.The same applies with the object layer, where it is possible to use other development boards (rather than Galileo's Intel) and different sensors and actuators, giving the proposal a greater richness in object diversity.

Semantic Object Layer
Responsible for hosting the tools that support the semantic capabilities of the test bed.It has three main elements:

•
Semantic Object Ontology (SOO) [5]: Is one of the relevant element of the present work.Uses OWL [23] as its language.It is stored and instantiated in each smart object of the test bed.The SSO have the information necessary to generate collaborative behavior between smart objects and their users.The SOO stores the smart object information of: context, metadata, interaction services (ECA), basic service, entity of interest, and resources in a set of instances.This element is consulted when the object needs to expose information about its metadata or create the contracts of interaction service with other objects.In Figure 2, the upper level of the SOO is presented.
SSO have the information necessary to generate collaborative behavior between smart objects and their users.The SOO stores the smart object information of: context, metadata, interaction services (ECA), basic service, entity of interest, and resources in a set of instances.This element is consulted when the object needs to expose information about its metadata or create the contracts of interaction service with other objects.In Figure 2, the upper level of the SOO is presented.In Figure 2, the upper level of the SOO is presented.Each of the concepts are defined as follows in Table 1.

•
Semantic IoT index: an information structure stored in a server in the cloud, which can be consulted to carry out the discovery and connectivity processes to IoT devices in a specific context and place.When a user made a query, the index uses the concepts contained in a context ontology to organize the information retrieved from the digital representation of each object.Then the index exposes a list of smart objects and their services, according to the concepts of the domain ontology.• DogOnt [24]: since it was necessary to define a dynamic context, this domain ontology was used because it contains the concepts and relationships to generate the context.This ontology is stored and instantiated in the semantic index element.The semantic index consumes the information from DogOnt and generates the context based on the ontology concepts.The DogOnt can be changed according the test bed needs.In this project we use the context of home automation included in DogOnt.
The semantic index and the DogOnt are not core elements of this project, those are from external developments, but we use those elements as an important part of our project.The union of the semantic index and DogOnt generates the domain, this information can be requested from different elements.

Service Layer
The service layer exposes the results of the semantic index using web services based on SOAP [25], making it possible for applications and objects to consume metadata, data, and other context information, in an interoperable and transparent manner.This server is also responsible for recovering the digital representation of the objects in Xively and exposing it in the semantic index.There is a semantic index for each specific domain ontology that is provided on the cloud server.

Interaction Layer
The interaction layer supports the tools that allow the objects to communicate with applications and with other objects.It is based on the Eclipse Paho broker server (iot.eclipse.org)that manages the MQTT protocol [26].The broker server is the intermediary where objects and users can communicate their states, requirements, and queries.All the messaging work of the elements that interact with the broker are supported by XML documents, which were coded to take into account the Open Group ODF standard [27] in order to define a common and interoperable information protocol by any type of smart object.The interactions defined on this layer are:

•
Object to object: the event object shares the status of one of its resources to the action object.

•
Object to user: the object responds to the user about the result of an internal operation.

•
User to object: the user makes a query about the metadata of the object by means of a query to it.The user communicates the structure of a new interaction service to the event and action object by sending them an ECA.The user requests the change of status of a basic service (on/off).The user requests the status change of an interaction service (on/off).The user requests the elimination of an interaction service to the event and action object (eliminates ECA of each object).
Among the documents developed, those that intervene in the creation of an interaction service can be highlighted:

•
MetaData.xml:contains the information of the object and its resources, Figure 3 presents a representation of the main elements.

•
ECA.xml: supports the creation of an interaction service, Figure 4 presents a representation of the main elements.broker are supported by XML documents, which were coded to take into account the Open Group ODF standard [27] in order to define a common and interoperable information protocol by any type of smart object.The interactions defined on this layer are:  Object to object: the event object shares the status of one of its resources to the action object. Object to user: the object responds to the user about the result of an internal operation. User to object: the user makes a query about the metadata of the object by means of a query to it.The user communicates the structure of a new interaction service to the event and action object by sending them an ECA.The user requests the change of status of a basic service (on/off).The user requests the status change of an interaction service (on/off).The user requests the elimination of an interaction service to the event and action object (eliminates ECA of each object).
Among the documents developed, those that intervene in the creation of an interaction service can be highlighted:


MetaData.xml:contains the information of the object and its resources, Figure 3 presents a representation of the main elements.

Application Layer
This layer hosts the applications that will allow the user to interact with the information to define the interaction services desired by the user.The applications and interfaces used are listed:

Application Layer
This layer hosts the applications that will allow the user to interact with the information to define the interaction services desired by the user.The applications and interfaces used are listed:

•
Clipio: a mobile application that manages the objects of the test bed.It communicates its requests through the broker server, in this way it can create and eliminate interaction services, modify the states (turn on and off) of the basic services and interaction, and consult metadata about the objects.Clipio is developed under Android Lillipop (5.0 or higher); jdom (handling of XML), Paho (management of client MQTT) and kSOAP 2 (handling client SOAP) libraries were used.
The application was installed on a LG Nexus 5 mobile device.

•
NFC tag: corresponding to an entity or smart object.When aimed at an entity, the tag contains the name of the entity and its global position (longitude and latitude).Mifare Ultralight adhesive tags were used.The tag identified the room of the house and the coordinates in which the other nearby smart objects were displayed.

•
User panel: presents information about the test bed such as instantaneous states of each resource of the objects, general information about the operation of each object, real-time information of the interaction activities between the objects.This information is stored and subsequently used in the evaluation of the test bed.It is developed using Html, Javascript, Php, and Ccs.For the database MySQL is used.

•
Initialize object: a program in Python that initializes the smart object for the first time, retrieving the metadata from the object of the indexing service and requesting the user for missing data.It synchronizes the physical representation with the digital representation of the object (SOO).This interface interacts with the user when the object is registering in the system.It is supported in the Python "SmartObject.py"directory.

Test Bed Implementation
At this point the architecture is materialized in a test bed implementation, in order to analyze strengths and weaknesses in this kind of WoT test beds.The implementation of this is the core of the research because it takes the architecture as a conceptual base and develops a simple test bed, what will be evaluated, and finally the conclusions are extracted from the evaluation results.
For the development of the test bed, the UP Agile [28] software development methodology is used, which is defined in four phases.This section shows the three initial phases and the fourth phase corresponds to the evaluation of the test bed and is dealt with in Section 5.

Start-Up Phase
The main requirement for the project is: "The test bed must have tools that allow the creation, execution, and removal of services for the interaction and execution of basic services".To meet this requirement, critical use cases are: create, modify and eliminate interaction service, and also modify basic service.Figure 5 shows the diagram of critical use cases.
strengths and weaknesses in this kind of WoT test beds.The implementation of this is the core of the research because it takes the architecture as a conceptual base and develops a simple test bed, what will be evaluated, and finally the conclusions are extracted from the evaluation results.
For the development of the test bed, the UP Agile [28] software development methodology is used, which is defined in four phases.This section shows the three initial phases and the fourth phase corresponds to the evaluation of the test bed and is dealt with in Section 5.

Start-Up Phase
The main requirement for the project is: "The test bed must have tools that allow the creation, execution, and removal of services for the interaction and execution of basic services".To meet this requirement, critical use cases are: create, modify and eliminate interaction service, and also modify basic service.Figure 5 shows the diagram of critical use cases.

Elaboration Phase
The elements of the test bed are distributed in modules that make it possible to differentiate the processes that will develop the requirements and use cases proposed in the start-up phase.Within these modules, the one that responds to the use cases in Figure 6 is the smart object interaction module-SOIM, represented in Figure 6.

Elaboration Phase
The elements of the test bed are distributed in modules that make it possible to differentiate the processes that will develop the requirements and use cases proposed in the start-up phase.Within these modules, the one that responds to the use cases in Figure 6 is the smart object interaction module-SOIM, represented in Figure 6.SOIM enables Clipio to communicate with objects through the broker server to manage the creation, modification and deletion of service requests, and the objects in turn communicate with each other to execute interaction services.In order for SOIM to work properly, it ought to be taken into account that the test bed must previously comply with the following prerequisites (these are processes that are not mentioned in detail in the document, but are included in other modules):


The participating objects of an interaction service must have complete metadata information in the SOO.This process is done using the initialization interface of the object (initialize object SOIM enables Clipio to communicate with objects through the broker server to manage the creation, modification and deletion of service requests, and the objects in turn communicate with each other to execute interaction services.In order for SOIM to work properly, it ought to be taken into account that the test bed must previously comply with the following prerequisites (these are processes that are not mentioned in detail in the document, but are included in other modules):

•
The participating objects of an interaction service must have complete metadata information in the SOO.This process is done using the initialization interface of the object (initialize object program).

•
The participating objects of an interaction service must have their digital representation in Xively and also the semantic index must have previously recovered this representation and expose the object in the object server.

•
Clipio must perform the authentication process within an entity of interest, so that the discovery of the objects includes the context associated with the entity of interest.
After the prerequisites are set, the system can generate a new ECA.To generate a new interaction service, we use the ECA element.The ECA is a xml document (Figure 4) that links two smart objects belonging to the same context.Each smart object stores the ECA relation in its SOO and the ECA document in its root directory.The ECA is configured in Clipio, the user can change the value of any ECA variable, name the ECA, and choose the involved smart objects.Figure 7 (five picture) shows the screenshot of an ECA generation interface.First, the user chooses two resources of any smart object (previously indexed in the semantic index element).Then, the interface enables a combo-box, for choosing the "condition_comparator"; and enable a text-box to enter the "condition_variable" and "action_variable" (this task is the same for both resources).Finally, the user sets the name and a description of the ECA and sends this request to the involved smart objects.

Construction Phase
The tools that expose the functionality to the users were implemented.In the following section, the main Clipio interfaces are presented with which the user can manage the objects to create, execute, and eliminate interaction services and execute basic services.
Figure 7 shows the different interfaces that Clipio displays to carry out the administration of the test bed services.The user goes through the home and start up interfaces of the application and then enters the interface where the creation of an interaction service begins.The user must enter the searches of the objects using words or phrases that identify him.In addition, he can adjust the search radius to detail the desired object.Clipio then requests the variables of the interaction service and finally the service is created.The remaining processes are similarly supported by Clipio in order to remove and modify services.
test bed services.The user goes through the home and start up interfaces of the application and then enters the interface where the creation of an interaction service begins.The user must enter the searches of the objects using words or phrases that identify him.In addition, he can adjust the search radius to detail the desired object.Clipio then requests the variables of the interaction service and finally the service is created.The remaining processes are similarly supported by Clipio in order to remove and modify services.

Evaluation
Although some of the measures used most to evaluate test beds and other implementations are the quality of service indicators, it was decided not to manage these since the measurement objective is the interaction between smart objects, and not the quality of the different aspects that the test bed may have.However, the test bed takes the following measures in order to ensure a good quality of service:

Evaluation
Although some of the measures used most to evaluate test beds and other implementations are the quality of service indicators, it was decided not to manage these since the measurement objective is the interaction between smart objects, and not the quality of the different aspects that the test bed may have.However, the test bed takes the following measures in order to ensure a good quality of service:

•
Duplication of tasks [29]: in critical tasks such as sending MQTT messages to the server, the processes dedicated to publishing the messages are replicated at least three times.This is done in order to ensure the arrival of the package to the broker and its replication in the respective subscribers, and in this way increase the fault tolerance of the test bed.

•
Focus on programming threads [30]: the elements of the test bed have been programmed to think of thread systems, seeking to organize and synchronize different redundant and heavy processes in separate threads to improve the response times of the test bed.

•
Interactivity, delay, and criticality interactivity [31]: corresponds to the queries made by the user to the semantic index to detect objects and their resources.Delay is an indicator that is measured in the experiments under the name of interaction latency, with which a quality of interaction service can be established.Finally, criticality was taken into account when sending the states of each resource to the MQTT server, because these processes are critical in the test bed.
To evaluate the test bed, it was established that the appropriate indicator to perform the measurements should be latency in interaction.This consists of measuring the time elapsed since an element makes a query or sends a message, until the results are returned or executed.
The first tests showed very high interaction latency times, with average values of 13 s.Analyzing the critical points of the system, improvements were made in the processes and bottlenecks, achieving considerably improved response times as the alpha tests of functionality progressed.Therefore, a new group of tests was carried out to detect delays (latencies) with precise times and with suitable analysis.The steps taken for the analysis were:

•
Measurements of latency times were applied only to the general processes.

•
The times correspond to the exact latency from the start message until the confirmation with the completion message arrives.The times perceived may be a bit longer due to a delay in the recomposition of the interfaces.

•
A table was collected that keeps all the messaging work between the objects and Clipio.They were organized according to the use case to which they belong and finally a latency analysis process was carried out.

•
Twelve tests were carried out during twelve different days, one per day.

•
Not all the tests were performed executing the same interaction services, since each test sought to test a particular functionality.However, the times were averaged, solving the problems of the differences in the number of records collected • Since at individual times the individual measurements had extreme times (long and short) with respect to the average normal function, the ends were removed to avoid distortions.The eliminated times were stored separately in order to determine what happened at those points.
Taking the interaction latency times into account, an interaction service quality can be measured.The results of the operations on the test bed were identified.To be classified as real time, these should not be longer than 4 ms [15].This time is taken as a reference for the experiments and Table 2 is defined to interpret the interaction service quality.For the evaluation, the following considerations are taken into account:

•
The measurements were applied to the use cases and not to the internal processes contained in them.Evaluations are presented for the use cases discussed in this document, considered as those that contain the main functionalities of the test bed.

•
Using the user panel application, the messaging work was collected between smart objects and Clipio, organized by use cases and the latency analysis was carried out.

•
Twelve tests were carried out over twelve separate days, one per day.

•
The experiment was conducted using an internet access point that handles speeds of 9.74 Mbps for loading and 17.9 Mbps for download.In addition, the network is shared with approximately 70 other users.

•
A stack of tests was designed keeping in mind that situations in which the test bed is sensitive to conflicts must be avoided.These can occur when two or more interaction services are run that execute the same actuator resource with opposite actions (as in the example given earlier, when service interaction 1 has the action of turning on the heating while interaction service 2 has the action of turning off the heating).
• Finally, a total of 57,824 messages are analyzed in each of the use cases.
Next, show the result analysis of all use cases in Figure 5.

Create Interaction Service
The reported times show an average latency of 7.68 ms, rating the result as a poor quality, according to Table 2.The standard deviation is 3.4, this shows a low critical dispersion in the results.Figure 8 displays low growth trend in time, but the use case has a significant peak in the 7 group.Because of this it is necessary to tune the use case's processes to improve the times.On the other hand, this use case is considered as the heaviest process and it uses a lot of computer resources.Thus the results are close to a good rate and have a low critical dispersion, revealing a relatively acceptable calcification.Table 3 shows the data relation and statistics results.

Update Interaction Service
The reported times show an average latency of 5.01 ms, rating the result as a good quality, according to Table 2.The standard deviation is 0.7, this show a low dispersion in the results.Figure 9 displays a very low growth trend in time, and the use case does not have a significant peak.Table 4 shows the data relation and statistics results.This is the ideal use case, because it uses few computer resources.

Update Interaction Service
The reported times show an average latency of 5.01 ms, rating the result as a good quality, according to Table 2.The standard deviation is 0.7, this show a low dispersion in the results.Figure 9 displays a very low growth trend in time, and the use case does not have a significant peak.Table 4 shows the data relation and statistics results.This is the ideal use case, because it uses few computer resources.

Update Basic Service
The reported times show an average latency of 4.92 ms, rating the result as an excellent quality, according to Table 2.The standard deviation is 2.2, this shows a low dispersion in the results.Figure 10 displays a low growth trend in time, but the use case has a significant peak in the 8 group.This peak can be caused by human mistakes, broken elements, or internet problems.Table 5 shows the data relation and statistics results.

Update Basic Service
The reported times show an average latency of 4.92 ms, rating the result as an excellent quality, according to Table 2.The standard deviation is 2.2, this shows a low dispersion in the results.Figure 10 displays a low growth trend in time, but the use case has a significant peak in the 8 group.This peak can be caused by human mistakes, broken elements, or internet problems.Table 5 shows the data relation and statistics results.

Update Basic Service
The reported times show an average latency of 4.92 ms, rating the result as an excellent quality, according to Table 2.The standard deviation is 2.2, this shows a low dispersion in the results.Figure 10 displays a low growth trend in time, but the use case has a significant peak in the 8 group.This peak can be caused by human mistakes, broken elements, or internet problems.Table 5 shows the data relation and statistics results.

Delete Interaction Service
The reported times show an average latency of 3.82 ms, rating the result as excellent quality, according to Table 2.The standard deviation is 1.3, this shows very low dispersion in the results.Figure 11 displays low growth trend in time, but the use case has a significant peak in the 3 group.Table 6 shows the data relation and statistics results.This use case is considered the lighter process and it uses few computer resources.
Table 7 shows the results of the evaluation for each use case.An analysis of these times then follows below.
The times reported in Table 7 show an average latency of 5.36 ms, qualifying as good quality, according to Table 2.The tendency of most use cases is toward a behavior of quality of service between excellent and good.However, the process of creating an interaction service is the one that presents the worst time.This is because several processes that this use case handles must be replicated in the devices that participate in the creation of the interaction service.Other cases, meanwhile, do not have optimal times.This may be due to human error at the time of implementing the test.It is possible that many interaction services are operated without taking care to turn them off later, generating conflicts and delaying the response of the system.Although in these tests the system has been overloaded, it is not expected that many interaction services will be managed at the same time.Table 7 shows the results of the evaluation for each use case.An analysis of these times then follows below.

Conclusions
A test bed of semantic interaction was implemented in the WoT, using real physical devices and all the elements defined in the architecture were incorporated.The preliminary results allow us to confirm that the proposal of an interaction test bed in the WoT based on semantic indexes, web services and semantic objects, is viable for generating interaction test beds in the WoT.However, it is necessary to make more implementations to improve the tools, latency times and applied concepts.
The design of the experiments, their execution, and the analysis carried out suggests that the implemented test bed is viable as a solution to create semantic relationships between objects and generate new services adjusted to the needs of the WoT users.The result of the evaluation concludes that the response times are located in the range of a good rate.

Future 19 
Internet 2018, 10, x FOR PEER REVIEW 5 of Entity: representation of a person, place or thing, which is related to one or more smart objects and which are subject to measurement or action.

Figure 2 .
Figure 2. Module of the properties of the Semantic Object (object-oriented pattern).Figure 2. Module of the properties of the Semantic Object (object-oriented pattern).

Figure 2 .
Figure 2. Module of the properties of the Semantic Object (object-oriented pattern).Figure 2. Module of the properties of the Semantic Object (object-oriented pattern).

Future
Internet 2018, 10, x FOR PEER REVIEW 10 of 19

Table 1 .
SOO upper level concepts.
StatesStage, change, phase, course, moment, period, seasonValues of the properties measured by the resources of the object in a given time.

Table 2 .
Interaction service quality by latency.

Table 4 .
Update interaction service latency.

Table 3 .
Create interaction service latency.

Table 5 .
Update basic service.

Table 4 .
Update interaction service latency.

Table 5 .
Update basic service.Update basic service (day vs. ms).

Table 5 .
Update basic service.

Table 7 .
Average times for use case.Delete interaction service (day vs. ms).

Table 7 .
Average times for use case.