D3.1 Design Specification of IPSE (preliminary design) · 2020-05-15 · programme und This project...

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Grant Agreement No 780075.

Cognitive Heterogeneous Architecture for Industrial IoT

D3.1 Design Specification of

IPSE (preliminary design)

Document Summary Information

Grant Agreement No 780075 Acronym CHARIOT

Full Title Cognitive Heterogeneous Architecture for Industrial IoT

Start Date 01/04/2018 Duration 36 months

Project URL www.chariotproject.eu

Deliverable D3.1 Design Specification of IPSE - Version 1 (preliminary design)

Work Package WP3 – IoT Privacy, Security and Safety Shielding and Supervision Engine (IPSE)

Contractual due date M12 31/12/2018 Actual submission date

M12 21/12/2018

Nature R Dissemination Level CO

Lead Beneficiary IBM

Responsible Author Bora Caglayan

Contributions from Bora Caglayan, Mingming Liu (IBM), Christos Skoufis (EBOS), Christina Stratigaki (VLTN), Andrea Battaglia, Mario Villani (ASP), Konstantinos Loupos (ILS), Bill Karakostas (VLTN)

Ref. Ares(2019)4020814 - 25/06/2019

http://www.chariotproject.eu/

D3.1 – Design Specification of IPSE (preliminary design)

© CHARIOT, 2018 Page | 2

Revision history (including peer reviewing & quality control) Version Issue Date % Complete1 Changes Contributor(s)

V0.1 15/05/2018 10% Initial Deliverable Structure Bora Caglayan (IBM)

V0.2 15/06/2018 15% Initial Content Bora Caglayan (IBM)

V0.3 15/07/2018 40% Updated Content Bora Caglayan (IBM)

V0.4 12/09/2018 70% Updated Content Bora Caglayan (IBM) Mingming Liu (IBM) Christos Skoufis (EBOS) Christina Stratigaki (CLMS) Andrea Battaglia (ASP) Mario Villani (ASP)

V0.5 16/11/2018 80% Updated Content Bora Caglayan (IBM) Mingming Liu (IBM) Christos Skoufis (EBOS) Christina Stratigaki (CLMS) Andrea Battaglia (ASP) Mario Villani (ASP)

V0.6 26/11/2018 100% Updated content Bora Caglayan (IBM) Mingming Liu (IBM) Christos Skoufis (EBOS) Christina Stratigaki (CLMS) Andrea Battaglia (ASP) Mario Villani (ASP)

V0.7 03/12/2018 100% Quality Check Christos Skoufis (EBOS) Konstantinos Loupos (ILS) Bill Karakostas (VLTN)

V0.8 07/12/2018 100% Quality Assurance Revisions Bora Caglayan (IBM) Mingming Liu (IBM) Christos Skoufis (EBOS) Christina Stratigaki (CLMS) Andrea Battaglia (ASP) Mario Villani (ASP)

V1.0 21/12/2018 100% Final version Bora Caglayan (IBM) Mingming Liu (IBM)

1 According to CHARIOT’s Quality Assurance Process:

4 months before Deliverable’s Due Date: 70% should be complete

3 months before Deliverable’s Due Date: 90% should be complete

2 months before Deliverable’s Due Date: close to 100%. At this stage it sent for review by 2 peer reviewers

1 month before Deliverables Due Date Month-1: All required changes by Peer Reviewers have been applied, and goes for

review by the Quality Manager



Disclaimer

The content of the publication herein is the sole responsibility of the publishers and it does not necessarily represent the views expressed by the European Commission or its services. While the information contained in the documents is believed to be accurate, the authors(s) or any other participant in the CHARIOT consortium make no warranty of any kind with regard to this material including, but not limited to the implied warranties of merchantability and fitness for a particular purpose. Neither the CHARIOT Consortium nor any of its members, their officers, employees or agents shall be responsible or liable in negligence or otherwise howsoever in respect of any inaccuracy or omission herein. Without derogating from the generality of the foregoing neither the CHARIOT Consortium nor any of its members, their officers, employees or agents shall be liable for any direct or indirect or consequential loss or damage caused by or arising from any information advice or inaccuracy or omission herein.

Copyright message

© CHARIOT Consortium, 2018-2020. This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both. Reproduction is authorised provided the source is acknowledged.



Table of Contents 1 Executive Summary ........................................................................................................................... 7

2 Introduction ....................................................................................................................................... 8

2.1 Mapping CHARIOT Outputs ........................................................................................................ 8

2.2 Deliverable Overview and Report Structure .............................................................................. 9

2.3 IoT Privacy, Security and Safety Supervision Engine (IPSE) in CHARIOT Platform ................... 10

2.4 IPSE Design Approach ............................................................................................................. 11

3 Requirements Summary and Technical Components ..................................................................... 12

4 Safety Supervision Engine ............................................................................................................... 15

4.1 Key Definitions and Users ........................................................................................................ 16

4.2 Functional Design Requirements ............................................................................................. 16

4.3 Non-Functional Design Requirements ..................................................................................... 18

4.4 Technical Design Specifications ................................................................................................ 18

4.5 Interface Definitions ................................................................................................................. 24

4.6 Use Cases .................................................................................................................................. 25

4.7 Scenario Implementations ....................................................................................................... 25

4.8 Current State Summary / Development Plan .......................................................................... 25

5 Privacy Engine .................................................................................................................................. 27

5.1 Key Definitions ......................................................................................................................... 27




5.4.1 PRIVACY SPEC 1: Privacy engine checks ............................................................................ 30

5.4.2 PRIVACY SPEC 2: Defining ACL (Access Control Language) ............................................... 31


5.6 Use Cases .................................................................................................................................. 32



6 Security Engine ................................................................................................................................ 34

6.1 Key Definitions ......................................................................................................................... 34





6.6 Use Cases .................................................................................................................................. 37



7 Dashboard Design ............................................................................................................................ 40

7.1 Scope ........................................................................................................................................ 40

7.2 Dashboard Concept and Benefits ............................................................................................. 40



7.5 Technical Design Specifications and Interface Definitions ...................................................... 45

7.6 Current State Summary/ Development Plan ........................................................................... 51

8 Conclusions ...................................................................................................................................... 52



9 References ....................................................................................................................................... 53

Annex 1: IoTL Grammar .......................................................................................................................... 55

Annex 2: Deployment Plan for the IPSE to the Living Labs ..................................................................... 57

Annex 3: IPSE Dashboard Initial Designs for all LLs ................................................................................ 58

List of Figures Figure 1: An iteration of CHARIOT design process. The requirements are gathered and validated on the three living labs of the project. ........................................................................................................ 11

Figure 2: CHARIOT Platform High Level Architecture adapted from Deliverable 2.1............................. 12

Figure 3: Main Elements of the CHARIOT Safety Supervision Engine .................................................... 20

Figure 4: The schematic diagram of the data flow monitoring and detection system .......................... 22

Figure 5: The state of the system is shared between cloud and local components using IoTL. ............ 24

Figure 6: Privacy Engine architecture design .......................................................................................... 29

Figure 7: A taxonomy of checking types ................................................................................................. 30

Figure 8: How it applies cipher filtering rules ......................................................................................... 31

Figure 9: How it applies topology related filtering rules ........................................................................ 31

Figure 10 Privacy engine visual representation ...................................................................................... 33

Figure 11: Security Engine workflow process ......................................................................................... 36

Figure 12: Dashboard Widget Showing Sensor Events ........................................................................... 49

Figure 13: Interactive Widgets ................................................................................................................ 50

Figure 14 CHARIOT IPSE Deployment View ............................................................................................ 57

Figure 15 Building Monitoring Dashboard (IBM) .................................................................................... 58

Figure 16 Room Monitoring Dashboard (AIA) ........................................................................................ 58

Figure 17 IoT Device Monitoring Dashboard (TRIT) ................................................................................ 59

List of Tables Table 1: Adherence to CHARIOT’s GA Deliverable & Tasks Descriptions ................................................. 8



Glossary of terms and abbreviations used

Abbreviation / Term Description

BLE Bluetooth Low Energy

BPMN Business Process Model and Notation

CPU Central Processing Unit

DoA Description of Actions

EC European Commission

F Functional Requirement

F2F Face to Face (meeting)

GA Grant Agreement

GDPR General Data Protection Regulation

GPU Graphical Processing Unit

IPSE IoT Privacy, Security and Safety Supervision Engine

IoT Internet of Things

LL Living Lab

M Month

MQTT Machine-to-machine (M2M)/"Internet of Things" connectivity protocol

MS Milestone

NF Non-functional requirement

PKI Private Key Infrastructure

PoC Proof of Concept

POSIX Portable Operating System Interface

PR Peer Review

QA Quality Assurance

QM Quality Manager

QoS Quality of Service

SoC System on a chip

Spec Technical Specification

SSE Safety Supervision Engine

V Version

WP Work Package



1 Executive Summary

CHARIOT Project envisions a holistic approach to the problems related to security, safety supervision and privacy

in industrial IoT (Internet of Things) deployments. For this goal CHARIOT IPSE (IoT Privacy Safety Supervision

Privacy and Security Engine) offers several cognitive capabilities on different parts of the CHARIOT architecture

to handle these issues. CHARIOT IPSE is designed by considering the requirements of the three living labs in the

CHARIOT Consortium.

This document reports the first phase of the design specifications of CHARIOT. For all the technical components

of IPSE the functional and non-functional requirements are reported. Functional requirements report the main

functionalities of the engines and non-functional requirements highlight the quality and operation attributes of

the system. The requirements were used by the Work Package 3 Partners to generate the high-level technical

specifications of the component. On top of that, we present the interface definitions and highlight several use

cases and scenarios. We conclude each technical section with an overall summary of the current work status and

future tasks related to the technical component.

CHARIOT IPSE functionality can be listed briefly as follows: CHARIOT Safety Supervision Engine is used to observe

and share the system topology across Fog computation components and enforce rule based or machine learning

based safety supervision policies across the industrial IoT setup. On top of this, safety supervision engine can be

used to optimize the system signal rate under normal and emergency conditions. CHARIOT Privacy Engine

ensures privacy by design by handling the encryption policies for data within CHARIOT. CHARIOT Security Engine

processes firmware binary updates and identifies the security vulnerabilities of the firmware. Finally CHARIOT

Dashboard integrates with the CHARIOT engines to provide reporting, configuration and visualization

functionality for the engines.

The purpose of this deliverable is sharing the draft version of the CHARIOT IPSE design as the first version of

CHARIOT D3.1. In this context, we share our output to align with work package 2 and work package 4 of CHARIOT

Project, coordinate the partners’ effort on IPSE and to guide further development and innovation goals related

to IPSE. In the next iteration of the project, we aim to deploy the IPSE to the three living labs by using this

document as a guideline. The document involves contributions from WP 3 and in particular WP 3 task leaders of

the CHARIOT Project.



2 Introduction Goal of this section is to provide a brief outline of the objectives of the specific CHARIOT Deliverable, how are

