Introduction to the

Architectural Reference Model

for the
Internet of Things

Executive Summary
Executive Summary
 This Introduction to the Archi-
tectural Reference Model (ARM)
for the Internet of Things which
is currently developed by the
project partners of the European FP7 Research
Project IoT-A shall give the reader a first
glimpse into the concepts of the ARM, its origin
Executive Summary  
Today, "Internet of Things" (IoT) is used as a catch-
phrase by many sources. This expression encom-
passes a galaxy of solutions somehow related to
the world of intercommunicating and smart objects.
These solutions show little or no interoperability
capabilities as usually they are developed for spe-
cific challenges in mind, following specific require-
ments. Moreover, as the IoT umbrella covers totally
different application fields, development cycles and
technologies used vary enormously, thus imple-
menting vertical solutions that can be labelled as
"INTRAnet of Things", rather than "INTERnet of
Things". For instance, in some fields such as manu-
facturing and logistics, communication and tagging
solutions are well established as they provide a
clear business benefit in terms of asset tracking and
supply-chain management. However, the same
solutions do not apply for other fields such as do-
motics, where business synergies could provide
services with clear added-value benefits.
While quite logical at this point, on the long run we
believe that this situation is unsustainable. As in the
networking field, where several solutions emerged
at his infancy to leave place to a common model,
the TCP/IP protocol suite, the emergence of a
common reference model for the IoT domain and
the identification of reference architectures can lead
Executive Summary
and its goals. Furthermore, this introduction
shall serve as guidance for reading the actual
documents issued by the IoT-A project as deliv-
erables. All documents and deliverables re-
ferred to in the subsequent pages are publicly
available and can be downloaded at
http://www.iot-a.eu/arm.
to a faster, more focused development and an ex-
ponential increase of IoT-related solutions. These
solutions can provide a strategic advantage to ma-
ture economies, as new business models can lev-
erage those technological solutions providing room
for economic development.
Leaving aside business considerations, and consid-
ering only the technical point of view, the existing
solutions do not address the scalability require-
ments of a future IoT, both in terms of communica-
tion between and the manageability of devices.
Additionally, as the IoT domain comprises several
different governance models, which are often in-
compatible. This leads to a situation where privacy
and security are treated on a per-case and per-
legislation basis, retro-fitting solutions to existing
designs, and this severely hampers portability, in-
teroperability and deployment.
In our vision of the Internet of Things, the interoper-
ability of solutions at the communication level, as
well as at the service level, has to be ensured
across various platforms.
This motivates, first, the creation of a Reference
Model for the IoT domain in order to promote a
common understanding.
Second, businesses that want to create their own
compliant IoT solutions should be supported by a
Reference Architecture that describes essential
building blocks as well as design choices to deal
with conflicting requirements regarding functionality,
performance, deployment and security. Interfaces
should be standardised, best practices in terms of
functionality and information usage need to be pro-
vided.
The central choice of the IoT-A project was to base
its work on the current state of the art, rather than
using a clean-slate approach. Due to this choice,
Objectives and Outline of the current version of the ARM 
The previous version v0.9 of the ARM was pub-
lished approximately one year ago as project deliv-
erable D1.2, and presented to a large audience
during the IoT week 2011 in Barcelona. As a result
we received a large number of comments, the ma-
jority of them being taken into account already in
the new version v1.5 of the ARM.
While the general objective of v1.5 is the same as it
was for v0.9, i.e., describing thoroughly an Architec-
tural Reference Model for IoT, this version of the
ARM brings to the audience substantial improve-
ments over the previous version, as summarised
below:
 All feedback received internally from IoT-A and
externally from the stakeholders was taken into
account in order to improve the document and
in order to make sure that the IoT-A architecture
work will eventually meet expectations from the
external users;
 Introduction of new views and perspectives
beyond the Functional Decomposition view and
Security Perspective touched in v0.9. V1.5
Objectives and Outline of the current version of the ARM
common traits are derived to form the base line of
the Architectural Reference Model (ARM). This
has the major advantage of ensuring backward-
compatibility of the model and also the adoption of
established, working solutions to various aspects of
the IoT. With the help of end users, organised into a
stakeholders group, new requirements for IoT have
been collected and introduced in the main model
building process. This work was conducted accord-
ing to established architecture methodology.
comes with the Deployment & Operation and In-
formation views and with the Evolution & In-
teroperability, Performance & Scalability and
Availability & Resilience perspectives. It will be
shown in the document how the Design Choic-
es applied at the view levels impact the various
quality properties attached to the system archi-
tecture materialised by the four perspectives in-
troduced above;
 First version of Best Practices and associated
Design Choices which are an initial step to-
wards an aided architecture design for concrete
system architects;
 Improvement of the soundness of the whole
