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

IoT.est develops a test-driven service creation environment (SCE) for Internet of Things enabledbusiness 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 IoTservices that exploit data across domain boundaries and facilitate run-time monitoring which enablesautonomous 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 towardsfuture IoT service creation, deployment and testing products.

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

Criteria have been defined according to the IoT.est project objectives to prioritize representative andchallenging scenarios for IoT.est. Based on scenarios in 14 application domains, three were chosenbased on criteria’s such as complexity of the involved functionality in the scenario, the non-functionalrequirements 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 derivingrequirements for the IoT.est framework.

As IoT.est aims at supporting the complete service life-cycle from service creation to service provisiona special effort was undertaken to state also service life-cycle specific requirements. These focus onsemantic 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).

1. Introduction1.1 Motivation and ScopeTo date, implementations of Internet of Things (IoT) architectures are confined to particularapplication 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 ofspecific tailored services for Internet of Things applications, in particular for innovative businessprocesses. 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, contextinterpretation, decision support, and action control hinders uptake and penetration of specific tailoredservices for “Internet of Things” applications.

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

IoT.est will establish and ease the creation and provision of IoT enabled business services by bringingtogether the following three disciplines: Internet of Things, Service Engineering and Testing. Theobjective of the project is to develop a service creation and provision environment for reliable “Internetof 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 serviceexecution. 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 relatedtests from semantic service descriptions based on standard service interfaces and re-usableservice and test components.• Composition Phase: A test-aware IoT Service Creation Environment supports incrementalservice evolution by regression tests. When adding new functionalities, the servicecomponents and system tests are included to ensure backward compatibility with previousservice releases.IoT service provision (run-time):• Deployment Phase: The framework forces service validation tests in a sandbox environmentbefore deployment in the service providers’ infrastructure, including automated deploymentprocedures based on semantics for service resource requirements and network capabilities.• Execution Phase: Run-time monitoring mechanisms enable service adaptation to environmentchanges and adjustment of network parameters. This adaptation can result in reselection ofinvolved components at run-time.

D2.1 Dissemination Level – PU Page 9

Figure 1.1 - Life-Cycle Management for IoT enabled Business Processes1.2 Purpose of the DocumentThis 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 forreliable service management in the different service life cycle phases. The requirements will drive theIoT.est architecture development with focus on re-usable cross service boundary tools for easy andreliable IoT service creation and provision.1.3 Overview of the DocumentThe next chapter contains an overview of the terminology that will be used. Chapter 3 describes thechosen approach to structure, define and describe the scenarios. Following that, a short introductionto the various IoT application domains will be given. Chapter 5 describes how the project hasprioritized the various IoT scenarios. In chapter 6 the prioritized scenarios are documented. Chapter 7contains the IoT.est generic use cases. Section 8 derives the requirements from the scenarios anduse 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 futuredocuments, 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-A1project, which is thelargest 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 tothis project, i.e., service adaptation and compensation.

Actor: an entity which is outside of the IoT.est system. Actors can be users, external connectedsystems, external databases etc. The interaction between an actor and the system is described withinuse 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 singleresponse to the requester. With atomic services there is no ongoing interaction between the user andthe service. [W3C-OWLS]

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

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

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

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

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

IoT Service: IoT service is a subclass of service which represents the capability of its correspondingIoT resource. An IoT service integrates IoT into the world of high level business services. Althoughmost 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 andchemical 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 bemade available, too, to create a Web of Data. This collection of interrelated datasets on the Web canalso be referred to as Linked Data. [W3C-gloss]

1IoT-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 theuser for the completion of his goal. Physical entities are represented in the digital world via a virtualentity. [Joachim W. Walewski et al, 2011]

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

Service: A service is an abstract resource that represents a capability of performing tasks that form acoherent 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 servicebehaviour according to the changes of service operating context to meet service provider orconsumer’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 withanother 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 theuser situation and preferences. [Attou et al, 2007] This definition is mainly for personalisation to usersituation and preference.

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

Adaptation, the process of modifying a service system in order to satisfy new requirements and to fitnew situations, can be performed either because monitoring has revealed a problem or because theapplication 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 ofthe service. [SOA4ALL-gloss]

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

