Internet of Things Environment for Service Creation and Testing

croutonsgruesomeΔίκτυα και Επικοινωνίες

16 Φεβ 2014 (πριν από 3 χρόνια και 6 μήνες)

336 εμφανίσεις

   
 

D2.1 Dissemination Level – PU  Page 1 
 



Small or medium-scale focused research project (STREP)
ICT Call 7
FP7-ICT-2011-7


Internet of Things Environment for
Service Creation and Testing

IoT.est

Grant Agreement 288385


Report on Use Case Scenarios and Requirements
for the Internet of Things


Document Ref.
D2.1
Document Type
Report
Workpackage
WP2
Lead Contractor
AI
Author(s)
Jorge Vaquero Sesmero, Lara Lopez Muñiz, Ralf Tönjes,
Eike Reetz, Daniel Kuemper, Filipe Cabral Pinto, Paulo
Chainho, Bogdan-Sorin Tarnauca, Wei Wang, Ruidong Li
and Svend Rostgaard Thielsen
Contributing Contractors
ATOS, UASO, PTIN, SIE, US, AI
Planned Delivery Date
31.05.2012
Actual Delivery Date
31.05.2012
Dissemination Level
PU
Status
Final
Version
N/A
Reviewed by
Bogdan Stanca-Kaposta and Suparna De
   
 

D2.1 Dissemination Level – PU  Page 2 
 





Executive Summary

The IoT.est project (Internet of Things Environment for Service Creation and Testing) aims at
establishing and easing the creation and provision of Internet of Things (IoT) enabled business
services by bringing together the following three disciplines: Internet of Things, Service Engineering
and Testing. The objective of the project is to develop a service creation and provision environment
for reliable “Internet of Things” enabled business processes.

IoT.est develops a test-driven service creation environment (SCE) for Internet of Things enabled
business services. The SCE will enable the acquisition of data and control/actuation of sensors,
objects and actuators. The project will provide the means and tools to define and instantiate IoT
services that exploit data across domain boundaries and facilitate run-time monitoring which enables
autonomous service adaptation to environment/context and network parameter (e.g. QoS) changes.
The project will prototype its major concepts and will evaluate the results for exploitation towards
future IoT service creation, deployment and testing products.

This report analyses a number of IoT application domains to identify typical IoT scenarios and related
use cases. The IoT scenarios and use-cases are analysed with the purpose of deriving the
requirements for reliable service management in the different service life cycle phases. The
requirements will drive the IoT.est architecture development with focus on re-usable cross service
boundary tools for easy and reliable IoT service creation and provision.

Criteria have been defined according to the IoT.est project objectives to prioritize representative and
challenging scenarios for IoT.est. Based on scenarios in 14 application domains, three were chosen
based on criteria’s such as complexity of the involved functionality in the scenario, the non-functional
requirements and the realism of implementing the scenario;
- Emergency - Smart Events Scenario,
- Energy – Energy Efficient Buildings Scenario, and
- Healthcare - Well Being Scenario.
These three scenarios and their related use cases are analysed further with the purpose of deriving
requirements for the IoT.est framework.

As IoT.est aims at supporting the complete service life-cycle from service creation to service provision
a special effort was undertaken to state also service life-cycle specific requirements. These focus on
semantic descriptions, service composition and testing during design-time and service deployment,
monitoring, and adaptation & compensation during run-time.

This deliverable on use case scenarios and requirements serves as a base for the future documents,
such as IoT.est architecture (WP2), derivation of re-usable service and test components (WP3),
definition of service creation (WP4) and provision mechanisms (WP5).

   
 

D2.1 Dissemination Level – PU  Page 3 
 

Contents

1.
 
Introduction...................................................................................................................................... 8
 
1.1
 
Motivation and Scope .............................................................................................................. 8
 
1.2
 
Purpose of the Document ....................................................................................................... 9
 
1.3
 
Overview of the Document ...................................................................................................... 9
 
2.
 
Terminology................................................................................................................................... 10
 
3.
 
Scenario Description Methodology ............................................................................................... 12
 
3.1
 
State of the Art in categorizing IoT Application Domains ...................................................... 12
 
3.2
 
Internet of Things Application Domains ................................................................................ 13
 
3.3
 
Definition of Scenarios, Use Cases and Requirements ........................................................ 13
 
3.4
 
Methodology for Scenario Description .................................................................................. 14
 
3.4.1
 
Scenario Description Structure ..................................................................................... 14
 
3.4.2
 
Use Case Descriptions .................................................................................................. 14
 
3.4.3
 
Description of Functional Components ......................................................................... 15
 
3.4.4
 
Description of Non Functional Aspects ......................................................................... 15
 
3.4.5
 
Description of Test related Aspects .............................................................................. 16
 
4
 
IoT Application Domains ............................................................................................................... 17
 
4.1
 
Transportation ....................................................................................................................... 17
 
4.2
 
Smart Home .......................................................................................................................... 17
 
4.3
 
Smart City .............................................................................................................................. 17
 
4.4
 
Smart Factory ........................................................................................................................ 17
 
4.5
 
Supply Chain ......................................................................................................................... 17
 
4.6
 
Emergency ............................................................................................................................ 18
 
4.7
 
Healthcare ............................................................................................................................. 18
 
4.8
 
Lifestyle ................................................................................................................................. 18
 
4.9
 
Retail ..................................................................................................................................... 18
 
4.10
 
Agriculture ............................................................................................................................. 18
 
4.11
 
Culture and Tourism .............................................................................................................. 19
 
4.12
 
User Interaction ..................................................................................................................... 19
 
4.13
 
Environment .......................................................................................................................... 19
 
4.14
 
Energy ................................................................................................................................... 19
 
5
 
Evaluation of Scenarios ................................................................................................................ 20
 
5.1
 
Criteria Function .................................................................................................................... 20
 
5.2
 
Evaluation of IoT Scenarios ...................................................................................................... 21
 
5.3
 
Prioritizing the Scenarios ...................................................................................................... 23
 
6
 
Prioritized Scenarios ..................................................................................................................... 24
 
6.1
 
Emergency - Smart Events ................................................................................................... 24
 
6.1.1
 
Scenario Description ..................................................................................................... 24
 
6.1.2
 
Actors ............................................................................................................................ 25
 
   
 

D2.1 Dissemination Level – PU  Page 4 
 

6.1.3
 
Objectives and Goals .................................................................................................... 25
 
6.1.4
 
Relation to other Scenarios ........................................................................................... 25
 
6.1.5
 
Use Cases ..................................................................................................................... 25
 
6.1.5.1 Share context related Data with Co-workers .................................................................... 26
 
6.1.5.2 Crowd control at Large Events .......................................................................................... 27
 
6.1.5.3 Activate Emergency Plan .................................................................................................. 29
 
6.1.5.4 Automatic collaboration in case of Emergency (Heatstroke or other Illness) ................... 30
 
6.1.5.5 Making Data Available for the Festival Guests (about empty Garbage bins) ................... 31
 
6.2
 
Energy Efficient Buildings ..................................................................................................... 31
 
6.2.1
 
Scenario Description ..................................................................................................... 31
 
6.2.2
 
Actors ............................................................................................................................ 32
 
6.2.3
 
Objectives and Goals .................................................................................................... 32
 
6.2.4
 
Relation to other Scenarios ........................................................................................... 33
 
6.2.5
 
Use Cases ..................................................................................................................... 33
 
6.2.5.1 Conference Room Lighting ............................................................................................... 33
 
6.2.5.2 Hallways Lighting .............................................................................................................. 35
 
6.2.5.3 Office Cooling and Heating ............................................................................................... 37
 
