Public Deliverables

This document presents the exploitation of the results of BRAIN-IoT project for replication and scale-up. The main potential outcomes of the project that can be exploited have been analyzed from three perspective : 

• Each of the 13 partners and their plan to extend the impact of BRAIN-IoT and ensure the continuation of the activities initiated in the project; 
• Each of the 14 assets and their plan to exploit the assets; 
• Two use cases in critical water infrastructure and robotics showcased the utilization of BRAIN-IoT. 

The replication and scale-up of BRAIN-IoT reveal to be diverse from commercial exploitation to academic collaboration and research support though contribution to standardization and community developers, also thanks to the positive synergies between project’s partners described along this document: 

• The creation of a start-up – Kentyou – composed of formers members of BRAIN-IoT aiming to exploit commercially the assets deployed during BRAIN-IoT; 
• A partnership commercialization of a module designed during BRAIN-IoT with a start-up commercializing water meters external to the project; 
• The contribution to standardization activities including OMG, W3C and OSGi Alliance. 
• The release of an open source stack demonstrating the project results; 
• The development of a new R&D testbed for smart cities designed to attract research institutions and device and systems producers to validate solutions before commercialization; 
• And the initiation of an open source community to sustain these results. 

The main objective of work package 7 is to create awareness and adoption of the BRAIN-IoT project within the targeted communities defined by deliverables D7.4 & D7.1, i.e.: research communities, developer communities (Early adopters and Late adopters), solution makers, end-users and the general public. 

This report documents the final efforts and results of the project in term of advertising and community engagement. It follows the dissemination strategy defined in D7.1. and the updated version of the advertising, community engagement materials and results available in D7.5. 

In this document, a list of press releases, articles, social media tools and available contents will be presented. 

The present document is a deliverable of the BRAIN-IoT project, funded by the European Commission, under its Horizon 2020 Research and innovation program (H2020), reporting the validation results of the activities carried out by “WP6 – Test, Demonstration and Evaluation”. This deliverable includes the results of the validation methodology described in the “Deliverable D6.2 – Integration and Lab Scale Evaluation” and “Deliverable D6.3 – Phase 1 Integration and Evaluation Framework” and it follows the presentation philosophy of validation results in some production environments. The deliverable does not extend deeply the sections included in the previous D6.2 and D6.3 more than necessary, but it adds information and remarks important aspects related to the validation methodology needed for the good comprehension of the process and that they were not indicated in the D6.3 because the approach was not yet fully defined at the time of writing that deliverable. 

The development activities are being performed in the WP3, WP4 and WP5 and the activities of verification, validation and evaluation will be reported in the deliverables 6.3, 6.4, 6.5 and 6.6 of WP6. 

This deliverable includes 5 sections. Section 1 introduces a summary of concepts related to the validation procedures. Section 2 presents the process of the validation management including the methodology. Section 3 is the main section and includes the results of the validation activities during the first validations iteration, indicating the status of every test and requirement defined in the previous activities. Section 4 contents the status of the tests and demonstrations regarding the KPIs defined in the Grant Agreement and extended in the deliverable D6.2. Section 5 provides the main conclusions related to the validation process and results. 

This document presents the hardware and software architecture that support the integration and evaluation of all separated results of the technical work packages that, once integrated, provide the behaviours defined in the use cases. 

This document focuses on two different but related parts. The first part focuses on the integration of all the components developed in the Brain-IoT project from a practical approach, describing in detail the software and hardware infrastructure that allows integrating all the components that, once integrated, implement the use cases defined and implemented in the project. 

The second part focuses on describing the validation methodology used to validate the integration and proper implementation of the use cases. The validation methodology is described in more detail in the D6.6: Phase 2 evaluation report. D6.6 also presents the results of the tests created for evaluating the integration of all the components that implement the defined use cases. 

The deliverable D5.9, titled “Guidelines for privacy compliance and control in IoT services models” is the third outcome of the Task 5.3 “Privacy awareness and control”. 

The first two outcomes of the task have been the followings: 

• D5.3 – Initial enablers for Privacy awareness and control 
• D5.7 – Final enablers for Privacy awareness and control 

D5.3 focused on an analysis of the General Data Protection Regulation (GDPR)’s precepts and defined a methodology based on Privacy Impact Assessment (PIA) to evaluate the risks for personal data misuse in an IoT application like the ones considered in BRAIN-IoT project (see D2.6 for a description of the use-cases). According to GDPR, risks assessment based on PIA must always be done when data containing information related to individuals are intended to be handled. This procedure helps to understand whether a specific application or service do satisfy the requirements to be allowed for the treatment of such personal data. 

As described in D5.7, the planning of the activities related to Task 5.3 evolved a lot between the end of the second year of the project and during the third year, following the feedback received by the Reviewers and the External Stakeholder Group (ESG) members, as well as the hints provided by the H2020 Large Scale Pilot (LSP) MONICA Project’s members. In fact, the collaboration between BRAIN-IoT and MONICA led to the identification of a set of use-cases which brought Brain-IoT Consortium few doubts about how to remain compliant with GDPR while still providing a reasonably good level of the quality of service. 

The identified use-case, described in D2.6 and D5.7, differs slightly from a usual case where a data owner establishes a relationship with a service provider, who handles her/his personal data to deliver the required service. In fact, the identified use-case consists in a service provider who delivers a service, which is composed by micro services implemented and managed by different realms and administrative domains. 

Such case is covered by GDPR in the sense that the internal micro services would be considered like third party services that the macro service is supposed to indicate in the PIA along with all the details about how the personal data will be used, treated, and managed. Basically, such cases would be handled composing the PIA of the single micro services in one big all-encompassing PIA of the macro service. 

This methodology is fully GDPR-compliant and aligned with legal frameworks but, from a technological point of view, it is completely unscalable and very difficult to manage both from the side of the service provider and from the data owner’s side. In fact, whenever the macro service is supposed to be composed by a large number of micro services, the PIA gets difficult to be performed and also it may easily be error prone. Moreover, in a context where the micro services can frequently vary, e.g., when the provided macro service implements a location-based user experience and the micro-services can churn according to the position of the end user, the macro service if forced to contact the end-user/data owner very frequently to inform her/him about the new service conditions and data management information. Such situations would be very complex to handle and also annoying for a smooth experience and sufficient quality of the service provided. 

Apart from the use-case defined in conjunction between BRAIN-IoT and MONICA, wider context and scenarios have been identified as possibly affected by the issues mentioned above. More specifically, these issues could be relevant for: 

• Smart City scenarios where data provided by citizens can be required and exploited by a multitude of services belonging to the City; 
• Scenarios where IoT systems would like to access data source, which provide data streams in an open or monetized way. 