Service Compensation: Service compensation refers to techniques for automated replacement ofexisting service(s) or service component(s) in order to meet service provider or consumer’srequirements 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, butalso about providing services. This can be done in such a way that already existing services areorchestrated 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 bedescribed 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 andsemantics of a service. [W3C-gloss]

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

Service end point: An association between a binding and a network address, specified by a URI, thatmay be used to communicate with an instance of a service. An end point indicates a specific locationfor 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 thetypes of messages and the message exchange patterns that are involved in interacting with theservice, together with any conditions implied by those messages. [W3C-gloss]

Service Orchestration: A Service Orchestration is the description of how a specific service can berealised by interacting with other services. The orchestration is under control of a single endpoint. AnOrchestration 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]

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 itsdescription using SOAP-messages, typically conveyed using HTTP with an XML serialization inconjunction with other Web-related standards. [W3C-gloss]3. Scenario Description MethodologySince IoT applications range from anything from manufacturing and logistics to healthcare orentertainment, a way to structure and organise the various usages in application domains wasneeded. This section describes the chosen approach for the scenarios description.3.1 State of the Art in categorizing IoT Application DomainsIn order to be able to get an overview of the potential large number of IoT scenarios a way tocategorize and structure this information had to be chosen. Two approaches to categorizing scenarioswere considered to be used as a structure for collecting scenarios.

Rather than inventing a new application domain categorizing scheme the categorizing scheme whichhas been proposed by the IERC2and the categorizing scheme which was created by the IoT-i3

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

The two categorizing schemes have a big overlap and the difference between the two approaches tocategorize scenarios is insignificant. As the main intention was to have a common structure forcollecting and discussing the scenarios and the above mentioned schemes are quite similar thestructure 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 thisdocument.3.2 Internet of Things Application DomainsThe IoT-i project has defined the following application domains as part of its survey of IoT applicationscenarios. The purpose of the survey was to identify which IoT application scenarios were seen ashaving the highest business and societal impact. The scenarios were collected from FP6 and FP7projects.

A scenario is a narrative, which most commonly describes foreseeable interactions of actors and thetechnical 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 oftechnology in an IoT enabled world.

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

Finally we have the requirements which – in general - are at a more fine-grained level than the usecase. A requirement is a singular documented physical and functional need that a particular productor 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 adescription of what a system must do, referred to as a functional requirement. This type ofrequirement specifies something that the delivered system must be able to do. Another type ofrequirement specifies something about the system itself, and how well it performs its functions. Suchrequirements are often called non-functional requirements. A use case can consist of one or morerequirements 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 DescriptionThis 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 thisdocument.

<Scenario Name>The name of the scenario being describedScenario DescriptionThe scenario plot will be presented in this sectionActorsAn Actor is an entity which is outside of the IoT.est system. Actors can be users, externalconnected systems, external databases etc. The interaction between an actor and thesystem is described within use cases.The section provides a list of the actors involved in the related scenario.Objectives and GoalsThis section is dedicated to the objectives and the goals of the actors in the scenarioRelation to other scenariosThis section indicates the relation of the currently described scenario to other scenarios.Use casesThis section is dedicated to the definition of the use cases associated with the currentscenario<Use case name>This section is dedicated to the definition associated with the current scenarioUse case descriptionThis section contains a description of the use caseFunctional componentsThis section is dedicated to the description of the functional componentsthat are involved in the use case.Non functional aspectsThis section will include information about the non functional aspects ofthe use case based on the ISO/IEC 9126 standard4.Test related aspectsThis section will describe the most relevant malfunction cases and somerelevant tests associated with this use case

