Big IoT

BIG IoT – Bridging the Interoperability Gap of the
Internet of Things
Deliverable 2.3.a: Requirements Analysis and
Specifications
Version 1.0
State: Release
Date: 30.09.2016
This project has received funding from the European Union’s Horizon 2020 research and
innovation programme under grant agreement No 688038.
DELIVERABLE 2.3.REQUIREMENTS ANALYSIS AND SPECIFICATIONS D 2.3.A
Responsible Person and Affiliation Luca Gioppo - CSI Piemonte
Due Date / Delivery Date 30.09.2016
State Final
Reviewers Ernest Teniente - UPC, Costas Pipilas -

Econais
Version 1.0
Confidentiality Public
© 2017 2
List of Authors
Organisation Authors Main organisations’ contributions
CSI Luca Gioppo Document structure
Nives Alciato Chap. 1-2-3-4-5
Claudio Parodi Compilation of 6-Annex
VMZ Christian Seidel Northern german pilot
UPC Ernest Teniente Barcelona pilot, Second revision
Juan Hernandez Serrano Security
Econais Costas Pipilas First revision
Eva Arleti
Siemens Jelena Mitic Final revision
Bosch Stefan Schmid Third revision
© 2017 3
Table of Contents
ABBREVIATIONS ...................................................................................................... 6
DEFINITIONS AND VOCABULARY .......................................................................... 7
1 INTRODUCTION .......................................................................................... 9
1.1 SCOPE OF THIS DOCUMENT ............................................................................. 9
1.2 EXECUTIVE SUMMARY .................................................................................... 9
1.3 STRUCTURE OF THE DOCUMENT .................................................................... 10
2 METHODOLOGY ....................................................................................... 11
2.1 REQUIREMENTS CLASSIFICATION SCHEMA ..................................................... 12
3 BIG IOT ECOSYSTEM REQUIREMENTS ................................................. 22

3.1 BIG IOT MARKETPLACE ............................................................................... 25
3.2 BIG IOT LIBRARIES ...................................................................................... 27
4 PILOTS REQUIREMENTS......................................................................... 30
4.1 NORTHERN GERMANY PILOT REQUIREMENTS................................................. 30
4.2 BARCELONA PILOT REQUIREMENTS .............................................................. 32
4.3 PIEDMONT PILOT REQUIREMENTS.................................................................. 32
5 SURVEY AND REQUIREMENTS VALIDATION ....................................... 34

5.1 SURVEY....................................................................................................... 34
6 CONCLUSION AND OUTLOOK ................................................................ 35
REFERENCES ......................................................................................................... 36
7 ANNEX ....................................................................................................... 37
7.1 BIG-IOT ECOSYSTEM REQUIREMENTS CATALOGUE ........................................ 37
7.2 NORTHERN GERMANY PILOT REQUIREMENTS CATALOGUE ............................. 49
7.3 BARCELONA PILOT REQUIREMENTS CATALOGUE ........................................... 60
7.4 PIEDMONT PILOT REQUIREMENTS CATALOGUE .............................................. 66
© 2017 4
7.5 SURVEY....................................................................................................... 73
FIGURES AND TABLES.......................................................................................... 87
© 2017 5
Abbreviations
Abbreviation Meaning
BCN Barcelona (pilot)
BIG IoT Project title: Bridging the Interoperability Gap of the Internet of Things
DOA Description of Action
IoT Internet of Things
NG Northern Germany (pilot)
PIE Piedmont (pilot)
SDK Software Development Kit
MKPL Marketplace
SLA Service Level Agreement
ORG Organization
CLIB Consumer Library
PLIB Provider Library
SP Smart Parking
STM Smart Traffic Management
GRP Green Route Planning
© 2017 6
Definitions and Vocabulary

In this document several terms are mentioned that are often used differently even in expert
discussions. To clarify the meaning of those terms in the context of this deliverable the
following table provides a definition of terms.
Term Meaning in Document Context [Reference to Source]

API Application Programming Interface
Application See BIG IoT Application
BIG IoT API A Web based API consisting of a set of specifications for
i.) Providers and Consumers to interact with the BIG IoT Marketplace to
authenticate; register, discover and subscribe to Offerings; and perform
accounting; and ii.) Consumers to directly access the resources offered by
a Provider. The BIG IoT API defines the supported communication protocols,
data formats, semantic descriptions, etc. In order to facilitate BIG IoT Appli-
cations, Services and Platforms to implement and use the BIG IoT API,
dedicated Provider and Consumer Libs (SDKs) are provided for various plat-
forms and programming languages, offering also programming interfaces to
developers.
BIG IoT Application An application software that uses the BIG IoT API to discover Offerings on
the BIG IoT Marketplace, subscribe to Offerings and access the offered re-
sources. A BIG IoT Application acts merely as a (Offering) Consumer.
BIG IoT Marketplace A marketplace for IoT resource providers to offer and trade their resources
with consumers. The BIG IoT Marketplace implements the BIG IoT API in
order to allows Providers to register their Offerings (based on semantic de-
scriptions) and Consumers to discover relevant Offerings (based on semantic
queries) at run-time. The BIG IoT Marketplace also provides accounting
support for Consumers and Providers to track the amount of resources ac-
cessed, as well as a Web Portal for developers and administrators to
support the implementation and management of their BIG IoT Applica-
tions, Services and Platforms on the Marketplace.
BIG IoT Platform An IoT Platform that implements and uses the BIG IoT API to pro-
vide Offerings via the BIG IoT Marketplace.
BIG IoT Service An IoT Service that implements and uses the BIG IoT API to consume and/or
provide Offerings via the BIG IoT Marketplace. A BIG IoT Service can act
both as an Offering Consumer and Provider. It typically consumes basic in-
formation or functionality in order to offer "higher-value" information of
functionality on the BIG IoT Marketplace.
Service See BIG IoT Service
Smart Object A Device able to compute and communicate information about itself or
related artifacts (Physical Entities) to other devices or computer applica-
© 2017 7
tions; a Smart Object is typically attached to or embedded inside a Physical

Entity. Smart Objects either monitor a Physical Entity (sensing) or interact
with the physical world through actuators (actuation). Those functions can
be either controlled autonomously by local computations or triggered from
remote.
Offerings An Offering is a set of resources offered on the marketplace. It typically
encompasses a set of related information (e.g. low-level sensor data or ag-
gregate information) or functions (e.g. actuation tasks or computational
functions)
© 2017 8
1 Introduction
The work package 2 has been divided into four main tasks; task 2.3 is dedicated to require-
ments elicitation.
The purpose of this deliverable is to document the work carried out in the first iteration
phase of WP 2. Task 2.3 Requirements analysis and specification.
1.1 Scope of this Document
Task 2.3 analyses and specifies the requirements for the technology developments across
the whole project, according to the overall goal and vision of BIG IoT as well as the use cases
defined in Task 2.2. Key outcome of this analysis will generate the requirements for the BIG
IoT technologies - specifically the BIG IoT API and marketplace, also requirements for the
pilots will be included in this work.
Those requirements are independent of specific application domains and use cases. The
analysis of use case and pilot requirements will be important as examples for gathering the
generic requirements for the BIG IoT concepts.
The requirements analysis defines the scope, the functionalities and the features of the
overall architecture by taking into account the surrounding software infrastructure. The re-
quirements will be specified for the different aspects, including:
• the BIG IoT API,

• the BIG IoT marketplace and its surrounding software infrastructure,
• the semantic framework,
• the individual use cases,
• the regional pilots.
Since this task runs in three phases this deliverable represents the first phase, the initial set
of requirements that will be the basis for the implementation of the first version of the BIG
IoT technologies.
This document summarizes the inventory of requirements collected in this first phase and
has the goal of conveying the overall vision of the approach taken by the project by referring
to some of the most significant requirements.
1.2 Executive Summary
© 2017 9
To reach the goals that the project has defined it is necessary to transform those goals in a
set of precise requirements that generates a tree of coherent and consequential statements
that will guide the development of the project.
The iterative approach used will help improve and refine the requirements allowing fine tun-
ing of the final implementation.
The goal of this first iteration is to set some founding stones in the requirements infrastruc-
ture: the success of the project will be determined by a solid foundation of requirements
that will help to define the technical decisions throughout the life of the project and beyond.
To this extend a small set of main project requirements have been defined as guiding lights.
This document will present the methodology that has and will be used to collect the re-
quirements.
In the requirements chapters only a few requirements of the many collected will be men-
tioned and commented as considered important to help the reader to have an overall vision
of the project; understanding the reason for some architectural choices.
The complete list will be included as an annex to the document.
The project considered fundamental, for reaching the “ignition” of the ecosystem, to vali-
date the collected requirements; thus a survey has been prepared to be submitted firstly to
internal stakeholders and then, after refining it to external subjects.
The survey will be described even if the final results will fall on the second iteration of this
document.
1.3 Structure of the document
The structure of the document follows the methodological approach described above.
The following Chapter 2 depicts the Methodology used to gather the requirements referring
to the Requirements Classification Schema (FOCUS-D).
In Chapter 3 are described the BIG IoT Ecosystem Requirements that cover the Marketplace
and the Libraries.
In Chapter 4 are listed the Pilots Requirements about Northern Germany, Barcelona and
Piedmont each one indicated their own situation.
In Chapter 5 are explained the Survey and the Requirements Validation.
In Chapter 6 – Annex – are attached all the requirements catalogues related the Ecosystem
and the Pilots, and the structure of the Survey.
© 2017 10
2 Methodology
The requirement elicitation process in the BIG IoT project has been done through calls and
face to face meetings amongst the partners on the general topics regarding the overall archi-
tecture of the project, while the requirements of the pilots has been done only by the
partners involved in the pilots with a feedback on the architectural consequences.
Main requirements have been validated through a survey that has been used internally to
validate the question set and will subsequently be proposed to a group of stakeholders. This
helped to confirm some of the main pillars of the BIG IoT proposition.
In the first iteration requirements have been collected in an agile approach just collecting
the description, the category and the stakeholder using a wiki page to track the evolution
and the changes and to reach consensus. The first iteration goal is to explore some of the
technical open issues that the project goal presents: using semantic, creating a simple adop-
tion path and an inclusive approach for the involved stakeholders, requires placing on the
technical shoulders of the project a high level of complexity that needs to be iteratively vali-
dated and designed. In the second iteration, once the requirements will be refined probably
will be linked to a more structured development environment: an issue tracking system in
the project’s GitLab1 could be used to manage requirements linked to implementation mile-
stones.
The level of detail of the requirements will be, as the first iteration of the document, non-
homogeneous across the components of the project, due to the normal different level of
analysis that the different components will have in this phase.
The goal of the project is ambitious and the iterations will represent a validation of some of
the aspects and the opportunity to enhance and enrich them over time.
Requirements described here derive partly from the use cases already described in delivera-
ble related to the Task 2.2 and part from a deeper analysis over some components.
Parts of the architecture definition will not be repeated in this document but referred to the
specific parts of the 2.4 Deliverable where that topic is described.
Requirements are expressed in complyance with RFC 2119 "Key words for use in RFCs to
Indicate Requirement Levels":
 MUST is equivalent to REQUIRED and SHALL indicating that the definition is an abso-
lute requirement.
1
GitLab is the source code repository manager used by the BIG-IoT project: http://gitlab.com/groups/BIG-IoT
© 2017 11
 MUST NOT is equivalent to SHALL NOT and indicates that it is an absolute prohibition
of the specs.
 SHOULD is equivalent to RECOMMENDED means that there are valid reasons to ig-
nore a particular requirement, but the implications need to be weighed.
 SHOULD NOT and NOT RECOMMENDED means that a particular behavior may be ac-
ceptable or useful, but again, the implications need to be weighed.
 MAY means OPTIONAL and that the requirement is truly optional. Interoperability
with different systems that may or may not implement an optional requirement must
be done.
2.1 Requirements Classification Schema
There are many ways to classify software requirements even if there is no recognized stand-
ard [1].
The requirement classification schema used in the project comes from the agreement of the
consortium partners and a simplified common approach.
The adopted schema concentrates on a set of principal categories that cover many of the
aspects of a software project.
We kept out the requirements on budget and time since these have been considered non-
negotiable requirements already determined by the scope of the project.
This classification scheme is structured in six main categories (each one has sub-categories)
and with an acronym easy to remember (FOCUS-D):
 Functionality
 Detailed Functional
 Data and Accuracy
 Interoperability
 Responsibility
 Operativeness
 Availability
 Performance
 Capacity
 Scalability
 Reliability
 Installation
 Portability
 Compliance
 Laws and Regulations
 External and Internal Standards
 Audit
 Business Rules
 Technologies
© 2017 12
 Cultural and Political Requirements

 Usability
 Physical Environment
 Appearance and Style
 Ease of Use
 Personalization
 Internationalization
 Learning Time
 Accessibility
 Safety and Security
 Safety
 Access Protection
 Integrity
 Privacy
 Documentation, Maintenance and Support
 Documentation
 Maintenance
 Support
 Training
The description of the different classes of requirements follows in next paragraphs.
2.1.1 Requirements Description for “1-Functionality” (4 in total)
1 Detailed Functional Requirements
Content Requirements about what the system shall do. They specify what functions a
system must provide to meet stated and implied stakeholder needs. This
section may be used as a complement to the Use Cases section.
Questions What shall the system do?
Examples The system shall indicate the navigation to parking spots observing smart
objects
2 Data and Accuracy Requirements
Content Requirements about data the system shall use. Also, requirements about the
required level of accuracy of data.
Questions Are there specific data sources the system shall use? Specific data destina-
tions? Is there a data model that specifies entities and relationships for this
system? How long this kind of data shall be retained in data stores? How
long should it be visible to users? Which level of precision do we need to
display times?
© 2017 13
Examples Sensor data and smart objects shall be stored with 14 bit accuracy, expanding
to 18 bits in 3 years.
Sensor data and smart objects shall be archived in each own platform
3 Interoperability
Content Requirements about relationships and interfaces of this system with external
systems.
Questions Which other systems shall interact with the system? What are the interoper-
ability characteristics of these systems?
Examples Each platform shall interoperate with the marketplace
4 Responsibility
Content Requirements about who has the responsibility to perform specific system
functions.
Questions Who has the responsibility to do [a function]?
Examples The air quality shall be defined by the local authority
2.1.2 Requirements Description for “2-Operativeness” (7 in total)
1 Availability
Content Requirements about the availability of the system for operational use.
Questions When must the system be available for use? In which days? In which hours?
Are there specific time periods for which availability is mandatory to meet
business goals?
Examples The system shall be available every workday 24h
2 Performances
Content Requirements about the performances of the system. May vary for different
functions, or typology of functions.
Questions How quickly shall the system produce reports on request?
Examples The response time for the app shall be real time
© 2017 14
3 Capacity
Content Requirements about volumes and peaks the system must deal with, and
about the consumption of scarce resources.
Questions How many transactions per second shall the system manage?
Are there peaks the system must manage?
Examples The system shall be real-time responding
4 Scalability
Content Requirements about the expected growth in volumes that the system must
be able to handle.
Questions Are there forecasts or commitments about the growth in system usage? In
data volumes?
Examples In case of CPU load reaching 95% for more than a stated period another vir-
tual machine shall be activated in the cloud or more CPU shall be added to
the existing one.
5 Reliability
Content Which is the probability that the software executes without failure for a spe-
cific period of time?
Questions Which is the level of reliability needed for this system?
Examples The system shall achieve 99 percent uptime
6 Installation
Content Requirements about system installation and data migration.
Questions Who should install the system?
Is data conversion necessary?
Examples The system shall be available on marketplace
7 Portability
Content Requirements about the portability of the system to other hardware and
software environments.
Questions Shall the system be portable on other platforms? Which platforms? Which
© 2017 15
versions of common web systems shall the system support?
Examples The apps should be portable to all platforms involved
The apps should be available on android, iOS or windows phone smartphone
2.1.3 Requirements Description for “3-Compliance” (6 in total)
1 Laws and Regulations
Content Requirements about the laws, national and international, to comply with.
Take into account the different countries in which the system may be used.
In case of doubt, ask the legal
department of your organization, or a legal consultant.
Questions Are there any national or international laws relevant for this type of system?
Which are the requirements that the law mandates? Are there any copyrights
that must be protected?
Examples The system shall respect the European law in matter of privacy
2 External and Internal Standards
Content Requirements about the standards, external or internal to the organization,

to comply with.
Questions Shall the system support multiple versions of the standard at the same time?
Examples The system shall use coding standards
3 Audit
Content Requirements about the audit controls needed for the system
Questions Are there audit rules to comply with?
Examples The system shall maintain the number of download of the apps
4 Business Rules
Content Policies and procedures of the organization that define or constrain some
aspect of the business, and are relevant for the system. Business rules typi-
cally exist before and independently from the system we have to develop
Questions Are there internal policies to comply with?
© 2017 16
Examples Users shall respect the rules of the marketplace
5 Technologies
Content Requirements about technologies to use, or not to use
Questions Do we need to technological choices in order to be compatible with existing

systems?
Examples The system shall run on the platforms involved
6 Cultural and Political Requirements
Content Requirements about social factors that may influence the acceptability of the
system. These requirements may be related to the user world (e.g. local cul-
tural conventions) or to the internal politics of the organization
 Have the intended users different cultural conventions from our own?