6.3
 
Well Being ............................................................................................................................. 39
 
6.3.1
 
Scenario Description ..................................................................................................... 39
 
6.3.2
 
Actors ............................................................................................................................ 40
 
6.3.3
 
Objectives and goals ..................................................................................................... 40
 
6.3.4
 
Relation to other scenarios, .......................................................................................... 40
 
6.3.5
 
Use Cases ..................................................................................................................... 40
 
6.3.5.1 Daily Wellness Monitor...................................................................................................... 40
 
6.3.5.2 Alerting AAL wizard ........................................................................................................... 42
 
6.3.5.3 Multimedia Session setup between AAL Wizard and Maria ............................................. 43
 
6.3.5.4 Maria setups a Connection ............................................................................................... 44
 
6.3.5.5 Panic Attack ...................................................................................................................... 45
 
6.3.5.6 Wizard Assistance ............................................................................................................. 47
 
7
 
IoT.est Generic Use Cases ........................................................................................................... 49
 
7.1
 
Actors .................................................................................................................................... 49
 
7.2
 
Use Cases ............................................................................................................................. 49
 
7.2.1
 
GB-UC-1 Conceive IoT Product Offer ........................................................................... 49
 
7.2.2
 
GB-UC-2 Design Product .............................................................................................. 50
 
7.2.3
 
GB-UC-3 Design Atomic Service .................................................................................. 51
 
7.2.4
 
GB-UC-4 Design Composite Service ............................................................................ 51
 
7.2.5
 
GB-UC-5 Create Atomic Service ................................................................................... 52
 
7.2.6
 
GB-UC-6 Compose Service .......................................................................................... 53
 
7.2.7
 
GB-UC-7 Unit Tests ...................................................................................................... 53
 
7.2.8
 
GB-UC-8 Integration Tests ............................................................................................ 55
 
   
 

D2.1 Dissemination Level – PU  Page 5 
 

7.2.9
 
GB-UC-9 Regression Tests .......................................................................................... 55
 
7.2.10
 
GB-UC-10 Non-Functional Tests .................................................................................. 56
 
7.2.11
 
GB-UC-11 Deployment Preparation.............................................................................. 57
 
7.2.12
 
GB-UC-12 Service Certification (preproduction) ........................................................... 57
 
7.2.13
 
GB-UC-13 Service Provisioning .................................................................................... 58
 
7.2.14
 
GB-UC-14 Service Usage ............................................................................................. 58
 
7.2.15
 
GB-UC-15 Service Authorisation .................................................................................. 59
 
7.2.16
 
GB-UC-16 Service Usage Charge ................................................................................ 60
 
7.2.17
 
GB-UC-17 Service Monitoring ....................................................................................... 61
 
7.2.18
 
GB-UC-18 Service Adaptation ...................................................................................... 62
 
7.2.19
 
GB-UC-19 Update Product Offer .................................................................................. 62
 
7.2.20
 
GB-UC-20 Update Preparation ..................................................................................... 63
 
7.2.21
 
GB-UC-21 Update Deployment and Provisioning ......................................................... 63
 
8
 
Requirements ................................................................................................................................ 64
 
8.1
 
Requirements Analysis Methodology .................................................................................... 64
 
8.2
 
Scenario Driven Requirements ............................................................................................. 65
 
8.2.1
 
List of Scenario Driven Requirements .......................................................................... 65
 
8.2.2
 
List of Scenario Driven Goals ........................................................................................ 70
 
8.3
 
Service Lifecycle Requirements ............................................................................................ 72
 
8.3.1
 
Requirements for the Design-Time Phase .................................................................... 72
 
8.3.1.1 Semantics ......................................................................................................................... 72
 
8.3.1.2 Service Composition ......................................................................................................... 77
 
8.3.1.3 Testing .............................................................................................................................. 83
 
8.3.2
 
Requirements for the Run-Time Phase ........................................................................ 88
 
8.3.2.1 Testing Environment ......................................................................................................... 88
 
8.3.2.2 Large Scale Deployment, Monitoring and Adaptation ...................................................... 90
 
9
 
Conclusion..................................................................................................................................... 94
 
10
 
Reference .................................................................................................................................. 95
 
Appendix ............................................................................................................................................... 96
 
Table Template of Non-Functional Qualities ..................................................................................... 96
 
Complete list of Scenarios and Use Cases ....................................................................................... 97
 
1) Transportation ........................................................................................................................... 97
 
2) Smart Home .............................................................................................................................. 98
 
3) Smart City ............................................................................................................................... 102
 
4) Smart Factory ......................................................................................................................... 105
 
5) Supply Chain Management..................................................................................................... 105
 
6) Emergency .............................................................................................................................. 106
 
7) Healthcare ............................................................................................................................... 106
 
8) Lifestyle ................................................................................................................................... 109
 
9) Retail ....................................................................................................................................... 109
 
   
 

D2.1 Dissemination Level – PU  Page 6 
 

10) Agriculture ............................................................................................................................. 110
 
11) Culture and Tourism ............................................................................................................. 113
 
12) User Interaction ..................................................................................................................... 113
 
13) Environment .......................................................................................................................... 114
 
14) Energy ................................................................................................................................... 114
 




   
 

D2.1 Dissemination Level – PU  Page 7 
 

Table of abbreviations

AAL Ambient Assisted Living
API Application Programming Interface
AS Atomic Service
CS Composed Services
EU European Union
F Functional
FP6 The Sixth Framework Programme
FP7 The Seventh Framework Programme
GPS Global Positioning System
GUI Graphical User Interface
HTTP Hypertext Transfer Protocol
HVAC Heating, Ventilation, and Air Conditioning
ICT Information and Communication Technology
IERC Internet of Things European Research Cluster
IOPE Input, Output, Precondition and Effect
IoT Internet of Things
IoT.est Internet of Things Environment for Service Creation and Testing
KPI Key Performance Indicators
LED Light-Emitting Diode
MoSCoW A prioritization technique (Must, Should, Could, Would)
N/A Not Applicable / Not Available
NF Non Functional
OS Operating System
PC Personal Computer
QoE Quality of Experience
QoS Quality of Service
RFID Radio Frequency Identification
SCADA Supervisory Control And Data Acquisition
SCE Service Creation Environment
SLA Service Level Agreement
SMS Short Message Service
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SUT System Under Test
WBA Well Being Application
WP Work Package
WS-BPEL Web Service Business Process Execution Language
WSDL Web Service Definition Language
XML Extensible Markup Language



   
 

D2.1 Dissemination Level – PU  Page 8 
 

1. Introduction
1.1 Motivation and Scope
To date, implementations of Internet of Things (IoT) architectures are confined to particular
application areas and tailored to meet only the limited requirements of their specific applications.
These silo solutions used in these individual application domains hinder the uptake and penetration of
specific tailored services for Internet of Things applications, in particular for innovative business
processes. Hence the provisioning of IoT enabled business services (in short IoT services) is a time-
and cost extensive process. The complexity involved in data acquisition, quality control, context
interpretation, decision support, and action control hinders uptake and penetration of specific tailored
services for “Internet of Things” applications.

To overcome technology & application domain boundaries and to dynamically design and integrate
new types of services and generate new business opportunities requires a dynamic service creation
and provision environment that gathers and exploits data and information from sensors and actuators
across domain boundaries that use different communication technologies/formats.

IoT.est will establish and ease the creation and provision of IoT enabled business services by bringing
together the following three disciplines: Internet of Things, Service Engineering and Testing. The
objective of the project is to develop a service creation and provision environment for reliable “Internet
of Things” enabled business processes.