Smart cities provide services that may use data provided by citizens to implement public utility services, free or commercial services, marketing and entertainment services, integrating and federating sub-services (i.e., micro services) provided by public or private entities belonging to the city itself. 

Data can come from the most disparate sources, public or private. Data can be generated by citizens’ personal IoT devices, and citizens also may want to provide such data in an open or monetized way. The lowest common denominator which includes such scenario and privacy issues, is the right of the data owners to grant the access to her/his data according to her/his own rules. 

This document aims at describing the end-to-end data security layer which has been developed in the BRAIN-IoT Project to secure IoT systems. The first step performed by BRAIN-IoT Partners has been to study the IoT systems architecture, their security challenges and the existing mitigation measures in order to identify the innovations they can bring to go beyond the state-of-the-art. The IoT sensors/actuators have been identified as a weak point of the IoT systems architecture. To improve this, BRAIN-IoT Partners have worked on an end-to-end data security layer dedicated to constrained devices and including strong authentication of IoT sensors/actuators, end-to-end data encryption and optimization of key management. Once finalized, this solution has been compared with existing ones to highlight its added-value and has been implemented in the BRAIN-IoT Project. 

However as no major limitations have been identified for Cyber Physical Systems, BRAIN-IoT Partners have decided to rely on well-proven security solutions for them. 

So at the end, this deliverable summarizes for both BRAIN-IoT use-cases how end-to-end data security has been ensured.  It is essential to note that a demonstration video has been recorded to demonstrate the innovative end-to-end data encryption layer developed in the Project and will be available soon in the BRAIN-IoT website. 

The deliverable D5.7 – “Final enablers for Privacy awareness and control” is the second outcome of T5.3 – “Privacy awareness and control”. 

As per [RD.1], this task develops techniques to facilitate the adoption of privacy control policies in decentralized environments, focusing on programmatic ways to enable users to directly control the access policies of the data that she/he owns. The proposed approach is defined to be adopted in a wide number of IoT solutions and provides the ability for the data owner to change the existing (or pre-set) configurations at any time. 

Deliverable D5.7 describes the process which brought to the definition of the Privacy Control System components of the BRAIN-IoT Platform. It also reports the design choices and the development details of such component. 

This report presents the final perspective of a potential business strategy around the BRAIN IoT marketplace. 

To assess this potential perspective the consortium has structured its approach around the following tasks: 

• A definition of the repository functional and technical requirements (section 3) 
• A definition of the business requirements (also section 3), based on the project itself but also from an assessment of existing other examples of repository/marketplace from known, comparable European projects and a review of the business approach of existing software marketplaces developed by various type of businesses and industries (telecom operators, cloud platforms, software repositories, application enablement platforms…). (both detailed in appendix and in D4.3) 
• A specific focus (also section 3) on a target market – smart city – that was identified during the course of the project due to the creation of a new partner (minutes provided in appendix) 
• The analysis of potential business models for the marketplace (in section 4) 

The main findings can be summed up as follow: 

• The value of a `Marketplace` is dictated by the shareability/re-usability of artefacts in the Marketplace in different and unrelated runtime contexts. Generic high-quality Edge Integration Components with assured pedigree/provenance will be of interest to a large community. Whereas Sophisticated AI/ML-based behaviours trained for specific roles in specific environments may have extremely high business value in the target environment, but limited applicability elsewhere. Here, it is the generic modelling tools that allowed the simple creation of context-specific AI/ML-based behaviours that will be of interest to the wider community. High-value items are generally developed with a bespoke approach and do not fit with the idea of the marketplace. 
• • The development of the marketplace would provide benefits to various stakeholders by bringing additional value to the technology platform, but the sustainability of the approach remains unclear due to missing sponsors, especially if the engagement of developers remains too limited. Nonetheless, a repository, which can be seen as a low-key approach of the marketplace, already provide benefits to the limited set of partners already active in BRAIN-IoT and imply limited costs. The project has therefore decided to build such an approach (step 1 of the approach). 
• A Brain IoT marketplace would have then to attract a critical mass of contributors that can build potential behaviours. Thus a focus on the modelling tool community, smart behaviour developers, should be considered. Ideally, the marketplace should also initially be populated with simple behaviours that can be composed easily into more complex ones to facilitate adoption (step 2). The capacity to develop into this step remains so far to be clarified. 
• In a third time (or even potentially in parallel with step 2), the marketplace would have to focus on IoT users, deployment operators and integrators that would need the behaviour developed by the modelling tool community. This may be done as a private marketplace(s) in a given vertical like smart cities. The consortium has identified some sweet spots around large cities and potentially regions. For the latter target (large regions), the marketplace may have to extend to packaged apps (in addition to behaviours/components) and also to data. Data and apps would enlarge the marketplace usage as they correspond also to more replicable items. 

To compensate the marketplace costs and build up the marketplace community, a business model using a subscription model is considered as a more realistic short-term option than a traditional model that takes a share of marketplace exchanges. This is especially the case if the marketplace focuses at first on small atomic behaviours to be assembled. This provides a good balance between additional revenues to develop the marketplace and additional value for community members without developing a too large (and therefore expensive) approach. But overall, the limitations are too important (shareability of components remains low) to permit a real exploitation perspective and the consortium decided (especially after interim review) to focus on other opportunities and has therefore focused on a free model (which means that the marketplace is in reality bundled with the platform, bringing this way more value to the platform but no direct monetization). Indeed, the repository is already providing some added value to BRAIN-IoT partners. This could serve after as basis to provide additional features for BRAIN-IoT customers in vertical markets (like smart cities) on top of the platform in the future 

This deliverable provides the implementation of BRAIN-IoT Repository (it was called Marketplace before M18), developed during task 4.3, as part of Work Package WP4 “Decentralization of IoT Platform and Services”. Although it also presents the BRAIN-IoT Repository from a technical point of view, it will refer to documents on the business dynamics and other documents related to components, parts of the BRAIN-IoT architecture, and the related business analysis will be further explored in D4.7-“Final Deployment and Operation Enablers”. The present document will focus more on the technical implementation of BRAIN-IT Repository and its practical application in real scenarios. 

As exposed in D4.3, BRAIN-IoT Repository is a repository for receiving all kinds of artefacts generated by BRAIN-IoT development/modelling environment and BRAIN-IT infrastructure services. They can be OSGi bundles, BRAIN-IoT services, application logic and adaptors. Each BRAIN-IoT service is a functional unit of an IoT system deployable in an OSGi container and has its own Requirements/Capabilities metadata which will be used for the dynamic service discovery and deployment in BRAIN-IoT execution platform. Also, each BRAIN-IoT service include a set of OSGi bundles with code, and OSGI metadata satisfying all the dependency requirements for running the functional unit in an OSGi framework, and an OBR Index with a dependency map between bundles. To rapidly discovery a desired BRAIN-IoT service, BRAIN-IoT Repository uses a two-tier indexing hierarchy, the top-level index indicates the list of BRAIN-IoT services with their metadata and tell where the BRAIN-IoT execution platform will discover the required BRAIN-IoT service in response to a specific event. The secondary-level is the OBR index originally contained in a BRAIN-IoT service with the dependencies information. 