ARM approach, emphasizing the logical links
existing between the various elements and sub-
models of the Reference Model and the views
and perspectives of the Reference Architecture.
Document structure  
This document just gives an introduction to the
ARM. It first explains the vision and rationale behind
it, as well as the benefits of using the ARM. There-
after the process and the methodology used to de-
velop the ARM, as well as how the ARM should be
applied when developing concrete systems, is de-
scribed.
The final section then highlights some of the main
business scenarios where the application of the
Introduction to the ARM – Vision 
Many popular “umbrella” topics like Smart Cities pull
a large number of specific application domains like
Transportation, Energy, Environment, Assisted Liv-
ing, most of the time pre-fixed with “Smart” some-
times for obvious marketing reasons but also -more
generally- in order to emphasise the fact they em-
bed a certain degree of intelligence and global
awareness. This new breed of applications exploits
IoT related technologies, however, the resulting
applications unfortunately appear as vertical silos
only, meaning specific applications with specific
architectures, with little place left for inter-system
communication and inter-operation. Actually that is
where the real issue lies: the smartness of those
new applications can only reach its pinnacle if full
collaboration between those vertical silos can be
achieved.
If we consider also the fact that IoT related technol-
ogies come with a high level of heterogeneity, with
specific protocols developed with specific applica-
tions in mind, it is no surprise that the IoT landscape
nowadays appears as highly fragmented. Many IoT-
enabled solutions exist with recognised benefits in
terms of business and social impact, however they
form what we could call a set of Intranets of Things,
not an Internet of Things!
In the vision of the Internet of Things IoT-A wants to
promote, a high level of interoperability needs to be
Introduction to the ARM – Vision
ARM is beneficial, thus also validating the useful-
ness of creating an Architectural Reference Model
for the Internet of Things.
The full ARM is downloadable from
http://www.iot-a.eu/arm.
reached at the communication level as well as at
the service and the information level, going across
different platforms, but established on a common
grounding. The IoT-A project reckons that achieving
those goals comes in two steps, first of all in estab-
lishing a common understanding of the IoT domain
(hereafter called Reference Model), and second in
providing to IoT system developers a common
foundation for building interoperable IoT system
architectures (hereafter called Reference Architec-
ture).
A Reference Architecture (RA) can be visualised as
the “Matrix” that eventually gives birth ideally to all
concrete architectures. For establishing such a Ma-
trix, based on a strong and exhaustive analysis of
the State of the Art, we need to envisage the super-
set of all possible functionalities, mechanisms and
protocols that can be used for building such con-
crete architecture and to show how interconnections
could take place between selected ones (as no
concrete system is likely to use all of the functional
possibilities). Giving such a foundation along with a
set of design-choices, based on the characterisation
of the targeted system w.r.t. various dimensions
(like distribution, security, real-time, semantics,…) it
becomes possible for a system architect to select
the protocols, functional components, architectural
options, … needed to build their IoT systems.
The main aim of IoT-A can be explained using the here, as it represent the Architectural Reference
pictorial representation shown below. Model (ARM). The ARM is the combination of the
Reference Model and the Reference Architecture,
As any metaphoric representation, this tree does
the set of models, guidelines, best practices, views
not claim to be fully consistent in its depiction; it
and perspectives that can be used for building fully
should therefore not be interpreted too strictly. On
interoperable concrete IoT architectures and sys-
the one hand, the roots of this tree are spanning
tems. In this tree, we aim at selecting a minimal set
across a selected set of communication protocols
of interoperable technologies (the roots) and pro-
(6LoWPAN, Zigbee, IPv6,…) and device technolo-
posing the potentially necessary set of enablers or
gies (sensors, actuators, tags,..) while on the other
building blocks (the trunk) that enable the creation
hand the blossoms / leaves of the tree represent the
of a maximal set of interoperable IoT systems (the
whole set of IoT applications that can be built from
leaves).
the sap (i.e., data and information) coming from the
roots. The trunk of the tree is of utmost importance The ultimate aim of the Reference Architecture

Figure 1: The IOT-A Tree

Introduction to the ARM – Vision

work is to make sure that concrete system design-
ers will eventually use it. High attention is therefore
paid to ensuring the soundness of our work. In par-
ticular this version of the ARM aims at making more
The ARM Rationale
Figure 2 shows an overview of the process we used
for defining the different parts that make the IoT-A
ARM. Notice that definitions of terms such as refer-
ence architecture, etc. can be found in an external
glossary (see www.iot-a.eu/public/terminology).
Starting with existing architectures and solutions,
generic baseline requirements can be extracted and
used as an input to the design. The IoT-A ARM
consists of four parts:
- The vision summarises the rationale for
providing an architectural reference model
for the IoT. At the same time it discusses
underlying assumptions, such as motiva-
tions. It also discusses how the architectur-
al reference model can be used, the meth-
odology applied to the architecture model-
Figure 2: IoT-A architectural reference model building blocks.
explicit the various links existing between the vari-
ous models, views and perspectives, so that it will
make the work of systems designers easier.
ling, and the business scenarios and stake-
holders addressed.
- Business scenarios defined as require-
ments by stakeholders are the drivers of
the architecture work. With the knowledge
of businesses aspirations, a holistic view of
IoT architectures can be derived. Further-
more, a concrete instance of the reference
architecture can be validated against se-
lected business scenarios. A stakeholder
analysis contributes to understanding which
aspects of the architectural reference model
need to be described for the different
stakeholders and their concerns. According
to common usage, this part constitutes a
subset of the vision.
 - The IoT Reference Model provides the