Questions
 Are there colours, icons, or words that have different meanings for them?
 The icon "bike" is related to the UC "Healty Bike Navigation" and "Smart Bike
Examples
Sharing"
 The icon "car" is related to the UC "Smart Parking" and "Smart Traffic
Management"
2.1.4 Requirements Description for “4-Usability” (7 in total)
1 Physical Environment
Content Requirements about the physical environment in which the system will oper-
ate
Questions Which will be the normal usage environment? Should the system operate
also in other environments?
Examples Air quality stations shall be installed in a specific location of the town
2 Appearance and Style
Content Requirements about the style and appearance of the system to its users.
Detailed appearance requirements may be discovered through prototyping
© 2017 17
Questions How shall the system appear to its users? Shall the system be compliant with
corporate style guides, logos, etc.?
Examples The menu apps shall have at most 2 levels. The app will show the logo of the
partner who developed it
3 Ease of Use
Content Requirements about the ergonomic properties of the system, that is the
ease with which the system can be used by the intended users
Questions Which are the most complex functions to use? How shall error messages be
managed?
Examples The apps shall propose the area covered by the sensors. The app shall inform
users that the system is not available
4 Personalization
Content Requirements about the adaptability of the system to the personal prefer-
ences of each user, or, at a collective level, to the needs of specific
organizations.
Questions Shall the system be configurable by each adopting organization?
Examples The apps shall retain the favourite route of the user
5 Internationalization
Content Requirements about the language support of the system. Internationaliza-

tion is a specific and demanding form of personalization.
Questions Which languages shall be used by the system? Shall diverse character sets be
used (e.g. Chinese, Arab, Cyrillic)? Shall more than a language be displayed in
each user interface?
Examples The system shall use in each user interface German, Spanish and Italian
6 Learning Time
Content Requirements about the time needed to learn to use the system.
Questions How much time is allowable before a user of type [specify user typology] can
begin to use the system, performing simple functions?
Examples The apps shall be used after havig completed the on-line course
© 2017 18
7 Accessibility
Content Requirements about the accessibility of the system for people with physical
or cognitive disabilities. In some countries, may be regulated by laws.
Questions Is there any law about accessibility to comply with, for this type of system?
Is there any standard about accessibility to comply with, for this type of sys-
tem?
Examples The apps shall conform to the standard requirements of accessibility for iOS,
android and windows phone and smartphone
2.1.5 Requirements Description for “5-Safety and Security” (4 in total)
1 Safety
Content Requirements about the likely safety effects (loss, damage, or harm) of an
improper usage of the system. Take into account the different countries in
which the system may be used.
Questions Is this system safety-critical? May there be dangers to humans, or to proper-

ties, or to the environment?
Are there safety standards and laws relating to safety to comply with for this
kind of systems?
Examples The application using air quality data SHALL not expose raw data to public
2 Access Protection
Content Requirements about restrictions of access to the system. In case of doubt,

ask the security department of your organization, or a security consultant.
Questions Who has authorized access to the system? Is every function accessible to
everybody?
Examples The app shall be accessible to just public administration’s officers
3 Integrity
Content Requirements about the expected integrity level of the system. Also, re-
quirements about protection of the system from viruses, spyware, trojans
and similar threats.
© 2017 19
Questions What sensitive information must be protected? Which measures shall be

taken to prevent attacks from malicious software?
Examples Data in the DB shall be encrypted
4 Privacy
Content Requirements about privacy of personal and organizational data. Take into
account the different countries in which the system may be used. In case of
doubt, ask the legal department of your organization, or a legal consultant
Questions Do we need to notify users about our management of their data? Are there
sensitive data?
Examples The system shall store information for only as long as it is needed for the
stated purposes
2.1.6 Requirements Description for “6-Documentation, Maintenance and Support” (4 in

total)
1 Documentation
Content Requirements about the user documentation. It is useful to think from the
perspective of all types of users, because the documentation requirements
may be different.
Questions Which kind of user documentation must at a minimum be provided? In which

languages must the user documentation be provided? Who shall produce the
documentation? Who will be responsible for future updates to the documen-
tation?
Examples The documentation is on the shared platform "Wiki" hosted by Siemens and
it shall be written in English language. Each Pilot shall produce and update
the documentation related its own task
2 Maintenance
Content Requirements about the maintenance needs of the system
Questions Who shall maintain the system? Will different parts of the system be main-
tained by different people? Which kind of documentation will be needed for
the maintenance?
© 2017 20
Examples The system shall generate logs of the operations to support incident track-
ing.
3 Support
Content Requirements about the kind and the level of support needed for the system
Questions Which kind of support is required? Shall different levels of support be availa-
ble? Which documentation will be available for the support group?
Examples Support shall be provided via help desk
4 Training
Content Requirements about the user training needed in order to use effectively the
system. It is useful to look from the perspective of all types of users, because
the training needs may be different
Questions What training will be necessary? Who will design the training? Who will pro-
vide the training?
Examples The initial training shall be designed and provided by the developers to the
support group. The support group shall train end users.
© 2017 21
3 BIG IoT Ecosystem Requirements

The goals of the projects are ambitious: „BIG IoT project that aims at igniting an IoT ecosys-
tem as part of the European Platform Initiative“.
To reach this goal the task 2.3 defined a set of founding requirements that will act as a helm
of the overall work. In this summary some requirement ID are used as reference to the
whole list of requirements included in the annex. The most significant ones are used to ex-
press the overall view of the project.
In particular requirement FE-012 states that the means to reach the project’s goals are to
implement a proper marketplace and a set of tools (SDK lib) that will empower users to inte-
grate with the IoT platforms thus being able to bridge the interoperability gap.
The following requirements will better explain the principles that will be followed to em-
power the marketplace and the tools to be really effective:
FE-023 and FE-034 talk about working together with standardization bodies to define and
promote existing or emerging standards. This factor is crucial in an ecosystem like this one to
leverage on known and promising standards, because to ignite the main trigger is induce all
the actors to adopt the project’s outcomes, thus providing tools that comply with standards
will help reach this goal.
FE-045 is linked to the „standardization“ concept: the need of the end user, the actor that
wants to consume data coming out of different IoT platforms, is not having to implement
different code for each different platform he uses, thus limiting the integration. To allow this
actor to have a simple integration there should be a way to present him with a set of known
„smart objects“ that he can manage and use, described by a common and shared ontology.
Since the BIG IoT tools will allow this user to receive the same „smart object“ representation
disregarding the IoT platform source this is one of the main core requirements of the pro-
ject. This requirement will determine the success of the project. Making easy for the
consumer to discover and use the „smart objects“ in his own application and making his ap-
plication working across different IoT platform providers will represent the spark in the
market and the feature that at the moment is not present.
2
The PROJECT SHALL ignite the IoT ecosystem by providing a marketplace and an easy-to-use Lib/SDK for
integrating with it and the IoT platforms
3
The SYSTEM SHALL adopt known and/or promising standards
4
The PROJECT SHALL side with standardization bodies for enhancing the existing standards with the project's
feedback
5
The SYSTEM SHALL offer and promote the use of a set of ontologies to improve convergence towards a com-
mon interpretation of IoT entities
© 2017 22
FE-056 describes the need to involve the providers of the data: the BIG IoT platform has its
own business proposition that, as all, will need a wide user base to really captivate many
provider organizations; one of the requirements is to involve many provider organizations in
the ecosystem.
To achieve this, the project has decided that some of the features have to be optional since
the project and its tools do not have to impose constraints that require the stakeholder to
either accept them all or being cast out.
The IoT ecosystem is a highly dynamic one where IoT platforms are consolidating, providers
have just started investing in the technology and adding more constraints could represent a
risk of failure in making stakeholders adopting the BIG IoT paradigm.
This explains the reason for having 4 architectural integration modes as described in the
architectural diagram that follows [Figure 1]. Allowing the provider’s organization to inte-
grate with the BIG IoT system by any one of the 4 modes is giving stakeholders plenty of
options to adopt the BIG IoT proposition raising the chances that some user will invest some
more efforts to make its data available; this approach is placing an additional complexity on
the shoulders of the project to raise the inclusiveness of the overall proposition.
The main stakeholders of the project are the actors that “have the data”: without this actor
the ecosystem does not exist. These actors usually use a technology that is not developed by
them. This means that the project needs to look at the market, and this move the focus to-
wards the IoT platform vendors that are the one that the project will have to convince to
implement the integration with the BIG IoT API to interact with a marketplace that will help
providers distribute their data.
The other need for the project to be successful is to reach a critical mass of adoption since
the advantage of the whole representation of the data as a semantically represented smart
objects gains value by managing a high amount of sources. This will attract developers and
guarantee a return of investment for the actors that have invested in adopting the BIG IoT
model.
The marketplace will have to propose useful features to those actors and a successful “point
of sale” for their data.
6
The SYSTEM SHALL offer optional features that the user can choose not to use
© 2017 23
Figure 1 - Architecture diagram
The four modes, which will thoroughly be described in D2.4, represent the need to include
stakeholders that are in the condition to directly integrate the BIG IoT libraries inside the
code base of their IoT platform (mode1): these actors are the ones that build IoT platforms.
Other actors could need to place a gateway in front of their platforms to completely inte-
grate with all the feature set of the BIG IoT ecosystem (mode2).
A third case (mode3) is the case in which the actors have IoT solutions that overlap with
some of the feature set of the BIG IoT proposition, but want to use it as a registry to publish
and promote their data and want to be directly accessed by the end users.
These actors represent the majority of the market share of the IoT platform vendors and this
architectural modality represents the strategy of the project for being part of a market share
that will go beyond the partners and the IoT platforms involved in the project.
The final case is represented by IoT devices that could not be always accessible and thus
need BIG IoT proxy service.
© 2017 24
FE-067 is again a requirement that fosters the adoption of the BIG IoT project outcome. At
the current iteration there are no more details in the licencing scheme that the project will
adopt. The actual understanding is that not all components could be licenced with the same
licence and this is due to several constraints that the different components could have: for
example the provider lib that is a component that should be integrated in the IoT platform of
a provider should pose the less constraints as possible to allow developers to actually in-
clude it in their codebase. This will have to be balanced with the adoption of existing
libraries for the actual implementation of the „BIG IoT provider lib“.
3.1 BIG IoT Marketplace
Looking at the marketplace requirements, it is important to underline that the MK-0018 and
MK-0029 again stress the need to use patent free tools and components that will not require
the end user to spend licence fees. The goal of the project is to release a tool that can be
installed on premise to allow a provider to publish its own marketplace and to participate to
the ecosystem. Thus, it is important that all the barriers to adoption are removed from the
inception of the project.
MK-00310 and MK-00411 represent a strong position of the project on the overall architec-
ture of the project. This will be Linux based software with the aim of having it deployed on a
cloud infrastructure.
MK-006 to MK-016 describe the registration and roles of users in the system: the market-
place needs users to participate but also requires establishing a trusted environment. The
balanced approach is to allow users to self-register, but to require a validation for the crea-
tion of new organizations assigning an admin role to each organization and delegating the
user management to this actor. In this way the marketplace owner can guarantee that the
sources are validated and consumers can look and consume data from real and proven pro-
viders; at the same time the involvement process is kept lean and agile.
Semantic is one of the main pillars of the project: the goal is to deliver to consumers a com-
mon shared representation of the smart objects independently from the provider. To reach
this goal the marketplace needs to deliver a set of helping tools to the provider to help him
7
The components of the SYSTEM relevant for an open ecosystem building SHOULD be licensed with an open
source licence
8
The MARKETPLACE (MKPL) SHALL NOT use components that will require the operator to buy any licences
9
The MKPL SHALL NOT be based on software that has known patent implications blocking the ecosystem build-
ing
10
The MKPL SHALL run on Linux based systems
11
The MKPL SHALL be easily deployable on (Cloud) infrastructure
© 2017 25
converge on a common representation and to map its own specific data to the common
model using semantic. The strength of the semantic approach is in the capability to map and
search data even if this require a technical complexity that the project aims to hide behind a
set of wizards.
Thus requirements MK-017 through MK-024 cover the topic of building wizards for the users
of the system. These are at the moment high level requirements that are strongly dependent
on the final format that the project will use to represent all the entities: this means that the
final implementation of the wizards will represent a balance between the complexity of the
technology involved and the need to build an easy tool to guide the user.
There are two main supporting components that the project has prioritized: the tool for
helping the provider to map the data to the common representation since this is the core
feature for the whole project and the marketplace needs to offer coherent representations
to be successful.The second tool is reserved to the consumers and will help them to write
semantic queries to dynamically find all the offerings that will comply with their require-
ments so that it will be possible for their application to discover at runtime all the new
offerings and use them to enrich their service.
Another important requirement is MK-02812 that talks about the rating of offerings: goal of
the marketplace is to build a community around the offerings of smart objects. It is proven
that a rating system is a valuable resource for all providers to measure and to have a feed-
back on their offerings, to understand their positioning and to improve the quality of the
data.
The marketplace, in its minimal approach, could be considered as a registry with some en-
hanced search options and the aim of delivering coherent content; even in this configuration
it has the strength of having a market proposition that at the moment is missing in the eco-
system.
There are other features that the project has planned for the marketplace to make it more
appealing and giving it a selling advantage for providers: being a marketplace the require-
ment MK-03313 states the fact that it will collect usage information coming from the
consumer SDK and provider SDK libraries storing these usage events so that it will be possi-
ble to provide report to the providers of who used what. This feature will also help to
implement the accounting model of the marketplace.
12
The MKPL SHALL allow the consumer to rate the quality of the offerings he uses (subscribed to)
13
The MKPL SHALL expose and API for collecting accounting events for CONSUMERS and PROVIDERS
© 2017 26
These requirements represent aspects of the business model that will be better analysed in
the second iteration, but the existing requirements give enough detail and technical founda-
tion for this iteration.
Examining M2-009 is particularly interesting since it represents a specific path that the pro-
ject decided to follow: using a triple store14 for archiving the data of the marketplace
represents a strong orientation of the project towards the semantic technology.
This technology represents a fundamental element of the project: through semantics, even if
used under the hood of the marketplace, the user will be able to discover all the smart ob-
jects’ offerings that will fit the need of his application and get data out of them. This data
will be converted to a common representation, always through the use of semantics, so that
the application will be able to use it directly.
3.2 BIG IoT libraries
In the BIG IoT ecosystem there are two other components:
• Consumer SDK library

• Provider SDK library
These two components are libraries that the respective actors have to use to code the inte-
gration with the marketplace and for being part of the BIG IoT environment.
The goal of these libraries is to make it simple to access the marketplace features: in the
project approach the user is not provided with just an API to use but with a library that
wraps the API and adds some “code toppings” to further ease the integration process.
3.2.1 Consumer library
Thus in the case of the consumer lib the end user will receive an object representing the
smart object’s offering so that calling the provider and getting the data will be easy hiding
also all the marketplace interactions as much as possible.
The proposed pipeline for development using the marketplace is as follows:
 The user uses the marketplace to discover the data available and to consolidate a “que-
ry” representing its needs.
 This query may also discover in time new data that will conform the criteria defined by
the developer.
14
A purpose-built database for the storage and retrival of data entities composed of “subject-predicate-object”
© 2017 27
 This query will be used in the library to return to the developer the list of the required
