13.2.1 IoT and WoT Standards

In the IoT domain, anyone can propose an own architecture and an own communication protocol, due to a wide variety of requirements to which each architecture should be compliant. Then, each solution could propose a reference model and encourage clients to use it. Some consortium of universities and companies working in IoT have proposed the birth of few common reference models. A common reference model for the IoT domain and the identification of reference architectures can help to a faster, more focused development and an exponential increase of IoT-related solutions. WoX architectural model is developed looking at two IoT standards IoT-A and ITU-T, which we present in the next sections. Moreover we will also analyze two data representation formats: SensorML and Observation&Measurement.

The IoT-A Reference Model

The European Lighthouse Integrated Project has addressed for three years the Internet-of-Things Architecture (IoT-A) [2] and created an architectural reference model together with the definition of an initial set of key building blocks. It wants to promote a common ground between architectures so that they can interoperate even a more levels. IoT-A has achieved that thanks to two steps:

• Establishing a Reference Model;

• Providing a Reference Architecture.

The IoT-A ARM (Architecture Reference Model) (Fig. 13.1) consists of four parts:

• Vision: summarizes the rationale for providing an architectural reference model for the IoT;

• Business scenarios: define requirements provided by stakeholders that are the drivers of the architecture. They allow the architecture to be validated;

• The IoT Reference Model, which provides the highest abstraction level for the definition of the IoT-A Architectural Reference Model. It promotes a common understanding of the IoT domain. It includes the description of domain, communication and information model;

• The IoT Reference Architecture, which is the reference for building compliant IoT architectures. It provides views and perspectives on different architectural aspects that are of concern to stakeholders of the IoT.

An important aspect is the compliance of their technologies with standards and best practices, so that interoperability across organizations is ensured. If such compliance is given, the ecosystem allow every stakeholder to create new businesses entities that “interoperate” with already existing entities. Fig. 13.2 shows a high level information model derived by the IoT-A architecture. This model is so abstract that can represent any generic IoT solution. In particular, the device layer represents each device that interacts with the architecture and the communication layer represents mechanism to do it.

ITU-T

The ITU Telecommunication Standardization Sector (ITU-T) [3] is one of the three sectors of the International Telecommunication Union (ITU). It coordinates standards for telecommunications. The main products of ITU-T are Recommendations (ITU-T Recs) standards defining how telecommunication networks operate and interwork. ITU-T Recs have non-mandatory status until they are adopted in national laws. ITU-T recommendations are guidelines to develop IoT application. They have a deeply impact both for implementation phase and for validation stage in IoT software architectures. Fig. 13.3 shows the IoT reference model. It is composed of four layers as well as management capabilities and security capabilities which are associated with the four layers: the application layer, the service support and application support layer, the network layer, and device layer.

In particular, the device layer capabilities can be logically categorized into two kinds of capabilities:

• Device capabilities, which include but are not limited to:

∘ Direct interaction with the communication network: Devices are able to gather and upload information directly (i.e., without using gateway capabilities) to the communication network and can directly receive information (e.g., commands) from the communication network.

∘ Indirect interaction with the communication network: Devices are able to gather and upload information to the communication network indirectly, i.e., through gateway capabilities. On the other side, devices can indirectly receive information (e.g., commands) from the communication network.

• Gateway capabilities, which include but are not limited to:

∘ Multiple interfaces support: At the device layer, the gateway capabilities support devices connected through different kinds of wired or wireless technologies, such as a controller area network (CAN) bus, ZigBee, Bluetooth or Wi-Fi. At the network layer, the gateway capabilities may communicate through various technologies, such as the public switched telephone network (PSTN), second generation or third generation (2G or 3G) networks, long-term evolution networks (LTE), Ethernet or digital subscriber lines (DSL).

∘ Protocol conversion: There are two situations where gateway capabilities are needed. One situation is when communications at the device layer use different device layer protocols, e.g., ZigBee technology protocols and Bluetooth technology protocols, the other one is when communications involving both the device layer and network layer use different protocols e.g., a ZigBee technology protocol at the device layer and a 3G technology protocol at the network layer.

13.2.2 IoT and WoT Research Works