The BRAIN-IoT Repository is enabled by components developed for general purpose inside the Platform and also for dedicated enablers. This document will be focused on the dedicated enablers implemented for task 4.3 and will reference other enablers in the relevant documentations such as the enablers (i.e. BMS, BIS) in D3.7 for dynamic distribution of IoT behaviours in BRAIN-IT Fabric and the enablers (i.e. System Description, Paremus Service Fabric) in D4.4 for the discovery of BRAIN services, distributed deployment of IoT systems. 

The specific enablers are described in section 3 “Technologies used”. Subsequently, is addressed the integration with other enablers, not specifically developed in the Brain-IoT project. The final interaction, state and performance is then discussed. How to deploy them, conclusions and future work to conclude. 

Building a framework for deployment and operation of Internet of Things (IoT) service orchestration is a complex task, since it needs to address two major challenges: a strong availability and an abstraction layer to deal with heterogeneous devices. In order to tackle the challenge of availability, the Brain IoT project has chosen to rely on Paremus service Fabric1, which provides discover, search, composition and orchestration of IoT applications in a distributed changing production environment. Regarding the interaction with heterogeneous known/unknown IoT applications/devices, Brain-IoT must be flexible enrough to cope the new and changing discovery mechanisms and requirements. Apart from providing such a flexible BRAIN-IoT infrastructure, it also provides two types of generic Edge Nodes for the connectivity and interoperability to a large range of IoT applications/devices: the sensiNact-enabled Edge Node and the WoT-enabled Edge Node. 

The sensiNact-enabled Edge Node built based on the Eclipse sensiNact middleware2 has been chosen for its capability to interact with a wide variety of equipment and protocols, as well as its extensibility mechanisms, instead the WoT-enabled edge nodes are based on W3C Web of Things standard3 and specifically this deliverable presents the one implemented to work as an adaptor to the Robot Operating System (ROS)-based Cyber-physical Systems and devices for the interoperation with other heterogeneous IoT platforms and devices due to its generality and the extensibility. 

The purpose of deliverable 4.5 is to finalize the Brain-IoT execution platform as described in “D2.7-section 3.2 Development View“ using the best of those three enablers, thanks to evolutions of the three code-bases in order to integrate them gracefully. The section 2 of this deliverable will specify the scope of the components within the BRAIN-IoT overall Functional View, the sections 3 will briefly introduce the principle of how BRAIN-IoT Fabric Infrastructure is able to flexiblly and permitly garantee the load of existing/unexisting IoT services/devices on demand in production environment. The section 4 representes the sensiNact-enabled Edge Nodes practically used in BRAIN-IoT use cases, and the section 5 will represent the implemented WoT-enabled ROS Edge Node used in the Service Robotics domain. Finally, Section 6 describes briefly how the edge nodes are deployed in the Brain-IoT Exécution Platform and Section 7 concludes the deliverable. 

The software stack is finalized in this deliverable. Compared with the initial version of the deliverable “D4.2-Initial Deployment and operation enablers”, this deliverable will not only keep the installation instruction of Paremus Service Fabric, but it will also enrich and supplement the instructions to install the sensiNact Edge Node, as well as the application in both BRAIN-IoT use cases. Furthermore, the present document will also add the complete design and development details of WoT-enabled ROS Edge Node applied in BRAIN-IoT Service Robotics use case as well as the detailed instructions to build and run it in Brain-IoT platform. 

This document builds upon the concepts introduced in Brain-IoT deliverable D4.1 “Initial discovery, search, composition and orchestration enablers”, but whilst that document detailed the thinking concerning the overall design of the core infrastructure, this document provides an oversight of what has been delivered, and hopefully simplifies some of the ideas that were proposed in D4.1 

It is pleasing to report that many of the initial concepts proved viable, and hence this document reflects the initial proposals in the core area. 

Despite the omnipresent use of the word “Cloud” in almost all new software systems, in practice those systems continue to be built for a fixed and unchanging production environment. Whilst the use of Cloud technology might mean that the underlying hardware is abstracted to set of virtual machines running in some Cloud vendor’s data centres, the actual operational system is built with pre-determined functional behaviours. 

The critically important issues of operational complexity, maintainability and economic sustainability tend to be ignored so planned functional changes and changes forced by the underlying runtime environment are treated as `exception` behaviours. In response to this seemingly flexible but actually rigid model, the industry has come up with the “DevOps” combined development and operations model, tightly coupling the original developer and the production environment. This approach is manageable for relatively small and simple Enterprise systems with rigidly enforced homogenous runtime environments but rapidly fails at scale and in heterogeneous distributed environments. It is also prone to problems caused by poor documentation and neglect of correct operations procedures. 

Because of the sheer numbers of edge devices Smart City and Industry 4.0 environments promise to be orders of magnitude more sophisticated than any traditional Enterprise environment, or indeed 1st generation Cloud Hub & Spoke IoT deployments. Smart City and Industry 4.0 environments will be massively distributed, heterogeneous, federated and co-evolving software eco-systems: adapting and changing and scaling in response to local requirements and environmental changes. For such software ecosystems to be economically sustainable, operational simplicity, maintainability and runtime adaption must be intrinsic to their architectures; and so these non-functional concerns are core BRAIN-IoT objectives. 

This document explores how Brain-IoT has approached the requirements of initial device discovery, search, composition and orchestration in a manner that addresses these non-functional challenges. We believe that this approach is sufficiently flexible to deal with any foreseeable runtime use. As examples, the current Brain-IoT Use Cases are subsets of these generalized behaviours. 

This document describes the research work and overall approach identified by task 3.3 within Brain-IoT workpackage 3 – ” IoT Framework for smart dynamic behaviour”. 

This activity developed Brain-IoT’s generic (i.e. unrelated to specific functions or any particular use case) runtime mechanisms needed to support the dynamic deployment and orchestration of BRAIN-IoT’s Behaviours. 

This is an essential characteristic of the Brain-IoT project and provides not only unique differentiator, but significantly advances state of the art from a global IoT perspective. As such, this document discusses this in detail. 

It should be noted that this deliverable is solely concerned with the generic structures and does not detail the specifics of Behaviours needed for particular Brain-IoT project Use Cases as specified in D2.4; nor how Behaviours should be modeled; these concerns are addressed by the D3.1, D3.2 & D3.4 deliverables in WP3. 

As specified in D2.7 – Final Architecture and Test Sites Specifications, the BRAIN-IoT functional architecture is defined as represented in Figure 1. A red rectangle highlights the functional component which is subject of the current document. 