offerings. With these offerings the developer will be able to access the data from the
provider by using some common syntax that is understood by the BIG IoT ecosystem and
mapped and translated to bridge the differences between different providers.
In this way the developer will retrieve coherent objects even if he is requiring data by differ-
ent providers potentially located in different locations and operating on different IoT
platforms.
This library will mask all the set of operations that the BIG IoT is implementing to allow the
described pipeline and will expose a simple interface to the user.
All this effort has being done for the sake of inclusion and pushing towards the FE-01 re-
quirement.
Another goal of these libraries is that, by wrapping the calls to the marketplace’s APIs, they
can protect the user code towards the evolution of the marketplace’s APIs.
This library will have to be delivered in more than one programming language and the pro-
ject is targeting the most adopted ones as JavaScript and Java as first implementations.
3.2.2 Provider library
The provider library goal is to ease the publishing of the data endpoint by the provider: this
actor will already have a set of data exposed through an IoT platform, this library either by
being integrated in the platform or used as a tool for simplifying the integration will make
the publishing an operation as smooth and as automatic as possible.
This is one of the most important requirements since the quality of this component will de-
termine the adoption rate of the BIG IoT proposition and the final success towards the final
project goal.
Apart from an initial phase where the provider will have to register himself and his organiza-
tion on the marketplace he will have to get some easy configuration information to be
empowered to place the provider library besides its data to allow a continuous communica-
tion to update the marketplace and to collect all the information on the operation behaviour
and statistics.
Also this library will have to task of decoupling the marketplace API from the end user so
that it will be possible to manage the marketplace evolution by updating just the library
component protecting the investment in integration done by third party.
© 2017 28
This library will be used in all architectural models in a different way as the wrapping to-
wards the marketplace even if all four modes will have their own business logic
implementing the different integration approach.
© 2017 29
4 Pilots Requirements
Pilots have two types of requirements: the ones that affect the overall architecture and the
specific ones for the pilot application.
The project tried to focus initially on the first ones to reduce the risk of later changes on the
architectural aspects of the BIG IoT API.
Obviously being pilots to demonstrate the BIG IoT architecture they will have to comply with
the specific requirements of the final pilot users that are not directly interested in the BIG
IoT concept: from the point of view of the user of the “smart traffic management” pilot for
example is not important how the data get to the application and the integration that BIG
IoT represents, but he is interested in getting the data visualized on a proper dashboard.
Some requirements from the pilots are similar being most web application; some are specific
from the domain managed by the pilot.
One of the main requirements from the pilot is to be able to get a smart object software
representation that is homogeneous across any platform that the pilot opts to use so that it
will not be necessary to understand and harmonize the different data within the application.
This represents the main feature of the BIG IoT proposition.
The complete use cases have been already described in deliverable D2.2.a, here are listed
the requirements that go beyond the already defined features in that document.
4.1 Northern Germany Pilot Requirements
In the Northern Germany Pilot, requirements are defined for applications and services. The
applications cover for the Berlin Pilot Site the “Commuter App” and the “Smart Parking
App”, the “Charging Station Availability Service”, the “Charging Station WMS Service”, the
“Parking Spot Availability Service”, the “Parking Spot WMS Service” and the “VMZ Routing
Service”. For the Wolfsburg pilot site requirements are collected for the “Live bus location
app”, the “People density in area app” and the “Public transport load app” as well as for the
services “Live bus location service”, “People density estimation in area service” and “People
density estimation on bus service”.
The requirement classification for the Northern Germany Pilot follows the presented FOCUS-
D approach. It is furthermore divided by component types: An “All Components”-class rep-
resents the requirements to all applications and services. Those are mostly operativeness
requirements as e.g. “All applications, services, smart objects and other data sources in the
Northern Germany Pilot shall be available on weekdays from 9 am to 5 pm.”.
An “all of a specific component type”-class represents requirements e.g. for “All Applica-
tions” or for “All Services”. Those are mostly operativeness and compliance requirements
© 2017 30
such as “All end user apps in NG Pilot shall provide a single point of contact for the user (im-
print).”. The further classification represents the single applications or services, e.g. “Parking
Spot Availability Service” or “Smart Parking App”. The terminology used in the NG Pilot re-
quirement specification differs between “shall” as must-criteria and “should” as may-
criteria. Therefore, “the app shall…” is a mandatory requirement while “the app should…”
represents an optional requirement.
The pilot partners have documented requirements only for the first iteration components in
this document. In total, 133 requirements are stated.
93 of them are requirements for functionality which represents the implementation focus of
the pilot. The main focus for the first iteration implementation for the Northern Germany
Pilot lays on the integration of the BIG IoT API into basic services and applications. There-
fore, the requirements cover mostly detailed functional requirements for apps and services
as “The app shall allow the user to enter addresses as a starting or destination point of the
trip.” and data requirements, i.e. which data sources are used by the services and applica-
tions and which are provided or consumed via the BIG IoT API. Examples are “The service
shall use data of charging stations provided by VMZ TIC platform.” for direct data consump-
tion or “The service shall provide data on Charging Station Availabilities to VMZ Routing
Service via the BIG IoT API.” for provision of data via the BIG IoT API.
20 requirements address operativeness, seven requirements address usability. Most applica-

tions provided within the Northern Germany Pilot are designed for end users (traffic
participants) and developed services mostly shall provide data for these apps. Therefore
focus is set on usability to support the spreading of apps and services using the BIG IoT envi-
ronment. Response times are examples for such requirements at the app-level as in “In all
end user apps in NG Pilot, response time for the first response to user requests should be
under 5 seconds”, as well as performance within the whole system as stated with “For all
end user applications in NG Pilot that use real-time data, the data should not be older than
10 minutes.”.
12 requirements are for compliance as for example “All end user apps in NG Pilot shall pro-
vide well defined and comprehensive purposes of the data processing (why is which data
stored / used / processed) in the app.”. This represents the high state of data protection and
security in Germany. Furthermore, one requirement addresses safety and security.
The full requirement list for the Northern Germany Pilot can be found in chapter 7.2 on page
49.
© 2017 31
4.2 Barcelona Pilot Requirements
The Barcelona pilot will develop the following use case clusters: 1. Smart Parking, 2. Smart
Traffic Management and 6. Incentive-based Green Route planning. More details were de-
scribed in the deliverable D2.2.a.
Devices and sensors used in the Barcelona Pilot will be provided by both external and inter-
nal parties. The Barcelona City Council will put at BIG IoT disposal noise detectors through
the Sentilo platform. SEAT's in-car sensors will provide with air quality data. Finally,
Worldsensing will provide traffic status based on information gathered by magnetometers
and WiFi/Bluetooth detectors and parking spot availability status collected by on-street
parking sensors.
The first iteration of the Barcelona pilot will put focus on Traffic Management aspects of the
BIG IoT Project, i.e. dealing with performance and connectivity between sensors, handling
different sources of traffic data, and generating useful information from such data that be
meaningful for users –from citizens to operators.
This pilot has documented a total of 42 requirements. Following the FOCUS-D approach, 14
requirements focus on Functionality –addressing Use Cases, Detailed Functionality and In-
teroperability-; 14 more, on Operativeness –Availability, Performance, Capacity, Scalability,
Reliability, Installation and Portability-; 3, on Compliance –Laws and Regulations, and Exter-
nal and Internal Standards–; 1, on Usability –Internationalization–; and 10 on Security –
Safety, Access Protection, Integrity and Privacy. Particularly, the Functional requirements
which address the needs of BIG IoT Applications and Services are specified with detail in the
deliverable D5.1a.
4.3 Piedmont Pilot Requirements
The Piedmont pilot develops five use cases:
1. Smart traffic management

2. Incentive based green route planning
3. Smart bike sharing
4. Healthy bike navigation
5. Smart parking
The details of the use cases requirements can be seen in the D2.2.a deliverable and has not
been duplicated here.
© 2017 32
The Piedmont pilot, in this iteration, has concentrated on the aspects of the devices that will
have to be produced and deployed in the Biella and Vercelli municipality locations.
This device design comes from the experience from two project partners CSI and CSP that
have designed in the past the Haladin [8] air quality station and released it as an open
source/open hardware project; this resource will also be used in the “The4bees” European
project [6] as a starting point for the development of the indoor air quality sensor, thus
managing to properly describe this asset as requirement is an important step of the project.
In this set of requirements one important element is the need for an “over the air” firmware
upgrade: once the smart device is deployed in the municipality environment it will be impos-
sible to update the software of the device by hand so having a proper “over the air” update
system is an important aspect of the design of the device.
Another important detail is the need of having linked measurement: to properly measure
CO2 levels is needed also an accurate pressure and temperature measurements since those
values are needed to properly compensate the CO2 measurement.
The device will be produced by the partner Econais and deployed in the municipalities’ envi-
ronment. The current pilot activities have been finding the proper locations for installing the
sensor within the municipalities, checking the networking connections, getting the proper
allowances to finalize the installation.
On the software side the Piedmont pilot has also the goal to reuse the Opticities’s European
project [7] dashboard outcome as the dashboard for all the use cases that has to show data
on a map to a public administration user.
This will represent a requirement for the pilot services that will have to be able to get the
sensor data using the BIG IoT API and generate the proper output compatible with Opticities
dashboard.
The dashboard will have to be evolved and integrated to use the BIG IoT API linking the out-
comes of two EU project and delivering a tool that could easily help developers to have a
publication option for data coming out of the BIG IoT ecosystem.
© 2017 33
5 Survey and requirements validation
5.1 Survey
The project features and requirements come, at a first stage, from the partners understand-
ing of the IoT ecosystem.
The project planned a survey with the goal of validating these requirements and gathering
additional insight on the needs IoT stakeholders and their acceptance of the BIG IoT proposi-
tion.
The survey has been submitted firstly internally to the partners also as a means to sharing
the overall vision and to validate and hone the survey.
The revised survey will then be submitted to a list of stakeholders that will return a feedback
that the project will evaluate.
The survey is attached to this document as an annex and is hereafter briefly described.
5.1.1 Internal survey
The survey is targeted to IoT providers and application and service developers.
The aim is to better get to know the actors that start the ecosystem in the IoT environment:
the provider; the one that using an IoT platform exposes data to be used.
The project needs to understand if he buy or “make” his own platform to understand the
independence that this actor has from software vendors. Another important thing is the
interest in applying the integration patterns coming from BIG IoT to get the feature en-
hancements that the project proposes; thus the survey explore the interest in the semantic
aspects of the project and in the billing opportunities to get revenue out of the exposed da-
ta.
From the developers point of view the aim is to understand the interest of having an integra-
tion layer between the exposed data and the developer’s application or service. The project
needs to evaluate the level of “masking” that the various libraries should offer going from a
high level API that completely mask the internals to a more detailed set of APIs that give
more control.
Understanding the expectations will help to define the trade-off decisions that will have to
be taken in the next iterations.
© 2017 34
6 Conclusion and Outlook

D2.3.a offers a preliminary list of BIG IoT Requirements related to the First iteration of the
Project.
These requirements have allowed the project to define the first demo development for
some of the components of the architecture.
The discussion over the requirements allowed all the partners to be aware of the complexity
and the overall scope of the project, allowed to better address some crucial technical as-
pects and defined a precise path for the iterative development.
Next requirements iteration will be more linked to development and will have a more de-
tailed view of some of the implementation components of the architecture.
© 2017 35
References
1. by Adriano Comai - www.analisi-disegno.com – Creative Commons Attribution-

