1. General Call Objectives
The FIESTA‐IoT Project herewith announces its first Open Call for Experimenters and Extensions, targeting advance and innovative developments in the Internet of Things over the Experimentation as a Service platform and the underlying IoT testbeds that supports the FIESTA‐ IoT Consortium.
Overall, the project’s experimental infrastructure will provide experimenters in the IoT domain with the following unique capabilities:
Access to and sharing of IoT datasets in a testbed‐agnostic way. FIESTA‐IoT will provide researchers with tools for accessing IoT data resources (including Linked sensor data sets) independently of their source IoT platform/testbed.
Execution of experiments across multiple IoT testbeds, based on a single API for submitting the experiment and a single set of credentials for the researcher.
More information on the scope of this first Open Call of the FIESTA‐IoT project can be found in section 4 of this document.
(Table not available please visit the public link of the call)
Requirements related to the proposer:
Proposers must be eligible for participation in the EC H2020 projects
Proposals will only be accepted from a single party.
For the experiments in the category ‘Innovation by SME’, only proposals from small and medium‐size enterprises, including unipersonal companies and individuals, will be accepted.
Language in which the proposal must be submitted: English
Proposals must follow the provided template (see section 6 of this document)
Proposals must be submitted through the online submission portal (accessible from http://fiesta‐iot.eu/opencall/
3. Background information on the FIESTA‐IoT project
In FIESTA‐IoT project we focus on the problem of formulating and managing IoT data from heterogeneous systems and environments and their entity resources (such as smart devices, sensors, actuators, etc.), this vision of integrating IoT platforms, testbeds and their associated silo applications within cloud infrastructures is related to several scientific challenges, such as the need to aggregate and ensure the interoperability of data streams stemming from different IoT platforms or testbeds, as well as the need to provide tools and techniques for building applications that horizontally integrate diverse IoT Solutions.
The main aim in the FIESTA‐IoT federation is to enable an experimentation‐as‐a‐service (EaaS) paradigm for IoT experiments. However, instead of deploying yet another physical IoT infrastructure, it will enable experimenters to use a single EaaS application program interface (API) for executing experiments over multiple existing IoT testbeds that are federated in a testbed agnostic way. Testbed agnostic implies the ability to expose a single testbed that virtualize the access to the underlying physical IoT testbeds. Experimenters will be therefore able to learn the EaaS API once, and accordingly use it to access data and Resources from any of the underlying testbeds.
To this end, the testbeds willing to participate in the federation will have to implement the common standardized semantics and interfaces that are being defined within the FIESTA‐IoT project. This will enable the FIESTA‐IoT meta‐platform to access their data, resources’ and services’ descriptions and other low‐level capabilities.
As can be seen in the figure below, the central component of the FIESTA‐IoT meta‐platform will be a directory service (so‐called FIESTA‐IoT meta‐directory), where resources from multiple testbeds will be registered. In the same way, the observations produced by them will be also stored. This directory will enable the dynamic discovery and use of resources (e.g., sensors, services, etc.) from all the interconnected testbeds.
The key concept behind the federation of IoT testbeds is the specification of a common testbed API that will comprise the interfaces to carry out the registration of the testbed resources as well as pushing the observations to the meta‐platform. Besides the actual technologies used for implementing these interfaces, the main feature that underlies the FIESTA‐IoT Testbed API is the fact that the information is exchanged in a semantically annotated format. In this sense, federated testbeds will have to implement their own semantic annotators, by means of the transformation of the information they handle internally to a common semantic ontology, defined by the FIESTA‐IoT meta‐platform. Different Resource Description Framework (RDF) representation formats (i.e., RDF/XML, JSON‐LD, Turtle, etc.) are supported as long as the common ontology is used.
A primary decision of the FIESTA‐IoT project was to take as reference the IoT ARM as defined in the IoT‐A project1. This choice has particularly resulted in the observation of the domain model and the information model defined in the ARM. The domain model identifies the key concepts that appears in an IoT environment and the relations between these concepts. The information model defines a meta‐model of how to structure information in IoT platforms.
The second main design decision is the use of semantic technologies to support the interoperability between heterogeneous IoT platforms and testbeds. The first step towards a testbed federation is the use of a common language and the definition of relationships between concepts. The taxonomies and ontologies makes it possible to seamlessly deal with data from different sources.
The foremost aspect that these choices have implied is that a FIESTA‐IoT ontology2 has been defined to rule the semantic annotation of the core concepts that compose the aforementioned Domain and Information Models. These core concepts are:
The resource: is a “computational element that gives access to information about or actuation capabilities on a physical entity”. In FIESTA‐IoT, this concept is realized through the Device Class and its SubClasses (SensingDevice, ActuatingDevice and TagDevice).
The virtual entity: is a “computational or data element representing a physical entity”.
These concepts conform the baseline for representing the devices and overall IoT infrastructure. However, there is still a major concept that is not tackled within the ARM models. This concept relates to the actual data that is gathered by the devices and offered through the services that expose them. Namely, it is the observation concept:
An observation is a piece of information obtained after a sensing method has been used to estimate or calculate a value of a property of an Entity. In FIESTA‐IoT data from a SensingDevice will be available through the Observations that it has produced.
Linked to this concept and its relation to the entity one through the property idea, another important aspect that has been also addressed during the construction of the FIESTA‐IoT ontology is the definition of a taxonomy that sets a common ground for the description of the physical phenomena and units of measurement captured in the observations.
It is important to emphasize that this ontology is the baseline for the interoperability of the heterogeneous testbeds and IoT platforms that are expected to be federated in the FIESTA‐IoT meta‐platform. The different testbeds have to converge for participating in the federation and they must use this ontology as the reference for this convergence.
3.1 Tools/services for experimenters
Experimenters will be enabled with a set of tools for the interaction with the aforementioned FIESTA‐IoT EaaS meta‐platform. This tools will comprise both EaaS REST APIs as well as a basic UI that experimenters can use to get familiar with the available services in a friendly manner. Experimenters can decide which of the two options best fit their experiment requirements and their technological skills. The main Use Cases that these tools will support are as follows:
Registration as experimenters. In order to keep track of the Authentication, Authorization and Accounting (AAA) of all the users who interact with the FIESTA‐IoT platform they must sign up before using the enablers that offers the FIESTA‐IoT core functionalities. This way, an individual user management can be achieved and the means to provide a secure access can be accomplished. Experimenters will receive individual credentials to guarantee their private access to the platform experimentation services.
Experiment registration. Beside the registration of the experimenter described in the previous point, each experiment is to be registered so as to: 1‐ bind the experiment with its actual owner, 2‐ facilitate the management, 3‐ permit the dissemination of the experiment with other users.
Discovery of resources. The first step an experiment most likely carry out is to search or browse among all the available assets deployed throughout the FIESTA‐IoT federation. Through this service, the platform will generate a list of all the resources that match the experiment requirements, where it can specify:
1. No filters: in this default case, where users do not showcase any kind of preference, the response will be a list with all the resources registered at the FIESTA‐IoT repository, with no exception.
Location‐based queries: Instead of gathering the whole list of assets that the platform can actually provide to users, experimenters could only focus on the ones that are deployed within a particular area (or areas).
Physical phenomena‐based queries: Another possibility is to indicate only the applicative domain (e.g. through the specification of the set of physical phenomena that matches the context of the experiment). This way, experimenters will filter out all those resource that are not of their interest.
Testbed‐Agnostic query of datasets and data‐streams. Apart from fetching the very last observations captured by FIESTA‐IoT’s underlying resources, experimenters might want to opt for the analysis of data already captured and stored within the FIESTA‐IoT distributed repositories. In order to facilitate the harvesting of this historical information, a service will be available so that experimenters could specify a temporal window within which the observed measurements will be returned back to them.
As it has been described, FIESTA‐IoT EaaS meta‐platform uses semantic technologies to enable testbeds interoperability so that experimenters can have access to the datasets and data‐streams generated by any of the underlying testbeds in a testbed‐agnostic manner.
While some of the tools will intentionally hide the complexity introduced by the use of semantic technologies, others will enable the experimenter to exploit the potentials of semantic and linked data (e.g. use of SPARQL, access to RDF‐annotated information, etc.).
3.2 Testbed Provider Interface
The TPI (Testbed Provider Interface) is a set of RESTful web services that enables the integration of the testbeds to the FIESTA‐IoT meta‐platform. The TPI is spanning across two different layers as it is shown in the figure below. The first is the TPI Configuration & Management layer that runs at the FIESTA‐IoT platform side and controls the functionality of the TPI. A dedicated Graphical User Interface (GUI) will be available for Testbed Providers to operate the way they want their testbeds (and more specifically the resources – sensing devices – that are part of them) to behave. The second is the Testbed Provider Services (TPS) API where the Testbed Provider has to implement a list of predefined services that enables the management and manipulation of the offered data.
As it can be seen in the figure above a testbed may expose internally various standard or proprietary interfaces in order to interact with the sensor data. FIESTA‐IoT has specified a list of core services that should be exposed from a testbed in order to enable different connection methods to the platform. These services (i.e. getObservations and pushObservations), so‐called TPS, are one of the critical aspects for the underlying testbeds to be federated, and should be exposed from the testbed. The behaviour of these methods will be controlled from the FIESTA‐IoT platform. However, the Testbed Providers will be given with a GUI to control the TPS services that their testbeds exposes. This control will basically consist on either identifying a specific schedule, if the testbed works in a reactive manner (i.e. testbed only offers data if requested), or by enabling a data‐stream connection, if the testbed works in a proactive manner (i.e. testbed sends data without a specific request).
Below we can find a high level description of the list of TPS Services that needs to be implemented from the testbed provider:
getLastObservations: This service provides the latest values of a specific Sensor list.
getObservations: This service provides the values of a specific Sensor list for a specific
pushLastObservations: This service pushes continuously the latest values of a specific Sensor list to a specific endpoint.
In order to be able to initiate this configuration and set up process the Testbed Provider needs first to register all their resources (i.e. IoT devices). This is done by utilizing the services that are
exposed from the FIESTA‐IoT meta‐platform, more specifically the Semantic Resource Directory (SRD) – cf. Figure 1 – management services.
The last mandatory requirement to be observed by the Testbed Provider Interface is that, as previously mentioned, FIESTA‐IoT platform is designed to enable interoperability through semantic technologies. In this sense, any piece of information generated by the testbeds, whether sensor observations or resource descriptions must be semantically annotated using the FIESTA‐IoT ontology and taxonomies before it can be stored in the meta‐platform Directories. The annotation process, this is, the transformation from the testbed native format and vocabularies, to the FIESTA‐IoT semantic format and taxonomies must be handled by the Testbed Provider. In order to ease this process, the FIESTA‐IoT meta‐platform will offer both annotation services for those Testbed Providers that do not feel comfortable with RDF and semantics as well as validation services for those that prefer to handle themselves the annotation process.
In Annex D an end‐to‐end example for the sequence of the different interactions of a testbed with the FIESTA‐IoT platform is depicted for better understanding of the technical implications for the Testbed Provider to participate in the testbeds federation offered by FIESTA‐IoT.
3.3 Available testbeds descriptions
The FIESTA‐IoT project offers access to several IoT testbeds, such as SmartSantander (University of Cantabria), Smart ICS (University of Surrey), Comm4Innov and KETI. All of these testbeds are installed in either outdoor or indoor environments ranging four different domains (i.e. Smart City, Smart Campus, Cellular Networks and Smart Office). A summarized description of each of them follows:
The SmartSantander testbed is located in Santander, a seaside town settled in the north of Spain. With a population of nearly 200,000 inhabitants, this city was chosen to deploy an experimental test facility (i.e. open laboratory) for the research and experimentation of big‐scale architectures, in the context of a Smart City environment. Amongst its assets, the platform spans a number of domains that will be made available for the experimenters under the scope of the FIESTA‐IoT’s Experiment as a Service (EaaS) interface. Numerically speaking, the SmartSantander testbed manages around 3,000 IoT devices (which communicate through IEEE 802.15.4 interfaces), another 200 devices that play the role of gateways (with cellular communication capabilities) that establish a link between the abovementioned devices and the core of the platform, 2,000+ joint Radio Frequency Identification (RFID) tags/Quick Response (QR) code labels and more than 2,000 points of interest pertaining to a wide range of events (e.g. shopping, restaurants, cultural events, etc.). Table below summarizes the principal domains supported by the SmartSantander platform that will be available in the scope of the FIESTA‐IoT federation. Besides, the table also describes the main assets associated to each of these domains, as well as the number of resources available in each of the cases.
(TRUNCATED - please visit the public link for the full text)