The methodology is detailed in the following sections.3.4.2 Use Case DescriptionsThe description of Use Cases contains a textual description for the usage of the system by one orseveral actors. The Use Cases describe a way in which the actors interact with the system in order toreach a goal. An actor can either be a human or an external system, i.e. service running on externaldevice(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 twothat describes the interaction between the actor and the system or a more detailed structurethat consists of a numbered list of steps, where a step is defined as a simple statement of theinteraction between the system and the actor. Actor: An entity that is outside the system and interacts with the system.

4See [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 theuse case.3.4.3 Description of Functional ComponentsThe description of the functional components for services starts from identification of all the use casesthat are derived from the scenarios. Based on the use cases, functionalities that should be providedas well as the service components that offer such functionalities need to be specified. The servicecomponents can be delivered either in terms of atomic IoT services or composite services (alsoreferred to as IoT enabled services in the document).The functional descriptions provide importantinput for the following IoT.est work packages as described below. The relevant functional aspects thatneed 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 andcomposite services as building blocks for a service composition environment.o WP3 will also identify input, output, and pre-conditions of the service componentsthus 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 compositionand derive control mechanisms from input, output and pre-condition aspects. Ifservice composition is needed, then all the participating atomic or composite servicesas well as their input, output and pre-condition need to be identified, however, in thecase of automated service composition, these might not be required. Conditions under which service adaptation or compensation is needed should be identifiedo WP5 will exploit service adaptation and compensation aspects for automated serviceoptimisation during run-time. Service adaptation and compensation are two importanttechniques to ensure that composite services meet the requirement of serviceconsumers and providers as documented in the service level agreements. Thedescription should ideally include the conditions under which service adaptation andcompensation need to be performed.3.4.4 Description of Non Functional AspectsThis section is dedicated to the description of the non-functional aspects of the use case which arethe most relevant. The ISO/IEC 9126 standard will be used to categorize the different aspects ofsoftware quality. As can be seen in the below figure the standard differs between qualitycharacteristics, 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 implicitfunctional 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 usersatisfaction in the agreed usage conditions. Efficiency is the relationship between the level of performance of the software and theamount 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 AspectsThe 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 scenariosand the identified functional components. The description of the malfunction cases includes thecategory of the malfunction case and, if possible, identifies the physical or virtual functionalcomponent where the malfunction could occur. In addition, the description indicates if this malfunctioncan be identified at design-time (during implementation, test environment) or at run-time (duringdeployment, service monitoring). The malfunction categories are as follows: Networko Delayo Packet Losso Bandwidth Resourceso Power supply failure Battery Voltage failureo Hardware failure Storage corruption Defective sensor Calibrationo Resource limitations (due to load/ number of requests) Hardware Software Logicalo Protocol mismatcho Functional description differs from implementationo Unhandled exceptions Lack of service robustness Lack of proper recovery Securityo Access privilege mismatcho Compromisation Quality of Informationo Accuracyo ConfidenceThe malfunction case description offers important input for: identification of required test componentsand test interfaces; building a test environment; guiding the identification of the required testintegration into the service composition.

D2.1 Dissemination Level – PU Page 17

4 IoT Application DomainsThis chapter contains the set of application domains within which the project has identified IoTscenarios. 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 ApplicationDomain specific scenarios is given.4.1 TransportationThe IoT will offer solutions for a toll system, screening passengers boarding commercial carriers andintelligent 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 HomeSmart 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 andinteractive surfaces of various kinds, and will aid the residents in their daily life and enrich their homelife. Examples include smart energy metering or applications with the goal of making the elderly moreself-sufficient.

Sample scenario:- Living in a smart home.4.3 Smart CityThe vision of the smart city is realized by adding a digital layer to the city that will bridge silos ininformation 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 thenearest available parking spot and interactive screens around the city will provide information tocitizens and tourists. The municipalities on the other hand will be able to optimize their resources byonly 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 FactoryThe Smart Factory uses context-awareness to assist people and machines in the execution of theirtasks. This is achieved by combining network enabled devices and context-aware applications. Usingpositioning and automatic identification technologies will help to locate and track items and containersand thereby improve logistics. Another area of the Smart Factory that will benefit both supplier andcustomer is the introduction of automated production processes combined with an ICT-enabledordering process.

Sample scenario:- Route guidance for service technicians.- Close integration between supplier and customer.4.5 Supply ChainThe logistic processes from supply chains in many application domains can profit from exchangingRFID 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 ofstock.

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

Sample scenario:- Smart events4.7 HealthcareThe IoT will benefit in areas such as monitoring of health and in cases of accidents. Sensorscombined with communication technology will enable easy monitoring of vital parameters andimplantable 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 LifestyleUsing IoT-enabled equipment will help in areas such as sport and fitness. Golfers, for instance, willget advice about how to improve their game by letting their golf app analyze the data from the golfclub and the pressure sensors in the golf shoes.

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

Sample scenario:- Intelligent shopping4.10 AgricultureIoT application will be found in many agriculture-related areas. ICT and sensors will increase thefarmer’s efficiency by allowing the farmer to monitor the condition of the crops, level of rainfall, andhumidity. Traceability of crops and animals will also be enhanced, which for instance will make iteasier 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 TourismThe IoT will also introduce changes to tourism. Based on previous trips your personal tourist app willbe able to give recommendations to the places of interest. Back at the hotel, the hotel rooms will knowyour visitor profile and preferences with respect to lighting and temperature. Instead of rating thewhole hotel it will also be possible for the hotel guests to rate specific rooms since each room has itsown id.

Sample scenario:- Augmented reality for tourists.4.12 User InteractionIn an IoT enabled world users of IoT applications will make both explicit and implicit interaction withan IoT-application. The implicit interaction means that the user concentrates on his/her primaryactivity (for instance chopping vegetables) but the user isn’t aware of the interaction with the computersystem (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 EnvironmentThe utilization of IoT technologies in green related application and environmental conservation is apromising market. Pollution levels will be monitored in the city and in the case of an accident at afactory where dangerous substances are released in the air sensors will pick up the polluted air andwarning messages are broadcasted to mobile phones in the affected areas.

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

Sample scenario:- Energy efficient buildings.

D2.1 Dissemination Level – PU Page 20

5 Evaluation of ScenariosThe purpose of this document is to provide an overview of the various IoT scenarios and what typesof applications will exist in an IoT-enabled world. This knowledge is extremely important because itallows extracting the needed requirements that the full life-cycle management for IoT enabledbusiness processes must accomplish.5.1 Criteria FunctionEach of the scenarios will be rated on a 1-3 scale, with 1 being low fulfilment of the criteria and 3being 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 servicesleading to more complex scenarios.4) Implementable scenario: The scenarios should be realizable, meaning that it should bepossible to get access to the sensors, services etc.5) Service Composition: The scenario should consist of service composition, i.e., createcontext-aware business services (i.e., IoT enabled services) composing reusable highlevel services and the low level IoT services.6) Service adaptation: The scenarios shall provide service adaptation use cases whereservices will automatically switch or adapt to new conditions when network andenvironment variables change.