those aligned and relevant with the overall project, and what was the approach followed in order to achieve

them.

2.1 Mapping CHARIOT Outputs The purpose of this section is to map CHARIOT’s Grant Agreement commitments, both within the formal

Deliverable and Task description, against the project’s respective outputs and work performed.

Table 1: Adherence to CHARIOT’s GA Deliverable & Tasks Descriptions

CHARIOT GA Component

Title

CHARIOT GA Component Outline Respective Document Chapter(s)

Justification

DELIVERABLE

D3.1 Design specification of IPSE

This deliverable will strive to consider and integrate as necessary the technical components and design requirements as provided by all partners contributing to the technical design specifications of the IPSE as part of WP3. It will also consider the use case scenario requirements and reflect them in the technical design specifications and topology for the IPSE prototype development to facilitate a “bottom up/top down” parallel approach to the iterative design process. Two versions of each IPSE components will be developed: One version (v1) by M12 and an upgraded version (v2) after the technology has been evaluated in the first phase of Living Labs by M26.

Sections 3-6

• The document contains the initial requirements and the specs of all the engines and dashboard.

• The material in the document has been evaluated in two face to face meetings and several online meetings with the living labs to ensure alignment. Bottom up/ top down approach has been followed to share work on every iteration with the partners.

TASKS

Task 3.1

The objective of this task is to define and evolve design specifications for the IPSE within the constructs of a methodological and iterative framework to enable the deployment of an IPSE runtime environment that will comprise the Privacy, Safety and Security engines. The design task will also consider and incorporate the IPSE interconnectivity and interoperability

Sections 3-6

• In this deliverable the initial design specification of the three engines (privacy, safety and security engines) as well as the CHARIOT dashboard is shared.

• The IPSE components with high level interface with the CHARIOT components have been defined. These



factors, such as open standards API interfaces, relevant to the supporting Open IoT Cloud Platform and the Fog networks of IoT devices, sensors and gateways. The design process will be driven by the innovative objective of developing an IPSE that can seamlessly interface with any IoT platform, gateway or IoT device in a plug and play way, by using specifically engineered software adaptors designed for ease of integration, and by leveraging the API’s exposed by the IoT Platforms and gateways. The IPSE components and constituent engines will operate in unison to monitor the cyber-physical ecosystem that is compromised of the IoT gateways and devices whilst incorporating the highest levels of security and privacy via the applied combination of PKI, Blockchain, Firmware Integrity and applied security and safety policies.

definitions will be refined in the second version of this deliverable.

2.2 Deliverable Overview and Report Structure

This document reports the technical specifications and requirements of the privacy engine, security engine and

the safety supervision engine that are developed as part of Work Package 3 of CHARIOT Project. This report is

sent as the draft version of CHARIOT Deliverable 3.1 for Month 12. In Section 1, we provide an executive

summary of the deliverable. In Section 2, we report the relation of the deliverable with CHARIOT Project and

summarize the key functionalities of the CHARIOT IPSE. In Section 3 to 5, we report the requirements,

specifications, potential use cases, interface definitions, use case definitions, scenario implementations and

development status for privacy, security and safety supervision engines respectively. In Section 6, we report the

scope, concept, requirements, spec and development status for CHARIOT Dashboard. Finally, in Section 7, we

conclude with some final remarks and discussion of the future work.



2.3 IoT Privacy, Security and Safety Supervision Engine (IPSE) in CHARIOT Platform

This chapter introduces the technical components and design requirements as provided by all partners

contributing to the technical design specifications of the IPSE as part of WP3. CHARIOT project structure creates

a relation with the three living labs and establishes a frequent feedback opportunity. The consortium iterated

the requirements elicitation process three times between Month 4 and Month 11 of the Project. The initial

requirements and the scenarios for the three engines and CHARIOT Dashboard have been evaluated in two face

to face meetings. In Dublin IBM Living Lab meetings on April 2018 IBM Living Lab provided the feedback for the

three engines and the dashboard. IPSE provides the core cognitive capabilities in the CHARIOT platform.

Industrial IoT applications in various domains including large office sites and transport infrastructure are getting

more complex with multiple computer based management systems handling the work load. These systems can

generate data that can be used to introduce cognitive capability in many critical tasks. Handling the concerns

related to privacy and security is important to enable any complex functionality [9] [10] [11]. For this reason,

CHARIOT IPSE shows a solution that links the privacy, security and safety supervision functionality in a novel way.

In summary, safety supervision engine will propose a mechanism to process and handle the signals generated

by sensors for safety related scenarios. Lately, IoT deployments are moving away from an approach of offloading

the cognitive capabilities to one central approach towards distributed intelligence with multiple nodes handling

the cognitive capabilities of the IoT deployment [8] [9]. The implementation of machine learning based policies

and propagating the changes on the systems require edge cloud orchestration done by the system [17] [18]. To

align with the CHARIOT objectives, we plan a safety supervision engine that can run on multiple Fog nodes of an

IoT setup. In addition safety supervision engine provides collaborative optimization capability to dynamically

change priorities of sensor priorities based on the operation mode of the system [21]. By doing dynamic

prioritization of signal transfer to cloud, the scalability issue which is seen as one of the major research

challenges for industrial IoT [14].

Privacy engine will use blockchain to avoid privacy breaches in the IoT network. Privacy engine encrypts the data

on the southbound dispatcher by using the keys distributed on the blockchain network. It keeps the policies and

the access rights for particular sensitive data in the policy repository and enforces the access right for CHARIOT.

Privacy engine is particularly suitable for large industrial IoT deployment environments where multiple

contractors may access different data streams [15] [16].

Security engine checks the firmware updates and related changes in network and network transmission to make

sure that the data shared in the system is bona-fide with no security breaches [12] [13]. We will use machine

learning where historical firmware binary data will be used to identify updates with security vulnerabilities and

inform the operator.



CHARIOT dashboard provides a modern interface to an IoT deployment and the capabilities of the CHARIOT

engines for the operator. We follow modern web development practices to create an interface accessible from

multiple devices. It also provides an API so that dynamic widgets and panels can be installed for particular use

case.

By integrating the engines and the dashboard through the interfaces that are explained in Sections 3 to 6, a

problem handled by one engine can trigger other actions in CHARIOT IPSE. For example, after a security alert is

found after firmware inspection of the security engine, various safety supervision protocols can be actuated by

the safety supervision engine. The implementations of the components explained in this document will be a part

of D3.2, D3.3, D3.4 and D3.5 in CHARIOT project.

2.4 IPSE Design Approach

CHARIOT being a research project with involvement from multiple partners distributed throughout Europe is

suitable for a more iterative approach. The design of the IPSE follows an iterative process to ensure the alignment

between partners in various stages. Initially, the design document components are proposed by the task leaders

in Work package 3 as described in the first internal draft version of the design deliverable D3.1. We plan to

continue this roughly quarterly requirements validation throughout the project until the submission date.

Afterwards, the initial design of the security, safety supervision, privacy engines and the CHARIOT dashboard

were implemented and deployed to the living lab environments. The feedback received from the living labs is

used to iterate the CHARIOT IPSE design document that will be submitted on month 25 of the project. The

feedback from the partners are collected in the meeting minutes and internally evaluated to create the next

version of the deliverable.

Figure 1: An iteration of CHARIOT design process. The requirements are gathered and validated on the three living labs of the project.



3 Requirements Summary and Technical Components IPSE is one of the core elements of the CHARIOT architecture that will be used for intelligent IoT management

for safety, security and privacy of IoT systems. CHARIOT core functionality exists between a southbound

dispatcher which handles the traffic from gateways attached to the sensors and a northbound dispatcher which

handles the traffic to the industrial gateways that are connected to the management systems and industrial

gateways. IPSE runs within the CHARIOT Platform between the southbound dispatcher that handles sensor data

streams from the IoT Gateway and northbound dispatcher which is connected to the industrial gateways that

are handling the actuation of the industrial management systems such as building manager or a train controller

as highlighted in Figure 2.

Figure 2: CHARIOT Platform High Level Architecture adapted from Deliverable 2.1

The detailed functional and non-functional requirements of the safety supervision, privacy and security engines

and CHARIOT dashboard are shared in Section 4 to Section 7 for each component individually. In summary the

main functionality requirements of the engines are listed as follows. The core requirement listed below

summarizes the main functionality of the engines and are further elaborated in the respective sections:



Safety Supervision Engine

The main functionality requirement of the Safety Supervision Engine are listed as follows:

• Define and assess the topology of an IoT system and share across multiple Fog nodes in CHARIOT as

defined in CHARIOT architecture (Deliverable 2.1) through a domain specific language [19].

• Enforce machine learning rules on the edge by transferring models across devices.

• Optimize the signal rate through collaborative optimization techniques during normal and abnormal

operation of the industrial IoT deployment.

• Propagate the unsafe state detections to the management systems.

The detailed capability of the security engine is explained further in Section 4.

Security Engine

The main functionality requirement of the Security Engine are listed as follows:

• Security engine checks the security binary updates for security flaws. The security engine functionality

will run during the propagation of firmware during deploy time and the security engine.

• Security engine signs the firmware update using CHARIOT Blockchain implementation.


Privacy Engine

The main functionality requirement of the Privacy Engine is as follows:

• Encrypt the data on the southbound broker using PKI managed by CHARIOT blockchain implementation

in a near-real time manner. In our context, near real time refers to the time delay introduced, by

automated data processing or network transmission, between the occurrence of an event and the use

of the processed data.

• Ensure privacy of data by design by keeping the access rights of all the data handler modules of CHARIOT.


CHARIOT Dashboard

The main functionality requirement of the Dashboard is as follows:

• Provide a multi device interface to the core capabilities of CHARIOT engine by accessing the API provided

by the engine and visually set the preferences of the engines.

• Provide visualization options for optimized for the three living labs optimized for the industrial IoT

system operators.



• Present time series from the sensors visually and act as a near-real time interface for the operators in

the living lab.

In the rest of the document we report the detailed functional requirements, non-functional requirements and

specifications of the IPSE components. The functional requirements are numbered using the following

convention:

• Functional Requirements: <COMPONENT_NAME>_F#

• Non-Functional Requirements: <COMPONENT_NAME>_NF#

• Specifications: <COMPONENT_NAME>_SPEC#



4 Safety Supervision Engine In this section, we summarize the safety supervision engine. Safety supervision engine keeps the state of an

industrial IoT setup and shares it across components of a Fog network as its basic feature. On top of this basic

feature, multiple machine learning or rule-based models can be enforced on multiple nodes of the system to

detect anomalies and other safety hazards in an industrial IoT setup. The last functionality of the CHARIOT safety

supervision engine is regulating the data transfer rate in the case of an abnormal operation of the system during

a safety hazard such as a natural disaster.

CHARIOT safety supervision aims to provide safety functionality even when the network is partially disables. This

requires distributing and replicating some cognitive functionality in the Fog network. For this aim CHARIOT