In the literature, the interest in design and development of WoT software architectures, using different approaches, is very deep. Several Web platforms are emerging with the aim to abstract the heterogeneity of the physical embedded devices in order to facilitate their integration and interoperability. Most of the existing architectures belong to two main categories:

• Architectures based on international standards. They enjoy several benefits arising from compliance with international standards, but they are very close to the physical layer. Therefore, using these architectures requires expert knowledge of physical technologies and significant familiarity with programming languages. Furthermore, they are generally focused on a specific use cases and are not horizontal enough to support the integration of heterogeneous technologies.

• Horizontal architectures, which are explicitly designed to integrate heterogeneous protocols and standards. Semantic architectures, for example, belong to this category. Generally, these architectures are not compliant with international standards, but have the considerable advantage of being closer to the developer's mental model, who is not required to know about the involved physical technologies nor specific programming languages.

Regarding the first category, in [8] authors propose an IoT framework, based on the EPCglobal [4] architecture, which is able to integrate the transducer capability of IEEE 1451 standards [9]. As the original EPCglobal definition only supports C-1 Gen-2 RFID tag identification, authors propose to extend the framework to support more readers, tags, and transducers in versatile IoT applications. EPCglobal Application Level Events (ALE) middleware is provided with transducer capability of IEEE 1451. Regarding the second category, the Semantic Web of Things (SWoT) is an emerging activity in Information and Communication Technology (ICT), joining together the Semantic Web and the Internet of Things. Its goal is to associate semantically rich and easily accessible information to real-world objects, locations and events, by means of a service infrastructure that makes easy the deployment and use of semantic applications involving Internet of Things devices, as described in [10].

A widely used tool for the development of semantic architectures is Smart-M3 [11]. It is a content-based, semantic subscribe-notify, and open-source middleware able to provide a Semantic Web information-sharing infrastructure among software entities and devices. The main goals of Smart-M3 is the sharing interoperable information in smart environment applications and making information in the physical world available for smart services. Authors in [12] describe their own vision a middleware for the Internet of Things, with the aims of creating a new generation middleware platform which will enable self-managed complex systems, in particular industrial ones, consisting of distributed, heterogeneous, shared and reusable components of different nature. Grounding on semantic and Multi-Agent System technologies and methodologies, they analyze and design such middleware and demonstrate how it is possible to enable various components to automatically discover each other and to configure a system with complex functionalities based on the atomic functions of the components. Another interesting horizontal approach is presented in [13], where authors propose a software architecture to easily mash-up CoAP resources. The architecture is able to discover the available devices and to virtualize them outside the physical network. These virtualizations are then exposed to the upper layers by a RESTful interface, so that the physical devices interact only with their own virtualization. The architecture is designed to establish a bidirectional communication channel, allowing not only to monitor but also to control the devices. The achieved platform, also, provides simplified tools allowing the development of mash-up applications to different-skilled users. Relating to Enterprise Service Bus for IoT, the study in [14] proposes an architecture for an effective integration of the Internet of Things in enterprise services: the architecture exposes real-world devices with embedded software to standard IT systems by making them accessible in a service-oriented way. The author in [15] shows a new IoT sensing service system based on EDSOA (Event Driven SOA) architecture to support real-time, event-driven, and active service execution. The study also provides a new IoT browser that uses augmented reality technology to display IoT resource, obtaining the superposition presentation of the physical world and abstract information. Despite these interesting approaches, in literature there is a lack of integrated platforms that can provide a cloud access to IoT resources along with a semantic management of them. There is the need of IoT architecture that can manage smart devices with the support of knowledge processing tools and, at the same time, that allow end-users to interact with them as Web resources, adopting a model-driven approach typical of the Web engineering sector. Moreover, WoX approach differs from existing solutions thanks to its independence from specific hardware constraints, since it grounds on a software architecture enabling the inter-connection of any kind of IoT real and virtual devices, as described later in the chapter. The WoX architecture tries to satisfy both the requirements.

13.4.1 Analytical Formulation

WoX refers to both IoT hardware nodes and IoT applications generically as IoT entities. In WoX, the “sensor” and “actuator” concepts are hidden. The main concept is the Topic. A WoX Topic is about an information of interest – called feature – in a certain location. More rigorously, a feature is any characteristic or entity of the environment that can be perceivable, definable, measurable and/or controllable. Some bare examples of feature are: temperature, humidity, presence. A crowd of people can be a feature too, as well as an alarm. Also a mathematical function – e.g. sum, min, max – can be a feature. The set of WoX features is the following:

