architectural reference model (arm) · management iot business process management security sensor...

Architectural Reference Model (ARM)

Presenter: Martin Bauer (NEC Europe)

IoT Forum Bled – November 2012

http://www.iot-a.eu/

Overview

• Motivation

• Architectural Reference Model

• Reference Model

• Reference Architecture

• Best Practice / Guidelines

• Summary and Outlook

• Internet of Things European Research Cluster (IERC)

• AC1 - Architecture approaches and models

Slide 2 IoT Forum Bled – November 2012


FP7 IoT-A: Internet of Things Architecture

● Current IoT status

Fragmented architectures, no coherent unifying concepts, solutions exist only for application silos

No holistic approach to implement the IoT has been proposed, yet

Many island solutions do exist (RFID, Sensor networks, etc.)

In essence, there are only Intranets of Things existing

● Achieve an Internet of Things

IoT Forum Bled – November 2012 Slide 3


Vision of Architectural Reference Model (ARM)

• IoT Reference Model to promote common understanding

• High abstraction level

• Describes the aspects of the IoT domain that do not change

• Enables a general discourse on the IoT domain

• IoT Reference Architecture to describe essential building blocks and identify

design choices to deal with conflicting requirements

• Based on IoT Reference Model

• Reference for building compliant IoT architectures

• Provides views and perspectives on different achitectural aspects that are of concern to

stakeholders

• Best Practice / Guidelines to help in developing an architecture for a

specific system based on the IoT Reference Architecture

• Provide guidance for system architects



Dependencies and Model Influences

Slide 5

IoT Reference

Model

IoT Reference

Architecture

Application-

Specific

Requirements

Unified

Requirements

extrapolate

Compliant

Domain-Specific

Architectures

Business

Scenarios, Existing

Architectures &

Stakeholders

guides

define

steer

define

guides with

Best Practices

understand



IoT-A Reference Model



Reference Model (RM) Overview

• The RM provides a common understanding of the IoT

domain

• The RM contains: Domain Model

Information Model

Functional Model

Communication Model

Trust, Security and Privacy Model

Slide 7

Domain Model

Information

Model

Functional

Model

T, S&P

Model

Comm

FG Sec.

FG

Concepts explicitly

represented

Concepts as

foundations of

functional groups

Communication

Model

Information handled by

functional components



IoT-A Domain Model

Slide 8

class Domain Model

Dev ice

Physical Entity

Human User

Serv ice

On-Dev ice

Resource

SensorActuator

Network Resource

Resource

User

Passiv e Digital

Artefact

Activ e Digital

Artefact

Virtual Entity

Digital Artefact

Augmented Entity

Tag

A Virtual Entity is either an

Active Digital Artefact or a

Passive Digital Artefact.

0..*

monitors

1..*

0..*

acts on

1..*

0..*

invokes

0..*

1..*

exposes

0..*

0..*

is attached to0..*

1..*

has Information about / acts on

1..*

0..*

contains

0..1

0..*

hosts

1

0..*

contains

0..1

0..* identifies

1

0..*

contains

0..*

1

1..*

1

1

1..*

invokes / subscribes

1..*

0..*

is associated with

0..*

1..*

reads

0..*

0..*

is associated with

0..*

1..*

relates to 1

0..*

contains

0..1

*

interacts with

*

Device

Physical

Entity

User

interacts

invokes

Service

exposes

Resource

hosts

Association

Virtual

Entity

models

The DM defines the main

concepts of the Internet of

Things and the relations

between these concepts



Information Model (IM)

• The (IM) models Domain Model

concepts that are to be explicitly

represented and manipulated in the

digital world

• In addition the IM explicitly models

relations between these concepts

• The Information Model is a meta

model that provides a structure for the

information

• This structure provides the basis for

defining the functional interfaces

Slide 9

class Information Model

Attribute

attributeName

attributeType

ValueContainer

MetaData