IoT.est distinguishes four service life cycle phases belonging either to design- or run-time. Design-
time is understood as the service creation time that splits into modelling and composition phases.
Run-time aspects cover service provision that can be subdivided into service deployment and service
execution. In IoT.est all phases are characterized by a knowledge based, test driven approach.
IoT service creation (design-time):
• Modelling Phase: Knowledge based methods derive semi-automatically services and related
tests from semantic service descriptions based on standard service interfaces and re-usable
service and test components.
• Composition Phase: A test-aware IoT Service Creation Environment supports incremental
service evolution by regression tests. When adding new functionalities, the service
components and system tests are included to ensure backward compatibility with previous
service releases.
IoT service provision (run-time):
• Deployment Phase: The framework forces service validation tests in a sandbox environment
before deployment in the service providers’ infrastructure, including automated deployment
procedures based on semantics for service resource requirements and network capabilities.
• Execution Phase: Run-time monitoring mechanisms enable service adaptation to environment
changes and adjustment of network parameters. This adaptation can result in reselection of
involved components at run-time.
   
 

D2.1 Dissemination Level – PU  Page 9 
 


Figure 1.1 - Life-Cycle Management for IoT enabled Business Processes
1.2 Purpose of the Document
This report analyses IoT applications domains to identify typical IoT scenarios and related use cases.
The IoT scenarios and use-cases are analysed with the purpose of deriving the requirements for
reliable service management in the different service life cycle phases. The requirements will drive the
IoT.est architecture development with focus on re-usable cross service boundary tools for easy and
reliable IoT service creation and provision.
1.3 Overview of the Document
The next chapter contains an overview of the terminology that will be used. Chapter 3 describes the
chosen approach to structure, define and describe the scenarios. Following that, a short introduction
to the various IoT application domains will be given. Chapter 5 describes how the project has
prioritized the various IoT scenarios. In chapter 6 the prioritized scenarios are documented. Chapter 7
contains the IoT.est generic use cases. Section 8 derives the requirements from the scenarios and
use cases and, finally, chapter 9 summarizes the concluding remarks.

The deliverable D2.1 on use case scenarios and requirements serves as a base for the future
documents, such as IoT.est architecture (WP2), derivation of re-usable service and test components
(WP3), definition of service creation (WP4) and provision mechanisms (WP5).


   
 

D2.1 Dissemination Level – PU  Page 10 
 

2. Terminology

This Chapter provides formal definitions for the terms used throughout the project and this document.
Definitions of the terms related to the IoT are mostly adapted from the IoT-A
1
project, which is the
largest EU FP7 project on IoT architecture [Joachim W. Walewski et al, 2011], [De et al, 2011].
Definitions of the terms related to services are mostly adapted from W3C [W3C-gloss], [W3C-OWLS]
and the SOA4ALL project [SOA4ALL-gloss]. This chapter also defines the terms that are essential to
this project, i.e., service adaptation and compensation.

Actor: an entity which is outside of the IoT.est system. Actors can be users, external connected
systems, external databases etc. The interaction between an actor and the system is described within
use cases. [AgileModeling]

Atomic Service: Atomic services are ones where a single Web-accessible computer program,
sensor, or device is invoked by a request message, performs its task and perhaps produces a single
response to the requester. With atomic services there is no ongoing interaction between the user and
the service. [W3C-OWLS]

Augmented entity: as the composition of a physical entity and its associated virtual entity. [Joachim
W. Walewski et al, 2011]

Composite service: complex or 'composite' services are composed of multiple more primitive
services, and may require an extended interaction or conversation between the requester and the set
of services that are being utilised. [W3C-OWLS]

Digital entities: are a synchronised representations of a given set of aspects (or properties) of the
physical entity. [Joachim W. Walewski et al, 2011]

Device: Technical physical component (hardware) with communication capabilities to other IT
systems. A device can be either attached to, or embedded inside a physical entity, or monitor a
physical entity in its vicinity. It can be Mobile Phone, Embedded system, sensor node with multiple
sensors, and/or actuators, or any sensor, actuator, or gateway. [Joachim W. Walewski et al, 2011],
[De et al, 2011]

Gateway Device: provides protocol translation between peripheral trunks of the IoT that are provided
with lower parts of the communication stacks. [Joachim W. Walewski et al, 2011]

Internet of Things (IoT): A dynamic global network infrastructure with self configuring capabilities
based on standard and interoperable communication protocols where physical and virtual “things”
have identities, physical attributes, and virtual personalities and use intelligent interfaces, and are
seamlessly integrated into the information network. [IERC]

IoT Service: IoT service is a subclass of service which represents the capability of its corresponding
IoT resource. An IoT service integrates IoT into the world of high level business services. Although
most of the IoT services are atomic, the definition does not restrict them to be composite.

Linked Data: The Semantic Web is a Web of Data — of dates and titles and part numbers and
chemical properties and any other data one might conceive of. To make the Semantic Web a reality,
not only does the Semantic Web need access to data, but relationships among data should also be
made available, too, to create a Web of Data. This collection of interrelated datasets on the Web can
also be referred to as Linked Data. [W3C-gloss]


1
IoT-A terminology can be found here: http://www.iot-a.eu/public/terminology
   
 

D2.1 Dissemination Level – PU  Page 11 
 

Physical entity: is a discrete, identifiable part of the physical environment which is of interest to the
user for the completion of his goal. Physical entities are represented in the digital world via a virtual
entity. [Joachim W. Walewski et al, 2011]

Resources: are software components that provide information about physical entities or enable the
controlling of devices. [Joachim W. Walewski et al, 2011], [De et al, 2011] (Note: IoT Resource and
Resource will be used interchangeably.)

Semantic Web: The term “Semantic Web” refers to W3C’s vision of the Web of linked data. Semantic
Web technologies enable people to create data stores on the Web, build vocabularies, and write rules
for handling data. [W3C-gloss]

Service: A service is an abstract resource that represents a capability of performing tasks that form a
coherent functionality from the point of view of providers entities and requesters entities. To be used,
a service must be realized by a concrete provider agent. [W3C-gloss]

Service Adaptation: Service adaptation refers to the techniques that automatically modify service
behaviour according to the changes of service operating context to meet service provider or
consumer’s requirements and goals. This definition is proposed based on the following definitions.

Service adaptation refers to the problem of modifying a service so that it can correctly interact with
another service, overcoming functional and non-functional mismatches and incompatibilities.
[Kongdenfha et al, 2006]

Adaptation refers to techniques that enable efficient ubiquitous accessibility and personalization to the
user situation and preferences. [Attou et al, 2007] This definition is mainly for personalisation to user
situation and preference.

Adaptation means techniques to ensure the interoperability between different service description
technologies. [Brogi et al, 2004] This focuses on interoperability between different service description
technologies.

Mainly there are three domains of adaptation: a) content adaptation, b) adaptation of behavior
(services) and c) presentation (or interface) adaptation. [Miraoui et al, 2008]

Adaptation, the process of modifying a service system in order to satisfy new requirements and to fit
new situations, can be performed either because monitoring has revealed a problem or because the
application identifies possible optimizations or because its execution context has changed. [PLAY,
2011]

Service Capability: A Service Capability is the functionality offered by a service, including quality of
the service. [SOA4ALL-gloss]

Service Choreography: Service Choreography is the specification of interactions among a set of
services, described from a global perspective. [SOA4ALL-gloss]

Service Compensation: Service compensation refers to techniques for automated replacement of
existing service(s) or service component(s) in order to meet service provider or consumer’s
requirements and goals.

Service Composition: Service Composition is the act of executing service coordination. [SOA4ALL-
gloss]

