The Web of Things (WoT) refers to those parts of the web consisting of special web application systems connected to the real world via sensors or actuators. These WoT systems include robots connected to the web as a special case. We propose a general framework for modeling, simulating, designing and building WoT systems. We propose a core ontology for WoT systems, which is the basis for our modeling and simulation approach. The modeling and simulation part of our framework is independent of the WoT and could also be employed in the engineering of other forms of embedded systems and robots. As a test case and a proof of concept we present an example of a green house WoT system.
The Web of Things (WoT ) is a subset of the Internet of Things (IoT ). While in the IoT, all kinds of Internet technologies can be used for building sensor-based information systems and device control applications, the WoT is based on web technologies only: foremost DNS, HTTP and HTTP-compatible protocols like Web Sockets and the Constrained Application Protocol (CoAP), and the user interface and frontend computing technologies HTML, CSS and JavaScript. The WoT consists of special web application systems connected to the real world via sensors or actuators, including robots connected to the web as a special case.
There are three recent trends promoting the WoT. First, the web's infrastructure has progressed dramatically 1) by extending the internet's address space with IPV6, 2) by continuously increasing the speed and bandwidth of internet connections, and 3) by improving the speed of HTTP with HTTP 2.0 as well as introducing near-real-time web protocols like Web Sockets. Second, the widespread use of smartphones and tablets, containing various sensors, has created a large pool of sensing and computing resources for the WoT. Third, the Entity name[0..1] : String participants receiver
*
Event
1 CommunicationEvent increasing availability of many kinds of cheap sensors, actuators and other electronics components has led to the development of a large Do It Yourself (DIY) robotics and WoT community, creating lots of open source software and hardware, and publishing a great variety of DIY projects1. The availability of all these resources, and, in particular, of low-cost hardware, creates new opportunities for WoT and robotics-related research and education.
For instance, a simple WoT project can be the temperature monitoring of a room by using a cheap temperature sensor, like the Texas Instruments LM352 (available for about 1 Euro), attached to a Raspberry Pi microcomputer (available for about 30 Euro) running a NodeJS-based web application on top of Linux and connected to the Internet via WiFi. More complex WoT systems, like a home security and monitoring system or a home robot that is able to move around and talk to people, can be built with hardware costs of a few hundreds Euro, only, possibly using a no-longer-needed smartphone as the control computer and exploiting its (GSM/3G and WiFi) communication and its (GPS, microphone, camera) sensing capabilities.
A critical issue for any kind of web application, and even more for device control applications in the WoT, is security. However, in this paper we do not treat security issues.
In the robotics and WoT research literature, as well as in the DIY robotics and WoT literature, there is still a lack of methodologies, including general approaches to modeling and simulation. Our aim is to develop a general framework for modeling, simulating, designing and building WoT systems (WoTS). The basis of this framework is a WoTS core ontology de ning such concepts as event, object, agent, sensor, actuator, etc. 1 See, e.g., http://www.instructables.com/tag/type-id/category-technology/. 2 Centigrade Temperature Sensor: http://www.ti.com/lit/ds/symlink/lm35.pdf «invariant» {startTime = occurrenceTime duration} «invariant» {duration = 0} * cause
0..1 CausedEvent ExternalPerceptionEvent *
InMessageEvent
ExogenousEvent
EnvironmentEvent OutMessageEvent
* 0..1 1 Message perceiver 1 1
a1ctor Agent
The last section presents a proof of concept implementation of a WoT system controlling a green house using our open source Java/Android-based WoTS implementation framework. *
AgentEvent
An ontology is a system of inter-related categories for classifying the things that
inhabit (some part of) our real world. A foundational (or upper-level ) ontology
identi es the most fundamental categories such as objects and events, while a
core ontology de nes the core concepts of a domain, based on a foundational
ontology. We use the Uni ed Foundational Ontology (UFO) proposed by
Guizzardi and Wagner in [
As can be seen in Figure 1, The most important top-level category in WoTCO is the category of PhysicalAgent, which is derived from both PhysicalObject and Agent. As a physical object, a physical agent is in time and space (and has physical attributes such as mass, spatial coordinates, velocity, etc.), and participates in events. As an agent, a physical agent has reactive behavior and may participate in out-message events as sender, and in in-message events as receiver.
As de ned in Figure 3, a WoT system is a physical agent. A WoTS component may be a sensor, an actuator or a human-interface device (HID).
Hid Actuator
Sensor «invariant» {Components contain at least one sensor coupled to at least one actuator.}
As de ned in Figure 2 and 4, we distinguish between environment events, which occur in (and are used for simulating) the environment, and agent events, which occur internally in agents. Our high-level view of the perception-action cycle of a WoTS can be described in WoTCO terms as follows. An external perception event, as an environment event, corresponds to a potential perception event enabled by physical causality. A sensor of a WoTS maps such an external perception event to an internal perception event (or sensor event). Then a reactive behavior rule maps this sensor event to an internal action event (or actuator command), which is mapped to an external action event via the used actuator. The newly created external action event can then cause another external perception event, which starts the cycle over again. 3
The IoT-A project has collected a report on the existing frameworks and
architectures [
The issues of searchability, shareability and composability of WoT systems
are discussed in [
An attempt to de ne a core ontology for robotics based on the foundational
ontology SUMO is made by the IEEE working group Ontologies for Robotics
and Automation (ORA) in [
inputs
* outputs
ExternalActionEvent 1 1
* outputs
* inputs *
resultingEvent
Our goal is to develop a general architecture for modeling, simulating, designing and implementing WoT systems. This means that a WoTS model specifes both both the WoT system to be realized and its simulations, which may be partial in the sense that any number of its components may be present in its con guration while all others are simulated. 4.1
Simulating WoTS Components
Our prototype WoT system presented in the next section is based on the
architecture metamodel shown in Figure 5, which is derived from the
Agent-ObjectRelationship Simulation Metamodel[
A component can be atomic (a Sensor, an Actuator or a Hid) or composite, like, for example, a robot arm composed of a set of interconnected sensors and actuators. Even sensors can be composite devices, as for example a humidity and temperature sensor in a single unit with a single communication interface.
A WoTComponent (sensor, actuator, HID) or WoTSystem can contain a set of custom de ned rules. The rule de nition speci es the type of the event which activate it. The project author is free to build simple or complex rules by using the capabilities of the used system implementation programming language. «interface»
EventListener on(in event : Event)
Event
0..1
* occurrenceTime[
priority[
ReactionRule 1 * «enumeration» EventPriority VERY_HIGH HIGH MEDIUM LOW VERY_LOW «interface»
EventSource addListener(in linstener : WoTSComponent) trigger(in listener : Event)
Also the behavior of a WoT system is de ned by reaction rules (e.g., trigger the alarm when an intruder is detected or start watering the owers when the soil moisture is under a threshold value). 4.2
Sensors
Sensors are mostly used to collect data. In general a sensor can be an atomic
component, having just one speci c function (e.g., a LM35 centigrade temperature
sensor) or a composite one, where multiple sensors are packed in one unit and
all of them use the same communication interface (e.g., 1-wire DHT22
temperature and humidity sensor). Sensors can be divided in categories based on their
types. Our category divisions (see Figure 6) were obtained by selecting the most
relevant types of sensors, according to [
Actuators
Actuators are in general simple electro-mechanical devices that require a signal
(voltage, current or a speci c protocols) to activate or deactivate them. The
most relevant categories, according to [
Human Interface Devices
According to [
LM35
ResistiveSoilMoistureSensor resistance : Double ChemicalSensor WeatherSensor
OpticalSensor
AcousticSensor PositionSensor
ProximitySensor NavigationSensor
RadioSensor
ElectricSensor MagneticSensor RadiationSensor
FluidFlow system and a human user who needs to interact with the system. Such devices can either be input or output devices, but can also be composite devices (providing multiple inputs, multiple outputs or multiple inputs and outputs). Examples of HIDs are displays (with or without touch screen), LEDs, keyboards, etc. 5
This section presents a project as a proof of concept for the proposed architecture. The project is about the implementation of a Green House, which is monitored and controlled by a WoT System. Speci c needs in terms of temperature, water and light have to be considered for the Green House. The system provides the following functionality: { soil moisture sensors measure from dry up to ooded soil. { the temperature is monitored and an automatic cooling system is activated to control the temperature (air ux may come from outdoors). { a speci c light intensity is required for an optimal production. { the water system can be started or stopped by using an electrovalve. A WoT project consists of a set of sensors that perceive the environment, a set of actuators with the purpose of performing physical actions, and a computer device connected to them and to the web via a web application. In general, a normal computer or smart device cannot be directly connected to sensors or actuators, but rather an interface board is needed for this purpose. Such a board is a device which allows to communicate via speci c protocols (e.g., USB, Serial, Parallel, etc) with the computer and in the same time provides I/O channels (via GPIO pins) to interface with sensors and actuators. Examples of such boards are: IOIO-OTG3 and Arduino4. One can also use development boards which provide a combination of mini-computers and interface boards in just one device, such as Beaglebone5 and Raspberry PI 6. There are some disadvantages in this case since usually the number of available GPIO pins is limited (e.g., Raspberry PI provides only 8, neither having analog capabilities) and others requires advanced programming skills to control the GPIO pins (e.g., Beaglebone requires advanced C/C++ and Assembler knowledges for more than blinking a led projects).
For our project we use the IOIO-OTG interface board, which allows to connect a smart device running Android v2.3 or higher with external components (e.g., sensors and actuators) by using the 46 GPIO pins. It provides multiple interfacing capabilities, such as communication via I2C, SPI and UART protocols, analog data reading (reads voltage within 0-3.3V range) and PWM (pulse width modulation) control with possibility of changing the frequency and duty cycle. The board is connected with the Android device via USB cable or bluetooth. For an optimal usage of the IOIO-OTG interface board, the Android device must have 512MB or more RAM memory and a CPU with a frequency over 1GHz.
The board itself does not require custom software to interface with external components. Instead it interfaces with the Android device via a Java API, which is rather generic and does not provide speci c implementation to interface with sensors or actuators, this being part of the custom project software implementation. Our Java prototype of the proposed WoT architecture includes the IOIO-OTG API and extends it with speci c sensors and actuators implementation, as the ones (but not only) used for the Green House project. 5.2
Hardware Con guration The system consists of the following hardware parts: { A Samsung Galaxy S (GT-I9000) smartphone running Android version 4.3.1. { A IOIO-OTG board is used as an interface between the smartphone and the system. It connects with the smartphone via bluetooth or USB cable. { The LM35 centigrade analog sensor is used to monitor the temperature.
It represents a speci c TemperatureSensor implementation, part of the WeatherSensor category (see Figure 6 and Figure 8). { The VT93N1 photo-resistor sensor, is used to detect the light intensity.
It represents a speci c PhotoResistorSensor implementation, part of the OpticalSensor category (see Figure 6 and Figure 8). { DIY custom soil moisture sensors are created with the help of nickeled nails, wires and resistors. Those sensors represents a speci c implementation of ResistiveSoilMoistureSensor, a speci c subclass of SoilMoistureSensor, part of the WeatherSensor category (see Figure 6 and Figure 8). 3 IOIO/IOIO-OTG - https://github.com/ytai/ioio/wiki 4 Arduino - http://www.arduino.cc/ 5 Beaglebone - http://beagleboard.org/Products/BeagleBone 6 Raspberry PI - http://www.raspberrypi.org/ { The electrovalve used to start/stop watter supply is activated and deactivated by using a PullDownRelayActuator (see Figure 7 and Figure 8). Such a relay type is closed by default, and is activated by connecting it to the ground of the power supply, from here its "pull down" name. { A set of mains powered coolers are used to keep the temperature in a speci ed range. PullDownRelayActuator relays are used to control their on/o states.
The air ow used to adjust the temperature level comes from outdoors. { A recycled ATX PC power supply (provides 12V and 5V at high current levels) is used to power all components except the ones being connected to mains power supply (cooling system).
The total cost of the system is about 200e , from which the sensors and the IOIO interface board cost about 50e . The rest of the price is for the electrovalve, relays, coolers and dimmable lights. The smartphone price is not included, but is currently evaluated to about 50-60e on the market. 5.3
Software Con guration Our WoT Java/Android implementation is used to implement the system software. It contains the code required to read the sensors and control the actuators. As already discussed in this paper, our architecture uses an event based communication between components and the system behavior is de ned by using reactive rules. For this project a set of rules are used to control the actuator components based on various sensor readings. For readability reasons, a pseudocode version of the rule is shown in this paper, but its Java version (as used by our architecture implementation) is also simple to write.
Temperature and Soil moisture Control: The LM35 sensor is used in AUTO mode, thus creating TemperatureSensorEvents (builtin event type which carries the temperature value) only when temperature value changed compared with latest known value. Controlling the cooling system is performed by using a rule shown below: WHEN TemperatureSensorEvent event if ( event.getTemperature() < lowRange) then CREATE DisableRelayEvent( CoolerRelay) elseif (event.getTemperature() > highRange) then CREATE EnableRelayEvent( CoolerRelay)
The coolers are started if a high temperature is detected. When the temperature goes back in the normal range, the coolers are stopped. The temperature is maintained in the speci ed range with the condition that outdoors temperature (from where the air ux come) is below the highest temperature value speci ed by our system. The same considerations are used to control the soil moisture, the di erences being the type of event which triggers the rule (SoilMoistureSensorEvent) and the moisture threshold values. Lights Control: Using PWM (pulse width modulation) one can control a light system to have not only light on and light o light states, but also various intermediate light intensity levels. Using the IOIO board we generate the PWM signals to control a set of PWM controlled dimmable lights. The following rule allows to control the light by changing the PWM duty cycle: WHEN LightSensorEvent event if ( event.getLuxValue() > highRange) then CREATE DisablePWMEvent( PWMLight) else DEFINE VAR dutyCycle = (targetLuxValue - event.getLuXValue()) / 100
CREATE ChangePWMDutyCycleEvent( PWMLight, dutyCycle)
The sensor returns values between 0 Ohm (direct sun light) and 300K Ohm (complete dark) which are internally converted to LUX values. Increasing the PWM duty cycle results in higher light levels. The targetLuxValue represents the target light intensity value (in LUX) for our Green House.
Safety Considerations: A WoT system presents safety risks in some cases. For example the malfunction of the soil moisture sensor in the case of the Green House project may result in ooding the plants. We are working on a solution to categorize the WoT components and events so that posible safety risks are limited as much as possible. Additionally, implementing some WoT systems may require to work with possible dangerous voltage levels for the human body, e.g., using mains power. Such safety risks must be considered by the hardware project author.
Project Enhancements: The project was prototyped in a room by replacing the mains powered coolers with PC coolers and the electrovalves with LEDs. The project will be improved by allowing a human user to interfere with the automated actions if required (e.g manually start or stop the water or coolers). Additionally, a data collector component will be added to have statistics about the expenses by monitoring the consumed water and electricity. This is possible by using sensors to read and monitor consumed electrical power and water volume. 6
We have presented an ontology and metamodels for modeling, designing and simulating WoT systems. A simple, but illustrative, test case implementation was shown as a proof of concept. We still have to make our framework more complete, e.g., by developing a general approach how to create simulation models for speci c sensors and actuators based on their technical speci cation provided by the vendor.