1. General Call Objectives
The FIESTA-IoT Project herewith announces its second Open Call for 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 testbed providers in the IoT domain with the following unique features:
• 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.
• Boost the sharing, reuse and repurposing of IoT facilities at an EU and global scale. FIESTA-IoT will showcase and validate this concept in the scope of enterprise applications/experiments, smart city applications/experiments and more.
• A global market confidence programme for extending the pool of interoperable facilities and testbeds that will comply with the project interoperability model.
More information on the scope of this second Open Call of the FIESTA-IoT project can be found in section 4 of this document.
2. Call Information Project full name:
FIESTA-IoT - Federated Interoperable Semantic IoT/cloud Testbeds and Applications
Project grant agreement number:
Second FIESTA-IoT Open Call for Experiments
15th February 2017, at 17:00 Brussels local time
Category / Identifier : FIESTA-IoTOC2‐EXT
Call budget : € 150 000
Max. budget per exp. or ext. : € 50 000
Minimum no. of exp./ext. to be funded : 3
Total funding of this call
€ 150 000
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.
• A proposer can only be selected for funding for one proposal (even if the proposer submitted multiple proposals that are ranked high enough to be selected for funding, or if the proposer submitted multiple proposals in different categories).
• Parties having been selected in previous FIESTA-IoT Open Calls are not eligible to participate again.
• The FIESTA-IoT project especially welcomes and stimulates the participation of new players in the FIRE community.
• 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”.
• The IoT Service: is a “software component enabling interaction with resources through a well-defined interface. It can be orchestrated together with non-IoT services (e.g., enterprise services). Interaction with the service is done via the network”.
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.1Tools/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.
2. 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).
3. 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.
(-- TRUNCATED -- full proposal in the official link of the call)