provides a state definition language (IoTL) to define the state of the relevant industrial IoT setup and a web server

that listens to state transfers from relevant nodes in the Fog network. In one sense, this state sharing protocol

acts as the application level communication standard for the safety supervision engine. In addition, CHARIOT

enables the sharing a machine learning model across the network so that enforcement can be done on any

computation node in the Fog dynamically. This core innovation creates an adaptive framework for dynamically

respond to any safety supervision scenario in an industrial IoT deployment including the three living labs of

CHARIOT.

The last core functionality of the IoT safety supervision engine is the dynamic regulation of the sensor signal

transmission rates during abnormal operation. In an adaptive Internet of Things (IoT) environment, physical

entities, e.g. sensors, vehicles, machines, having sensing, computing and communication capabilities should be

operated in a plug-and-play manner taking account of various resource constraints. This implies that when an

individual device plugs into the system it should automatically get its required resources (e.g. bandwidth,

storage) for different functionalities, and release them back to the system when not in use. Generally speaking,

resources allocated to each device should change dynamically to reflect the overall availability of resources

provided by the system as well as the utilization of resources from other devices in real-time.

In a typical industrial IoT setup, data flows of IoT devices are originally generated by sensors, and these raw data

are usually offloaded to the Cloud/Fog nodes, through gateways, for further storage, e.g. Cloudant DB2,

processing and analysis. Depending on the amount of data transmitted to the Cloud, the knowledge contained

in such a dataset can also be different. This can be understood particularly from a model training or knowledge

mining point of view, where one can typically expect to gain more insights from data sources with larger

dimensions and size. However, in practice, sensors cannot offload as much as they wish to the Cloud especially

in a resource-constrained environment, for instance in a common scenario where the Cloud can only allow a

2 https://www.ibm.com/uk-en/marketplace/database-management



fixed number of files uploaded at every fixed time interval. In this context, it becomes more important to

prioritize the rate of data flow given their level of importance.

In a safety-sensitive scenario, different types of IoT devices, e.g. sensors, can be classified into different

categories. In the simplest set-up, sensors can be classified as either by safety-aware or non- safety -aware. In

general, this concept can also be extended to include many other subcategories which totally depends on the

objectives of applications. Mathematically, characteristics of the safety-awareness of each device can be simply

modelled by a utility function parametrized by weights. A candidate function in this example could be logarithmic

function such as log(x) which gives rise to proportional fairness across devices in respect of weight factors. In

such a way, sensors with larger weight factors can expect to transmit at higher rates, thus presenting more

awareness to the system operator (less delay) and bringing more insights to data analysts (large datasets).

4.1 Key Definitions and Users

We categorize the users who will use the main functionalities in the system. We identify three categories of users

for the safety supervision engine as follows:

1. Operator: Person responsible with day to day safe operation of the site. An operator examines the real

time alerts and generated reports, acts on alerts, works with IT expert in modifying the safety scenarios

by acting as a domain expert. Operator interacts with the safety supervision engine mainly through the

graphical user interface.

2. IT Expert: Person who is maintaining the safety engine. Main goal of the IT expert is ensuring high

availability of the safety supervision engine on multiple nodes. The expert interacts with components

directly and checks the availability. In case, there is a problem in data flow the expert debugs the issue

directly on the components.

3. Analyst: Person who is responsible for generation of reports from raw data. Analyst works with operator

to generate reports and does more advanced analytics to mine the data further. Analysts interacts with

the safety supervision system through API and IoTL domain specific language. The main role of the

analyst is experimenting on new capabilities and extending/enhancing the safety supervision capabilities

by plugging novel machine learning models.

4.2 Functional Design Requirements

The functional requirements of the safety supervision engine are listed as follows:



SAFETY F1. An industrial IoT setup is defined as zones, gateways, sensors which have various types of

relations between them. These relations are dependencies and correlations. On top of the definitions

the plugged machine learning models and enforcements are defined.

SAFETY F2. Operator should be able to see the active rules and topology of the system. This represents a

digital twin of an active system. We define system state as the set of definitions, dependencies, plugged

models and active enforcements in an IoT setup. An IoT setup may have multiple zones, gateways and

sensors. Safety supervision engine provides a domain specific language to define the state of the system.

Data flow is controlled separately.

SAFETY F3. IT expert should be able to debug the potential communication problems. The system should

indicate the problems through a WebSocket API that can be connected by third party diagnostics tools.

SAFETY F4. System should give warnings for the management systems that are responsible with actuation

in case of security alerts. Actuation is not part of the safety supervision system. However, an API should

be provided for the actuation systems employed by the system.

SAFETY F5. The enforced rules or machine learning models should be transferrable to different nodes in the

IoT network securely. For example, an enforced rule for a subcomponent should be transferrable to

another component in the node.

SAFETY F6. Machine learning models should be trained using the Cloud historical dataset. The models are

trained on a central node and the trained model with weights and other details are shared as an object

with the local nodes.

SAFETY F7. Historical dataset will be kept on Cloud and it should be searchable for audit and reporting

purposes. It should either provide an API by the cloud service or CHARIOT safety system for the IT

experts.

SAFETY F8. The safety supervision system will interface with rest of CHARIOT using the APIs. The most

important API is between the safety supervision API and the dashboard.

SAFETY F9. The system should auto correct inconsistencies that might be created by the nodes doing change

of state on edge nodes. For example, a state is sent by another node that violates the local

representation, the system should auto correct the inconsistency.

SAFETY F10. The operator will see the active enforcements and the system state using an indoor map as the

user interface. The indoor maps will be associated with the zones of the system.



4.3 Non-Functional Design Requirements

SAFETY NF1. Safety supervision engine should not have a single point of failure. For example, when there is

no cloud connection the system should not go down completely. The independent systems should be

able to enforce rules.

SAFETY NF2. The safety supervision system should run on any POSIX compatible system with at least the

following specs or equivalent. The specs are based on Raspberry Pi which is easy to access for

demonstration setups. The gateway used for the project (Panthora) also has similar specifications:

o SoC (System on a Chip): Broadcom BCM2837

o CPU: 1.2 GHZ quad-core ARM Cortex A53 (ARMv8 Instruction Set)

o GPU (Graphical Processing Unit): Broadcom VideoCore IV @ 400 MHz

o Memory: 1 GB LPDDR2-900 SDRAM

SAFETY NF3. The safety supervision engine will be a web application with a REST API that will be used for

sending and receiving state and the relevant active enforcements through IoTL. The external interface will

connect to CHARIOT dashboard to create a user-friendly UI for configuring the system.

SAFETY NF4. Safety supervision engine should interoperate with the CHARIOT dashboard. The API should

provide a geospatial representation of the system, an interface for IoTL commands and other UI for all the

functionalities provided by the safety supervision engine.

4.4 Technical Design Specifications

SAFETY SPEC 1. CHARIOT safety supervision runtime runs on any of the Fog nodes, gateways (running

Linux) and central cloud nodes as a web server using Python3 Flask4. The application runs on any low

computational capability device (Raspberry Pi 3b 5or better). The goal is sharing only relevant states with

more local nodes to avoid security problems and synchronizing state automatically. This is achieved by

communicating the state of the system through a domain specific language between all the nodes

automatically. Shared state data is persisted on every node in a local database.

SAFETY SPEC 2. The data streaming loop is separate and data streaming is controlled for critical and non-

critical sensors by the data streamer component. Depending on the requirements of the safety scenario,

data stream can be cached locally to enable the operation of a machine learning module in the system

such as anomaly detectors.

3 https://www.python.org/ 4 http://flask.pocoo.org/ 5 https://www.raspberrypi.org/



SAFETY SPEC 3. In order to investigate the dynamic behaviours of many IoT devices in any practical

scenarios, it is essential to enable the fundamental capabilities of emulating multiply sensors/devices

connected to the same platform. To this end, safety supervision engine will not only focus on any physical

entities, e.g. raspberry pi, but also include many other types of plug-in IoT devices which may become

available in the near future. By doing this, a system operator can gain better understanding of the nominal

behaviours of each device in different scenarios or applications. In our context, these devices are referred

to “virtual devices”. In fact, virtual devices can be defined as any physical type of devices in the network

since the mock data transmitted by these devices are only used for data flow analysis. However, since we

are more interested in the safety aspect of different devices, the level of safety importance of such

devices must be clearly specified and modelled.

SAFETY SPEC 4. In our system set-up, any physical device needs to be assigned with a gateway in the

network. In addition, each physical device should be able to communicate with the gateway for data and

information exchange through available communication channels. However, physical devices are not

necessarily required to have large computing capabilities. In the case where devices only have limited

computing power, the associated gateway should be acting as a proxy on behalf of these devices for

certain tasks. Furthermore, depending on the application of interest, a number of “virtual devices” can

also be created, registered to the network via a gateway, and start transmitting data on demand. In the

same time, each gateway should be able to check the current status of its connected devices and report

this information timely to the Cloud platform.



Figure 3: Main Elements of the CHARIOT Safety Supervision Engine

SAFETY SPEC 5. For practical implementations, Cloud is required to specify the overall number of

resources that can be currently accessible by gateways in a functional manner. However, we note here

that the overall number of resources is, however, not visible at the gateway level, and each gateway is

not required to know the distribution of resources at other gateways for safety and privacy concerns. In

order to get the resource, each gateway needs to send a request to the Cloud, e.g. via an API, during its

initialization stage, or whenever the demand has been changed for more or less request of resources.

When this procedure is finished, both physical and virtual devices can optimally share the resource in a

distributed collaborative manner by taking account of the utility function of each device, which essentially

captures the level of safety importance for such a device. Finally, we require that both types of devices

should be able to set up their transmission rates as suggested by the output of the algorithm whenever

an optimal decision has been made.

SAFETY SPEC 6. The weight factor of a sensor can also be implicitly included in a utility function so that

a user does not have to give this particular detail to the platform when registering a sensor or device to



an IoT system. From the system point of view, this also makes user’s information privacy-preserving.

Finally, there are many other ways that one can formulate a utility function taking account of other

features with the sensor, e.g. battery consumption, sampling rate, among others. This design

methodology potentially gives opportunities for users to specify comprehensive information on their

sensors for better decision making in an adaptive and customizable IoT environment.

SAFETY SPEC 7. In order to further analyse the data flows produced by different IoT devices, we shall

develop a robust and effective Safety Supervision Engine (SSE) which requires the following functions.

First of all, a reliable interface is required to fetch online data streams from the Cloud. After receiving the

data, the SSE should be capable of implementing predefined enforcement rules and deploying machine

learning models to detect potential anomalies of data flows. The SSE should be operated in a robust

fashion by considering uncertainties that may arise in practice, e.g. transmission delay of devices, noisy

and transmission failures between gateway and the Cloud.

SAFETY SPEC 8. The output of SSE will indicate the safety status of the system. For this purpose, we

require that (1) an interface to send warning messages to the system operator when any safety related