highest abstraction level for the definition of
the IoT-A Architectural Reference Model. It
promotes a common understanding of the
IoT domain. The description of the IoT Ref-
erence Model includes a general discourse
on the IoT domain, an IoT Domain Model
as a top-level description, an IoT Infor-
mation Model explaining how IoT infor-
mation is going to be modelled, and an IoT
Communication Model in order to under-
stand specifics about communication be-
tween many heterogeneous IoT devices
and the Internet as a whole. The definition
of the IoT Reference Model is conforming to
the OASIS reference model definition.
- The IoT Reference Architecture is the ref-
erence for building compliant IoT architec-
tures. As such, it provides views and per-
spectives on different architectural aspects
that are of concern to stakeholders of the
IoT. The terms view and perspectives are
used according to the general literature and
Benefits of using the ARM
Using the IoT-A ARM can provide many benefits.
We list here the most important ones.
Cognitive aid 
When it comes to product development and other
activities, an architectural reference model is of
fourfold use.
First, it aids in guiding discussions, since it provides
a language everyone involved can use, and which
is intimately linked to the architecture, the system,
the usage domain, etc.
Benefits of using the ARM
standards The creation of the IoT Refer-
ence Architecture focuses on abstract sets
of mechanisms rather than concrete appli-
cation architectures.
To organisations, an important aspect is the com-
pliance of their technologies with standards and
best practices, so that interoperability across organ-
isations is ensured. If such compliance is given, an
ecosystem forms, in which every stakeholder can
create new businesses that “interoperate” with al-
ready existing businesses. The IoT-A ARM provides
best practices to the organisations so that they can
create compliant IoT architectures in different appli-
cation domains. Those IoT architectures are in-
stances from the Reference Architectures with
some architectural choices (called later on Design
Choices) like considering strong real-time or choos-
ing strong security features, etc. They form thus
special “flavours” of the IoT Reference Architecture.
Where application domains are overlapping, the
compliance to the IoT Reference Architecture en-
sures the interoperability of solutions and allows the
formation of new synergies across those domains.
Second, the high-level view provided in such a
model is of high educational value, since it provides
an abstract but also rich view of the domain. Such a
view can help people new to the field with under-
standing the particularities and intricacies of IoT.
Third, the architectural reference model can assist
IoT project leaders in planning the work at hand and
the teams needed. For instance, the Functionality
Groups identified in the functional view of the IoT
system can also be understood as a list of inde-
pendent teams working on an IoT system imple-
mentation.
Fourth, the architectural reference model aids in
identifying independent building blocks for IoT sys-
tems. This constitutes very valuable information
when dealing with questions like system modularity,
processor architectures, third-vendor options, re-
use of already developed components, etc.
IOT‐A Reference Model as a common ground 
Establishing a common ground for a field is not an
easy task. To be effective, such a ground has to
capture as many pertinent vantage points as possi-
ble. Establishing the common ground encompasses
the definition of IoT entities and describing their
basic interactions and relationships with each other.
The Architecture Reference Model is providing ex-
actly such a common grounding for the IoT field.
Any party envisaging to develop an IoT system that
is IoT-A compatible must build on the common con-
cepts provided in the IoT-A Reference Model.
Generation of architectures 
Another benefit is the use of the IoT-A ARM for the
generation of compliant architectures for specific
systems. This could be done by enabling tool sup-
port. The benefit of such a generation scheme for
IoT architectures is not only the automatism of this
process, and thus the saved R&D efforts, but that
the generated architecture will provide intrinsic in-
teroperability of the derived IoT systems.
Process and Architecture Methodology
This Section provides a meta-perspective of IoT-A
process, viz. a look at how the IoT ARM model was
derived. It also explains the basic process how con-
crete systems can be developed by using the ARM
First, we need to understand why the reference
architecture derived needs to be accompanied by a
Identifying differences 
When using the aforementioned system-generation
tools, which are based on the IoT-A ARM, any dif-
ferences in the derived architectures can be at-
tributed to the particularities of the pertinent use
case. When applying the IoT-A ARM, predictions of
system complexity, etc. are available for the system
parts to be implemented. That makes judging the
overall implementation effort for use case imple-
mentation easier, and some projects that might not
have been realised due to uncertainties in the pro-
ject plan might become possible. The overall im-
plementation effort is most certainly less than de-
veloping an architecture without the help of an ar-
chitectural reference model.
Benchmarking 
Another important use is benchmarking. For exam-
ple, NASA used a reference architecture of its new
exploration vehicle for better benchmarking tenders
it was going to receive during a public bidding pro-
cess. While the reference model prescribes the
language to be used in the systems/architectures to
be assessed, the reference architecture states the
minimum (functional) requirement on the sys-
tems/architectures. By standardising the description
and also the ordering and delineation of system
components and aspects, it also provides a high
level of transparency and inherent comparability to
the benchmarking process.
reference model, before we discuss how the parts
of the IoT ARM have been developed.
Introduction 
Through the development of an architecture, a solu-
tion to a pre-defined goal is found. The develop-
ment and description of architectures in turn is a
modelling exercise. In this respect it is important to
point out that the modelling itself does not happen
in a vacuum, but rests on a thorough understanding
of the domain modelled. In other words, any archi-
tecture development is contingent on one’s under-
standing of the domain in question. The same is
true for a generalisation of this process, viz. the
derivation of reference architectures. Thus, refer-
ence architectures also have to be based on a de-
tailed understanding of the domain in question. This
understanding is commonly provided in the form of
a reference model.
The above discourse motivates why the IoT Refer-
ence Architecture is accompanied by a thorough
discussion of the IoT domain in the form of an IoT
Reference Model. However, this high-level view
does not explain how one derives either. What is
needed here are both a process and a methodology
for deriving the parts of the ARM. The process de-
scribes what steps need to be undertaken during
the derivation of the architectural reference model,
and the methodology describes how these steps
are achieved. In other words, the methodology de-
scribes how to identify the tasks attached to each
development step, and how and in which order to
conduct these steps. Both the process and the
methodology description are provided in this Sec-
tion.
The remainder of the text in this Section is organ-
ised as follows. To start with, we provide a short
discussion of the particularities of reference archi-
tectures and how they relate to concrete architec-
tures, and also how they relate to reference models.
This information enables us to discuss what high-
level actions and input is needed for the derivation
of an ARM, and what input is needed in order to
guide the transformation of the reference architec-
ture into use-case- and application-specific architec-
Process and Architecture Methodology
tures. With this knowledge at hand we dive into the
details of the development process. First, we re-
state the goals of IoT-A and how we translated
them into a step-by-step process. Second, we ex-
plain how concrete architectures can be generated
from the ARM. Next, we discuss the methodologies
available for conducting each step. As it turns out,
there is no standardised methodology for the deri-
vation of ARMs. In order to overcome this lack of
ARM methodology, we assessed the well-equipped
toolboxes for the development of use-case- and
application-specific architectures instead. Since
these methods intrinsically rely on the specificity of
the pertinent use cases and application scenarios, it
is found that the methods considered, for instance
model-driven engineering cannot always be applied
one to one. This Section concludes with a detailed
discussion of our requirements process, which is at
the heart of our entire architecture process.
Reference model and reference architec‐
ture 
Reference models and reference architectures pro-
vide a description of greater abstraction than what
is inherent to actual systems and applications. They
are more abstract than system architectures that
have been designed for a particular application with
particular constraints and choices. From the litera-
ture, we can extrapolate the dependencies of refer-
ence architecture, architectures, and actual systems
(see Figure 3).
Architectures do help in designing, engineering,
building, and testing actual systems. At the same
time, understanding system constraints better can
provide input to the architecture design, and in turn
this allows identifying future opportunities. The
structure of the architecture can be made explicit
through an architecture description, or it is implicit
through the system itself.
By extracting essentials of existing architectures,
like mechanisms or usage of standards, a reference
architecture can be defined. Guidance in form of
best practices can be associated to a reference
architecture in order to derive use-case-specific
architectures from the reference architecture (see
Figure 4). Such guidance can, for instance, make
new architectures and systems compliant to each
other. These general architecture dependencies
apply to the modelling of the IoT domain as well.
While the model presented in Figure 3 stops at the
reference architecture, the IoT-A architectural refer-
ence model goes one step beyond and also defines
a reference model. As already discussed earlier, a
reference model provides the grounding for a com-
mon understanding of the IoT domain by modelling
its concepts and their relationships.
Actions and inputs  ence model are stakeholder concerns, business
In the previous Section we discussed how reference
architectures relate to architectures and real sys-
tems. In order to derive such a reference architec-
ture and the reference model upon which the refer-
ence architecture builds, one needs better how they
relate to each other and to external input. Such a
Figure 3: Relationship between a reference architecture, architectures, and actual systems (adapted
from literature).
Process and Architecture Methodology
taxonomy already provides us with a high-level
perspective of actions and inputs needed for devel-
oping an ARM for IoT.
Best Practice
Figure 4: Relation of an architectural reference
model, best practice, and concrete architectures.
A high-level taxonomy of how we understand the
reference-architecture process is depicted in Figure
5. As discussed earlier, the IoT Reference Model
provides guidance for the description of the IoT
Reference Architecture. The Best Practice guides
the derivation of IoT-A-compliant domain-specific
architectures from the reference architecture.
Essential inputs for the definition of the IoT refer-
scenarios, and existing architectures. It is important
to create a common understanding of the IoT do-
main from the different inputs. This is mainly a
modelling exercise, during which experts have to
work together and extract the main concepts and
their relations of the IoT domain from available
knowledge.
Furthermore, business scenarios, existing architec-
tures, and stakeholder concerns can be trans-
formed into application-specific requirements. When
extrapolated, these requirements lead to a set of
unified requirements. Unified requirements in turn
steer the definition of the IoT Reference Architec-
ture.
Within the ARM, the IoT Reference Model guides
the definition of the IoT Reference Architecture,
creating dependencies between the Reference
Architecture and the Reference Model; once a
change is proposed in the Reference Model a clear
chain of dependencies can be followed and lead to
subsequent changes within the Reference Architec-
ture. By so doing, an overall consistency of the IoT-
A ARM is maintained.
As one can see, this high-level representation al-
ready identifies high-level actions for the derivation
of the ARM and for domain-specific architectures
(“understand”, “define”, etc.). However this view is
still too abstract for being of use in the day-to-day
development work of the project. What is needed is
a detailed architecture process that identifies indi-
Figure 5: High-level representation of the IoT-Reference-Model and IoT-
Reference-Architecture dependencies and model influences.
Process and Architecture Methodology
vidual tasks within the development process, that
provides insight in the dependencies of said tasks,
and that provides a dynamic model of the develop-
ment process itself (viz. what step follows after the
next).
Overall process 
ARM development 
A process-based view of the ARM derivation is
shown in Figure 6. The ARM development process
consists of one main process, which is the ARM
derivation. Within the ARM derivation two actions
are worth mentioning, viz. the domain modelling,
which results in the IoT Reference Model, and the
functional modelling, which is the main contributor
to the IoT Reference Architecture. This process
receives input from the requirement-collection pro-
cess, which in turn receives input from external
stakeholders and the state-of-the-art surveys con-
ducted during the early stages of IoT-A.
The work in the ARM-derivation process is present-
ed as an ARM draft. The initial ARM draft v0.9 was
presented in deliverable D1.2.
The ARM draft guides the setup- up of the public
use-case demonstrations as well as the work of the
technical work packages within IoT-A (“technical
analysis”).
The ARM draft is reviewed by the project’s external
stakeholders, the demonstration activity, as well as
the technical work packages. This review serves as
input for a revision of the ARM. In other words, the
IoT-A project follows the well-established spiral
design and prototyping model. The result from the
first iteration of this development cycle is the current
document, viz. ARM version v1.5. Before the con-
clusion of the project two more iterations are
planned, resulting in v1.6 and v1.7, respectively.
Besides the architecture and domain analysis we
also provide the user of the ARM with best practices
for deriving use-case- and application-specific archi-
tectures (see Figure 6). Besides being of benefit for
the user of the ARM, this process has the side ben-
efit of providing valuable feedback to the ARM deri-
vation itself. When devising guidelines for translat-
ing the ARM into a specific architecture, potential
gaps and inconsistencies are revealed. Also, the
best-practice exercise deepens our understanding
of the IoT domain, and provides additional guidance
on what aspects of the ARM need further en-
hancement. Last but not least, studying the transla-
tion of ARM into specific architectures and vice
versa provides a compelling validation of the use-
fulness of the ARM.
The spiral-model approach inherent in the ARM
development process was chosen for the following
reasons. Firstly, each new iteration of the process
increases the stability of the ARM. Secondly, due to
its multi-step nature, the dissemination of the (em-
bryonic) ARM starts early within the project. Thanks
to early publication corrective impulses from peers
and external stakeholders are received timely in the
development process and can thus positively influ-
ence both the applicability of the ARM as well as its
acceptance. Third, this approach formalises and
coordinates the interaction of the architecture activi-
ty within IoT-A with that of the other activities (tech-

<<guides>>
Technical analysis

«input»
«input»
«guides»
Demonstrator
implementation

ARM development

ARM rev iew

«input»
«resource» «input» Stakeholders
ARM draft
«input»
«input»
«input»
Best practice

«output» Requirement collection

«input»
ARM deriv ation
«input» «input»
Domain modelling

«information»
State of the art

Functional modelling

Figure 6: Dynamic view of the IoT-A ARM process.

Process and Architecture Methodology

nical analysis and demonstrator set up), which is
expected to enhance the efficacy of this exchange.
Generation of architectures 
So far we have only described the genesis of the
IoT-A ARM, but not how its use for the generation of
specific architectures actually works. While Figure 4
explains that the Best Practice accomplishes the
transformation from the IoT ARM to a concrete ar-
chitecture, the detailed picture is actually more
complex.
When applying the ARM in the design of systems, it
is likely that different architectures will result subject
to the desired properties of the system. So, the
best-practice transformation depicted in Figure 4
relies on a use-case description and requirements.
This fact is reflected in Figure 8. The role of the
ARM is to guide the architect through design choic-
es at hand, and to provide best practices and de-
sign patterns for those different choices. The ARM
is not operating in a design vacuum but should be
applied together with proven design-process prac-
tices.
When designing concrete systems, one needs to
keep in mind that in practice this will not always be
the case. Depending on the engineering strategies
used, some of the steps can be done in parallel or
even have to be reiterated due to additional under-
standing gained during the process, or due to
changes in the requirements.
Choice of design and development methodology  Figure 9.
The choice of a design and development methodol-
ogy can be understood in two ways: first, a method-
ology for the ARM development and second, a
methodology for generating specific architectures.
We have so far only provided high-level views of
either case. In reality one needs more guidance,
viz. a recipe on how to derive all aspect of the ARM
Process and Architecture Methodology
model as well as how to derive the best practices.
Simply dissecting them into design steps and pro-
cesses is not enough; one needs to know how to
achieve each step.
In the case of the ARM there are, to our knowledge,
no standardised approaches for developing such a
model. Furthermore, the IoT usage domain is, com-
pared to typical reference-architecture domains,
extremely wide and varied, and common denomina-
tors are thus rather few and abstract. This high level
of abstraction in terms of the domain to be modelled
stands in contrast to input needed for established
and standardised methodologies such as, for in-
stance, Aspect-Oriented Programming, Model-
Driven Engineering, Pattern-Based Design, and
SysML. All these methodologies were designed for
very concrete use cases and application scenarios.
Unfortunately, this high degree of specificity is even
defining their inner workings. In other words, if one
applies them to generalised use cases, one does
often not get generalised models on the abstract
level of an ARM as desired, since the processes of
which said methodologies are constituted do not
work for generalised use cases.
We illustrate the above issue with two examples,
Model-Driven Engineering (MDE) and Pattern-
Based Design (PBD). In the first case, the method-
ology is not directly applicable, while, in the second
case, the methodology can potentially be general-
ised for deriving the best-practice transformation in
Model-Driven Engineering for the generation of
Model-Driven Architectures is standardised by the
Object Management Group. Its application area is
the development of software systems. It provides an
approach for, first, specifying a system inde-
pendently from the platform; second, specifying
platforms; third, choosing a particular platform for
 «resource»