The present document is a deliverable of the BRAIN-IoT project, reporting the results of the activities carried out by WP3-IoT Framework for smart dynamic behaviour. The work presented in this document has been compiled with a collaborative effort of all partners who actively participated in Task 3.2 AI and ML features for smart behaviour and actuation. 

In this deliverable D3.6 Final AI and ML features for smart behaviour and actuation, we provide the implementation of the final AI and ML components and the final resolution of the relevant use cases where the ML components are involved. The use cases resolved are from both Brain-IoT target scenarios Critical Water Management Infrastructure from EMALCSA and Service Robotics from ROBOTNIK. The document is organized in this way: 

• Section 2 – State of art: Where the present condition of the technologies related to ML and AI and their current uses is showcased. 
• Section 3 – BRAIN-IoT Implementations: Describes the implementations that have been developed inside of the BRAIN-IoT project for showcasing the ML and AI capabilities of the environment. 
• Section 4 – BRAIN-IoT Use Cases resolution: Outlines how the implemented solution solves two different use cases. 
• Section 5 – BRAIN-IoT Services runtime deployment: Details the particular characteristics of the deployment of ML and AI services. 
• Section 6 – Conclusions: Finally summarizes the results of the work described in this document and offers an insight of what could be done on the field from now on. 

In this deliverable we have considered the reviewers comments for previous related documents and for M18 recommendations, the answers can be found in the in the end of the document – Appendix : M18 reveiw comments addressment. 

This document is an updated version of D3.1 – “Initial data and capabilities models for cross-platform interoperability”. It has been improved dramatically comparing with the D3.1. In D3.1, we analyzed the items that need to be modelled within the BRAIN-IoT scope and identified a set of the potential state of the art modelling languages and proposed a rough idea of the BRAIN-IoT Services Modelling Language development. However, in this document, based on the initial outcome from D3.1, we have presented a comprehensive view of the framework with the concrete building blocks it contains as well as its implementation. More importantly, we have developed the BRAIN-IoT Services Modelling Language to satisfy the different needs derived from the same modelling language and clearly identified the features to be provided in three abstraction levels of IoT systems. As a note, the introduction of the technologies adopted to implement the proposed architecture can be found in D3.1, we will not repeat in this deliverable, instead, we pointed the specific sections to look at on demands. 

This document shows the overview of the BRAIN-IoT modelling & Validation Framework, including the proposed modelling methodology, functional architecture and its implementation with a focus on Modelling language development. 

Furthermore, this document has properly addressed the comments from the M11 review and M18 review, more information can be found in the Appendix: M11 and M18 comments addressing. 

The deliverable D2.8, titled “Second Landscape and ESG workshop report” is the second outcome of T2.2 “Alignment with on-going IoT-related initiatives, roadmaps and the ESG”. 

This document is the second iteration of the deliverable D2.3 – “Second Landscape and ESG workshop report”, and extend it as follows: 

• • Section 4.3 has been updated with the implication of the adoption of the W3C WoT standard within the BRAIN-IoT Platform, specifically for the implementation of the WoT-enabled Edge Node component. 
• • Section 5.4 has been added with the perspective of the project in terms of data privacy preservation and the challenges and identified countermeasure to allow the Data Owner to take direct control of the policies to access their data. 
• • Section 12 has been added to better explain the redefinition of the plan for the organization of the External Stakeholder Group meeting, and the motivation that brought to the replanning. 
• • Section 13.4 has been added to summarize the outcomes from the 1st ESG meeting and clarify the beneficial return that the project had from this meeting. 
• • Section 14 has been added to describe the organization of the SAM IoT Conference to attract new external stakeholders through an open call and present the latest achievements of the project and get feedback. 
• • Section 15 has been added to describe the virtual workshops organized with the ESG members engaged from SAM IoT, as well as the methodology used for the assessment of the BRAIN-IoT Platform by the ESG itself. Also, the results of the ESG’s assessment are reported. 
• • Section 16 has been updated with the conclusions coming from the final assessment of the BRAIN-IoT Platform by the ESG members. 

1.1 Scope 

For each asset brought by a project partner, this document details its landscape. That is: 

• • The SoA (State of the Art) and forecast in technology trends in the asset’s field. That is “research, policy and commercial initiatives delivering tangible results, standards, regulations or lessons learned which are relevant.” This document will either collect the finding here, or reference previous BRAIN-IoT deliverables. 
• • The positioning of the asset in relation to relevant SoA and technologies trends. 
• • The asset improvements that will result from BRAIN-IoT developments. 

This document also provides the report on the first two ESG meeting held in December 2019 and September 2020, as well as the report of the outcomes from the BRAIN-IoT Assessment Workshops held from December 2020 to March 2021. 

1.2 Feedbacks from the Reviewers related to D2.8 

The M18 Review Report mentioned the necessity to define a clear “plan on involvement of stakeholders around pilots should be put in place”. Moreover, the “dissemination towards the IoT cluster should also be the opportunity to assess the interest of the stakeholders community for Brain-IoT developments”. 

This document aims to better specify the plan for the involvement of External Stakeholder supporting the design and refinement phase, as well as the evaluation. A specific focus has been dedicated to the assessment of the platfrom in the context of the pilots. Members of the Security and Privacy Cluster have also been invited (more specifically in the context of SAM IoT, where members of CHARION, SEMIOTICS and NGIoT projects participated), and the BRAIN-IoT security and privacy approaches have been disseminated as chapters in books edited in the context of the Cluster itself. Contributions to common approaches presentation have also been delivered. model-Based fRamework for dependable sensing and Actuation in INtelligent decentralized IoT systems 

Deliverable nr. Deliverable Title Version D2.8 Second Landscape and ESG workshop report 1.10 – 31 March 2021 Page 6 of 59 

The description of the redefined plan, as well as the contribution of the stakeholders to the improvement of the project achievements, are reported in Section 12, 13 and 14. Section 15 reports the outcomes of the assessment process contributed by the External Stakeholder Group members. 

1.3 Related documents 

This the list of documents referenced in this deliverable, including project deliverables that carry information and analysis on SoA and trends. 

The present document is a deliverable of the BRAIN-IoT project, funded by the European Commission, under its Horizon 2020 Research and innovation program (H2020), reporting the results of the activities carried out by WP2 – Requirements and Architecture Engineering. 

The main objective of the BRAIN-IoT project is to focus on complex scenarios, where populations of heterogeneous IoT systems cooperatively support actuation and control. In such context, many initiatives fall into the temptation of developing new IoT platforms, protocols, models or tools aiming to deliver the ultimate solution that will solve the IoT challenges and becomes reference IoT platform or standard. 