issue arises; (2) an interface to send the diagnostic result to the platform, for example, an evaluation

report indicating when and where the anomalous event happened; and (3) an interface to send

methods/recommendations to both platform and the system operator about how to clear faults and

anomalies.



Figure 4: The schematic diagram of the data flow monitoring and detection system

SAFETY SPEC 9. IoTL is a language for communicating the state of the system. Its grammar is created

using Antlr 6 and a Python 3 parser is generated by ANTLR. In the APPENDIX, we provide the current Antlr

Grammar. IoTL is used to share and track the topology of an IoT setup across different components. This

language enables communicating safety related actions and state changes between multiple nodes of a

system. The core specs of the IoTL is listed as follows:

System State:

We define the system state of an IoT setup using the following constructs:

1. Definitions: We use zone, gateway and sensor as the key elements of an IoT network. A zone is

an enclosed area in an industrial IoT setup which might have multiple zones, gateways and

6 https://www.antlr.org/ Also see [20]

https://www.antlr.org/



sensors. Gateway is another core unit which might be running CHARIOT safety engine if it is Linux

enabled. It controls the traffic of multiple sensors. A zone can be associated with a Fog node.

2. Relations: A relation is defined between two components in the system. The types of allowed

relations are listed as follows:

a. Dependency: A dependency is between a master and slave component and denotes that

the slave component is part of or controlled by the master component. When the system

state is synced to a local component, the state associated with all the dependent

components is shared too. For example, several gateways might exist in a zone or several

zones might have a master zone.

b. Correlation: Correlation can exist only between sensor components. Violation of a

correlation creates an abnormal state on the system.

c. Equality: Equality is equal recordings by two sensors at the same time stamp.

d. Delayed condition: Delayed condition is a condition applied within a time interval. For

example, the presence sensor in a corridor might be equal with a certain delay.

3. Plugs: Plugs are external components such as machine learning models plugged directly to the

data streams on the devices.

4. Enforcements: Enforcements are plugged machine learning models and rules of the system. A

violation of an enforcement is classified as an alert by the alert manager.

5. Alerts: Alerts are next actions after an anomalous condition in the system.

IoTL API:

The commands of the system are shared between different components using REST API. REST API can

be used to send a set of commands and get the state of the system. The new state can be appended to

the old state or can overwrite the existing state of the system.

State Manager

The core functionality of CHARIOT Safety Supervision Engine is keeping the state of the system

consistent across all the components. The state of the system is communicated using IoTL. All

the components in CHARIOT is running safety supervision engine and the state is shared by

periodical and action triggered synchronizations.



Figure 5: The state of the system is shared between cloud and local components using IoTL.

4.5 Interface Definitions

According to the suggested architecture shown in Figure 5, the system will operate as follows:

During the initialization stage, the total number of available resources is specified from the Cloud side, and all

devices are required to register to the Cloud platform. Following that, each gateway detects the number of

devices assigned, and sends a request to the Cloud platform for resource allocation for data transmission. Upon

receiving the resource allocation decision at the gateway level, each IoT device starts running a distributed

cooperative optimization algorithm which maximized the overall utility for the whole group subjecting to the

resource constraints specified at the gateway. The output of the algorithm determines the optimal transmission

rate of each device (i.e. the delay time for each transmission), where each device should set up before

transmitting data to the Cloud. The status and transmission information of each device will be synchronized to

the CHARIOT platform for visualization. This finishes the initialization stage.

During runtime, data point collected from each IoT device will be sent to the storage database, i.e. Cloudant DB7,

via MQTT8, for further processing through the Cloud platform. Data streams will be fetched and analysed by the

SSE while transmitting to the Cloud. Warning message management mechanism will be activated when any

anomalous event has been found. The SSE will be able to indicate when and where the problem happened, and

based on that, gives recommendations to the operator about how to resolve the problem effectively. Finally, in

case if the operator is offsite, SMS or phone call services can also be made available to notify the operator

regarding the status of operations of devices in real time.

7 https://www.ibm.com/uk-en/marketplace/database-management 8 http://mqtt.org/



4.6 Use Cases

Safety supervision engine has the following use cases:

1. Enforcing safety scenarios on the edge even when there is no connectivity

2. Keep state of the system consistent across different devices

3. Keep local state only in the edge devices for security reasons

4. Dynamically calibrating signal reading frequencies for the safety scenarios

4.7 Scenario Implementations

The exemplar scenario implementation for the safety supervision engine is given as follows as part of CHARIOT

work package 4 for the IBM Living Lab:

Safety supervision scenario will showcase CHARIOT IPSE safety supervision engine functionality. We aim to

showcase the utilization of sensor data during a fire hazard event. One key problem during a fire is connectivity

loss between the network components in the offices that are affected by fire. This can be caused due to fire

destroying the equipment and cables. A safety supervision system that have the cognitive capabilities only in

Cloud or one on-site-server will have a single point of failure and one critical failure might render the system

non-operational.

We will use a zone in IBM designed to showcase the innovations of IBM named Thinkspace to deploy our sensors.

In this scenario, we will use three low power Fog units in the network that are already deployed in the Thinkspace

zone (Three raspberry PIs). These units will connect to Panthora gateways 1-to-1 and run safety supervision

engine even when the main CHARIOT server and other low power Fog instances are not connected with each

other during a fire hazard.

We plan to place 4 temperature sensors, 4 CO2 sensors to 4 rooms in the Thinkspace zone as well as 4 presence

sensors. The system will be connected with IBM building management system sensors. In addition, we will utilize

10 desk presence sensors already deployed in the zone. All the sensors purchased will have wireless connectivity.

The sensor connection with the Panthora Gateway can be either through BLE or Wi-Fi. The Panthora gateway

will have a wired connection with IBM network which also contains CHARIOT Fog server.

4.8 Current State Summary / Development Plan

Safety supervision engine contains three pieces of core work. They are listed as follows:

1. Safety supervision engine with API connections to CHARIOT runtime: A server based on Flask and Python

have been developed with a rest API for the CHARIOT dashboard https://gitlab.com/chariot-

h2020/ibmcloud-demo

https://gitlab.com/chariot-h2020/ibmcloud-demo

https://gitlab.com/chariot-h2020/ibmcloud-demo



2. IoTL for sharing the topology of an industrial IoT state: The core components of the language have been

finalized and shared with the consortium as a Python module here: https://gitlab.com/chariot-

h2020/iot-modeling-language

3. Collaborative optimizer for the signalling rate under different scenarios: The initial specification and

experiments have been finalized and currently being integrated to the safety supervision engine.

The initial design and specifications for the safety supervision engine has been finalized. The prototype of the

safety supervision engine has been shared with the CHARIOT Consortium as well as the three living labs and the

first version of the prototype will be deployed to the living labs in Q1 2019.

https://gitlab.com/chariot-h2020/iot-modeling-language

https://gitlab.com/chariot-h2020/iot-modeling-language



5 Privacy Engine

As IoT technologies become more ubiquitous, offering improved connectivity and increasing the amount of data

available, users from all spectra expect to have the same, if not better, levels of security and privacy protections

as they would have offline. Maslow’s hierarchy is indicative of the importance of privacy, as it is commonly

classified as a basic safety need. Moreover, recent surveys among end users show that the data privacy is topping

their list of concerns [6].

Furthermore, IoT connectivity is becoming so embedded in everyday life that, in many cases, users are not aware

of the extent of data sharing they participate in. Combination of diverse data sources and types only adds to the

complexity, making it difficult to document and communicate the flow and processing of data. Integration of

different data sources make the process of identifying secondary (processed) sensitive data problematic, for

organisations and users alike.

Recent initiatives in regulations regarding data privacy, especially GDPR, are set to impose large fines to

organisations that are found to have broken the rules. Notwithstanding the strict regulations, users are left

without realistic remedies as in most cases issues are detected after the fact.

That is why privacy engines, a key part of modern solutions, are tasked with desensitizing personal and sensitive

information making it usable to a range of processes while eliminating the risk of exposure. Moreover, privacy

engines attempt to identify raw sensitive data while sensitive data resulting from data integration recording an

audit trail and data provenance information, therefore enabling organizations to demonstrate compliance.

In the context of CHARIOT, the privacy engine will provide the necessary foundations for secure and private

information exchange between participants. The engine will need to communicate with other modules of IPSE.

Its role is to detect anomalies in the ‘behaviour’ of IoT systems maintain a topological representation, interact

with the central CHARIOT platform and many other. Functionalities are described in more detailed later in this

document.

5.1 Key Definitions

Runtime privacy engine and service is a part of the CHARIOT architecture that ensures that data transmitted

from the safety critical system to the IoT will not compromise sensitive information. The Privacy Engine analyses

a model of the interactions between the controlled safety critical system and the IoT system and by using model-

based information security techniques ensures that no sensitive information is exposed in locations where it can

be accessed by third/unauthorized parties. Thus, the Privacy Engine contributes to the cognitive capabilities of

the CHARIOT platform.



For the privacy engine we defined the following key definitions:

• Privacy: According to [10], Information privacy implies that the user can control when, how, and to what

extent personal information is collected, used, and shared. “In an IoT environment, connected systems

may communicate with each other, transmit collected, or control exchanged data. The capabilities of

system’s connections during various processes imply many security and privacy issues in the dynamic

world of IoT, regarding constraints of maintaining the meaning of the handled information”.

• Anonymization: It is a process or an algorithm to remove any personal information from data-set.

• Cipher: In cryptographic cipher is the technique we use to encrypt or decrypt a message.

• Cryptographic Hashing: It is a non-invertible function that maps an arbitrary size string to a fixed-sized

called digest, and it's unfeasible to recreate the starting message from that digest.


The functional requirements of the privacy engine are listed as follows:

PRIVACY F1. The message must leave the CHARIOT Gateway encrypted with the destination

principal’s public key, in order to minimize the risk of exposing personal information of company’s

customers.

PRIVACY F2. Since messages are text-based the system has to analyse each packet for privacy data

by using natural language processing algorithm to perform schematic check.

PRIVACY F3. System must analyse logged messages and detect potential privacy threats when data

from different sensors are combined.

PRIVACY F4. The operator of the system should use the provided access-control language for the

purpose of grant permission of external system to get message for the CHARIOT’s sensors.

PRIVACY F5. The operator should label sensors that produce user’s privacy data.

All the alerts should be stored locally and on the cloud.

Expect of those we have the following cross-component functional requirements:

PRIVACY F6. Privacy Engine should get the topology of the chariot network from a dedicated service.

PRIVACY F7. The IPSE should get instruction from the Privacy engine on how it will release the data

stream on the northbound of the Fog Node.

PRIVACY F8. The IPSE should encrypt the message with destination’s public key.

PRIVACY F9. The southbound MQTT should establish connection only with trusted sensors.




PRIVACY NF1. Privacy engine should work independently from other systems in order to enforce rules.

PRIVACY NF2. The privacy engine should run on a docker container.

PRIVACY NF3. The ACL rules will be updated through a REST API. The operator of the system could