Noncommercial-No Derivative Works 3.0 Unported License – version 1.0 - 26th November
2007
2. ISO/IEC 25010:2011 (see http://adcorsi.com/analisidisegnowp/wp-
content/uploads/2013/08/iso25010-en.pdf for not functional requirements).
3. SWEBOK (see http://www.computer.org/web/swebok)
4. BABOK
(see http://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/1538/Describe-
the-basic-classification-of-requirements-as-defined-by-the-BABOK-v20.aspx)
5. http://agilemodeling.com/essays/agileRequirements.htm
6. http://www.alpine-space.eu/projects/thefourbees/en/home
7. http://www.opticities.com/
8. http://www.csipiemonte.it/web/it/magazine/news/1010-haladin-s-la-lampada-magica-che-
difende-la-nostra-salute
9. https://www.flickr.com/photos/azaraskin/5304502420/sizes/o/
10. http://www.icityproject.eu/
D2.2.a – Use case definition
D5.1.a – Pilot Specification deliverable
© 2017 36
7 Annex
7.1 BIG-IoT Ecosystem requirements catalogue
The requirements of the BIG IoT ecosystem cover all Marketplace components and interfac-
es together with the "BIG IoT lib" component both in the Consumer and Provider parts.
To better understand the components relations refer to Figure 1 - Architecture diagram
The following tables will be divided to easily group requirements over the different compo-
nents. Requirements for semantic aspects are part of this table since they are not
independent or represent a component of the system but are part of system.
7.1.1 Project Requirements

Table 1- PRO-RQ-01 – Project Requirements – First iteration
Requirement- Requirement Description Category & Stakeholder

RID Subcategory
(FOCUS-D)
FE-01 The PROJECT SHALL ignite the IoT ecosystem C/Business BIG IoTMarketplace,Offering
by providing a marketplace and an easy-to-use Rules Consumer and Provider
Lib/SDK for integrating with it and the IoT plat-
forms
FE-02 The SYSTEM SHALL adopt known and/or prom- F/Data and BIG IoTMarketplace,Offering
ising standards Accuracy Consumer and Provider
FE-03 The PROJECT SHALL side with standardization F/Data and BIG IoTMarketplace,Offering
bodies for enhancing the existing standards with Accuracy Consumer and Provider
the project's feedback
FE-04 The SYSTEM SHALL offer and promote the use C/Business BIG IoTMarketplace,Offering
of a set of ontologies to improve convergence Rules Consumer and Provider
towards a common interpretation of IoT entities
FE-05 The SYSTEM SHALL offer optional features that F/Functional BIG IoTMarketplace,Offering
the user can choose not to use Consumer and Provider
FE-06 The components of the SYSTEM relevant for an C/Business BIG IoTMarketplace,Offering
open ecosystem building SHOULD be licensed Rules Consumer and Provider
with an open source licence
FE-07 The project SHALL run an instance of the MKPL U/Accessibility BIG IoTMarketplace,Offering
on a publicly accessible internet location Consumer and Provider
FE-08 The MKPL instance SHALL have SLA levels of O/Availability BIG IoTMarketplace,Offering
90% minimum Consumer and Provider
© 2017 37
7.1.2 Marketplace Requirements
The following table collects all the generic requirements of the marketplace not linked to specific inter-
faces – First iteration.
Table 2 - MKP-RQ-01 – Project Requirements – First iteration
Requirement- Requirement Description Category & Sub- Stakeholder

RID category
(FOCUS-D)
MK-001 The MARKETPLACE (MKPL) SHALL NOT use compo- C/Business Rules BIG IoT Market-
nents that will require the operator to buy any licences place Provider
MK-002 The MKPL SHALL NOT be based on software that has C/Business Rules BIG IoT Market-
known patent implications blocking the ecosystem building place Provider
MK-003 The MKPL SHALL run on Linux based systems O/Portability BIG IoT Market-
place Provider
MK-004 The MKPL SHALL be easily deployable on (Cloud) infra- O/Portability BIG IoT Market-
structure place Provider
MK-005 The MKPL SHALL be scalable for performance and avail- O/Scalability BIG IoT Market-
ability place Provider
Organizations
MK-006 The MKPL SHALL manage ORGANIZATIONs (ORG) F/Functional BIG IoT Market-
place Provider
MK-007 The MKPL SHALL manage users belonging to an ORG F/Functional BIG IoT Offering
Consumer and
Provider
MK-008 The MKPL SHALL allow users to create new ORG F/Functional BIG IoT Offering
Consumer and
Provider
MK-009 The MKPL SHALL require a validation from an admin role F/Responsibility BIG IoT Market-
for the newly created ORG place Provider
MK-010 An ORG SHALL have at least 1 user as the administrator F/Functional BIG IoT Offering
(ORG_ADM) Consumer and
Provider
Users
MK-011 The MKPL SHALL allow self registration for users S/Access Protec- BIG IoT Offering
tion Consumer and
Provider
MK-012 The ORG_ADM SHALL create new users for the admin- S/Access Protec- BIG IoT Offering
istration or validate users that declare to belong to the tion Consumer and
organization Provider
© 2017 38

RID category
(FOCUS-D)
MK-013 USERS SHALL belong to one or more of the following S/Access Protec- BIG IoT Market-
roles: mkt_adm, org_adm, user, guest tion place, Offering
Consumer and
Provider
MK-014 ROLE mkt_adm SHALL manage all the entities of the S/Access Protec- BIG IoT Market-
marketplace tion place Provider
MK-015 ROLE org_adm SHALL manage the users of the organiza- S/Access Protec- BIG IoT Offering
tion and the entities linked to the organizations tion Consumer and
Provider
MK-016 ROLE user SHALL manage all the entities linked to the S/Access Protec- BIG IoT Offering
organizations with the exclusions of users tion Consumer and
Provider
Providers management and actions
MK-017 The MKPL SHALL manage offering PROVIDERS belong- F/Functional BIG IoT Offering
ing to an ORG Provider
MK-018 The MKPL SHALL allow users to see PROVIDERS be- S/Access Protec- BIG IoT Offering
longing only to its ORG tion Provider
MK-019 The MKPL SHALL allow a PROVIDER to register OFFER- F/Functional BIG IoT Market-
INGs based on a REGISTRATION DESCRIPTION place Provider
MK-020 The MKPL SHALL save a PROVIDER´s REGISTRATION C/Technologies BIG IoT Market-
DESCRIPTION in a triple-store to allow reasoning over place Provider
unknown semantic entities and to be able to return offer-
ings of coherent semantic entities to the consumer
MK-021 The MKPL SHALL offer an optional feature that allows the F/Functional BIG IoT Offering
provider's organization to make the consumer's organiza- Consumer and
tion pay, through the MKPL, the offering usage based on a Provider
pricing model defined in the offering description
Consumers management and actions
MK-022 The MKPL SHALL manage CONSUMERS belonging to F/Functional BIG IoT Offering
an ORG Consumer
MK-023 The MKPL SHALL allow users to manage CONSUMERS S/Access Protec- BIG IoT Offering
belonging only to its ORG tion Consumer
MK-024 The MKPL SHALL allow a CONSUMER to discover avail- F/Functional BIG IoT Offering
able OFFERING based on a semantic query Consumer
MK-025 The MKPL SHALL offer a wizard to help the user build the U/Ease of Use BIG IoT Offering
semantic query Consumer and
Provider
© 2017 39

RID category
(FOCUS-D)
MK-026 The MKPL SHALL be able to save a query of a CON- F/Functional BIG IoT Offering
SUMER Consumer
MK-027 The MKPL SHALL allow a CONSUMER to subscribe to an F/Functional BIG IoT Offering
OFFERING as a result of a query through a web interface Consumer
The MKPL SHALL allow the consumer to rate the quality
MK-028 F/Functional BIG IoT Offering
of the offerings he uses (subscribed to)
Consumer
MK-029 The subscription process SHALL generate the credentials S/Access Protec- BIG IoT Offering
needed to authenticate the communication between tion Consumer
CONSUMER and PROVIDER
MK-030 The CONSUMER SHALL be able to subscribe to a se- F/Functional BIG IoT Offering
mantic query, which means that the MKPL will periodically Consumer
reissue the query to notify a CONSUMER of changes in
the results (e.g. new offerings)
MK-031 The MKPL SHALL notify a CONSUMER if a subscribed F/Functional BIG IoT Offering
OFFERING is changed by its PROVIDER (e.g. offering Consumer
withdrawn or conditions changed)
MK-032 The MKPL SHALL provide a wizard to help the provider's U/Ease of Use BIG IoT Market-
organization converge on a common ontology representa- place Provider
tion of the "smart thing"
API Communications
MK-033 The MKPL SHALL expose and API for collecting account- C/Audit BIG IoT Offering
ing events for CONSUMERS and PROVIDERS Consumer and
Provider
MK-034 The MKPL SHALL expose an API for PROVIDERS and F/Interoperability BIG IoT Offering
CONSUMERS to interact with MKPL Consumer and
Provider
MK-035 All communications between a PROVIDERS or CON- S/Access Protec- BIG IoT Market-
SUMERS and the MKPL SHALL be encrypted tion place, Offering
Consumer and
Provider
MK-036 Access to the MKPL APIs SHALL be protected through S/Access Protec- BIG IoT Market-
user authentication and access control tion place, Offering
Consumer and
Provider
MK-037 The MKPL SHALL offer a web interface and a backend C/Technologies BIG IoT Market-
set of components; this implementation detail is defined in place, Offering
the architectural design Consumer and
Provider
© 2017 40
7.1.3 Interface M2 (register) requirements

The following table collects all the Interface M2 (register) requirements – First iteration.
Table 3 - M2-INTERFACE-REQ – First iteration

RID Subcategory
(FOCUS-D)
M2-001 The MKPL SHALL expose an API to register a REGIS- F/Functional BIG IoT Mar-
TRATION DESCRIPTION belonging to a PROVIDER of an ketplace
ORG Provider
M2-002 The access to the registration API on the MKPL SHALL be S/Access Protec- BIG IoT Offer-
protected using authentication in order to identify the PRO- tion ing Provider
VIDER
M2-003 The REGISTRATION DESCRIPTION content SHALL be C/External and BIG IoT Offer-
compliant with description done in deliverable D2.4.a and Internal Standards ing Provider
SHALL contain information about the price model, license
of the data, access control restrictions, and the geographic
area of the OFFERINGS provided
M2-004 The MKPL SHOULD provide a Web Portal to allow a user F/Functional BIG IoT Offer-
to generate the REGISTRATION DESCRIPTION ing Provider
M2-005 The MKPL SHOULD allow the user to store a REGISTRA- F/Functional BIG IoT Offer-
TION DESCRIPTION via the Web Portal ing Provider
M2-006 The REGISTRATION DESCRIPTION SHALL be validated F/Data and Accu- BIG IoT Offer-
before being stored racy ing Provider
M2-007 The REGISTRATION DESCRIPTION SHALL contain the F/Interoperability BIG IoT Offer-
information of the Integration Mode that is used by the IoT ing Provider
platform (mode 1 through 4)
M2-008 The REGISTRATION DESCRIPTION SHALL allow a F/Functional BIG IoT Offer-
PROVIDER to semantically describe OFFERINGS that are ing Provider
not yet supported by the Web Portal
M2-009 The MKPL SHALL store the REGISTRATION DESCRIP- C/Technologies BIG IoT Mar-
TION in a semantic store (e.g. triple store) ketplace
Provider
M2-010 A PROVIDER platform or service SHALL be able to regis- F/Interoperability BIG IoT Offer-
ter a REGISTRATION DESCRIPTION at run-time by ing Provider
providing the semantic description or a reference to a
stored REGISTRATION DESCRIPTION on the MKPL
M2-011 An REGISTRATION DESCRIPTION MAY include one or F/Functional BIG IoT Offer-
more OFFERINGS ing Provide
7.1.4 Interface M3 (lookup) requirements
© 2017 41
The following table collects all the Interface M3 (lookup) requirements – First iteration.
Table 4 - M3-INTERFACE-REQ – First iteration

RID Subcategory
(FOCUS-D)
M3-001 The MKPL SHALL allow CONSUMERS to search for OF- F/Functional BIG IoT Offering
FERINGS based on a semantic query and return a list Consumer
of matching OFFERINGS
M3-002 The MKPL SHALL expose a discovery API to the MKPL, F/Functional BIG IoT Offering
allowing CONSUMERS to discover OFFERINGS Consumer
M3-003 The access to the discovery API on the MKPL SHALL be S/Access Protec- BIG IoT Offering
protected using authentication in order to identify the tion Consumer
CONSUMER
M3-004 The MKPL SHOULD provide a Web Portal to allow a user F/Functional BIG IoT Offering
to generate an OFFERING QUERY Consumer
M3-005 The MKPL SHOULD allow the user to store a QUERY via F/Functional BIG IoT Offering
the Web Portal Consumer
M3-006 A CONSUMER service or application SHALL be able to F/Interoperability BIG IoT Offering
query the MKPL at run-time by providing the QUERY or a Consumer
reference to a stored QUERY on the MKPL
M3-008 The QUERY_LANGUAGE SHALL allow to search on spa- F/Functional BIG IoT Offering
tial clauses Consumer
M3-009 The QUERY_LANGUAGE SHALL allow to search on tem- F/Functional BIG IoT Offering
poral clauses (offering that exposes the measurement time Consumer
could be searched by range interval or could be sub-
scribed for real time reading)
M3-010 The QUERY_LANGUAGE SHALL allow to search on the F/Functional BIG IoT Offering
SCHEMA used to return the data Consumer
M3-011 The QUERY_LANGUAGE SHALL allow to search on topic F/Functional BIG IoT Offering
related to type of offering Consumer
M3-012 The QUERY_LANGUAGE SHALL allow a CONSUMER to F/Functional BIG IoT Offering
write a QUERY for OFFERINGS that are not yet supported Consumer
by the Web Portal
7.1.5 BIG IoT Consumer LIB requirements
The following table collects all the requirements for the Consumer LIB requirements – First
iteration
Table 5 - CONS_LIB_REQ – BIG IoT Consumer LIB Requirements – First iteration

RID Subcategory
(FOCUS-D)
CL-001 The CONSUMER LIB (CLIB) SHALL implement the BIG IoT Service
wrapping of BIG IoT API (M1, M3, M4, A1) and Application
Developer
© 2017 42

RID Subcategory
(FOCUS-D)
The CLIB SHALL be a facade to use the API exposed
CL-002 F/Interoperability BIG IoT Service
by the MKPL, masking the complexity for the develop-
and Application
ers of interacting with the MKPL and access resources
Developer
offered by a PROVIDER
The CLIB SHALL support authentication of the CON-
CL-003 S/Access Protec- BIG IoT Service
SUMER application or service on the MKPL.
tion and Application
Note: Upon successful authentication, the CLIB obtains Developer
credentials to access the MKPL
CL-004 The CLIB SHALL support discovery of relevant OFFER- F/Functional BIG IoT Service
INGS registered on the MKPL and Application
Developer
The CLIB SHALL support subscription to OFFERINGS
CL-005 F/Functional BIG IoT Service
on the MKPL.
and Application
Note: Upon subscription to an OFFERING, the CLIB Developer
obtains credentials to access the OFFERING on the
PROVIDER.
CL-006 The CLIB SHALL manages the usage of credentials for S/Access Protec- BIG IoT Service
all the required interactions with the MKPL and other tion and Application
PROVIDERS Developer
CL-007 The CLIB SHALL allow access (via the A1 interface) to F/Functional BIG IoT Service
resources offered by a PROVIDER based on the infor- and Application
mation provided by the MKPL in the OFFERING Developer
DESCRIPTION (ODESC)
CL-008 The CLIB SHALL allow to call directly the IoT platform F/Interoperability BIG IoT Service
using the information present in the ODESC (this will and Application
enable the Mode3 of the architecture) Developer
CL-009 The CLIB SHOULD transform the received information F/Functional BIG IoT Service
from a PROVIDER if a mapping description is present in and Application
the ODESC Developer
CL-010 The CLIB SHALL conform to the model described in the C/External and BIG IoT Service
deliverable 2.3.a Internal Standards and Application
Developer
CL-011 The CLIB SHALL be released in JAVA C/Technologies BIG IoT Service
and Application
Developer
CL-012 The CLIB SHALL be released in JavaScript C/Technologies BIG IoT Service
and Application
Developer
CL-013 The CLIB SHALL be tested on Windows, Linux and C/Technologies BIG IoT Service
Android and Application
© 2017 43

RID Subcategory
(FOCUS-D)
Developer
CL-014 The CLIB SHALL NOT use software components that C/External and BIG IoT Service
will require to buy any licences Internal Standards and Application
Developer
CL-015 The CLIB SHOULD be provided under an open source C/External and BIG IoT Service
license Internal Standards and Application
Developer
CL-016 The CLIB SHOULD send accounting information to the C/Audit BIG IoT Service
MKPL for access to an OFFERING and Application
Developer
CL-017 The CLIB SHALL allow access to subscribed OFFER- O/Availability BIG IoT Service
INGS even if the MKPL is temporarily down and Application
Developer
CL-018 The CLIB SHOULD keep a cache of the latest searches O/Availability BIG IoT Service
to allow it to operate even in case of downtime of the and Application
MKPL Developer
CL-019 The CLIB SHALL attempt to use locally available cre- F/Functional BIG IoT Service
dentials, if available, for platforms that are integrated and Application
with Mode 3 - credentials will be associated based on Developer
the tuple (provider_id, offering_id)
CL-020 The CLIB, in mode3, SHALL enable the transformation F/Interoperability BIG IoT Service
of the input parameters defined in the offerings to the and Application
input parameters expected by the IoT platform API Developer
CL-021 The CLIB for the supported platforms and development U/Accessibility BIG IoT Service
environment SHALL be discoverable and downloadable and Application
from the MKPL Developer
7.1.6 BIG IoT Provider LIB requirements
The following table collects all the requirements for the Provider LIB requirements – First
iteration
Table 6 - PROV_LIB_REQ – BIG IoT Provider LIB Requirements – First iteration

RID Subcategory
(FOCUS-D)
PL-001 The PROVIDER LIB (PLIB) SHALL implement the wrap- F/Interoperability BIG IoT Service
ping of the BIG IoT API (M2) and Platform
Developer
PL-002 The PLIB SHALL be a facade to use the API exposed by F/Interoperability BIG IoT Service
the MKPL, masking the complexity for the developer of and Platform
© 2017 44

RID Subcategory
(FOCUS-D)
interacting with the MKPL and providing CONSUMERS Developer
access to resources
PL-003 The PLIB SHALL support authentication of the PROVID- S/Access Protec- BIG IoT Service
ER platform or service on the MKPL tion and Platform
Developer
Note: Upon successful authentication, the PLIB obtains
credentials to access the MKPL
PL-004 The PLIB SHALL support registration of resource OFFER- F/Functional BIG IoT Service
INGS provided by the PROVIDER platform or service on and Platform
the MKPL Developer
PL-005 The PLIB SHALL provide access to resources offered by F/Functional BIG IoT Service
the PROVIDER for platforms integrated based on Mode 1, and Platform
2 and 4 (see figure 1) as well as services Developer
PL-006 For Integration Mode 1, 2 and 4 (see figure 1), the PLIB F/Functional BIG IoT Service
SHALL provide access credentials as part of the OFFER- and Platform
ING Developer
PL-007 For Integration Mode 1, 2 and 4 (see figure 1), the PLIB S/Access Protec- BIG IoT Service
SHALL validate the access credential provided by the tion and Platform
CONSUMER request prior to processing the access re- Developer
quest
SHALL validate the consumer credential provided by the tion and Platform
CONSUMER request prior to granting access to any re- Developer
sources
SHALL change the access credentials for an OFFERING, tion and Platform
when an offering is updated (to ensure that a CONSUM- Developer
ER cannot access the OFFERING any longer without
explicitly subscribing to it first)
PL-010 The PLIB SHALL be incorporated in the IoT platform and F/Interoperability BIG IoT Service
exposed as one of the IoT platform endpoint (for Integra- and Platform
tion Mode 1) Developer
PL-011 The PLIB SHALL be incorporated in the gateway or proxy F/Interoperability BIG IoT Service
service and exposed as independent endpoint (for Inte- and Platform
gration Mode 2 and 4) Developer
PL-012 The PLIB SHALL be released in JAVA C/Technologies BIG IoT Service
and Platform
Developer
PL-013 The PLIB SHALL be released in JavaScript C/Technologies BIG IoT Service
and Platform
Developer
PL-014 The PLIB SHALL be tested on Windows, Linux and An- C/Technologies BIG IoT Service
droid and Platform
Developer
PL-015 The PLIP SHALL NOT use software components that will C/External and BIG IoT Service
require to buy any licences Internal Standards and Platform
© 2017 45

RID Subcategory
(FOCUS-D)
Developer
PL-016 The PLIP SHOULD be provided under an open source C/External and BIG IoT Service
license Internal Standards and Platform
Developer
PL-017 The PLIB SHALL send accounting information for access C/Audit BIG IoT Service
to an OFFERING to the MKPL and Platform
Developer
PL-018 The PLIB SHALL allow access to offered resources even O/Availability BIG IoT Service
if the MKPL is temporarily down and Platform
Developer
PL-019 The PLIB for the supported platforms and development U/Accessibility BIG IoT Service
environment SHALL be discoverable and downloadable and Platform
from the MKPL Developer
PL-020 The PLIB SHALL manages the usage of credentials for all BIG IoT Service
S/Access Protec-
the required interactions with the MKPL and Platform
tion
Developer
7.1.7 Common Security & Privacy Requirements
The following table presents common security and privacy requirements.

RID Subcategory
(FOCUS-D)
SP-001 Extend security end-to-end. S/Access Pro- all

IoT communications typically spread over several nodes tection
and technologies. In particular, BIG IoT is not another IoT
platform, it is a framework for a heterogeneous set of S/Integrity
platforms, services, and applications. A possible solution
to provide security would be to leave the mechanisms
already in use for each platform, and then to define adap-
tation policies of these mechanisms in the boundary points
of platforms. The definition of these “low-level” relation-
ships would highly increase complexity and hence should
be avoided. The solution adopted in BIG IoT is to provide
security at the API level accordingly to the actual platform
capabilities and/or constraints..
SP-002 “Batteries included but swappable”. BIG IoT has to S/Access Pro- all
be designed to be capable of ageing in place while tection
still addressing evolving risks.
There may appear new attacks, crypto systems, counter S/Integrity
measures, techniques, and topologies, but the IoT system
must be capable of dealing with these emerging concerns
© 2017 46

RID Subcategory
(FOCUS-D)
long after the system was deployed. Consequently, BIG

IoT must ship a default but swappable security implemen-
tation, not hard-coded to specific security
protocols/systems.
SP-003 S/Access Pro- BIG IoT Service

Flexible authentication/authorization.
tection Provider
The authentication and authorization systems used in the
BIG IoT ecosystem must ease the management of identi- S/Integrity BIG IoT Market-
ties and permissions. Features like single sign on and place Provider
authentication without intervention of the BIG IoT auth
manager are key. Therefore decentralized, federated or
delegated authentication must be supported.
SP-004 Continuous security. S/Integrity BIG IoT Market-

The BIG IoT system should be ready to respond to hostile place Provider
participants, compromised nodes, and any other adverse
event. Therefore, it is necessary to implement mecha- BIG IoT Service
nisms and/or tools to re-issue credentials, exclude Provider
participants, distribute security patches, updates, swap
algorithms, or protocols, etc. BIG IoT Applica-
tion Provider
SP-005 Secure development. S/Access Pro- BIG IoT Devel-

Security must be a key part during the design phase of tection opers
every BIG IoT software, but a secure design would be
useless if development errors open unexpected attacks S/Integrity
and/or vulnerabilities.
S/Privacy
SP-006 Data minimization. S/Integrity BIG IoT Service

Data minimisation is a long-standing principle of privacy and Platform
protection that means that a data controller should limit the S/Privacy Provider
collection of personal information to what is directly rele-
vant and necessary to accomplish a specific purpose. C/Laws and
In the EU, the data minimisation principle derives from Regulations
Article 6.1(b) and (c) of Directive 95/46/EC and Article
4.1(b) and (c) of Regulation EC (No) 45/2001, which state
that personal data must be "collected for specified, explicit
and legitimate purposes" and must be "adequate, relevant
and not excessive in relation to the purposes for which
they are collected and/or further processed".
When a company needs to gather and store sensitive data
with a business purpose, it should consider whether it can
do so with a deidentified data set. Deidentified data can
© 2017 47

RID Subcategory
(FOCUS-D)
reduce potential consumer harm while still promoting

beneficial societal uses of the information.
A key to effective de-identification is to ensure that the
data cannot be reasonably re-identified even with external
cross sources. This usually requires removing identifiers or
pseudo-identifiers
SP-007 Strong accountability. S/Access Pro- BIG IoT Service

BIG IoT platforms, services and applications should protection Provider
vide proper accounting mechanisms to securely log any
action by any actor dealing with sensitive data. S/Integrity BIG IoT Market-
However, enabling strong accountability may also com- place Provider
promise individual/data privacy. Finding an appropriate S/Privacy
balance is challenging and specific to every ser-
vice/individual.
SP-008 Transparency and easy access. S/Access Pro- BIG IoT Service
The centrepiece legislation at EU level in the field of data tection Provider
protection is the Data Protection Directive which is imple-
mented in EU Member States through national laws. This S/Integrity BIG IoT Applica-
directive aims to protect the rights and freedoms of per- tion Provider
sons with respect to the processing of personal data by S/Privacy
laying down guidelines that determine when the pro- BIG IoT Market-
cessing is lawful. C/Laws and place Provider
The EU will require European organizations to publish Regulations
transparent and easily accessible data protection policies.
In this context, simple icons on websites and applications
could explain how, by whom and under whose responsibil-
ity personal data will be processed. As a consequence,
users are better informed about how and if their personal
data is being exploited. The set of privacy icons proposed
by Aza Raskin[9] are a good example. BIG IoT applica-
tions should use similar icons (or even those) to clearly
show end users how their data are being processed.
© 2017 48
7.2 Northern Germany Pilot Requirements Catalogue
The following table collects all the requirements for the Northern Germany Pilot – First itera-
tion.
Table 7 - NG-01 – BIG IoT Regional Northern Germany Pilot Requirements – First iteration
Require- Subsystem Requirement Description Category & Stakeholder

ment-RID Subcategory
(FOCUS-D)
Charging Station The service shall filter information 1.1 Functionality -
Availability Service according to a given set of location Functionality (de- BIG IoT Service
RQF-NG-1 (SRV-CS_AS) and perimeter. tailed) Provider
The app shall allow a user to get
best routes according to his prefer- 1.1 Functionality -
Commuter App ences between a start and a Functionality (de- BIG IoT Service
RQF-NG-2 (APP-CA) destination. tailed) Provider
1.1 Functionality -
Commuter App The app shall provide routes for Functionality (de- BIG IoT Service
RQF-NG-3 (APP-CA) long distance public transport. tailed) Provider
The app shall allow the user to
choose a point on a map as a start- 1.1 Functionality -
Commuter App ing and/or destination point of the Functionality (de- BIG IoT Service
RQF-NG-4 (APP-CA) trip. tailed) Provider
The app shall allow the user to
choose actual position of the 1.1 Functionality -
Commuter App smartphone as a starting or desti- Functionality (de- BIG IoT Service
RQF-NG-5 (APP-CA) nation point of the trip. tailed) Provider
1.1 Functionality -
Commuter App The app shall provide routes for Functionality (de- BIG IoT Service
RQF-NG-6 (APP-CA) individual (street) traffic. tailed) Provider
The app shall allow the user to 1.1 Functionality -
Commuter App enter adresses as a starting or Functionality (de- BIG IoT Service
RQF-NG-7 (APP-CA) destination point of the trip. tailed) Provider
Live bus location The app shall use the information 1.1 Functionality -
app (APP- provided by the Live bus location Functionality (de- BIG IoT Service
RQF-NG-8 APP_LBL) service. tailed) Provider
Live bus location The app shall provide the infor- 1.1 Functionality -
app (APP- mation in form of the location Functionality (de- BIG IoT Service
RQF-NG-9 APP_LBL) marked on a map. tailed) Provider
Live bus location 1.1 Functionality -
app (APP- The app shall allow the user to Functionality (de- BIG IoT Service
RQF-NG-10 APP_LBL) select bus from a menu. tailed) Provider
Live bus location The app shall provide the infor- 1.1 Functionality -
app (APP- mation based on the input from the Functionality (de- BIG IoT Service
RQF-NG-11 APP_LBL) user of bus line. tailed) Provider
Live bus location The service shall provide the live 1.1 Functionality - BIG IoT Service
RQF-NG-12 service (SRV- location of buses, based on bus id. Functionality (de- Provider
© 2017 49

(FOCUS-D)
SRV_LBL) tailed)
Parking Spot The service shall filter information 1.1 Functionality -
Availability Service according to a given set of location Functionality (de- BIG IoT Service
RQF-NG-13 (SRV-PS_AS) and perimeter. tailed) Provider
People density The service shall provide an esti-
estimation in area mate of the number of people in an 1.1 Functionality -
service (SRV- area based on a defined area and Functionality (de- BIG IoT Service
RQF-NG-14 SRV_PDEA) time. tailed) Provider
People density
estimation on bus The service shall provide an esti- 1.1 Functionality -
service (SRV- mate of the number of people on Functionality (de- BIG IoT Service
RQF-NG-15 SRV_PDEB) buses. tailed) Provider
People density
estimation on bus The service shall filter the infor- 1.1 Functionality -
service (SRV- mation according to bus id and Functionality (de- BIG IoT Service
RQF-NG-16 SRV_PDEB) time. tailed) Provider
People density in The user shall be able to select the 1.1 Functionality -
area app (APP- area from a map and the time from Functionality (de- BIG IoT Service
RQF-NG-17 APP_PDA) a menu. tailed) Provider
People density in The app shall provide information in 1.1 Functionality -
area app (APP- the form of map (heat map) and Functionality (de- BIG IoT Service
RQF-NG-18 APP_PDA) graphs. tailed) Provider
People density in The app shall allow the user to get 1.1 Functionality -
area app (APP- an overview of the current and Functionality (de- BIG IoT Service
RQF-NG-19 APP_PDA) historical people density in an area. tailed) Provider
People density in 1.1 Functionality -
area app (APP- The app shall provide information Functionality (de- BIG IoT Service
RQF-NG-20 APP_PDA) based on input of area and time. tailed) Provider
Public transport The app shall allow the user to get 1.1 Functionality -
load app (APP- an overview of the current and Functionality (de- BIG IoT Service
RQF-NG-21 APP_PTL) historical load of public transport. tailed) Provider
Public transport 1.1 Functionality -
load app (APP- The app shall provide information Functionality (de- BIG IoT Service
RQF-NG-22 APP_PTL) based on input of bus line and time. tailed) Provider
load app (APP- The app shall provide the transport Functionality (de- BIG IoT Service
RQF-NG-23 APP_PTL) load information in form of graphs. tailed) Provider
load app (APP- The user shall be able to pick the Functionality (de- BIG IoT Service
RQF-NG-24 APP_PTL) bus line from a menu. tailed) Provider
The app shall allow a user to enter 1.1 Functionality -
Smart Parking App an address for positioning and Functionality (de- BIG IoT Service
RQF-NG-25 (APP-SP_A) information provision. tailed) Provider
Smart Parking App The app shall allow a user to get 1.1 Functionality - BIG IoT Service
RQF-NG-26 (APP-SP_A) the best route for private transport Functionality (de- Provider
© 2017 50

(FOCUS-D)
(street traffic) to the selected park- tailed)
ing spot.
The app shall allow a user to select 1.1 Functionality -
Smart Parking App an parking spot from the list or the Functionality (de- BIG IoT Service
RQF-NG-27 (APP-SP_A) map. tailed) Provider
For the given location, the app shall 1.1 Functionality -
Smart Parking App provide a map indicating parking Functionality (de- BIG IoT Service
RQF-NG-28 (APP-SP_A) spots and their availability status. tailed) Provider
The app shall provide ist Infor- 1.1 Functionality -
Smart Parking App mation for the current location Functionality (de- BIG IoT Service
RQF-NG-29 (APP-SP_A) (using GPS). tailed) Provider
The app shall allow a user to locate 1.1 Functionality -
Smart Parking App a position on a map for information Functionality (de- BIG IoT Service
RQF-NG-30 (APP-SP_A) provision. tailed) Provider
For the given location, the app shall 1.1 Functionality -
Smart Parking App provide a list of parking spots with Functionality (de- BIG IoT Service
RQF-NG-31 (APP-SP_A) their availability status. tailed) Provider
1.1 Functionality -
Smart Parking App The availability status of parking Functionality (de- BIG IoT Service
RQF-NG-32 (APP-SP_A) spots shall be current. tailed) Provider
The app shall provide ist Infor- 1.1 Functionality -
Smart Parking App mation for a free to choose location Functionality (de- BIG IoT Service
RQF-NG-33 (APP-SP_A) (selectable by the user). tailed) Provider
VMZ Routing The service shall allow multimodal 1.1 Functionality -
Service (APP- routing for car traffic and long dis- Functionality (de- BIG IoT Service
RQF-NG-34 MRS) tance public transport. tailed) Provider
The service shall allow a user to
VMZ Routing route with car traffic from a start to 1.1 Functionality -
Service (APP- available charging station at or near Functionality (de- BIG IoT Service
RQF-NG-35 MRS) a destination. tailed) Provider
VMZ Routing The service shall provide best 1.1 Functionality -
Service (APP- routes from start to destination for Functionality (de- BIG IoT Service
RQF-NG-36 MRS) car traffic (Street). tailed) Provider
VMZ Routing route with car traffic from a start to 1.1 Functionality -
Service (APP- an available parking spot at or near Functionality (de- BIG IoT Service
RQF-NG-37 MRS) a destination. tailed) Provider
VMZ Routing route multimodal from a start to a 1.1 Functionality -
Service (APP- destination, returning the best route Functionality (de- BIG IoT Service
RQF-NG-38 MRS) for each modal option. tailed) Provider
VMZ Routing The service shall provide best 1.1 Functionality -
Service (APP- routes from start to destination for Functionality (de- BIG IoT Service
RQF-NG-39 MRS) long distance public transport. tailed) Provider
RQF-NG-40 VMZ Routing The service shall take personal trip 1.1 Functionality - BIG IoT Service
© 2017 51

(FOCUS-D)
Service (APP- preferences into account for route Functionality (de- Provider
MRS) calculation. tailed)
The service shall provide best
VMZ Routing routes from start to destination for 1.1 Functionality -
Service (APP- car traffic (Street) taking real time Functionality (de- BIG IoT Service
RQF-NG-41 MRS) traffic data into account. tailed) Provider
Charging Station The service shall provide data on 1.2 Functionality -
Availability Service location, plug type, voltage and Data and Accura- BIG IoT Service
RQF-NG-42 (SRV-CS_AS) availability of charging stations. cy Provider
Charging Station The service shall use data on loca- 1.2 Functionality -
Availability Service tion and availability (free, Data and Accura- BIG IoT Service
RQF-NG-43 (SRV-CS_AS) occupied), voltage and plug-type. cy Provider
Charging Station The Service shall handle all 1.2 Functionality -
Availability Service georeferenced information in Data and Accura- BIG IoT Service
RQF-NG-44 (SRV-CS_AS) WGS84 format. cy Provider
The app shall use Charging Station
Availability Data by using the 1.2 Functionality -
Commuter App Charging Station Availability Ser- Data and Accura- BIG IoT Service
RQF-NG-45 (APP-CA) vice through the BIG IoT API. cy Provider
The app shall handle all georefer- 1.2 Functionality -
Commuter App enced information in WGS84 Data and Accura- BIG IoT Service
RQF-NG-46 (APP-CA) format. cy Provider
The app shall use Parking Spot
Availability Data by using the Park- 1.2 Functionality -
Commuter App ing Spot Availability Service Data and Accura- BIG IoT Service
RQF-NG-47 (APP-CA) through the BIG IoT API. cy Provider
The app shall use parking spot
availability pictures by using the 1.2 Functionality -
Commuter App Parking Spot WMS Service through Data and Accura- BIG IoT Service
RQF-NG-48 (APP-CA) the BIG IoT API. cy Provider
Parking Spot The service shall provide data on 1.2 Functionality -
Availability Service location and availability of parking Data and Accura- BIG IoT Service
RQF-NG-49 (SRV-PS_AS) spots. cy Provider
Parking Spot The service shall use data on loca- 1.2 Functionality -
Availability Service tion and availability (free, occupied) Data and Accura- BIG IoT Service
RQF-NG-50 (SRV-PS_AS) of parking facilities. cy Provider
Parking Spot The service shall handle all georef- 1.2 Functionality -
Availability Service erenced information in WGS84 Data and Accura- BIG IoT Service
RQF-NG-51 (SRV-PS_AS) format. cy Provider
Parking Spot The service shall provide WMS tiles 1.2 Functionality -
WMS Service indicating location and availibility Data and Accura- BIG IoT Service
RQF-NG-52 (SRV-PS_WMS) (free / occupied) of Parking Spots. cy Provider
The app shall use parking spot 1.2 Functionality -
Smart Parking App availability pictures provided by the Data and Accura- BIG IoT Service
RQF-NG-53 (APP-SP_A) Parking Spot WMS Service provid- cy Provider
© 2017 52

(FOCUS-D)
ed via the BIG IoT API.
The app shall use parking spot
availability data provided by the 1.2 Functionality -
Smart Parking App Parking Spot Availability Service Data and Accura- BIG IoT Service
RQF-NG-54 (APP-SP_A) via the BIG IoT API. cy Provider
The app shall handle all georefer- 1.2 Functionality -
Smart Parking App enced Information in WGS84 Data and Accura- BIG IoT Service
RQF-NG-55 (APP-SP_A) format. cy Provider
VMZ Routing The service shall be able to use 1.2 Functionality -
Service (APP- GTFS data for public transport in Data and Accura- BIG IoT Service
RQF-NG-56 MRS) Wolfsburg and Berlin. cy Provider
VMZ Routing The service shall handle all georef- 1.2 Functionality -
Service (APP- erenced information in WGS84 Data and Accura- BIG IoT Service
RQF-NG-57 MRS) format. cy Provider
The service shall be able to use
VMZ Routing Charging Station Availability Data 1.2 Functionality -
Service (APP- (location, plug type, voltage and Data and Accura- BIG IoT Service
RQF-NG-58 MRS) availability status). cy Provider
VMZ Routing The service shall be able to use 1.2 Functionality -
Service (APP- Parking Spot Availability Data (lo- Data and Accura- BIG IoT Service
RQF-NG-59 MRS) cation and availability status). cy Provider
The service shall provide data on
Charging Station Charging Station Availabilities to
Availability Service VMZ Routing Service via the BIG 1.3 Functionality - BIG IoT Service
RQF-NG-60 (SRV-CS_AS) IoT API. Interoperability Provider
Charging Station
Availability Service The service shall provide data via 1.3 Functionality - BIG IoT Service
RQF-NG-61 (SRV-CS_AS) the BIG IoT API. Interoperability Provider
Charging Station The service shall use data of charg-
Availability Service ing stations provided by VMZ TIC 1.3 Functionality - BIG IoT Service
RQF-NG-62 (SRV-CS_AS) Platform. Interoperability Provider
Charging Station The service shall provide ist data to
Availability Service the Commuter App via the BIG IoT 1.3 Functionality - BIG IoT Service
RQF-NG-63 (SRV-CS_AS) API. Interoperability Provider
Charging Station
WMS Service The service shall provide WMS tiles 1.3 Functionality - BIG IoT Service
RQF-NG-64 (SRV-CS_WMS) to the BIG IoT API. Interoperability Provider
Commuter App The app shall use the VMZ Routing 1.3 Functionality - BIG IoT Service
RQF-NG-65 (APP-CA) Service for routing functionalities. Interoperability Provider
Live bus location The app shall be able to present
app (APP- the bus location on a map together 1.3 Functionality - BIG IoT Service
RQF-NG-66 APP_LBL) with bus routes. Interoperability Provider
Live bus location The app shall use the information
app (APP- provided by the Live bus location 1.3 Functionality - BIG IoT Service
RQF-NG-67 APP_LBL) service (BIG IoT API). Interoperability Provider
© 2017 53

(FOCUS-D)
Live bus location The service shall provide the infor-
service (SRV- mation according to the BIG IoT 1.3 Functionality - BIG IoT Service
RQF-NG-68 SRV_LBL) API. Interoperability Provider
Live bus location The service shall be able to include
service (SRV- information of bus routes and 1.3 Functionality - BIG IoT Service
RQF-NG-69 SRV_LBL) schedules. Interoperability Provider
Live bus location The service shall use data from the
service (SRV- sensors on buses provided by AAU 1.3 Functionality - BIG IoT Service
RQF-NG-70 SRV_LBL) and WAG. Interoperability Provider
Parking Spot The service shall use data of park-
Availability Service ing detectors provided by Siemens 1.3 Functionality - BIG IoT Service
RQF-NG-71 (SRV-PS_AS) APM Platform. Interoperability Provider
Parking Spot
Availability Service The service shall provide data via 1.3 Functionality - BIG IoT Service
RQF-NG-72 (SRV-PS_AS) the BIG IoT API. Interoperability Provider
The service shall provide data on
Parking Spot Parking Spot Availabilities to VMZ
Availability Service Routing Service via the BIG IoT 1.3 Functionality - BIG IoT Service
RQF-NG-73 (SRV-PS_AS) API. Interoperability Provider
Parking Spot The service shall provide ist data to
Availability Service the Commuter App via the BIG IoT 1.3 Functionality - BIG IoT Service
RQF-NG-74 (SRV-PS_AS) API. Interoperability Provider
Parking Spot The service shall provide ist data to
WMS Service the Commuter App via the BIG IoT 1.3 Functionality - BIG IoT Service
RQF-NG-75 (SRV-PS_WMS) API. Interoperability Provider
Parking Spot The service shall use data of the
WMS Service Parking Spot Availability Service 1.3 Functionality - BIG IoT Service
RQF-NG-76 (SRV-PS_WMS) (PS_AS). Interoperability Provider
Parking Spot
WMS Service The service shall provide WMS tiles 1.3 Functionality - BIG IoT Service
RQF-NG-77 (SRV-PS_WMS) to the BIG IoT API. Interoperability Provider
People density
estimation in area The service shall use the on bus
service (SRV- sensors provided by AAU and 1.3 Functionality - BIG IoT Service
RQF-NG-78 SRV_PDEA) WAG. Interoperability Provider
People density
estimation in area The service shall provide the infor-
service (SRV- mation according to the BIG IoT 1.3 Functionality - BIG IoT Service
RQF-NG-79 SRV_PDEA) API. Interoperability Provider
People density
estimation on bus The service shall use the on bus
service (SRV- sensors provided by AAU and 1.3 Functionality - BIG IoT Service
RQF-NG-80 SRV_PDEB) WAG. Interoperability Provider
People density The service shall provide the infor- 1.3 Functionality - BIG IoT Service
RQF-NG-81 estimation on bus mation according to the BIG IoT Interoperability Provider
© 2017 54

(FOCUS-D)
service (SRV- API.
SRV_PDEB)
People density in The app shall use the information
area app (APP- provided by People density estima- 1.3 Functionality - BIG IoT Service
RQF-NG-82 APP_PDA) tion in area service (BIG IoT API). Interoperability Provider
Public transport The app shall use the information
load app (APP- provided by People density estima- 1.3 Functionality - BIG IoT Service
RQF-NG-83 APP_PTL) tion on bus service (BIG IoT API). Interoperability Provider
Public transport The app shall be able to include
load app (APP- information about bus routes and 1.3 Functionality - BIG IoT Service
RQF-NG-84 APP_PTL) schedules in the presentation. Interoperability Provider
The app should be able to use
parking spot availability data from
Smart Parking App TIC platform and Bosch Smart City 1.3 Functionality - BIG IoT Service
RQF-NG-85 (APP-SP_A) Platform (via BIG IoT API). Interoperability Provider
The app shall use routing function-
Smart Parking App alities of the BIG IoT Application 1.3 Functionality - BIG IoT Service
RQF-NG-86 (APP-SP_A) "VMZ Routing Service". Interoperability Provider
VMZ Routing The service shall integrate the
Service (APP- Parking Spot Availability Service 1.3 Functionality - BIG IoT Service
RQF-NG-87 MRS) via the BIG IoT API. Interoperability Provider
VMZ Routing
Service (APP- The service shall use different data 1.3 Functionality - BIG IoT Service
RQF-NG-88 MRS) sources via BIG IoT API. Interoperability Provider
VMZ Routing The service should be able to use a
Service (APP- modal router for other locations 1.3 Functionality - BIG IoT Service
RQF-NG-89 MRS) than Berlin via the BIG IoT API. Interoperability Provider
VMZ Routing The service shall integrate the
Service (APP- Charging Station Availability Ser- 1.3 Functionality - BIG IoT Service
RQF-NG-90 MRS) vice via the BIG IoT API. Interoperability Provider
VMZ Routing The service shall provide ist func-
Service (APP- tionalities to an app or application 1.3 Functionality - BIG IoT Service
RQF-NG-91 MRS) (direct connection). Interoperability Provider
VMZ Routing The service shall be able to use a
Service (APP- Modal Router for Public Transport 1.3 Functionality - BIG IoT Service
RQF-NG-92 MRS) (direct connection). Interoperability Provider
VMZ Routing The service shall be able to use a
Service (APP- Modal Router for Street traffic (di- 1.3 Functionality - BIG IoT Service
RQF-NG-93 MRS) rect connection). Interoperability Provider
All Applications, All applications, services, smart
Services, Smart objects and other data sources in
Objects and other Northern Germany Pilot shall be
Data Sources available on weekdays from 9 am 2.1 Operativeness BIG IoT Service
RQO-NG-1 (ALL-ALL) to 5 pm. - Availability Provider
RQO-NG-2 All Applications, All applications, services, smart 2.1 Operativeness BIG IoT Service
© 2017 55

(FOCUS-D)
Services, Smart objects and other data sources in - Availability Provider
Objects and other Northern Germany Pilot shall be
Data Sources available until the end of BIG IoT
(ALL-ALL) project Dec. 31, 2018.
For all end user applications in NG
Pilot that use real-time data, the
All Applications data should not be older than 10 2.2 Operativeness BIG IoT Service
RQO-NG-3 (APP-ALL_APP) minutes. - Performance Provider
In all end user apps in NG Pilot,
response time for the final result to
All Applications user requests should be within 2.2 Operativeness BIG IoT Service
RQO-NG-4 (APP-ALL_APP) appropriate time. - Performance Provider
In all end user apps in NG Pilot,
response time for the first response
All Applications to user requests should be under 5 2.2 Operativeness BIG IoT Service
RQO-NG-5 (APP-ALL_APP) seconds. - Performance Provider
For all end user services in NG
Pilot that use real-time data, the
All Services (SRV- data should not be older than 10 2.2 Operativeness BIG IoT Service
RQO-NG-6 ALL_SRV) minutes. - Performance Provider
VMZ Routing The service shall provide ist result
Service (APP- in applicable time to the requesting 2.2 Operativeness BIG IoT Service
RQO-NG-7 MRS) service. - Performance Provider
Applications in NG Pilot shall be
All Applications scalable to a user number < 2.3 Operativeness BIG IoT Service
RQO-NG-8 (APP-ALL_APP) 10.000. - Capacity Provider
All applications, services, smart
All Applications, objects and other data sources in
Services, Smart Northern Germany Pilot shall sup-
Objects and other port a number of 10 users
Data Sources simultaneously using the compo- 2.3 Operativeness BIG IoT Service
RQO-NG-9 (ALL-ALL) nent. - Capacity Provider
All Applications,
Services, Smart
Objects and other All applications in NG Pilot should
Data Sources include the increase in numbers of 2.4 Operativeness BIG IoT Service
RQO-NG-10 (ALL-ALL) smart objects involved. - Scalability Provider
All end user applications shall in-
form users on system failures,
All Applications updates and wrong user input with 2.5 Operativeness BIG IoT Service
RQO-NG-11 (APP-ALL_APP) understandable error messages. - Reliability Provider
All mobile apps in NG Pilot shall be
All Applications available via the Apple App Store 2.6 Operativeness BIG IoT Service
RQO-NG-12 (APP-ALL_APP) or Google Play Store. - Installation Provider
RQO-NG-13 All Applications All mobile apps in NG Pilot shall be 2.6 Operativeness BIG IoT Service
© 2017 56

(FOCUS-D)
(APP-ALL_APP) referenced from the BIG IoT Mar- - Installation Provider
ketplace.
All services developed within the
BIG IoT Project shall be registered
All Services (SRV- and available for discovery on the 2.6 Operativeness BIG IoT Service
RQO-NG-14 ALL_SRV) BIG IoT Marketplace. - Installation Provider
All web applications in NG Pilot
All Applications shall be available on Firefox and 2.7 Operativeness BIG IoT Service
RQO-NG-15 (APP-ALL_APP) Chrome web browsers. - Portability Provider
All mobile apps in NG Pilot shall be
All Applications available for iOS or Android Sys- 2.7 Operativeness BIG IoT Service
RQO-NG-16 (APP-ALL_APP) tems. - Portability Provider
Commuter App The app shall be available at least 2.7 Operativeness BIG IoT Service
RQO-NG-17 (APP-CA) for Android 4.2 and iOS 8. - Portability Provider
Commuter App The app shall be available for the 2.7 Operativeness BIG IoT Service
RQO-NG-18 (APP-CA) latest version of Android and iOS. - Portability Provider
Smart Parking App The app shall be available for the 2.7 Operativeness BIG IoT Service
RQO-NG-19 (APP-SP_A) latest version of Android and iOS. - Portability Provider
Smart Parking App The app shall be available at least 2.7 Operativeness BIG IoT Service
RQO-NG-20 (APP-SP_A) for Android 4.2 and iOS 8. - Portability Provider
All end user apps in NG Pilot shall
allow users to revoke their consent 3.1 Compliance -
All Applications and uninstall the app, and delete Laws and Regula- BIG IoT Service
RQC-NG-1 (APP-ALL_APP) data where appropriate. tions Provider
ask for user consent once before
retrieving or place personal infor-
mation on or from the device (e.g.
Location, Unique Device Identifier, 3.1 Compliance -
All Applications Identity of the data subject, Identi- Laws and Regula- BIG IoT Service
RQC-NG-2 (APP-ALL_APP) ty). tions Provider
provide well defined and compre-
hensive purposes of the data
processing (why is which data 3.1 Compliance -
All Applications stored / used / processed) in the Laws and Regula- BIG IoT Service
RQC-NG-3 (APP-ALL_APP) app. tions Provider
provide purposes of the data pro-
cessing in advance to installation of 3.1 Compliance -
All Applications the app, not being changed without Laws and Regula- BIG IoT Service
RQC-NG-4 (APP-ALL_APP) renewed consent. tions Provider
All end user apps in NG Pilot avail- 3.1 Compliance -
All Applications able on mobile devices shall not be Laws and Regula- BIG IoT Service
RQC-NG-5 (APP-ALL_APP) provided for usage in vehicle while tions Provider
© 2017 57

(FOCUS-D)
driving.
All end user apps in NG Pilot shall 3.1 Compliance -
All Applications provide a single point of contact for Laws and Regula- BIG IoT Service
RQC-NG-6 (APP-ALL_APP) the user (imprint). tions Provider
provide a readable, understandable 3.1 Compliance -
All Applications and easily accessible privacy policy Laws and Regula- BIG IoT Service
RQC-NG-7 (APP-ALL_APP) to the user. tions Provider
provide information about mecha-
nisms to exercise their rights of
access, rectification, erasure and 3.1 Compliance -
All Applications their right to object to data pro- Laws and Regula- BIG IoT Service
RQC-NG-8 (APP-ALL_APP) cessing. tions Provider
provide comprehensive information 3.1 Compliance -
All Applications if data will be used for third party Laws and Regula- BIG IoT Service
RQC-NG-9 (APP-ALL_APP) purposes. tions Provider
Objects and other Northern Germany Pilot should 3.1 Compliance -
Data Sources comply with European data protec- Laws and Regula- BIG IoT Service
RQC-NG-10 (ALL-ALL) tion and privacy regulations. tions Provider
All Applications,
Services, Smart All applications and services in NG
Objects and other Pilot should protect users privacy 3.1 Compliance -
Data Sources according to local privacy regula- Laws and Regula- BIG IoT Service
RQC-NG-11 (ALL-ALL) tion. tions Provider
Objects and other Northern Germany Pilot shall com- 3.1 Compliance -
Data Sources ply with German data protection Laws and Regula- BIG IoT Service
RQC-NG-12 (ALL-ALL) and privacy regulations. tions Provider
The app shall comprehend calcu-
lated routes both through route
itineary sketches on a map and 4.2 Usability -
Commuter App through textual instructions (turning Appereance and BIG IoT Service
RQU-NG-1 (APP-CA) movements). Style Provider
Pictograms should be used for
certain directions to allow users to 4.2 Usability -
Commuter App be able to follow the correct path Appereance and BIG IoT Service
RQU-NG-2 (APP-CA) (visual assistance). Style Provider
All Applications allow the user to handle the provid- 4.3 Usability - BIG IoT Service
RQU-NG-3 (APP-ALL_APP) ed functionalities in the frontend in Ease of Use Provider
© 2017 58

(FOCUS-D)
a convenient way.
4.5 Usability -
All Applications All end user apps in NG Pilot shall Internationaliza- BIG IoT Service
RQU-NG-4 (APP-ALL_APP) be available in German language. tion Provider
All Applications,
Services, Smart
Objects and other All applications and services in NG- 4.5 Usability -
Data Sources Pilot shall be available in English Internationaliza- BIG IoT Service
RQU-NG-5 (ALL-ALL) language. tion Provider
4.5 Usability -
Smart Parking App The app shall support different Internationaliza- BIG IoT Service
RQU-NG-6 (APP-SP_A) languages to allow transferability. tion Provider
The app should be available for 4.5 Usability -
Smart Parking App German, English, Spanish and Internationaliza- BIG IoT Service
RQU-NG-7 (APP-SP_A) Italian Language. tion Provider
All Applications,
Services, Smart
Objects and other All NG Pilot applications and ser- 5.3 Safety
Data Sources vices should be protected against and Security - BIG IoT Service
RQS-NG-1 (ALL-ALL) security threats. Integrity Provider
© 2017 59
7.3 Barcelona Pilot Requirements Catalogue
The following table collects all the requirements for the Barcelona Pilot – First iteration
Table 8 - BCN-01 – BIG IoT Regional Barcelona Pilot Requirements – First iteration
Requirement- Subsystem Requirement Description Category & Stakeholder

RID Subcategory
(FOCUS-D)
Applications will seamlessly use the Functionality

RQF-BCN-08 All applications BIG IoT Applica-
proper service for the pilot site,
1.4 Interoperability tion and Service
using the service associated to the
Developer, BIG
location.
IoT Services
Applications will use BIG IoT API to Provider
access the required BIG IoT ser-
vices
Response time to user requests Operativeness

RQO-BCN-03 All applications BIG IoT Applica-
should be under 2 seconds
2.2 Performance tion User
For demo purposes it could be up to
5 seconds
All applications, in case of par- Operativeness

RQO-BCN-10 All applications BIG IoT Applica-
tial/total failure of services, shall
2.5 Reliability tion User
provide a human readable message
to users.
Information provided has to support

enough granularities to be able to
track failures.
All applications should support i18n Usability

RQU-BCN-01 All applications BIG IoT Applica-
For the project, all interfaces should 4.5 Internationaliza- tion User
be at least in English tion
Security
RQS-BCN-03 All applications Access to sensors raw data from the BIG IoT Service
applications should be restricted to 5.2 Access Protec- Provider
authorized users. Contract with tion
WorldSensing may impose some
restrictions on this.
Applications and services will use Functionality

RQF-BCN-13 All applications and BIG IoT Applica-
BIG IoT API to access BIG IoT ser-
services 1.4 Interoperability tion and Service
vices
Developer, BIG
IoT Services
Provider
© 2017 60

RID Subcategory
(FOCUS-D)
All systems related to Barcelona Operativeness BIG IoT Applica-

RQO-BCN-01 All applications and
Pilot shall be available every day tion User, BIG
services 2.1 Availability
24h x 7d. This requirement must be IoT Services
fulfilled by applications for citizens Provider
and traffic information centre/service
employees.
For demo purposes during BIGIoT

project 12h x 5d may be enough
All services should be registered Operativeness

RQO-BCN-12 All applications and BIG IoT Service
and be available for discovery on
services 2.6 Installation Provider
the marketplace
Applications will use marketplace to

discover the right service for Barce-
lona pilot
Security
RQS-BCN-01 All applications and Pilot must comply with all the com- All
services mon security & privacy
requirements.
RQS-BCN-03 All applications and Security

Access to sensors (platform) data BIG IoT Service
services
should be restricted to authorized 5.2 Access Protec- Provider
services. Contract with WorldSens- tion
ing may impose some restrictions on
this.
Application for SP/STM/GRP shall Operativeness

RQO-BCN-02 All applications and BIG IoT Service
support a number of concurrent
services for traffic 2.4 Scalability Provider
users equals or greater than the
participants
estimation of the number of con-
(SP/STM/GRP)
nected vehicles on the urban roads.
2018: 30% connected vehicles pen-

etration rate
2023: 75% connected vehicles pen-

etration rate
Operativeness
RQO-BCN-11 All infrastructure, All systems related to Barcelona all
applications and Pilot shall be available until end of 2.1 Availability
services 2018
All mobile apps shall be available for Operativeness

RQO-BCN-13 All mobile applica- BIG IoT Applica-
© 2017 61

RID Subcategory
(FOCUS-D)
tions download on official stores tion User

2.6 Installation
(i.e.Apple Store or Google Play)
All mobile apps shall be installable Operativeness

RQC-BCN-02 All mobile applica- BIG IoT Applica-
on android and optionally on IOS
tions 2.7 Portability tion Provider
All mobile apps to be used in cars Compliance

RQS-BCN-02 All mobile applica- BIG IoT Applica-
should comply with Mirrorlink, An-
tions used in cars 3.2 External and tion Developer
droidAuto or Apple CarPlay
(SP/GRP) Internal Standards
Security
RQF-BCN-14 All mobile applica- All mobile apps to be used in cars BIG IoT Applica-
tions used in cars should comply with Driver Distrac- 5.1 Safety tion Developer
(SP/GRP) tion Rules defined by SEAT
Services will use BIG IoT API to Functionality

RQO-BCN-09 All services BIG IoT Applica-
interact with Smart Object Platforms
1.4 Interoperability tion and Service
Developer, BIG
IoT Services
Provider
All services shall manage the growth Operativeness

RQO-BCN-14 All services BIG IoT Service
of the number of smart objects in-
2.4 Scalability Provider
volved.
All web applications shall support Operativeness

RQC-BCN-03 All web applications BIG IoT Applica-
these browsers:
2.7 Portability tion Developer
 Mozilla Firefox
 Google Chrome
An optionally:
 Internet Explorer
 Edge
Responsive design UI should be

encouraged
All web applications should comply Compliance

RQC-BCN-01 All web applications BIG IoT Applica-
with web standards
Portability tion Developer
 HMTL
 CSS
© 2017 62

RID Subcategory
(FOCUS-D)
 JavaScript
All applications should comply with Compliance

RQO-BCN-07 All applications BIG IoT Service
Spanish data protection regulations
3.1 Laws and regu- Provider
lation
Application for SP/STM/GRP shall Operativeness

RQO-BCN-04 Application and BIG IoT Service
support a number of concurrent
services for traffic 2.3 Capacity Provider
users equals or greater than the
participants
estimation of number of connected
(SP/STM/GRP)
vehicles on the urban roads.
2016-2018 (pilot): 10 concurrent

users (2 connected cars + 8
web/app users)
Operativeness
RQO-BCN-05 Applications and Real time data for parking availabil- BIG IoT Services
services for SP ity shouldn't be older than 10 2.2 Performance Provider
seconds
RQO-BCN-06 Applications and Operativeness

Real time data for traffic manage- BIG IoT Services
services for STM
ment shouldn't be older than 5 2.2 Performance Provider
minutes
Alarms of abnormal situations previ- Operativeness

RQF-BCN-11 Applications and BIG IoT Applica-
ously configured should be triggered
services for Traffic 2.2 Performance tion User
to the Traffic Monitoring Centre
Monitoring Centre
Operator in 30 seconds if direct data
Operator (STM)
is reported by sensors or connected
cars.
If data estimation is required from

collected data, then the overall time
should be under 10 minutes.
Functionality
RQS-BCN-10 Environment Moni- The service should return alerts
toring Service when combinations of real time 1.4 Interoperability
sensors readings are over the limit
values established previously
Security
RQF-BCN-02 Environment Moni- Data provided by the connected BIG IoT Service
toring Service cars must be properly deidentified. Provider
© 2017 63

RID Subcategory
(FOCUS-D)
5.3 Integrity
5.4 Privacy
Functionality
RQF-BCN-09 Green Route Plan- The application will implement the
ning App use cases defined in Deliverable 1.1 Use Cases
D2.2
Functionality
RQF-BCN-10 ParkFinder applica- The application will implement the
tion current functionality of SEAT Park- 1.4 Interoperability
finder 1.X but it will use the BIG IoT
API and services instead of iCity
API.
Functionality
RQS-BCN-08 Parking Availability The service should be able to offer
Service the availability of a set of parking 1.4 Interoperability
sensors in a specific area of Barce-
lona (a similar functionality to the
provided by iCity [10]).
Security
RQS-BCN-09 Parking availability Data minimization: provide (if possi- BIG IoT Service
service ble) just with free spots on a given Provider
5.3 Integrity
street, area or segment; Its size
should get a proper balance be-
5.4 Privacy
tween usability and privacy.
Security
RQF-BCN-12 Parking availability If providing data about individual BIG IoT Service
service parking spots, implement measures Provider
5.3 Integrity
to disallow continuous monitoring of
individual spots by other ser-
5.4 Privacy
vices/applications.
Functionality
RQF-BCN-01 Routing Service The service should offer best routes BIG IoT Service
based on traffic recommendations 1.4 Interoperability Provider
The application will implement the Functionality

RQF-BCN-03 Traffic Information BIG IoT Service
use cases defined in: WP5.1 Appli-
Centre tool 1.1 Use Cases Provider
cation Specification for Traffic
Information Centre tool
Given a specific area, the service Functionality

RQF-BCN-04 Traffic Monitoring BIG IoT Service
will offer a set of travel time, speed,
Service 1.2 Detailed Func- Provider
© 2017 64

RID Subcategory
(FOCUS-D)
congestion and other information at tionality

link level (where available)
The service will push notification Functionality

alarms when certain threshold is
reached for specific KPIs (such as
tionality
travel time, speed and congestion)
The service will be able to estimate Functionality

the Travel Time for a predefined pair
of Origin Destination
tionality
The Service will implement further Functionality

RQS-BCN-04 Traffic Monitoring BIG IoT Service
functionality defined in: D5.1 -
Specification for STM- Traffic Moni-
tionality
toring Service
Only services and/or applications Security

RQS-BCN-05 Worldsensing BIG IoT Platform
authorized by the UPC and
Bitcarrier, Fastprk provider
Worldsensing can connect to the 5.2 Access Protec-
and Sensefields
platforms. tion
platforms
Data collected by WiFi/Bluetooth Security

antenna (Worldsensing's bitcarrier
Service Provider
platform) should be minimized thus 5.3 Integrity
to provide with useful travel times
and speed without providing unique 5.4 Privacy
fields that correlated with other
sources may be used to track users.
If unique fields are stored as part of Security

the data collected by WiFi/Bluetooth
Service Provider
antenna (Worldsensing's bitcarrier
platform), such stored data should
be properly deidenti- 5.3 Integrity
fied/anonymized.
5.4 Privacy
Data provided by the connected Security

cars must be properly deidentified.
Service Provider
5.3 Integrity
© 2017 65

RID Subcategory
(FOCUS-D)
5.4 Privacy
The Service will implement the func- Functionality

RQS-BCN-08 Traffic Recommen- BIG IoT Service
tionality defined in: D5.1 -
dation Service 1.2 Detailed Func- Provider
Specification for STM- Traffic Rec-
tionality
ommendations Management
Service
7.4 Piedmont Pilot Requirements Catalogue
The following table collects all the requirements for the Piedmont Pilot – First iteration
Table 9 - PIE-01 BIG IoT Regional Piedmont Reqs - First iteration
Require- Subsystem Requirement Description Category & Stakehold-

ment-RID Subcatego- er
ry (FOCUS-
D)
Functionality
RQF-PIE-01 Parking Avail- A stall status shall be represented in geojson for- BIG IoT Ap-
ability Service mat as: 1.3 Data and plication User
Accuracy
stall_status_response:
{
stall_id: <>,
stall_name:<>,
updated_timestamp:<>,
position:[<>,<>],
status: <>,
group_id:<>,
group_name:<>,
group_address:<>,
location_id:<>,
location_name:<>
}
Parking status data used by this service shall be Functionality

RQF-PIE-02 Parking Avail- BIG IoT Ap-
gathered by CSI Smartdata Platform through BIG
ability Service 1.3 Data and plication User
IoT.
Accuracy
Service shall expose an API that return the last Functionality

status of all parking stalls in a rectangular area.
ability Service 1.2 Detailed plication User
© 2017 66

ry (FOCUS-
D)
Functional
Signature of API:
host/path/parkStallStatusInArea
GET Parameters:
 latMax: longitude of NE point

 lonMax: latitude of NE point
 latMin: longitude of SW point
 lonMin: latitude of SW point
Method shall return a geojson with an array of-

stall_status_response as described in RQF-PIE-
01:
{
timestamp:<>,
stalls_status_responses: [
<stall_status_response1>,
]
}
Service shall expose an API that return the last Functionality

status of all parking stalls within a distance from a
point, optionally filtering by status and ordered by
Functional
distance.
Signature of API:
host/path/parkStallStatusInRange
GET Parameters:
 lat: longitude of point

 lon: latitude of point
 distance: max distance from point
 status: FREE, OCCUPIED
 orderby: DESC, ASC (by distance)
Method shall return a geojson with an array of-

01:
{
timestamp:<>,
© 2017 67

ry (FOCUS-
D)
]
}
Service shall expose an API that returns the last Functionality