The work presented in this document has been compiled with a collaborative effort of all partners who actively participated in the Task 2.1 – Analysis and elicitation of innovative user stories and requirements of BRAIN-IoT target scenarios: Critical Water Management Infrastructure from EMALCSA and Service Robotics from ROBOTNIK. 

Deliverable D2.1 “Initial Vision, Scenarios and use cases” at M3 has reported on i) the identification of the purpose and workflow of the workbench, ii) an initial set of stakeholders and their categorization, iii) the communication flow between them and lastly iv) an initial description and analysis of use cases. In the deliverable D2.4 “Updated visions, scenarios, use cases and innovations” at M14, we have refined and updated the initial description of Water Management and Service Robotics scenarios and use cases. 

In this deliverable D2.6 “Final visions, scenarios, use cases and innovations”, we provide the results of the final description and analysis of BRAIN-IoT scenarios. The specification presented in D2.6 will be used in the third and final iteration of the BRAIN-IoT development cycle for inter-project communication in order to identify development scenarios and help to fertilize the process of thinking for the design of future systems. Besides the aspects regarding development, the vision scenarios are used as understandable stories to externally communicate the project’s aims and to inform the audience what kind of applications can be designed with the framework developed by BRAIN-IoT project. 

The novel technical contributions with respect to the previous deliverable D2.4 are: 

• We add Section 2.2 to explain the key concepts and the common template used for the use cases description. 
• We update both Service Robotics and Critical Water Management Infrastructure scenarios and provide clear description of use cases with their associated smart behaviours and security perspective in Sections 3 and 4. 
• We clarify the innovations brought by BRAIN-IoT for target scenarios in Sections 3.8 and 4.8. 
• We introduce UML diagrams for visual modelling of ROBOTNIK use cases (Section 3.5) and EMALCSA use cases (Section 4.5). 
• We highlight related European IoT Large Scale Pilots (LSP) projects in Section 5. 

In this deliverable, we have considered the reviewers’ comments for D2.4. The answers to the comments are given in annex A1. 

This document is a quick start guide to the BRAIN-IoT Modelling & Validation framework implementation, i.e., a design tool hereafter named BRAIN-IoT Services Development Toolkit”. BRAIN-IoT Services Development Toolkit is an Eclipse Rich Client Platform (RCP).

The tool is composed of the Papyrus IoT-ML modeller, W3C WoT TD modelle, BIP modeller, AIML modeller, and sensiNact data model modeller. These modelling languages and their modellers are integrated within a same UML and Eclipse framework. More information on the underlying modelling languages can be found in D3.5. In addition to these modellers, BRAIN-IoT Services Development Toolkit offers Model-Driven Engineering (MDE) tools for purposes such as model checking, model verification, code and interface description generation, and monitoring.

This document shows how to download, install, launch, and create a first IoT-ML model with BRAIN-IoT Services Development Toolkit. We show how the model can be annotated with concepts of W3C WoT TD and sensiNact. Then the model can be refined as system software components which are represented in the BIP modelling and analysis framework for code generation. Finally, this document shows the work have been done for the final version of the tool. These MDE tools in development exploit the model for metadata generation and add Models@runtime functionalities, i.e., monitoring and quick post-deployment behaviour prototyping through models.

The deliverable D2.3, titled “First Landscape and ESG workshop report” is the first outcome of T2.2 “Alignment with on-going IoT-related initiatives, roadmaps and the ESG”.

As per [RD.1], “This task will continuously monitor state-of-the-art research, policy and commercial initiatives delivering tangible results, standards, regulations or lessons learned which are relevant for BRAIN-IoT developments and further business exploitation. Input from monitored initiatives will be used to perform analysis to identify and exploit synergies with other on-going initiatives and forecast of technical trends. In order to ensure relevance and correctness of analysed synergies, this task will leverage the collaboration of representative external experts, namely the External Stakeholder Group (ESG), which will support the project with the identification of potential values of use cases for stakeholders and uncertainties related to business and technology trends, as well as providing their view on the BRAIN-IoT potential for development. As further detailed in Section 12, interaction with the ESG will be managed jointly by LINKS, UGA, and IDATE, led by partner CEA. ISMB has set aside a dedicated budget to organize and support ESG activities. CEA will lead the task by ensuring that identified synergies are properly reflected in BRAIN-IoT specifications.

LINKS and UGA will ensure alignment with initiatives and roadmaps in the areas of IoT and CPS. PAREMUS will focus on inputs from key standardization initiatives in the area of middleware. AIRBUS will support the activity by focusing on security and privacy aspects, providing inputs from cyber-security IoT initiatives, especially with the French ANSSI agency and similar initiatives. IDATE will support the activity ensuring alignment with technology trends identified through IDATE reports, desk research and other projects with similar activities like CREATE-IoT. Results will be documented in deliverables D2.3 and D2.8.”

The present document is a deliverable of the BRAIN-IoT project, funded by the European Commission, under its Horizon 2020 Research and innovation program (H2020), reporting the validation results of the activities carried out by “WP6 – Test, Demonstration and Evaluation”. This deliverable includes the results of the validation methodology described in the “Deliverable D6.2 – Integration and Lab Scale Evaluation” and “Deliverable D6.3 – Phase 1 Integration and Evaluation Framework” and it follows the presentation philosophy of validation results in some production environments. The deliverable does not extend deeply the sections included in the previous D6.2 and D6.3 more than necessary, but it adds information and remarks on important aspects related to the validation methodology needed for the good comprehension of the process and that they were not indicated in the D6.3 because the approach was not yet fully defined at the time of writing that deliverable. 

The development activities are being performed in the WP3, WP4, and WP5, and the activities of verification, validation, and evaluation will be reported in the deliverables 6.3, 6.4, 6.5, and 6.6 of WP6. 

This deliverable includes 5 sections. Section 1 introduces a summary of concepts related to the validation procedures. Section 2 presents the process of validation management including the methodology. Section 3 is the main section, and includes the results of the validation activities during the first validation iteration, indicating the status of every test and requirement defined in the previous activities. Section 4 contains the status of the tests and demonstrations regarding the KPIs defined in the Grant Agreement and extended in the deliverable D6.2. Section 5 provides the main conclusions related to the validation process and results. 

This document reports the activities performed in Task 5.2. This task aims at designing and implementing an Authentication, Authorization and Accounting (AAA) layer in order to provide security and trust for the BRAIN-IoT system. This layer ensures Authentication and Access Management to allow only enrolled and authorized devices or users to access a service. It aims at overcoming the current state-of-the-art by: 

• Providing only one solution to manage Users and Devices authentication and access control 
• Ensuring strong authentication for low power devices 
• Optimizing key management 

Actually, a large number of devices and their specificities in IoT systems lead indeed to complex management activities with high operating costs, especially regarding security management: identity, cryptographic keys, and right management. 