metadataName

metadataType

metadataValue

VirtualEntity

entityType

identifier

Serv iceDescription

Association

Value

Resource

DescriptionDev ice

Description

0..1

0..*

0..* 1..*

0..*

metadata

1



class Domain Model

Dev ice

Physical Entity

Human User

Serv ice

On-Dev ice

Resource

SensorActuator

Network Resource

Resource

User

Passiv e Digital

Artefact

Activ e Digital

Artefact

Virtual Entity

Digital Artefact

Augmented Entity

Tag

A Virtual Entity is either an

Active Digital Artefact or a

Passive Digital Artefact.

0..*

monitors

1..*

0..*

acts on

1..*

0..*

invokes

0..*

1..*

exposes

0..*

0..*

is attached to0..*

1..*

has Information about / acts on

1..*

0..*

contains

0..1

0..*

hosts

1

0..*

contains

0..1

0..* identifies

1

0..*

contains

0..*

1

1..*

1

1

1..*

invokes / subscribes

1..*

0..*

is associated with

0..*

1..*

reads

0..*

0..*

is associated with

0..*

1..*

relates to 1

0..*

contains

0..1

*

interacts with

*

class Information Model

Attribute

attributeName

attributeType

ValueContainer

MetaData

metadataName

metadataType

metadataValue

VirtualEntity

entityType

identifier

Serv iceDescription

Association

Value

Resource

DescriptionDev ice

Description

0..1

0..*

0..* 1..*

0..*

metadata

1

Mapping of Domain Model Concepts to Information Model

Slide 10

Service

Virtual

Entity

Associates Virtual

Entities and Services

based on Attributes

Services provide

attribute values or

through modification of

attribute values

manipulate modelled

aspect of Physical Entity

Device

Resource


IoT Service and Virtual Entity Abstraction Levels

Physical World

IoT Service

Level

sensor

sensor

actuator

sensor sensor

Virtual entity-based

model models relevant

aspects of Physical World

Virtual

Entity

Level

IoT System

Resources

exposed as IoT

Services measure,

observe and

actuate on

Physical World

Association of IoT Services

to modelled Virtual Entities

Give me the

indoor

temperature in

Room 1.23

Example

Interactions

Give me the

value of

Temperature

Sensor 456

Set Actuator 867

To “on”

Set light level

In Room 2.57

to 15



Functional Model (FM)

Slide 12

Seru

rity

Man

ag

em

en

t

Application

IoT Business Process

Management

Virtual Entity

IoT Service

Communication

Device

Serv

ice O

rgan

izati

on

• The FM is derived from

internal and external

requirements

• In closely related to the

Reference Architecture

(see Functional Views)

• 7 Functional Groups

strongly related to:

• Domain model

• Communication Model

• Security Model



Typical Internet model

IoT specialization of the model

Communication Model

Communication in the IoT domain

model from an application point of

view AppNode: application node

GW: gateway

CP: control point

DS: data sink




Security features and general layering

Communication Security

Based on Communication

Model

Functional Component Functional Component Functional Component Functional Component Functional Component



IoT-A Reference Architecture



Overview: Reference Architecture

IoT Reference Architecture to describe essential building blocks and

identify design choices to deal with conflicting requirements

Views:

A view is a representation of one or more structural aspects of a reference

architecture that illustrates how the reference architecture can be adopted to

address one or more concerns held by its stakeholders.

Perspectives:

The issues addressed by perspectives are the nonfunctional requirements of the

architecture

{Views, Perspectives} -> Design Choices

Design Choices -> Best Practice / Guidelines



Several Core Views

Functional View

Information View

+ Deployment

& Operational View



From the Functional Model…

Managem

ent

Security

Application

IoT Business Process

Management

Virtual Entity

IoT Service

Communication

Device

Serv

ice O

rganis

ation



…To the Functional View

Serv

ice O

rganis

ation

VE Service VE & IoT