$F=\{f_i\}$

The location is expressed hierarchically following the URN (Uniform Resource Name) scheme, e.g. “urn:italy:salento:highschool:firstfloor:phylab:desk1” or “urn:usa:california:la:westwood:overlandavenue:2801”. The set of WoX locations is the following:

$L=\{l_i\}ULO{C}_{A}NY,LO{C}_{S}ELF$

where L also includes two special locations:

1. LOC_ANY, i.e. a wildcard for any location;

2. LOC_SELF, i.e. a reference to the current location.

Hence WoX define T as the set of couples feature-in-location:

$T=\{t_{i,j}=(f_i,l_j)\in F\times L\}$

As we said, in WoX the topic is the key between who asks for services and who provides services. Separating the twos, WoX reaches the maximum abstraction possible. In fact, IoT designers can focus on concepts (features) rather than on hardware. An IoT entity will link itself to a topic in different ways, depending on its nature. In WoX, such nature is captured in two dimensions:

1. Collaborative dimension. It includes two aspects: (i) the capability to perform a service within the topic, and (ii) the need for other entities who can perform a service.

2. Technological dimension. It includes the legacy (i) sensor and (ii) actuator distinction, as well as a generic (iii) function service.

Hence WoX defines the following two dimensions sets:

$D_C=\{Capability,Need\}$

$D_{TECH}=\{Source,Executor,Function\}$

Then, WoX defines the set of WoX roles R included in the following Cartesian product:

$R=D_C\times D_{TECH}=\{SN,EN,FN,SC,EC,FC\}$

The items in the curly brackets respectively state for: sensor capability, actuator capability, function capability, sensor need, actuator need, function need. The generic IoT entity z can be modeled as a set of couples role-topic belonging to the following Cartesian product:

$E_z=\{(r_k,t_{i,j})\in R\times T\}$

By this way, WoX is able to model any device or app in the IoE, even the most complex or abstract. An example of IoE node implementing the WoX model is a personal enhanced RFID tag which need to know the temperature in the current room, is capable to perform a comparison between float numbers and can activate a LED alarm.

13.4.2 The Information Architecture

End-users applications as well as core architectural components (e.g. data analysis) need to aggregate information that will not be directly available from the IoT physical layer. This is because the physical layer generates raw sensor data that need to be compared, intersected, cross checked, reasoned before being available for the upper layers. Particularly, we can distinguish the following information types, as depicted in Fig. 13.5:

• Raw data coming from the specific IoT technology (sensor). This is wrapped in the specific technology protocol message, and may vary in format (int, float, Boolean, binary, string), semantics and timing of availability/update;

• Event, described by a unified information schema that encapsulates the raw data and specifies meta-data such as: time, location, (technological) source. Event messages mask the inherent technology complexity. Such events are typically fired by middleware. Despite the uniformity of the event definition among different IoT technologies, events still wrap technology-specific information. Moreover, different events could describe the same situation (e.g. more events incoming from different IoT technologies could say that someone is entering a place);

• Topics, updated by events. A topic wraps a value and it is identified by providing its Feature and Location. We can distinguish in:

∘ Low level topics, for example, an application may be interested in someone entering a place, no matter which technology originates this event;

∘ High level topics, which retain the information inferred by interpreting the relations among more topics and data sources. Such relations can be statically foreseen;

• Facts and Patterns. The topic is a synchronous entity (its value continuously changes at every event incoming from the lower layers or from low level topics). A Fact is the snapshot of a topic at a certain time. Facts for one or more topics can be stored for future analysis. Such analysis can use heuristics in order to find recurring Patterns. That is, we can find “a-posteriori” topic relations. Domain experts can decide what to do with the elicited patterns: print reports, define new high level topics, send alerts, etc.

13.4.3 Expected Benefits

A number of stakeholders will benefit from the WoX model's abstraction power:

• The end-user does not want to waste money in buying non-interoperable hardware that delivers few pre-defined scenarios. For instance, the end-user expects that when s/he is going back home, the air conditioner will automatically turn on, no matter how the user location is picked, no matter what the air conditioner manufacturer is.

