Semantic Modeling of a VLC-Enabled Task Automation Platform for Smart Offices

Abstract

The evolution of ambient intelligence has introduced a range of new opportunities to improve people’s well-being. One of these opportunities is the use of these technologies to enhance workplaces and improve employees’ comfort and productivity. However, these technologies often entail two major challenges: the requirement for fast and reliable data transmission between the vast number of devices connected simultaneously, and the interoperability between these devices. Conventional communication technologies present some drawbacks in these kinds of systems, such as lower data rates and electromagnetic interference, which have prompted research into new wireless communication technologies. One of these technologies is visible light communication (VLC), which uses existing light in an environment to transmit data. Its characteristics make it an up-and-coming technology for IoT services but also aggravate the interoperability challenge. To facilitate the continuous communication of the enormous amount of heterogeneous data generated, highly agile data models are required. The semantic approach tackles this problem by switching from ad hoc application-centric representation models and formats to a formal definition of concepts and relationships. This paper aims to advance the state of the art by proposing a semantic vocabulary for an intelligent automation platform with VLC enabled, which benefits from the advantages of VLC while ensuring the scalability and interoperability of all system components. Thus, the main contributions of this work are threefold: (i) the design and definition of a semantic model for an automation platform; (ii) the development of a prototype automation platform based on a VLC-based communication system; and (iii) the integration and validation of the proposed semantic model in the VLC-based automation platform.

1. Introduction

The extension of Internet connectivity to physical devices and everyday objects has become the foundation of the concept of “smart homes” [1]. The main goal of smart technology is to improve people’s well-being by reacting and adapting according to information obtained from the environment [2]. Enabling new services and applications that take advantage of the interconnection of the physical and virtual domains leads to new opportunities and opens up a range of possibilities [3]. One of these possibilities is the application of these technologies in offices and workspaces, allowing companies to improve the comfort, performance, and productivity of their employees by supporting and meeting their needs [4].

However, the huge (and increasing) number of connected devices, along with the requirement for fast, reliable, and cost-effective data transmission, pose a challenge for these kinds of systems [5]. Several Radio Frequency (RF)-based wireless technologies have been used to provide Internet of Things (IoT) services: WiFi [6], Bluetooth [7], Near-Field Communication (NFC) [8], or Zigbee [9], and also Low Power Wide Area Network (LPWAN) technologies such as SigFox [10], NB-IoT [11], or LoRa/LoRaWAN [12]. Nevertheless, these technologies present some drawbacks, such as Electromagnetic Interference (EMI), a limited frequency spectrum, and, in some cases, a lower data rate [5]. These problems have pushed the investigation of new wireless communication technologies, such as Visible Light Communication (VLC) [13]. VLC uses the existing light in an environment (e.g., Light Emitting Diode (LED) lights) for transmitting data, exploiting the bandwidth of visible light, which is almost ten times wider and completely different from that of conventional wireless access technologies [14]. Furthermore, the use of existing LED-based lighting infrastructure in buildings for lighting and data communication simultaneously can notably reduce the operating costs and carbon footprint [5]. These features make VLC a very promising technology for IoT services [15].

The success of the technology largely depends on its user acceptance and ease of use [16]. In this regard, one of the major challenges of intelligent environments is the interoperability between different platforms and components, which is further compounded by the integration of new communication technologies [17]. The information in these systems is transmitted to and from various devices and services through heterogeneous network protocols and communication technologies [18]. In order to facilitate the continuous communication of the huge amount of heterogeneous data generated, very agile data models are required [19]. The semantic approach addresses this problem by replacing ad hoc application-centric representation models and formats with a formal definition of concepts and relationships [20]. These definitions are known as ontologies or vocabularies and enable the interoperable representation of inferred data, solving the problems of isolation between heterogeneous information and providing a better understanding of the environment [21]. In addition, semantic representation significantly improves system scalability by providing a rich, machine-readable format that can be understood, reasoned about, and reused. These capabilities have boosted the tendency of integrating semantic technologies into the Internet of Things [22]. Nevertheless, there is still a lack of a semantic model that covers the representation of the automation domain. Moreover, whereas smart office automation is already being implemented by using conventional wireless technologies, VLC is hardly used [23].

This paper aims to fill this gap by proposing a semantic vocabulary for an intelligent automation platform based on VLC that benefits from the advantages of VLC while guaranteeing the interoperability and scalability of all system components. Thus, the main contributions of this paper are threefold: (i) the design and definition of a semantic model for an automation platform; (ii) the development of a prototype automation platform based on a VLC-based communication system; (iii) the integration and validation of the proposed semantic model in the VLC-enabled automation platform.

The remainder of the article is structured as follows: Section 2 introduces the background and related work of the technologies used in this work. Once the technologies involved in this work have been reviewed, a scenario for introducing the proposed system is described in Section 3. The design and definition of the semantic model are explained in Section 4, while a prototype of the VLC-enabled semantic task automation platform is given in Section 5. Lastly, an evaluation of the proposed semantic model using competency questions is presented in Section 6, and Section 7 describes the conclusions drawn from this paper and an outline of possible lines of future work is presented.