update them from the CHARIOT dashboard.


According to the architecture, we made the following diagram in order to achieve the functionality of the

Privacy Engine.

Figure 6: Privacy Engine architecture design

First, the message is received on the gateway from the sensor and then the gateway forwards it to the CHARIOT

node. The southbound dispatcher receives the message and do the following tasks:

1. For the purpose of local anomaly detection, it stores them on a local instance of InfluxDB.

2. It sends the message to the cloud in order to train the global model.

3. It passes the message to the engines given that they would be able to check for flaws.

Southbound Broker

Northbound Broker

Fire detector Sensor

Dashboard Front-End

BMS Actuator

Privacy Engine

Northbound Dispatcher

Southbound Dispatcher

Subscribe new actuator

IoTL Langu

Encrypted message by recipient public key

Get sensor info & Access Control Info

Message from sensor

Publish alert

Blockchain PKI

Log the message locally

Cloud Storage



When a message arrives, the privacy engine looks for flaws. In case a discrepancy is found, it informs the system

operator through the dashboard. Finally, the message is forwarded to the recipient through the northbound.

5.4.1 PRIVACY SPEC 1: Privacy engine checks

In order to check for privacy related error, we run some checks for each message. We define the following two

types of checking:

1. Filtering: For such rules we try to transform the message, so we hide information from unauthorized

personnel.

2. Inspection: In this case we try to understand the meaning of the payload e.g. we check if the message

contains a user identity.

Figure 7: A taxonomy of checking types

5.4.1.1 Filtering

The filtering rule purpose is to avoid leakage of sensitive information to unauthorized users. We use public-key

encryption and access control list to achieve that. We expect from the CHARIOT operator to define the access

list controls with the use of IoTL and the engine should apply them to guard user data. On the following flowchart

shows the process of public-key encryption of message payload.

Checking Type

Filtering

Inspection

Anonymization

Cipher

Hashing

Topology

Natural Language Processing

(NLP)



Figure 8: How it applies cipher filtering rules

5.4.1.2 Inspections

In order to prevent a privacy information breach, we expect by the administrator of the network to label a sensor

as a ‘Sensitive’. Every time a message is generated by `Sensitive` labelled sensor privacy engine should raise an

alert and consequently all the actors of the IoT Network will be aware of those sensors.

Figure 9: How it applies topology related filtering rules

5.4.2 PRIVACY SPEC 2: Defining ACL (Access Control Language)

CHARIOT includes an access control language (ACL) that provides declarative access control over the elements

of the CHARIOT Network.

The Access Control Language introduces the following definitions:

1. Principal: Defines the person or entity that has listened on CHARIOT for new messages. A principal

example is an Industrial System Gateway.

No more subscribers

Has more subscribers

New

message

Get subscribed

actor list

Get public key from

Blockchain PKI

Encrypt message

payload

Send it to the

northbound

Wait for new

message

Not sensitive

Is sensitive New

message

Get sensor

information from

IoTL

Wait for new

message

Raise alert



2. Resource: Defines the things that the ACL rule applies to. Some examples are the Sensors, Logs or the

alerts.

3. Operation: Identifies the action that the rule governs. CHARIOT support only READ.

4. Guard: Is the responsible service to applies ACL rules, for us the Privacy Engine.

5. Action: Identifies the action of the rule. It must be one of: ALLOW, DENY.


As a result of the current architectural design shown in Figure 6, the engine will work as follows.

At the installation stage, the system operator must define the rules of access for devices’ data through the

gateway dashboard, then the fog node will synchronize the local stored rules from the connected devices with

the global ones.

Each time a flaw is detected, the engine will publish an alert message at a dedicated MQTT broker topic. Then,

it is expected to have an omni-channel way to deliver the alert to the system operator.

Since it is expected to have a list of subscribed external systems on a sensor, a REST API will be exposed to

initialize a registration procedure for the new data-stream listener, such as a BMS system.

5.6 Use Cases

Privacy engine has the following use cases:

1. Prevent user data leakage e.g. data from employee card reader.

2. Infer the message payload type, for example, if the type is identity card number.

3. Raise awareness for the danger to expose personal data in case of using related sensors such as

card reader.


The smart building scenario, at IBM Campus, involves the installation of presence sensors, aiming to

ameliorate the overall energy efficiency of the building. Monitoring occupancy levels allows for a more

informed approach in energy management, allowing the adjustment of HVAC systems depending on

the levels of occupancy (e.g. switch off when the office is empty).

The use of presence sensors and the combination of the generated data with the physical presence of

a person can potentially lead to the leak of sensitive and private information., hence disclosing a

person’s location and exposing them to various threats (e.g. home invasion).



The privacy engine will ensure that this kind of information is computationally improbable to fall in the

wrong hands by employing asymmetric encryption to cipher those data. Therefore, in the event that an

attacker attempts to intercept the communication from the gateway to the actuators, they will not be

able to read the exchanged message due to the encryption. The following diagram describe how the

privacy engine works.

Figure 10 Privacy engine visual representation


We had finished the initial design for the privacy engine and a prototype of it is already published at

the common consortium repository. We expect to release a RC version of the privacy engine by the

January of 2019. For more information about the implementation of the engine, please download the

project from its repository https://gitlab.com/chariot-h2020/chariot-privacy-engine.

https://gitlab.com/chariot-h2020/chariot-privacy-engine



6 Security Engine

The Security Engine service is a part of the CHARIOT platform responsible to check the integrity of the firmware

of IoT gateways and devices. The service scans the pre-OS (firmware) of devices provided by the static source

code analysis module and, by using ML/neural net techniques, will check the integrity of firmware, ensuring that

only approved firmware is operating and blocking untrusted updates. A Neural Network can ensure the detection

of altered firmware at runtime or each time a firmware update is requested. This functionality enhances system

security functionality by complementing device authentication with an additional security check carried out

through signing the compiled firmware to the CHARIOT Blockchain in case of compliance when it passes the

security check. At the same time, Security Engine is liable to raise the guard level when any security related issue

arises. Therefore, the Security Engine is able to detect tampered firmware which could contain potential threats

by checking consolidated firmware and subsequent firmware updates to guarantee no security breaches.

6.1 Key Definitions

Repository: Is a storage location that contains all the pre-compiled binaries of firmware for sensor devices. It

includes a sort of whitelist that checks and grants the latest approved firmware/software versions for each type

of sensors (respectively used in rail sector/airport/smart building environments) and devices in CHARIOT

platform.


The functional requirements of the Security Engine are listed as follows:

SECURITY F1. All CHARIOT Network devices should be loaded with a compliant trusted firmware that is

securely installed on the device.

SECURITY F2. CHARIOT devices should be authenticated against the information held in the blockchain ledger

to guarantee they are trusted and not have been tampered.

SECURITY F3. The Security Engine should receive the pre-compiled device firmware after a static source code

analysis phase and a compilation phase.

SECURITY F4. The system should be able to sign the firmware to the CHARIOT Blockchain through a POST

request.

SECURITY F5. The Security Engine should send the validated sensor data packets directly to IoT gateway to

apply them in CHARIOT device.

SECURITY F6. The Security Engine should be able to provide effective resiliency to every low-level attack vector,

based on firmware tampering.



SECURITY F7. Machine Learning (ML) based algorithms should be used to provide a standard behaviour of

reference to give compliance/non-compliance result.

SECURITY F8. Machine Learning models should be trained using firmware binary format samples.

SECURITY F9. The Security Engine should raise alerts for security threats to the Management Portal.


SECURITY NF1. The Security Engine system should use a computational unit resource to extract data from

firmware image, perform reverse engineering, obtain Control Flow Graph data, perform the core

ML analysing service. The Security Engine system should run on a Linux compatible system with

at least specs of quad-core CPU and 8GB Memory.

SECURITY NF2. An Artificial Neural Network (ANN) model should be built close to IoT Gateway subnet.

SECURITY NF3. The Security Engine system should use a storage unit (repository-like) that will be used to contain

all data extracted in evaluation/tuning phase (CFG data, functions) to attest the value of standard

behaviour, used to devices in CHARIOT platform. The Storage Unit should have a capacity of, at

least, 100GB of free space.

SECURITY NF4. Either ANN and Security Engine could be run in the same embedded resource that should be in

IoT Gateway network. ANN may be built also in external platforms and use external processing

power given by external platforms.


In order to accomplish a firmware verification of CHARIOT IoT devices, an approach based to Machine Learning

(ML) /neural network technic will be used to implement the Security Engine. A Machine Learning based

algorithm will give to gateways an internal Artificial Intelligence (AI) that will decide if the device is receiving or

is running a compromised firmware. The Security Engine may use external processing power given by external

platforms, such as IBM Watson.

During the first stage, an evaluation phase is mandatory to instruct the engine with the right behaviour held by

sensors/devices. A sandbox like a machine emulator or machine virtualisation tool could be used to perform

dynamic analysis of firmware. At the end of this phase, the engine is able to check the security of a firmware

based on his typical behaviour. The Security Engine should be run close to gateways to guarantee a direct

connection with devices to avoid any tampering event during communication.



In a runtime stage, after passing the static source code analysis by Bismon compiler, every compiled firmware

must be run by Security Engine to guarantee the lack of security breaches. The engine releases a response that

indicates if firmware behaves as expected and certifies it as not compromised.

Finally, the Security Engine will be able to indicate when a potential security breach has occurred and firmware

will be marked as tampered and not secure. Through a warning message management mechanism, an alert

status will be sent to a management portal. Based on that response, security operators will take subsequent

actions for further detailed analysis and troubleshooting.

Figure 11: Security Engine workflow process

Security Engine will perform the following operations:

SECURITY SPEC1. Evaluation Stage:

When CHARIOT system is deployed, there should be a tuning phase, during which the Security Engine, using

reverse engineering technics, extracts Control Flow Graph data and used functions to understand device’s

normal operating conditions.

During this training, the system uses the received input to calculate the weight on the Neural Network

nodes. It could be done by using statistical methods, such as confidence intervals, code coverage, CPU idle,

where it will be estimated the performance of the classifiers.

SECURITY SPEC2. Runtime Stage:



At the end of the tuning phase, after the analysis of the behaviour of the device firmware, the Security

Engine is able to detect all eventual anomalies as a deviation from the usual pattern whenever a new

firmware is going to be installed on a sensor. This could be done every n minutes by extracting current

running firmware via UART from each sensor connected to the Gateway to make sure that current firmware

sensors have not been tampered (if supported).

A standard behaviour is attested as a “Reference” and is used to approve each firmware, in case of non-

compliance a compromised status will be generated with warning message dispatch.

SECURITY SPEC3. Response Stage:

Security Engine will be responsiblefor sending a POST request to the Blockchain in order to sign the compiled

firmware in case of compliance when it passes the security check, besides sending via SFTP the firmware

file itself directly to IoT Gateway.

Otherwise, the Security Engine will send a warning message to the Management Portal when the compiled