status of all parking stalls optionally filtered by
locationId and groupId and status.
Functional
Signature of API:
host/path/parkStallStatus/<locationId>/<groupId
>
GET Parameters:
 status: FREE, OCCUPIED
Note: <locationId> and <groupId> are optional
Method shall return a geojson with an array of

01:
{
timestamp:<>,
]
}
Service shall use an API from CSI Smartdata Functionality

Platform that return the last status of a specific
parking stall.
Functional
Service shall use an API from CSI Smartdata Functionality

Platform to subscribe a specific parking stall, in
order to be notified in real time when status
Functional
changed.
Big IoT platform shall expose a MQTTchannel to Functionality

RQF-PIE-08 All applications BIG IoT Ser-
acquire data from BIG IoT sensors
1.2 Detailed vice
Functional Developer
Firmware code running on air quality monitoring Functionality

station units shall be written in a language com-
1.4 Interoper- vice
© 2017 68

ry (FOCUS-
D)
pilable for multiple hardware platforms ability Developer
Air quality monitoring stations shall use wireless Functionality

narrow band and long range communication pro-
1.2 Detailed vice
tocols
Air quality monitoring stations shall be placed in a Functionality

waterproof enclosure, still permitting an adequate
1.2 Detailed vice
air circulation to the sensing units
Air quality monitoring stations shall be compared Functionality