Service Composition involves the development of customized services often by discovering,
integrating, and executing existing services. It's not only about consuming services, however, but
also about providing services. This can be done in such a way that already existing services are
orchestrated into one or more new services that fit better to the composite applications. [SAP-SCN]
   
 

D2.1 Dissemination Level – PU  Page 12 
 


Service Coordination: Service Coordination is the interaction among services. Coordination can be
described in one of two forms: orchestration or choreography. [SOA4ALL-gloss]

Service Deployment: All of the activities that make a service available for use. [SOA4ALL-gloss]

Service description: A service description is a set of documents that describe the interface to and
semantics of a service. [W3C-gloss]

Service discovery: The act of locating a machine-processable description of a Web service-related
resource that may have been previously unknown and that meets certain functional criteria. It involves
matching a set of functional and other criteria with a set of resource descriptions. The goal is to find
an appropriate Web service-related resource. [W3C-gloss]

Service end point: An association between a binding and a network address, specified by a URI, that
may be used to communicate with an instance of a service. An end point indicates a specific location
for accessing a service using a specific protocol and data format. [W3C-gloss]

Service interface: A service interface is the abstract boundary that a service exposes. It defines the
types of messages and the message exchange patterns that are involved in interacting with the
service, together with any conditions implied by those messages. [W3C-gloss]

Service Orchestration: A Service Orchestration is the description of how a specific service can be
realised by interacting with other services. The orchestration is under control of a single endpoint. An
Orchestration may be executable. [SOA4ALL-gloss]

User: The user is a human person or some kind of active digital entity (e.g., a Service, an application,
or a software agent) that has a goal. [Joachim W. Walewski et al, 2011]

Virtual entity: a representation of a physical entity in the digital world. [Joachim W. Walewski et al,
2011]

Web Service: A Web service is a software system designed to support interoperable machine-to-
machine interaction over a network. It has an interface described in a machine-processable format
(specifically WSDL). Other systems interact with the Web service in a manner prescribed by its
description using SOAP-messages, typically conveyed using HTTP with an XML serialization in
conjunction with other Web-related standards. [W3C-gloss]
3. Scenario Description Methodology
Since IoT applications range from anything from manufacturing and logistics to healthcare or
entertainment, a way to structure and organise the various usages in application domains was
needed. This section describes the chosen approach for the scenarios description.
3.1 State of the Art in categorizing IoT Application Domains
In order to be able to get an overview of the potential large number of IoT scenarios a way to
categorize and structure this information had to be chosen. Two approaches to categorizing scenarios
were considered to be used as a structure for collecting scenarios.

Rather than inventing a new application domain categorizing scheme the categorizing scheme which
has been proposed by the IERC
2
and the categorizing scheme which was created by the IoT-i
3

project, (as part of their survey of IoT application scenarios) were considered.


2
http://www.internet-of-things-research.eu/
3
http://www.iot-i.eu/public/news/iot-i-project-launches-survey-on-iot-scenarios
   
 

D2.1 Dissemination Level – PU  Page 13 
 

The two categorizing schemes have a big overlap and the difference between the two approaches to
categorize scenarios is insignificant. As the main intention was to have a common structure for
collecting and discussing the scenarios and the above mentioned schemes are quite similar the
structure proposed by the IoT-i has been chosen.

Note that IoT-i uses the term IoT Sector, whereas we chose to use the term application domain in this
document.
3.2 Internet of Things Application Domains
The IoT-i project has defined the following application domains as part of its survey of IoT application
scenarios. The purpose of the survey was to identify which IoT application scenarios were seen as
having the highest business and societal impact. The scenarios were collected from FP6 and FP7
projects.

As a result of this analysis the IoT application domains were categorized as follows:
 Transportation
 Smart Home
 Smart City
 Smart Factory
 Supply Chain
 Emergency
 Healthcare
 Lifestyle
 Retail
 Agriculture
 Culture and Tourism
 User Interaction
 Environment
 Energy

3.3 Definition of Scenarios, Use Cases and Requirements

A scenario is a narrative, which most commonly describes foreseeable interactions of actors and the
technical system, which usually includes computer hardware and software. A scenario has a goal,
which is usually functional. In this document, scenario is a broad “narrative” about the use of
technology in an IoT enabled world.

Scenarios may consist of several use cases, which document alternative and overlapping ways of
reaching a goal. Each use case describes the interaction between an “actor” (i.e. a user) and the
system, to achieve a goal. Similarly, one use case can be used by several scenarios. Besides the use
cases there are also malfunction cases that will enable the identification of the required test cases
and test categories.

Finally we have the requirements which – in general - are at a more fine-grained level than the use
case. A requirement is a singular documented physical and functional need that a particular product
or service must be or perform. It is a statement that identifies a necessary attribute, capability,
characteristic, or quality of a system for it to have value and utility to a user. A requirement can be a
description of what a system must do, referred to as a functional requirement. This type of
requirement specifies something that the delivered system must be able to do. Another type of
requirement specifies something about the system itself, and how well it performs its functions. Such
requirements are often called non-functional requirements. A use case can consist of one or more
requirements and a requirement may apply to several use cases.

In the following sections scenarios, use cases and requirements are developed.
   
 

D2.1 Dissemination Level – PU  Page 14 
 

3.4 Methodology for Scenario Description
This section explains structure of the scenarios and what each section contains.

3.4.1 Scenario Description Structure

The following hierarchy has been used for the scenario descriptions chosen to be detailed into this
document.

<Scenario Name>
The name of the scenario being described
Scenario Description
The scenario plot will be presented in this section
Actors
An Actor is an entity which is outside of the IoT.est system. Actors can be users, external
connected systems, external databases etc. The interaction between an actor and the
system is described within use cases.
The section provides a list of the actors involved in the related scenario.
Objectives and Goals
This section is dedicated to the objectives and the goals of the actors in the scenario
Relation to other scenarios
This section indicates the relation of the currently described scenario to other scenarios.
Use cases
This section is dedicated to the definition of the use cases associated with the current
scenario
<Use case name>
This section is dedicated to the definition associated with the current scenario
Use case description
This section contains a description of the use case
Functional components
This section is dedicated to the description of the functional components
that are involved in the use case.
Non functional aspects
This section will include information about the non functional aspects of
the use case based on the ISO/IEC 9126 standard
4
.
Test related aspects
This section will describe the most relevant malfunction cases and some
relevant tests associated with this use case

The methodology is detailed in the following sections.
3.4.2 Use Case Descriptions
The description of Use Cases contains a textual description for the usage of the system by one or
several actors. The Use Cases describe a way in which the actors interact with the system in order to
reach a goal. An actor can either be a human or an external system, i.e. service running on external
device(s).

As a minimum, a Use Case consists of
 Title: that is, the goal the Use Case is trying to satisfy
 Main Success Scenario: The main success scenario can range from being a paragraph or two
that describes the interaction between the actor and the system or a more detailed structure
that consists of a numbered list of steps, where a step is defined as a simple statement of the
interaction between the system and the actor.
 Actor: An entity that is outside the system and interacts with the system.

4
See [ISO-ISO/IEC 9126-1:2001]
   
 

D2.1 Dissemination Level – PU  Page 15 
 

A more detailed Use Case will contain one or more of the following elements: Preconditions,
Stakeholders, Triggering Event and Success Criteria, i.e. what is considered a successful end to the
use case.
3.4.3 Description of Functional Components
The description of the functional components for services starts from identification of all the use cases
that are derived from the scenarios. Based on the use cases, functionalities that should be provided
as well as the service components that offer such functionalities need to be specified. The service
components can be delivered either in terms of atomic IoT services or composite services (also
referred to as IoT enabled services in the document).The functional descriptions provide important
input for the following IoT.est work packages as described below. The relevant functional aspects that
need to be provided are summarised as follows:
 functional requirements should be identified for each use case.
 based on functional requirements service components should be identified.
