| ... | ... | @@ -18,17 +18,17 @@ Organization of the project work packages and consortium can be seen [here](http |
|
|
|
|
|
|
|
# Project outcomes and KERs
|
|
|
|
|
|
|
|
Here we list projects key exploitable results (KER) and outcomes that can be used by the wider public. Each KER has its own sub-section including figures, short introductory text and links towards detailed technical documentation, guidelines and software artefacts. The listed KERs are available for 3rd part integrators as complete set of enablers for joining te existing or building the new semantically interoperable ecosystems.
|
|
|
|
Here we list projects key exploitable results (KER) and outcomes that can be used by the wider public. Each KER has its own sub-section including figures, short introductory text and links towards detailed technical documentation, guidelines and software artefacts. The listed KERs are available for 3rd part integrators as complete set of enablers for joining the existing or building the new semantically interoperable ecosystems.
|
|
|
|
|
|
|
|
## InterConnect Ontology
|
|
|
|
|
|
|
|
The starting point is the ETSI SAREF or Smart Appliance Reference ontology with its distributions for energy and buildings.
|
|
|
|
|
|
|
|
The project extends this ontology family with concepts specific to the cross-domain semantic interoperability requirements of the project.
|
|
|
|
The project extends this ontology family with concepts specific to the cross-domain semantic interoperability requirements of the project.
|
|
|
|
|
|
|
|
So we have extensions for representing the user information and profiles, Device and sensor information and profiles, forecast and flexibility information which are very important in the scope of the project and finally connection information.
|
|
|
|
|
|
|
|
The project also uses other available ontologies for measurements, time representation and geo locations.
|
|
|
|
The project also uses other available ontologies for measurements, time representation and geo locations.
|
|
|
|
|
|
|
|
|
|
|
|
|
| ... | ... | @@ -36,11 +36,11 @@ The project also uses other available ontologies for measurements, time represen |
|
|
|
|
|
|
|
## InterConnect Interoperability Framework
|
|
|
|
|
|
|
|
The InterConnect delivers an Interoperability Framework capable of bridging the integration gaps “within” and “between” the IoT and the energy domains.
|
|
|
|
The InterConnect delivers an Interoperability Framework capable of bridging the integration gaps “within” and “between” the IoT and the energy domains.
|
|
|
|
|
|
|
|
The Interoperability Framework comprises:
|
|
|
|
|
|
|
|
* **Semantic interoperability layer** (using InterConnect ontology over SAREF) based on distributed enablers interconnecting all resources, platforms and services and enabling them to exchange data and instructions in a uniform and secure manner while relying on widely adopted interfacing technology (RESTful). Exchanged data is not stored or processed anywhere in between communicating parties.
|
|
|
|
* **Semantic interoperability layer** (using InterConnect ontology over SAREF) based on distributed enablers interconnecting all resources, platforms and services and enabling them to exchange data and instructions in a uniform and secure manner while relying on widely adopted interfacing technology (RESTful). Exchanged data is not stored or processed anywhere in between communicating parties.
|
|
|
|
* **Service Store** a catalogue of all interoperable services, including knowledge exploring capabilities, service testing sandbox and automated interoperability compliance tests, streamline onboarding of 3rd parties’ services and systems to become part of the InterConnect ecosystem ensuring growth of the interoperable ecosystems and creation of new ones.
|
|
|
|
* **DLT based P2P marketplace enablers** allowing community-based energy and data trading use cases to be implemented in a way interoperable with project’s ecosystem.
|
|
|
|
* Configurable **access control and knowledge handling procedures** so that stakeholders can maintain business logic behind their services.
|
| ... | ... | @@ -58,6 +58,10 @@ _Levels of interoperability provided by the Interoperability Framework:_ |
|
|
|
|
|
|
|
### Service Store
|
|
|
|
|
|
|
|
<span dir="">As one of the main IC Interoperability Framework tools, the IC service store will provide a single stop for all providers and adopters of interoperable services from energy and non-energy domains. The service store is conceptualized as a web service with its front-end and back-end modules and processes. The main objective is to enable building of the InterConnect ecosystem of service providers and adopters by allowing them to register new interoperable services and browse existing ones to identify services best suited for the challenge at hand and get all necessary information for accessing and properly utilizing selected services.</span>
|
|
|
|
|
|
|
|
[Service Store web application](https://store.interconnectproject.eu/ServiceStore/#/auth/login?returnUrl=%2Fdashboard%2Fhome)
|
|
|
|
|
|
|
|
[Service store backend source code](https://gitlab.inesctec.pt/interconnect-public/service-store-backend)
|
|
|
|
|
|
|
|
[Service store frontend source code](https://gitlab.inesctec.pt/interconnect-public/service-store-frontend)
|
| ... | ... | @@ -66,10 +70,65 @@ _Levels of interoperability provided by the Interoperability Framework:_ |
|
|
|
|
|
|
|
### Semantic Interoperability Layer - Knowledge Engine
|
|
|
|
|
|
|
|
[Knowledge Engine source code](https://gitlab.inesctec.pt/interconnect-public/knowledge-engine)
|
|
|
|
<span dir="">The Semantic Interoperability Layer (SIL) is the main component of the InterConnect Interoperability Framework. It is implemented as a distributed middleware responsible for facilitating secure and trusted semantic and syntactic interoperability between digital systems.</span>
|
|
|
|
|
|
|
|
<span dir="">Central to the design of the Knowledge Engine is the concept of a **Knowledge Base (KB)**. A KB is a logical unit where knowledge flows to and/or from. These KBs can be anything like apps, services or existing databases and their nature depends on the use case that is being implemented. Also, the size of a KB is flexible, it can represent a single device or a whole platform with multiple devices and services.</span>
|
|
|
|
|
|
|
|
<span dir="">Each KB instantiates a **Smart Connector (SC)** which allows it to register its capabilities and exchange data with other KBs connected to the **Knowledge Network (KN)**. The SC is the generic software component that does all the heavy lifting within the Knowledge Engine. Each SC registers itself in a **Knowledge Directory (KD)** with a description of the capabilities that it wants to make available to other SCs. These KB capabilities supported by the SC are called **Knowledge Interactions (KI)**. Each KI is a capability description of the KB and each KB has one or more KIs. There are four types of KIs: **Ask, Answer, Post and React**. Both the Ask/Answer and Post/React are opposites of each other where the Post and Ask Knowledge Interactions represent the capability of the KB proactively posting or asking data to/from the KN. While the React and Answer KIs represent the capability of the KB reactively reacting to or answering a question from a Post or Ask, respectively.</span>
|
|
|
|
|
|
|
|
<span dir="">A KI also contains one or two **graph patterns** (depending on its type) that uses the terminology from a common ontology to describe the actual type of data that the KB produces or consumes. The Ask and Answer KI expects a single graph pattern, while the Post and React require a single argument graph pattern, but optionally allow a result graph pattern as well. These graph patterns use a subset of the </span>[<span dir="">SPARQL syntax</span>](https://www.w3.org/TR/rdf-sparql-query/#BasicGraphPatterns)<span dir=""> and an example looks like this:</span>
|
|
|
|
|
|
|
|
<span dir="">_?mm rdf:type saref:Measurement ._</span>
|
|
|
|
|
|
|
|
<span dir="">_?mm ex:hasValueInCelcius ?v ._</span>
|
|
|
|
|
|
|
|
<span dir="">This graph pattern could be used in combination with the Post KI for a sensor KB that regularly publishes measurements of the temperature in degrees Celsius. These types of KIs together with the graph patterns cover most data exchange scenarios necessary for realizing the InterConnect pilots. After a KB has register its capabilities using KIs, the data exchange starts depending on their types.</span>
|
|
|
|
|
|
|
|
* <span dir="">In case of an **Ask KI**, the KB is expected to proactive trigger the Smart Connector to ask the registered question optionally providing bindings for the variables in its graph pattern. Any KB that can answer such questions will be involved by the SC.</span>
|
|
|
|
* <span dir="">In case of an **Answer KI**, the KB will be contacted by its SC whenever another KB asks the type of data it can provide.</span>
|
|
|
|
* <span dir="">In case of a **Post KI**, the KB can post data to its SC whenever it sees fit. Any KB with compatible KIs will get a chance to react to the publication of data.</span>
|
|
|
|
* <span dir="">In case of a **React KI**, the KB will be contacted by its SC whenever another KB posts data to which it wants to react.</span>
|
|
|
|
|
|
|
|
<span dir="">In short, a SC of KB A will involve any other KB B that has compatible capabilities with any of the capabilities of KB A. In the front of semantic reasoning the Knowledge Engine supports two approaches for checking KI compatibility and executing knowledge discovery and exchange:</span>
|
|
|
|
|
|
|
|
* **<span dir="">Graph pattern matcher</span>**<span dir=""> – this is approach where KIs will execute knowledge exchange only if the graph patterns completely match. This approach ensures high speed knowledge exchanges.</span>
|
|
|
|
* **<span dir="">Semantic reasoner</span>**<span dir=""> – this approach will ensure knowledge exchange through KIs with graph patterns that do not necessarily match completely. Partial matching is enabled and with it, new knowledge inference is possible in a wide Knowledge Network. The semantic reasoner is slower than the matcher, but it provides more flexibility in defining graph patterns for KBs.</span>
|
|
|
|
|
|
|
|
<span dir="">The Knowledge Engine Runtime comprises a set of Smart Connectors and internal interfaces needed for facilitating KIs between KBs. This KE Runtime can be deployed on different system levels: on level of single service runtime, on a level of one digital platform, shared among multiple services and digital platforms (e.g. on a pilot level) and on a global/project level. This flexibility in deploying KE Runtime constitutes the distributed nature of the Interoperability Framework. </span>
|
|
|
|
|
|
|
|
_Knowledge Engine as a distributed knowledge network:_
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Knowledge Engine Documentation](https://gitlab.inesctec.pt/interconnect-public/knowledge-engine/-/tree/main/docs)
|
|
|
|
|
|
|
|
[Knowledge Engine OpenAPI specification of developer REST API](https://gitlab.inesctec.pt/interconnect-public/knowledge-engine/-/blob/main/openapi-sc.yaml)
|
|
|
|
|
|
|
|
[Knowledge Engine source code (available end of February 2022)](https://gitlab.inesctec.pt/interconnect-public/knowledge-engine)
|
|
|
|
|
|
|
|
### Generic Adapter
|
|
|
|
|
|
|
|
In the InterConnect project we define the following adapters:
|
|
|
|
|
|
|
|
* **<span dir="">Service Specific Adapter (SSA)</span>**<span dir=""> – configuration/mapping point between legacy interface and data model of the service and the InterConnect SIL.</span>
|
|
|
|
* **<span dir="">Generic Adapter (GA)</span>**<span dir=""> – a generic software component that provides communication gateway for secure and trusted integration into a wider Interoperability Framework instance.</span>
|
|
|
|
* **<span dir="">InterConnect Service Adapter</span>**<span dir=""> – a combination of SSA and GA representing a semantically interoperable service in a wider InterConnect Interoperability Framework instance (e.g. within and between project pilots).</span>
|
|
|
|
|
|
|
|
_Adapter terminology used in InterConnect:_
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span dir="">The Generic Adapter (GA) is a software gateway for secure and trusted communication between a service and a wider Interoperability Framework instance</span>. <span dir="">The GA enables:</span>
|
|
|
|
|
|
|
|
* <span dir="">A unified and secured communication interface using REST API;</span>
|
|
|
|
* <span dir="">Authentication and authorization point for IF access;</span>
|
|
|
|
* <span dir="">Deployment flexibility – Docker, with and without Knowledge Engine Runtime;</span>
|
|
|
|
* <span dir="">Automates registration of knowledge base and common knowledge interactions on boot.</span>
|
|
|
|
|
|
|
|
_High level architecture of the Generic Adapter:_
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Generic adapter source code](https://gitlab.inesctec.pt/interconnect-public/generic-adapter)
|
|
|
|
|
|
|
|
[Generic adapter REST API docs](https://gitlab.inesctec.pt/interconnect-public/generic-adapter/-/blob/master/generic-adapter-rest-OpenAPI.yaml)
|
| ... | ... | @@ -80,10 +139,63 @@ _Levels of interoperability provided by the Interoperability Framework:_ |
|
|
|
|
|
|
|
### P2P Marketplace Enablers
|
|
|
|
|
|
|
|
<span dir="">The P2P marketplace enablers include:</span>
|
|
|
|
|
|
|
|
* **<span dir="">Hyperledger Fabric blockchain configurations</span>**<span dir=""> for different types of P2P marketplaces (different hierarchies, consortium organizations, stakeholders, nodes and channels).</span>
|
|
|
|
* **<span dir="">Smart contract templates</span>**<span dir=""> for different types of orders and transactions to be featured in the marketplace. Smart contracts will include APIs for end user GUIs (web application) and APIs for services for automated P2P trading.</span>
|
|
|
|
* <span dir="">Smart contract templates for generating reports and audits about status of the marketplace and executed transactions - in line with regulatory and business requirements.</span>
|
|
|
|
* <span dir="">Smart contract implemented as semantic interoperability adapter for interfacing with the wider InterConnect Interoperability Framework.</span>
|
|
|
|
* <span dir="">Smart contracts for registering and identifying key actors and resources constituting P2P marketplaces.</span>
|
|
|
|
* <span dir="">Smart Contracts for integration of interoperable services which write data to or read data from the Hyperledger Fabric. This ensures that the P2P marketplaces are integrated with a wider instance of Interoperability Framework.</span>
|
|
|
|
* **<span dir="">Configurable order matching engine</span>**<span dir=""> for managing regulatory constraints, transaction priorities and conflict resolutions. The ordering engine also chains the smart contract calls performed by services participating in the P2P marketplace.</span>
|
|
|
|
* **<span dir="">White-labelled web application</span>**<span dir=""> for providing interface through which end users place orders. The web application can be instantiated and adapted to specific needs of a community establishing the P2P marketplace.</span>
|
|
|
|
|
|
|
|
<span dir="">The Interoperability Framework provides these P2P marketplace enablers as part of its toolbox. The enablers are provided as deployable containers that allow pilot owners and integrators to deploy and fully manage P2P marketplace instances. The established P2P marketplaces are in full control and under jurisdiction (regulatory, market wise, data privacy protection) of the integrators.</span>
|
|
|
|
|
|
|
|
_InterConnect P2P marketplace enablers:_
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
<span dir="">The P2P marketplace can be an energy marketplace or a marketplace for data transactions required for the realization of the community-based use cases. In the scope of the Task 5.4 the following P2P marketplace configurations are implemented and made available for the pilots and 3<sup>rd</sup> party integrators:</span>
|
|
|
|
|
|
|
|
</div>* <span dir="">Generic P2P marketplace configuration that can be easily adapted to specific use cases in energy and IoT domains. This implementation also features a web application for demonstration purposes.</span>
|
|
|
|
* <span dir="">Specialized configurations based on participating pilots (each having specific set of requirements for integration of P2P marketplaces into instances of the Interoperability Framework):</span>
|
|
|
|
* <span dir="">Dutch pilot - IoT data exchange with loyalty tokens realized through P2P marketplace.</span>
|
|
|
|
* <span dir="">Portuguese pilot - flexibility and energy profile trading/aggregation in communities through P2P marketplace instance.</span>
|
|
|
|
* <span dir="">Belgium pilot from Think E! and VUB - P2P energy trading within and between energy communities through instantiated P2P marketplace.</span>
|
|
|
|
|
|
|
|
[P2P marketplace enablers repository](https://gitlab.inesctec.pt/interconnect-public/p2p-marketplace)
|
|
|
|
|
|
|
|
[Generic P2P marketplace configuration, code and documentation](https://gitlab.inesctec.pt/interconnect-public/p2p-marketplace/-/tree/p2p-sample-marketplace)
|
|
|
|
|
|
|
|
[Dutch pilot (P2P marketplace for IoT data) configuration, code and documentation](https://gitlab.inesctec.pt/interconnect-public/p2p-marketplace/-/tree/p2p-data-mp-activities-mg)
|
|
|
|
|
|
|
|
[Portuguese pilot (flexibility and energy profile trading/aggregation in communities) configuration, code and documentation](https://gitlab.inesctec.pt/interconnect-public/p2p-marketplace/-/tree/p2p-flex-sharing)
|
|
|
|
|
|
|
|
[Belgian pilot (P2P energy trading within and between energy communities) configuration, code and documentation ](https://gitlab.inesctec.pt/interconnect-public/p2p-marketplace/-/tree/p2p-energy-trading)
|
|
|
|
|
|
|
|
## Service Specific Adapters
|
|
|
|
|
|
|
|
<span dir="">The Service Specific Adapter (SSA) is a custom software component developed and configured for a specific service/Knowledge Base. Each service provider goes through a process of implementing SSA. The main functionalities of the SSA are:</span>
|
|
|
|
|
|
|
|
* <span dir="">SSA Service endpoint functionality – includes all necessary functionality to interact with the service via the offered (legacy) service API.</span>
|
|
|
|
* <span dir="">SSA mapping functionality – performs mapping of parameter bindings (semantic interface) to service API parameters and vice versa. Can be one-to-one mapping or more complex logic to combine for instance several API calls to complete one binding set.</span>
|
|
|
|
* <span dir="">SSA GA endpoint functionality:</span>
|
|
|
|
* <span dir="">Register the Generic Adapter instance for this service.</span>
|
|
|
|
* <span dir="">Register the Knowledge Base - this creates a smart connector.</span>
|
|
|
|
* <span dir="">Register the Knowledge Interactions (Graph Patterns).</span>
|
|
|
|
* <span dir="">Offer Knowledge Interaction execution.</span>
|
|
|
|
|
|
|
|
_Knowledge Base with its SSA and GA:_
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
_Interoperability chain and message sequence chart between two interoperable services:_
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Methodology for building Service Specific Adapters (SSA) will be included here by 25th of February 2022.
|
|
|
|
|
|
|
|
## Examples and Tutorials
|
| ... | ... | |