D2.1 Dissemination Level – PU Page 21

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

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

Common for several of these scenarios in the middle segment is that they score low on the “beingimplementable” criteria (e.g. the agriculture and the Smart Factory scenario), which makes itunrealistic to prototype the use cases in the scenarios. These scenarios will instead be useful forActivity 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 andwill 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 inthe below. The full list of scenarios and use cases can be found in the appendix.

6.1 Emergency - Smart EventsThe advantages of using technologies in the setting of a large event, such as a festival, have beeninvestigated in the @aGlance project5. The @aGlance project develops and joins technologies tosupport overview, collaboration and coordination at e.g. larger events such as the SkanderborgFestival (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 improvethe coordination of the effort and let the emergency personnel reply back to the coordinators usingvarious annotations.

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

5http://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 girlwho feels sick. Thomas opens his @aGlance app and adds a “Doctor is needed tag”. A few hundredmeters away sits Julie, one of the doctors at the festival. As Thomas sends the message Juliereceives it, as she is the nearest available doctor. She then runs to help Thomas with the young girl.6.1.2 Actors

ActorTypeRolesPolice Person The Police patrol the festival to make sure thatthe festival participants are secure, and that noone does anything illegal.Guard Person/Avatar The Guards at the festival has to make sure thatthe festival participants are secure.Doctor Person The Doctors at the festival are in charge of one ofthe camp hospitals.Stretcher Team Person The stretcher team helps injured and sick festivalparticipants.Festival Participant Person A person that has bought an access pass to thefestival, and participates in the festival.Security Coordinator Person The person that is in charge of the security at thefestival. The security coordinator coordinates theemergency effort from the “headquarter” wherethe @aGlance system provides him/her withoverview and emergency related information fromthe festival field.@aGlance App SW app The smartphone application that guards and theother emergency personnel use to coordinate theemergency effort.@aGlance system SW The system that supports @aGlance applicationsand the connected IoT services.Smartphone Device Mobile Equipment with a simple user interface. Italso links the sensor information with remotesystemsIoT devices Devices The @aGlance system gets information fromsensors and actuators. Examples include videocameras, smoke sensors and sensors thatmeasure the fill level in garbage bins.

6.1.3 Objectives and GoalsTo support overview and collaboration between emergency response personnel with differentresponsibilities during larger events.6.1.4 Relation to other ScenariosThis scenario is related to the healthcare scenarios.6.1.5 Use CasesThe following section contains a number of use cases related to the scenario.

D2.1 Dissemination Level – PU Page 26

6.1.5.1 Share context6related Data with Co-workersUsecase DescriptionIn this usecase the Users (either Police, Guard, Stretcher Team or a Doctor) should be able to sharecontext related data with the Central as well as with the fellow emergency personnel in order foreveryone 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 inthe @aGlance App. The data will then be shared with the Actors that need this information, and theywill then be able to see the tag in the @aGlance App.Functional Components Precondition derived componentso Authentication: In order to log into the @aGlance App a username and password isrequired.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 thentransferred to the central server. Role Based Access Control: A User will have one or more Roles. Having a Role means thatcertain functionality is available in the @aGlance System and that the User retrieves a certainset of the available information in the system.Non Functional Aspects

QualitycharacteristicsSub-aspectsDescriptionTechnical requirementsFunctionalityInteroperabilityMany types of mobilephones should be able touse the systemN/AReliabilityFault toleranceThe system should be ableto function even in the caseof a software fault.N/AEfficiencyTime behaviourData should be transferredquickly from the Users tothe centralResponse time: 3 secondsResource usageThere shouldn’t be used toomuch bandwidth because itis limited and there will bemany users.N/A

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

D2.1 Dissemination Level – PU Page 27

Test related AspectsMalfunction Cases:1. Network: Due to changing network conditions with part unavailability of the mobiledevices the @aGlance App as well as the central server could have problems torecover.2. Resource Limitation: due to the amount of published context and the central storagethe context sharing might become inefficient. Wrong or missing caching mechanismcould result in storage, CPU, and network overflow3. Unhandled exception: GPS sensor are switched off by the user or other application(e.g. battery saving) resulting in an exception at the @aGlance app4. Security: Access privilege mismatch: users have access to information not intended forthem5. Unhandled Exception: Central stations disappear due to hardware, software or powersupply failure. @aGlance app does not notice that and did not start the re-initializationprocess or start the re-initialization process at the same time for every user whichresults in a CPU or network overload.6. Logical mismatch: Due to different used smart phones with different hardware andsoftware capabilities the app might react differently which might cause among othersprotocol mismatch (different app versions) or sensor usage problems (differenthardware) or lack of service robustness (due to different APIs)7. Quality of Information due to deactivated GPS sensors the location information is basedon the CellID but the accuracy value is not considered

Performance testIt should be tested that the context tag gets shared with the coworkers within the definedtimelimit. The response time of the system should be tested in high and low stresssituations.

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

Context tags get shared with co-workersIt 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 EventsUse Case Description

The goal of the crowd control use case is to predict how large crowds will react in certain situations byusing, for instance, artificial intelligence and data from the surroundings,. In the case of an event thecentral 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 nearbypersonnel will get a notification that they must be ready. After the headquarter personnel haveassessed the situation they can either: 1) remove the alarm status, 2) create an emergency planFunctional 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 casethe combination of data sources and algorithms for predicting the crowd behavior will varybased 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, willbe 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 foranalysis. Identify Event Based on Crowd Behavior: The input data (video, voice, sensordata) will beanalyzed 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 thecrowd is too crowded” or “Crowd Panic”. Move Cameras: When an event happens, the nearby cameras should move to the destinationof the event. Alarm: When an event happens the personnel at the headquarter must be notified by soundand visual effect on the @aGlance overview screen.Non Functional Aspects