o WP3 will evaluate the service components to identify reusable atomic services and
composite services as building blocks for a service composition environment.
o WP3 will also identify input, output, and pre-conditions of the service components
thus providing interfaces and semantic descriptions of the service components.
 Relationships between the service components should be identified;
o WP4 will exploit the reusable service components for automated service composition
and derive control mechanisms from input, output and pre-condition aspects. If
service composition is needed, then all the participating atomic or composite services
as well as their input, output and pre-condition need to be identified, however, in the
case of automated service composition, these might not be required.
 Conditions under which service adaptation or compensation is needed should be identified
o WP5 will exploit service adaptation and compensation aspects for automated service
optimisation during run-time. Service adaptation and compensation are two important
techniques to ensure that composite services meet the requirement of service
consumers and providers as documented in the service level agreements. The
description should ideally include the conditions under which service adaptation and
compensation need to be performed.
3.4.4 Description of Non Functional Aspects
This section is dedicated to the description of the non-functional aspects of the use case which are
the most relevant. The ISO/IEC 9126 standard will be used to categorize the different aspects of
software quality. As can be seen in the below figure the standard differs between quality
characteristics, such as reliability, and sub-characteristics, such as fault tolerance or time behaviour.


Figure 3.1 Taxonomy of Quality (in IoT services)

   
 

D2.1 Dissemination Level – PU  Page 16 
 

The quality characteristics are defined as follows:
 Functionality is the ability to provide functions which meet the explicit and the implicit
functional requirements.
 Reliability is the ability to keep the agreed performances within the agreed conditions.
 Usability is the capability of the software to be understood and used with a good user
satisfaction in the agreed usage conditions.
 Efficiency is the relationship between the level of performance of the software and the
amount of resources used, under stated conditions.
 Maintainability is the ability to be modified with relatively little effort.
 Portability is the ability of the software to be moved from an operating system to another.

More information can be found in [ETICS2-SQB] and [ISO-ISO/IEC 9126-1:2001].
3.4.5 Description of Test related Aspects
The description of malfunction cases (here and after used as an umbrella term for defect, error, bug,
failure or fault for the sake of simplifications) should be derived from the use cases of the scenarios
and the identified functional components. The description of the malfunction cases includes the
category of the malfunction case and, if possible, identifies the physical or virtual functional
component where the malfunction could occur. In addition, the description indicates if this malfunction
can be identified at design-time (during implementation, test environment) or at run-time (during
deployment, service monitoring). The malfunction categories are as follows:
 Network
o Delay
o Packet Loss
o Bandwidth
 Resources
o Power supply failure
 Battery
 Voltage failure
o Hardware failure
 Storage corruption
 Defective sensor
 Calibration
o Resource limitations (due to load/ number of requests)
 Hardware
 Software
 Logical
o Protocol mismatch
o Functional description differs from implementation
o Unhandled exceptions
 Lack of service robustness
 Lack of proper recovery
 Security
o Access privilege mismatch
o Compromisation
 Quality of Information
o Accuracy
o Confidence
The malfunction case description offers important input for: identification of required test components
and test interfaces; building a test environment; guiding the identification of the required test
integration into the service composition.
   
 

D2.1 Dissemination Level – PU  Page 17 
 

4 IoT Application Domains
This chapter contains the set of application domains within which the project has identified IoT
scenarios. The complete list of scenarios and use cases can be found in the appendix.

Below a short description of the different application domains, as well as the names on the Application
Domain specific scenarios is given.
4.1 Transportation
The IoT will offer solutions for a toll system, screening passengers boarding commercial carriers and
intelligent transport systems that will improve the transportation of people and goods.

Sample scenarios:
- A life warning system for detecting road conditions.
- Real-time traffic overview in the city.
4.2 Smart Home
Smart or intelligent homes is an area that has received a lot of attention from the research community.
The networked smart home will be equipped with sensors, actuators, cameras, monitors and
interactive surfaces of various kinds, and will aid the residents in their daily life and enrich their home
life. Examples include smart energy metering or applications with the goal of making the elderly more
self-sufficient.

Sample scenario:
- Living in a smart home.
4.3 Smart City
The vision of the smart city is realized by adding a digital layer to the city that will bridge silos in
information and operations and making data accessible to citizens, decision makers and companies.
Citizens will be able to monitor the pollution concentration in the streets, they will be guided to the
nearest available parking spot and interactive screens around the city will provide information to
citizens and tourists. The municipalities on the other hand will be able to optimize their resources by
only emptying those garbage bins that are full or by detecting water leaks in the sewers.

Sample scenarios:
- Public transportation.
- Urban waste management.
- Safety & security surveillance.
4.4 Smart Factory
The Smart Factory uses context-awareness to assist people and machines in the execution of their
tasks. This is achieved by combining network enabled devices and context-aware applications. Using
positioning and automatic identification technologies will help to locate and track items and containers
and thereby improve logistics. Another area of the Smart Factory that will benefit both supplier and
customer is the introduction of automated production processes combined with an ICT-enabled
ordering process.

Sample scenario:
- Route guidance for service technicians.
- Close integration between supplier and customer.
4.5 Supply Chain
The logistic processes from supply chains in many application domains can profit from exchanging
RFID data. The retailers will benefit from using RFID-equipped items and “smart shelves” that allows
   
 

D2.1 Dissemination Level – PU  Page 18 
 

real time monitoring of stocks and automatically ordering new products before the retailer runs out of
stock.

Sample scenario:
- Retail supply chain.
4.6 Emergency
In cases of emergency, the IoT will enhance the coordination and collaboration between the
emergency personnel. An example of an IoT application is in the case of a car accident: The collision
detectors of the cars involved in the accident will automatically send an alarm to the emergency
central and the GPS location of the cars can be transferred to the nearest ambulance.

Sample scenario:
- Smart events
4.7 Healthcare
The IoT will benefit in areas such as monitoring of health and in cases of accidents. Sensors
combined with communication technology will enable easy monitoring of vital parameters and
implantable wireless devices will store critical healthcare data about the individual.

Sample scenarios:
- The HemoLab @ Home.
- Remote rehabilitation support.
- Implantable wireless devices storing health record.
- Well-being.
4.8 Lifestyle
Using IoT-enabled equipment will help in areas such as sport and fitness. Golfers, for instance, will
get advice about how to improve their game by letting their golf app analyze the data from the golf
club and the pressure sensors in the golf shoes.

Sample scenarios:
- Wearing a climate dress.
- Using solar power to charge your electronic devices.
4.9 Retail
Not only the shops benefit from using IoT-enabled technology, the shoppers do as well. Based on
their shopping list, they will be guided around the shop and by pointing his or her phones with RFID
reader to the product information such as origin, expiry date or carbon footprint will be presented to
the shopper.

Sample scenario:
- Intelligent shopping
4.10 Agriculture
IoT application will be found in many agriculture-related areas. ICT and sensors will increase the
farmer’s efficiency by allowing the farmer to monitor the condition of the crops, level of rainfall, and
humidity. Traceability of crops and animals will also be enhanced, which for instance will make it
easier to control outbreaks of contagious diseases.

Sample scenarios:
- Smart farming.
- From farm to fork.
   
 

D2.1 Dissemination Level – PU  Page 19 
 