IoT Architectural
Reference Model

«guides via Best

Practice»

«information»
Use Cases & «resource»
Requirements System Design Concrete
«input» «output» Architecture

«guides»

«resource»
Engineering Strategies

Figure 8: Process for the generation of concrete architectures.

the system; and fourth, transforming the system
specification into that of a particular platform. The
goals behind this approach are portability, interop-
erability, and reusability through the architectural
separation of concerns. So, on the face of it, all this
sounds very similar to the goals of our ARM devel-
opment process.
In Figure 7, the main idea of model-driven architec-
ture is shown. A platform-independent model, viz.
an architecture, is to be transformed into a platform-
specific model, viz. an implementation. An example
for the former is a GUI user interface described in
UML, and the latter
Figure 7: Generalised architecture approach
according to the Model-Driven-Architecture
methodology, a.k.a. Model-Driven Engineering.
phone model featuring a particular operation sys-
tem.
While this sounds very much like the Best-Practice
transformation depicted in Figure 4, it is not the
same. This becomes clearer in Figure 9.
Figure 9 is pieced together from Figure 4 (ARM)
and Figure 7 (Model-Driven Engineering). As one
can see, both the ARM and the Model-Driven-
Engineering approach are linked to each other
through platform-independent models, but they
reside on different levels of abstraction. While the
general idea of a model transformation, as promot-
ed by MDE, resonates with our ARM approach (see
Figure 4), the methodology developed for the deri-
vation of transformations between platform-
independent and platform-specific models can, up-
on a thorough analysis, not be transferred and
adapted for the derivation of Best-Practice trans-
formations.

