uTRUSTit D2.4 Technical Requirements For The IoT Prototype Final

30/04/2011
Page 1 / 28

uTRUSTit Usable Trust in the Internet of Things
Project Reference: 258360
FP7-ICT (Area: ICT-2009-1.4 Trustworthy ICT)
Project Duration: 1 Sep 2010 31 August 2013

D.2.4 Technical Requirements for the IoT
Prototype
SWE

Final Version

Author:
Henrik Arfwedson (SWE)
Niklas Back (SWE)
Peter Thellenberg (SWE)
Markus Burvall (SWE)
Dniel Petr (SEARCH)

Version: 1.0
Date: 04/29/2011
Dissemination level: (PU, PP, RE, CO): PU

Project Co-Funded by the European Commission within the 7th Framework Programme

30/04/2011
Page 2 / 28
Abstract:
We present technical requirements for scenarios in the three domains of smart home, smart office, and
e-voting. The smart home consists of five sub scenarios; the smart office includes five sub scenarios; e-
voting has four sub scenarios. The definitions (D2.2) and personas (D2.1) documents are the foundation
for the real world technical requirements of the scenarios, this document. The requirements are the
basis for work package WP4 and capture the functionality planned to be implemented. The sub
scenarios cover a variety of situations that people may encounter in their everyday life and help to
illustrate the trust issues that can show up when working with the Internet of Things (IoT).
30/04/2011
Page 3 / 28
Table of Contents

1. INTRODUCTION ................................................................................................................................................... 5
1.1 Background .................................................................................................................................................... 5
1.2 Scope of this Deliverable ............................................................................................................................... 5
1.3 Document Layout .......................................................................................................................................... 5
2. TERMINOLOGY .................................................................................................................................................... 6
3. SCENARIO: TRUSTED SMART HOME SERVICES ................................................................................................... 7
3.1 Sub-scenario: Door lock and wireless key management and control system ............................................... 7
3.1.1 System overview and description ......................................................................................................... 7
3.1.2 Functional requirements ...................................................................................................................... 7
3.1.2.1 Door lock system ........................................................................................................................................ 8
3.1.3 Application and devices ........................................................................................................................ 9
3.1.3.1 Hardware .................................................................................................................................................... 9
3.1.3.2 Software ..................................................................................................................................................... 9
3.2 Sub-scenario: Medicine Management and Control system ........................................................................ 10
3.2.1 System overview and description ....................................................................................................... 10
3.2.2 Functional requirements .................................................................................................................... 11
3.2.2.1 Medical Cabinet system ............................................................................................................................11
3.2.2.2 Medical cabinet size ..................................................................................................................................12
3.2.3 Applications and devices .................................................................................................................... 13
3.2.3.1 Hardware ...................................................................................................................................................13
3.2.3.2 Software ....................................................................................................................................................14
3.3 Sub-scenario: Home Entertainment Management ..................................................................................... 14
3.3.2 Application and devices ...................................................................................................................... 16
3.3.2.1 Hardware ...................................................................................................................................................16
3.3.2.2 Software ....................................................................................................................................................16
3.4 Sub-scenario: Tracking Movement .............................................................................................................. 17
3.4.2.1 Hardware ...................................................................................................................................................18
3.4.2.2 Software ....................................................................................................................................................18
3.5 Sub-scenario: Inventory of Things ............................................................................................................... 19
3.5.2.1 Hardware ...................................................................................................................................................20
3.5.2.2 Software ....................................................................................................................................................20
4. SCENARIO: SMART OFFICE ................................................................................................................................ 21
4.1 Sub-scenario: Project Meeting with Entry Registration .............................................................................. 21
4.1.2.1 Hardware ...................................................................................................................................................21
4.1.2.2 Software ....................................................................................................................................................21
4.2 Sub-scenario: Exchanging data with other project members ..................................................................... 21
4.2.2.1 Hardware and software .............................................................................................................................22
4.3 Sub-scenario: Connecting to infrastructure ................................................................................................ 22
4.3.2.1 Hardware ...................................................................................................................................................22
4.3.2.2 Software ....................................................................................................................................................22
4.4 Sub-scenario: Smart door ............................................................................................................................ 23
30/04/2011
Page 4 / 28
4.4.2.1 Hardware ...................................................................................................................................................23
4.4.2.2 Software ....................................................................................................................................................23
4.5 Sub-scenario: Smart Break Room ................................................................................................................ 23
4.5.2.1 Hardware ...................................................................................................................................................24
4.5.2.2 Software ....................................................................................................................................................24
5. SCENARIO: E-VOTING ........................................................................................................................................ 25
5.1 Sub-scenario: Voting for Someone Else ....................................................................................................... 25
5.1.2.1 Hardware ...................................................................................................................................................26
5.1.2.2 Software ....................................................................................................................................................26
5.2 Sub-scenario: Vote from abroad ................................................................................................................. 26
5.3 Sub-scenario: The participant Votes on the Options ................................................................................... 27
5.4 Sub-scenario: Impaired participant votes on options ................................................................................. 27

30/04/2011
Page 5 / 28

1. Introduction
1.1 Background
The project defines Internet of Things (IoT) scenarios for virtual reality and real world scenarios. This
document provides the technical requirements for the real world implementations. The three scenario
areas are:

Smart Home
Smart Office
E-Voting