2. Related Work

This section presents the background and related work of the technologies involved in the paper. Given the different technologies used in this work, this section has been split into three subsections. First, Section 2.1 gives an overview of related work in ambient intelligence and specifically in smart offices. Then, an introduction and revision of the state of the art in VLC are described in Section 2.2. Lastly, Section 2.3 presents the state of art regarding semantic technologies.

2.1. Smart Offices

The rise in the popularity of IoT has spread widely to simple household applications and everyday tasks, intending to improve the well-being and comfort of people. For example, a system can be configured to monitor specific parameters of an environment, such as temperature, air quality, or luminosity, helping users to keep them within an acceptable range and improving human comfort [24].

Applying these technologies to the work environment has resulted in the concept of the “smart office”. This new paradigm for industrial activities has been applied to various official and industrial tasks [25], including manufacturing, healthcare, communications, and agriculture [26]. A company can leverage these technologies to improve the comfort and well-being of the workers, which may result in higher performance and productivity [4]. With this aim, smart offices must efficiently and proactively manage the infrastructure deployed in the workplace and the enterprise systems [27]. The scientific literature shows different approaches addressing smart offices and identifies the main challenges to tackle in the design, implementation, and optimization of these systems [28,29,30,31]. Shigeta et al. [32] propose a smart office system able to recognize the workers’ mental and physiological states through several biometric sensors and to adapt the environment to the mood of the users for enhancing their comfort. The adaptation uses an aroma generator, a speaker, and color lights. The use of lights is also exploited by Andrei Mocanu [33], who provided a solution aimed at identifying a specific task and adapting the light accordingly. The system can predict future activities and provide reliable recommendations. These technologies have also been used for improving energy efficiency, as proposed by Xin Wang et al. [34]. They describe an automatic office lighting control system based on the occupancy status. In addition, the presence detection system can also be used as a security system to discover the presence of intruders or burglars.

The reviewed works show specific examples of smart office solutions to improve well-being. Several systems capable of performing environment adaptation according to the users’ needs are presented in them. However, as far as we know, no work in the literature adequately addresses the use of VLC as a communication system in a smart office to take advantage of the benefits of this type of technology compared to RF-based communication. This work aims to fill this gap by proposing a smart office automation platform that uses a VLC system to communicate with sensors.

2.2. Visible Light Communication

The growing demand for high data rates and the immense number of connected appliances leads to the overloading of conventional radiofrequency technologies, saturating the RF spectrum. This makes it necessary to resort to new communication technologies. One of the technologies that has gained much popularity in recent years is VLC [13]. VLC has emerged as an alternative solution, in which a light source is used simultaneously for lighting and data transmission. The possibility of enabling simultaneous illumination and communication has led VLC to become a novel alternative to RF. Compared to RF links, VLC links feature a very large bandwidth that enables much faster transmission rates. Specifically, VLC uses the visible light region of the electromagnetic spectrum, whose wavelength ranges from 380 nm to 780 nm, equivalent to a frequency between 430 THz and 790 THz approximately [35]. Compared to other wireless technologies, VLC technology presents better stability, higher speed, immunity to electromagnetic interference, a higher level of security, the availability of unlicensed channels, and lower costs [36]. The superior stability of VLC systems refers to the specific low degree of failure. As long as a VLC communication system does not require a permanent Internet connection, it will continue to operate (data transmission) at full capacity as long as the lighting infrastructure is operational. Moreover, VLC can achieve data rates of over 10 Gbit/s and can be used in electromagnetically sensitive areas without electromagnetic interference. From the point of view of the higher degree of security compared to WiFi technology, it must be taken into account that a closed VLC communication system can only be penetrated from inside the areas where it is implemented. Outside penetration, as can be encountered in the case of systems based on the usage of TCP/IP communication protocols, is impossible. Furthermore, even if an intruder succeeds in traversing the VLC perimeters, the penetration of the optical communication channel is only possible by using specially developed VLC devices for demodulating the VLC data packets. Hence, a high degree of reliability and security in communication can be guaranteed [35]. Finally, VLC is license-free and it is considered cheaper than other licensed technologies (for example, it is expected to be ten times cheaper than WiFi [36]). This communication system can be based on low-cost LED devices, taking advantage of their capability to switch between different light intensities at high speed, so that it is imperceptible to the human eye [37]. In this way, they facilitate high data transfer. Nowadays, LED illumination is the most broadly used light source [38], providing a robust infrastructure for establishing fast VLC communications.