4.11 Culture and Tourism
The IoT will also introduce changes to tourism. Based on previous trips your personal tourist app will
be able to give recommendations to the places of interest. Back at the hotel, the hotel rooms will know
your visitor profile and preferences with respect to lighting and temperature. Instead of rating the
whole hotel it will also be possible for the hotel guests to rate specific rooms since each room has its
own id.

Sample scenario:
- Augmented reality for tourists.
4.12 User Interaction
In an IoT enabled world users of IoT applications will make both explicit and implicit interaction with
an IoT-application. The implicit interaction means that the user concentrates on his/her primary
activity (for instance chopping vegetables) but the user isn’t aware of the interaction with the computer
system (the oven starts to heat). The interaction is therefore said to be implicit but on purpose.

Sample scenario:
- Smarter laundry service.
- The sensing chair.
4.13 Environment
The utilization of IoT technologies in green related application and environmental conservation is a
promising market. Pollution levels will be monitored in the city and in the case of an accident at a
factory where dangerous substances are released in the air sensors will pick up the polluted air and
warning messages are broadcasted to mobile phones in the affected areas.

Sample scenario:
- Monitoring the pollution level in the city.
4.14 Energy
The energy sector is yet another area where many IoT applications can be found. Topics include
smart grids, home control of energy consumption and smart metering.

Sample scenario:
- Energy efficient buildings.


   
 

D2.1 Dissemination Level – PU  Page 20 
 

5 Evaluation of Scenarios
The purpose of this document is to provide an overview of the various IoT scenarios and what types
of applications will exist in an IoT-enabled world. This knowledge is extremely important because it
allows extracting the needed requirements that the full life-cycle management for IoT enabled
business processes must accomplish.
5.1 Criteria Function
Each of the scenarios will be rated on a 1-3 scale, with 1 being low fulfilment of the criteria and 3
being high fulfilment of the criteria. Following are presented the main criteria:

1) Business oriented scenario: It is a requirement that the use case is business oriented,
and the use cases should preferably be part of a business process.
2) Usage of devices: IoT-enabled devices should be involved in the scenario.
3) Complex scenarios: It is a requirement that the use case consists of composed services
leading to more complex scenarios.
4) Implementable scenario: The scenarios should be realizable, meaning that it should be
possible to get access to the sensors, services etc.
5) Service Composition: The scenario should consist of service composition, i.e., create
context-aware business services (i.e., IoT enabled services) composing reusable high
level services and the low level IoT services.
6) Service adaptation: The scenarios shall provide service adaptation use cases where
services will automatically switch or adapt to new conditions when network and
environment variables change.

   
 

D2.1 Dissemination Level – PU  Page 21 
 

5.2 Evaluation of IoT Scenarios
The table below shows the outcomes of the evaluation of the IoT Scenarios (see Appendix for more
information about the actual scenarios that were used as input for this). The evaluation was based on
the criteria function described in the previous section.

Domains
Transportation
Smart Home
Smart Factory
Scenario
A Life Warning
System for
detecting Road
Conditions
Real-Time Traffic
Overview in the
City
Living in a Smart
Home
Route Guidance
for Service
Technicians
Close integration
between Supplier
and Customer
Criteria
Business oriented
scenario
1 2 1 3 3
Usage of devices 2 2 2 2 2
Complex
scenarios
3 2 2 1 2
Implementable
scenario
1 1 2 1 1
Service adaptation 2 2 2 2 2
Score:  9  9  9  9  10 
Domains
Smart City
Supply Chain
Management
Emergency
Scenario
Public
Transportation
Urban Waste
Management
Safety & Security
Surveillance
Retail Supply
Chain
Smart Events
Criteria
Business oriented
scenario
2 2 1 3 2
Usage of devices 1 2 2 2 3
Complex
scenarios
2 2 3 1 3
Implementable
scenario
1 1 1 2 3
Service adaptation 2 2 2 2 2
Score:
8  9  9  10  12 

         









         

         
   
 

D2.1 Dissemination Level – PU  Page 22 
 

Domains
Healthcare
Retail
Scenario
The HemoLab @
Home
Remote
Rehabilitation
Support
Implantable
wireless devices
storing health
record
Well-being
Intelligent
shopping
Criteria
Business oriented
scenario
2 2 2 2 3
Usage of devices 1 1 2 2 2
Complex
scenarios
2 2 3 3 1
Implementable
scenario
2 2 1 3 2
Service adaptation 2 2 1 3 2
Score:
9  9  9  13  10 
Domains
User Interaction
Culture and
Tourism
Agriculture
Scenario
Smarter Laundry
Service
The Sensing Chair
Augmented
Reality for Tourists
Smart Farming
From farm to fork
Criteria
Business oriented
scenario
1 1 2 3 3
Usage of devices 2 2 2 2 2
Complex
scenarios
2 2 2 1 2
Implementable
scenario
2 2 1 1 1
Service adaptation 2 2 2 2 2
Score:
9  9  9  9  10 

         
Domains
Environment
Energy
Scenario
Monitoring the
Pollution level in
the City
Energy Efficient
Buildings

Criteria
Business oriented
scenario
1 2

Usage of devices 2 2
Complex
scenarios
2 3
Implementable
scenario
2 3
Service adaptation 2 3
Score:
9  13 
   
 

D2.1 Dissemination Level – PU  Page 23 
 

5.3 Prioritizing the Scenarios

Since all scenarios (listed above) have been chosen with the wider IoT and in particular with testing of
the services in mind, all of them did end up with a relatively high score. The scenarios that have a
combined scores below 10 are categorized as “low score”. Having reached a score of 10 is “fine” and
scores over 10 are “good”.

The middle segment (“fine”) contains following scenarios:
- Smart Home – Living in a smart home
- Agriculture – From farm to fork
- Retail – Intelligent Shopping
- Supply Chain Management – Retail Supply Chain
- Smart Factory – Close integration between Supplier and Customer

Common for several of these scenarios in the middle segment is that they score low on the “being
implementable” criteria (e.g. the agriculture and the Smart Factory scenario), which makes it
unrealistic to prototype the use cases in the scenarios. These scenarios will instead be useful for
Activity 3.2 that will derive re-usable service components from business scenarios.

Based on the evaluation presented in section 5.2 the following scenarios had the highest scores and
will therefore be considered to be the most relevant for further analysis:
- Emergency – Smart Events Scenario
- Energy – Energy Efficient Buildings Scenario
- Healthcare – Well Being Scenario

The scenarios have first and foremost complex functionalities and have non trivial requirements,
which are essential prerequisites for the testing effort to be worthwhile.

The prioritized scenarios will be the subject of the following section.


   
 

D2.1 Dissemination Level – PU  Page 24 
 

6 Prioritized Scenarios

The scenarios that were evaluated highest using the above mentioned criteria’s will be presented in
the below. The full list of scenarios and use cases can be found in the appendix.

6.1 Emergency - Smart Events
The advantages of using technologies in the setting of a large event, such as a festival, have been
investigated in the @aGlance project
5
. The @aGlance project develops and joins technologies to
support overview, collaboration and coordination at e.g. larger events such as the Skanderborg
Festival (around 50.000 visitors) as part of the contingency plan.

All emergency response personnel (police, guards, stretcher teams, doctors etc.) carry a smartphone.
This GPS enabled devices enable everyone to have an overview of the personnel and thus improve
the coordination of the effort and let the emergency personnel reply back to the coordinators using
various annotations.

The technology is designed:
 to allow professionals to assemble large numbers of pervasive computing devices and
services
 to produce an overview of their resources
 to get data from handheld devices in order to produce an overview of the situation on the
ground
 and thereby support collaboration between (potentially distributed) team members