All scenarios may be defined and implemented in various ways. Key for the project is to be able to test
TRUST, using the scenario prototypes. Testability and flexibility of the scenarios are of great importance
especially on user/GUI level.
1.2 Scope of this Deliverable
This document defines the technical requirements for the real world scenarios planned for within the
uTRUSTit project. With these requirements at hand the basics for the implementation phase of the
scenarios are available. The structure of the scenario requirements chapters are partitioned into the
three basic scenarios Home, Office and e-Voting partitioned into their respective sub-scenarios.

After the implementation phase, developed prototypes will be the deliverable to the parties conducting
the trust tests using real people. Feedback and changes to the requirements will take place according
to feedback from those events. In most of the scenarios the technology is specified and also the devices
to use. However, scenarios may be implemented using various technologies and set-up, so
requirements from the project can have impact on technical requirement in later phases of the project.
A general requirement of the user interfaces, such as web and app interface, shall be accessible to
dyslexics and people with impaired vision. The web interface will follow the WCAG2.0 or the WAI-ARIA
as appropriate. For disseminations purposes new requirements may be imposed at a later stage. Use
and re-use of software and hardware, from 3
rd
parties may be used in the project.
1.3 Document Layout
Each scenario is given its own section: the smart home scenarios in Section 3, smart office scenarios in
Section 4, and e-voting scenarios in Section 5. The sub-scenario requirements sections are partitioned
into:

System overview
Functional requirements
Application and devices
Hardware requirements
Software requirements

For each sub-scenario, a system overview including a figure will show how the sub scenarios work and
are implemented. Functional requirements focus on the perceived functionality by the user or
administrator of a system. Applications and devices together with hard- and software provides the basis
for the used devices as well as actual implementations in the sub scenario.

30/04/2011
Page 6 / 28
2. Terminology
IoT Internet of Things
API Application Program Interface
TTS Text To Speech
HAP Home Access Point
HTPC Home Theatre Personal Computer
Bluetooth Bluetooth wireless technology
WLAN Wireless Local Area Network
WPA WiFi Protected Access
PHP Hypertext Preprocessor
RFID Radio Frequency Identification
NFC Near Field Communication
MySQL Open source database handler
VoIP Voice over IP / Voice over Internet Protocol
UI User Interface
I/O Input/Output
TMS Tracking Movement System
HMC Home Media Center
LAMP Linux Apache MySQL PHP
XBMC Xbox Media Center
PKI Public Key Infrastructure
WCAG 2.0 Web Content Accessibility v. 2.0
WAI-ARIA Web Accessibility Initiatives Accessible Rich Internet Applications
TalkBack Open source screen reader for Android devices from Google
USB Universal Service Bus
30/04/2011
Page 7 / 28
3. Scenario: Trusted Smart Home Services
This part covers what is expected to be seen as applications within homes and apartments. It is
understood that the following scenarios at home, at the office and e-voting also may take place in other
parts of the smart world. Using the word smart focuses on using technologies to make life easier in
the sense of having access, control and flexibility at home. There are devices and systems
(commercially) available, which are used in accordance with parts of this specification. Commercially
available applications and devices may be used when testability of trust, the key focus of the entire
project, can successfully be performed.
3.1 Sub-scenario: Door lock and wireless key management and control system
The scenario comprises a door with a wireless key lock system that aims at the ease of use and
flexibility by using mobile phones, and that uses the Internet for administrating the key handling. This
system consists of a door, a wireless key lock, and a system that distributes privileges to accessing the
lock for various users. The wireless control system shall use a Bluetooth-enabled mobile phone when
communicating with the door. This sub-scenario covers also the Lost keys to the apartment from the
definitions document D2.2.
3.1.1 System overview and description
The overview shows the suggested solution and implementation. Authentication data may be sent to
the mobile phone via Internet and used when entering into the house as a key to the specific door lock.
When entering into the house, information on status of the door lock, as well as the mobile phone
identity, may be registered via the mobile phone or the door lock to the home access point (HAP). Text
to Speech (TTS) and camera functionality may also be used in specific parts of this scenario.

Figure 1 Wireless key & management system
3.1.2 Functional requirements
The technical requirements are mapped to the scenario in the definition document D2.2. There are also
added requirements that are not included in D2.2, but should be considered in the functionality and the
implementation of the door lock system.
Door lock Mobile phone

Internet
Server / Data
base
Web based
Management /
Configuration
Bluetooth
Internet Access
Home access
point
Internet
Internet
Bluetooth
Internet
30/04/2011
Page 8 / 28
3.1.2.1 Door lock system
When managing the door lock the administrator (e.g. House owner or external company) shall be able
to provide and delete keys as well as getting information on the status of the door lock. Configuration
of the door lock shall be possible when the door lock is connected to the Internet via the HAP or a
mobile phone. When using the HAP to communicate with the door lock the placement in the home can
be important since the usual signalling distance is only about ten meters when Bluetooth technology is
used.

The target requirement for the door lock is to have an electronic lock installed directly on an existing
mechanical door lock. This would be advantageous in terms of ease of implementation and use in the
home scenario. The Bluetooth door lock is battery powered and should have low power consumption in
order to save battery. Therefore, the lock should only be connectable when the door handle is knocked-
on or when the door is actually opened.

Technical requirements Mapping definitions
Ordinary key may be used
Tamper protected from the outside
Mounting the Bluetooth control lock cause no damage to the door
and the existing lock

Fits standard doors
The control lock must be easy to install
Electric door lock engine
Bluetooth control in the door lock D2.2 ch 2.2.2.1 p 2

Mobile phone with Bluetooth for door opening D2.2 ch 2.2.2.1 p 2
Speakers at the front door reminds the user to bring the mobile
phone when exiting

