iot-a ierc ac1 expert workshop 15./16. april 2013, heidelberg

IoT-A IERC AC1 Expert Workshop

15./16. April 2013, Heidelberg

General Introduction and Goals ofIoT-A Architectural Reference Model

(ARM)

Martin Bauer, NEC Europe

Slide 2IoT-A Workshop @ Bosch – 13th March 2013

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

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



Purpose of Architectural Reference Models

1) Cognitive aid: common language, common concepts – how can I talk about different architectures

2) Reference model as a common grounding – how can I structure research, development etc. of an architecture – what aspects do I need to cover? – what people do I need?

3) Generation of architectures – how can I create an architecture that fits my needs? – what are the design choices?

4) Identifying differences and commonalities in derived architectures – which architecture should I choose? – what do I need to do when integrating systems based on different architectures? – where are the crucial points?

5) Benchmarking – how can I compare different architectures? – what are the functionalities? – what are the respective qualities?



Structure of IoT-A 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

• Guidelines to help in developing an architecture for a specific system based on the IoT Reference Architecture

• Provide guidance for system architects



Methodology: Dependencies and Model Influences


IoT Reference Model

IoT Reference Architecture

Application-Specific

R equirements

Unified Requirements

extrapolate

Compliant Domain-Specific

Architectures

Business Scenarios, Existing

Architectures & Stakeholders

guides

define

steer

define

guides throughGuidelines

understand


Development and evolution

Slide 7

e-p ARM Process

ARM development

ARM deriv ation

«resource»ARM draft

Requirement collection

Technical analysis

Stakeholders

«information»State of the art

Demonstrator implementation

Best practice

Domain modelling

Functional modelling

ARM rev iew

«input»

«input»

«guides»

«output»

«input»

<<guides>>

«input»

«input»

«input»

«input»«input»

«input»

«input»

IoT-A Workshop @ Bosch – 13th March 2013


Connecting the dots: generation of architectures



Platform-Independent

Model

Plattform-SpecificModel

Transform

atio

n

Model-Driven EngineeringARM Guidelines

Application-Independent

Model

Transform

atio

n

Architectural Reference Model

ConcreteArchitecture Implementation

From Architectural Reference Model to Concrete Architecture and Implementation



Things are of course a bit more complicated



ARM Purpose 1 – Cognitive aid: common language, common concepts

Device

PhysicalEntity

User

interacts

invokes

Service

exposes

Resource

hosts

VirtualEntity

modelsSmartPhone :Dev ice Location Serv ice :

Serv ice

GPS Sensor :Sensor Location :On-Dev ice Resource

Tracking App :Activ e Digital Artefact

John :Physical Entity

contains

hosts exposes

hosts

relates to

useshosts

is attached to

has location information about

Domain Model(Example)

Use C

oncepts

to S

pecify

Mai

n IoT E

lem

ents

IoT-A Workshop @ Bosch – 13th March 2013Slide 11

Association


OperationSpecialists

Architects

Modelling Specialists

ARM Purpose 2 – Reference model as a common grounding

Slide 12

Domain

Information

Functional

Operation

Deployment

timel

ine

Planning and

Organizing



ARM Purpose 3 – Generation of architectures

Slide 13

Topic

Design Choice

Impact onSecurity &

Privacy

Performance &

Scalability

Availability &

Resilience

Evolution & Interoperability

IoT Business Process Management/

Application support

DC1.1 Business Process Modelling according to

BPMN 2.0

+/- + + +

DC1.2 Business Process Execution by BPMN 2.0

execution engine

+/- + + +

Service Organisation DC2.1 Service Orchestration with mandatory security

+/- 0 + 0

DC2.2 Service Orchestration with optional

security

- 0 - 0

VE Resolution DC3.1

VE Resolution with mandatory security

+/- 0 + 0

DC3.2 VE Resolution with optional security

- 0 - 0

DC3.3 VE Resolution with QoS

0 0 + 0

DC3.4 VE Resolution domain-oriented

+ + + +

DC3.5 VE Resolution location-oriented

- + +/- +/-

DC3.6 Resolution Semantic Web-oriented

0 0 + +/-