The present document is the deliverable D5.5 of the BRAIN-IoT project, funded by the European Commission, under its Horizon 2020 Research and innovation program (H2020), reporting the results of the activities carried out by WP5 – End-to-end Security, Privacy and Trust Enablers. The work collected in this document has been compiled with a collaborative effort of all partners who actively participated in Task 5.1 – Threat Modeling and Assessment of BRAIN-IoT target scenarios: Critical Water Management Infrastructure and Service Robotics.

The first report on threat modeling and security assessment has been provided in deliverable D5.1 at M6. In deliverable D5.1 “Initial Threat Modeling and Security Assessment of Target Scenarios, Solutions”, we have focused on the definition of the risk assessment methodology and provided an initial risk assessment of the target scenarios as an illustration of the first phases of the methodology, namely, the identification of critical assets and associated threats and vulnerabilities.

The results of the second iteration have been provided in deliverable D5.4 at M16. In deliverable D5.4 “Updated Threat Modeling and Security Assessment of Target Scenarios, Solutions”, we have continued the risk assessment process through one more iteration by updating and refining the set of assets and their associated threats, for each scenario. We have also made progress in the risk assessment methodology by identifying security objectives that cover the full list of threats for each asset and elaborating technical security requirements covering various security objectives.

This deliverable D5.5 gives the final report on threats modeling and the security assessment process. The novel technical contributions with respect to the previous deliverable D5.4 are:

• In sections 5 and 6, we update the list of assets and their associated threats, security objectives, and security requirements for both Critical Water Management Infrastructure and Service Robotics scenarios.
• In section 7, we present a technological solution to implement the security requirements and explain the innovation of BRAIN-IoT solutions compared to the state of the art.
• In section 8, we collect quantitative metrics of attacks that can exploit several threats and vulnerabilities. Then, we explore defense configurations with the highest impact on attacks.

The IoT domain comprises several different governance models, which are often incompatible, this leads to a situation where security is treated on a per-case and per-legislation basis, retrofitting solutions to existing designs, and this severely hampers portability, interoperability, and deployment. This motivates, first, adopting a Reference Model for the BRAIN-IoT domain in order to promote a common understanding and a common ground for IoT solutions. Second, solutions should describe the essential building blocks regarding functionality, development, deployment, and security schemes.

This document presents the updated reference architecture stemming from deliverable 2.5 and deliverable 2.2 versus requirements that rely on technologies supported by our BRAIN-IoT partners.

The main objective of work package 7 is to create awareness and adoption of the BRAIN-IoT project within the targeted communities defined by deliverables D7.3 & D7.1, i.e.: research communities, developer communities (Early adopters and Late adopters), solution makers, end-users and the general public.

This report documents the updated efforts and results of the project in terms of advertising and community engagement. It follows the dissemination strategy defined in D7.1 and the first version of the advertising, community engagement materials, and results available in D7.3.

In this document, a list of the press releases, articles, social media tools, and available contents will be presented, as well as a brief summary of the events in which the project has participated.

This document will present the different ideas composing the frameworks that the BRAIN-IoT consortium is considering for the integration and evaluation of separated results of all technical work packages. 

The technical evaluation Framework initially defined by Task 6.1 will be presented in the first sections by introducing our lab-scale Proof of Concepts. 

Then, our main concepts for user-centered evaluation will be introduced by highlighting the expectations of the end-user partners, and the way the BRAIN-IoT developments will support the operative work. The end-user related KPI’s will also be revised in this section. 

Finally, the test-site evaluation framework will be presented by describing the real demonstrators that are foreseen to be part of the project at this point. 

The present document is a deliverable of the BRAIN-IoT project, funded by the European Commission, under its Horizon 2020 Research and innovation program (H2020), reporting the results of the activities carried out by WP6 – Test, Demonstration and Evaluation. The main objective of the BRAIN-IoT project is to focus on complex scenarios, where populations of heterogeneous IoT systems cooperatively support actuation and control. In such a complex context, many initiatives fall into the temptation of developing new IoT platforms, protocols, models or tools aiming to deliver the ultimate solution that will solve all the IoT challenges and become ”The” reference IoT platform or standard. Instead, usually they result in the creation of “yet-another” IoT solution or standard. More specifically, the project revolves around two vision scenarios; Service Robotics and Critical Infrastructure Management. The scenarios outlined in the proposal are refined within the engineering efforts alongside the project, driven by WP2.

This deliverable defines the different steps, methods and tools required to verify and validate the architecture of the BRAIN-IoT project and its two related use cases. It also provides the timeline to indicate the achievements of these validations. Furthermore, it provides complementary KPIs associated with the expected outcomes from the BRAIN-IoT architecture concerning its main building blocks, the two site use cases and the tools.

The development activities are being performed in the WP3, WP4 and WP5 and the activities of verification, validation and evaluation will be reported in the deliverables 6.3, 6.4, 6.5 and 6.6 of WP6.

This deliverable includes 6 sections. Section 1 introduces the activities of WP6 and more precisely the activities performed in Task 6.1. It briefly describes the expectations of this deliverable. Section 2 presents the different steps to follow the development, verification and validation of the BRAIN-IoT System architecture and its corresponding use cases. Each step is associated with a Proof-of-Concept (PoC) that will be developed in order to demonstrate the main concepts proposed by the BRAIN-IoT project. At the end of Section 2, a PoCs implementation schedule is provided. Section 3 gives more details on the two use cases (Service Robotics and Critical Infrastructure Management) that will be implemented and demonstrated to validate the architecture and concepts developed in BRAIN-IoT. Section 4 proposes a verification and validation methodology, a test plan and a modelling framework, and its associated tools, to perform the BRAIN-IoT system validation. At the end of Section 4, a tool implementation schedule is provided. Section 5 provides a list of KPIs related to the expected outcomes coming from the different main elements constituting the BRAIN-IoT architecture, the Modelling Framework tools, and the two use cases. Section 6 concludes this work.

The present document is a deliverable of the BRAIN-IoT project, funded by the European Commission, under its Horizon 2020 Research and innovation program (H2020), reporting the results of the activities carried out by WP5 – End-to-end Security, Privacy and Trust Enablers. The work collected in this document has been compiled with a collaborative effort of all partners who actively participated in the Task 5.1 – Threat Modeling and Assessment. 

The first report on threat modeling and security assessment has been provided in deliverable D5.1 at M6. This document has reported on the initial threat modeling and preliminary security assessment of the BRAIN-IoT proposed scenarios and introduces the principles of the BRAIN-IoT security methodology based on known threats analysed by international initiatives undergoing in the EU and worldwide. Starting from the scenarios and architectural solutions defined by WP2, the involved partners performed an initial analysis considering intentional threats that may result in BRAIN-IoT services to be compromised or disrupted. 