firmware check doesn’t pass, or any security related issue arises. A confidence measure is sent with the

output prediction.


According to the suggested architecture shown in Figure Figure 11: Security Engine workflow process, the

system will be able to receive in input the pre-compiled image of the certified firmware file (in .elf format e.g.)

from Bismon compiler as well as the generated digital signature attached to the firmware file with the

corresponding public key.

During runtime, the Security Engine will release in output, through a POST request, the digital verification

response for CHARIOT Blockchain nodes to indicate the validation and the correct device status to IPSE interface.

At the same time, it will dispatch the validated firmware file via SFTP directly to device sensor through IoT

Gateway.

In case the validation process fails, the Security Engine will release in output a warning message to be dispatched

to the management portal to indicate an alert status for further investigations.

6.6 Use Cases

Security engine has the following use cases:

1. Early detection of anomalous communication

2. Perform firmware check integrity



3. Raise alerts for security threats

4. Report a security violation


Monitoring of energy efficiency Scenario in Trenitalia railway environment

The Energy Department of Trenitalia is responsible for the control and evaluation of an innovative near real time

system of monitoring of energy optimization on railway equipment daily operation. This system supports train

operators producing relevant impacts on costs reduction as well as improvements in overall train-system

behaviour enabling operators to improve their operational performance and energy efficiency. It is realized with

the study of the energy consumption trends of specific equipment on the base of a real time dashboard that

analyses IoT sensors data communicated by an IoT Platform that interacts with a Wi Fi connection on the On-

Board Dynamic Maintenance Management System. The sensitive data that allows train operators to guarantee

a High quality of rolling stock energy efficiency optimization, that comes from IoT sensors, need to be managed

in security conditions considering the disruptive impacts of a malicious intrusion in the communications between

IoT on board Sensors and Dynamic Maintenance Management System. Indeed, the environment could be a

target of a potential hacker that could alter the flow of energy efficiency related data coming from train

components, by injecting anomalous values of Electric charge flow and Voltage (lower and higher than the

average value commonly performed) in order to contaminate punctual findings as well as to alter the operational

trends elaborated on the base of these data. This can have repercussions on both daily operations, daily energy

consumption and, possibly, on the reliability of machine learning or traditional algorithms applied to interpret

energy-efficiency related raw data. The cyberattack rational could be related to the interest of a competitor in

tampering the whole system of efficiency management or predictive maintenance discrediting the consistency

of the system truthfulness and usability, as well as to cause direct malfunctioning, increased energy spending or

problems to the company. By performing the Firmware Integrity check offered by CHARIOT Security Engine it

will be possible to perform an early detection, diagnosis and mitigation of the malicious intrusion performing

data alteration controlling the IoT sensors data package that are delivered to the Dynamic Maintenance

Management System. The Security Engine checks the IoT Communications generated from device sensors and

raise alerts for eventual security threats. Hence, CHARIOT would complement the characteristics of the new

generation of Intrusion Monitoring Detection and Prevention Systems enabling a real time safe and secure

energy management.




The initial specifications with functional e non-functional design requirements have been finalized. Currently, it

is going to be conceived a machine learning algorithm to improve security level based on behavioural analysis.

An example application is planned for the next period; the first version of Security Engine (using embedded

neural networks) it is expected to be ready by M17, after Living Labs demonstration by M26 a reviewed steady

version will be released.



7 Dashboard Design

7.1 Scope

For the purposes of the CHARIOT project, a security, privacy and safety awareness configurable dashboard will

be developed in order to remotely monitor in near real-time the various IoT gateways and sensors in the f

Fog network. The dashboard is part of the entire IPSE implementation and will also be used for both

understanding of the IoT ecosystem topology and for post data analytical purposes to assist in the refinement

and improvements of PSS policies.

The advanced intelligence dashboard will be utilizing the latest state-of-the-art web technologies in order to

deliver rich content information to the LL users and achieve cross-browser and multi-device compatibility.

Further to that, the dashboard will be user friendly, fully responsive and configurable web solution, based on the

LLs needs, with an easy access to the necessary content.

In this document, the dashboards’ functional, non-functional requirements, the technical design specifications

along with the interface definitions are defined. This information will be used as principles and guidelines during

the implementation of the dashboard. The implementation progress including dashboard mock-up designs and

screenshots from the implemented web-based dashboard solution will extendedly be described and presented

in D3.5 (Development of a prototype IPSE Analytics Prediction model and Dashboard). D3.5 will be submitted in

a later stage of the project and more specific in M17 (May 2019).

7.2 Dashboard Concept and Benefits

A dashboard is a kind of an information management tool which is used for the purpose of tracking metrics, KPIs

and several other data elements which are of importance to an organization. The organizations (in our case the

LLs), are looking for certain tools that can help them know whether their business is running at the right pace

and in the right direction. With the development and use of dashboards, this area is been taken care of.

As far as the LLs are concerned, a web-based dashboard can help visualize summaries of data in a format of

comparisons, graphs, line and bar charts, trends, reports, statistics, etc. There are four key requirements for a

good and effective dashboard, and they are given as follows:

• Simplicity and communication in the easiest manner.

• Visuals to offer the least number of distractions or confusions.

• Enable application of visual perception to visual presentation.

• Configurable, well-organized business and presentation of useful data.



Moreover, the business benefits of using a dashboard are very important for the LLs that are participating in the

project. These benefits are listed below:

• Visibility – Dashboards offer an objective real time (or at least near real time) view of the conditions that

are valuable for the LL.

• Consolidation of multiple data points – What dashboard can do is to collect data from multiple sources

(in our case from the 3 main engines; Privacy, Safety Supervision and Security) and consolidate it to one

single reporting source. This can help the user (or the operator) and moreover the organization to reduce

decision making time well as the manual work, thus making it possible for you to share the data among

the entire organization.

• More value out of data – When bringing all the data in one place, dashboards make it possible to

compare those data and metrics more easily. A well-designed and structured dashboard can help the LLs

gain much more understanding about the business and environment current status.

Exploring existing dashboards relevant to the IoT concept and technology (i.e. ThingsBoard9, TheThings10,

MyDevices11, Ubidots12, Freeboard13), it is more than clear that the purpose is to provide an information

management tool helping the operators monitoring smoothly the necessary information and taking the correct

decisions, timely and cost efficient.

So, it’s crucial to understand the importance of collecting data and the convenience of analysing it and present

them in one place. Dashboards not only offer a convenient display but also make way for accessing performance

metrics and statistics simple. The following list points out the LLs benefits of utilizing dashboards.

• Saves time – A dashboard can save time of executives who spend several hours a week trying to log

information into reports and then running them. This saved time can be then invested on other

important tasks and may offer increased productivity and profitability. As they say “time is money”, so

the more time you save, the more money you make.

Existing dashboards relevant to the IoT concept and technology 9 https://thingsboard.io/ 10 https://thethings.io/ 11 https://mydevices.com/ 12 https://ubidots.com/ 13 https://freeboard.io/



• Offers better results – A dashboard helps operators to address the issues or problems that need

checking. Performance indicators and real-time alerts are hugely instrumental in improving your

operations by eliminating problem areas and capitalizing on elements that are working currently.

• Improves productivity – In continues with the previous point, a well-organised dashboard enables

operators to be more efficient since the decision making is faster. So, the performance can be improved,

thus increasing profits.

• Offers deeper transparency – One of the main reasons why a business needs a well-designed dashboard

is because such a tool helps users to know what kind of forces are driving it at a given point in time. The

well-illustrated gauss graphs, and the detailed reports can pinpoint to the factors that may be working

for the business or the ones that may not be proving beneficial.

• Offers better overview picture – A dashboard helps to provide a much greater overview of the data by

dividing it into groups, blocks or widgets. This kind of condensed overview picture, data can be easily

analysed, and better insights can be gained.

Thus, dashboards not only speed up the process of decision making but also enables the creation of alignment

of data. But this is only possible if the dashboard is created with enough consideration and by considering certain

rules and suggestions. In order to be able to implement an aesthetically pleasing and functional dashboard, we

need to have in mind the design requirements (functional and non-functional) as mentioned in the following

section of the document.


During the “Use Case Modelling Phase”, a number of meetings and calls have taken place with the LLs (final

Dashboard’s users) but also between the rest of the technical partners, in order to identify the user needs

regarding the IPSE Dashboard. This section lists and describes the IPSE Dashboard’s functional design

requirements. These requirements need to be taken into consideration during the Implementation of IPSE

Dashboard in order to achieve the required goal of having an aesthetically pleasing and functional dashboard

that covers LLs needs and comply with the project vision in general.

DASHBOARD F1: Cross-Browser and Multi Device Compatibility

The dashboard needs to perform in the same way under all major browsers and devices without affecting its

functionality. Responsive dashboards do not only look attractive but also offer several critical benefits over the

non-responsive ones. Having a responsive solution is one of the most important features that needs to be

adopted in a newly created modern dashboard. Some of the major benefits are listed below:



• It provides an unparalleled user experience across different devices and resolutions. The number of

mobile users is higher than ever, and continues to grow. Luckily, a responsive dashboard is compatible

with both desktop and mobile users, so none of the potential users are left out.

• It speeds up the dashboards’ loading time. A responsive dashboard is much faster than a non-responsive

one, which means that the visitors are less likely to give up on the website and click away because it

takes too long to load.

• It simplifies the development process. The responsive design is not just great for the dashboard users

but also streamlines the web development process because web developers are not required to create

multiple sets of code for different devices and screen resolutions.

DASHBOARD F2: Metrics presentation.

It is important to have different statistics and KPIs available to be presented to the user. Dashboards are often

very cluttered, but this can create confusion in the mind of the onlookers. This is why it is important to select

very carefully what metrics we want to add so that only relevant data or information is displayed.

DASHBOARD F3: Users’ needs and flexibility

Creating a single dashboard to meet the needs and suitability of all the LLs can be tough but is equally important.

A good dashboard is one which can be understood even by the slowest user of a team. The visualization tools

must be used in such a way that the gist of the data can be evaluated in a matter of seconds. Basically, simplicity

is the key to creating a user-friendly dashboard. In addition, the business needs are changed on a regular basis.

This is why, it is important to create a dashboard in such a way that it can be changed or updated according to

the changes in the business’s requirements. The dashboard should have the availability for different time scale

data presentation (current, hourly, weekly, monthly and yearly).

DASHBOARD F4: Exporting

We need to make sure that the dashboard will be implemented in such a way it can exported in common formats

like Excel and PDF. This is another factor that can help to come up with a highly functional dashboard.

DASHBOARD F5: Online solution

The dashboard needs to be continually “online” and accessible any time and from anywhere. User do not have

to install anything, download any software, or worry about upgrades.

DASHBOARD F6: The required number of refreshing



In order to ensure optimal performance of the dashboard, we must pay attention to the frequency or how often

it needs refreshing.

DASHBOARD F7: User management and authentication

The web-based dashboard needs to perform a user role management. Each user who access the dashboard

