BB26.I Ontology for secure wireless data transfer
From its-wiki.no
Revision as of 15:37, 18 July 2017 by Josef.Noll (Talk | contribs)
| Title | Semantic and ontology definition for secure wireless data transfer |
|---|---|
| Page Title | |
| Technology Line | Reference Architecture/Implementation |
| Lead partner | ISEP |
| Leader | Ramiro Robles |
| Contributors | ISEP |
| Related to Use Cases | SCOTT:WP8, SCOTT:WP9, SCOTT:WP11, SCOTT:WP15 |
| Description | Define the semantics and ontology features that will allow different entities of the architecture to exchange secure information and minimize attacks. |
| Main output | The final objective is to enable interoperability between different domains with different technologies and different security levels. Ontologies will be created to enable a convenient data representation with high levels of security and privacy, and also that minimize risk of attacks, leaking or misinterpretation. |
| BB category | Methodology (for SW/HW development), SW component, Interface, Standard, Means for establishing cross-domain interoperability |
| Baseline | Currently there is no consensus or standard for security in the IoT. Semantics and ontology interoperability has been proposed but it is also in its infancy. There are many vendors nd standards in the industry for IoT interoperability. This is an important gap in the literature. Our building block attempts to bridge this ga providing convenient interoperability, protocol translation, and data representation for industrial automation, smart cities etc. |
| Current TRL | TRL 3 |
| Target TRL | TRL 6 |
Status
mail from Xavier, 17Jul2017
After a deeper analysis of the Building Blocks and the modifications which have been produced these last weeks, we have detected that two of our BBs, the BB26.C “Uninterrupted network interconnection for the WSN on trains” and BB26.J “Ubiquitous IoT/M2M coverage and connectivity via satellite. Satellite technology resources and cost optimization for M2M applications“ are redundant and no longer needed.
- The technology to be developed in these Building Blocks are already covered by BB26.A.
- This BB manage the development of the reference architecture and implementation of the Autonomous Wireless Network including ours, so doesn’t make sense to add also another BB for it.
- Our BB26.C and J have no participants but us, and BB26.A has a more interesting partners’ participation with a more coherent integration between elements of the Autonomous Wireless Network.
We have discussed this with the owner of this BB, and we agreed to participate in this BB to develop this technology, so we will merge our BB26.C and J technical aspects and requirements with them. So we propose to delete the BB26.C and BB26.J.