Service Monitoring VE Resolution

Business Process

Execution

Business Process

Modeling

IoT Service IoT Service

Resolution

Serv

ice

Orc

hestr

ation

Serv

ice

Com

positio

n

QoS Energy Optimisation Routing &

Addressing

Error Detection &

Correction

Flow Control &

Reliability Gateway

Management Security

Application

IoT Business Process Management

Virtual Entity

IoT Service

Communication

QoS Manager

Device Manager

Authorisation

Key Exchange &

Management

Trust & Reputation

Identity Management

Authentication

Device



LOCAL

CORE

Deployment & Operation

•Topologic considerations

• Typical subnetworks

• GWs and proxies

• IPv4 vs. IPv6

•Device considerations and

choices

• When and where to use

constrained devices?

• Access and interaction

considerations

•Service/requirement

mapping

Slide 20

Internet

Cellular Networks

Users

Cabled networks

(ethernet/DSL)

WiFi networks

RFID and WSN

Tags Sensors

Other



Information View: Example of a hierarchical EntityType model



IoT Service: SensorData

Flow Control &

Reliability

IoT Service

Communication

Device Sensor Device

Serv

ice O

rganis

ation

Management Security IoT Business Process Management

Sensor value

VE Service: Attribute

Virtual Entity

User 1 Application

User 2 User 3

Notify

Information flow: Publish/subscribe from Sensor to User



Perspectives

The issues addressed by perspectives are the nonfunctional requirements of the

architecture

The stakeholder requirements clearly show a need of addressing non-functional

requirements (~30 non-functional requirements related to systems)

“Architectural perspective is a collection of activities, checklists, tactics and

guidelines to guide the process of ensuring that a system exhibits a particular set of

closely related quality properties that require consideration across a number of the

system’s architectural views.” [Rozanski, 2005] (Definition used in D1.3)

Tailored the approach from Rozanski et. al. to IoT Systems



Some Perspectives:

• Evolution & Interoperability

The ability of the system to be flexible in the face of the inevitable change that all systems

experience after deployment, balanced against the costs of providing such flexibility

• Performance & Scalability

Concerns: processing volume, response time, responsiveness, throughput,

predictability

Techniques: performance requirements definition, performance modeling,

workload characterization

• Availability & Resilience

The ability of the system to be fully or partly operational as and when required and to

effectively handle failures that could affect system availability



Best Practice / Guidelines

Slide 31

“Build your own Architecture”



What’s the “Best Practices” activity in IoT-A about?

IoT Reference

Model

IoT Reference

Architecture

Application-

Specific

Requirements

Unified

Requirements

extrapolate

Compliant

Domain-Specific

Architectures

Business

Scenarios, Existing

Architectures &

Stakeholders

guides

define

steer

define

guides with

Best Practices

understand

Application-

Independent

Model

Platform-

Independent

Model

Architectural

Reference Model

Concrete

Architecture

Plattform-

Specific

Model

Implementation

Tra

nsfo

rma

tion

Best

Practice

Tra

nsfo

rma

tion



Connecting it to something more familiar



Scope of Best Practices

Domain-specific architecture

IoT ARM

Ma

nu

al

Ste

ps

Illu

str

atio

n

Domain-specific architecture

IoT ARM

DM usage

IM usage

CM usage

Security

FM usage

Deployment

Perspectives

Use cases

Reverse

mapping

Requirements

engineering

Design

choices

Risk

analysis



Domain-model usage & examples

Domain Model::

Augmented Entity

Domain Model::

Physical Entity

Active Digital Artefact

Digital Artefact

Domain Model::Virtual

Entity

UAV Controller :

Virtual Entity

Unmanned Aerial

Vehicle :Augmented

Entity

UAV Body :Physical

Entity

1

1..*

1

1

1..*

relates to

1

controls

«is instance of» «is instance of»«is instance of»

Automobile manufacturer data base