should have different levels which will allow them to access different functionality and visualise only the relevant

to them information.


In continues with the previous section, this section lists and describes the IPSE Dashboard’s non-functional design

requirements that needs to be taken into consideration during the Implementation of IPSE Dashboard. The non-

functional requirements include a couple of categories that we will use to benchmark the project.

There is the measurement of time taken to process the web pages, reliability of our web application to store

data and retrieve data, recoverability of the web applications state in case of failure, and integrity of information

provided by the web application.

DASHBOARD NF1: Live monitoring of IoT devices Monitor the values and location of each IoT device (i.e. sensor, gateway, etc.). These values could be real-time

or near-real time but also historical (i.e. last day) or event averages (i.e. daily average, last hour, etc.)

DASHBOARD NF2: Different levels of monitoring

There are different levels where the operator of each LL will monitor information about the IoT devices. For

example, in IBM and AIA LLs there is a need to monitor information about the IoT devices installed in a building,

drill-in and monitor information about the IoT devices installed in a room, but also monitor information about a

specific IoT device. The same applies in TRIR LL where there is a need to monitor information about the IoT

devices installed in a train, drill-in and monitor information about the IoT devices installed in a wagon, but also

monitor information about a specific IoT device.

DASHBOARD NF3: Visually appealing

Another thing that needs to be considered while designing and implementing the dashboard is its visual look and

appeal. The overall attractiveness of the dashboard needs to be good enough for the business users and

operators of each LL. A well-designed dashboard is one which is pleasing to look at and high in terms of usability.

DASHBOARD NF4: Concise and responsive



Information must be displayed in the briefest or concise way to enable easy navigation, visualizing and reading.

Moreover, the dashboard must be quick and smooth as well. It must be able to enable access to huge amounts

of information effortlessly without difficulties in navigation.

DASHBOARD NF5: Response time

The response time has to do with the time taken by the dashboard to deliver the results to the users. This includes

having low delays during heavy traffic on the web dashboard, as well as retrieving data efficiently during high

demand.

DASHBOARD NF6: Reliability and integrity

Reliability is measured by whether the dashboard can be accessed and the data that are served is valid and

relevant to the logged in user. The integrity of the information provided by the dashboard should be enforced

by following strict guidelines. Any information/data streaming that doesn’t follow the guidelines will not be

presented by the dashboard.

7.5 Technical Design Specifications and Interface Definitions

In this section, the IPSE Dashboard’s technical design specifications are listed and detailed analysed, based on

the design requirements (functional and non-functional) as described in the previous Section. Apart of the above,

the list below provides a mapping of each specification with the appropriate requirement that has been

previously identified.

DASHBOARD SPEC 1: Following the latest technology for design and implementation, the dashboard needs to

be responsive and fully compatible with different devices (laptops, tablets and smartphones) and browsers

(Safari, Chrome, Firefox, and Internet Explorer) without affecting its functionality. With a responsive dashboard,

a user will receive the same content, but the site’s style is structured in such a way that changes may be made

based on the type, resolution, or orientation of the device that is being used. These kinds of changes may include

things like changing from a desktop-friendly horizontal navigation menu to a mobile-friendly vertical drop-down

menu or scaling up font sizes on mobile devices to improve user readability. This will be achieved with the

utilization of modern technologies such as HTML5 [1], CSS3 [2] and JavaScript [3] during the implementation

period.



DASHBOARD SPEC 2: A large number of charts but also KPIs and Gauges can be offered for statistical purposes,

as listed below. To do that, an external JavaScript Charting Library will be used, called FusionCharts [4].

• Column & Bar Charts

• Line & Area Charts

• Pie & Donut Charts

• Stacked Charts

• Bubble & Scatter Charts

• Heat & Tree Maps

• Radar (Spider Charts)

• Rating Meter

• Speedometer

• Linear Scale

• Cylinder fill

• Horizontal / Vertical LEDs

• Thermometer display

• Bulb indicator

There are no fixed rules as to which metrics must be selected as each LL have different requirements and needs.

In order to select which metrics must be included, we can consider the following given factors:

• Identify whether the metrics are necessary to the LL or not.

• Analyse the way in which each metric is contributing to your overall LLs objectives.

• Identify whether the LLs can provide the relevant data to assess those metrics.

DASHBOARD SPEC 3: While the development process of the dashboard is going on, it is crucial that we keep in

mind the entire audience and try to address the needs of each one of the LL users. Every individual user group

or user type (i.e. Operator, Operational Manager, Director, etc.) must be able to operate it and should be able

to meet their individual objectives. While the development process is going on, we need to make sure that the

larger picture is taken into consideration and the dashboard is flexible enough to change functionality,

components and settings based on LLs needs.

DASHBOARD SPEC 4: An additional functionality needs to be implemented to support the dashboard exporting

to various formats, such us .pdf or image. A JavaScript technology will be utilized in order to implement such a

functionality.

DASHBOARD SPEC 5: The dashboard should be a web-based solution accessible anytime over the internet with

a web browser, smartphone of tablet. The dashboard will be implemented by utilizing the Microsoft C# ASP.NET

(Microsoft .NET Framework) [5] technology.

https://www.fusioncharts.com/charts/gauges/rating-meter-gauge

https://www.fusioncharts.com/charts/gauges/speedometer-gauge

https://www.fusioncharts.com/charts/gauges/linear-scale-gauge

https://www.fusioncharts.com/charts/gauges/gauge-with-cylinder-fill

https://www.fusioncharts.com/charts/gauges/horizontal-leds

https://www.fusioncharts.com/charts/gauges/thermometer-display

https://www.fusioncharts.com/charts/gauges/gauge-with-bulb-indicator



DASHBOARD SPEC 6: Refreshing must be spaced in such a way that can save user time and avoid the unnecessary

manual refreshing. Some examples of the refreshing rates of dashboards include daily refreshing, weekly

refreshing, monthly refreshing as well as real-time refreshing. In our case, where we need an operation

dashboard a real-time refreshing is a must.

DASHBOARD SPEC 7: Different user types and different users’ needs to have access in different elements of the

dashboard. For example, an operational manager might have additional access (in relation to the operator) to

KPIs. An administrator role needs to exist which will have a full access to the Dashboard to perform an initial

setup of the rest of the dashboards. In addition, the administrator will have an overall monitoring about the

numbers of users, which of them are online, available resources, etc.

DASHBOARD SPEC 8: Monitor the values of an IoT device (i.e. sensor, gateway, etc.) on a real time (or near real

time) and for a specific period of time (i.e. last 24 hours, last hour, etc.). Along with the values of an IoT device,

there is a need to monitor the specific area where this device is located. For example, in IBM and AIA LLs, there

is a need to monitor in a building map (in an architectural or maps view) where this device is located (in which

building and room). In another example, TRIT LL needs to know in which train and wagon, the IoT devices are

installed, and moreover, the exact current location of the train. An integration with external sources (i.e. Google

Maps) is required in order to load a map in the dashboard and present an exact position of each device (i.e.

building).

DASHBOARD SPEC 9: It was identified that there is a need to have a 4 level/type of Dashboards, applied to the

3 LLs, as listed below:

• Overall Monitoring Dashboard

• Dashboard available right after the operator’s login

• Information about overall monitoring of the “Critical IoT Devices” (i.e. sensors, gateways) along with

any possible alarms that occurred.

• 1st Level - Train or Building Monitoring Dashboard

• It’s possible to search and filter results for a specific IoT device, train, wagon, building, room, etc.

• Visibility in all the available IoT devices on a train (or building) level, along with the any possible

alarms and a graphical representation of this train and their wagons (or building and their rooms)

and the specific position of each IoT device.



• 2nd Level - Wagon or Room Monitoring Dashboard

• Access available through any of the above 2 Dashboard types.

• Visibility on the information about the IoT devices located in the specific wagon (or room) and their

values (current and last hour average)

• 3rd level - IoT device (sensor, gateway) Monitoring Dashboard

• Access through any of the above 3 Dashboard types.

• Visibility on the information about the specific IoT device (i.e. parameters, current value and last 24

hours values, sensor image and location) along with any possible alarms.

In addition, an option for setting up and maintenance the devices (sensors, gateways, etc.) network and topology

will exist. This functionality will give the option for adding, and removing devices in the network and monitor (via

the Dashboard) how this affects the overall topology. The dashboard will also be integrated with the Simulation

Tool implemented under T1.4 and have the option to load data (generated using this tool) and present them to

the final user.

DASHBOARD SPEC 10: The following are some factors that can be considered to make the Dashboard visually

appealing and make increase the usability:

• Data grouping should be done logically. Data must be arranged and displayed in logical blocks of

information or groups, as otherwise it can cause only confusion by the operator that uses the dashboard.

Grouping must be done according to the people using it or similar categorization. The way the data is

displayed is what determines how eye will move on the dashboard and which order will we read the data

presented. Thus, it is very important to place data logically and in proper categories.

• Graphs, charts, and widgets. For a functional and streamlined dashboard, it is important for it to have

charts, widgets and graphs (i.e. statistics, gauss) etc. so as to display information in a systematic way and

so as to throw light on the trends and reports in a simplified manner. The graph and chart types that will

be chosen are also important, based on its relevance and suitability to the overall design.

• Colour, shapes, lines, etc. Another part of the overall visualization that we can consider is the kinds

of colours used, the shapes used as well as the kinds of lines and thicknesses chosen for different

elements. We need to be careful on the selection of these visual attributes and avoid using cute widgets

and 3D graphics to keep the dashboard subtle.

• Captivating design. The overall design of the dashboard must be compelling and captivating enough to

enable the users to work on it with ease and without getting bored.



DASHBOARD SPEC 11: Information must be displayed in the briefest or concise way to enable easy navigation,

visualizing and reading. Moreover, the dashboard must be quick and smooth as well. It must be able to enable

access to huge amounts of information effortlessly without difficulties in navigation.

This section also provides some additional technical information regarding the components of the dashboard

but also the dashboard itself, that will enable the implementation of a fully customised and personalised (per

LL user) dashboards. These components are listed below.

1. Widgets: Widget is basically an interface component (like a container) with grouping functionality on

common information. So, information about a specific element (i.e. sensor information, alarms, events

etc.) that are relevant can be grouped in the same widget. A widget can also present statistic results,

KPIs, or even gauss controls. For example, in the Figure below, we have a dashboard widget that presents

sensor events. In a dashboard we might have as many widgets we need.

Figure 12: Dashboard Widget Showing Sensor Events

2. Customizable dashboards: A user will have the option to personalize their dashboards by choosing

widgets that needs to be included to the Dashboard. Users can reposition (by drag and drop) and resize

(by choosing width and height from predefined sizes) different widgets within a Dashboard. This will

give them the option to fully customize the dashboard as per their preference and needs. Additionally,



users can select the colouring theme for the Dashboards. Users will have the option to create multiple

Dashboards under each account, name it and customize it based on their monitoring needs. As already