The beginnings of visible light communication date back to the 2000s in Japan, when researchers at Keio University used white LED for illumination and communication [39]. Following this achievement, several studies have been published on the use of LEDs in communication systems, and many initiatives have been observed to foster and standardize VLC technology. One of these initiatives is the Visible Light Communication Association (VLCA) (available at https://j-photonics.org/vlca/en/ (accessed on 10 June 2021), which is the successor of Visible Light Communication Consortium (VLCC), a consortium including the main Japanese companies that was established in 2003 for the standardization of VLC technology. In addition, in 2011, the IEEE 802.15 working group for wireless personal area networks published the first IEEE standard related to VLC (802.15.7-2011). The details of this standard regarding data rates, modulation schemes, coding, and attenuation mechanisms are discussed in [40].

However, regardless of the great advantages of VLC technology and the variety of its applications, its dependence on a direct line of sight has hindered its use. In recent years, hybrid RF/VLC systems have been proposed to benefit from the high capacity of VLC links and the improved connectivity of RF links. Therewith, RF/VLC hybrid systems are a pivotal element in optimizing capacity, interference, and overall network power consumption. Numerous studies are investigating how RF and VLC systems can complement each other, leveraging the advantages of each of the technologies to overcome their limitations. One of the first studies to present this idea was proposed by Haijun Zhang et al. [41], presenting an RF/VLC asymmetric combination in which VLC is used for downlink and RF for uplink in a duplex system. A hybrid RF/VLC system was also proposed by Jiaxuan Chen et al. [42] for a vehicular communication system. In addition, the use of hybrid technologies for energy efficiency improvement represents an important application. Justin Kong et al. [43] explored this idea to improve the energy efficiency of a heterogeneous network of VLC and RF systems. The obtained results of the conducted experiments confirm the improvement in the energy consumption of the proposed system. Moreover, many studies have been conducted on VLC to improve its functionality [13,44]. However, the use of VLC for providing IoT services has not been extensively studied [14].

2.3. Semantic Technologies in Ambient Intelligence

The evolution and growth of ambient intelligence have boosted the number of connected devices and services in our daily lives. The result is that an enormous amount of data is produced. The great heterogeneity of the IoT in terms of devices, communication protocols and technologies, and data formats makes semantic interoperability one of the most critical challenges to resolve in these systems [22]. Therefore, it is necessary to establish a standard set of rules for exchanging information between independent systems. These rules should include expected formats, schemas, and behavior. Semantic technologies help to address this problem with a standard definition of concepts and relationships that replaces application-centric representation models and formats. These definitions establish a mechanism for sharing knowledge, and are known as ontologies or vocabularies [45]. Ontologies help to exchange semantically annotated information between heterogeneous applications, resulting in a significant enhancement in interoperability and scalability.

Each ontology typically represents a domain in detail, and they take some concepts from others when necessary. Later, systems can use parts or modules of different ontologies jointly to represent the full breadth of their knowledge. Semantic modeling has become a ubiquitous approach to data semantization in healthcare and smart cities. One of the first ontologies for IoT systems was Brick, proposed by Balaji et al. [46]. Brick is an ontology for energy efficiency in smart buildings that uses tags to identify components and devices inside buildings. Another relevant ontology for IoT systems is the Smart Appliance Reference Ontology (SAREF) [47], intended to describe, at a high level, smart appliances along with their services. The SAREF model includes concepts such as sensor, service, state, and function, being generic enough to be used in different smart domains. However, it applies most naturally to limited spaces such as homes or offices. Finally, the W3C Semantic Sensor Network Incubator Group proposed the Semantic Sensor Network (SSN) ontology [48], one of the most prominent ontologies within the IoT domain. SSN, published in 2012, enables the representation of concepts such as sensor, actuator, and observation. A few years later, in 2017, the SSN ontology was updated, giving rise to the Sensor, Observation, Sample, and Actuator (SOSA) ontology [49].

The previously described ontologies allow the modeling of the devices, platforms, and communication systems present in an intelligent environment, but do not cover the modeling of the automation process. The Evented Web (EWE) ontology [50] was designed with this purpose: to enable the modeling of the rule-based automation process in an intelligent environment. It describes the most significant aspects of task automation services in an illustrative way, and provides a standard model for its representation. The main elements of the ontology have been defined and formalized on the basis of several identified perspectives (configurability, privacy, communication, and integration). Moreover, EWE is based on Web Ontology Language (OWL) 2 classes, and there are implementations of EWE enabling inferences using a SPARQL Inferencing Notation (SPIN) Engine (TopBraid (available at https://www.w3.org/2001/sw/wiki/TopBraid (accessed on 20 June 2021)) and Notation 3 (N3) Logic (Euler Yet another proof Engine (EYE)) (available at http://eulersharp.sourceforge.net/ (accessed on 5 June 2021)).

With the rise of the Semantic Web, technologies for defining and managing ontologies have grown considerably. For example, numerous repositories have emerged for storing data in a semantic format, such as Virtuoso, Apache Jena TDB, and GraphDB. In addition, the formats, protocols, and conventions used to model and exchange semantic information are standardized and well known (SPARQL Protocol and RDF Query Language (SPARQL), Resource Description Framework (RDF), JSON-based Serialization for Linked Data (JSON-LD)). However, no semantic model has been developed for an automation platform based on VLC communication, to the best of our knowledge.

3. Scenario

To better understand the scope of the proposed system, we have defined the following scenario. Consider a highly skilled Information Technology (IT) Small and Medium Enterprise (SME) where company leaders want to improve the comfort and well-being of their employees. Company leaders expect that an increase in their well-being would be translated into better performance and productivity [51]. For this purpose, they want to implement an intelligent automation platform in their offices that adapts the environment to the workers’ needs. The employee’s expectations for a workplace include proper lighting, a comfortable temperature, clean air, and reduced noise levels [4,52,53]. In order to address these expectations, the company proposes the use of different sensors and actuators that help to maintain these conditions at their optimum levels:

1.

A temperature sensor is used to detect whether the office temperature is outside of the range configured as a reference for the employees’ comfort;

2.

A motion sensor is used to detect whether there are or are not people in the office;

3.

A dust sensor is used to measure the air quality and detect when this quality is below the required value;

4.

A luminosity sensor is used to continuously monitor the intensity of the light in order to guarantee optimum light conditions;

5.

A noise sensor is intended to detect whether the environment’s noise level is too high;

6.

Intelligent LED lights enable the configuration of the intensity, color, and temperature;

7.

An air purifier is able to filter the air to improve its quality;

8.

A smart Heating, Ventilation, Air Conditioning (HVAC) system allows users to control the air conditioning and heating in order to achieve the optimum temperature;

9.

A voice assistant is intended to provide voice alerts to users when any of the conditions is outside of the comfort ranges.

In order to not interfere with the existing RF systems in the office, the company considers the use of VLC for communicating with the sensors. In this way, the company can use the LED lights simultaneously for illumination and communication. Furthermore, intending to guarantee the interoperability and scalability of the system, the company proposes the use of semantic modeling for all the components involved in the intelligent environment. This allows the company to ensure interoperability between all the elements in the system and facilitate the integration of new components. An overview of the proposed smart environment is given in Figure 1.

Once the semantic task automation platform is implemented, the company can define different automation rules that help to maintain the ambient conditions at the required levels. Some examples of these rules are:

1.

If the dust level is too high, increase the power of the air purifier. This rule helps to maintain a good value for the air quality, increasing the power of the air purifier when the dust level rises above a certain limit.

2.

If the noise level is high, suggest silence by means of the voice assistant. The voice assistant can be used for sending alerts to workers. In this rule, an alert is played by the voice assistant if the noise level is too high.

3.

If the temperature falls below 20 °C, adjust the temperature to 22 °C. Working at too low or too high temperatures can significantly reduce employees’ well-being, so this rule enables the automatic control of the ambient temperature to prevent too low values.

The platform allows the adaptation of the environment to the users’ needs. Therefore, the company and workers can configure and customize their own automation rules to enhance the working conditions, comfort, and well-being. The following section describes the approach followed for the semantic modeling of the platform.

4. Semantic Modeling

In order to apply a semantic layer to the VLC-enabled automation platform, a vocabulary with the corresponding relationships between ontologies has been defined. This vocabulary enables the semantic modeling of all entities in the smart office environment. The defined vocabulary is based on two existing ontologies: SSN (and its core, SOSA) and EWE. Figure 2 shows the classes of these ontologies that we have used for defining our model, along with the relationships between them.

The SSN ontology is organized into several modules [54]. Its core module is the so-called SOSA (Sensor, Observation, Sampling, Actuator), an independent and lightweight module that defines the elementary classes and properties. SOSA can be used as a standalone ontology to broaden the target audience and application, as it provides a flexible framework that enables the representation of all the entities involved in sensing and actuation, along with the relationships between them [49]. We can analyze SOSA from two different perspectives: observation and actuation.

From the observation perspective, we find classes that provide a pattern and terminology that can be used for sensing and measuring activities. The observation of a property is considered an event, completed when the result is available. In particular, SOSA defines the class Sensor, a physical device that performs an Observation about some ObservableProperty. From the actuation perspective, we find classes that allow us to model the changes and actuations. With this purpose, SOSA provides the class Actuator, which represents a physical device performing an Actuation on some ActuatableProperty. ObservableProperty and ActuableProperty are subclasses of ssn:Property, which represents a quality of an entity. Finally, SOSA provides two models to attach the value of a property to observation or actuation activities. First, the sosa:hasSimpleResult property is used to indicate a simple literal. Second, the object property sosa:hasResult is used to link an individual to the observation.

The SSN ontology allows us to model the physical devices existing in the system. In order to model the process of automation, we use the EWE ontology [50], a vocabulary that allows us to model the most relevant aspects of task automation services. The core of EWE is formed by four major classes: Channel, Event, Action, and Rule. The class Channel represents entities (devices or services) that either generate events, provide actions, or both. In the smart office context, sensors and actuators such as a motion sensor or an air purifier are described as channels, and their observations or actuations as events and actions. The class Event represents a particular occurrence of a process (such as an observation of a property) and allows users to define under which conditions the corresponding actions should be triggered. Event individuals are generated by a specific channel and usually provide additional details that can be modeled as parameters, using the class Parameter. These parameters can be used within rules to customize actions. The detection of motion generated by the motion detector sensor is an example of an entity that belongs to the Event class. The class Action represents an operation (or actuation) provided by a channel that is triggered under some conditions. Actions provide actuations on specific properties, and can be configured to react according to the data collected from a certain event using the class Parameter. Following the smart office context mentioned above, to switch on the air purifier is an example of Action generated by the air purifier channel. Lastly, the class Rule represents an Event, Condition, Action rule, i.e., an automation rule triggered by an event that fires the execution of an action. An example of a rule is: “If a motion is detected, switch on the air purifier”.

Based on these two ontologies, we propose a semantic model for the VLC-enabled automation platform. A general overview of the model is given in Figure 3. In order to benefit from the features of the SSN and EWE ontologies, the proposed model divides some of the provided classes into subclasses. In this way, we define the classes vlctas:SensorChannel and vlctas:ActuatorChannel, which are subclasses of ewe:Channel. In addition, vlctas:SensorChannel is a subclass of sosa:Sensor and vlctas:ActuatorChannel is a subclass of sosa:Actuator. This allows us to treat each channel as a sensor or an actuator depending on its nature. Moreover, by means of the ewe:generatesEvent and ewe:providesAction properties, we can model the events and actions of a channel. We consider that each sosa:Observation can be seen as an ewe:Event, and each sosa:Actuation as a ewe:Action. Following this idea, we have defined the class vlctas:ObservedEvent, which is a subclass of ewe:Event and sosa:Observation; meanwhile, vlctas:TriggeredAction, is a subclass of ewe:Action and sosa:Actuation. Finally, the observations and actuations have a result, which we can consider a ewe:Parameter. In this way, we have defined the class vlctas:Parameter as a subclass of ewe:Parameter and sosa:Result.

In the considered scenario, each sensor or actuator can be modeled as a channel: temperature sensor, air purifier, etc. In order to offer a better idea of how specific components of the system have been modeled, we show an example written in Notation3 with the modeling of one of the rules described in Section 3: “If the temperature falls below 20 °C, increase the temperature to 22 °C”. The first step is to define the property to measure or change (in this case, the temperature). Then, we can define the channels representing the sensors and actuators, along with their events and actions. Finally, we could also define some custom properties useful for defining the parameters of events and actions. Listing 1 shows these definitions.

Listing 1. Semantic representation written in N3 of channels, events and actions related to temperature.

vlctas:Temperature a owl: Class ;

rdfs:label "Temperature"@en ;

rdfs:isDefinedBy vlctas: ;

rdfs:subClassOf sosa:ObservableProperty ;

rdfs:subClassOf sosa:ActuableProperty .

vlctas:TemperatureSensor a vlctas:SensorChannel ;

rdfs:label "Temperature sensor"@en ;

sosa:observes vlctas:Temperature ;

ewe:generatesEvent vlctas:TemperatureMeasured .

vlctas:HVACSystem a vlctas:ActuatorChannel ;

sosa:forProperty vlctas:Temperature ;

ewe:providesAction vlctas:AdjustTemperature .

vlctas:TemperatureMeasured a vlctas:ObservedEvent ;

rdfs:label "Temperature  Measured"@en ;

sosa:observedProperty vlctas:Temperature .

vlctas:AdjustTemperature a vlctas:TriggeredAction ;

rdfs:label "Adjust Temperature"@en ;

sosa:actsOnProperty vlctas:Temperature .

vlctas:hasTemperature rdfs:subPropertyOf ewe:hasParameter ;

rdfs:subPropertyOf sosa:hasSimpleResult ;

schema:domainIncludes vlctas:TemperatureMeasured ;

schema:domainIncludes vlctas:AdjustTemperature ;

schema:rangeIncludes xsd:double .

vlctas:hasTime rdfs:subPropertyOf ewe:hasParameter ;

rdfs:subPropertyOf sosa:resultTime ;

schema:domainIncludes vlctas:TemperatureMeasured ;

schema:rangeIncludes xsd:dateTime .

In this way, every observation or actuation of a device can be modeled semantically. For example, Listing 2 shows the definition of two events representing the observation of the temperature at two different times. The events have been modeled with grounded parameters on the basis of the concepts defined in the listing given above.

Listing 2. Instances of the event of temperature measurement.

:tempmeasure1 rdf: type vlctas:TemperatureMeasured ;

ewe:generatedBy vlctas:TemperatureSensor ;

vlctas:hasTemperature "15.7"^^xsd:double ;

vlctas:hasTime "2021-09-24T06:56:12Z"^^xsd:dateTime .

:tempmeasure2 rdf: type vlctas:TemperatureMeasured ;

ewe:generatedBy vlctas:TemperatureSensor ;

vlctas:hasTemperature "22.7"^^xsd:double ;

vlctas:hasTime "2021-09-24T12:51:52Z"^^xsd:dateTime .

Finally, Listing 3 shows the definition of rule instances. This example represents a rule that is triggered by the event of TemperatureMeasured when the observed temperature is lower than 20 °C and fires the action of adjusting temperature to 22 °C (both defined in Listing 1). Moreover, Notation3 supports rules and formulae, so we can express the rule using the formulae as shown in Listing 4. This allows us to use a semantic engine (or reasoner) to infer the action from the event received.

Listing 3. Rule instance.

vlctas:RegulateTemperature a ewe:Rule ;

dcterms:title "Temperature Regulation Rule" ;

ewe:triggeredByEvent [

rdf:type vlctas:TemperatureMeasured ;

ewe:generatedBy vlctas:TemperatureSensor ;

vlctas:hasTemperature [

math:lessThan "20.0"  ^^xsd:double

]

] ;

ewe:firesAction [

rdf:type vlctas:AdjustTemperature ;

ewe:providedBy vlctas:HVACSystem ;

vlctas:hasTemperature "22.0" ^^xsd:double

] .

Listing 4. Automation rule formulae.

{

?event  rdf:type vlctas:TemperatureMeasured ;

ewe:generatedBy vlctas:TemperatureSensor ;

vlctas:hasTemperature [

math:lessThan "20.0"

] .

}

=>

{

?action  rdf:type vlctas:AdjustTemperature ;

ewe:providedBy vlctas:HVACSystem ;

vlctas:hasTemperature "22.0" ^^xsd:double .

}.

5. A Prototype of a Semantic Task Automation Platform with VLC

The proposed architecture has been designed on the basis of the reference architecture for task automation services [50], which has been extended to enable VLC. The system is composed of two main parts: a VLC system and a task automation server, as shown in Figure 4. The former implements the visible light communication system and contains the modules involved in the communication with the sensors. The automation system receives the data coming from the sensors, applies semantic modeling to these data, and evaluates the events along with the automation rules in order to trigger the respective actions. In addition, it includes several functions for managing and configuring automation rules.

5.1. VLC System

This module implements the communication based on visible light. The system uses this kind of communication to receive data from sensors, so this module is responsible for the collection of these data and their dispatch to the automation platform. The module consists of two main parts: a transmitter and a receiver. The former obtains data from the sensors and sends the information to the receiver through visible light. An overview of the architecture of each part is given in Figure 5. As can be seen, both are based on the Raspberry Pi 3 Model B+ minicomputer.

The transmitter includes the processing unit, a control module, and an LED matrix. In addition, it is connected to various sensors in order to measure different ambient conditions: temperature, air quality, noise, luminosity, and motion:

1.

The LM35 sensor is used to measure the environment’s ambient temperature;

2.

The TSL235R sensor monitors the luminosity;

3.

The PIR HC-SR501 is a motion sensor designed to monitor the ambient environment and detect when there is someone in the workplace;

4.

The GP2Y1014AU0F sensor is used to monitor the air quality, measuring the dust concentration within the air;

5.

The LM393 module is intended to detect the environment’s noise level.

The output data of each sensor are transformed into a binary number. These binary values collected for each measurement are concatenated to obtain a binary string. Using the 3.3 V logic, each 1 in the string corresponds to a HIGH signal, whereas 0 corresponds to a LOW value. The 3.3 V interface is connected to a signal conditioning circuit with a Negative-Positive-Negative (NPN) transistor and an electromechanical relay. In order to obtain data from the sensor and convert them into a digital signal, the transmitter uses an MCP-3008 analog-to-digital converter. Even if some of the sensors are digital and would not require a connection through the MCP-3008, it was preferred that all of them be connected to it. This enables easier integration and processing of the data. Moreover, in order to facilitate the integration of new sensors, the Serial Peripheral Interface (SPI) protocol is used between the Raspberry Pi and the converter. The data packets are collected by the microcontroller, and then are sent to the control circuit of the LED. In order to achieve the fast switching of the LED, this circuit is formed by two transistors in the Darlington connection. Finally, the data packets are modulated using the On-Off Keying (OOK) modulation and sent to the receptor using the LED lights.

The receptor includes the processing unit and a photodiode. The photodiode detects the optical signal emitted by LEDs and converts it into an electrical signal. Then, the microcontroller converts the analog signal into a digital one, which is dispatched to the automation platform. Finally, it is interesting to note that the photodiode can be calibrated using ambient light, in order to determine the threshold value used to identify the logic value of the received binary signal.

Regarding the placement of the transmitter and the receiver, the presence of a line-of-sight link between them is essential to provide a suitable data rate performance. For this reason, the employee behavioral patterns and building-specific electrical plans must be taken into account during the implementation planning. In this way, the possibility of unintentional blocking of optical transmission or reception sources is minimized. The proposed system has been thoroughly evaluated in previous works, which include numerous scenarios to test the system’s performance, both in indoor and outdoor conditions [55,56].

5.2. Automation Platform

The main goal of this module is to enable the adaptation of the environment depending on the data received from the sensors. It is based on semantic Event, Condition, Action automation rules and provides integration with several devices and services, such as an air purifier or the HVAC system. Moreover, it allows users to configure custom automation rules or import rules created by other users easily.

The platform receives data coming from the sensors through the VLC system. It encodes these data using semantic technologies (as described in Section 4), and then the received events are captured and dispatched to the rule engine, where they are evaluated along with the stored automation rules. The rule engine module receives events from the events manager and loads the automation rules stored in the repository. It consists of a semantic engine reasoner [57] based on an ontology model. Once the event is received and the available rules are loaded, the reasoner runs the ontology model inferences in order to draw the corresponding actions depending on the incoming events and the automation rules. The drawn actions are then sent to the action trigger, which connects with the corresponding actuators channels that will perform the generated actions. This connection with the channels is carried out using their own communication interfaces. Therefore, the integration of such components and optical communication elements into the platform actually results in a hybrid system.

In addition, the platform provides the repositories where rules are stored, as well as functions for managing rules and channels. In order to enable the configuration and management of automation rules, the platform provides a mobile client and a web client where users can easily create, remove, or edit rules. The clients connect with the rule editor module, which handles the corresponding changes in the repositories. The platform includes two different repositories: the rule repository and the vocabularies repository. The former is used to store information regarding rules, whereas the latter contains information regarding channels. In the smart office context proposed, the rules are intended to regulate the ambient conditions in order to maximize comfort and productivity. With this aim, the rules enable the automation and regulation of temperature, air quality, noise, and luminosity conditions.

The implementation of this architecture has been performed using Python, and the semantic automation is based on N3 technology and the EYE reasoning engine (available at http://n3.restdesc.org/) (accessed on 27 June 2021). This results in a lightweight program that can be run also on devices with low resources. For the web and mobile clients, React and Kotlin are used, respectively.

Finally, the system enables rule adaptation on the basis of channel description. Rule adaptation is based on discovering whether the channels used by a specific rule are integrated into an intelligent environment. The system detects available channels of the same class used by the rule and asks for a confirmation from the user to import the adapted rule. In this way, rules can be adapted to different channel providers. The EWE ontology enables this adaptation by means of the OWL2 (available at: https://www.w3.org/TR/owl2-overview/) (accessed on 4 July 2021) punning mechanism for attaching properties to channels [50]. Moreover, the notion of adapters [58,59] is used for supporting the semantic integration of devices and services. These adapters interact with devices and Internet services in order to provide a semantic output.

6. Evaluation

In order to evaluate the proposed semantic model, we defined a set of Competency Questions (CQs) to check its selection capabilities. CQs represent the ontology requirements and consist of a set of queries related to the data that the ontology must be able to answer correctly [60]. A common user may complete these queries in order to retrieve information about the rules and channels available, the events and actions of a particular type, or the number of configurable parameters. The defined CQs are:

1.

Which sensor channels are integrated into the automation platform? Task automation platforms offer a list of available channels. Using the proposed model, it is also straightforward to filter these channels depending on whether they are sensors or actuators.

2.

Which sensors can measure temperature? Often, users in a task automation platform need to know which of the integrated sensors can measure a specific property, or which of the actuators can change this property. The proposed model enables filtering between all the provided channels by those able to measure or act on a certain property.

3.

Which actions provide the HVAC system actuator? Knowing which events or actions are available for a specific channel allows users in the task automation platform to have a clear notion of the capabilities of each device.

4.

Which parameters and which type accept the action “Adjust Temperature”? This query gives insight into the configurable parameters of each event or action, which enables the custom configuration of automation rules. Knowledge of the configurable parameters allows users to benefit from all the possibilities offered by the system.

5.

How many rules are triggered by a change in noise level? The proposed model allows users to know the platform’s capabilities concerning a specific property. In this way, they could extract information about the number of rules affecting the property and obtain the particular devices involved in these rules.

6.

How many rules trigger an action provided by the AirPurifier actuator channel? Occasionally, users need insights into the use they are giving to each channel. This allows them to analyze whether some sensor or actuator is not being used as it should.

These queries have been coded using SPARQL and run on the semantic repository.

Table 1. Example CQs using the proposed model written in SPARQL.

CQ	SPARQL Query	Results
Which sensor channels are integrated into the automation platform?	SELECT ?sensorLabel WHERE { ?sensor rdf:type vlctas:SensorChannel ; rdfs:label ?sensorLabel. }	Luminosity sensor, Motion sensor, Noise sensor, Dust sensor, Temperature sensor
Which sensors can measure temperature?	SELECT ?sensorLabel WHERE { ?sensor rdf:type vlctas:SensorChannel ; sosa:observes vlctas:Temperature ; rdfs:label ?sensorLabel. }	Temperature sensor
Which actions provide the HVAC system actuator?	SELECT ?action WHERE { vlctas:HVACSystem ewe:providesAction ?action. ?action rdfs:label ?actionLabel. }	Adjust Temperature, Turn On, Turn Off
Which parameters and which type accept the action “Adjust Temperature”?	SELECT ?param ?type WHERE { ?param rdfs:subPropertyOf ewe:hasParameter ; schema:domainIncludes vlctas:AdjustTemperature ; schema:rangeIncludes ?type. }	Temperature (double)
How many rules are triggered by a change in noise level?	SELECT (COUNT(?rule) as ?number) WHERE { ?rule rdf:type ewe:Rule; ewe:triggeredByEvent ?event . ?event ewe:generatedBy ?channel . ?channel ?observes vlctas:Noise . }	4
How many rules trigger an action provided by the AirPurifier actuator channel?	SELECT (COUNT(?rule) as ?number) WHERE { ?rule rdf:type ewe:Rule; ewe:firesAction ?action . ?action ewe:providedBy vlctas:AirPurifier. }	5

shows each executed query, along with the results retrieved from the repository.

Compared with other automation systems, the semantic modeling of the automation platform enables access to information about components that are not usually available. Furthermore, it allows users to perform complex queries about these components and to use external information available in the Linked Data cloud to complement the information about them. Finally, information available in other Linked Data sources (such as DBPedia) can be integrated into queries to the repository of the automation platform, enabling the extension of the queries with data that are present in other systems. For example, DBPedia contains further information about the sensors integrated in the platform. This information can be obtained using the SPARQL Federated Query extension (available at: https://www.w3.org/TR/sparql11-federated-query/) (accessed on 17 September 2021), which enables the execution of queries distributed over different SPARQL endpoints. Listing 5 shows the SPARQL query for obtaining the DBPedia comments of the actuators existing in the platform.

Listing 5. SPARQL query for finding the DBPedia comments of the actuators of the platform.

SELECT ?sensor ?comment

WHERE {

?actuator rdf:type vlctas:ActuatorChannel ;

owl:sameAs ?dbpconcept .

SERVICE <http://dbpedia.org/sparql/> {

?dbpconcept rdf:type dbo:Device;

rdfs:comment ?comment

}

FILTER (lang(?comment) = ’en’)

}

In this way, SPARQL can be used to express queries across diverse data sources, allowing users in the platform to expand and complement their knowledge about the existing components with the information present in other data sources.

7. Discussion

This paper proposes a semantic model for a task automation platform that enables the adaptation of the environment in a smart office to the needs of the employees. The proposed model guarantees the interoperability and the scalability of all the components of the system, as well as the portability of automations. In addition, this paper contributes to the research on the use of VLC communication technology for developing intelligent systems, and proposes VLC as a communication system in the platform. The paper introduces a practical use case scenario in order to better understand the scope of the paper and to illustrate the progress made beyond the state of the art. Moreover, it presents an implementation of a VLC-enabled task automation platform, describing the different components involved. Finally, the semantic model proposed is evaluated with a set of meaningful queries.

The proposed platform architecture benefits from the advantages of semantic technologies and visible light communication to facilitate the continuous communication of all the heterogeneous data generated. Users of the platform can configure their own automation rules based on the ambient conditions to regulate these conditions and enhance comfort and productivity. With this aim, several sensors and actuators have been included in the proposed prototype for measuring and regulating different ambient conditions: air quality, temperature, luminosity, and noise.

Compared with other automation or intelligent systems [61,62,63], the provided platform presents some advantages. First, thanks to the semantic model, it enables a straightforward and common representation of all the components in the smart environment, along with their relationships. Apart from the enhancement in the interoperability and scalability of the system, it also enables access to linked data related to the components. This offers the users the possibility to access complementary information about the different elements of the platform. Moreover, the use of visible light communication alleviates the load of the RF spectrum. This prevents the electromagnetic interference of sensors with other devices of the environment, which may deteriorate the data rate and the reliability of the communication. Furthermore, the use of the existing LED lighting infrastructure simultaneously for illumination and data communication may entail a reduction in operating costs and carbon footprint [5]. Given the interoperability challenge that the integration of new communication technologies could entail, the use of semantic technologies is particularly useful for the system. In this way, the data exchanged between the sensors and the automation platform follow a model that facilitates continuous communication among the different components, and the system can benefit from the advantages of VLC without compromising its extensibility.

As future work, one possible line is the integration of methods for recognizing the personal parameters of the user, such as emotions or activities. This may enhance the environmental adaptation and may benefit from these technologies for regulating emotions. Moreover, the proposed system could be applied to different scenarios apart from smart offices. The high scalability offered by the developed system facilitates the extension of both the architecture and the developed tools to give a more solid solution to a broader range of scenarios. Another planned line of future work is the enhancement of the VLC system using a hybrid VLC–WiFi approach for communication with the sensors, in order to improve its reliability and robustness. In this way, WiFi could be used if the VLC link was interrupted, guaranteeing seamless reliable coverage. Finally, the data generated by the platform could be used for applying machine learning techniques. This would allow the system to learn from the users in order to be able to improve the adaptation of the environment, or even the recommendation of automation rules between users.