DC3.7 Resolution Peer-to-Peer-oriented

0 + + 0

Design Choices

Architecture Creatio

n

Process

Guidelines(Examples)



ARM Purpose 4 – Identifying differences and commonalities in architectures

(Reverse Mapping + Comparison)

Slide 14

Serv

ice O

rganis

ati

on

VE ServiceVE & IoT

Service MonitoringVE Resolution

Business ProcessExecution

Business ProcessModeling

IoT ServiceIoT ServiceResolution

Serv

ice

Orc

hest

rati

on

Serv

ice

Com

posi

tion

QoSEnergy OptimisationRouting & 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

Data CaptureDevice

(i.e. RF Reader)

Data CaptureDevice Management(i.e. RF Reader Mngt)

Filtering & Collections

EPCISCapturing Application

EPCIS Repository

EPCIS Accessing Application

Local ONSONS i/f

Reader Mngt i/f

Air protocol

Reader i/f

Application Level Event i/f

EPCIS Capturing i/f

EPCIS Query i/f

End User A

Discovery Services ONS RootEPC Network Services


End User B

EPCIS Query i/f

Discovery i/f Discovery i/f

RFID Tag

Objects

Places

Ucode

Ucode

User Terminal

Ucode Resolution

Server

Application Information

Servcie

Functional View(Example)

Mapping Architecture

Functions to Functional

View of ARM



ARM Purpose 5 – Benchmarking

Serv

ice O

rganis

ati

on

VE ServiceVE & IoT





Serv

ice

Orc

hest

rati

on

Serv

ice

Com

posi

tion




Gateway

Management Security

Application


Virtual Entity

IoT Service

Communication

QoS Manager

Device Manager

Authorisation


Trust & Reputation

Identity Management

Authentication

Device

Data CaptureDevice

(i.e. RF Reader)

Data CaptureDevice Management(i.e. RF Reader Mngt)

Filtering & Collections

EPCISCapturing Application

EPCIS Repository


Local ONSONS i/f

Reader Mngt i/f

Air protocol

Reader i/f

Application Level Event i/f

EPCIS Capturing i/f

EPCIS Query i/f

End User A

Discovery Services ONS RootEPC Network Services


End User B

EPCIS Query i/f

Discovery i/f Discovery i/f

RFID Tag

Functionalities# Functional Groups addressed# Functional Components covered

Qualities addressed + Level Evolution and Interoperability: +Availability and Resilience: -Security and Privacy: --Performance and Scalability: +

Evolution and Interoperability

Availability and Resilience

Security and Privacy

Performance and Scalability

Benchmarking for

high-level

comparison



IoT-A Reference Model

Carsten Magerkurth, SAP



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 17

Domain Model

InformationModel

Functional Model

T, S&PModel

CommFG Sec.

FG

Concepts explicitlyrepresented

Concepts asfoundations offunctional groups

Communication Model

Information handled byfunctional components



Reference Model –Different Parts and Their Relations


Domain Model: Core concepts of IoT and their relations - independent of specific technologies

Device

PhysicalEntity

Service

exposes

Resource

hosts

Association

VirtualEntity

models

Attribute

attributeNameattributeType

ValueContainer

MetaData

metadataNamemetadataTypemetadataValue

VirtualEntity

identifierentityType

Serv iceDescription

Association

Value

Resource Description

Dev ice Description

0..* 1..*

1

0..*

metadata

0..1

0..*

Information Model: structure (e.g. relations, attributes) of all the information (data) that is handled in an IoT system

Functional Model: Functionalgroups of an IoT system and theirrelations

Communication Model: IoT channelmodel and communication functionalities

Trust, Security and PrivacyModel: Respective concepts in the context of IoT


IoT-A Domain Model

Slide 19

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..*

hosts1

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

PhysicalEntity

User

interacts

invokes

Service

exposes

Resource

hosts

Association

VirtualEntity

models

The DM defines the main concepts of the Internet of Things and the relations between these concepts



IoT Domain model according to IoT-A

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

Animate objects (humans, animals etc.)

Hardware

Software

Not clearly classifiable (e.g., combination)

Colour Scheme