This deliverable D5.4 is an updated and extended version of D5.1, where the partners refined the threats identified previously for the two use cases (“Critical Water Management Infrastructure” and “Service Robotics”) and completed several additional phases of the proposed security methodology. In particular, the risk assessment process has been extended to include the security objectives and the associated security requirements. The novel technical contributions with respect to the previous deliverable D5.2 are described in the following sections: 

• Sections 4.4 Security Objectives and 4.5 Security Requirements provide generic objectives and requirements relevant for the Brain-IoT methodology. 
• Sections 5.3 Security Objectives and 5.4 Security Requirements for the Critical Water Management Infrastructure. 
• Sections 6.3 Security Objectives and 6.4 Security Requirements for the Service Robotics. 

Finally, the work presented in this deliverable will be continued in the next iteration and updated in the deliverable D5.5, where the final results will be documented. 

This document is a deliverable of the BRAIN-IoT project, funded by the European Commission, under Horizon 2020 Research and Innovation Program (H2020). It belongs to WP5 – End-to-end Security, Privacy and Trust Enablers, under Task 5.3- Initial enabler for privacy awareness and control. 

Scope and goals 

The main scope of this task is to facilitate the adoption of privacy control policies in decentralized environments building upon goals set by current EU General Data Protection Regulation (GDPR) regulations in terms of privacy and security. More specifically, the goal of this task is to integrate privacy awareness and control in programmatic ways to: (i) increase awareness of users about which data is collected, where it is transmitted, by whom, etc.; (ii) provide controls to enable users to control such aspects, being at the same time aware of how such a decision affect the quality of the IoT service provided in BRAIN-IoT. In the context of privacy awareness and control, the primary objectives are the identification of the privacy risks and the associated technical requirements towards proposing privacy risk mitigation strategies to protect the individuals data (both private and corporate users) the BRAIN-IoT system. The activities performed by Task 5.3 are the following: 

• Study of the state-of-the-art in the context of privacy risk assessment and control; 
• Propose an approach for privacy impact assessment based on the guidelines from GDPR; 
• Initial privacy impact assessment of the BRAIN-IoT use cases; 
• Outline the components needed to integrate privacy policies within the Brain-IoT system. 

The proposed solution will be cross-platform, so to possibly support a wide number of IoT products deployed by corporate and private users, therefore empowering final users (both private and corporate) with the capability of deciding which combination of self-hosted or cloud-oriented IoT systems is most suitable to handle the personal data they generate and own – as well as with the ability to change the existing (or pre-set) configurations at any time. Deliverable D5.3 will be continuously updated and refined through an iterative process that will lead to the production of two additional deliverables; D5.7 Final enablers for Privacy awareness and control, solutions planned on M32 and D5.9 Guidelines for privacy compliance and control in IoT services models, solutions planned on M36. LINKS is in charge to coordinate these deliverables with contributions from CNRS, IM, STM-GNB, AIRBUS, EMALCSA, and Robotnik. 

This document reports the activities performed in Task 5.2. This task aims at designing and implementing an Authentication, Authorization and Accounting (AAA) layer in order to provide security and trust for the Brain-IoT system. 

A BRAIN-IoT environment is composed of a number of BRAIN-IoT Fabrics. These are in-turn composed of a number of BRAIN-IoT nodes (see the related document RD.1 in §1.2). A BRAIN-IoT environment may consist of arbitrary complex distributed interactions between dynamically deployed Smart Behaviours. These behaviours may migrate between runtime locations within each Fabric environment (see the related document RD.2 in §1.2). 

To be discovered, and to participate as a member of a Fabric, each BRAIN-IoT node must have the appropriate X509 certificates. Certificates and TLS are both good defenses against external Man-in-the-middle (MITM) attacks but are insufficient against internal MITM. So to guard against a Smart Behaviour erroneously (or maliciously) editing data for an event and sending them on, the project requires that each BRAIN-IoT message contains its own Authentication token. 

Finally, BRAIN-IoT must ensure that Smart Behaviours only interact at runtime in an expected manner. 

Scope 

Security is an extremely broad subject within computer science, and it can quickly become difficult to describe the complete set of security actions that apply to a software system. In this deliverable the scope of security is limited to the following considerations: 

• The registration of identity for users, devices and Smart Behaviours within the Brain-IoT system. 
• The authentication of users, devices and Smart Behaviours. 
• The validation of data integrity for messages passed through the Brain-IoT system. 
• Permission management for users, devices and Smart Behaviours, limiting the permitted actions and data interactions. 
• The runtime application of permissions to permit or deny access. 

This report presents the initial perspective of a potential business strategy around the BRAIN IoT repository / marketplace.

To assess this potential perspective the consortium has worked in three different, complementary pathways:

• A careful definition of the repository functional and technical requirements (section 2)
• An assessment of existing other examples of repository/marketplace from known, comparable European projects (COMPOSITION and Big IoT, presented in section 3).
• A review of the business approach of existing software marketplaces developed by various types of businesses and industries (telecom operators, cloud platforms, software repositories, application enablement platforms…). (section 4)

Through this cross-analysis, a first definition of the potential business requirements of a BRAIN IoT marketplace has been defined (section 2.2).

The main findings can be summed up as follow:

• The development of the marketplace would provide benefits to various stakeholders by bringing additional value to the technology platform, but the sustainability of the approach still needs to be assessed, especially if engagement of developers remains too limited.
• The value of a `Marketplace` is dictated by the shareability/re-usability of artefacts in the Marketplace in different and unrelated runtime contexts.
• Generic high-quality Edge Integration Components with assured pedigree/provenance will be of interest to a large community. Whereas, Sophisticated AI/ML-based behaviours trained for specific roles in specific environments may have extremely high business value in the target environment, but limited applicability elsewhere. Here, it is the generic modelling tools which allowed the simple creation of context specific AI/ML-based behaviours that will be of interest to the wider community.
• A Brain IoT marketplace would have to first attract a critical mass of contributors that can build potential behaviours. Thus, a focus on the modelling tool community, smart behaviour developers, should be considered. Ideally the marketplace should also initially be populated with simple behaviours that can be composed easily into more complex ones to facilitate adoption. In a second time the marketplace would have to focus on IoT users, deployment operators and integrators that would need the behaviour developed by the modelling tool community.
• To compensate the marketplace costs and build up the marketplace community, a business model using a subscription model is considered as a more realistic short-term option than a traditional model that takes a share of marketplace exchanges. This is especially the case if the marketplace focuses at first on small atomic behaviours to be assembled. Building up on these initial findings, further discussions are planned as part of the project work on exploitation in the M18-M36 activity period to identify if such a business dynamics can be integrated in the exploitation plan of some of the project partners