with reference laboratory measurements and rela-
1.3 Data and vice
tive accuracy shall be estimated
Accuracy Developer
Requirements
Air quality monitoring stations shall send relative Functionality

measurements accuracy together with the data to
1.2 Detailed vice
the BIG IoT platform
Functionality
RQF-PIE-14 All applications Air quality monitoring station will measure temper- BIG IoT Ser-
ature together with pressure and CO2 since the 1.2 Detailed vice
first two are also needed to properly calibrate the Functional Developer
CO2 measurement
Functionality
RQF-PIE-15 All applications Air quality monitoring station will measure Particu- BIG IoT Ser-
late Matter (PM): at least PM10 and PM2,5 must 1.2 Detailed vice
be measured Functional Developer
Functionality
RQF-PIE-16 All applications Air quality monitoring station will measure Nitrogen BIG IoT Ser-
Dioxide (NO2) 1.2 Detailed vice
Functionality
RQF-PIE-17 All applications Air quality monitoring station MAY measure Ozone BIG IoT Ser-
(O3) 1.2 Detailed vice
Functionality
RQF-PIE-18 All applications Air quality monitoring station firmware will be up- BIG IoT Ser-
datable over the air 1.2 Detailed vice
© 2017 69

ry (FOCUS-
D)
Functionality
RQF-PIE-19 All applications Air quality monitoring station connectivity SHALL BIG IoT Ser-
be both WIFI and wired 1.2 Detailed vice
Functionality
RQF-PIE-20 All applications BIG IoT platform should allow the integration of BIG IoT Ser-
existing devices without installing any component 1.4 Interoper- vice
in its firmware. In this case the device is expected ability Developer
to export an API (this is the way most ip-cams
works)
Operativeness BIG IoT Ap-