mentioned, these Dashboards will be configurable, and therefore can be renamed or even deleted.

3. Multiple dashboards opened in parallel: Another functionality that is mandatory in that multiple

dashboard can be opened in parallel in different tabs. Moreover, the user can open each Tab in a

separated window. This will allow them to move each dashboard into a separate screen and monitor all

of them simultaneously.

4. Filtering Data: The presented to a dashboard can be filtered by the user. This setup might give the option

to the user to set a specific time period on which the data will be presented, for example show only last

24 hours data. This will affect and dynamically update the results presented on a dashboard (including

graphs) that are related with real-time feed data.

5. Interactive Widgets: There will be a dynamic interaction between the widgets of a Dashboard. For

example, by selecting a malfunctioning sensor (from a list with all the sensors) , a “Map” widget will focus

on the specific buildings’ room and points the exact location of the sensor in that room. In the Figure

below, what is presented is the monitoring of three chosen sensors, their values along with their location

in a room.

Figure 13: Interactive Widgets



7.6 Current State Summary/ Development Plan

Currently the dashboard implementation is in the stage where the LLs user (non-functional) along with functional

requirements have been finalized. Moreover, it is under investigation how the technical design, specifications

and topology of the entire IPSE platform are affected with the dashboard and vice versa.

Based on the above-mentioned requirements and specifications, a number of mock-up designs have been

prepared for each of the LLs in order to demonstrates how the actual dashboards will look like. These initial

designs have been circulated and approved by the end-users of each LL. Annex 3 presents some indicative

Dashboard designs that have been separated in 3 different monitoring levels as listed below:

• Building (for IBM and AIA) or Train (for TRIT) Monitoring. Monitoring of sensors’ and gateways’ values

and alerts in a building (or train) level, along with a building map showing the position of each IoT device.

• Room (for IBM and AIA) or Wagon (for TRIT) Monitoring. Monitoring the values of the IoT devices that

are installed in a specific room (or wagon), along with their alerts. This dashboard includes real-time

values and average values for the last hour or the last 24 hours. It also presents sensor's alarms along

with an indication of the severity level of each alarm.

• IoT device monitoring. This dashboard presents information about t specific IoT device (i.e. model,

location, connection type, battery level, etc.). Apart of these, the dashboard presents the current (real-

time) value of the sensor, the values for the last 24 hours, the list of alarms that occurred for a specific

period of time, an image of this device, along with a map showing its exact position.

More details about the mock-up designs and the implementation process will be reported in D3.5 which is

planned to be submitted at M17. Moreover, it is also under progress the identification of the principals that will

be used for the integration between the Dashboard and the IPSE Platform, and the Engines (Security, Safety,

Privacy). This integration will be formulated in order to enable the data feeding from IPSE Platform.

As a next step, the implementation of the actual dashboard will be initiated, having in mind the identified

requirements, specifications along with the above-mentioned designs. According to the DoA and T3.5 (IPSE

Analytics Prediction models and Dashboard), the first version (v1) of the dashboard it is expected to be ready by

M17. A revised version (v2) will be completed by M26 after receiving feedback from WP4 (Demonstration of

concept in Living Labs).



8 Conclusions

In this document, we highlighted the main components of the CHARIOT IPSE. Each engine of CHARIOT IPSE

provides several new innovations over the state of the art in industrial IoT. Distributed safety supervision

introduced by the safety supervision engine ensures fault tolerant operation of the cognitive safety assurance

components such as anomaly detectors and other online machine learning based models. The relevant state is

shared across multiple components in the Fog network to enable edge cloud orchestration by using the domain

specific language developed for IPSE. Having multiple active computation nodes in the industrial IoT network

enables fault tolerance during safety hazards against partial network outages.

Privacy engine ensures data privacy through encrypting data at the source namely at the southbound dispatcher

through a PKI supported by CHARIOT blockchain infrastructure. For industrial IoT setups with multiple

contractors, our approach provides detailed privacy policies for every sensor data stream. On top of that, through

the privacy related constructs in the domain specific language, privacy policies can be enforced even during

partial network outage. Using CHARIOT Blockchain solution for handling PKI provides secure encryption for the

multiple data streams handled by CHARIOT.

Finally, security engine applies machine learning to identify security problems in possible firmware updates

dynamically and the signed firmware updates are distributed across the industrial IoT setup. Deployment of the

integrated IPSE provides CHARIOT living labs the capability of addressing their business-critical problems related

to safety supervision, security and privacy.

The Consortium plans to use the specifications reported in this document for the initial version of the

implementation tasks in work package 3. By the experience after deploying our initial version of IPSE to the living

labs, the Consortium will finalize the requirements in the final version of this deliverable (M26).



9 References

[1] HTML5 [Online], 2016, https://www.w3schools.com/html/html5_intro.asp, Last accessed on 15.11.2018.

[2] CSS3 [Online], 2016, https://www.w3schools.com/css/css3_intro.asp, Last accessed on 15.11.2018.

[3] JavaScript [Online], 2016, https://www.w3schools.com/js/, Last accessed on 15.11.2018.

[4] FusionCharts [Online], 2014, https://www.fusioncharts.com/, Last accessed on 15.11.2018.

[5] C# ASP.NET [Online], 2016, https://docs.microsoft.com/en-us/visualstudio/ide/tutorial-csharp-aspnet-core?view=vs-2017, Last accessed on 15.11.2018.

[6] TechCrunch [Online], 2018, The IoT threat to privacy, https://techcrunch.com/2016/08/14/the-iot-threat-to-privacy/?guccounter=1, Last accessed on: 21/11/2018.

[7] Pohl, Klaus. Requirements engineering: fundamentals, principles, and techniques. Springer Publishing Company, Incorporated, 2010.

[8] Pradhan, Dhiraj K., and Sudhakar M. Reddy. "A fault-tolerant communication architecture for distributed systems." IEEE transactions on Computers 9 (1982): 863-870.

[9] Ranjan, Rajiv, et al. "The Next Grand Challenges: Integrating the Internet of Things and Data Science." IEEE Cloud Computing 5.3 (2018): 12-26.

[10] Sfar, Arbia Riahi, et al. "A roadmap for security challenges in the Internet of Things." Digital Communications and Networks (2018): 118-137

[11] Sanchez-Iborra, Ramon, and Maria-Dolores Cano. "State of the art in LP-WAN solutions for industrial IoT services." Sensors 16.5 (2016): 708.

[12] Sadeghi, Ahmad-Reza, Christian Wachsmann, and Michael Waidner. "Security and privacy challenges in industrial internet of things." Design Automation Conference (DAC), 2015 52nd ACM/EDAC/IEEE. IEEE, 2015.

[13]

Zhao, Yan Ling. "Research on data security technology in internet of things." Applied Mechanics and Materials. Vol. 433. Trans Tech Publications, 2013.

[14]

Da Xu, Li, Wu He, and Shancang Li. "Internet of things in industries: A survey." IEEE Transactions on industrial informatics 10.4 (2014): 2233-2243.

[15]

Porambage, Pawani, et al. "The quest for privacy in the internet of things." IEEE Cloud Computing 2 (2016): 36-45.



[16] Ukil, Arijit, Soma Bandyopadhyay, and Arpan Pal. "Iot-privacy: To be private or not to be private." Computer Communications Workshops (INFOCOM WKSHPS), 2014 IEEE Conference on. IEEE, 2014.

[17] Shi, Weisong, et al. "Edge computing: Vision and challenges." IEEE Internet of Things Journal 3.5 (2016): 637-646.

[18]

Sun, Xiang, and Nirwan Ansari. "EdgeIoT: Mobile edge computing for the Internet of Things." IEEE Communications Magazine 54.12 (2016): 22-29.

[19]

Fowler, Martin. Domain-specific languages. Pearson Education, 2010.

[20]

Parr, Terence J., and Russell W. Quong. "ANTLR: A predicated‐LL (k) parser generator." Software: Practice and Experience 25.7 (1995): 789-810.

[21]

Tappeta, R. V., and J. E. Renaud. "Multiobjective collaborative optimization." Journal of Mechanical Design 119.3 (1997): 403-411.



Annex 1: IoTL Grammar grammar IoTL; /* * Parser Rules */ root : (statement)+ ; statement : (register|define|access|plug|enforce|comment) ; define : 'define' CTYPE NAME (params_json)? ; access : 'acl' NAME NAME ACLRULE ; register : 'register' NAME ASSIGNMENT NAME ; enforce : 'enforce' condition (priority)? (alert)? (start)? (finish)? ; plug : 'plug' NAME NAME SOURCES ; params_json : '--params ' '{' pair (',' pair)* '}' ; pair : '"' NAME '"' ':' ('"' IP '"'|'"' NAME '"'|NUMBER) ; condition : '[' NAME ASSIGNMENT NUMBER ']' | NAME ; alert : '--alert' NAME ; priority : '--priority' NUMBER ; start : '--start' ISODATETIME ; finish : '--finish' ISODATETIME ; comment : CTEXT ;



/* * LEXER RULES */ CTYPE : 'GATEWAY' | 'SENSOR' | 'ZONE' | 'MODEL' | 'EXTERNAL' | 'TYPE'; ACLRULE: 'ALLOW' | 'DENY'; CTEXT : '//'~( '\r' | '\n' )*; NAME : [A-Za-z][A-Za-z0-9]*; SOURCES: '(' NAME (',' (' ')* NAME)* ')'; NUMBER : ('-')? DIGIT+ ('.' DIGIT+)?; ASSIGNMENT : (ASSIGN|CORRELATE|COMPARE); DOT : '.'; ASSIGN : '->'; CORRELATE : '~'; COMPARE: '<'|'>'|'=='|'<='|'>='; ISODATETIME : DIGIT DIGIT DIGIT DIGIT'-'DIGIT DIGIT'-'DIGIT DIGIT 'T'DIGIT DIGIT':'DIGIT DIGIT':'DIGIT DIGIT '+'DIGIT DIGIT':'DIGIT DIGIT; DIGIT : ('0'..'9'); IP: DIGIT+ '.' DIGIT+ '.' DIGIT+ '.' DIGIT+; WS : [ \t\n\r]+ -> skip;



Annex 2: Deployment Plan for the IPSE to the Living Labs

Bare Metal Server

Safety Supervision

Engine

Container

Security Engine

Container

Privacy Engine

Container

Dashboard

Docker Virtual Box

EBOS VM (Windows)

Linux OS (Ubuntu 18.04 Server)

Figure 14 CHARIOT IPSE Deployment View



Annex 3: IPSE Dashboard Initial Designs for all LLs

Figure 15 Building Monitoring Dashboard (IBM)

Figure 16 Room Monitoring Dashboard (AIA)



Figure 17 IoT Device Monitoring Dashboard (TRIT)

D3.1 Design Specification of IPSE (preliminary design) · 2020-05-15 · programme und This project...

Documents

Transcript of D3.1 Design Specification of IPSE (preliminary design) · 2020-05-15 · programme und This project...