XOR

0..*

contains

0..1

0..*

interacts with

0..*1

1

1..*

relates to 1

0..*

is associated with

0..*

0..*

contains

0..*

0..* identifies

0..10..*

is associated with

0..*

0..*

hosts1

0..*

contains

0..1

1

1..*

0..*

contains

0..1

0..*

invokes

0..*

0..*


1..*

0..*


0..*

0..*

reads

0..*

0..*

monitors

0..*

0..*

acts on

0..*

0..*

is attached to0..*

0..*

exposes

0..*

Slide 20


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 21

class Information Model

Attribute


ValueContainer

MetaData


VirtualEntity

entityTypeidentifier

Serv iceDescription

Association

Value


Dev 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

Passive Digital Artefact

Active 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..*


1..*

0..*contains

0..1

0..*

hosts1

0..*

contains

0..1

0..* identifies

1

0..*

contains

0..*

1

1..*

1

1

1..*


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


ValueContainer

MetaData


VirtualEntity

entityTypeidentifier

Serv iceDescription

Association

Value


Dev ice Description

0..1

0..*

0..* 1..*

0..*

metadata

1

Mapping of Domain Model Concepts to Information Model

Slide 22

Service

VirtualEntity

Associates Virtual Entities and Services based on Attributes Services provide attribute values or through modification ofattribute values manipulate modelled aspect of Physical Entity

Device

Resource


IoT Service and Virtual Entity Abstraction Levels

Physical World

IoT ServiceLevel

sensor

sensor

actuatorsensor

sensor

Virtual entity-based model models relevantaspects of Physical World

Virtual EntityLevel

IoT System

Resourcesexposed as IoTServices measure,observe andactuate onPhysical World

Association of IoT Servicesto modelled Virtual Entities

Give me theindoor

temperature inRoom 1.23

ExampleInteractions

Give me thevalue of

TemperatureSensor 456

Set Actuator 867To “on”

Set light levelIn Room 2.57

to 15



Functional Model (FM)

Slide 24

• 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



Later: Detailing the Functional Model in the “Functional View”

Serv

ice O

rganis

ati

on

VE ServiceVE & IoT





Serv

ice

Orc

hest

rati

on

Serv

ice

Com

posi

tion




Gateway

Management Security

Application


Virtual Entity

IoT Service

Communication

QoS Manager

Device Manager

Authorisation


Trust & Reputation

Identity Management

Authentication

Device



Typical Internet model

IoT specialization of the model

Communication Model

Communication in the IoT domain model from an application point of viewAppNode: application nodeGW: gatewayCP: control point DS: data sink



Trust, Security and Privacy Model

Security features and general layering

Communication Security

Based on Communication Model

Functional ComponentFunctional ComponentFunctional ComponentFunctional ComponentFunctional Component



IoT-A Reference Architecture

Martin Bauer, NEC Europe



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…

Man

ag

em

ent

Secu

rity

Application


Virtual Entity

IoT Service

Communication

Device

Serv

ice

Org

an

isati

on



…To the Functional View

Serv

ice O

rganis

ati

on

VE ServiceVE & IoT





Serv

ice

Orc

hest

rati

on

Serv

ice

Com

posi

tion




Gateway

Management Security

Application


Virtual Entity

IoT Service

Communication

QoS Manager

Device Manager

Authorisation


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 33

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

IoT Service

Communication

DeviceSensor Device

Serv

ice O

rganis

ati

on

Management

Security

Application


Sensor value

VE Service: Attribute

Virtual Entity


Information flow from Device to VirtualEntity Attribute



IoT Service: SensorData


IoT Service

Communication

DeviceSensor Device

Serv

ice O

rganis

ati

on

Management

SecurityIoT Business Process Management

Sensor value

VE Service: Attribute

Virtual Entity

User 1Application 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 & ResilienceThe ability of the system to be fully or partly operational as and when required and to effectively handle failures that could affect system availability



iot-a ierc ac1 expert workshop 15./16. april 2013, heidelberg

Documents

iot reference model

structure of iot

goals of iot

fp7 iot

compliant iot architectures

model influences slide

implementation slide

evolution slide