is an implementation of said interface in a cell-

Process and Architecture Methodology

Pattern-Based Design is a technique that reuses ARM.
repeatable solutions to solve commonly occurring
Methodology Aspect adopted in our work
problems. In this design method one records how
Aspect- Delineation of functionalities by aspects. This
object-oriented designers identify recurring design Oriented Pro- is embodied in the concept of Functionality
problems. The corresponding solutions are then gramming Groups

documented, and a reuse of the solutions is strived Model-Driven General concept of transformation from a
Engineering generic to a more specific model. We use this
for. Consequently, the design process becomes concept for describing and developing our
increasingly flexible, elegant, and, most important, Best Practice.

reusable. The solutions are divided into Sub- Pattern-Based We will test the efficacy of this method upon
Design deriving a concrete architecture as a best-
solutions, where “A design pattern identifies the practice test case.
participating classes and instances, their roles and
Views and We adopt the concept of views and perspec-
collaborations, and the distribution of responsibili- Perspectives tives for the derivation of the IoT Reference
Architecture, viz. we arrange all aspects of
ties. Each design pattern focuses on a particular our reference architecture according to views
object-oriented design problem or issue”. From this and perspectives). The same is done for the
unified requirements.
short discussion it becomes clear that (a) Pattern-
Table 1: Usage of standardised architecture
Based Design was developed for implementation methodologies for the development of the IoT ARM.
processes, viz. the transformation to the right in
Requirements process 
Figure 9, and that (b) the only way this method can
The IoT Reference Model by itself does not specify
be applied for the derivation of the best-practice
the technical particularities of an IoT system. For
transformation in the same Figure would be by try-
example, how are things identified and addressed in
ing to translate the ARM into a particular architec-
an IoT context? Or: how are these things associat-
ture and to see whether the “book-keeping” ap-
ed with services? Such particularities are addressed
proach prescribed by Pattern-Based Design yields
in the IoT Reference Architecture. In order to build
valuable insight. At the current stage we do not
such a reference architecture, we not only need the
know whether this is possible and aim at finding out
IoT Reference Model and the methodology to do so,
during on-going best-practice development, which,
but also technical requirements that can be used for
among others, encompasses the derivation of a
inferring particularities of the architecture. This is
concrete architecture.
reflected in Figure 5.
In Table 1 we summarise how we use ideas bor-
In this Section we explain how the requirements for
rowed from standardised architecture methodolo-
the IoT ARM have been inferred. The collection of
gies for our work on the higher abstract level of an

Figure 9: Relation of the Best-Practice-driven derivation of concrete architectures

form an architectural reference model and the derivation of implementations from
said concrete architecture.

Process and Architecture Methodology