RQO-PIE-01 All applications All systems related to Piedmont Regional Pilot
plication User
shall be available 7/24. This requirement must be 2.1 Availability
fulfilled by applications for citizens and traffic in-
formation centre/service employees
Operativeness
RQO-PIE-02 All applications All systems related to Piedmont Regional Pilot BIG IoTAppli-
shall be available until 2018 2.1 Availability cation User
Operativeness
RQO-PIE-03 Application for Application for bikers shall support a number of BIG IoTAppli-
Bikers concurrent users equals or greater than the num- 2.3 Capacity cation User
(HBN/SBS) ber of registered users to bike sharing service at
this moment.
Operativeness
RQO-PIE-04 Application for Application for SP/STM/GRP shall support a num- BIG IoTAppli-
traffic partici- ber of concurrent users equals or greater than the 2.3 Capacity cation User
pants estimation of number of vehicles on the urban
(SP/STM/GRP roads.
)
Operativeness
RQO-PIE-05 Application for Application for SP/STM/GRP shall support a peak BIG IoTAppli-
traffic partici- of concurrent users equals or greater 50 2.3 Capacity cation User
pants
(SP/STM/GRP
)
All applications shall manage the growth of the Operativeness

RQO-PIE-06 All applications BIG IoTAppli-
number of smart objects involved.
2.4 Scalability cation User
All applications, in case of failure of services, shall Operativeness

provide a human readable message to customers
© 2017 70

ry (FOCUS-
D)
cation User
2.5 Reliability
All applications, during a planned maintenance, Operativeness

shall provide a human readable message to cus-
2.5 Reliability cation User
tomers
All mobile apps shall be available for download on Operativeness

RQO-PIE-09 All mobile BIG IoTAppli-
Apple Store, Google Play and Windows Store.
applications 2.6 Installation cation User
URL for all web applications shall be available on Operativeness

the marketplace
applications 2.6 Installation cation User
All mobile apps shall be installable on android (min Operativeness

ver. will be defined in second iteration), IOS (min
applications 2.7 Portability cation User
ver. will be defined in second iteration)
All web applications shall support these browsers: Operativeness

RQO-PIE-12 All web appli- BIG IoTAppli-
cations 2.7 Portability cation User
 Internet Explorer (min ver. will be defined in
second iteration)
 Mozilla Firefox (min ver. will be defined in second
iteration)
 Google Chrome (min ver. will be defined in second
iteration)
Operativeness
RQO-PIE-13 All applications BIG IoT Platform shall allow updating of firmware BIG IoT Ser-
running on devices 2.6 Installation vice
using Over-The-Air Programming (OTAP) tech- Developer
niques
Air quality monitoring stations shall assure further Operativeness

RQO-PIE-14 All applications BIG IoT Ser-
hardware improvements and expansion. For ex-
2.4 Scalability vice
ample, I2C digital sensor interfaces shall be
Developer
available for further integrations
Air quality monitoring stations shall be based on Operativeness

low power hardware in order to guarantee compat-
2.6 Installation vice
ibility with solar powered systems
Developer
Air quality monitoring stations shall be powered Operativeness

using 12V DC input, which is compatible with most
vice
© 2017 71

ry (FOCUS-
D)
solar powered installations Developer

2.6 Installation
RQF-PIE-15 Vodafone Get predicted traffic indications computed by the Functionality BIG IoTAppli-
Mobile Analyt- Vodafone cellular network data source for a target cation User
1.3 Data and
ics Service geographical area specified in <lat, long> geodetic
Accuracy
coordinates
RQF-PIE-16 Vodafone Get more accurate traffic indications computed by Functionality BIG IoT Ap-
Mobile Analyt- aggregating forecast derived by mobile network plication User
1.3 Data and
ics Service with other sources, such as Wi-Fi or road sensors,
Accuracy
for a target geographical area specified in
<lat,long> coordinates
RQF-PIE-17 Vodafone Get the expected traffic status (forecast) for a Functionality BIG IoT Ap-
Mobile Analyt- target geographical area specified in <lat,long> plication User
1.3 Data and
ics Service geodetic coordinates and in a future target
Accuracy
ISO8601 date and time
RQF-PIE-18 Vodafone Get speed patterns for a given road segment iden- Functionality BIG IoT Ap-
Mobile Analyt- tified by Open Street Map id plication User
1.3 Data and
ics Service
Accuracy
RQF-PIE-19 Vodafone Expose interface for providing traffic status fore- Functionality BIG IoT Ser-
Mobile Analyt- cast for a target geographical area specified in vice
1.2 Detailed
ics Service <lat,long> geodetic coordinates and in a future Developer
Functional
target ISO8601 date and time
RQF-PIE-20 Vodafone Expose an interface for providing traffic status Functionality BIG IoT Ser-
Mobile Analyt- forecast for a target road segment identified by vice
1.2 Detailed
ics Service Open Street Map id and in a future target ISO8601 Developer
Functional
date and time
RQF-PIE-21 Vodafone Traffic information are exposed according to DA- Functionality BIG IoT Ser-
Mobile Analyt- TEX II standard (http://www.datex2.eu/) vice
1.3 Data and
ics Service Developer
Accuracy
RQS-PIE-01 Vodafone The web application life cycle must follow the Security BIG IoT Ser-
Mobile Analyt- OWASP guidelines for the coding, reviewing and vice
ics Service testing (www.owasp.org) Developer
RQO-PIE-17 Vodafone A web application will enable navigating Vodafone Operativeness BIG IoT Ap-
Mobile Analyt- road traffic forecast for test and demo purposes plication User
2.1 Availability
ics Service
© 2017 72

ry (FOCUS-
D)
RQO-PIE-18 Vodafone Vodafone Mobile Analytics Service will be granted Operativeness BIG IoT Ap-
Mobile Analyt- to BIG IoT partners for the solely purposes of the plication User
2.1 Availability
ics Service project, for its duration and under Vodafone prior
notification and Vodafone approval
RQO-PIE-19 Vodafone Vodafone Mobile Analytics Services will be provid- Operativeness BIG IoT Ap-
Mobile Analyt- ed with best effort plication User
2.1 Availability
ics Service
RQP-PIE-01 All Applica- Systems managing personal data have to comply Privacy BIG IoT Ser-
tions with European and Italian law (Legislative decree vice
196/2003 and related integrations) Developer
RQP-PIE-02 All Applica- App provided through public stores do not have to Privacy BIG IoT Ap-
tions contain information related to login/password to plication User
access the service, the credentials, if any, have to
be inserted by the end user during the registration
RQP-PIE-03 All Applica- The app must have disclaimer for terms and condi- Privacy BIG IoT Ap-
tions tions plication User
RQP-PIE-04 All Applica- If personal data belonging to the user are treated Privacy BIG IoT Ap-
tions (e.g. MSISDN or user location) a dedicated notifi- plication User
cation has to be provided in line privacy law
RQP-PIE-05 All Applica- The user, before using the app, has to accept Privacy BIG IoT Ap-
tions terms and conditions plication User
RQP-PIE-06 All Applica- Within client/server communication, any personal Privacy BIG IoT Ser-
tions data exchange has to be performed in a protected vice
way (e.g. HTTPS) in order to ensure confidentiality Developer
and integrity
7.5 Survey
7.5.1 Assessing technology needs to build an IoT ecosystem (Section 1/17)
This questionnaire gathers requirements of IoT stakeholders to facilitate the creation of an

Internet of Things (IoT) ecosystem of interoperating IoT platforms.
© 2017 73
The questionnaire is directed towards all stakeholders related to the IoT, e.g., IoT platform
providers or IoT application developers.
7.5.2 BIG IoT - technology for an interoperable IoT ecosystem (Section 2/17)
The questionnaire has been developed as part of the BIG IoT project.
Before you start filling this questionnaire, please take a look at the information below to get
familiar with the technological proposal of the BIG IoT project.
To get a first overview on the BIG IoT idea of creating an ecosystem of IoT platforms, please
watch the video below. Afterwards, please take a look at the figure underneath that de-
scribes the architectural overview.
Two components play a central role:
1.) BIG IoT API
This API provides various functionalities (e.g., discovery or data access). The API is imple-
mented by an IoT platform in order to join the IoT ecosystem. Having this API, it becomes
very easy for IoT applications and services to work with different IoT platforms.
2.) BIG IoT Marketplace
The marketplace allows registering IoT platforms and services. This is beneficial for provid-
ers of such components, since they can advertise their IoT offerings (e.g., live access to
locations of city buses) through the marketplace to potential consumers. Once a consumer
accesses an offering, the marketplace notices that and collects this information. This mecha-
nism allows providers to monetize their IoT offerings!
The BIG IoT approach in a nutshell