Vehicle registration station data base

Insurance company data base

Manufacturing land Manufacturing date ...

Plate number Model Owner nameColor ...

Plate number Model Owner name Insurance type ...

Chassis numberVE

VE

VE



Example: design choices

Majority of unified requirements non-functional

Generally map onto a perspective (architecture quality)

We provide tactics of how to achieve said perspectives

Upon translating the reference architecture into a concrete architecture

Design choices have to be made in order to achieve non-functional requirements

We detail choices an implementer will face

Example perspective: Performance & Scalability

Two of the tactics provided are

Reuse resources and results

Reduce contention via replication

Connected design choice: where to store histories (VE histories etc.)

Recommendation: both remote and locally



Summary and Outlook



Summary

• IoT Reference Model to promote common understanding

Domain Model

Information Model

Functional Model

Communication Model


• IoT Reference Architecture to describe essential building blocks and identify

design choices to deal with conflicting requirements

Views: Functional, Information, Deployment & Operation

Perspectives: Evolution & Interoperability, Performance & Scalability,

Availability & Resilience,Trust – Security - Privacy

• Best Practice to help in developing an architecture for a specific system

based on the IoT Reference Architecture



Outlook

• A final version of the ARM will be compiled as an IoT-A deliverable in

May 2013.

• Validation based on feedback required changes

• Focussing on so far underdeveloped models, views and perspectives

• Further development of the Best Practice part

• Applying it to real system architecture development exercises

• Interest: Use of IoT-A ARM by other projects!



Please provide feedback!

• Currently v2.0 of the IoT-A ARM (D1.4) available as a project

deliverable (www.iot-a.eu/public/public-documents) or direct link:

http://tinyurl.com/cnwq62o

• Feedback collection:

Everybody can provide comments at:

http://oe160.iml.fraunhofer.de/iot-a/projects/iot-a



http://www.iot-a.eu/public/public-documents













Internet of Things European Research Cluster

(IERC)

Activity Chain 1 - Architecture approaches and models


IERC Activity Chains

AC1 - Architecture approaches and models (Alessandro Bassi - IoT-A, Co-

Coordinator Martin Bauer - IoT-A)

AC2 - Naming and addressing schemes. Means of search and discovery (John

Soldatos - OPENIOT)

AC3 - Application scenarios, Pilots and Innovation (Amine Houyou - IOT@Work)

AC4 - Service openness and inter-operability issues/semantic interoperability

(Philippe Cousin, PROBE-IT, Co-Coordinator Martin Serrano - OpenIOT)

AC5 - Governance, Privacy and Security issues (Gianmarco Baldini - iCore, Co-

Coordinator Trevor Pierce)

AC6 - Standardisation and pre-regulatory research (Patrick Guillemin, Co-

Coordinator Friedbert Berens - BUTLER)

AC7 - IoT Enabling technologies (Franck Le Gall – BUTLER, Co-Coordinator

Raffaele Giaffreda - iCore)

AC8 - Cognitive Technologies for IoT (Abdur Rahim Biswas - iCore)


AC1 - Architecture approaches and models

Architecture approaches and models activity chain is focusing on defining a

global approach using the experience from multiple complementary approaches

and methodologies that are used to develop IoT architectures. This challenging

task requires more cooperation among the IERC projects and involvement of

different stakeholders. The development of the IoT architecture is an integral part of

systems engineering and significant analytical insight into the system is needed by

involving the different stakeholders in this process.

• Use IoT-A Architectural Reference Model (ARM) as a basis for discussion

• New projects utilize ARM for developing their system architecture and provide

feedback to improve the ARM

• Longer-running projects do reverse-mapping exercise and also provide feedback

regarding missing aspects

• Mapping to ARM provides basis for comparison and discussion of different

architectures communalities, differences, what needs to be done to achieve

interoperability


architectural reference model (arm) · management iot business process management security sensor...

Documents