Status check and handling for locked/unlocked door D2.2 ch 2.2.2 p 5
The door is locked automatically after remote opening
The door may be locked manually
Bluetooth simple remote control device for opening, stand-alone
control
D2.1 p 4 Description
Notify on door lock activity and tracking function to the mobile D2.2 ch 2.2.2 p 5. Together with
personal tracker
Ability to log door passes/device
Configuration of door lock
Key access/remote management. Allocation of keys through the lock
Internet access
D2.2 ch 2.2.2.1 p 3 & 4 , 2.2.3.1
p 3 & 6
Key access/remote management. Allocation of keys through the
mobile phone Internet access
D2.2 ch 2.2.2.1 p 3 & 4 , 2.2.3.1
p 3 & 6
The owner has with his mobile phone access to the camera at the
front door and possibility to open the door lock.
D2.2 ch 2.2.2.1 p 4

Authorizing keys for family, friends and personnel D2.2 ch 2.2.2 p 2
Access privileges for family, friends and personnel D2.2 ch 2.2.2 p family & friends
Access privileges for personnel D2.2 ch 2.2.2 p 3
Valid period, Time restrictions, key revoke

Wired/Wireless Network Camera D2.2 ch 2.2.2.1 p 4, Easy to
implement with #1/Limited
function with #2
30/04/2011
Page 9 / 28
Built-in microphone and speaker

API in mobile phone for Door opening and key handling
API's in key management system to control the Door lock
API's to control the Camera and speaker phone

The Key management system is connected to a directory service, containing the different keys and the
rights associated with them (e.g., validity period, time restrictions etc.). Via the home access point it
may be reached over the Internet, or from the 3G enabling users to create new keys and modify/ delete
existing keys remotely/ locally.

If the key is stored in the mobile, it may have a limited duration and needs to get renewed periodically
through the cellular or LAN networks. If the mobile does not have mobile coverage, the key may be
unusable when the validity period ends.
3.1.3 Application and devices
To access the key management system and mobile phone functionality applications running on the used
devices shall provide a GUI.
Key access management
Authorization for family, friends and personnel from health care
Check logs for door passes
Configuration of the lock (manually or automatically locked)
Status check and handling for locked/unlocked door
Main interface used for viewing the camera in a browser
The door opened/locked from the web page
3.1.3.1 Hardware
The hardware for the door lock is divided into the various functions needed to implement the sub-
scenario
Electric door lock engine
Bluetooth device control in the door lock
Bluetooth /Simple remote control device (TBD)
Manual key lock
Wired/Wireless Network Camera
Android based mobile phone
LAMP with I/O ports as a home access point
3.1.3.2 Software
Via the home access point web server, the keys are managed and the outdoor camera can be
monitored. On the HAP the door lock manager software is also running. The software is responsible for
updating and validating the door keys, opening the door on remote request and reporting door status.
It also manages the access logs an handles alarms/notifications if needed.
Linux
Apache
MySQL
PHP
Directory Services
Java
Android
TalkBack
30/04/2011
Page 10 / 28
3.2 Sub-scenario: Medicine Management and Control system
The medicine cabinet is an intelligent cabinet with a number of functions: it is an assistance tool for
elderly and impaired to manage their self-care with the need of extra support for their medical intake.
The system keeps track of medication, and sends notifications when the user or the mobile health care
service needs to refill medicines. The cabinet is equipped with an alert and warning system to user,
administrator (e.g. family member or external company) and mobile health service.
3.2.1 System overview and description
The Figure below shows how the cabinet is connected to the Internet. This provides access to the status
of medicine cabinet usage and gives an alarm when deviating from the medication scheme.

Figure 2 Medicine cabinet & management system

The Medicine cabinet can access the Tracking Movement System (TMS), the TTS system used by the
entrance door speaker, and the databases used by the health care provider via the HAP. By using the
health care database the medicine cabinet knows which RFID tags represent various pillboxes. From the
health care database, the Medicine cabinet accesses and downloads the ordination scheme for the
patient. The TMS notifies the medicine cabinet when the patient is away from home and the reminder
system for medicines should be activated. For security reasons, parts of the health care database
should also be copied to the medicine cabinet, e.g., in the case of malfunctions of the Internet
connection.

Medicine cabinet
Mobile phone

Internet
Server / Data
base
Web based
Management /
Configuration /
Information
WLAN / LAN
Home access
point
Internet
Internet
Internet
Internet
30/04/2011
Page 11 / 28

Figure 3 Entities of medicine cabinet

The figure above shows the entities of the medicine cabinet, including a pillbox with an RFID tag. The
cabinet has its own computer that is connected to the HAP. In the cabinet, the computer is connected
to various devices.
The system identifies the pill-boxes that are in the medicine cabinet. TTS feature supervise when wrong
medicine is taken out from the cabinet. The system shall be connected to Internet through a WLAN/LAN
connection. The medicine cabinet computer is connected to the RFID reader, the door sensor, the
camera, the speakers, HAP and Internet database services. RFID tags are used on the pillbox for
identification. There is an administration web page for configuring and viewing the status of the
Medicine cabinet. The built in camera may monitor the status and pill levels in the medicine boxes.
3.2.2.1 Medical Cabinet system
The requirements on the medical cabinet system are individually mapped according to the D2.2
document.