• IoT inventors (e.g. developers and makers) want to shorten the distance between the idea and the solution. Unfortunately, currently they spend most of their time in focusing on the implementation details (often reinventing the wheel) rather than the core concepts of their ideas.

• Business organizations want to minimize the cost of their solutions as well as the time-to-market. They want to concentrate on the business models and on the business logic rather than burning their efforts on study different protocols and deal with implementation details.

13.5.1 Reference Architecture

The WoX model requires a robust ICT architecture capable of facing the extremely high number of IoT entities and Topics, the intense exchange of messages, and the heterogeneity of the IoT technologies. WoX architecture is built as instance of the publish-subscribe (pub/sub) software design pattern. Pub/sub is an enterprise integration pattern where senders of messages, called publishers, do not know a priori what are the specific receivers of messages, called subscribers. Instead, published messages are characterized into classes, without knowledge of subscribers identity. Similarly, subscribers express interest in one or more classes, and only receive messages that are in their scope, without knowledge of publishers' identity. The modelling of the pub/sub architecture starts from the Topic class. In Fig. 13.7 the UML dependence diagram is shown. The Observer software design pattern implements the main WoX idea. The Topic class has the Feature and Location member variables, as well as two other member variables, to hold respectively the topic's actual value and preferred value: the actual value contains the most recent value for the feature in the location; the preferred value is used to send and receive requests about the desired topic value (e.g. the desired temperature in a room).

Every time an IoT node shows up, it handshakes with the WoX architecture, i.e. it declares its roles according to the formula (13.7). The corresponding subscriber classes are instanced and get attached to the Topic instance. When the Topic's actual value gets updated, SN subscribers (i.e. information consumers) get notified. Vice versa, when the Topic preferred value is modified, AC subscribers are notified so they can absolve their tasks. If the Topic's feature is a function, the topic's preferred value is ignored and the actual value is used both to pass function parameters as well as to obtain the function result. In the first case, FC subscribers get notified; in the second case, FN subscribers get notified. The pub/sub architectural pattern centralizes the core information separating who provides data from who consumes it. IoT-based apps perform a one-time subscription to the topic(s) of interests, without perceiving the hardware layer. Subscribing to topics is easy also for “stupid” IoT nodes (e.g. RFID tags). Moreover, the total number of exchanged messages is drastically reduced because of dropping all the point-to-point connections between IoT entities. The whole enterprise architecture depends on the WoX model, as presented in the previous section. The platform receives the raw data from sensors and it elaborates them in order to extract complex information. The workflow of data within the application is basically depicted in Fig. 13.8. The WoX logical architecture introduces two kinds of topics, both compliant with the definition of Topic, but referring to different levels of abstraction:

1. Low-Level Topic: it is related to data belonging to observable/controllable IoT entities without any semantic connotation;

2. High-Level Topic: it represents a refined information semantically characterized and interpreted.

The other components in the logical architecture are:

1. Enterprise Service Bus (ESB): it is the solution adopted to connect the various component of the application. It is compliant to Service-Oriented Applications (SOA) architectural pattern and it guarantees the interoperability among heterogeneous technologies.

2. Business Rules Web Service: it is a middleware component with the specific function of Knowledge Processor (KP). The module subscribes to the Low-Level Topic and applies the business rules on row data deriving information from it, in order to draw events of interest and to update the corresponding High-Level Topic;

3. User Application: high abstraction level module. Its role is to subscribe the High-Level Topic and to notify the user when an event of interest occurs.

The Low Level Topic is used to catch data provided by sensors, to control actuators and, generally, to process row data in an IoT network. The High Level Topic is used to treat elaborate information mined from raw data according to the logic rules imposed by the KP. Once a High-Level Topic changes its own internal state, that is some event of interest has occurred, it notifies the User Application component as any other topic too.

13.5.2 Physical Architecture