6.1.1 Scenario Description
This scenario refers to the coordination of emergency response personnel at large events.Bob, Jim
and Alice works at the Skanderborg Festival. Alice is working at the local headquarter while Bob and
Jim are part of the security team. Bob carries along a Smartphone which is connected with the central
station via mobile networks. The Smartphone is authorised and bounded with the unique entity
identification of Bob and shares his location on a regular basis. A number of scenarios will be
described:
Guard handles brawl: Bob has marked himself available with the Smartphone. While Bob and Jim
patrol the festival one of the surveillance cameras analyzes a situation as being a violent situation and
an alert is sent to the headquarter. Alice receives the alert and confirms the brawl on one of the
surveillance cameras. Alice identified the nearest guard on the “overview screen”, which is Bob, and
sends him a notification to his Smartphone that he should go to the identified destination to clarify the
situation. Bob acknowledges the request and runs to the destination. When Bob and Jim arrive at the
operation destination they get the situation under control, and report back to the station using the
smartphone.
Identifying crowd behavior: One of the big artists are playing at the main scene. Jack and Joe – two
friends from college – enjoy the music in the front rows, but they feel that they are about to get
squashed by the other festival participants. The event is being analyzed by a combination of video
and mobile phone data, and the situation is categorized as dangerous, so a number of guards are
being told to intervene and make sure people do not get injured.

5
http://www.aglance.dk/
   
 

D2.1 Dissemination Level – PU  Page 25 
 

Alerting the doctor: Thomas works as a guard. As he patrols the festival he encounters a young girl
who feels sick. Thomas opens his @aGlance app and adds a “Doctor is needed tag”. A few hundred
meters away sits Julie, one of the doctors at the festival. As Thomas sends the message Julie
receives it, as she is the nearest available doctor. She then runs to help Thomas with the young girl.
6.1.2 Actors

Actor
Type
Roles
Police Person The Police patrol the festival to make sure that
the festival participants are secure, and that no
one does anything illegal.
Guard Person/Avatar The Guards at the festival has to make sure that
the festival participants are secure.
Doctor Person The Doctors at the festival are in charge of one of
the camp hospitals.
Stretcher Team Person The stretcher team helps injured and sick festival
participants.
Festival Participant Person A person that has bought an access pass to the
festival, and participates in the festival.
Security Coordinator Person The person that is in charge of the security at the
festival. The security coordinator coordinates the
emergency effort from the “headquarter” where
the @aGlance system provides him/her with
overview and emergency related information from
the festival field.
@aGlance App SW app The smartphone application that guards and the
other emergency personnel use to coordinate the
emergency effort.
@aGlance system SW The system that supports @aGlance applications
and the connected IoT services.
Smartphone Device Mobile Equipment with a simple user interface. It
also links the sensor information with remote
systems
IoT devices Devices The @aGlance system gets information from
sensors and actuators. Examples include video
cameras, smoke sensors and sensors that
measure the fill level in garbage bins.

6.1.3 Objectives and Goals
To support overview and collaboration between emergency response personnel with different
responsibilities during larger events.
6.1.4 Relation to other Scenarios
This scenario is related to the healthcare scenarios.
6.1.5 Use Cases
The following section contains a number of use cases related to the scenario.
   
 

D2.1 Dissemination Level – PU  Page 26 
 

6.1.5.1 Share context
6
related Data with Co-workers
Usecase Description
In this usecase the Users (either Police, Guard, Stretcher Team or a Doctor) should be able to share
context related data with the Central as well as with the fellow emergency personnel in order for
everyone to have an overview of the situation. For this, the User has access to the @aGlance App,
and the smartphone is connected to the mobile network.
To share context data, the User must chose a Context Tag from the predefined list of Context Tags in
the @aGlance App. The data will then be shared with the Actors that need this information, and they
will then be able to see the tag in the @aGlance App.
Functional Components
 Precondition derived components
o Authentication: In order to log into the @aGlance App a username and password is
required.
o Network access: The @aGlance App should be connected to the network.
 Get Location (GPS): This service captures the position of the User.
 Load list of Context Tags: The list of available tags will be loaded.
 Insert Context Tag: The Context tag is mapped to the location of the User, and is then
transferred to the central server.
 Role Based Access Control: A User will have one or more Roles. Having a Role means that
certain functionality is available in the @aGlance System and that the User retrieves a certain
set of the available information in the system.
Non Functional Aspects

Quality
characteristics
Sub-aspects
Description
Technical requirements
Functionality
Interoperability
Many types of mobile
phones should be able to
use the system
N/A
Reliability
Fault tolerance
The system should be able
to function even in the case
of a software fault.
N/A
Efficiency
Time behaviour
Data should be transferred
quickly from the Users to
the central
Response time: 3 seconds
Resource usage
There shouldn’t be used too
much bandwidth because it
is limited and there will be
many users.
N/A





6
The User can add a ”context tag” which can be seen by the other Users. The purpose of the tag is to
share information with the other Users. Examples of tags include: Stretcher team is needed, Place Is
crowded, etc.
   
 

D2.1 Dissemination Level – PU  Page 27 
 

Test related Aspects
Malfunction Cases:
1. Network: Due to changing network conditions with part unavailability of the mobile
devices the @aGlance App as well as the central server could have problems to
recover.
2. Resource Limitation: due to the amount of published context and the central storage
the context sharing might become inefficient. Wrong or missing caching mechanism
could result in storage, CPU, and network overflow
3. Unhandled exception: GPS sensor are switched off by the user or other application
(e.g. battery saving) resulting in an exception at the @aGlance app
4. Security: Access privilege mismatch: users have access to information not intended for
them
5. Unhandled Exception: Central stations disappear due to hardware, software or power
supply failure. @aGlance app does not notice that and did not start the re-initialization
process or start the re-initialization process at the same time for every user which
results in a CPU or network overload.
6. Logical mismatch: Due to different used smart phones with different hardware and
software capabilities the app might react differently which might cause among others
protocol mismatch (different app versions) or sensor usage problems (different
hardware) or lack of service robustness (due to different APIs)
7. Quality of Information due to deactivated GPS sensors the location information is based
on the CellID but the accuracy value is not considered

Performance test
It should be tested that the context tag gets shared with the coworkers within the defined
timelimit. The response time of the system should be tested in high and low stress
situations.

Role-based access to data
It should be tested that the correct actors get access to the context tag.

Context tags get shared with co-workers
It should be tested that when a context tag gets “shared” it gets visible to the co-workers.
6.1.5.2 Crowd control at Large Events
Use Case Description

The goal of the crowd control use case is to predict how large crowds will react in certain situations by
using, for instance, artificial intelligence and data from the surroundings,. In the case of an event the
central headquarter should be informed.
When the @aGlance System identifies a situation an alert is triggered at the central headquarter.
Cameras will automatically turn towards the destination that triggered the event, and nearby
personnel will get a notification that they must be ready. After the headquarter personnel have
assessed the situation they can either: 1) remove the alarm status, 2) create an emergency plan
Functional Components
 Get input (Pictures) from video cameras: Video data is transferred to the system for analysis.
- Service Adaptation comment: Due to the high accuracy requirements for this use case
the combination of data sources and algorithms for predicting the crowd behavior will vary
based on the conditions, e.g. time of day, meteorological conditions and noise level.
 Get input from sensors on Mobile phones: Various sensor data, such as accelerometer, will
be transferred to the system for analysis.
   
 

D2.1 Dissemination Level – PU  Page 28 
 

 Get voice data: Voice data from the surroundings will be transferred to the system for
analysis.
 Identify Event Based on Crowd Behavior: The input data (video, voice, sensordata) will be
