smartie - cordis...this deliverable presents the scenario screenplays for the planned real world...

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

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 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.



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



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



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



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



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



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.



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



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)



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



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.



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.



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).



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:



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.



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



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



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.


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.


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



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.


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



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.


TC name Actuation using Distributed Kerberos

Preconditions a. User and device are registered with the Kerberos component.



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



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



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




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



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.



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


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.



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



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


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)


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



Pilot Scenario 2

Accessing information on air quality/pollution

Involves interactions of the platform with ekoNET device and users (via smart mobile app)


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)



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)


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


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



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


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


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



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


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.


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.



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



Figure 13: Secure data upload

Figure 14: Secure data retrieval



Expected results, procedures and measurements to be undertaken are explained in detail using KPIs and a

Balance Score Card.


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



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


Platimo mobile

payment/tickets sending

options

Percentage of Platimo

mobile payment/tickets

sending option over the

total mobile tickets

requests. 3 30 %



incentive.

MobileTicketPaymentPayPal 10


Paypal mobile payment/tickets

sending options

Percentage of PayPal

mobile payment/tickets

sending options over the

total mobile tickets

requests. 3 30 %



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)



dynamics and rate

2



NumCombinedTickets Purchased 7

Assess the number of combined

transport tickets purchased

over a period of time (dynamics

in purchasing the tickets)



dynamics and rate

2



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



Table 5: Serbian Pilot - Internal Business Process - KPIs with Target Values, Rationale and

Measurement Process



Table 6: Serbian Pilot - Learning and Growth - KPIs with Target Values, Rationale and Measurement

Process Measurement Process


Table 7: Roadmap of Smart Public Transport test case


1. fleetNET registration to RD

2. Data upload





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.


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.



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.


In the smart traffic scenario, we will test and validate the following components provided by work packages

WP2-WP4.



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.


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



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



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



Interfaces RS 232, RS422



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.



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.


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



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.



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


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



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



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 Platform

Smartdata Provider

Traffic Sensor


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


TC name Sign actuation test case




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.



4. If the authentication is successful the TS Wrapper receives a capability token from



5. The traffic monitor service requests a capability token for authenticating and



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 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



(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


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



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


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


TC name Emergency event test case




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



initiates a DTLS exchange for securing communication with the Capability

Manager.



4. If the authentication is successful, the TS Wrapper receives a capability token from



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


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



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



(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


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


Return status

Traffic Light State (REST)

Figure 23: Sequence diagram of emergency event test case




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



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


Table 8: Roadmap of Smart Traffic test case


5. Receive traffic data

6. Sign Actuation

7. Emergency Events



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.



References

smartie - cordis...this deliverable presents the scenario screenplays for the planned real world...

Documents