FP7-SMARTCITIES-2013 Project number: 609062 http://www.smartie-project.eu/
SMARTIE
Deliverable D6.1
Real world test - Screenplay
Editor: Manfred Kopielski (GWS)
Dissemination level: (Confidentiality)
PU
Suggested readers: Consortium
Version: 1.0
Total number of pages: 59
Keywords: Test Description, Test Scenario, IoT
Abstract
This deliverable provides a first description of the required deployment of components, timing of
deployments, events to be handled by the components etc. and the parameter of the system that shall be
measured.
Ref. Ares(2015)3988320 - 28/09/2015
SMARTIE Deliverable D6.1
Page 2 of (59) © SMARTIE consortium 2015
Disclaimer
This document contains material, which is the copyright of certain SMARTIE consortium parties, and may
not be reproduced or copied without permission.
All SMARTIE consortium parties have agreed to full publication of this document.
The commercial use of any information contained in this document may require a license from the proprietor
of that information.
Neither the SMARTIE consortium as a whole, nor a certain party of the SMARTIE consortium warrant that
the information contained in this document is capable of use, or that use of the information is free from risk,
and accept no liability for loss or damage suffered by any person using this information.
The information, documentation and figures available in this deliverable are written by the SMARTIE
partners under EC co-financing (project number: 609062) and does not necessarily reflect the view of the
European Commission.
Impressum
[Full project title] Secure and sMArter ciTIes data management
[Short project title] SMARTIE
[Number and title of work-package] WP6 Real world test
[Document title] Real world test - Screenplay [Editor: Name, company] Manfred Kopielski, GWS
[Work-package leader: Name, company] Luis Cortesão, PTIN
Copyright notice
2015 Participants in project SMARTIE
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 3 of (59)
Executive Summary
This document describes the different scenario screenplays of the SMARTIE project that will be
implemented in the real world tests in Murcia, Novi Sad and Frankfurt (Oder). These screenplays will lead to
the detailed test specification in D6.2. Every scenario is described in detail, illustrating the SMARTIE
components to be evaluated and the relevant devices. The evaluation of the SMARTIE results will be
executed on the basis of several test cases that are defined for every scenario in this document.
The document starts with a short overview about the SMARTIE components that are evaluated in the
different scenarios. These components are DCapBAC (capability tokens for authorisation of queries),
XACML (resolving authorisation decisions), CP-ABE (ciphering schema), SmartData platform (framework
to integrate components to IoT environment), shortECC (elliptic curves for constrained devices), Distributed
Kerberos (high security level for outsourced Kerberos Tickets), Resource Directory (secure storage of
resource descriptions), lwsCoAP (lightweight CoAP for constrained devices).
Then the document describes three different test scenario screenplays starting with the test location in
Murcia, Spain. This test scenario provides a smart building management situation with users utilizing mobile
devices to connect to the SMARTIE platform and enable secure end-to-end communication with IoT devices
deployed in the building. The test cases in this scenario embrace the retrieving of sensor values, the actuation
of building equipment and the subscription to maintenance information.
The second scenario in Novi Sad, Serbia provides a smart public transport situation where users utilize
mobile devices to connect to the SMARTIE platform and enable them, to securely, via web services, access
information provided by securely registered IoT resources deployed within the platform. The test cases in
this scenario embrace accessing information on bus arrival times or air quality, interaction with fleet devices
and mobile ticket selection and payment.
The third scenario in Frankfurt (Oder), Germany provides a smart traffic situation where radar based traffic
sensors, LED traffic signs and traffic light units connect to the SMARTIE platform. The processed traffic
data is used to control the connected actuators, provide a web application or manage the connected devices.
The test cases in this scenario embrace the receiving of processed traffic data, the actuation of LED sign
content and the interoperation of different devices in emergency situations.
SMARTIE Deliverable D6.1
Page 4 of (59) © SMARTIE consortium 2015
List of authors
Company Author
GWS Manfred Kopielski
UMU Antonio Skarmeta, Rafael Marin-Perez, Alfredo Quesada-Sanchez
DNET Boris Pokric, Aleksandra Rankov, Stevan Jokic
NEC Jens-Matthias Bohli
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 5 of (59)
Table of Contents
Executive Summary ........................................................................................................................................... 3 List of authors .................................................................................................................................................... 4 Table of Contents .............................................................................................................................................. 5 List of Tables ..................................................................................................................................................... 6 List of Figures.................................................................................................................................................... 7 Abbreviations .................................................................................................................................................... 8 1 Introduction ................................................................................................................................................ 9
1.1 Relation to S&T Objectives ................................................................................................................ 9 1.2 Beyond State-of-the-Art Contributions ............................................................................................... 9
2 Overview .................................................................................................................................................. 10 2.1 Purpose and Scope of the WP6 ......................................................................................................... 10 2.2 Purpose and Scope of Task T6.1 ....................................................................................................... 10 2.3 Purpose and Scope of the Document ................................................................................................ 10
3 Scenario Screenplays................................................................................................................................ 11 3.1 SMARTIE components used in the test beds .................................................................................... 11 3.2 Real World Test 1: Smart Building Management ............................................................................. 12
3.2.1 Description of the test field ........................................................................................................ 12 3.2.2 Relevant SMARTIE components .............................................................................................. 14 3.2.3 Standard Protocols to Be Used .................................................................................................. 14 3.2.4 Description of test cases ............................................................................................................ 15 3.2.5 Assessment criteria .................................................................................................................... 23 3.2.6 Test scenario roadmap ............................................................................................................... 24
3.3 Real World Test 2: Smart Public Transport ...................................................................................... 25 3.3.1 Description of the test field ........................................................................................................ 26 3.3.2 Technical Description of the components ................................................................................. 27 3.3.3 Relevant SMARTIE components .............................................................................................. 28 3.3.4 Standard protocols to be used .................................................................................................... 29 3.3.5 Description of test cases ............................................................................................................ 30 3.3.6 Assessment criteria .................................................................................................................... 36 3.3.7 Test scenario roadmap ............................................................................................................... 39
3.4 Real World Test 3: Smart Traffic Control ........................................................................................ 40 3.4.1 Description of the test field ........................................................................................................ 40 3.4.2 Relevant SMARTIE components .............................................................................................. 41 3.4.3 Standard Protocols to Be Used .................................................................................................. 42 3.4.4 Description of test cases ............................................................................................................ 42 3.4.5 Assessment criteria .................................................................................................................... 56 3.4.6 Test scenario roadmap ............................................................................................................... 57
4 Conclusions .............................................................................................................................................. 58 References ....................................................................................................................................................... 59
SMARTIE Deliverable D6.1
Page 6 of (59) © SMARTIE consortium 2015
List of Tables
Table 1: Roadmap for smart building test scenario ......................................................................................... 24 Table 2: Use of SMARTIE components for achieving different smart transport pilot functionalities ............ 29 Table 3: Serbian Pilot Goals ............................................................................................................................ 36 Table 4: Serbian Pilot - Financial Key Performance Indicators (KPIs) with Target Values, Rationale and
Measurement Process ............................................................................................................................... 37 Table 5: Serbian Pilot - Internal Business Process - KPIs with Target Values, Rationale and Measurement
Process ...................................................................................................................................................... 38 Table 6: Serbian Pilot - Learning and Growth - KPIs with Target Values, Rationale and Measurement
Process Measurement Process .................................................................................................................. 39 Table 7: Roadmap of Smart Public Transport test case ................................................................................... 39 Table 8: Roadmap of Smart Traffic test case .................................................................................................. 57
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 7 of (59)
List of Figures
Figure 1: Location of the Pleiades building ..................................................................................................... 12 Figure 2: Photo of Smart Building .................................................................................................................. 13 Figure 3: Test area in the fourth floor of Pleiades building. ............................................................................ 14 Figure 4: Test Case to Retrieve values in Smart Building ............................................................................... 19 Figure 5: Test Case of Actuation for legacy building equipment .................................................................... 21 Figure 6: Test Case to subscribe information in Smart Building .................................................................... 22 Figure 7: Smart public transport scenario ........................................................................................................ 25 Figure 8: City of Novi Sad, Serbia .................................................................................................................. 26 Figure 9 : Line 2 – City bus transport .............................................................................................................. 26 Figure 10: Pilot architecture for the Smart Public transport in Novi Sad ........................................................ 27 Figure 11: Components’ interaction diagram for Security & Privacy framework .......................................... 28 Figure 12: Secure device registration .............................................................................................................. 34 Figure 13: Secure data upload ......................................................................................................................... 35 Figure 14: Secure data retrieval ....................................................................................................................... 35 Figure 15: Location of Frankfurt (Oder) ......................................................................................................... 40 Figure 16: inner city area of Frankfurt (Oder) ................................................................................................. 41 Figure 17: Mockup of the web application map view ..................................................................................... 45 Figure 18: Overview receive traffic data test case........................................................................................... 47 Figure 19: Sequence diagram Receive traffic data test case ............................................................................ 49 Figure 20: Overview sign actuation test case .................................................................................................. 50 Figure 21: Sequence diagram sign actuation test case..................................................................................... 52 Figure 22: Overview Emergency event test case ............................................................................................. 53 Figure 23: Sequence diagram of emergency event test case ........................................................................... 55
SMARTIE Deliverable D6.1
Page 8 of (59) © SMARTIE consortium 2015
Abbreviations
6LoWPAN IPv6 over Low power Wireless Personal Area Network
AR Augmented Reality
CoAP Constrained Application Protocol
DTLS Datagram Transport Layer Security
ECC Elliptic Curve Cryptography
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
HVAC Heating, Ventilation and Air Conditioning
IoT Internet of Things
IP Internet Protocol
LED Light Emitting Diode
M2M Machine-to-Machine
MQTT Message Queue Telemetry Transport
REST Representational State Transfer
TLS Transport Layer Security
UDP User Datagram Protocol
URL Uniform Resource Locator
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 9 of (59)
1 Introduction
This deliverable presents the scenario screenplays for the planned real world tests taking into account outputs
from WP2-WP5. Several test scenarios were designed with the integrated components of WP5. These
scenarios will be implemented in three real world demonstrator sites in Murcia, Novi Sad and Frankfurt
(Oder). This document will be input for the detailed test specification in D6.2 and the deployment of the real
world tests.
The deliverable describes every testbed in detail. It shows which SMARTIE components will be evaluated in
the different test sites and which devices are relevant for the scenario. For each scenario several test cases are
outlined to evaluate the functionality of the SMARTIE platform in real world applications.
1.1 Relation to S&T Objectives
This deliverable is defining the SMARTIE components and mechanisms that will be implemented in real
world environments. It declares the goals of the project partners in transfer the outputs of WP 3& WP 4 into
concrete prototypical applications. Therefore this deliverable is essential for achieving Objective O5
“Demonstrate the project results in real use cases.”
1.2 Beyond State-of-the-Art Contributions
As this deliverable is the foundation for the real world demonstrators, it is not directly contributing to the
state of the art and also not beyond state of the art. However if the test scenarios could be implemented
successfully, they will prove the functionality of the integrated SMARTIE components in an IoT platform,
which will go beyond state-of-the-art.
SMARTIE Deliverable D6.1
Page 10 of (59) © SMARTIE consortium 2015
2 Overview
2.1 Purpose and Scope of the WP6
The purpose of WP6 is the specification and implementation of real world test scenarios. These test scenarios
lean on the use cases defined in WP2. The test scenarios are specified in detail and are evaluated in several
test cases. This will finally result in an experience report with technical data and assessment of the
functionalities.
2.2 Purpose and Scope of Task T6.1
This task aims to realize concrete scenarios selected from the use cases (WP2) in real word tests. The use
case scenarios will be refined and concrete data & applications to be realized in real world tests will be
selected. This leads to screenplays for the test runs.
In addition, score sheets to gather feedback from end users will be developed (those will be used in Task
6.3).
The following activities are expected to take place in this task:
selection of the use case scenarios to realize
definition of the concrete test scenarios for every demonstrator site
detailed specification of test scenarios
definition of assessment criteria and measurements
2.3 Purpose and Scope of the Document
The purpose of this document is to provide a description of the test scenarios, relevant components and
timing of deployment including:
Description of test sites
Use of relevant components in test scenarios
Validation and evaluation criteria
Time schedule for deployment
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 11 of (59)
3 Scenario Screenplays
The following subchapters provide a first description of each of the three test scenarios, with all of its
involved components. For every test scenario the planned test cases are defined in detail, the assessment
criteria are explained and the roadmap for every scenario is outlined.
3.1 SMARTIE components used in the test beds
The following chapter gives a technical overview of the developed SMARTIE components, which are used
in at least one of the test scenarios.
DCapBAC provides a distributed scheme for the generation and verification of capability tokens
which will be used to send the authorizations with the query from the user to subscribe to a topic or
request an actuation in IoT devices.
XACML enables the Policy Decision Point and is in charge of resolving the authorization decision
from a user to obtain a capability token for the access to IoT resources and services.
CP-ABE is used as a ciphering schema enabling a user to receive the information ciphered according
to privacy policies.
SmartData platform provides functionalities that extend the innovative components developed by the
project. It allows a common framework to integrate the components in order to be tested in a
complete end-to-end IoT environment.
shortECC is an optimized library that enables elliptic curves for constrained devices. The approach
provides security mechanisms such as encryption and digital signature.
Distributed Kerberos is used to achieve a high security level when Kerberos tickets or related access
tokens are created in an outsourced platform. The purpose is that a Kerberos ticket authenticates to
user to a device and at the same time establishes a session key.
Resource directory (RD) with secure storage provides a permanent storage of resource descriptions.
It provides an instant access to the description/properties of IoT devices stored in the directory. It
stores attributes such as physical address, status, location, capability etc. It has a modular
architecture - high cohesion and loose coupling of parts as well as the flexible resource description
model.
lwsCoAP (with shortECC) provides secure transmission of data from IoT devices to the backend
cloud platform (for constrained low-power nodes and networks)
SMARTIE Deliverable D6.1
Page 12 of (59) © SMARTIE consortium 2015
3.2 Real World Test 1: Smart Building Management
The Smart Building Management test has been designed to provide a distributed, interoperable, secure and
IoT-compatible solution to the management of smart buildings. In this context, several subsystems can be
accessed in order to get the real-time information required to make decisions, as well as the set of actuators
(both legacy and IP devices) which can be used to modify the conditions of the area.
As smart buildings are becoming more and more popular, having a platform capable of providing
mechanisms to control the set of available devices is required. Furthermore, by using standard protocols, the
system offers an interface for external users to make decisions remotely if needed, in case the platform hasn’t
been deployed in the building itself. As a result, information from different sources can be aggregated to
make more efficient decisions, once the decision process has a wider perspective of the whole scenario.
This scenario addresses the secure management of smart buildings through the cross-domain integration of
SMARTIE components. It intends to demonstrate the benefits of the SMARTIE components to guarantee the
secure management of IoT buildings through mobile phones, IoT devices and a SmartData platform.
This scenario presents a situation within a smart building, where users can use mobile phones to be
authenticated and request authorization credentials to the SmartData platform in order to enable secure end-
to-end communication with IoT devices deployed in the building. So, user can subscribe to monitoring topics
about energy and comfort parameters of the building and request actuations for improving the efficiency and
comfort according to the user’s needs.
3.2.1 Description of the test field
The specific test area is a smart building belonging to the University of Murcia (UMU) in the Campus de
Espinardo located in the Murcia region (see next figure). The UMU has several smart buildings to improve
the energy efficiency and security by means of telecontrol and monitoring systems. In particular, a building
called Pleiades has eight floors with an area of 6.500 m². The following images show the map of University
of Murcia and the Pleiades building.
Figure 1: Location of the Pleiades building
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 13 of (59)
Figure 2: Photo of Smart Building
This test area is located in the fourth floor of the Pleiades building (see Figure 3). It is one of the many
buildings being monitored at the University of Murcia, although this is the most advanced one in terms of
automation and types of technologies installed. The Pleiades building contains different legacy systems for
lighting, air-conditioning, solar-panels, anti-fire and anti-thief.
For the tests, Pleiades is a fully monitored and automated building with some areas using common services,
such as a centralized HVAC system for corridors, but at the same time with some rooms having their own
devices. Despite not having the same amount of automated devices in all the rooms, the scenario is going to
include one room with an IoT gateway and an IoT sensor so that both can be accessed through SMARTIE in
the same way, as well as an air conditioning unit.
SMARTIE Deliverable D6.1
Page 14 of (59) © SMARTIE consortium 2015
Figure 3: Test area in the fourth floor of Pleiades building.
3.2.2 Relevant SMARTIE components
In the smart building scenario, we will test and validate the following components provided by work
packages WP2-WP4.
DCapBAC: In smart building scenario, the purpose is that the capability token will be included
within a DTLS-COAP message. The DCapBAC will be deployed for three entities: User to request
the tokens, Capability Manager to generate the tokens and IoT devices to validate the tokens.
XACML: In smart building scenario, the purpose is that the XACML will be included into
Capability Manager, to check the authorization of a user before providing a capability token.
CP-ABE: In smart building scenario, the purpose is that the user is able to decipher the information
with his keys. This will be implemented for the platform to cipher information and for the user to
decipher the information.
SmartData platform: In smart building scenario, the purpose is that this platform will include three
entities: Capability Manager, Policy Decision Point and Topic Manager.
shortECC: . In smart building scenario, the purpose is that the elliptic curve will be included in the
DCapBAC scheme for the Capability Manager to sign the generated tokens and for the IoT devices
to verify the signature of tokens.
Distributed Kerberos: In smart building scenario can be combined with capability tokens to provide
authorization for smart building equipment.
3.2.3 Standard Protocols to Be Used
For the real world tests of the Smart building use case, we need to use standard protocols that enable
essential communication functionalities at network and application layers.
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 15 of (59)
1. 6LoWPAN is a network protocol that enables the use of IPv6 on high constrained devices in wireless
networks like IEEE 802.15.4. 6LoWPAN implements addressing, fragmentation, and header
compression of IPv6 protocol. The 6LoWPAN implementation is based on RFC4944 (Transmission
of IPv6 Packets over IEEE 802.15.4 Networks), the Internet draft “Interoperability Test for
6LoWPAN”, and the Internet draft “Compression format for IPv6 datagram in 6LoWPAN
Networks”.
2. COAP is an optimized web protocol for use with constrained nodes and constrained networks in the
Internet of Things. The protocol is designed for machine-to-machine (M2M) applications such as
smart energy and building automation. CoAP is based on the wildly successful REST model: Servers
make resources available under a URL, and clients access these resources using methods such as
GET, PUT, POST, and DELETE.
3. DTLS is a network protocol based on TLS that is capable of securing the communication among
entities for UDP datagram transport. DTLS provides the security services such as integrity,
authentication and confidentiality. The integration of CoAP and DTLS is defined in RFC7252 with
the minimal appropriate configurations for constrained devices and networks.
4. REST: All the services provided by the SmartData platform support REST. The applications
consuming the data provided by the subscribed topics must implement REST as it is the only
interface supported by the platform at the northbound.
3.2.4 Description of test cases
This section specifies the test cases implemented in the real world scenario and describes the devices and
equipment deployed in Pleiades building.
3.2.4.1 Devices and equipment in smart building.
This subsection describes the devices and equipment to be deployed in Pleiades building for the real world
tests.
3.2.4.1.1 Building Management System
In the hierarchy of the UMU deployment, the top element is an open platform called Building Management
System, which acts as entry point where the information is gathered from the devices installed in the
building.
It can interact with IP devices, including IoT gateways, IoT sensors and other legacy machines which are
also accessible through IP ↔ legacy buses converters. In fact, one of the elements of the test bed is the air
conditioning unit of the room, which is integrated through a RS-485 Modbus card. In this case the adapter is
an Ethernet ↔ RS-485 converter, and the Building Management System will handle this communication.
The Building Management System can interoperate with the SmartData platform using open standard
protocols such as CoAP, MQTT and REST. CoAP and MQTT would be the preferred options so that the
way to access to the devices is the same as in IoT gateways.
3.2.4.1.2 IoT Gateways
This is the intermediate level unit in building deployment in terms of performance. IoT gateways are
developed by UMU researchers. IoT gateways are µC-powered boards which act as adapters for legacy
devices attached to inputs and outputs, as well as for other devices which communicate using some standard
protocols such as Modbus through industrial interfaces, like RS-485.
Regarding the access to legacy wired devices in this specific scenario, these gateways offer control to data
from:
Humidity, temperature and luminosity sensors (Modbus over RS-485).
SMARTIE Deliverable D6.1
Page 16 of (59) © SMARTIE consortium 2015
Power meters (Modbus over RS-485).
Digital actuators as light on/off switches.
Motion detectors.
The board includes a 32-bit MIPS µC running at 80 MHz, with 16 inputs/outputs configurable by software as
analogue or digital, two RS-232 ports, one RS-485 port, Can BUS and Ethernet compatible with IPv4 and
IPv6.From the IoT compatibility perspective, gateways provide CoAP and MQTT support.
3.2.4.1.3 IoT sensors (6LowPAN)
An IoT sensor is the most constrained unit of the building deployment. IoT sensors are developed by UMU
researchers. These IoT sensors are the result of combining a 16-bit µC running at 8 MHz with extra
connectors for legacy devices to support analogue inputs, digital inputs and digital outputs. In terms of
connectivity, it has a802.15.4/6LowPAN interface and supports CoAP. For example, one purpose is to
indicate if the room’s window is open or not in the scenario, with this information being used to reduce the
consumption derived of the HVAC unit when it’s open. On the other hand, other purpose is to provide the
temperature and humidity of the test room.
3.2.4.1.4 Ethernet ↔ 6LowPAN bridges
In order to access to IoT wireless sensors, some kind of bridge is necessary. The bridges are developed by
UMU researchers. Their purpose is to forward packets between 6LowPAN wireless network and Ethernet
connection. In the 6LowPAN wireless network, they act as routers, sending Router Advertisements to notify
the sensors of available routers (themselves) and IPv6 prefixes, as expected in IPv6 networks. The bridge
includes a 16-bit µC running at 16 MHz, with Ethernet and 802.15.4 links. The Ethernet interface is
compatible with IPv4 and IPv6 while the radio interface supports 6LowPAN.
3.2.4.1.5 Power meters
Using power meters is mandatory in the management of a smart building if you want to analyse the power
consumption of different subsystems. Otherwise, there’s no way to know which systems are working
properly and what can be improved in terms of efficiency. Besides, it can be used to detect malfunctions
whenever the measurements obtained don’t make sense for some reason.
For the test room, the overall consumption is going to be measured, as well as the power usage of the
lighting subsystem. In both cases, readings from single-phased meters is available, offering information such
as voltage, current or energy. Still, in this particular case it’s a bit too complicated to determine the power
usage of a specific room regarding the HVAC system as it relies on several outdoor units to heat up or cool
multiple rooms at the same time.
3.2.4.1.6 Legacy sensors/actuators
Considering that few manufacturers offer native IP sensors nowadays, it’s very common to rely on standard
legacy sensors. The way to access them in an IoT-compatible environment is by connecting these
sensors/actuators to a board acting as adapter, so that you can get or modify their status through an IoT
protocol.
For this specific scenario, in the end both gateways and IP sensors are going to have legacy devices attached.
Among them, there are:
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 17 of (59)
Digital humidity, temperature and luminosity sensors, used to obtain the information required to
make decisions from comfort and power efficiency perspectives.
Digital actuators, used to switch lights on and off depending on whether there are people in the room
or not, and whether the current amount of light is enough to fulfil the expected requirements.
Motion detectors, a key piece when trying to optimize energy consumption, as some systems can be
switched off when no one needs them.
Magnetic contacts to indicate if windows are open or not.
3.2.4.1.7 HVAC
As mentioned before, in the building there is a set of outdoor HVAC units, connected to a to every single
indoor split providing a room-level control.
In order to interact with the units, two RS-485 cards act as bridges between the manufacturer’s internal
proprietary protocol and Modbus. Given the amount of splits installed in the building (about 100), having
one card per split wouldn’t make sense, as each card provides access to 64 units.
For each unit the available resources will be:
On/off.
Operation mode (heat, cool, vent, dry, auto).
Set temperature (from 10 to 40ºC).
Vent speed (stop, auto, fast, med, slow, ultra slow).
3.2.4.1.8 Smart Phone
For the tests, an UMU application will be deployed in a smart phone to act as client part of the SmartData
platform. The UMU application can be deployed in any smart phone with Android operation system. The
main functionalities of the mobile phone will be:
Access control in the SmartData platform before M2M communication with smart things.
Retrieve sensor values from IoT sensors.
Actuation with legacy equipment through IoT gateways.
Subscription for maintenance information of legacy equipment.
3.2.4.2 Participating users/roles including SMARTIE components
IoT Sensors and IoT Gateways are embedded devices that provide the monitored information (i.e.
temperature, humidity, power consumption, etc.) and allow applying the actuation over the legacy
equipment of the smart building (i.e. HVAC, lighting, etc.). They will receive the information and
actuation queries with authorization tokens to verify the access to the resources and services.
Users may subscribe the information collected by sensors and may request the actuation of gateways
over legacy equipment. To do that, the users employ the Android application to be authenticated in
the SmartData platform and obtain the capability tokens for the M2M communication with IoT
devices.
Capability Manager is an entity within the SmartData platform that generates the capability tokens
for enabling a user to interact with an IoT device, for information or actuation.
SMARTIE Deliverable D6.1
Page 18 of (59) © SMARTIE consortium 2015
Policy Decision Point is an entity within the SmartData platform that checks the authorization of a
user for access to an IoT device and takes the decision of sending a capability token generated by
Capability Manager.
Topic Manager is an entity within the SmartData platform with the responsibility of managing the
information provided by the sensors. It acts as broker to enable the subscription of users and
publishing the information from sensors.
3.2.4.3 Test Cases in Smart Building.
This section describes the test cases to be validated in the real world scenario of Smart Building in Murcia.
Each test case shows the devices, parameters and events that participate in the validation of the SMARTIE
components. The proposed test cases are:
Retrieve sensors values: This test case shows how a user is able to obtain the parameters measured
(i.e. temperature, humidity, etc.) by an IoT sensor or legacy devices (i.e. HVAC) through an IoT
gateway.
Actuation for legacy building equipment: This test case is similar to the retrieve interaction, with the
difference that an IoT gateway modifies or alters the state of the legacy equipment in the building
(i.e. switching off lights).
Subscribe for maintenance information of legacy equipment: This test case shows how a user can
request some kinds of information (i.e. HVAC operation mode, power consumption, etc.) and
receive that information as soon as is generated. This test case validates the interaction with the
Building Management System that manages complex legacy equipment, such as HVAC in the
Pleiades building.
Actuation using Kerberos: This test case will also modify the state of equipment in the building.
However, the focus in on the generation of a Kerberos ticket, and the use of the ticket to set up
encrypted communication.
These test cases are described in detail in the next subsections.
3.2.4.3.1 Test Case to Retrieve values in Smart Building
This subsection describes the test case to validate the retrieve interaction from users through the SmartData
platform and IoT sensors, in order to obtain relevant information about the building conditions in a real
world scenario. For instance, the user can request the temperature value of an IoT sensor.
Test Case (real world level)
TC name Retrieve Sensors Values
Preconditions a. SmartData platform including Capability Manager and Policy Decision Point.
b. User with smart phone application including Capability client of DCapBAC
component.
c. IoT Sensor including Capability server of DCapBAC component.
Execution 1. The user employs the Android application to send a query to the Capability
Manager for a capability token to retrieve a sensor value from a IoT sensor. This
query contains the IPv6 address of the IoT sensor as well as the object or
resource requested.
2. To do that, the Android application initiates a DTLS exchange to establish a
secure communication channel with the Capability Manager in SmartData
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 19 of (59)
platform.
3. The Capability Manger authenticates the user credential to access the
temperature value.
4. If the authentication is successful then the manager sends a XACML query to
the PDP to check the authorization of the value requested by the user.
5. The Capability Manager receives a XACML Response indicating if the query is
Permitted or Denied.
6. When the query is permitted, the Capability Manager generates the capability
token and sends it back to the Android application.
7. With the capability token stored in Android application, the user is able to
establish a secure end-to-end communication with the IoT sensor.
8. To perform a secure communication, the Android application starts a DTLS
exchange with the IoT sensor and sends a CoAP query with the capability token
containing the temperature requested.
9. Then the IoT sensor is able to verify the sign of the capability token.
10. If the token is valid, the IoT sensor measures the temperature requested and
sends the information towards the Android application.
Expected
results
The user receives the value requested to the IoT sensor. Otherwise, the access can be
denied if the user credential has not permission to access the temperature value of the
IoT sensor in SmartData platform.
Expected
completion
M28
Figure 4: Test Case to Retrieve values in Smart Building
SMARTIE Deliverable D6.1
Page 20 of (59) © SMARTIE consortium 2015
3.2.4.3.2 Test Case of Actuation in Smart Building
This subsection describes the test case for the validation of the actuation from users to the SmartData
platform, in order to modify the behaviour of legacy building equipment in a real world scenario. For
example, the user can request to switch off legacy lights through an IoT gateway.
Test Case (real world level)
TC name Actuation for legacy building equipment
Preconditions a. SmartData platform including Capability Manager and Policy Decision Point.
b. User with smart phone application including Capability client of DCapBAC
component
c. IoT Gateway including Capability server of DCapBAC component.
d. Light is managed by the IoT gateway.
Execution 1. The user employs the Android application to send a query to the Capability
Manager for a capability token to switch off the light connected to the IoT
gateway.
2. This query contains the IPv6 address of the IoT gateway as well as the action
requested (swith off light).
3. To do that, the Android application initiates a DTLS exchange to establish a
secure communication channel with the Capability Manager in SmartData
platform.
4. The Capability Manger authenticates the user credential to switch off the light.
5. If the authentication is successful then the manager sends a XACML query to
the PDP to check the authorization of the action requested.
6. The Capability Manager receives a XACML Response that indicating if the
query is Permitted or Denied.
7. When the query is permitted, the Capability Manager generates the capability
token and sends it back to the Android application.
8. With the capability token stored in Android application, the user is able to
establish a secure end-to-end communication with the IoT gateway.
9. To perform a secure communication, the Android application starts a DTLS
exchange with the IoT gateway and sends a CoAP query with the capability
token containing the switch-off action.
10. Then the IoT gateway is able to verify the sign of the capability token.
11. If the token is valid, the IoT gateway switching off the light sends a confirmation
message towards the Android application.
Expected
results
The user achieves to switch off the light of the room. Otherwise, the access can be
denied if the user credential has not permission to access the light resource of IoT
gateway in SmartData platform.
Expected
completion
M29
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 21 of (59)
Figure 5: Test Case of Actuation for legacy building equipment
3.2.4.3.3 Test Case to Subscribe information in Smart Building
This subsection describes the test case for the validation of the subscription from users to the SmartData
platform, in order to access the published information of legacy equipment, connected via industrial protocol
Modbus to the Building Management System in a real world scenario. For example, the user can request to
subscribe the information generated by HVAC, in order to tele-control the states and the maintenance.
Test Case (real world level)
TC name Subscribe for maintenance information of legacy equipment
Preconditions a. SmartData platform including Capability Manager, Policy Decision Point and Topic
Manager.
b. User with Android application including Capability client of DCapBAC component
c. Building Management System including Capability server of DCapBAC component.
d. HVAC is managed by the Building Management System.
Execution 1. The Topic Manager will request the Capability Manager for a capability token,
in order to enable the M2M communication with the Building Management
System.
2. With this capability token, the Topic Manager will send a query to the Building
Management System for subscribing to the given topic (i.e. state of the HVAC in
the specified room).
3. If the subscription was successful, The HVAC information collected by Building
Management System is published to the Topic Manager.
4. At this point, the user is able to subscribe to the topic of HVAC state provided
by the Topic Manager. To do that, a DTLS connection is established towards the
SMARTIE Deliverable D6.1
Page 22 of (59) © SMARTIE consortium 2015
Topic Manager.
5. The Topic Manager authenticates the user credential and asks the PDP if the user
is authorized to perform the mentioned subscription.
6. If the PDP responds an acceptation message, then the Topic Manager sends a
confirmation to the user.
7. If the subscription was successful, each time the Topic Manager receives the
HVAC information published by Building Management System; such data is
transmitted to the user.
8. The Topic Manager will cipher the information with CP-ABE according to some
policies in order to send the data ciphered towards the user.
9. The user will decipher the mentioned information with its keys.
Expected
results
The user subscribes the topic of HVAC state in the tested room in order to receive
periodic information from Topic Manager. Otherwise, the access can be denied if the
user credential has not permission to access this IoT resource in SmartData platform.
Expected
completion
M30
Figure 6: Test Case to subscribe information in Smart Building
3.2.4.3.4 Actuation with Distributed Kerberos component.
This subsection describes the test case for the validation of the actuation using Kerberos key establishment
for authentication and encryption of the communication. This is suitable for lightweight components that
perform critical actuation in a real world scenario. For example, the user can request to unlock a door.
Test Case (real world level)
TC name Actuation using Distributed Kerberos
Preconditions a. User and device are registered with the Kerberos component.
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 23 of (59)
b. Device with a relay to unlock a door.
c. Kerberos servers obtain DCapBAC capabilities from Capability server.
Execution 0. If not done, the device creates a key and registers the key with the Kerberos
servers using a bootstrap procedure.
1. The user uses a Java or Android application to authenticate to the Kerberos
authentication service.
2. The user requests an access ticket for the device, providing the device ID to the
Kerberos ticket service.
3. The user extracts the communication key from the ticket and starts an encrypted
session with the device to request unlocking a door.
4. The device processes the received message and decrypts the embedded
capability token.
5. If the request is permitted, the device unlocks the door and sends an encrypted
confirmation message back to the user.
Expected
results
The user achieves to unlock a door. The communication between user and device is
encrypted with Kerberos. A capability token is encoded in the Kerberos ticket, and the
actuation is denied if the user does not have the required.
Expected
completion
M30
3.2.5 Assessment criteria
The evaluation process is focused on two main aspects: user assessment and technical validation. These
aspects are described in the following subsection.
3.2.5.1 User assessment
Name Description measurement
Friendly user-application
Design of any user interface
(apps/websites etc.) has to be
user friendly and easy to
understand
User survey
Range of functions Application must provide the
functionalities the user expects User survey
Easy configuration Application must allow easy user
configuration. User survey
Response time The response to a user request
should be delivered in proper
time
User survey
Monitor response time
Availability Application must be always
available. User Survey
Availability
measurements
SMARTIE Deliverable D6.1
Page 24 of (59) © SMARTIE consortium 2015
3.2.5.2 Technical validation
Name description measurement
Authentication Participants of the message
exchanges are authenticated
through the mechanisms of
DCapBAC, XACML and
shortECC
Test with not
authenticated request
Integrity The messages transmitted cannot
be modified during DTLS
transportation.
Design and run man-in-
the-middle attacks
Freshness The received messages cannot be
the retransmission of previous
messages through capability
tokens.
Check that retransmitted
messages are discarded
as invalid.
Privacy/Confidentiality The content of the messages may
be made legible only to
authorized entities through CP-
ABE
Check that the messages
are illegible
Small size of protocols Small size implementations for
embedded devices with 16KB
RAM and 100KB Flash.
Check the small size of
protocols
Reliability Good delivery rates in end-to-end
communications Logging of sent and
received data and
evaluate possible losts.
Low latency Low latency time in the end-to-
end transmission communication Monitor the end-to-end
latency
Scalability High number of resources and
services can be managed by the
SMARTIE platform
Run of test cases with
simulated components,
measure data loss
3.2.6 Test scenario roadmap
In this section, we present the timing for validating the defined test cases in Pleiades building in Murcia.
Table 1: Roadmap for smart building test scenario
Test Scenario M25 M26 M27 M28 M29 M30
1. Retrieve sensor values
2. Actuation for legacy building equipment
3. Subscribe for maintenance information
4. Secure bootstrapping with Distributed Kerberos
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 25 of (59)
3.3 Real World Test 2: Smart Public Transport
The Smart Public Transport pilot aims to improve the management of the public transportation network
in the city of Novi Sad, starting from the Public City Bus Transport Network, with the intention to
extend it to other transport means and networks and thus promote and encourage the greater use of
sustainable transport modes.
It has therefore been designed to provide a secure, interoperable and multimodal IoT compatible solution
for the public transport management providing time and cost benefits to travellers.
The intention here is to demonstrate a secure management of public transport and other services
provided to transport users and providers, through a cross domain integration of SMARTIE components
mobile phones, IoT devices, and SmartData platform.
The scenario demonstrates how the users can use their mobile phones to securely access registered IoT
resources deployed within the platform utilising security related components, such as the capability
manager..
The main features of the deployed pilot available to smartphone users include:
1. Getting real time information on bus arrival times
2. Real time pollution data at particular spot in the city
3. Travel ticket purchase via mobile phone app (not in full control of the SMARTIE platform)
Figure 7: Smart public transport scenario
SMARTIE Deliverable D6.1
Page 26 of (59) © SMARTIE consortium 2015
3.3.1 Description of the test field
The Smart Public Transport testbed is set in the City of Novi Sad in Serbia, Figure 8, and covers one city bus
line and busses used on that line as shown in Figure 9.
Figure 8: City of Novi Sad, Serbia
Figure 9 : Line 2 – City bus transport
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 27 of (59)
3.3.2 Technical Description of the components
In the smart public transport scenario, we will test and validate components provided by work packages
WP2-WP4, which are presented within the pilot architecture illustrated in Figure 10Figure 10.
Figure 10: Pilot architecture for the Smart Public transport in Novi Sad
The pilot architecture, as presented in Figure 10, shows different layers in the system architecture and
interaction between them.
The infrastructure layer represents a central part of the platform, where the system value is created through
provision of a range of services. Users access the services via smart mobile app (or web portal) and get
information collected by the platform through the IoT device layer.
Secure aspects of this system, including the access control, protection of data and users' privacy, are part of
the Security and Privacy framework within the infrastructure layer. These aspects include:
Secure device registration.
Secure data transfer between IoT devices and backend infrastructure.
Access to information on location of public vehicles and air pollution to system users according to
access policy and privacy rules.
SMARTIE Deliverable D6.1
Page 28 of (59) © SMARTIE consortium 2015
Secure ticket purchase
Mobile ticketing and payment is realised through the mTicketingAR platform
utilising QR codes, Augmented Reality (AR) and optical validation. Combination of these technologies
enable travellers to access various services and information within the public transport including the ticket
purchase. The payment is enabled through the mPayment platform, which enables secure transfer of funds to
another service provider account using a mobile phone. Once the payment is authorized, the ticket is sent
electronically to the mobile phone as a 2D bar code, which is optically validated at the start of service use.
SMARTIE components to be deployed within the pilot are Capability Manager, DcapBAC, lwsCoaP (with
shortECC) and secure RD with secure storage as part of the Security and Privacy framework. SMARTIE
components will improve security mechanisms in public transportation pilot. A more detailed view of this
framework is illustrated in Figure 11. The added value through using the SMARTIE components is to
increase the security aspects of the entire platform such as improved and more efficient user authentication
leading to the potential reduction of the fraud, more secure transfer of sensitive data such as air pollution
information owed by the City of Novi Sad.
Figure 11: Components’ interaction diagram for Security & Privacy framework
3.3.3 Relevant SMARTIE components
In the smart traffic scenario, we will test and validate the following components provided by work packages
WP2-WP4.
DCapBAC: Access control decisions through generation and verification of capability tokens.
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 29 of (59)
Capability Manager generates capability tokens for uses and devices registering to the platform.
This enables entities to access or interact with devices and web services
lwsCoAP (with shortECC): Secure transmission of data from IoT devices to the backend cloud
platform (for constrained low-power nodes and networks).
Secure RD with secure storage: System supporting secure registration of IoT devices and storage
of all information about IoT objects, resources and services together with all relevant data. It enables
efficient search and discovery of resources and services supported by secure storage and user
authentication.
Novi Sad Pilot leverages SMARTIE components to ensure the required functionalities in each of the
anticipated pilot usage scenarios.
For each of the pilot functionalities, a different group of SMARTIE components will be used which is
specified in Fehler! Verweisquelle konnte nicht gefunden werden.
Table 2: Use of SMARTIE components for achieving different smart transport pilot functionalities
Functionality/purpose (in the
scenario)
SMARTIE components used
DcapBAC Capability
Manager
lwsCoAP
(shortECC)
Secure RD
with secure
storage
Secure data transfer between IoT devices
and the backend infrastructure following
secure device registration to the platform.
X x x
Access to information on location of public
vehicles by system users according to
access policy and privacy rules
x x
Access to air pollution data by system users
according to access policy and privacy
rules
x x
Secure ticket purchase x
Legacy systems to be integrated within the platform include RPi800 device with sensors; RD, Virtual
Resource Unit; sCoAP, DTLS.
The main constrains of the system can be caused by CPU and RAM of RD, as well as a data uploading
frequency of Rpi800.
3.3.4 Standard protocols to be used
For the test scenario planned in Novi Sad, the following protocols are utilised within the system:
CoAP is used between ekoNET devices and the REP component at the server side for the data
transfer of sensor measurements related to the environmental parameters. The underlying protocol
utilised in CoAP is UDP
DTLS is utilised for the secure transfer within the CoAP communication and it is based on ECC
technology and possibly on shortECC component
SMARTIE Deliverable D6.1
Page 30 of (59) © SMARTIE consortium 2015
HTTPs is utilised for the communication between mobile application and mTicketing back-end
infrastructure
Proprietary REST protocol is utilised for the communication between fleetNET devices and back-
end platform and REP handler for which the appropriate protocol adapter has been developed
3.3.5 Description of test cases
This section provides specification and description of test cases implemented within the three selected
scenarios.
Considered pilot scenarios include the following:
1. Pilot Scenario 1: Getting information on bus arrival times
2. Pilot Scenario 2: Environment and pollution data at particular spot in the city
3. Pilot Scenario 3: Travel ticket purchase via mobile phone app (requires authentication
by the SMARTIE platform)
3.3.5.1 Participating users/roles including SMARTIE components
Participating users/roles identified include:
1. User (Traveller with a smart phone - android or iOS)
2. Platform (PTIN and DNET)
3. IoT devices (ekoNET and fleetNET)
4. Services for data access
3.3.5.2 Pilot scenarios corresponding test cases
Pilot Scenario 1
Accessing information on bus arrival time
Involves interactions of the platform with fleetNET device and users (via smart mobile app)
SERVICE TYPE TEST CASES
Device side: Info on bus arrival time 1. fleetNET registration to RD
2. Data upload
User side: Info on bus arrival time 3. User access to the platform (user
authentication via DCapBAC)
4. Service search via RD
5. REP web service access and data retrieval
6. Data visualisation
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 31 of (59)
Pilot Scenario 2
Accessing information on air quality/pollution
Involves interactions of the platform with ekoNET device and users (via smart mobile app)
SERVICE TYPE TEST CASES
Device side: Air quality measurements 1. Secure ekoNET device registration to RD
(and secure storage)
2. Data upload (via sCoAP )
User side: Air quality service usage
3. User access to the platform (user
authentication via DCapBAC)
4. Service search via RD
5. REP web service access and data retrieval
6. Data visualisation
Pilot Scenario 3
Ticket selection and payment request
Involves interactions of the mTicketing and mPayment framework within the platform with the
Security and Privacy framework, as well as with the 3rd
party payment services (via smart mobile
app)
SERVICE TYPE TEST CASES
User side: Ticket purchase
1. User authentication using DCapBAC tokens to
enable ticket purchase
Device side: Payment realisation
2. Payment via 3rd
party services
3.3.5.3 Test case implementation details
Test Case (real world level)
TC name PS1/ TC1: fleetNET registration to RD
Register fleetNET device to Resource Directory integrated within the SmartData
platform
Preconditions a. SMARTIE Platform including RD and Capability Manager
b. IoT device (fleetNET) including secure CoAP component
SMARTIE Deliverable D6.1
Page 32 of (59) © SMARTIE consortium 2015
c. Capability server of DCapBAC component
Execution 1. Capability Manager (PDP) is updated with the fleetNET device ID
2. A fleetNET device is deployed on a bus
3. fleetNET device initiates a session with RD in order to register
4. RD communicates with Capability Manager using fleetNET device ID
5. The Capability Manager authenticates the device and checks authorisation to
register to the RD and publish data to the platform.
6. If the authentication is successful, the RD receives a capability token from
Capability Manager. With this token, the RD allows device to register and
publish meta data to the platform
Expected
results
fleetNET device registers to the platform and provides meta data containing types of
sensors, locations, IDs. Following the successful registration, the applications and other
components are able to discover the associated fleetNET device.
Expected
completion
M28
Test Case (real world level)
TC name PS1/ TC2: Data upload
Preconditions a. SmartData platform including Capability Manager and Policy Decision Point (PDP).
b. ekoNET devices with secure CoAP component
c. REP including Capability server of DCapBAC component
Execution 1. The ekoNET device establishes a secure connection with REP in order to upload
the data
2. The REP handler sends a query to the Capability Manager for a capability token
to retrieve a sensor value from a REP handler. This query contains the ID of the
device.
3. If the device is authorised to store the data, REP handler receives the token.
4. The token is then used by the REP handler to store the data.
Expected
results
The data from the ekoNET sensors are stored in the associated secure storage
Expected
completion
M28
Test Case (real world level)
TC name PS1/ TC4: Service search via RD
Preconditions a. SMARTIE Platform including RD and Capability Manager
b. IoT device (ekoNET) including secure CoAP component
c. Capability server of DCapBAC component
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 33 of (59)
Execution 1. An application (user) is requesting environmental data for the area. The application
requests a capability token for authenticating and authorizing the user.
2. The application requests from the RD for active ekoNET devices on a certain route
or in a certain area.
3. The RD checks with Capability Manager if the application (user) is authorised to
retrieve this information.
4. In case user is authorised, the RD sends the list of devices together with the token
which can be used to retrieve the data.
Expected
results
The application shows the environmental data within the mTicketing service.
Expected
completion
M29
Test Case (real world level)
TC name PS1/ TC5: REP web service access and data retrieval
Preconditions a. SmartData platform including Capability Manager and Policy Decision Point (PDP).
b. Application including Capability client of DCapBAC component
c. REP including Capability server of DCapBAC component
Execution 1. The application sends a query to the Capability Manager for a capability token to
retrieve a sensor value from a REP handler. This query contains the URL of the
device as well as the value requested.
2. To do that, the application initiates a HTTPS exchange to establish a secure
communication channel with the Capability Manager in SmartData platform.
3. The Capability Manger authenticates the user credential to access the required
value.
4. If the authentication is successful, then the manager sends a XACML query to
the PDP to check the authorization of the value requested by the application.
5. The Capability Manager receives a XACML Response indicating if the query is
Permitted or Denied.
6. When the query is permitted, the Capability Manager generates the capability
token and sends it back to the application.
7. With the capability token stored in application, the user is able to establish a
secure end-to-end communication with the REP handler.
8. To perform a secure communication, application starts a HTTPS exchange with
the REP handler query with the capability token containing the value type
requested.
9. Then the REP handler is able to verify the sign of the capability token.
10. If the token is valid, the REP handler sends the information back to the
application.
Expected
results
The application requests the data from the appropriate REP handler and receives the
value if authorised.
SMARTIE Deliverable D6.1
Page 34 of (59) © SMARTIE consortium 2015
Expected
completion
M30
Diagrams showing the sequence of using each particular service, as well as the interaction between the IoT
devices and the platform are included in figures below (Figure 12, Figure 13 and Figure 14)
Figure 12: Secure device registration
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 35 of (59)
Figure 13: Secure data upload
Figure 14: Secure data retrieval
SMARTIE Deliverable D6.1
Page 36 of (59) © SMARTIE consortium 2015
Expected results, procedures and measurements to be undertaken are explained in detail using KPIs and a
Balance Score Card.
3.3.6 Assessment criteria
Key performance indicators (KPIs) have been defined to assess the pilot performance. They have been
created in such a way to reflect the pilot’s goal and objectives. The scenarios selected focus on the following
pilot goals:
Enable real-time bus arrival time shown to travellers
Provide air quality information to travellers
Provide option to buy bus tickets using mobile phone
At the lower level, these can be translated to the following goals:
Prevent unauthorised devices to connect to the platform (RD)
Establish access control policies for end users
Establish access control policies for IoT devices
Ensure secure data transfer between the device and back-end infrastructure
Preventing and disabling other users that wish to eavesdrop on other’s travel plans, which rely on the
data privacy aspects implemented within the SMARTIE platform.
Successful integration with PTIN platform
Key performance indicators have been presented in the tables below.
Table 3: Serbian Pilot Goals
ID Serbian Pilot Goal Pilot Phase
1 Enable real-time bus arrival time shown to travellers 1
2 Enable multi-modal transportation 3
3 Provide air quality information to travellers 1
4 Increase number of travellers using public transport 3
5 Provide relevant tourist information to travellers 2
6 Provide most efficient routing to travellers 3
7 Implement core features in line with ISO 24014 2
8 Increase quality of public transport in Novi Sad 2
9 Promote public transport as a way to decrease air pollution 3
10 Enable interoperability between transport operators 3
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 37 of (59)
11 Provide option to buy bus tickets using mobile phone 3
12 Increase the satisfaction of employees in public transport services 3
Table 4: Serbian Pilot - Financial Key Performance Indicators (KPIs) with Target Values, Rationale
and Measurement Process
View KPI name Importance
(1-10)
Rationale Measurement
process
Phase Target Units Goal
ID
Initiative
MobileTicketsIssued 10 Assess the usage of mobile
payment and mobile ticketing
options
Percentage of mobile
tickets requests over the
total bus arrival time
requests
3 10 % 11 Promote mobile ticketing,
provide incentives
MobileTicketPaymentSMS 10
Assess the usage/popularity of
sms mobile payment/tickets
sending options
Percentage of sms mobile
payment/tickets sending
options over the total
mobile tickets requests. 3 40 %
11 Promotion of the payment
platform. Evaluation of possible
incentive.
MobileTicketPaymentPlatimo 10
Assess the usage/popularity of
Platimo mobile
payment/tickets sending
options
Percentage of Platimo
mobile payment/tickets
sending option over the
total mobile tickets
requests. 3 30 %
11 Promotion of the payment
platform. Evaluation of possible
incentive.
MobileTicketPaymentPayPal 10
Assess the usage/popularity of
Paypal mobile payment/tickets
sending options
Percentage of PayPal
mobile payment/tickets
sending options over the
total mobile tickets
requests. 3 30 %
11 Promotion of the payment
platform. Evaluation of possible
incentive.
NumBusTicketsPurchased 7
Assess the number of bus
tickets purchased over a set
period of time (dynamics in
purchasing the tickets)
DB query at regular times in
order to assess the usage
dynamic and rate
2
4,10 Promotion of the public
transport in Novi Sad
NumBikeTicketsPurchased 7
Assess the number of rental-
bike tickets purchased over a
set period of time (dynamics in
purchasing the tickets)
DB query at regular times in
order to assess the usage
dynamics and rate
2
4,10 Promotion of the public
transport in Novi Sad
NumCombinedTickets Purchased 7
Assess the number of combined
transport tickets purchased
over a period of time (dynamics
in purchasing the tickets)
DB query at regular times in
order to assess the usage
dynamics and rate
2
4,10 Promotion of the public
transport in Novi Sad
SalesGrowth 9
Assess the salesgrowth on the
pilot line with respect to the
sales in 2013 (before the pilot)
Number of tickets sold over
number of tickets sold in
the same period last year 2
110 % 4 Promotion of the new service
Fin
anci
al
SMARTIE Deliverable D6.1
Page 38 of (59) © SMARTIE consortium 2015
Table 5: Serbian Pilot - Internal Business Process - KPIs with Target Values, Rationale and
Measurement Process
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 39 of (59)
Table 6: Serbian Pilot - Learning and Growth - KPIs with Target Values, Rationale and Measurement
Process Measurement Process
3.3.7 Test scenario roadmap
Table 7: Roadmap of Smart Public Transport test case
Test Scenario M25 M26 M27 M28 M29 M30
1. fleetNET registration to RD
2. Data upload
3. Service search via RD
4. REP web service access and data retrieval
SMARTIE Deliverable D6.1
Page 40 of (59) © SMARTIE consortium 2015
3.4 Real World Test 3: Smart Traffic Control
This scenario addresses the secure interconnection of several traffic management systems in a city context.
The intent is to integrate traffic data from several resources into the SMARTIE platform, securely store and
process the data to improve the traffic situation in a city area.
The test is designed to show options of integrating already existent subsystems into the SMARTIE platform
in a secure way. The connected systems in such a scenario will probably not provide all of its data to the
platform but only relevant one. Nevertheless, the data provided by the subsystems to the platform must be
secured against external illegal access, especially if the subsystems concern infrastructure. As intelligent
traffic solutions became more common in the last years, the demand is to connect these systems with each
other to raise their benefit. This makes the traffic scenario a reasonable approach to test the possibilities of
the SMARTIE platform in this point. Key issue is the secure transfer and storage of data between different
subsystems, because of the critical impact of traffic management infrastructure on the traffic safety in an
area.
The scenario focuses on the connection of radar based traffic sensors, LED traffic signs and traffic light units
to the SMARTIE platform. The processed traffic data is used to control the connected actuators and can be
shown to end-users via a web application. Furthermore, users with special rights should be able to manage
the connected devices (e.g. switch traffic sign content).
The scenario demonstrates the secure data exchange between connected devices and the smart data platform,
the mechanism for authentication and authorisation of users when accessing traffic signs or crucial data, as
well as the validation of the data resources.
3.4.1 Description of the test field
This scenario is located in Frankfurt (Oder), Germany. Frankfurt (Oder) is a town with 60.000 inhabitants,
about 100km east of Berlin. It is located in the German federal state Brandenburg right next to the border to
Poland.
Figure 15: Location of Frankfurt (Oder)
The city is located directly next to the river Oder, which furthermore is the German national border to
Poland. A bridge over the river connects the German city Frankfurt (Oder) with the Polish city Słubice. It is
one of the main border crossings in the region and a very important traffic artery for both cities.
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 41 of (59)
Figure 16: inner city area of Frankfurt (Oder)
The specific test area extends to the inner city area located around the bridge. There are several main routes
leading to the border bridge which are essential to the traffic situation in the city (marked in red in Figure
16). The traffic situation in the inner city is affected by the border bridge in the north east of the map. There
is no nearby evasion route for the traffic going to Słubice, however there is a big traffic volume caused by
commuters. In situation of high border traffic volumes, there is a high risk of traffic jams in the whole inner
city area, especially in the west-east direction. The only possibility for the traffic user to avoid these jams is a
route via a motorway outside of the city.
For the test scenario there are two relevant subsystems in place, which will be connected to the SMARTIE
platform to send and retrieve data from/to it. Traffic Safe is a mobile traffic control system originally
designed for temporary traffic situations, like construction sites on motorways. It consist of detectors and
display units installed at the side of the street and a central control unit. Several detectors are installed all
around the city are and send traffic data to the SMARTIE platform.
Traffic Green is a system for prioritization of emergency vehicles at traffic lights. This system uses
stationary units, which are installed at several traffic lights all over the city area. These units handle radio
telegrams of passing emergency vehicles to change the operation mode of the traffic lights. The units will
send information about ongoing emergency runs to the platform. This will cause an operation of the display
units, showing informational content to the road users.
3.4.2 Relevant SMARTIE components
In the smart traffic scenario, we will test and validate the following components provided by work packages
WP2-WP4.
SMARTIE Deliverable D6.1
Page 42 of (59) © SMARTIE consortium 2015
SmartData platform: In smart traffic scenario the SmartData platform will include Capability
Manager to generate validation tokens for accessing or publishing data the platform. It provides the
connection to the RD and stores all published data in virtual entities. The scenario uses the service
enabler and context broker provided by the platform.
DCapBAC: In smart traffic scenario the capability tokens will be used to register devices to the
platform and to authorise users to request data via a web application. Therefore the DCapBAC
scheme will be applied by traffic safe wrapper, capability manager and web application.
Resource directory (RD) with secure storage: In smart traffic scenario the Resource Directory is
used to register devices and for the discovering available resources. The purpose is to register all
traffic devices to the RD.
3.4.3 Standard Protocols to Be Used
For real world tests of Smart building, we need to use standard protocols that enable essential
communication functionalities at network and application levels.
1. REST – The Smart Data platform provides REST interfaces to send and retrieve data to the platform.
It is used by the TS Wrapper and Web App to connect to the SMARTIE platform.
2. HTTPS – is the secure communication protocol standard of the internet. It is used for the
communication of the users to the web application.
3. TLSoverIP – is a communication standard for traffic installations on German motorways, published
by the German Federal Highway Research Institute (BASt). It is used by sensors and signs to
communicate with the Traffic Safe Central Unit.
3.4.4 Description of test cases
This section specifies the test cases implemented in the smart traffic scenario and describes the devices and
equipment that will be deployed in Frankfurt (Oder).
3.4.4.1 Devices and equipment in smart traffic
This subsection describes the devices and equipment to be deployed for the real world tests.
3.4.4.1.1 TS Central Unit
The Traffic Safe central unit is the platform to control and manage all connected traffic devices like traffic
sensors or led signs. It monitors the operational status of all components, handles errors and initiates
actuations on the traffic devices. The raw data of the devices is processed and logged by the central unit.
The TS central unit communication to the traffic devices is realized via TLSoverIP, a communication
standard for traffic installations on German motorways. The central unit will provide different APIs to
receive (aggregated) traffic data or managing traffic devices. The REST interface of the central unit will be
used by the TS Wrapper to interoperate with the traffic devices.
3.4.4.1.2 TS Wrapper
The Traffic Safe Wrapper connects the TS central unit and the SMARTIE platform. It uses the REST
interfaces of the TS central unit to retrieve traffic data or trigger switching commands. It manages all traffic
devices that will be connected to the SMARTIE platform and administers these devices as virtual units. The
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 43 of (59)
TS Wrapper will use the REST interface of the SMARTIE platform to register & authenticate the devices. It
proxies the devices when publishing or retrieving data from the platform.
3.4.4.1.3 Radar Traffic Sensor
The radar traffic sensor is the device to measure passing vehicles. The sensor is connected to a local control
system that handles errors, solar power & communication. The controller is designed and developed by GWS
using a Microchip PIC18F2620 microcontroller. It realizes communication via IP based mobile data
communication via an Aarlogic® TER-GX300S modem. The supported protocols are TLSoverIP or a
proprietary protocol developed by GWS.
There are several options for the traffic sensors that can be used, depending on the concrete installation
conditions and the planned application:
Component Smart Micro UMRR Traffic Sensor Type 29
Mounting Height Typ. 4m/6m
Speed Accuracy Typ.< ±0.28 m/s or ±1%
Interfaces CAN V2.0b (passive)VII, RS485 half-duplex
Description A 24GHz radar for traffic management applications. Works in adverse conditions,
almost unaffected by weather, and independent of sunlight, in a wide temperature
interval. On highways and country roads, the sensor is typically used to count
and classify traffic. Usually three classes are selected and reported in
configurable counting /statistics intervals.
- Counting and Classification
- Wrong Way Detection (vehicle moving opposite to the defined direction of traffic)
- Incident Detection
- Speed measurement
Component viafalcon SOLAR
Mounting Height Typ. 2m/5m
Speed Accuracy Typ.< ±1.4 m/s or ±5%
Interfaces RS 232, RS485
Description Simple 24GHz radar detector for basic applications. Easy and fast installation. Does
not detect standing vehicles.
- Counting
- Wrong Way Detection
- Speed measurement
Component viafalcon PLUS 3
Mounting Height Typ. 2m/5m
Speed Accuracy Typ.< ±1.4 m/s or ±5%
Interfaces RS 232, RS422
SMARTIE Deliverable D6.1
Page 44 of (59) © SMARTIE consortium 2015
Description Simple 24GHz radar detector for basic applications. Easy and fast installation.
Standing vehicles can be detected.
- Counting & Classification
- Wrong Way Detection
- Speed measurement
3.4.4.1.4 Traffic Sign (LED)
Several LED traffic signs will be installed in the test area. The signs are SWARCO Futurit WR20 full matrix
displays. The dimension of the display surface is 1120x1600mm with a resolution of 56x80 pixels. The
standard model can show two colours – red and white, which covers most applications in the field of traffic
management. For special purposes displays with a RGB colour space are available.
The sign is connected to a local control unit, which handles errors, solar power & communication. The
control unit is based on a WAFER-LX3-R20 running an embedded Windows OS. The IP based mobile data
communication is realized by an Aarlogic® TER-GX300S modem. The supported protocols are TLSoverIP
or a proprietary protocol developed by GWS.
The content of the displays can be stored as picture data in the control unit. In this case, an actuation request
will just activate the content by an identifier. It is also possible to change the content of a sign dynamically
via the protocol interface.
3.4.4.1.5 Traffic Light Communication Unit
The traffic light communication unit receives registration & sign of telegrams from the emergency vehicles
via radio transmission, processes the requests and triggers switching programs in the connected traffic light
control unit. The controller is based on a circuit board designed and developed by GWS. In the actual
operation mode, this communication is not forwarded to any central instance. To connect the Traffic Green
system with the SMARTIE platform, the communication unit will be extended with a module to realize
mobile data connection, to register & authenticate the devices, as well as publish data of incoming
emergency runs to the SMARTIE platform.
3.4.4.1.6 Web Application
For visualisation of the measured traffic data a web application will be deployed. It will request data from the
SMARTIE platform via the REST API. The following data will be requested:
Actual average speed on a certain sensor
Historical speed data on a certain sensor aggregated at the base of 5/15/60 min
Vehicle count on a certain sensor for the last 5/15/60 min
Historical count data on a certain sensor aggregated at the base of 5/15/60 min
Actual content of a certain traffic sign
The data is shown to the user on a map of the area. Coloured routes represent the actual status of the sensors.
Historical traffic data is shown in form of tables.
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 45 of (59)
Figure 17: Mockup of the web application map view
3.4.4.1.7 Traffic Service Applications
To demonstrate the event based subscription of the SMARTIE platform, several service applications will be
developed and deployed during the tests. These applications use the REST interface of the SMARTIE
platform to subscribe to events which are generated from the incoming traffic data. The purpose is to actuate
the led traffic displays in the test area, based on data that is coming out of the SMARTIE platform. The
application will use the functionality of the TS Wrapper to address the actuation requests. Depending on the
test scenario, the service applications will use events generated from measured data of the radar sensors or
from data of ongoing emergency runs in the city area.
3.4.4.2 Participating users/roles including SMARTIE components
Users may subscribe the information collected by sensors and may request the actuation of gateways
over legacy equipment. To do that, the users employ the Android application to be authenticated in
the SmartData platform and obtain the capability tokens for the M2M communication with IoT
devices.
Capability Manager is an entity within the SmartData platform that generates the capability tokens
for enabling a user, to interact with an IoT device for information or actuation.
Policy Decision Point is an entity within the SmartData platform that checks the authorization of a
user for access to an IoT device and takes the decision of sending a capability token generated by
Capability Manager.
Topic Manager is an entity within the SmartData platform with the responsibility of managing the
information provided by the sensors. It acts as broker to enable the subscription of users and
publishing the information from sensors.
Radar Traffic Sensors & LED traffic signs are devices installed beside the street in the city area
providing traffic data, like vehicle speed and count or showing content to the road users
Traffic Light Communication Unit is a device receiving incoming radio telegrams from emergency
vehicles and triggering special switching cycles at the traffic light and publishing emergency events
to the SMARTIE platform
Traffic Safe Central Unit & TS Wrapper – The Traffic Safe Central Unit manages all connected
radar sensors and traffic signs. It monitors operating data of the devices, like battery voltages and
sign errors. The Traffic Safe Central Unit is connected to the smart data platform by the TS Wrapper,
which routes traffic data between the two systems and proxies traffic devices
Users can get processed and aggregated traffic data for a certain area via the web application.
Resource Directory (RD) with secure storage handles secure resource registration and resource
discovery implemented in the SMARTIE platform
SMARTIE Deliverable D6.1
Page 46 of (59) © SMARTIE consortium 2015
Capability Manager generates capability tokens for uses and devices registering to the platform.
This enables entities to access or interact with devices and web services
Virtual Entity within the SMARTIE platform that represents the IoT traffic devices. It receives
incoming traffic data from sensors and operating data from sensors and signs that can be accessed
via the Smart Data API.
Web Application receives user request for processed data. Accesses the Smart Data API to
send/retrieve information to virtual entities.
3.4.4.3 Smart Traffic Test Cases
This section describes the test cases to be validated in the real world scenario of Smart Traffic in Frankfurt
(Oder). Each test case shows the devices, parameters and events that participate in the validation of the
SMARTIE components. The proposed test cases are:
Receive aggregated traffic data via Web Application: This test case shows how a user can access
(real time and historical) traffic data in the test area via a web application.
Actuation for traffic signs by traffic sensor data: In this test case, a service application will subscribe
to events generated from the traffic data that is measured by the radar sensors.
Actuation of the traffic signs by emergency events: This test case is similar to the one above. A
service application will subscribe to events to actuate the traffic signs. The difference is that the
events are generated from incoming emergency events from the traffic light control units.
These test cases are described in detail in the next subsections.
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 47 of (59)
3.4.4.3.1 Test Case of Receive traffic data
This subsection describes the test case of a user receiving traffic data from the platform via a web
application. It validates the functionalities and interaction of TS Wrapper, Capability Manager, Resource
Directory and Web application with traffic sensors integrated.
SMARTIE Platform
Smartdata Provider
Traffic Sensor
User
Traffic Safe Central Unit
1. TLS over IP
TS WrapperRessource Directory with
secure storage
Capability Manager
2. Token Request
3. Register
Smartdata Storage REST
4. Publish Data
Smartdata SE
Web-App
REST
Smartdata: API
5. Token Request
7. Access Data
4. Request Data
9. Retrieve Data
6. Discover Ressources
Virtual Entity8. Validate request
Figure 18: Overview receive traffic data test case
Test Case (real world level)
TC name Receive traffic data
Preconditions a. SmartData platform including Capability Manager, Policy Decision Point, DCapBAC
& Resource Directory
b. TS Wrapper with DCapBAC component
c. web application for visualisation of traffic data including DCapBAC component
Execution 5. The traffic sensors register to the TS central unit and send traffic data frequently.
6. The TS Wrapper request Capability Manager for capability token to register sensor
to RD. This request contains a sensor id to identify the device. The wrapper initiates
a DTLS exchange for securing communication with the Capability Manager.
7. The Capability Manager authenticates the device and checks authorisation to register
SMARTIE Deliverable D6.1
Page 48 of (59) © SMARTIE consortium 2015
to the RD and publish data to the platform.
8. If the authentication is successful the TS Wrapper receives a capability token from
Capability Manager. With this token the Wrapper is able to register the device to the
Resource Directory and publish data to the platform.
9. A user is requesting traffic data for the area via web application. The web
application requests a capability token for authenticating and authorizing the user in
a similar way the TS Wrapper does for devices.
10. The web application requests the Resource Directory for active devices on a certain
route or in a certain area.
11. Then the web application request data from the SMARTIE platform via REST
interface with the capability token. The platform validates the token for the certain
virtual entity.
12. If the token is valid, data is send to the web application and can be shown to the user
in a proper way, like a map.
Expected
results
The user receives actual values of the traffic sensors in the test area. Otherwise, the
access can be denied if the user has no permission to access the data at all. If the user has
access to a subset of devices only the data of these devices should be shown.
Expected
completion
M29
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 49 of (59)
SMARTIE Platform
Traffic Sensor
TS Central/Wrapper
Capability Manager
Ressource Directory
Virtual Sensor
DCapBAC Validator
Web Application
SensorRegistration
(TLSoIP)
Cap Token Request
Cap Token Response
Register with CapToken
Return statusSensor Data
(TLSoIP)Sensor Data
(REST)
Cap Token Request
Cap Token Response
Request Sensor Data
User
Request List
Validate
Response
Sensor Data Response
Get list of sensors
Validate
Response
sensor list
Show data
Sensor Data(REST)
Sensor Data(TLSoIP)
Cap Token Request
Cap Token Response
Request Data
Figure 19: Sequence diagram Receive traffic data test case
3.4.4.3.2 Test Case of sign actuation
This subsection describes the test case of a traffic monitor service actuating signs in the emergence of traffic
events, like congestions. The monitor service subscribes to entities of sensor devices and receives published
traffic data. Depending on the data published by the sensors, the monitor service will actuate sign content in
the test area. This test case validates the functionalities and interaction of TS Wrapper, Capability Manager,
Resource Directory and TS monitor service with traffic sensors and LED signs integrated.
SMARTIE Deliverable D6.1
Page 50 of (59) © SMARTIE consortium 2015
SMARTIE Platform
Smartdata Provider
Traffic Sensor
Traffic Safe Central Unit
1. TLS over IP
TS Wrapper12. Validate actuation request (DCapBAC)
Ressource Directory with secure storage
Capability Manager
2. Token Request
3. Register
Smartdata Storage REST
4. Publish Data
Smartdata SE
Smartdata: API
Traffic Monitor Service9. Event Detection 5. Request Subscription
Token
Virtual Entity7. Validate subscription
6. Subscribe 8. Publish
LED Sign13. Change Sign
11. Actuation Request
10. Request Actuation
Token
Figure 20: Overview sign actuation test case
Test Case (real world level)
TC name Sign actuation test case
Preconditions a. SmartData platform including Capability Manager, Policy Decision Point, DCapBAC
& Resource Directory
b. TS Wrapper with DCapBAC component
c. monitor service for subscribing to traffic data & actuating signs including DCapBAC
component
Execution 1. The traffic sensors & led signs registers to the TS central unit. The devices send
traffic & operational data frequently to the central unit via TLSoIP.
2. The TS Wrapper request Capability Manager for capability token to register sensors
& signs to RD. This request contains a device id to identify the device. The wrapper
initiates a DTLS exchange for securing communication with the Capability
Manager.
3. The Capability Manager authenticates the device and checks authorisation to register
to the RD and publish data to the platform.
4. If the authentication is successful the TS Wrapper receives a capability token from
Capability Manager. With this token the Wrapper is able to register the device to the
Resource Directory and publish data to the platform.
5. The traffic monitor service requests a capability token for authenticating and
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 51 of (59)
authorizing subscription to sensor data.
6. The monitor service uses capability token to subscribe to certain sensor data. The
token is validated by the platform to guarantee that the data can be accessed by the
monitor service.
7. Incoming sensor data from real world devices will be published to the traffic monitor
service to detect certain traffic events (e.g. congestion). If an event occurs the
monitor service will try to change the content of certain led signs.
8. To do that the monitor service requests a token form the capability manager to
actuate led signs. The token is used by the monitor service to request sign actuation
at the TS Wrapper.
9. TS Wrapper validates the token and will initiate the content switch on certain LED
signs.
Expected
results
The content of the signs is automatically actuated depending on the sensor data. The
actual sign states are published into the SMARTIE platform
Expected
completion
M30
SMARTIE Deliverable D6.1
Page 52 of (59) © SMARTIE consortium 2015
SMARTIE Platform
Traffic Sensor
TS Central/Wrapper
Capability Manager
Ressource Directory
Virtual Device
DCapBAC Validator
Traffic monitor service
SensorRegistration
(TLSoIP)
Cap Token Request
Cap Token Response
Register with CapToken
Return statusSensor Data
(TLSoIP)Sensor Data
(REST)
Subscribe to device request
Validate
Response
Subscription Response
Sign Data(REST)
Sign Data(TLSoIP)
Cap Token Request
Cap Token Response
LED Sign
SignRegistration
(TLSoIP)
Cap Token Request
Cap Token Response
Register with CapToken
Return status
Sensor Data(TLSoIP)
Sensor Data(REST)
Sensor Data (REST)
Detect Event
Cap Token Request
Cap Token Response
LED actuation Request
Validate
Response
LED actuation request
LED actuation responseSign Data(REST)
Figure 21: Sequence diagram sign actuation test case
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 53 of (59)
3.4.4.3.3 Test Case emergency events
This subsection describes the test case of an emergency event service actuating signs in case of ongoing
emergency runs in the test area. The service subscribes to entities of traffic light communication devices and
receives published data of emergency runs, which will actuate sign content in the test area. This test case
validates the functionalities and interaction of TS Wrapper, Capability Manager, Resource Directory and
traffic light event service with traffic sensors, LED signs & Traffic Light communication units integrated.
SMARTIE Platform
Smartdata ProviderTraffic Safe
Traffic Sensor
Traffic Safe Central Unit
1. TLS over IP
TS Wrapper12. Validate actuation request (DCapBAC)
Ressource Directory with secure storage
Capability Manager
2. Token Request
3. Register
Smartdata Storage
REST
4. Publish Data
Smartdata SE
Smartdata: API
Traffic Light Event Service9. Event Detection 5. Request Subscription
Token
Virtual Entity7. Validate subscription
6. Subscribe 8. Publish
LED Sign13. Change Sign
11. Actuation Request
10. Request Actuation
Token
Traffic light comunication unit
2. Token Request
Smartdata ProviderTraffic Lights
Figure 22: Overview Emergency event test case
Test Case (real world level)
TC name Emergency event test case
Preconditions a. SmartData platform including Capability Manager, Policy Decision Point, DCapBAC
& Resource Directory
b. TS Wrapper with DCapBAC component
c. monitor service for subscribing to traffic & emergency event data, actuating signs
including DCapBAC component
d. traffic light communication module with Capability module
Execution 1. The traffic sensors & led signs registers to the TS central unit. The devices send
traffic & operational data frequently to the central unit via TLSoIP.
2. The TS Wrapper request Capability Manager for capability token to register sensors
& signs to RD. This request contains a device id to identify the device. The wrapper
SMARTIE Deliverable D6.1
Page 54 of (59) © SMARTIE consortium 2015
initiates a DTLS exchange for securing communication with the Capability
Manager.
3. The Capability Manager authenticates the device and checks authorisation to register
to the RD and publish data to the platform.
4. If the authentication is successful, the TS Wrapper receives a capability token from
Capability Manager. With this token the Wrapper is able to register the device to the
Resource Directory and publish data to the platform.
5. The traffic light communication unit request token from capability manager to
register to the RD and publish data to the platform.
6. Capability manager authenticates the device and checks authorisation to register to
the RD and publish data to the platform
7. If the authentication is successful the traffic light control unit receives a capability
token from Capability Manager. With this token the device is able to register to the
Resource Directory and publish data to the platform.
8. The traffic monitor service requests a capability token for authenticating and
authorizing subscription to sensor data.
9. The traffic light event service uses capability token to subscribe to certain sensor
data. The token is validated by the platform to guarantee that the data can be
accessed by the service.
10. If an emergency event occurs, the traffic light event service will try to change the
content of certain led signs.
11. To do that, the service requests a token form the capability manager to actuate led
signs. The token is used by the traffic light event service to request sign actuation at
the TS Wrapper.
12. TS Wrapper validates the token and will initiate the content switch on certain LED
signs.
Expected
results
If an emergency run is ongoing the content of the signs is automatically actuated. After
emergency run is finished signs will switch back to normal mode. The actual sign states
are published into the SMARTIE platform
Expected
completion
M30
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 55 of (59)
SMARTIE Platform
Traffic Sensor
TS Central/Wrapper
Capability Manager
Ressource Directory
Virtual Device
DCapBAC Validator
Traffic light event service
SensorRegistration
(TLSoIP)
Cap Token Request
Cap Token Response
Register with CapToken
Return statusSensor Data
(TLSoIP)Sensor Data
(REST)
Subscribe to device request
Validate
Response
Subscription Response
Sign Data(REST)
Sign Data(TLSoIP)
Cap Token Request
Cap Token Response
LED Sign
SignRegistration
(TLSoIP)
Cap Token Request
Cap Token Response
Register with CapToken
Return status
Emergency State(REST)
Emergency Event (REST)
Cap Token Request
Cap Token Response
LED actuation Request
Validate
Response
LED actuation request
LED actuation responseSign Data(REST)
TL com module
Cap Token Request
Cap Token Response
Register with CapToken
Return status
Traffic Light State (REST)
Figure 23: Sequence diagram of emergency event test case
SMARTIE Deliverable D6.1
Page 56 of (59) © SMARTIE consortium 2015
3.4.5 Assessment criteria
For evaluating the results of the test cases there are two main topics to consider: user related criteria &
technical indicators. The following subsection will give an overview of the relevant aspects for both topics.
3.4.5.1 User related criteria
Name description measurement
User guidance Design of every user interface
(apps/websites etc.) has to be
user friendly and easy to
understand
User survey
Range of functions App must provide the
functionalities the user expects User survey
Response time The response to a user request
should be delivered in proper
time
User survey
Monitor response time
Availability User interfaces must be available
24/7 User Survey
Availability
measurements
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 57 of (59)
3.4.5.2 Technical Indicators
Name Description measurement
Availability components All Traffic components in test
bed should be connected to
platform 24/7
Monitor component
status data
Delay Components should send their
data in real time Monitor message delay
Data loss All data send to the platform
must be received. No data should
be lost
Logging of sent and
received data and
evaluate possible diffs.
Number of components System must be able to handle a
great number of components at
the same time
Run of test cases with
simulated components,
measure delay & data
loss
Authentication Users and devices must be
authenticated with capability
tokens
Test with not
authenticated request
Data Integrity Telegrams must not be modified
during test sequence design and run man-in-
the-middle attacks
Authorization No unauthorized actuation of
traffic components design test runs with
different users & roles
3.4.6 Test scenario roadmap
Table 8: Roadmap of Smart Traffic test case
Test Scenario M25 M26 M27 M28 M29 M30
5. Receive traffic data
6. Sign Actuation
7. Emergency Events
SMARTIE Deliverable D6.1
Page 58 of (59) © SMARTIE consortium 2015
4 Conclusions
This document provides a definition of the concrete test scenarios to be implemented on the three
demonstrator sites in Murcia, Novi Sad and Frankfurt (Oder). The definition of the scope of the tests will
allow a focused validation of the SMARTIE platform and the affiliated applications. The planned test cases
in every test scenario cover a wide variety of functionalities and use cases. If these test cases can be
implemented and evaluated successfully, the applicability of the results of the project will be proven. The
detailed specification of the technical measurements and parameters will be part of D6.2.
Deliverable D6.1 SMARTIE
© SMARTIE consortium 2015 Page 59 of (59)
References