QualitycharacteristicsSub-aspectsDescriptionTechnical requirementsFunctionalityAccuracyValidity is very important asan event might triggerseveral eventsN/ASecurityIt must not be possible tohack the systemN/AReliability

Reliability

The services must bereliable and have a highlevel of availabilityN/AEfficiency

Time behaviourNear real time performancewill be needed.N/A

Test related AspectsMalfunction Cases:1. Network: video transmissions might exceed the bandwidth of network this can happenespecially if the network is also used from other services and the already consumedbandwidth is unknown2. Quality of Information: Sensor data from mobile devices are outdated, or thetransmitted 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 newtransmissions and the network interface of the central stations gets overloaded4. Hardware failure: calibration mismatch between different sensors results in switchingevent detections at the same location5. Hardware/Software: the calibration of the camera movement is wrong and there is anincreasing gap between the expected and the correct positioning. Use case: Automaticcollaboration in case of emergency (heatstroke or other illness)6. Resource limitations: Stress test of the system must be performed to evaluate how thecrowd behaviour algorithms perform when huge amounts of video, sensor and voicedata are received.7. Robustness: System must be tested in various meteorological situations (e.g. rain andfog), during different times of the day (morning and evening).

Accuracy testIt should be tested that the system delivers the correct answers, even when the conditionsare not optimal, e.g. in the evening.