requirements was done in a three-pronged process:
1. The rich experience and knowledge of the
project partners guided the derivation of a
minimum-requirement list, which also had a
major influence in drafting the Reference
Modelmodel. The state of the art concern-
ing thing-centric communication and Inter-
net technologies was considered, and a list
of internal requirements was deduced.
2. A group of external IoT stakeholders was
established and queried for their use cases
and their expectations toward IoT. They
were also asked for their objectives, con-
cerns, and business goals. As far as feasi-
ble, these overarching aspirations were
broken down into requirements.
Usually, such stakeholder aspirations are not made
as system requirements, rather as use-case specific
goals. Therefore, each stakeholder aspiration was
thoroughly analysed, and suitable translations into
requirements were sought. Stakeholder aspirations
can be rather general (strategic objectives, con-
cerns, or business goals) or they can be very spe-
cific, i.e., a stakeholder spells out what kind of func-
tionality or performance she/he needs. An example
for the former is the functionality of the IoT systems.
For instance, European Telecommunications
Standards Institute ETSI raised the following con-
Business Scenarios validating the ARM
Business scenarios play an important role in the
external validation of the Architectural Reference
Model (ARM). Business scenarios help defining
application-specific requirements, i.e., they are one
source of input regarding what potential systems
and applications need to implement and deliver, if
they are to realise certain business scenarios. At
Business Scenarios validating the ARM
cern: “Today, due to sub-optimal processes, a lot of
time and money is wasted. This situation could be
improved a lot by tracking all the items/things,
providing context data on them at any time and
location, allowing for automated evaluation of the
collected data and reacting immediately on a dan-
gerous situation to protect against the breakdown-
break-down of items.” This addresses the functional
view, but it does not clearly address what function-
alities are needed in order to meet this aspiration. In
our requirement-engineering process, we broke this
concern down into two distinct functional require-
ments.
 “The system shall enable centralized or de-
centralized automated activities (control
loops).”
 “The system shall enable the planning of
