Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 3
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 4
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.2 Functional Design Requirements ............................................................................................. 28
5.3 Non-Functional Design Requirements ..................................................................................... 29
5.4 Technical Design Specifications ................................................................................................ 29
5.4.1 PRIVACY SPEC 1: Privacy engine checks ............................................................................ 30
5.4.2 PRIVACY SPEC 2: Defining ACL (Access Control Language) ............................................... 31
5.5 Interface Definitions ................................................................................................................. 32
5.6 Use Cases .................................................................................................................................. 32
5.7 Scenario Implementations ....................................................................................................... 32
5.8 Current State Summary / Development Plan .......................................................................... 33
6 Security Engine ................................................................................................................................ 34
6.1 Key Definitions ......................................................................................................................... 34
6.2 Functional Design Requirements ............................................................................................. 34
6.3 Non-Functional Design Requirements ..................................................................................... 35
6.4 Technical Design Specifications ................................................................................................ 35
6.5 Interface Definitions ................................................................................................................. 37
6.6 Use Cases .................................................................................................................................. 37
6.7 Scenario Implementations ....................................................................................................... 38
6.8 Current State Summary / Development Plan .......................................................................... 39
7 Dashboard Design ............................................................................................................................ 40
7.1 Scope ........................................................................................................................................ 40
7.2 Dashboard Concept and Benefits ............................................................................................. 40
7.3 Functional Design Requirements ............................................................................................. 42
7.4 Non-Functional Design Requirements ..................................................................................... 44
7.5 Technical Design Specifications and Interface Definitions ...................................................... 45
7.6 Current State Summary/ Development Plan ........................................................................... 51
8 Conclusions ...................................................................................................................................... 52
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 5
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 6
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 7
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 8
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 9
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 10
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 11
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 12
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:
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 13
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.
The detailed capability of the security engine is explained further in Section 5.
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.
The detailed capability of the security engine is explained further in Section 6.
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 14
• 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#
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 15
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 16
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:
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 17
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 18
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/
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 19
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 20
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 21
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 22
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]
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 23
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 24
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/
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 25
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 26
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 27
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 28
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.
5.2 Functional Design Requirements
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 29
5.3 Non-Functional Design Requirements
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.
5.4 Technical Design Specifications
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 30
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)
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 31
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 32
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.
5.5 Interface Definitions
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.
5.7 Scenario Implementations
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).
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 33
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
5.8 Current State Summary / Development Plan
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 34
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.
6.2 Functional Design Requirements
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 35
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.
6.3 Non-Functional Design Requirements
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.
6.4 Technical Design Specifications
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 36
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:
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 37
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.
6.5 Interface Definitions
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 38
3. Raise alerts for security threats
4. Report a security violation
6.7 Scenario Implementations
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 39
6.8 Current State Summary / Development Plan
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 40
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 41
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/
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 42
• 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.
7.3 Functional Design Requirements
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:
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 43
• 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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 44
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.
7.4 Non-Functional Design Requirements
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 45
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 46
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 47
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 48
• 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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 49
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,
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 50
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 51
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).
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 52
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).
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 53
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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 54
[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.
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 55
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 ;
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 56
/* * 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;
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 57
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
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 58
Annex 3: IPSE Dashboard Initial Designs for all LLs
Figure 15 Building Monitoring Dashboard (IBM)
Figure 16 Room Monitoring Dashboard (AIA)
D3.1 – Design Specification of IPSE (preliminary design)
© CHARIOT, 2018 Page | 59
Figure 17 IoT Device Monitoring Dashboard (TRIT)