Cabinet material shall not disturb the RFID reading
RFID sensor reader for medical identification and registers D2.2 ch 2.2.4.1 p 1 & 2,
ch 2.2.4.2
Door sensor for door opening D2.2 ch 2.2.4.1 p 9
Alert to the user. 1) At once when the door is closed without all pillboxes in
place. 2) After a certain time when the door is open and the pill-boxes are
not in place
D2.2 ch 2.2.4.1 p 9
Alarm to the supervisor and health care. After a certain time 1) The door is
closed without all pillboxes being in place. 2) The door is open and a pillbox
is not in place.
D2.2 ch 2.2.4.1 p 9
Alert to the user with Text-to-speech warning D2.2 ch 2.2.4.1 p 9
Rough estimate of medicine by number of pillbox lifts from the cabinet by
using the RFID sensor.
D2.2 ch 2.2.4.1 p 10, ch
2.2.4.2.
Medicine cabinet
RFID reader
Computer
Web camera
RFID antenna
Cabinet lock /
door sensor
3G / WLAN
Built in / USB Built in / USB /
network
USB
IO / BT
Medicine
Pill-box
RFID tag
Speaker
Text - to - speech
30/04/2011
Page 12 / 28

The Medicine cabinet manages an individual medical schedule for the user D2.2 ch 2.2.4.1 p 2, 3
Speaker for text-to-speech message D2.2 ch 2.2.4.1 p 5
Text to speech, alert when incorrect pill box is lifted D2.2 ch 2.2.4.1 p 5
Controlling pill levels using the camera in the cabinet D2.2 ch 2.2.4.1 p 1, 4
Battery back-up
Electrical door lock
The user is able to choose the "take the medicine with me" when the alert
is coming up that the pill box is not in place
D2.2 ch 2.2.4.1 p7
Reminder take the medicine with me to mobile phone when leaving the
house
D2.2 ch 2.2.4.1 p7
Bluetooth or RFID tag for opening the door to the Medicine cabinet
Size of cabinet should be like e.g. bathroom cabinet
Medicine cabinet connected to Internet D2.2 ch 2.2.4.1 p 2, 6,
7,8, 9, 10, 2.2.4.2
Time to refill medicine, the medicine cabinet sends a request to the doctor
for new prescriptions.
D2.2 ch 2.2.4.1 p 10
The cabinet keeps track of medicine and posting to mobile and health
centre
D2.2 ch 2.2.4.1 p 6
Medical schedule with alarm D2.2 ch 2.2.4.1 p 6, 7, 8,
9
Reminder from the medicine cabinet to mobile D2.2 ch 2.2.4.1 p 8, info
via tracker
The user's mobile reminds when it's time to take medicine D2.2 ch 2.2.4.1 p 8
When the health care service replace pill boxes they are automatically
registered in the database
D2.2 ch 2.2.4.1 p 11
Mobile phone for opening the door lock

API's to medicine management system

3.2.2.2 Medical cabinet size
The below figures show suggested size and set-up of the medical cabinet. It includes possible positions
and sizes of screen, camera, door lock and pillboxes. Final and actual size and implementation will
follow in updates of this document.

30/04/2011
Page 13 / 28

Figure 4 Medicine cabinet dimensions.
The size of the cabinet is more or less as standard cabinets used in bathrooms today both from front
and side perspective.

Figure 5 Medicine cabinet dimensions
3.2.3 Applications and devices
The system identifies the pillboxes in the medicine cabinet via RFID tags. The TTS feature sends an alert
when the wrong medicine is taken out from the cabinet. The system shall be connected to the Internet
through a WLAN/3G connection. The medicine cabinet system with computer is connected to the RFID
reader, the door sensor, the camera, the speakers, HAP and Internet database services.

A Web page for viewing the status of the Medicine cabinet, and the built in camera for monitoring the
levels of the medicine boxes are the main interfaces used. We also consider using a mobile app for this
purpose. The web page will follow the WCAG 2.0 guidelines.
3.2.3.1 Hardware
The hardware for medicine cabinet/system is divided into the various functions needed to implement
the sub-scenario.
Medicine cabinet
RFID sensor reader
4 pcs pillboxes
Door sensor
30/04/2011
Page 14 / 28
Computer/Mobile
Web camera
RFID antenna
Antenna switch
Speaker
RFID tag label
WLAN/LAN
3.2.3.2 Software
A database containing the prescription schedule and the RFID to medicine mapping will run on the
cabinet computer. The medicine cabinet software is responsible for monitoring the RFID readers,
authenticating to the database, communicating with the TTS software and a web server running on the
cabinet computer for monitoring purposes.
Linux
Apache
MySQL
PHP
Directory Services
Java
Android
TalkBack
3.3 Sub-scenario: Home Entertainment Management

Figure 6 Media center & management system

The home media center (HMC) manages media content, such as music, films/video, photo albums, and
games. It can also connect to social networks, make and receive calls using VoIP. The HMC is connected
to the HAP via a network connection. The media center can distribute media content to sub terminals
30/04/2011
Page 15 / 28
placed in different rooms in the home. The media center can be configured to delegate access for its
own or for external media by altering rights in the local rights database.