automated tasks.”
The above example was provided in order to briefly
illustrate our requirement process. The functional
view is a recurring item in the list of unified require-
ments. This view is represented as a block-diagram
in the IoT Reference Architecture, which in itself
constitutes a central result of the IoT-A project and
an indispensable input for the development of a
compliant IoT system.
the same time, business scenarios help under-
standing the IoT Reference Model as such, as the
domain components described in the reference
model are reflected in the respective business sce-
narios, i.e. the reference model provides a formal-
ised and abstracted model of the entities and their
relationships that are brought to life within the dif-
ferent business scenarios.
Rationale and Introduction  tegic objectives, such as future-proof, low-
The primary aim of business scenarios is to provide
an external validation of the ARM in economic
terms, i.e., business scenarios should demonstrate
that concrete systems built utilising concrete ARM
compliant architectures are economically viable and
beneficial, so that it makes sense for business
stakeholders to develop business scenarios based
on IoT-A models and best practices. Ideally, busi-
ness scenarios should cover a diverse set of rele-
vant application fields in order to demonstrate the
broad applicability of IoT-A, especially since one of
the primary goals of IoT-A is to develop an IoT Ref-
erence Architecture that transforms the isolated
island solutions of the “intranets of things” as we
know them today into a domain-spanning interop-
erable infrastructure of IoT platforms that is viable
from an economic point of view and facilitates novel
business opportunities.
Due to limited space, we will here only briefly dis-
cuss the main application fields for which viable
business scenarios compliant to IoT-A can be de-
veloped, and then focus only on one central appli-
cation field in the focus of the project, namely the
retail domain.
The narrowed focus of the use cases comes from
the fact the stakeholder group of the IoT-A project
focuses mostly on selected application fields. With-
in these fields, stakeholder aspirations can of
course be diverse, because of differences in their
background and differences in their business views.
Nevertheless, there are some common themes in
stakeholder aspirations that make us confident that
there is some potential for generalizing business
scenarios:
Business Scenarios validating the ARM
o Many stakeholders see IoT as a means of
improving their current business. IoT will
thus serve various business goals and stra-
ered costs, etc.
o Other stakeholders see IoT as a disruptive
technology, which will aid them in creating
new applications and thus new business
opportunities (selling access to sensor da-
ta, etc.).
o In order to achieve a maximum of flexibility
of IoT technology and its use, short prod-
uct-development cycles, and a maximum
leverage of existing and new solutions to
common problems is needed. For that rea-
son, many stakeholders advocate open IoT
platforms and frameworks. The underlying
business goal for this advocacy is to lower
costs in product development. Strategic ob-
jectives are to enhance product interopera-
bility and to shorten the development cy-
cles. The latter is important for responding
to customers’ emerging needs in an agile
manner.
o Since active supervision of IoT interactions
is even more elusive than monitoring to-
day’s Internet traffic, security and privacy
have, as expected, been identified as a
core topic. Privacy is strongly related to the
overall acceptance of IoT. If individuals and
other users cannot experience a sufficient
level of privacy when utilising IoT technolo-
gy, this will critically challenge the ac-
ceptance of this novel technology. Security
equates of course not only to privacy, but
also to the protection of the IoT against in-
terferences, such as service attacks, tro-
jans, viruses, etc.
Fields of Application  cooperate in the user’s home, such as Internet
In order to maximise the impact of our architectural
reference model, we have to identify those scenari-
os where IoT technologies have a special rele-
vance, taking into account that these scenarios
frequently share the same applications, sensors,
stakeholders and, of course, users. We will base
this identification on scenarios that have been kind-
ly provided by the IoT-i1 project.
Transportation/ Logistics  are , encompassing economy, people, governance,
In transport logistics, IoT improves not only material
flow systems, but also global positioning and auto-
identification of freights. Additionally, it increases
energy efficiency and decreases thus energy con-
sumption. In conclusion, IoT is expected to bring
profound changes to the global supply chain via
intelligent cargo movement. This will be achieved
by means of continuous process synchronisation of
supply-chain information, and seamless real-time
tracking and tracing of objects. It will provide the
supply chain a transparent, visible and controllable
nature, enabling intelligent communication between
people and cargo.
Smart home  
Future smart homes will be conscious about what
happens inside a building, mainly impacting three
aspects: resource usage (water conservation and
energy consumption), security, and comfort. The
goal with all this is to achieve better levels of com-
fort while cutting overall expenditure. Moreover,
smart homes also address security issues by
means of complex security systems to detect theft,
fire or unauthorized entries. The stakeholders in-
volved in this scenario constitute a very heteroge-
neous group. There are different actors that will
1
See http://www.iot-i.eu/
Business Scenarios validating the ARM
companies, device manufacturers, telecommunica-
tions operators, media-service providers, security
companies, electric-utility companies, etc.
Smart city 
While the term smart city is still a fuzzy concept,
there is a general agreement that it is an urban
area which creates sustainable development and
high quality of life. Important areas of a smart city
mobility, environment and living. Outperforming in
these key areas can be done through strong human
or social capital and/or ICT infrastructure. For the
latter, a first business analysis concludes that sev-
eral sectors/industries will benefit from more digital-
ised and intelligent cities (examples for a city of 1
million people2:
 Smart metering, 600.000 meters, US $ 120
million opportunity
 Infrastructure for charging electric vehicles,
45.000 electric vehicles, US $ 225 million
opportunity
Remote patient monitoring (diabetes),
70.000 people, US $ 14 million opportunity
 Smart retail, 4.000 stores, US $ 200 million
opportunity
 Smart-bank branches, 3.200 PTMs, US $
160 million opportunity
Smart factory 
Companies will be able to track all their products by
means of RFID tags in a global supply chain; as a
consequence, companies will reduce their opera-
2
Cf. R. Nicholson, “Smart Cities: Proving Ground for the Intelli-
gent Economy”, 2010
tional expenditure and improve their productivity
due to a tighter integration with enterprise resource
planning and other systems. Generally, IoT will
provide automatic procedures that imply a drastic
reduction in the number of employees needed.
Workers will be replaced by bar-code scanners,
readers, sensors and actuators, and in the end by
complex robots that are as efficient as a human.
Without any doubt, these technologies will bring
opportunities for white-collar workers and a big
number of technicians will be necessary to program
and repair these machines. This is synonymous to
a transfer to maintenance jobs, but it also consti-
tutes a new challenge for providing all blue-collar
workers with an opportunity to move toward these
types of jobs and to avoid unemployment.
Retail  first stakeholder session of IoT-A. It is worth men-
IoT realises both customer needs and business
needs. Price comparison of a product; or looking for
other products of the same quality at lower prices,
or with shop promotions gives not only information
to customers but also to shops and business. Hav-
ing this information in real time helps enterprises to
improve their business and to satisfy customer
needs.
Obviously, big retail chains will take advantage of
their dominant position in order to enforce the future
IoT retail market, as it happened with RFID adop-
tion, which was enforced by WalMart in 2004. Par-
ticularly, companies with controlling positions, such
as WalMart, Carrefour, Metro AG, etc. are able to
push the adoption of IoT technology due to their
sizeable market power.
e‐Health 
Controlling and preventing is one of the main goals
of future health care. Already today, people can
have the possibility of being tracked and monitored
by specialists even if both are not at the same
Business Scenarios validating the ARM
place. Tracing peoples’ health history is another
aspect that makes IoT-assisted eHealth very versa-
tile. Business applications could offer the possibility
of medical service not only to patients but also to
specialists, who need information to proceed in
their medical evaluation. In this domain, IoT makes
human interaction much more efficient because it
not only permits localization, but also tracking and
monitoring of patients. Providing information about
the state of a patient makes the whole process
more efficient, and also makes people much more
satisfied.
The most important stakeholders in this scenario
will be public and private hospitals and institutes
such as, e.g., the Institute of Applied eHealth at
Edinburgh Napier University, which partook in the
tioning that telecommunications operators are quite
active in e-health (for instance, O2 UK).
Environment 
Applications in the environmental domain have
many overlaps with other scenarios, such as smart
home and smart city. The key issue in these sce-
narios is to detect means that help to save energy.
One prominent example is Smart Grid. Concerning
this application area one needs to highlight initia-
tives that imply a more distributed energy produc-
tion, since many houses have a solar panel today.
As a vital part, smart metering is considered as a
pre-condition for enabling intelligent monitoring,
control, and communication in grid applications.
The use of IoT platforms in Smart Metering will
provide the following benefits:
 An efficient network of smart meters allows
for faster outage detection and restoration
of service. Such capabilities redound to the
benefit of customers
  Provides customers with greater control Business Case Methodology 
over their energy or water consumption, As demonstrated above, there is a huge potential
providing them more choices for managing for realising IoT applications in different application
their bills. fields that are based on architectural concepts of
IoT-A and potentially bring novel business opportu-
 IoT deployment of smart meters is ex-
nities, for instance when sensor technology contrib-
pected to reduce the need to build power
utes to changing distribution models for perishable
plants. Building power plants that are nec-
goods, so that e.g. fruits or vegetables can still be
essary only for occasional peak demand is
sold to the consumer before their quality deterio-
very expensive. A more economical ap-
rates and the goods are wasted. However, in order
proach is to shape the demand by either to
to make such scenarios possible large investments
incentivize customers to reduce their de-
are needed in, e.g., hardware, software, installation,
mand through time-based rates or other
configuration, maintenance, business process
programs, or by service-level agreements
reengineering and training of personnel. To justify
that allow temporarily turning off devices
such investments, a ‘business case’ (BC) is usually
which are not needed (e.g., the freezer for
developed, describing the benefits, costs and risks
20 minutes).
of each investment alternative.

In order to describe a well-defined business model

BCs commonly appear as spread-sheets, often
it is necessary to define what needs to be done in
accompanied by presentations or explanatory doc-
the business, which are the metrics for success,
uments. They may be presented by the project
which are the problems that must be solved and the
leader (BC ‘owner’ or ‘champion’) to senior man-
plans that solve these problems. Knowing which
agement, which is responsible for prioritizing BCs
part of the problem is possible to solve and how
and making investment decisions. This way, the BC
much time is needed and which part cannot be
can be used to decide about investment before
solved is an important step that we must take into
project execution (‘ex-ante’), to evaluate progress
account when we develop concrete business cases
during project execution and to determine to what
for some of the application fields discussed above.
extent the proposed value of the investment has

As we can only go into the details of one business been realized after project execution (‘ex-post’).

case in the context of this document, we will pick a Naturally, the development of BCs is a complex

use case from the application field of retail, as this task. First, collecting, transforming and aggregating

is a central application field for the project, and the required information demands interdisciplinary

apply an appropriate business case methodology to teamwork and expertise in a wide range of fields

it. This methodology is outlined in the next section. such as business strategy, business operations

The use of a methodology instead of merely calcu- (‘work practice’), information technology, account-

lating “some kind of business case” enables us to ing and project management. Second, BCs are

perform comparisons between different application based on assumptions concerning the future devel-

fields, for instance when we consider health under opment of certain variables. Predicting those varia-

an economic perspective within the context of the bles requires accurate data and reliable analysis

forthcoming deliverables. methods. Third, BCs are subject to a constantly

Business Scenarios validating the ARM

changing business environment, requiring an agile
BC development process to adapt to these chang-
es.
Within the context of IoT-A, BCs should be based
on a generic BC process to allow for their develop-
ment, use and improvement across different appli-
cation fields. We therefore base the BC process on
a framework that is being developed in the IoT pro-
3
ject SemProM that proposes a BC framework
which is based on a generic BC process, consisting
of six steps: Scope, Processes, Criteria, Methods,
Results, Conclusion. During this process, domain-
specific components consisting of criteria and
methods may be reused.
The BC framework provides a set of spread-sheets
in Microsoft Excel that accompany the process
proposed. In the following section, we apply this
framework to two of the primary retail use cases of
IoT-A, namely the NFC Based Shopping Assistant
in combination with the sensor- based quality con-
trol.
Retail Business Case  optimization strategies has always been crucial. In
The use case shows how IoT technologies like
sensor technologies built into consumer electronic
devices and NFC tags coupled with the Internet of
Things Architecture can provide useful meta-
information to the customer to enhance the overall
shopping experience and at the same time signifi-
cantly reduce the costs for consulting that sales
personnel in the retail stores need today, as there
are no such systems in widespread use. The use
case demonstrates a direct human-to-machine
interaction.
From a business perspective, the use case is pri-
marily interesting because the NFC-based product
3
http://www.semprom.de/
information has the potential to reduce the consul-
tation time of the sales personnel in the store.
In order to make the business case somewhat more
complex, we also integrate the sensor based quality
control use case and assume that both scenes are
interconnected, because they are based on a
common architecture, namely a concrete architec-
ture based on the IoT-A Reference Architecture.
The sensor based quality control scene shows how
sensors monitor perishable goods in a store. De-
pending on the luminance, humidity, and tempera-
ture of the environment, the estimated future quality
of the perishable products is determined and prices
are reduced even before a perceivable degradation
of quality occurs. By applying this sensor based
quality control and combining it with dynamic pric-
ing, it is ensured that the goods are sold before
quality degradation is likely to occur. From a busi-
ness and industry perspective, the scene demon-
strates two important retail-related concepts: Dy-
namic pricing and quality control of perishable
goods. Dynamic pricing as a real-time tool for price
contrast to the state of the art, dynamic pricing in
the featured use case is not performed on static
information such as best-before dates in the
backend ERP system, but it is based on real time
IoT data gathered from a sensor infrastructure. As
about 20% of perishable goods never reach the
consumer, but are disposed of before, the utilization
of IoT sensors is also an interesting concept to
implement quality control of perishables and thus
reduce waste and increase profits at the same time.
As we have stated before, we assume that both the
self-contained NFC-based product information and
the sensor based quality control are based on the
same technical system realised in accordance with
the IoT-A ARM. Therefore, we calculate their antici-

Business Scenarios validating the ARM

pated effects in a combined business case. The
actual Excel sheets are available on the IoT-A web-
site at www.iot-a.eu, but in the following tables we
already provide some of the respective criteria, on
which the calculations are based, as well as instan-
tiations of these criteria calculated for cases, when
the IoT-A -based use cases are realised and when
they are not realised (= the baseline).
In our calculations we base our BC on an example
case for German Retailers trading fast moving con-
sumer goods (FMCG) in a higher market segment.
The following two tables outline the respective pa-
rameters used.
Table 2: Sample Instantiations for the Retail
Table 3: Criteria for the Retail Business Case
Business Scenarios validating the ARM
The core result of the business case calculation for
the retail domain is that, apart from the reduced
waste of perishables due to the sensor based quali-
ty control, the consulting time of sales personnel
being reduced significantly, in our case about 30%,
so that IoT-based scenarios indeed appear to have
a significant business impact. For the detailed re-
sults, please consult the respective spread-sheet.
The business case as we have calculated it for a
retailer from the FMCG field does not yet take into
account the savings and benefits of software sys-
tems that are compliant with the IoT-A Reference
Architecture and that follow the best practices and
design choices laid out by the IoT-A project. While
we envision the best practices to be a strong and
central contribution of the project, it is currently hard
to calculate its economic impact.
Conclusions & Outlook 
Apart from the best practices, we also believe that
substantial economic benefits can emerge from the
modular and component-based approach to build-
ing IoT systems that are compliant with the IoT-A
Reference Architecture. These additional business
effects will also be taken into account for future
business cases.
While we can already state that from an economic
perspective the IoT-A approach simply makes
sense, it is also important to note that solid busi-
ness scenarios are only a precondition to the appli-
cation of the ARM. In order to implement Internet of
Things use cases based on the IoT-A Reference
Architecture, the project aims at providing much
more than just the Reference Architecture itself and
an economic validation: The business cases are
just one building block towards a fully featured
“Cook book” with information on various aspects
concerning the implementation of IoT systems. It
will provide best practices for the various modules
that the ARM comprises and will discuss design
choices that academics and practitioners alike will
be faced with when implementing concrete systems
based on IoT-A.
Conclusions & Outlook
The latest project deliverable D1.3 already includes
lavish sections on design choices and best practic-
es that will be further augmented and refined in
order to develop an easily accessible guide for
implementation that will certainly have an impact
beyond the IoT-A partners and the projects in the
IERC cluster. Our leitmotif was and remains to pro-
vide the industry standard for implementing future
IoT systems based on a modular, common ap-
proach and an accessible, yet sophisticated, refer-
ence architecture.
Please follow our activities towards the concretiza-
tion of the ARM and the best practices on working
with the ARM by visiting our website at www.iot-
a.eu and getting the latest version of the ARM. In
order to give feedback and help shaping future
versions of the ARM and the best practices for im-
plementation, please make sure to get in touch with
us and our stakeholder group about which you can
also find information on our website.
Imprint 
Editors:

Sebastian Lange (VDI/VDE-IT), Andreas Nettsträter (Fraunhofer IML), Stephan Haller (SAP), Francois Carrez
(University of Surrey), Alessandro Bassi (Hitachi)

Authors:

Martin Bauer (NEC), Nicola Bui (Consorzio Ferrara Ricerche), Francois Carrez (University of Surrey),
Pierpaolo Giacomin (Hitachi), Stephan Haller (SAP), Edward Ho (University of St.Gallen), Christine Jardak
(Siemens), Jourik De Loof (Alcatel-Lucent), Carsten Magerkurth (SAP), Andreas Nettsträter (Fraunhofer IML),
Alexandru Serbanati (Sapienza University of Rome), Matthias Thoma (SAP), Joachim W. Walewski (Sie-
mens), Stefan Meissner (University of Surrey)

Imprint