Water management is a key scenario for the deployment of IoT systems because of the particularities that arise depending on the geographical region as well as its inherent weather conditions. This scenario offers different and challenging problems to the deployment of IoT based applications and services which must rely on a rich technological vocabulary able to represent such characteristics and particularities. This is the reason why ontologies are the medium to achieve this goal. In this paper, we review the most well-known related ontologies as well as propose a model called MEGA promoted at state level with the objective of not only representing the information, but also integrating all the elements of an irrigation system, specially water distribution networks under interoperable platforms or systems.1
• CCS → Information systems → Data systems → Information integration management © 2017 Copyright held by the author/owners. SEMANTiCS 2017 workshops proceedings: SIS-IoT September 11-14, 2017, Amsterdam, Netherlands 1
Nowadays water resources management scenarios benefit from innovative techniques that support the seamless integration by upgrading the necessary components and methodologies with more technological and flexible systems. Water systems have a great background of state-of-the-art management systems that take advantage of the newest developments in the Internet of Things (IoT) field. By incorporating intelligent devices, water management can be controlled and managed by a common entity that enables new capabilities and goals than in a traditional way. This ends with a better resource exploitation and ultimately in essential resources preservation.
Currently, water resources management is mainly confined to the water reserve supervision and provisioning, and this is clearly making use of the current existing technologies. But, what can be expected when this boundary ispassed beyond? The answer is a totally lack of a multi-disciplinary and standardized methodology when more than one area of interest is involved.
In this work, we study other rural management fields in addition to the water management environment, as currently, any combination made is getting more important with the relevant ecological awareness that the green economy directives dictate. The need of a seamless integration between these several concepts in a technological system is a key factor to develop an interoperable and linked managed environment.
To achieve this, existing ontologies try to combine themselves with deprecated methods that are not taking any advantage of current state of the art, but in this research paper we are studying the problematics, requirements and possible solutions to enable more advanced methodologies that will allow several improvements on a rural management domain.
The rest of the paper is as follows: Section 2 introduces the water related management scenario used to test and deploy the development, Section 3 analyses the state of the art of the relevant areas that this paper covers, Section 4 states the standardization process proposed in this work and Section 5 describes ongoing work and conclusions. 2
Spanish south-eastern has an arid or semi-arid climate according to the climatic classification of the United Nations Environment Program (UNEP), which is mainly defined by high temperatures from May to September, with lower or null rainfall, and slightly lower although moderate temperatures from October to April with some more rainfall. Both characteristics, the lower and irregularity of rainfall coupled with the higher evaporative rate, are the limiting factors for the agricultural development. In this situation, the irrigation plays an important role in the production system, and therefore the efficient use of water must be an essential requirement.
The agricultural sector is in continuous evolution in which IoT technologies must be adopted to manage all the objects which are located on the farm under a single system. These technologies will improve the crop productivity through the management and water control and by optimizing the energy consumption. As a use scenario, a community of irrigators could be selected due to the fact is the organism where the farmers are grouped with the purpose to self-manage to distribute the water of irrigation of an effective and equitable way among its members.
To combat the water management problematics here in Spain,
a new platform endorsed by the Spanish government is being
developed within the agriculture sector to provide a new and
novel mechanism for water resources management: MEGA [
For the last years, development in MEGA has been focused on
establish a reliable communication between the different actors
involved into the development management [
Currently, web services are the main communication mechanism for controlling processes in the MEGA infrastructure. As MEGA introduces a new concept called “virtual entities” (composition of several hydraulic entities that reside in one or several subsystems) in addition to the logical devices found in the system, a web service defined between the interfaces drives the complex compound of the involved devices. The selection of this technology helped in the deployment of this new system into the existing devices, but once a successful integration has been done, new requirements has been observed. The lack of a standardized vocabulary that allows a more in-depth relationship definition along with their properties decrease the future growth of the developed system. As presented in Figure 1, interfaces driven by the web services mechanism (primarily SOAP) are in charge of relaying information between different layers. This communication is made without any vocabulary nor correlation between the implied subsystems.
Thanks to this real deployment, several needs have been observed with this development and deployment. In addition, a set of requisites have been identified to be satisfied with the inclusion of a global ontology vocabulary. 2.1
To achieve a successful deployment and integration of a novel platform, we use the expertise acquired in the previous development to create a set of requirements in order to collect all the needs that a final management system require in a real world situation. We use the scenario described in the section 2 in the requirements definition process.
Following, along with each requirement, a short description is provided in order to clarify and establish the future needs of the standard.
REQ #1: Unique device identification: In a management system, a reliable identification of the final device is a key requisite that allow to control and communicate system wide and provide singularity to precise events. As in our case scenario the devices or entities can be virtual, the process of creating and assuring a unique identification is critical for a successfully implementation. The devices will be identified by means of an identifier as used by Open Geospatial Consortium (OGC).
environments like water management scenarios, some entities by themselves are not capable of performing any substantial process nor even smart enough to be able to communicate with other elements. In this case, aggrupation is made to encompass one or more entities in one device that can be recognized by the management system. This grouping can be done recursively, as the devices can be part of a superior level device that is in charge of their dependent operations. Thus, a device can be composed by a single entity or a group of entities, in a recursive way.
REQ #3: Group characterization: To give a proper computing capacity to a device, a characterization of the properties and capabilities offered by the component is required to allocate the correct resources.
Characterization implies that a list of predefined capabilities must be assigned before and thus, a configuration process has to be carried out. Once the system is initialized, the management and exploitation layer is able to build an available resources schema with all the gathered information.
will be deployed on land, communication between different subsystems is mandatory. To provide interoperability, the communication among same layer devices and inter layer are used.
entails, measurements of certain aspects are required to analyze the performance and reliability of the system. The system must be able to collect metrics and provide interfaces to interact seamlessly for KPI generation and report.
REQ #6: Request optimization: In a multi-layer system, interlayer requests have to be optimized to reduce any unnecessary overhead. In this sense, a valid request can be addressed to a certain device whose upper layer know in advance its inability to process the request, so this request has to be redirected or cancelled at this layer, avoiding excessive requests.
systems, a water management environment requires acting capabilities over some devices. In this case, the developed system must be able to command actuators and last verify the correct state of the device.
REQ #8: Security and privacy: Every modern management system has to take into account the security implication as a cross layer that involve every component of the system. As the system is composed of several subsystems, each one must have its own security measures in addition to the global layer that cover the whole system. In this work, security is omitted as the authors relay the security mechanism to the selected framework and protocols. Even, the semantic addition does not modify the security implications of the platform.
In Figure 2, a representation of a generic device is shown, providing the requisites defined previously.
Many IoT available related research reviewes the current state
of the art in the domain of the IoT ontologies. Additionally, there
are many ontologies that have been available specifically for IoT
sensors and other related areas. In this section we analyze some of
these IoT related ontologies, and several ongoing integration
works for defining unified ontologies that are intended for
covering different applications domains. In the following
subsections, we provide detail of the most relevant ones. The
objective of this work is similar to that published by K.W.
Chau[
LOV4IoT
To provide a fundamental basis on the existing ontologies, a
project called Linked Open Vocabularies for Internet of Things
(LOV4IoT) was created [
The main issue arising from the LOV4IoT is: the lack of projects for water domain and the lack of an interoperability standard to avoid reuse many domains of knowledge. Instead, it may be worthwhile to integrate in a unique ontology all the information present in every similar domain category and in this case, LOV4IoT data can be of a great help to identify information duplicated in similar ontologies to unify them with more integrated and interoperable procedures. 3.2
In order to discern which ontologies are the best candidates to our management system, a more detailed analysis of the Internet of Things related ontologies is made in order to extract the necessary information about this specific domain. This will be the selected expertise area to use in our water management deployment.
In the literature, several related ontologies have been analyzed. In this section we have selected the most known ones as they comply with our interoperability goal in the water ecosystem domain:
The W3C forum has defined a Semantic Sensor Networks
(SSN) [
In that sense, SSN is primarily focus on offering great
interoperability of the capabilities offered by the devices in order
to facilitate the later addition and auto-discoverability of the
sensor devices [
So, to deal with the lack of this information, some observation concepts were included to allow link external ontologies and building a complex hierarchical ontology based on observation properties.
Different studies based on sensor ontologies compared the following aspects: • Purpose of the ontology • Status of the ontology: online, documentation, maintained, etc.
• Key concepts found in the ontology • Adoption of the ontology • Level of sophistication • Weakest features
As conclusion, they state that the W3C SSN is a great combination of the most important sensor ontologies at that time. It defines the key aspects of sensor representation and includes high-level concepts for the critical observation and representation within the sensor environment.
The IoT-Lite [
IoT-Lite describes the concepts of IoT in three main classes: objects, system or resources and services. IoT-Lite focuses on detection, although it has a high level of performance concept which allows any future extension in this area, this would be a weakness of the ontology.
Fiesta-IoT [9] was born with the aim of promoting semantic interoperability because not all ontologies provide it. Fista-IoT reuses the results of previous and current EU projects in the use of semantic web technologies such as OpenIoT, Citypulse, VITAL, Spitfire, IoT-est, IoT-A, IoT6, iCore, Sensei, etc.
The main objective can be summarized as the establishment of a new infrastructure for global experimentation, where concepts such as virtualization, federation and interoperability (semantics) play a fundamental role in IoT platforms (Internet of Things) of the future.
Fiesta-IoT addresses the issues of semantic interoperability at seven levels: • Hardware level, provides middleware based on semantics (eg OpenIoT) to handle heterogeneous hardware devices. • Data level, unifies data produced by devices from different cities and projects using the semantically data. • Model level, aligns existing IoT ontologies to ensure better interoperability. • Level of consultation, queries of unified knowledge bases (ontologies and set of data). • Level of reasoning, unifies how to derive meaningful information from the data sensor to avoid redundancy of the "if not then" constant rules redesigned in all IoT applications. • Service / application level, brings the innovative idea of "Experimentation-as-a-Service (EaaS)" of Cloud Computing. EaaS is built on top of "Linked Open Services" based on the Linked Data approach that currently extends to IoT domain. • Application domain level, build applications between domains / vertical applications to interconnect and reuse / specific horizontal applications of the current domain (eg, smart home). The use of FIESTA-IoT can be applied to all IoT projects, with these benefits: reusing domain knowledge, reusing existing ontologies and designing inteoperable applications
The Sensor, Observation, Sample and Actuator (SOSA) 2 ontology is considered a second version of SSN. SOSA provides a lightweight core for SSN and aims to expand the target audience and the application areas that can make use of the ontologies of the Semantic Web. At the same time, SOSA acts as a minimum level of interoperability, i.e. it defines those common classes and properties for which data can be exchanged with security between all SSN applications, their modules and SOSA.
Two of the new entities provided by SOSA are: - Actuator: device that is used by, or implements, a procedure that changes the state of an object. - Actuation: is the action that is performed to change the state of an object using an actuator.
SOSA extends the original scope of SSN beyond sensors and their observations, including classes and properties for actuators and sampling.
Other projects or ontologies that can serve as reference to this work are:
IoT-O ontology: It's another ontology [
Water-m project: the aim is finding solutions to the
interoperability, real-time, big data and heterogeneous data
challenges to being able to guarantee water supply and quality
along with the stability and reliability of a smart water network
[
Due to the lack of interoperability between the different
sensors, the Open Geospatial Consortium (OGC) [
One fact to consider should be the use of a data model (set of rules which control the transfer from the real world to the computer systems) which must be open and configurable enough to ensure its adoption is not an abrupt process and thus it will be able to promote better forms and more consistent to publish and to access data of common interest.
In any adopted solution, it is necessary to use a data model with spatial component, that allows us to share the information in a regulated framework. Although, this entails the migration of the model used to another one. 2 https://www.w3.org/2015/spatial/wiki/SOSA_Ontology
OGC has been working on data models since 1995, one of its
first documents was a Spatial Scheme that in its essence was a
global data model. SWE offers a common data encoding that is
used throughout the suite of OGC standards. Moreover, SWE
Common Data Model [
As for data models, organizations that need a web-based
platform to manage, store, share and analyse data from sensor
observations can use the SensorThings API [
It provides an open, unified framework for interconnecting IoT devices, data and applications through the Internet. The SensorThings API is designed to transform the several disconnected IoTs on a fully-connected platform where complex tasks can be synchronized and performed.
As a standardized data model, the SensorThings API offers the following benefits: 1. It allows the development of new high value services with lower development cost and of a wider scope. 2. Lower risks, time and costs through a complete IoT product cycle. 3. Simplify device-to-device and device-to-application applications.
The data model is composed of two distinct parts. A sensing profile that allows devices and their applications: create, read, modify and erase data in a SensorThings service. And another (tasking profile) that allows applications to control the devices through a service. 3.4
FI-Ware is an open-source European initiative that aims at creating the necessary standards to develop applications in a wide spectrum of smart domains such as smart cities and smart agriculture. FI-Ware wants to develop a standard to describe how to collect, manage and distribute the essential context information that enables its exploitation and finally a business model. This standard is key to build intelligent applications capable of provide a one unique digital market for smart applications where solutions could be ported seamlessly from one customer to another.
The FI-Ware platform provides cloud capabilities based on the OpenStack framework with a set of value tools and libraries called Generic Enablers (GEs). These GEs offer open interfaces that ease task such as integrating IoT deployments and infrastructures by allowing the data management and processing with common and reusable modules.
The specifications and APIs of the GEs are public and royalty free with open source code available of each implementation. This allows FI-Ware vendors to emerge on the market, sharing APIs, and therefore building extensible applications that can be selected between several vendors hosting to store the solution and process the data.
As FI-Ware is conceived as a cloud computing platform, it is aimed at providing Smart solutions for different scopes like: Smart cities, Smart ports, Smart logistics, Smart irrigation systems and the likes. Additionally, and unlike other private solutions, FIWare provides an open and free architecture along with a set of specifications that allow developers of service providers and any other company or organization to develop products promoting the creation of a marketplace to offer innovative solutions.
Usually, smart solutions are characterized by a three-step process: gathering information of interest from heterogeneous sources of information, storing the information into a repository of information, and its processing in order to generate the knowledge for the solutions. In addition, a fourth step could take place if actuation over certain elements is required.
FI-Ware is making a great effort at both first steps by
implementing the NGSI standard [
In this sense, FI-Ware has proposed the following categorization: Alarms, parks and gardens, environment, point of interest, street lighting, civic Issue tracking, IoT Device transportation, indicators, waste management, parking and weather.
This way, by using this representation, as well as the NGSI interface, all the information related to the above areas will be represented the same way promoting and encouraging the interoperability and data exchange. 3.5
It is clear that the large amount of IoT related ontologies only increases the difficulty of selecting a unique candidate to resolve all the vocabulary requirements that an organization or a system need. With this in mind, it is evident the need of creation a standardized method to embrace all the vocabulary entities of a precise environment. OCG models offers the necessary interoperability and the FI-Ware establishes the formal specification of an open and reusable module.
In the next Sections, a first phase is described and a formal development is defined within the region of Spain. 4
As previously mentioned, Spanish government and more specifically Tragsa3, is endorsing a new model called MEGA to overcome the problematics and to find new techniques of water management and optimization in Spain, but with a view of future 3 Tragsa is part of the group of companies of the State Industrial Ownership Corporation (SEPI) incorporation in European regions. With this approximation, Spain regions can test and incorporate new technological ways to power the water management industry.
MEGA architecture is described in Figure 3. The proposed high-level model identifies three layers (from right to left): the
and Exploitation layer. These layers deal with a common Water Management Model that is built based on two key elements: the Physical Model, which includes the component model, and the Process Model. The water management model is the key element for enabling MEGA to provide a common behavior framework. Between the Subsystem layer and the Coordination layer there is a Coordination interface and between the Coordination and the Management and exploitation layer there is a Common
The integration of IoT into the water management system could prove to be very beneficial for both information and communication technologies (ICT) areas and their business. In the rest of this section we analyse how IoT and Smart Environments are defined, their key characteristics to understand how they can be used in the definition of the reference model for Smart Water Management, taking advantage of the new advances in ICT technologies, for creating feasible and commercial systems. 4.1
MEGA is based on a top-down model that tries to solve the basic problems of a water management system by separating it in several layers of control. This deployment is abstracted by the physical model to enable the interaction of the control model. Besides, it allows an industrial management layer to define processes such as run water procedures and water supervision that are executed in the physical layer.
Physical entities, that can be unified in virtual entities by the coordination layer, are in charge of providing the interfaces and to verify the correct execution of the created recipes. In addition, this layer generates additional information that relayed in a synchronous or asynchronous way help to inform the status and process of the system. All of this implies that defined processes are externalized in the management layer that integrates and monitors the diverse information such as meteorological information, energy consumption, costs, etc. and allowing the development of a more complex recipe (irrigation programs) parameterised by this additional information.
As more information is gathered, the system approaches a more data centred system and recedes from original model. This is close to the IoT model as the devices, communications and processed are similar to the concepts in the IoT environment. The use of an IoT ontology to match the MEGA model is a reasonable arrangement to achieve a more modern water management system.
One of the basic characteristics for the design of a new ontology is the reuse of existing ones. One of the future works could be to define a semantic layer for the MEGA project partially using other ontologies.
At first glance, it can be considered that there is a subset of MEGA elements that can be modelled with FIESTA-IoT, the rest of entities that cannot be modelled with FIESTA will try to perform with other ontologies available in the market as SOSA. One of the fundamental concepts to be added to the ontology should be the management of the irrigation programs (Recipe of the MEGA model) that can be mapped with the classes: sosa:Actuation and sosa:Actuator.
The work hypothesis would be to start with the interface between the coordinator and the subsystems. One of the first steps will be to match the classes defined in FIESTA-IoT with those defined in the MEGA data model. 5
Integration works are in process of achieving a FI-Ware compatible platform that enables their interoperability abilities along with the previously MEGA development. In order to summarize the relationships between the MEGA model and the FI-Ware structure, Figure 4 resumes the interactions of the existing MEGA project with the FI-Ware components.
Following a top down approach, we establish FI-Ware business framework as the management component to provide the business intelligence layer at the upper level. Service application level is driven by normalized applications developed taking advantage of the NGSI interface provided by FI-Ware, as well as the different enablers existent in this platform. This interface guarantees the interoperability with other platforms and systems thanks to the NGSI standard interface adoption. This way, MEGA, as any other third party platforms can be integrated by using directly the NGSI interface, or by using the Generic Enablers already developed for the purpose, or developing an own adapter for such a task. Such interoperability guarantees the correct and uniform exchange of information and even the actuation over the deployed sensors devices.
The purpose of MEGA is to allow interoperability between the different elements of an irrigation system improving the waterenergy savings and smart farm production. In order to guarantee the interoperability and the exchange of standardized information, MEGA will be linked to different IoT ontologies defining possible actions that apply to each system element, both in the physical model and in the procedural model.
At the same time, efforts are put on establishing a better adaptation with the studied ontologies that allow an adequate interoperability between different managed systems in Spain and Europe. An example of this is a first approximation of the main concepts of the MEGA model with the classes of the ontologies, which is presented in the Table 1.
To conclude, MEGA project can be expanded as the experts incorporates new additional extensions to the original profiles. By combining several datasets in a centralized infrastructure, a global and interoperable managed system can be deployed and it will be capable of establish the implementations between structures developed for management and control of irrigation facilities. In this way, the standard can be applied under any technological platform in any type of irrigation system, regardless of the water management scheme (public or private, individual or collective).
This work was partially supported with the financial support of the research project FEDER 14-20-15 (Design and implementation of spatial data infrastructure on agriculture and water in the Murcia Region - IDEaRM), 80% co-funded by the European Regional Development Fund (ERDF). “A way to build Europe” and the financial support of the research Project INTERNET OF THINGS @ AGRO SPACES Programa FEDER INNTERCONECTA (EXP 00091605 / ITC-2016-20-45) and by the Ministry of Economy and Competitiveness through SEMOLA project (TEC2015-68284-R) and through the TORRES QUEVEDO Project granted to Odin Solutions S.L. with the reference PTQ-15-08073 .
Sensor / Platform Not considered Procedure Not considered Actuation ActuableProperty
Device / System