Legend NW HMC DB
Network Home Media Center Data Base
Stream over images/music/video to media center HMC D2.2 ch2.3.1
Control media center through web interface (play, Pause, stop,
Volume etc.)
HMC D2.2 ch2.3.1
Mount users device as source HMC D2.2 ch2.3.1
User interface for playing (controlling media center) uTRUSTit device D2.2 ch2.3.1
Provide an GUI (interface) for videos and films stored in media
center
D2.2 ch2.3.1
wireless trusted distribution to all rooms HMC / NW D2.2 ch2.3.1
Streaming of music/video (images) over local network to other
media centers
HMC / NW D2.2 ch2.3.1
Synchronization between rooms etc. HMC / NW D2.2 ch2.3.1
Generic functionality in media center (plug ins etc.) HMC D2.2 ch2.3.1
Access to web accounts, social networks file sharing and VoIP HMC D2.2 ch2.3.1
Internet access to media center required HMC D2.2 ch2.3.1
VoIP client HMC D2.2 ch2.3.1
User privileges needed in media center HMC D2.2 ch2.3.1
Web based configuration interface HMC D2.2 ch2.3.1
Controlled through home network HMC/NW D2.2 ch2.3.1
User privileges on resources available to media center HMC D2.2 ch2.3.1
Streaming interface (Temporary guest upload area, mounting) HMC D2.2 ch2.3.1
Check in point, receives context with WLAN passkeys (through
unprotected WLAN )
/NW D2.2 ch2.3.1
Context contains WLAN keys, Media center user credentials, etc /NW D2.2 ch2.3.1
GUI for accessing MC functionality on device (web based) D2.2 ch2.3.2.1 p. 4
User needs to be authenticated for control
Adding files to MC storage over local network HMC/NW/ D2.2 ch2.3.2.1 p. 6
Play uploaded file on media center
Play files from MC storage D2.2 ch2.3.2.1 p. 7
Through GUI in phone
Access control interface from device /DB/HMC D2.2 ch2.3.2.1 p. 8
Help functionality for configuration and GUIs DB / HMC D2.2 ch2.3.2.1 p. 9
Access code needed to change permissions DB D2.2 ch2.3.2.1 p. 10
Protection for access control / user privileges on DB DB D2.2 ch2.3.2.1 p. 10
Multiple user solution/ only on possible at the time. HMC D2.2 ch2.3.2.3
Pad or mobile as uTRUSTit device D2.2 ch2.3.2.2

30/04/2011
Page 16 / 28
The HMC consists of a HTPC connected to stereo equipment and a screen. It can be controlled with a
traditional remote as well as with an uTRUSTit device. An app on the mobile/pad is used for viewing and
controlling the HMC. Using the app, users can start, stop music, films, make VoIP calls, etc. The app also
handles the authentication to the media center. The administrator utility will also be using a web
interface used to create accounts and delegate access rights to different users.
3.3.2.1 Hardware
The home media center consists of a computer with Audio and Video input/output capabilities. The
media will be stored on a file server and on local media.
HTPC
Amplifier and Speakers
Screen
LAMP serving as database and web server
Home access point
Pad or mobile
3.3.2.2 Software
A media center application will run on the computer using open source applications/solutions.
Linux
XBMC
Apache
MySQL
PHP
Directory Services
Java
Android
TalkBack
30/04/2011
Page 17 / 28
3.4 Sub-scenario: Tracking Movement

Figure 7 Tracking movement & management system

The tracking system consists of a tracking server residing in the Internet. With the web based
management page, user credentials, trustee rights, and alarm notifications can be configured and
viewed. The tracking device reads its configuration from the tracking server. A special browser-based
view page is used to follow the different tracking devices. The tracking system can be connected to the
door lock and the medicine cabinet for reminders, etc.

Legend

HAP TrackS WBV WBM
Home Access
Point
Tracking
Server
Web Based Viewer Web Management

Tracking server for storing positions TrackS D2.2 ch2.2.5.1 p 1,2,3,4,5&6
Alarm management in tracking server e-
mail
TrackS D2.2 ch2.2.5.1 p 2, 3 & 4
Alarm tracking logic. Who has been notified,
who has confirmed etc.
TrackS D2.2 ch2.2.5.1 p2, 3 & 4
Tracking functionality in device device D2.2 ch2.2.5.1 p 1,2&4
Geo fencing in tracking device/server device D2.2 ch2.2.5.1 p 1,2
Emergency override to access medical info
on device
device
D2.2 ch2.2.5.3
Timer controlled notification to user after
leaving geo fencing area
device
D2.2 ch2.2.5.1 p 2
device capable of showing several users
position
device
D2.2 ch2.2.5.1 p 5
30/04/2011
Page 18 / 28
Tracking server able to activate tracking
application in monitoring device
device
D2.2 ch2.2.5.1 p 2
Reminder to bring tracker/ cell phone when
going out e.g., Text-to-speech.
HAP D2.2 ch2.2.5.1 p 1 & D2.1 - Technical
Knowledge and Usage of Technology
Reminder to charge tracking device, Text-
to-speech e.g., When user gets home.
HAP D2.1 - Technical Knowledge and Usage of
Technology + Quote
Administer access privileges for family WBM D2.2 ch2.2.5.1 p 2 & 5
Administer access privileges for personnel WBM D2.2 ch2.2.5.1 p 3 & 6
Administer adding & removing privileges WBM D2.2 ch2.2.5.1 p 3, 5 & 6
Uses Google maps device
Uses customized maps device/TrackS
Customized symbols for different roles device
Tracking device notifies cabinet when
leaving geo fencing area
device
Viewing position on web WBV
Pad or mobile as device
A Tracking server accessible from the Internet will be used to store and present positions. The server is
connected to some directory services, where the server configuration, viewing permissions, etc. are
stored. The server is accessed and configured mainly with a browser; alternatively a mobile phone
acting as a uTRUSTit device can be used. Depending on the rights of the authenticated user, different
views will be presented. E.g., a user with administrative rights will be presented the main administrative
interface whilst an ordinary user will only see a web page showing tracking devices.
3.4.2.1 Hardware
Besides the necessary hardware needed to connect the tracking server and the different viewing/
tracking devices to the Internet and the following hardware is also needed.
Android cell phone; alternatively GPS/GSM dongle as tracking device.
Android based cell phone as viewing device.
PC acting as a tracking server with an Internet connection
Laptop for viewing web
3.4.2.2 Software
The software components used by the tracking server, browsing and tracking devices in this scenario
are mostly based on SWE software components.
LAMP software for the tracking server;
Directory Services for storing access rights, PKI etc.;
Java
TalkBack; and
Android.
30/04/2011
Page 19 / 28
3.5 Sub-scenario: Inventory of Things