WoX uses an EPCglobal middleware (ETH Zurich's Fosstrak [5] implementation) and WSO2 ESB [6]. Fig. 13.9 shows the WoX technical architecture. A pub/sub architecture alone cannot satisfy the requirements of hardware abstraction, event filtering, and standard-compliant persistence of an IoT middleware. To this aim, the pub/sub architecture is put on the top of an EPCglobal middleware. Such design choice guarantees quality and performance to the whole architecture. As aforementioned, the WoX architecture grounds on the Fosstrak. It is made up of four main layers:

1. Environment Level: it comprises the physical layer as well as any virtual environment that can generate events. Social networks chats or other virtual data generators can be source of events too.

2. ALE middleware: it is responsible of querying/piloting the Environment Level and packing event reports for the upper layers. It also normalizes the events and filters duplicated data. On the bottom side, a series of adaptor is present for each IoT technology, both physical (e.g. RFID, WSN, KNX, etc.) and virtual (social networks, virtual environments, etc.). On the top level, three SOAP (Simple Object Access Protocol) Web services are needed to send hardware configuration (when needed), receive event reports formatted with the ECSpec (Event Cycle Specification) schema, and to send data to the technologies using the respective technology formats.

3. WoX Capturing Application: it is the architectural level implementing the WoX model. It instances the topics, updates them, updates the topic map, and makes such data available to the end-user apps by a set of REST interfaces.

4. End users applications use the WoX APIs to subscribe topics; they can run on any kind of device. For testing purposes, in the current work, Java and Android APIs have been used, but APIs in other programming language will be developed in the next steps. An additional element, the EPCIS (EPC Information System), persists IoT events for asynchronous usage.

Fig. 13.9 evidences the two possible flows of information: (i) node-to-node, the curved arrow, i.e. any IoT node can request services to other nodes (even of different technology), and (ii) node-to-app, the straight arrow, i.e. any app can receive data from any node, and vice-versa. The cornerstone of each information exchange is the WoX Capturing application, where the WoX model is implemented and the topics are instanced.

Referring to Fig. 13.10, most part of the architecture is implemented using WSO2 technologies. Particularly, WSO2 implements the following components: Enterprise Service Bus, Business Rules Server and Web Service Application Server. The module for managing topics is implemented on the top of Fosstrak EPCGlobal implementation and is deployed on a dedicated server. The different modules in the architecture communicate by way of RESTful interfaces, in accordance with WSO2 guidelines. The sensor component sends the data describing the state of the environment to the Enterprise Service Bus. The ESB sends the data from sensors to the Fosstrak Capturing Application component, where a specific instance of Low-Level Topic encapsulates the data from the sensor. The Application Server implemented on the WSO2 Web Service Application Server subscribes all the topic instances in the Capturing Application, firing different actions depending on the type of topic. In case of Low-Level Topic subscription, the Application Server receives notifications from it in conjunction with sensor updates and it forwards the information included in the topic to the Business Rule Server. In the latter component there is a Web service equipped with a Knowledge Processing Engine. It acts as Knowledge Processor and computes the received data. f an event of interest has occurred, the Business Rule Server updates the corresponding High-Level Topic. The business logic rules are implemented by means of Drools tool [7]. Since the Application Server can perform subscriptions also to High-Level Topic, an event of interest occurrence is seamless notified to it and, so, to the end users. The Business Rules Server exposes the logic rules as Web services. Therefore, it is possible adding new rules or modifying existing ones by means of http requests, without the need of redeploy the application.

13.5.3 L-WoX and M-WoX

As we said at the beginning of Section 13.5.1, three WoX topics domains exist: (i) the Cloud domain, more general and horizontal with respect to the WoX applications, (ii) the Local WoX (L-WoX) domain, which lives in intelligent user devices such as smartphones and tablets, and (iii) the Embedded WoX (M-WoX) domain, related to embedded devices. In this section we describe the last two WoX declinations.

L-WoX

The Local WoX (L-WoX) is a subset of the whole architecture running on the personal user device (smartphones and tablets). In L-WoX, the personal device works as an aggregator towards local WoT entities. Allowing to retain and manage some topics locally on the device is more efficient in some circumstances. For example, multiple mobile apps on the same device may be interested to the same topic, and its value is updated by an onboard sensor (e.g. the accelerometer). Another example consists in two mobile apps interested in two different topics, updated using the same onboard sensor. As an example, the accelerometer can feed both the “ATHLET_TRAINING” topic and “ELDERLY_PERSON_FALL” topic. In L-WoX we have the following components:

1. The L-WoX service, instanced as a singleton in the mobile operating system, retaining the topic instances;

2. The mobile apps, subscribing to the local topics after binding to the L-WoX service;

3. The native sensors APIs, offered by the mobile operating system to access the available sensors;

4. A set of WoX adaptors, which use the values incoming from the sensors to update specific topics.

Notice that the Location values for the local topics is often LOCATION_SELF. As for the Cloud case, the mobile app developer decides what to do with each local topic value. In addition, s/he decides if updating a Cloud topic (hence acting as a capability entity) or not.

Fig. 13.11 reports the L-WoX architecture. It is evidenced how to connect both existing and new App to the WoX Cloud.

The legacy app talks directly to the physical layer, using its own application layer protocol. In order for the legacy app to share its existing services, it should use the WoX APIs in order to translate the proprietary event to the common WoX topic. If necessary, the app forwards the new topic information to the global WoX architecture, else the information will remain in the specific app context. New IoT apps (not legacy) can directly uses all the L-WoX advantages.

M-WoX

No matter which IoT technique/technology – even passive – is considered, the specific IoT entity should be able to tell peers, gateways and apps its WoX profile, according to formula (13.7). The WoX profile exchange message format is called M-WoX. When possible, implementing the M-WoX data format protocol allows a seamless dialogue between different kind of devices, in a P2P fashion. The M-WoX application protocol is independent from the specific IoT device nature/brand, because its purpose to format the message payload rather than defining how the devices are networked. It can be used to format the payloads of BLE beacons/connections, QR codes, NFC tags, and so on. Given the constrained – even self-powered – of IoT nodes, it is obvious that such message should be composed bit by bit. M-WoX is based on and expands the user memory mapping proposal presented in the BRIDGE Project¹ Actually, if we consider the passive RFID as the most constrained IoT technology, we can use the WORD variable as the atomic piece of information. A WORD is composed of 4 HEX digits, i.e. 16 bit (e.g. AAAA, 0123, BCFF). In Fig. 13.12 the high level WoX message format is depicted.

The message starts with a Special Function Code (SFC) (1 WORD), by which the entity memory can be fixed, reset or initialized. The entity itself can also tell that it is not available in a certain moment. After the SFC, there is a succession of 236 WORDs blocks. The blocks division is foreseen in order to face the constraints of some IoT technologies, which does not allow to read all the retained information at once. Every block is self-consistent (i.e., it is not mandatory to read all the blocks in order to understand the single block content). In Fig. 13.13 the single block details is depicted.

Each block contains the serialized version of the WoX entity profile, as defined in formula (13.7). Here we describe the block format in detail. The first field is the NoR (Number of Roles).

Table 13.1

The Number of Roles (NoR) Field

FIELD	LENGTH
NoRa	1 word

a NoR: Number of Roles, i.e. the number of roles wrapped in the block.

Table 13.2

The roleAddress and roleRange Fields Details

FIELD	LENGTH
roleAddressa	1 word
roleRangeb	2 word

a roleAddress: hex address (in WORDs) of the role inside the whole message.

b roleRange: length of the role, in number of WORDs.

Table 13.3

The Capability Case Fields

FIELD	LENGTH
DATA	1 word
NUM_INTERVAL	1 word
LIMIT_HI	1 word
LIMIT_LO	1 word
NEGATIVE_OFFSET	1 word
INTERVAL	1 word
COUNT	1 word
TIMESTAMP	2 words
STARTTIME	2 words
LOGCTRL	1 word
LOGSTAT	1 word
ROLE_TYPE	1 word
FEATURE_ID	1 word
TOTAL	15 words

The NoR (Number of Roles) is the number of roles wrapped in the block. A role can be: (i) source capability; (ii) source need; (iii) executor capability; (iv) executor need, (v) function capability, (vi) function need. Then, the block contains the role map, which is a field having NoR couples roleAddress-roleRange, i.e. the memory address (expressed in WORDs) and the role size for each role.

The roleAddress is the hex address (in WORDs) of the role inside the whole message. The roleRange is length of the role, in number of WORDs. Then, each role must be described (serialized). Such serialization varies if it is a capability or a need.

In Table 13.3 there are shown the capability case fields. The fields meanings:

• FEATURE_ID: it is the unique identification number of the WoX feature (temperature, light, fall, ...)

• ROLE_TYPE: defines the role type. The value is one of the following:

Table 13.4

The LOGSTAT Register Details

Table 13.5

The LOGCTRL Register Detail

SOURCE_CAPABILITY_ROLE = 0;

SOURCE_NEED_ROLE = 1;

EXECUTOR_CAPABILITY_ROLE = 2;

EXECUTOR_NEED_ROLE = 3;

FUNCTION_CAPABILITY_ROLE = 4;

FUNCTION_NEED_ROLE = 5;

• LOGSTAT: a register containing the status flags (memory_full, upper_limit_violation, lower_limit_violation) as well as information about the feature data type.

The Type field contains the data type, which could be one of the following:

∘ 0000 = signed 16-bit integer

∘ 0001 = unsigned 16-bit integer

∘ 0010 = signed 32-bit integer

∘ 0011 = unsigned 32-bit integer

∘ 0100 = float, IEEE 754 Single-precision (32 bit)

∘ 0101 = fixed point Q10.6

∘ 1111 = Bitwise presentation (manufacturer specific)

The other LOGSTAT fields are:

∘ F = Memory Full flag

∘ LLV = Limit Low Violation flag

∘ LHV = Limit High Violation flag

• LOGCTRL: a configuration register defining the behavior of the specific feature.

In Table 13.5 there are shown the LOGCTRL fields details.

∘ RST = Reset

∘ L = Sensor monitoring activated

∘ D = Data logging activated

∘ TL = Timestamp activated

∘ M = Mode

– 0 = Continuous logging

– 1 = Event logging

∘ LHM = Limit High Monitoring (on/off)

∘ LLM = Limit Low Monitoring (on/off)

• STARTTIME: UNIX timestamp holding the beginning of logging (if the technology supports logging)

• TIMESTAMP: timestamp (UNIX time).

• COUNT: quantity of data record in memory. If data logging is not active, the value of COUNT is 1.

• INTERVAL: interval of sampling, in seconds (not needed if logging)

• NEGATIVE_OFFSET: the negative offset to be added to LIMIT_LO or LIMIT_HI to obtain the real limits (avoiding to face negative values).

Example. If: NEGATIVE_OFFSET = 20, LIMIT_LO = 0, LIMIT_HI = 30, then the real limits are:

(real) LIMIT_LO = −20 (i.e. LIMIT_LO + (−NEGATIVE_OFFSET))

(real) LIMIT_HI = 10 (i.e. LIMIT_HI + (−NEGATIVE_OFFSET))

• LIMIT_LO: the lower measure limit range

• LIMIT_HI: the upper measure limit range

• NUM_INTERVAL: defines the number of steps in which the interval (LIMIT_HI – LIMIT_LO) is sampled.

• DATA: data generated by the source (sensor) or to be forwarded to the executor (actuator)

The “need” case is reported in Table 13.6.

Table 13.6

The Need Case Fields

FIELD	LENGTH
DATA	1 word
locationMD5	1 or 8 words
NUM_INTERVAL	1 word
LIMIT_HI	1 word
LIMIT_LO	1 word
NEGATIVE_OFFSET	1 word
LOGCTRL	1 word
LOGSTAT	1 word
ROLE_TYPE	1 word
FEATURE_ID	1 word
TOTAL	10 or 17 words

The common fields have the same meaning as for the capability case. A specific comment is needed for the following field:

• locationMD5: The location URN in which the entity wants its need to be satisfied. When the URN is the same location where the entity resides (LOC_SELF), or any location (LOC_ANY), then the location URN field is 1 WORD long. Else, 8 WORDS.

13.6.1 The Kiss&Fly Scenario

The Kiss&Fly zone is a short-stay parking area located near the airports' terminals. Tipically, the total time of free pass and/or stay in this area is 10 minutes. For a stay of over 10 minutes users are charged for some price. The innovative scenario we want to develop includes the use of a smartphone to detect the entrance/exit of the user in the parking lot. Considered sensing technologies are:

• NFC. The user will tap its device to the entrance and exit gates;

• A mobile app. The user will tap manually the “I'm entering” and “I'm exiting” buttons.

The use of two different sensing technologies (very different from each other, the first one is physical, the second one is virtual) demonstrates the independence of the scenario from the specific hardware involved. We developed a unique physical gate for both entering and exiting the parking lot. We implemented it using an Arduino Mega 5360, expanded with a Seed Studio NFC Shield. The Arduino also has a relay which is needed to lift up and bring down the park barrier. Besides the mobile device and the Arduino, another IoT entity is needed: the billing system. It listens for users entering and exiting the parking lot, takes the event times, decides whether to charge or not the user, and settle the transaction if needed. In order to simulate the user status (inside or outside the parking lot), we use a light bulb connected to the Arduino relays instead if a real barrier. For this scenario we used the following topic: feature BARRIER, location: “it:apulia:brindisi:casale:parking:kissFly”. The value of the topic is formatted with a JSON String like this: {“user” : “user_id”, “lifted” : true}. Then, for each IoT entity (node or app) involved, we defined its role(s):

• The mobile app has an executor need role, because of both the “I'm entering” and “I'm exiting” buttons and the NFC tap possibility;

• The billing system has a source need role, because it want to know about the status of the barrier topic;

• The Arduino has both an executor capability (because it can lift up the barrier) and a source capability (because it can say that the barrier is lifted up or not after the execution).

In Fig. 13.14 it is shown the mobile app code we wrote for the Android platform. As readers can see, most code is about UI and variables updates. WoX needs only three instructions. L-WoX takes care of the NFC interaction.

Fig. 13.15 shows the Arduino firmware code. We used the M-WoX.h library we developed for embedded systems. Even here it is noticeable how short is the development effort. The smartphone's L-WoX instance and the Arduino's M-WoX instance silently uses the M-WoX application protocol to exchange data over the NFC link. The developer's only duty is to specify the callback function for each WoX role.

Generally, a billing system is already present at the business location. In this case, system integrators can use WoX APIs to add IoT functions to the system. For the considered scenario, we developed a sample billing system as a Java stand-alone application. In Fig. 13.16 we show a couple of code snippets of the billing system.

In Fig. 13.17 we show the prototyped barrier, whose status is simulated by a light bulb turning on and off. The reader can see the presence of the NFC shield and antenna, mounted on top of the Arduino, as well as the relays.

The light turns on/off in two cases: the user taps the button in the mobile app (hence the WoX Cloud is dragged in), or the user moves close the smartphone to the NFC antenna (direct M-WoX interaction, then the Arduino updates the WoX Cloud).

13.7.1 Conclusions

In this work we have presented the Web of Topics (WoX) approach, a novel design model that facilitates the design and development of innovative IoT scenarios. Despite the great spread of IoT devices in different context, nowadays IoT stakeholders face considerable difficulties in designing IoT applications without running into significant gaps with the solution domains. Moreover, there is a need to ease the access to the IoT nodes services also among physical nodes, particularly when they are technologically heterogeneous. The proposed model is based on the concept of Topic. Just like humans, IoT nodes and applications can talk and exchange information about a certain topic of interest. This kind of abstraction level ensures a lightweight configuration for physical nodes, and an intuitive metaphor for the IoT stakeholders, including the developers. The WoX model has been implemented on top of the EPCglobal architecture, which gives scalability, efficiency and robustness. The WoX reference model fills the gap between the Web of Things paradigm and the IoT apps. WoX aggregates data and events incoming from the WoT, providing ready-to-use information and concepts. This simplifies the mechanics behind the upper application levels as well as all the levels of knowledge base, ontology and knowledge discovery enriching the IoT and making it valuable for the people. WoX puts the basis for the definition of an interactive dialogue model between people and smart environments.

13.7.2 Open Issues and Future Challenges

WoX is inspired by the standard architectures proposed in the state of the art section, but it is not fully compliant yet. The main future work in this direction is the adoption of the O&M standard to describe the topics payload. Indeed, current topic payloads are primitive values (integer, float, string, boolean, etc.). Currently we are working on the development of the L-WoX app and process for the Android and iOS platforms. We are using the reflective architecture paradigm to let services dynamically downloading and installing adaptors from the repository. From the non-technical stakeholders' side, it is needed a WoX dialogue model intuitive notation allowing anyone to design their own IoT-based experience by the means of a simple authoring tool. we will build the WoX Author Web interface to let the users draw their scenarios and deploying them onto the Cloud. Another research direction will be the release of more programming languages WoX interfaces with an enhanced set of exposed APIs, as demanded by the developers involved in the experimentation.