D2.1 Dissemination Level – PU Page 29

Deployment testIt should be tested that that system delivers the correct answers under real life conditions.6.1.5.3 Activate Emergency PlanUse Case DescriptionIf an event is identified by the headquarter that qualifies for an evacuation of an area, the headquarterwill develop and coordinate an emergency plan. A triggering event could be a smoke alarm that getsactivated 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 acoordinated effort. When it has been chosen that an area should be activated the relevant personnelgets 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 anemergency, different roles have different tasks. The headquarter can order guards to thearea, 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 toheadquarter.

Test related AspectsMalfunction Cases:1. Security: Access privilege mismatch results in access to unintended information2. Resource limitations: due to the number of tasks at the same time during an emergencythe system might be overloaded which could result in time delay, unhandled exceptionsor lack of proper service recovery3. Logical description differs from description: GUI or internal functional description differsfrom the implemented system which results in limited or non-usability of the system4. Logical malfunction: pre-conditions have not been made. e.g. the predefined task havenever been prepared or reviewed or updated5. Resources: due to a part power supply failure or hardware failure some of the sensorinformation is missing the central service hangs due to long timeout exceptions or re-tries

Security testTest that atomic services are only accessible by authorized actors.

D2.1 Dissemination Level – PU Page 30

Interoperability testTest that the system can connect with the devices and external systems.6.1.5.4 Automatic collaboration in case of Emergency (Heatstroke or otherIllness)Use Case DescriptionWhen an emergency happens the different types of emergency personnel should be able tocoordinate the help. In such a situation one of the emergency personnel has tagged the event or theevent 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 thedestination of the emergency.Functional Components‐ Precondition derived components:o Identify emergency based on video: Video will be analysed and an event will be sentto the headquarter in the case of an emergency.o Identify emergency based on voice: Voice data will be analysed and an event will besent 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 ofemergency.‐ Send emergency Message: When the central receives the “emergency tag” (an emergency isoccurring), the location of the tag is transferred to the cameras in the area which automaticallyturns towards the area of the emergency.‐ Request backup: Based on the scale of the emergency a number of stretcher teams anddoctors 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 moresecure 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 moresecure services should be used.Non Functional Aspects

SecurityProcess should be securedue to integration withhospital/police IT-systems

N/A

Test related AspectsMalfunction Cases:1. Logical: Protocol mismatch due to changes at the police or hospital service. Thesystem have not noticed that a change happened and therefore have not beenretested.2. Security violations (security being compromised) : hospital or police service has noneor not enough security protection against security violations.

Functionality testIt 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 Garbagebins)Use Case DescriptionThe usecase goal is that a subset of the data that is available in the system should be made availableto the festival guests. One area that is of interest for the festival guests are the location of emptygarbage bins. Sensors monitor the fill-level of the garbage bins. This data is marked as shared dataand will therefore be available for festival Guests.

Interaction: When the festival guest logs in an starts the @aGlance App the festival guest will be ableto see the empty garbage bins

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

InteroperabilityMany types of mobilephones should be able touse the systemThe software should run on themost popular mobile phones(80% of the available mobilephones)Test related AspectsMalfunction Cases:1. Resource Limitations: too many request at the same time could result in unhandledexceptions, resources overflow (network, CPU, etc.) or lack of proper recovery2. Security: Access privilege mismatch results in no intended data access3. Resource Failures: based on hardware of software failures some of the sensors valuesare not updated and old outdated values are shown to the users.