Figure 8 Inventory of IoT management

A uTRUSTit device is able to see other devices in the Internet of Things, to monitor what the devices
request, and to see what information they transmit. Depending on his or her rights, the user can also
control the IoT devices, and configure what information these devices can transmit or receive. This
scenario uses the Home Access Point (HAP) as the central repository for registered devices. The actual
repository is a directory server placed on the Internet with a local replica for faster access.

Legend HAP MC MedCab TrackS
Home Access
Point
Media
Center
Medicine Cabinet Tracking Server


scanner (mobile phone) used to display registered devices device D2.2 ch2.4.1.1 p1
Home access Point with database containing registered devices and
their configuration options.
HAP D2.2 ch2.4.1.1 p2
device reads MC configuration from Home Access Point Device/HA
P
D2.2 ch2.4.1.1 p3 & 4
device reads the new MC configuration from Home Access Point Device/HA
P
D2.2 ch2.4.1.1 p6
device controls database on the Home Access Point and alters the
configuration.
Device/MC D2.2 ch2.4.1.1 p5
The home access point then updates the media center with new
configuration
MC/HAP D2.2 ch2.4.1.1 p5
UI/API
Door lock registered at Home Access Point (if exists) Door
lock/HAP

30/04/2011
Page 20 / 28
Medicine cabinet registered at Home Access Point (if exists) MedCab/H
AP

Tracking device registered at Home Access Point (if exists) TrackS/HAP
An Android based cell phone or pad is used as the viewing device. With the viewing device the different
IoTs can be monitored and configured. This requires that the different IoT devices have already
registered themselves at the HAP. As the Home Access point, a LAMP server will be used. A web page
will be used for management where IoTs can be added, deleted and configured. As in the previous
scenarios, the view presented to the user depends on the rights assign to the user.
3.5.2.1 Hardware
In this scenario the main devices are the HAP, the various IoTs registering to the HAP, and the viewing
device. Apart from the hardware needed to connect them together (e.g. by WLAN, 3G etc) the devices
used to add, delete and administer the IoT devices consist of:
PC acting as a HAP with router NAT capabilities;
Android based cell phone and/ or pad.
3.5.2.2 Software
The HAP will act as central point in this scenario running the LAMP, Java and Directory Services. The
Talkback software will run on the Android phone. If the medicine cabinet and door lock is connected, a
piece of software is needed on each device to connect to the HAP
LAMP software running the HAP
Directory Services
Java
Android
TalkBack
30/04/2011
Page 21 / 28
4. Scenario: Smart Office
4.1 Sub-scenario: Project Meeting with Entry Registration

Bluetooth to connect to receptionist D2.2 ch3.1.1.1 p1
Send identification and invitation D2.2 ch3.1.1.1 p1
Retrieve context from receptionist D2.2 ch3.1.1.1 p1
Text-to-speech, Speaker D2.2 ch3.1.1.1 p4
Display Electronic receptionist D2.2 ch3.1.1.1 p2
Bluetooth interface
Network interface computer
Network interface Mobile phone
Network interface Bluetooth / WLAN
Lighted path (Map downloaded with path) Electronic receptionist D2.2 ch3.1.1.1 p4
The invitation received by the visitor's uTRUSTit device, will be administered from a web application.
When the proper context, WAP keys, and other settings have been configured and stored in a directory
service, the invitation is sent to the visitor. On the uTRUSTit device, which in this case is a mobile phone
an app for viewing the invitation is needed. The app must also be able to download the context from
the electronic receptionist.
4.1.2.1 Hardware
The electronic receptionist will be a laptop with proper speakers, Bluetooth and hardware needed to
connect to a directory service.
A computer with Bluetooth acting as electronic receptionist
Android phone/ Pad as the uTRUSTit device
Speaker connected to electronic receptionist
Network interface in electronic receptionist
4.1.2.2 Software
The electronic receptionist software will connect to the Directory Service in order to obtain and manage
invitations, context, registrations etc. Via the Text-To-Speech module the receptionist communicates
with the user.
Text-To-Speech
TalkBack
Directory Service
4.2 Sub-scenario: Exchanging data with other project members

30/04/2011
Page 22 / 28
Device module for exchanging data Device D2.2 ch3.1.2.1 p5
Viewer on device to scrutinize received data Device D2.2 ch3.1.2.1 p6
Editor to alter information and what to be sent Device D2.2 ch3.1.2.1 p9, 2
Bluetooth or NFC in devices
The app used in this scenario is similar to the previous scenario. In addition, the requirements for this
scenario are the ability to view, modify and exchange vCards using Bluetooth.
4.2.2.1 Hardware and software
Android cell phone or pad shall run the app for sending and receiving contact information in the sub-
scenario.
4.3 Sub-scenario: Connecting to infrastructure