http://youtube.com/watch?v=H4Vjjvva4X8
© 2017 74
Figure 1 - Play the BIG IoT video
BIG IoT architecture overview
© 2017 75
Figure 2 - BIG IoT architecture overview
7.5.3 What is your role? (Section 3/17)
We call "IoT platform providers" such stakeholders in the IoT ecosystem, who run/operate
an IoT platform. This applies to you if you (or your organization) provides a platform that
offers access (e.g., on the Internet or internally within your enterprise) to data measured by
some sort of "thing" (e.g., temperature data gathered by weather stations). Please indicate
below whether this applies to you.
Question „Do you run/operate an IoT platform? *“

Mark only one oval
o Yes
o No
7.5.4 IoT platform providers (section 4/17)
You are an "IoT platform provider", since you (or your organization) are running an IoT plat-
form.
© 2017 76
Question „Do you provide an IoT platform that is accessible on the Inter-
net? (NO implies that it is internally deployed, e.g., on the Intranet of
your enterprise). “
Mark only one oval
o Yes
o No
Question „Does your IoT platform advertise or publish data via a Web-
based registry/catalogue? *
Mark only one oval
o Yes
o No
o Other:
Question „Does your platform provide a user interface or visualizations

of the data that it hosts? *“
Mark only one oval
o Yes
o No
o Other:
Question „Have you developed the software of your IoT platform in-
house, contracted the development, or bought an off-the-shelf IoT plat-
form solution? *“
Mark only one oval
o developed it in-house.
o contracted the development.
o bought an off-the-shelf IoT platform.
7.5.5 IoT platform developers (Section 5/17)
You are an "IoT platform developer", since you are building your own IoT platform software.
Question „In order to take part in an IoT ecosystem, would you be willing
to adapt the software of your platform to integrate it? (e.g., with a com-
mon API or marketplace) *“
© 2017 77
Mark only one oval
o Yes
o No
o Other:
Question „If YES: would you like to have an SDK/lib to help with such in-
tegration? For example, the SDK/lib would implement API calls towards
the Marketplace. „
Mark only one oval
o Yes, an SDK/lib would be helpful.

o No, I would not need an SDK/lib.
o Other:
Question „If NO: would you be interested in a dedicated "gateway ser-

vice" for your platform that interfaces with your current platform and
acts as a gateway towards the IoT ecosystem? Note: this requires you to
operate this service and adapt it to interface with your current platform.
„
Mark only one oval
o Yes, a gateway service would be an interesting means of integration.

o No, not interested in a "gateway service" to integrate with an IoT ecosystem.
o Other:
7.5.6 IoT platform buyers (Section 6/17)
Question „In order to take part in an IoT ecosystem, would you be inter-
ested in a dedicated "gateway service" for your platform that interfaces
with your current platform and acts as a gateway towards the IoT eco-
system? Note: this requires you to operate this service and adapt it to
interface with your current platform. *“
Mark only one oval
o Yes, a "gateway service" would help me.

o No, not interested in a "gateway service" to integrate with an IoT ecosystem.
7.5.7 Monetizing access to your IoT platform (Section 7/17)
© 2017 78
Question „Do you monetize the access to your IoT platform? (For exam-
ple, by charging users for the download of data) *“
Mark only one oval
o Yes
o No
o Other:
Question „If YES: would you be interested in monetizing the access via a
marketplace (e.g., BIG IoT's) and running it either on your premise or by
a third party? „
Mark only one oval
o Yes, advertising through a marketplace sounds good, but only in addition to

my platform's "marketing" functionalities.
o Yes, sounds great, I would rely on it in place of my platform's marketing func-
tionalities.
o No, a marketplace to advertise my platform's IoT offerings does not sound
good.
o Other:
Question „If NO: do you plan to monetize the access to your platform in
the near future? Would you be interested in monetizing the access via a
marketplace (e.g., BIG IoT's) and running it either on your premise or by
a third party? „
Mark only one oval
o Yes, but a marketplace does not sound good.

o Yes, using a marketplace sounds interesting.
o No, I do not plan to monetize the access.
o Other:
Question „If you are/would monetize the access to your platform, would
you charge based on "use" (e.g., per data message or per API call) or
based on a flat rate model (e.g., limits per month)? *“
Mark only one oval
o Per use
o Flat rate
o Other:
© 2017 79
Question „If you are/would monetize the access to your platform, would
you consider free access for an initial limited time or usage followed by a
pricing model? *“
Mark only one oval
o Yes
o No
o Other:
7.5.8 Integration with an IoT ecosystem (Section 8/17)
Question “Are you interested to integrate your IoT platform with an IoT
ecosystem, e.g., to increase its visibility and usage? Note: this requires
your platform (or a "gateway service" in front) to support common APIs
and advertising of its offerings (e.g., data sets) through a marketplace or
registry. „
Mark only one oval
o Yes
o No
o Other:
Question „How much time would you be willing to invest to learn and
use a common API (e.g., BIG IoT API) the first time? (e.g., to offer an ini-
tial data set of your platform on the marketplace?) Please specify an
upper bound of the initial learning phase: *“
Mark only one oval
o 1/2 day
o 1 Day
o 2 Day
o 1 Week
o Other:
Question „How much time would you be willing to invest to integrate all
of your platform's resources (data set or functions) with a marketplace?
Please specify an upper bound of a one-time integration per resource
type: „
© 2017 80
Mark only one oval
o 30 min
o 60 min
o 120 min
o Other:
Question „By integrating with an IoT ecosystem, which of the following

approaches would you prefer? *“
Mark only one oval
o wrapping my existing APIs and publishing them on the marketplace with a dif-
ferent signature compliant to the BIG IoT APIs
o publishing my existing APIs "as is" at the marketplace and adding a gateway
that implements an integration with the BIG IoT marketplace
o creating new API declarations for those offered on the marketplace and the
BIG IoT API
o Other:
7.5.9 Selling your IoT platform (Section 9/17)
Question „Are you selling your IoT platform? „

Mark only one oval
o Yes, I sell it as a product.

o Yes, I sell it as a service.
o No
o Other:
7.5.10 Security of your IoT Platform (Section 10/17)
Question “Do you require users to register to your IoT platform, in order
to access it? (e.g., to download data) *“
Mark only one oval
o Yes
o No
o Other:
Question „Do you manage access authorization to the APIs of your plat-
form? *“
Mark only one oval
© 2017 81
o Yes
o No
o Other:
Question „Which technology do you use for authorization? *“

Mark only one oval
o Custom implementation (your own identity management, IdM)

o Third party IdM/Auth systems, e.g., OAuth services as provided by Google or
Facebook
o Nothing
o Other:
7.5.11 Supported API protocols of your IoT platform (Section 11/17)
Question „Which protocols does your platform's API use? *“

Select all that apply
o MQTT
o Websocket + STOMP
o Websocket + REST
o COAP
o REST+JSON
o REST+XML
o Webservices
o XMPP
o oData
o AMQP
o Other:
7.5.12 Metadata descriptions on your IoT platform (Section 12/17)
Question “Are the data (or functions) provided through your IoT plat-
form described with metadata? If YES, are the metadata descriptions
based on known and well-defined vocabularies (e.g., standards or ontol-
ogies)? *“
Mark only one oval
o Yes
o Yes, AND: using known and well-defined vocabularies (e.g., standards or on-
tologies)
o No
© 2017 82
o Other:
Question „In your opinion: can the market be widened by utilizing com-
mon vocabularies? *“
Mark only one oval
o Yes
o No
o Other:
Question „Does your IoT platform provide semantic descriptions (e.g.,

based on ontologies) for APIs, metadata, or data structures? *“
Mark only one oval
o Yes
o No
o Other:
Question „Do you think a tool could help to define semantic descriptions
of your platform's resources to offer them on the marketplace? *“
Mark only one oval
not at all 1 2 3 4 5 Absolutely yes
Question „How much time would you be willing to invest to describe

your platform's resources for registration at a marketplace? Please speci-
fy a maximum one-time effort per resource: *“
Mark only one oval
o none
o 10 min
o 20 min
o 30 min
o Other:
7.5.13 Application / service providers (Section 13/17)
Both, applications and services in an IoT ecosystem are (data) consumers of IoT platforms.
While services provide again data or functions to other consumers, applications offer inter-
faces to end-users. An example for a service is a parking spot reservation service working on
top of a parking spot IoT platform. An example for an application is a smart parking app that
© 2017 83
can be utilized by end-users to find, reserve, and pay for parking. A provider offers (i.e. runs,
manages, etc.) an application or service. It is hereby not relevant if a particular instance is
hosted on the provider organization's own infrastructure or a 3rd party infrastructure.
Question „Are you provider of an IoT application or service? *“

Mark only one oval
o Yes
o No
o Other:
7.5.14 Application / service providers (Section 14/17)
You are a provider offering an application or service. It is hereby not relevant if a particular
instance is hosted on a provider organization's own infrastructure or a 3rd party infrastruc-
ture.
Question „Would you be interested that your application or service au-

tomatically accesses new data sources discovered at runtime? (Based on
a semantic query and without human interaction for data validation). *“
Mark only one oval
o Yes
o No
o Other:
Question „Would you be interested that your application or service au-

tomatically accesses data from different IoT platforms? (Based on a
defined context, e.g., location, costs) *“
Mark only one oval
o Yes
o No
o Other:
7.5.15 Application / service developers (Section 15/17)
Both, applications and services in an IoT ecosystem are (data) consumers of IoT platforms.
While services provide again data or functions to other consumers, applications offer inter-
faces to end-users. An example for a service is a parking spot reservation service working on
top of a parking spot IoT platform. An example for an application is a smart parking app that
© 2017 84
can be utilized by end-users to find, reserve, and pay for parking. A developer implements an
application or service.
Question „Are you developer of an IoT application or service? *“

Mark only one oval
o Yes
o No
7.5.16 Application / service developers (Section 16/17)
You are a developer implementing an application or service.
Question „Would you use an SDK/Lib to get easy access to the IoT eco-
system's marketplace (e.g., to discover offered resources) and to get
easy access to IoT platforms and services? *“
Mark only one oval
o Yes
o No
o Other:
Question „Would you use an SDK/Lib that wraps all calls to the different
IoT platforms and returns you the data in a common format? „
Mark only one oval
o Yes
o No
o Other:
Question „Would you use advanced queries (based on semantic vocabu-

laries) to discover data or functions from the IoT platforms and services?
*“
Mark only one oval
o Yes
o Yes, but only if it is easy to write queries (e.g., support through libs or tools)
o No
o Other:
© 2017 85
Question „Would you like a tool or UI on the Marketplace to help you to

define an advanced query (based on semantic vocabularies) for the re-
sources you want to discover via the marketplace? *“
Mark only one oval
o Yes
o No
Question „How much effort would you be willing to invest to adjust your
application/service to enable discovery of resources on the marketplace?
Please specify an upper boundary of time you would accept per resource
that you need to discover (assuming you have already passed the initial
learning curve): *“
Mark only one oval
o 30 min
o 60 min
o 120 min
o Other
7.5.17 Thank You! (Section 17/17)
Thank you so much for taking part in this survey and filling this questionnaire. The BIG IoT
project team greatly appreciates your efforts! Please also visit our website: http://big-iot.eu
or follow us on Twitter: https://twitter.com/BIG_IoT
© 2017 86
Figures and Tables

FIGURE 1 - PLAY THE BIG IOT VIDEO ..................................................................................................................... 75
FIGURE 2 - BIG IOT ARCHITECTURE OVERVIEW .................................................................................................... 76
TABLE 1- PRO-RQ-01 – PROJECT REQUIREMENTS – FIRST ITERATION .................................................................. 37

TABLE 2 - MKP-RQ-01 – PROJECT REQUIREMENTS – FIRST ITERATION ................................................................ 38
TABLE 3 - M2-INTERFACE-REQ – FIRST ITERATION ............................................................................................... 41
TABLE 4 - M3-INTERFACE-REQ – FIRST ITERATION ............................................................................................... 42
TABLE 5 - CONS_LIB_REQ – BIG IOT CONSUMER LIB REQUIREMENTS – FIRST ITERATION .................................. 42
TABLE 6 - PROV_LIB_REQ – BIG IOT PROVIDER LIB REQUIREMENTS – FIRST ITERATION ..................................... 44
TABLE 7 - NG-01 – BIG IOT REGIONAL NORTHERN GERMANY PILOT REQUIREMENTS – FIRST ITERATION .......... 49
TABLE 8 - BCN-01 – BIG IOT REGIONAL BARCELONA PILOT REQUIREMENTS – FIRST ITERATION ........................ 60
TABLE 9 - PIE-01 BIG IOT REGIONAL PIEDMONT REQS - FIRST ITERATION ........................................................... 66
© 2017 87

Big IoT

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Big IoT

Hochgeladen von

Copyright:

Verfügbare Formate

BIG IoT – Bridging the Interoperability Gap of the

Responsible Person and Affiliation Luca Gioppo - CSI Piemonte

Due Date / Delivery Date 30.09.2016

Reviewers Ernest Teniente - UPC, Costas Pipilas -

DEFINITIONS AND VOCABULARY .......................................................................... 7

3 BIG IOT ECOSYSTEM REQUIREMENTS ................................................. 22

5 SURVEY AND REQUIREMENTS VALIDATION ....................................... 34

6 CONCLUSION AND OUTLOOK ................................................................ 35

FIGURES AND TABLES.......................................................................................... 87

Definitions and Vocabulary

Term Meaning in Document Context [Reference to Source]

tions; a Smart Object is typically attached to or embedded inside a Physical

1.1 Scope of this Document

• the BIG IoT API,

1.2 Executive Summary

The complete list will be included as an annex to the document.

1.3 Structure of the document

In Chapter 5 are explained the Survey and the Requirements Validation.

2.1 Requirements Classification Schema

 Cultural and Political Requirements

The description of the different classes of requirements follows in next paragraphs.

2.1.1 Requirements Description for “1-Functionality” (4 in total)

1 Detailed Functional Requirements

Questions What shall the system do?

2 Data and Accuracy Requirements

Examples Each platform shall interoperate with the marketplace

Questions Who has the responsibility to do [a function]?

Examples The air quality shall be defined by the local authority

2.1.2 Requirements Description for “2-Operativeness” (7 in total)

Examples The system shall be available every workday 24h

Questions How quickly shall the system produce reports on request?

Are there peaks the system must manage?

Examples The system shall be real-time responding

Questions Which is the level of reliability needed for this system?

Examples The system shall achieve 99 percent uptime

Content Requirements about system installation and data migration.

Questions Who should install the system?

Is data conversion necessary?

Examples The system shall be available on marketplace

versions of common web systems shall the system support?

Examples The apps should be portable to all platforms involved

The apps should be available on android, iOS or windows phone smartphone

2.1.3 Requirements Description for “3-Compliance” (6 in total)

1 Laws and Regulations

2 External and Internal Standards

Content Requirements about the standards, external or internal to the organization,

Examples The system shall use coding standards

Questions Are there audit rules to comply with?

Questions Are there internal policies to comply with?

Examples Users shall respect the rules of the marketplace

Content Requirements about technologies to use, or not to use

Questions Do we need to technological choices in order to be compatible with existing

Examples The system shall run on the platforms involved

6 Cultural and Political Requirements

2.1.4 Requirements Description for “4-Usability” (7 in total)

2 Appearance and Style

Questions Shall the system be configurable by each adopting organization?

Content Requirements about the language support of the system. Internationaliza-

2.1.5 Requirements Description for “5-Safety and Security” (4 in total)

Questions Is this system safety-critical? May there be dangers to humans, or to proper-

Content Requirements about restrictions of access to the system. In case of doubt,

Examples The app shall be accessible to just public administration’s officers

Questions What sensitive information must be protected? Which measures shall be

Examples Data in the DB shall be encrypted