Building a framework for deployment and operation of Internet of Things (IoT) service orchestration is a complex task since it needs to address two major challenges: a strong availability and an abstraction layer to deal with heterogeneous devices. In order to tackle the challenge of availability, the Brain IoT project has chosen to rely on Paremus service Fabric, which provides distribution, monitoring, and automatic recovery in case of node failure. Regarding the interaction with heterogeneous devices, the Eclipse sensiNact middleware2 has been chosen for its capability to interact with a wide variety of equipment and protocols, as well as its extensibility mechanisms. The purpose of deliverable 4.2 is to provide a platform using the best of those two enablers, thanks to evolutions of the two code-bases in order to integrate them gracefully. For this reason, deliverable 4.2 is provided as source code.

This deliverable is a software release type of deliverable. The goal of the present notice is to help technical and non-technical stakeholders to understand the purpose of the source code which has been delivered, and to provide useful links to retrieve, build and run the platform.

The software stack is still under construction. It will be delivered in its final version at the end of the project, as part of deliverable 4.5 entitled “Final Deployment and operation enablers”

This document is a quick start guide to the BRAIN-IoT modelling framework implementation, i.e., a modelling tool hereafter named “BRAIN-IoT Designer”. The modelling tool is composed of the Papyrus IoT-ML modeller, and its eco-system od Model-Driven Engineering (MDE) tools for purposes such as model checking, code and metadata generation, and Models@runtime features. In this first version of BRAIN-IoT Designer, we shall expose its IoT-ML modeller and code generation functionalities through BIP. More information on the underlying modelling languages can be found in D3.1.

BRAIN-IoT Designer is an Eclipse Rich Client Platform (RCP) that has been built with all the required features packaged as one tool. In this first deliverable, BRAIN-IoT Designer is composed of the following features:

• Papyrus UML
• Papyrus SysML
• Papyrus MARTE
• Papyrus IoT-ML

This document shows how to download, install, launch, and create a first model with BRAIN-IoT Designer. Afterward we show how the model is represented in the BIP modelling and analysis framework for code generation. Finally, this document shows some ongoing development works for the second release of the tool, to be detailed in D3.8. These MDE tools in development exploit the model for metadata generation and add Models@runtime features, i.e., monitoring and quick post-deployment behavior prototyping through models.

This document describes the research and approaches identified by task 3.3 `Initial Enablers for dynamic distribution of IoT behaviour`: this activity delivering BRAIN-IoT’s generic nonfunctional runtime mechanisms needed to support the dynamic deployment and orchestration of BRAIN-IoT’s Smart Behaviours.

Why this is an essential characteristic of, and a unique differentiator for, BRAIN-IoT, is first explained.

It is important to note that this document is not concerned with the specifics of Smart Behaviours needed for particular Use Cases specified in D2.4; nor how Smart Behaviours should be modelled; these concerns addressed by the D3.1, D3.2 & D3.4 deliverables in WP3.

This document is a deliverable of the BRAIN-IoT project, funded by the European Commission, under the Horizon 2020 Research and Innovation Program (H2020). It belongs to WP3 – IoT Framework for smart dynamic behavior, under Task 3.2 – AI and ML features for smart behavior and actuation.

The main role of this task is to design and implement the features that deal with Artificial Intelligence (AI) and Machine Learning (ML) techniques in Smart Behaviours as they are being defined in BRAIN-IoT.

The two main sets of use-case real-world scenarios, service robotics, and critical infrastructure monitoring, will dictate the specific features where some applied intelligence (analysis, prediction, collaborative context base behavior) is needed to solve the problems.

However, it is the main goal of this document to generalize the solutions available for this kind of intelligence. Research in classic and state-of-the-art AI and ML methods will be elaborated on in order to design for a set of abstractions that can be used under a generalized approach. In such a way that this proposed design:

• Solves the use-case scenarios.
• Covers a wide enough range of problems in the context of Smart Behaviours in distributed environments.
• Is well defined in terms of the ongoing IoT-ML definition elements.
• Explore the Capabilities that would be needed to advertise regarding Smart Behaviours requirements.
• Outline which Smart Behaviours would benefit from the exogenous coordination approach advocated and developed in BIP.
• Those elements can be modelled and managed within the Brain-IoT developed modelling tools.

The IoT domain comprises several different governance models, which are often incompatible, this leads to a situation where security is treated on a per-case and per-legislation basis, retrofitting solutions to existing designs, and this severely hampers portability, interoperability, and deployment. In our vision of the Internet of Things, the interoperability of solutions at the communication level, as well as at the service level, has to be ensured across various platforms. This motivates, first, adopting a Reference Model for the BRAIN-IoT domain in order to promote a common understanding and a common ground for IoT solutions. Second, solutions should be supported by BRAIN-IoT Reference Architecture that describes essential building blocks regarding functionality, deployment, and security. The reference architecture proposed in this document relies on the technology supported by our BRAIN-IoT partners such as PAREMUS, CEA, and, Airbus.

The present document is a deliverable of the BRAIN-IoT project, funded by the European Commission, under its Horizon 2020 Research and innovation program (H2020), reporting the results of the activities carried out by WP2 – Requirements and Architecture Engineering. The main objective of the BRAIN-IoT project is to focus on complex scenarios, where populations of heterogeneous IoT systems cooperatively support actuation and control. In such a complex context, many initiatives fall into the temptation of developing new IoT platforms, protocols, models, or tools aiming to deliver the ultimate solution that will solve all the IoT challenges and become ”the” reference IoT platform or standard. Instead, usually, they result in the creation of a “yet-another” IoT solution or standard. More specifically, the project revolves around two vision scenarios; Service Robotics and Critical Infrastructure Management.

Deliverable D2.1 has reported on 1) the identification of the purpose and workflow of the workbench, 2) an initial set of stakeholders and their categorization, 3) the communication flow between them, and lastly 4) an initial description and analysis of use cases.

In the current deliverable D2.4, we refine the initial version of the use cases specified in D2.1 and give an updated vision towards which the project will evolve. The descriptions presented here will be used for interproject communication in order to identify development scenarios and help to fertilize the process of thinking for the design of future systems. Besides the aspects regarding development, the vision scenarios are used as understandable stories to externally communicate the project’s aims and inform the audience what kind of applications can be designed with the framework developed by BRAIN-IoT, the actual outcome of the project.

Finally, deliverable D2.4 will be further extended and refined in the next iteration and updated in the deliverable D2.6, where the final results will be documented.

Initial version of the vision, application scenarios and use cases in which the results of the BRAIN-IoT project will be demonstrated. D2.1 work has been conducted using domain analysis and brainstorming sessions involving relevant stakeholders and use case analyses. This document reports on the iterative process of ideation which resulted in the definition of: 1) the workflow of the workbench, 2) an initial set of relevant stakeholders, 3) the communication flow between them, and 4) the initial set of use cases.