Module in the Laptop detects WLAN or selects from
context
Laptop D2.2 ch3.1.3.1 p2
Module in the laptop requests WPA key from mobile Laptop/mobile D2.2 ch3.1.3.1 p3
Module in the Laptop installs allocated recourses Laptop D2.2 ch3.1.3.1 p4
Uses context to connect to Print
Uses context to connect to projector
An application in the laptop is needed for polling WLAN and WPA keys. The application will then
connect to the mobile phone app used in previous scenarios, to obtain necessary WLAN configurations
from the previous downloaded context. The laptop app is also responsible for installing and configuring
the printers and the projector.
4.3.2.1 Hardware
An access point with an attached printer and projector will act as the conference room equipment. An
ordinary laptop with WLAN and Bluetooth will be used to connect to the infrastructure.
Laptop with Bluetooth used to attach to the smart office infrastructure.
Android cell phone or Pad
Printer
4.3.2.2 Software
The software used shall configure and install printers with drivers on the laptop and also connecting to
the projector installing needed drivers.
Application for installing printer and projector and to manage WLAN access.
Appropriate accessibility software.
Drivers for projector and printer
30/04/2011
Page 23 / 28
4.4 Sub-scenario: Smart door

Technical requirements Mapping
definitions
Credentials in context used for unlocking device/lock/server 3.1.6.1 p1
Bluetooth door lock lock 3.1.6.1
Connected to LAN lock 3.1.6.1
Authorization through database lock / server
Engine to open lock lock
Save entry/exit log lock / server 3.1.6.1 p7
Configuration stored in Directory server (entry/exit, user, save
log...)
lock / server
Configure if door should be allowed to store entry/exit
information
device / lock 3.1.6.1 p5
Door may choose not to open if entry/exit info needs to be
saved
lock 3.1.6.1 p9
Notify if door stores entry/exit information device 3.1.6.1 p4
Lock mounted in door frame
Power and network through cables
The same application used in the registration scenario is also used for configuring the door access. The
mobile app will use the same key for the different locks. When a lock detects that the user is trying to
open, the lock will act according to the configuration settings stored in the directory service.
4.4.2.1 Hardware
The hardware used in this scenario is similar to the door lock sub-scenario except that the lock is now
connected to the electronic receptionist for verification of keys.
Electronic lock plate (or engine)
PC with Bluetooth and Network access controlling lock
Android based cell phone or Pad
4.4.2.2 Software
The software running on the computer controlling the lock is attached to a server running the directory
service. For dissemination purpose the electronic receptionist and the lock software may run on the
same computer
Directory service for storing configuration
Lock software controlling the lock and authenticating user devices.
4.5 Sub-scenario: Smart Break Room
The customer purchases items inside the smart break room. Selection of the item and payment is
performed when the customer waves his/her device over the payment area for the chosen item. If the
customer is accidentally bumped into by someone and repeatedly touches the pay area with his device,
he/she can check the transaction log to make sure it has not caused another payment transaction.
30/04/2011
Page 24 / 28

definitions
Provide goods Vending machine D2.2 ch3.2.1.1 p2,3
Register payment on NCF paying area Vending machine D2.2 ch3.2.1.1 p4,8
Contact accounting server Vending machine D2.2 ch3.2.1.1 p4,8
Pay for goods over NFC link Mobile phone D2.2 ch3.2.1.1 p4,8
Review transactions log and account balance Mobile phone D2.2 ch3.2.1.1 p10
4.5.2.1 Hardware
A vending machine equipped with an NFC reader and a NFC enabled mobile phone is needed for this
scenario:
Vending machine equipped with NFC reader
NFC enabled smart phone
4.5.2.2 Software
Software components realizing an e-payment infrastructure are required. The vending machine needs
to keep track of stocks and perform accounting functions. The mobile phone e-payment component
needs to keep track of monetary transactions.

Detailed software requirements:
Vending machine driver
o NFC Card Reader Driver
o Accounting client: Connects to the accounting server and subtracts the price of the
purchased items from the customers balance.
Accounting client for mobile phone (Android, Java)
o Payment via NFC link
o Retrieve the balance from accounting server
Accounting server: Handles payment transactions.
30/04/2011
Page 25 / 28
5. Scenario: e-Voting
All major scenarios from the definitions document D2.2 are covered in this requirements specification.
Not covered are however E-Voting system for owners of apartment in apartments building.
Voting Application
Voting Terminal
Voting Client
Application
Device 1
Device 2
Device 3
Internet
Delegate Credentials
Delegate Credentials Vote / Inspect

Figure 9 e-Voting management system
5.1 Sub-scenario: Voting for Someone Else
In this scenario the participants deliver their votes in person by appearing at a location where voting
terminals are situated. They supply proof of their identity and enter their vote into a terminal.
This scenario is further enhanced with delegation of voting credentials. A participant can transfer his or
her voting credentials to another person, who in turn can re-transfer these credentials to another party.

definitions
Voting credentials are transferred between devices uTRUSTit devices
(mobile)
D2.2 ch4 1.1.1 p1-2
Connecting to and registering in electronic election
registering system
Voting Application
(Laptop)
D2.2 ch4 1.1.1 p4
Confirming voter identity Voting Application
(Laptop)
D2.2 ch4 1.1.1 p5
Directing registered user to one of the terminals Voting Application
(Laptop)
D2.2 ch4 1.1.1 p6