analyzed using techniques such as artificial intelligence, pattern recognition and data mining.
The output will be a specific crowd behavior, such as “Crowd moves to the east”, “Area in the
crowd is too crowded” or “Crowd Panic”.
 Move Cameras: When an event happens, the nearby cameras should move to the destination
of the event.
 Alarm: When an event happens the personnel at the headquarter must be notified by sound
and visual effect on the @aGlance overview screen.
Non Functional Aspects

Quality
characteristics
Sub-aspects
Description
Technical requirements
Functionality
Accuracy
Validity is very important as
an event might trigger
several events
N/A
Security
It must not be possible to
hack the system
N/A
Reliability


Reliability

The services must be
reliable and have a high
level of availability
N/A
Efficiency

Time behaviour
Near real time performance
will be needed.
N/A

Test related Aspects
Malfunction Cases:
1. Network: video transmissions might exceed the bandwidth of network this can happen
especially if the network is also used from other services and the already consumed
bandwidth is unknown
2. Quality of Information: Sensor data from mobile devices are outdated, or the
transmitted data is not representative for the current situation (phone is in a bag (quit)
and the bag is thrown around (too much movement))
3. Network: too many open but unfinished network connections blocking new
transmissions and the network interface of the central stations gets overloaded
4. Hardware failure: calibration mismatch between different sensors results in switching
event detections at the same location
5. Hardware/Software: the calibration of the camera movement is wrong and there is an
increasing gap between the expected and the correct positioning. Use case: Automatic
collaboration in case of emergency (heatstroke or other illness)
6. Resource limitations: Stress test of the system must be performed to evaluate how the
crowd behaviour algorithms perform when huge amounts of video, sensor and voice
data are received.
7. Robustness: System must be tested in various meteorological situations (e.g. rain and
fog), during different times of the day (morning and evening).

Accuracy test
It should be tested that the system delivers the correct answers, even when the conditions
are not optimal, e.g. in the evening.

   
 

D2.1 Dissemination Level – PU  Page 29 
 

Deployment test
It should be tested that that system delivers the correct answers under real life conditions.
6.1.5.3 Activate Emergency Plan
Use Case Description
If an event is identified by the headquarter that qualifies for an evacuation of an area, the headquarter
will develop and coordinate an emergency plan. A triggering event could be a smoke alarm that gets
activated and that the event then gets confirmed by another sensor in the same area.
Personnel at ground level will execute the plan, and sensor information will be used to maintain a
coordinated effort. When it has been chosen that an area should be activated the relevant personnel
gets informed about what they should do via phone/radio or tags/tasks on the emergency personnel’s
@aGlance App.
Functional Components
‐ Send Predefined Task to Role (Guard, Police, Stretch Team or Doctor): In the case of an
emergency, different roles have different tasks. The headquarter can order guards to the
area, inform the medical personnel that injured people will be arriving, or something similar.
‐ Get information from Device: Data from devices such as gates (i.e. is the gate open or closed)
or cameras (i.e. are the transportation routes too crowded) should be transferred to
headquarter.

Non Functional Aspects

Quality
characteristics
Sub-aspects
Description
Technical requirements
Functionality

Interoperability
The system must be
interoperable with several
devices and external
sources.

N/A
Security The system must be secure.N/A
Reliability

Maturity

Faults and breakdowns can
not be allowed.

N/A
Efficiency
Time behaviour Near real-time performance
will be needed
N/A

Test related Aspects
Malfunction Cases:
1. Security: Access privilege mismatch results in access to unintended information
2. Resource limitations: due to the number of tasks at the same time during an emergency
the system might be overloaded which could result in time delay, unhandled exceptions
or lack of proper service recovery
3. Logical description differs from description: GUI or internal functional description differs
from the implemented system which results in limited or non-usability of the system
4. Logical malfunction: pre-conditions have not been made. e.g. the predefined task have
never been prepared or reviewed or updated
5. Resources: due to a part power supply failure or hardware failure some of the sensor
information is missing the central service hangs due to long timeout exceptions or re-
tries

Security test
Test that atomic services are only accessible by authorized actors.

   
 

D2.1 Dissemination Level – PU  Page 30 
 

Interoperability test
Test that the system can connect with the devices and external systems.
6.1.5.4 Automatic collaboration in case of Emergency (Heatstroke or other
Illness)
Use Case Description
When an emergency happens the different types of emergency personnel should be able to
coordinate the help. In such a situation one of the emergency personnel has tagged the event or the
event has been identified using a camera or voice sensor.
The User arrives at the scene, and tags the situation as being at a certain severity using an
“emergency tag”. Other emergency personnel then get notified about the situation and run to the
destination of the emergency.
Functional Components
‐ Precondition derived components:
o Identify emergency based on video: Video will be analysed and an event will be sent
to the headquarter in the case of an emergency.
o Identify emergency based on voice: Voice data will be analysed and an event will be
sent to the headquarter in the case of an emergency.
‐ Get list of emergency types: The User can tag an event as being one or several types of
emergency.
‐ Send emergency Message: When the central receives the “emergency tag” (an emergency is
occurring), the location of the tag is transferred to the cameras in the area which automatically
turns towards the area of the emergency.
‐ Request backup: Based on the scale of the emergency a number of stretcher teams and
doctors will be requested to go to the area of the emergency.
‐ Send Message to Police: A notification about the emergency can be sent to the police.
o Service Adaptation Comment: In the case of communication with the police more
secure services should be used.
‐ Send Message to the Hospital: A notification about the emergency can be sent to the hospital.
o Service Adaptation Comment: In the case of communication with the hospital more
secure services should be used.
Non Functional Aspects

Quality
characteristics
Sub-aspects
Description
Technical requirements
Functionality

Security
Process should be secure
due to integration with
hospital/police IT-systems

N/A
 
Test related Aspects
Malfunction Cases:
1. Logical: Protocol mismatch due to changes at the police or hospital service. The
system have not noticed that a change happened and therefore have not been
retested.
2. Security violations (security being compromised) : hospital or police service has none
or not enough security protection against security violations.

Functionality test
It should be tested that request for backup gets received.

   
 

D2.1 Dissemination Level – PU  Page 31 
 

6.1.5.5 Making Data Available for the Festival Guests (about empty Garbage
bins)
Use Case Description
The usecase goal is that a subset of the data that is available in the system should be made available
to the festival guests. One area that is of interest for the festival guests are the location of empty
garbage bins. Sensors monitor the fill-level of the garbage bins. This data is marked as shared data
and will therefore be available for festival Guests.

Interaction: When the festival guest logs in an starts the @aGlance App the festival guest will be able
to see the empty garbage bins
 
Functional Components
‐ Access Empty Bin-data: When the festival guest logs starts the @aGlance App the festival
guest will be able to see the empty garbage bins.
o Service Adaptation Comment: If the @aGlance system or its infrastructure is
encumbered, the services related to making data available for the festival guests will
be down prioritized.
‐ Measure fill-level of garbage bin: Using sensor data the garbage bin transfers its fill level to
the central server.
Non Functional Aspects

Quality
characteristics
Sub-aspects
Description
Technical requirements
Functionality

Interoperability
Many types of mobile
phones should be able to
use the system
The software should run on the
most popular mobile phones
(80% of the available mobile
phones)
Test related Aspects
Malfunction Cases:
1. Resource Limitations: too many request at the same time could result in unhandled
exceptions, resources overflow (network, CPU, etc.) or lack of proper recovery
2. Security: Access privilege mismatch results in no intended data access
3. Resource Failures: based on hardware of software failures some of the sensors values
are not updated and old outdated values are shown to the users.