architectural reference model (arm) · management iot business process management security sensor...
TRANSCRIPT
Architectural Reference Model (ARM)
Presenter: Martin Bauer (NEC Europe)
IoT Forum Bled – November 2012
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
Slide 4 IoT Forum Bled – November 2012
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 Forum Bled – November 2012
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 Forum Bled – November 2012
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
IoT Forum Bled – November 2012
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
IoT Forum Bled – November 2012
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
Slide 11 IoT Forum Bled – November 2012
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
IoT Forum Bled – November 2012
Slide 13
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
IoT Forum Bled – November 2012
Slide 14
Trust, Security and Privacy Model
Security features and general layering
Communication Security
Based on Communication
Model
Functional Component Functional Component Functional Component Functional Component Functional Component
IoT Forum Bled – November 2012
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
Slide 16 IoT Forum Bled – November 2012
Several Core Views
Functional View
Information View
+ Deployment
& Operational View
Slide 17 IoT Forum Bled – November 2012
From the Functional Model…
Managem
ent
Security
Application
IoT Business Process
Management
Virtual Entity
IoT Service
Communication
Device
Serv
ice O
rganis
ation
IoT Forum Bled – November 2012 Slide 18
…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
IoT Forum Bled – November 2012 Slide 19
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
IoT Forum Bled – November 2012
Information View: Example of a hierarchical EntityType model
Slide 22 IoT Forum Bled – November 2012
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
Slide 23 IoT Forum Bled – November 2012
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
Slide 24 IoT Forum Bled – November 2012
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
IoT Forum Bled – November 2012 Slide 25
Best Practice / Guidelines
Slide 31
“Build your own Architecture”
IoT Forum Bled – November 2012
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
IoT Forum Bled – November 2012 Slide 32
Connecting it to something more familiar
IoT Forum Bled – November 2012 Slide 33
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
IoT Forum Bled – November 2012 Slide 34
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
IoT Forum Bled – November 2012 Slide 35
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
IoT Forum Bled – November 2012 Slide 36
Summary
• IoT Reference Model to promote common understanding
Domain Model
Information Model
Functional Model
Communication Model
Trust, Security and Privacy 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
IoT Forum Bled – November 2012 Slide 38
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!
IoT Forum Bled – November 2012 Slide 39
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
Slide 40 IoT Forum Bled – November 2012
Internet of Things European Research Cluster
(IERC)
Activity Chain 1 - Architecture approaches and models
IoT Forum Bled – November 2012 Slide 41
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)
IoT Forum Bled – November 2012 Slide 42
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
IoT Forum Bled – November 2012 Slide 43