30/04/2011
Page 26 / 28
Participants need to supply either proof of their identity, or delegated credentials to the
electronic registry. In order to accomplish that, they need to be able to interface their uTRUSTit
devices with the voting infrastructure.
Participants shall be able to transfer voting credentials between their uTRUSTit devices.
5.1.2.1 Hardware
The electronic register and voting terminal may be realized by a single computer. For interfacing with
the voters uTRUSTit device we propose a NFC reader. The voter authenticates himself with his
uTRUSTit device over the NFC link, and then proceeds to enter his vote using the keyboard of the input
terminal.
Transfer of the voting credentials between uTRUSTit devices can be transferred over a wide array of
connectivity media ranging from WLAN to Bluetooth to other NFC protocols.
5.1.2.2 Software
Voting software installed on the voting terminal shall rely on X.509 certificates for
authentications.
Transfer of credentials shall also be based on Public Key Infrastructure and digital signature. In
order to transfer voting privileges, a permit needs to be issued to a second party and digitally
signed. This provides a non-refutable proof of intent. In his turn the second party may use the
same approach to grant voting privileges to a third person. Of course the electronic registry
shall be programmed to only accept one vote from the delegation chain. Only the first incoming
vote is admitted.
5.2 Sub-scenario: Vote from abroad
In this scenario the participant is voting from abroad. She authenticates herself using her uTRUSTit
device and then supplies her vote online.

definitions
Loading e-voting application Laptop D2.2 ch4 1.2.1 p1
Registering in e-voting system uTRUSTit device, Laptop
(NFC)
D2.2 ch4 1.2.1 p2
Confirming voter identity Voting Application
(laptop)
D2.2 ch4 1.2.1 p3
Presenting ballot to the registered user Voting Application
(laptop)
D2.2 ch4 1.2.1 p4

The participant must be able to download the voting client application.
The participant needs to authenticate him/herself to the client application.
The voting procedure needs to be implemented using a client-server model.
A computer is needed to install and run the e-voting client application. This could be the same device
that is acting as the participants uTRUSTit device. However, for the sake of subsequent scenarios, we
30/04/2011
Page 27 / 28
assume two separate entities . The participant needs to interface to the desktop computer. This can be
accomplished using WLAN, Bluetooth or NFC.
Desktop computer
uTRUSTit device
E-voting server: provides e-voting service to connected and authenticated clients over a secured
channel (SSL/TLS, IPSec).
E-voting client: Authenticates user and interacts with server.
uTRUSTit device authentication query component: This component facilitates querying the
identity of its owner.
Appropriate accessibility software.
5.3 Sub-scenario: The participant Votes on the Options
The participant installs the voting client on her computing device. Then she transfers the ballot to her
uTRUSTit device where she can use the familiar accessibility options. She selects an option then re-
transfers her selection to the first device that submits her vote to the remote server.

definitions
Transferring ballot to uTRUSTit device Voting application (laptop),
uTRUSTit device (mobile)
D2.2 ch4 1.3.1 p1
User magnifies the ballot on UI uTRUSTit device (mobile) D2.2 ch4 1.3.1 p2
User marks their choices on ballot UI uTRUSTit device (mobile) D2.2 ch4 1.3.1 p3-
4
User transfers the filled in ballot back to the
voting application
uTRUStit device (mobile), Voting
Application
(laptop)
D2.2 ch4 1.3.1 p5
User submits vote Voting Application
(laptop)
D2.2 ch4 1.3.1 p6

The difference between this scenario and the first one consists in the interaction of the two local
devices. The participant needs to transfer information to the secondary device, effect changes on its UI,
and then propagate the changes back to the primary device.
Same requirements apply as for previous sub-scenario. To accomplish this task we envision a software
utility similar to remote desktop applications, whereby a user can access a remote desktop. In our case
the remote desktop client should be enhanced with the accessibility options required by the
participant, namely image zooming.
5.4 Sub-scenario: Impaired participant votes on options
The participant is a affected by dyslexia and requires additional support from the IT infrastructure. He
first checks whether the voting terminal has been tampered with. Then he prompts the terminal to read
aloud the ballot choices, and makes his selection. Using his uTRUSTit device he confirms he has made
30/04/2011
Page 28 / 28
the right choice, and finally submits his vote. The rationale behind the double check is motivated by his
dyslexia. He wants to confirm his choice on a device he is familiar using.

definitions
User ensures security properties of the voting
terminal (data tampering)
uTRUSTit device (mobile), Voting
Terminal (laptop)
D2.2 ch4 1.4.1 p1
User recognizes and utilizes readout function in
the voting terminal
Voting Terminal (laptop) with user
interface, sound I/O
D2.2 ch4 1.4.1
p2-4
User marks their choices on ballot UI Voting Terminal (laptop) D2.2 ch4 1.4.1 p5
User verifies their vote uTRUSTit device (mobile) D2.2 ch4 1.4.1 p6
User submits vote Voting Terminal (laptop) D2.2 ch4 1.4.1 p7
Same hardware configuration used as in previous sub-scenarios. In order to support voting terminal
integrity check, the operating system of the terminal needs to be equipped with a security component
that guarantees integrity of the installed software base and hardware components. Mechanisms need
to be deployed that detect physical breach of the terminal (e.g., opening of the device cover).
To support access by the participants uTRUSTit device the terminal software needs to provide a
component that allows secure remote access to its UI.

uTRUSTit D2.4 Technical Requirements For The IoT Prototype Final

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

uTRUSTit D2.4 Technical Requirements For The IoT Prototype Final

Caricato da

Copyright:

Formati disponibili

30/04/2011

Potrebbero piacerti anche