Presentation is loading. Please wait.

Presentation is loading. Please wait.

IoT-A IERC AC1 Expert Workshop

Similar presentations


Presentation on theme: "IoT-A IERC AC1 Expert Workshop"— Presentation transcript:

1 IoT-A IERC AC1 Expert Workshop
15./16. April 2013, Heidelberg

2 Martin Bauer, NEC Europe
General Introduction and Goals of IoT-A Architectural Reference Model (ARM) Martin Bauer, NEC Europe Slide 2 IoT-A Bosch – 13th March 2013

3 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-A Bosch – 13th March 2013

4 Purpose of Architectural Reference Models
Cognitive aid: common language, common concepts – how can I talk about different architectures 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? Generation of architectures – how can I create an architecture that fits my needs? – what are the design choices? 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? Benchmarking – how can I compare different architectures? – what are the functionalities? – what are the respective qualities? Slide 4 IoT-A Bosch – 13th March 2013

5 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 Slide 5 IoT-A Bosch – 13th March 2013

6 Methodology: Dependencies and Model Influences
IoT Reference Model Architecture Application - Specific R equirements Unified Requirements extrapolate Compliant Domain Architectures Business Scenarios, Existing Architectures & Stakeholders guides define steer guides through Guidelines understand Slide 6 IoT-A Bosch – 13th March 2013

7 Development and evolution
IoT-A Bosch – 13th March 2013

8 Connecting the dots: generation of architectures
Guidelines! ARM Concrete architecture Slide 8 IoT-A Bosch – 13th March 2013

9 From Architectural Reference Model to Concrete Architecture and Implementation
Application - Independent Model Transformation Architectural Reference Model Concrete Architecture Transformation Implementation Platform - Plattform - Independent Specific Model Model ARM Guidelines Model-Driven Engineering Slide 9 IoT-A Bosch – 13th March 2013

10 Things are of course a bit more complicated 
Slide 10 IoT-A Bosch – 13th March 2013

11 ARM Purpose 1 – Cognitive aid: common language, common concepts
Domain Model (Example) Physical Entity User interacts invokes Association Use Concepts to Specify Main IoT Elements Service exposes Virtual Entity models Resource hosts Device how can I talk about different architectures Slide 11 IoT-A Bosch – 13th March 2013

12 ARM Purpose 2 – Reference model as a common grounding
Modelling Specialists Domain timeline Information Functional Architects Planning and Organizing how can I structure research, development etc. of an architecture – what aspects do I need to cover? – what people do I need? Operation Specialists Operation Deployment Slide 12 IoT-A Bosch – 13th March 2013

13 ARM Purpose 3 – Generation of architectures
Guidelines (Examples) Topic Design Choice Impact on Security & Privacy Performanc e & Scalability Availability & Resilience Evolution & Interoperabi lity 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 DC2.2 Service Orchestration with optional security - VE Resolution DC3.1 VE Resolution with mandatory security DC3.2 VE Resolution with optional security DC3.3 VE Resolution with QoS DC3.4 VE Resolution domain-oriented DC3.5 VE Resolution location-oriented DC3.6 Resolution Semantic Web-oriented DC3.7 Resolution Peer- to-Peer-oriented Design Choices Architecture Creation Process Slide 13 IoT-A Bosch – 13th March 2013

14 Mapping Architecture Functions to Functional View of ARM
ARM Purpose 4 – Identifying differences and commonalities in architectures (Reverse Mapping + Comparison) Functional View (Example) Service Organisation VE Service VE & IoT Service Monitoring VE Resolution Business Process Execution Modeling IoT Service Resolution Orchestration Service Composition QoS Energy Optimisation Routing & Addressing Error Detection & Correction Flow Control & Reliability Gateway Management Security Application IoT Business Process Management Virtual Entity Communication QoS Manager Device Manager Authorisation Key Exchange & Trust & Reputation Identity Management Authentication Device Mapping Architecture Functions to Functional View of ARM Slide 14 IoT-A Bosch – 13th March 2013

15 ARM Purpose 5 – Benchmarking
Service Organisation VE Service VE & IoT Service Monitoring VE Resolution Business Process Execution Modeling IoT Service Resolution Orchestration Service Composition QoS Energy Optimisation Routing & Addressing Error Detection & Correction Flow Control & Reliability Gateway Management Security Application IoT Business Process Management Virtual Entity Communication QoS Manager Device Manager Authorisation Key Exchange & Trust & Reputation Identity Management Authentication Device Functionalities # Functional Groups addressed # Functional Components covered Evolution and Interoperability Benchmarking for high-level comparison Qualities addressed + Level Evolution and Interoperability: + Availability and Resilience: - Security and Privacy: -- Performance and Scalability: + Availability and Resilience how can I compare different architectures? – what are the functionalities? – what are the respective qualities? Security and Privacy Performance and Scalability Slide 15 IoT-A Bosch – 13th March 2013

16 Carsten Magerkurth, SAP
IoT-A Reference Model Carsten Magerkurth, SAP Slide 16 IoT-A Bosch – 13th March 2013

17 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 Communication Model T, S&P Model Functional Model CommFG Sec. FG Information handled by functional components Information Model Concepts as foundations of functional groups Concepts explicitly represented Domain Model IoT-A Bosch – 13th March 2013

18 Reference Model –Different Parts and Their Relations
Trust, Security and PrivacyModel: Respective concepts in the context of IoT Communication Model: IoT channel model and communication functionalities Functional Model: Functional groups of an IoT system and their relations Information Model: structure (e.g. relations, attributes) of all the information (data) that is handled in an IoT system Domain Model: Core concepts of IoT and their relations - independent of specific technologies Device Physical Entity Service exposes Resource hosts Association Virtual Entity models IoT-A Bosch – 13th March 2013

19 IoT-A Domain Model Physical Entity User interacts The DM defines the main concepts of the Internet of Things and the relations between these concepts invokes Association Service exposes Virtual Entity models Resource hosts Device IoT-A Bosch – 13th March 2013

20 IoT Domain model according to IoT-A
Slide 20

21 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 Service Description and Virtual Entities also contain Security-Related information, such as public keys, access policies or pseudonyms. This information is spread over different functional Components when we analyse this from a functional point of view IoT-A Bosch – 13th March 2013

22 Mapping of Domain Model Concepts to Information Model
Service Virtual Entity The Information Model models all the concepts of the Domain Model that are to be explicitly represented and manipulated in the digital world In addition the Information 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 Resource Device Associates Virtual Entities and Services based on Attributes  Services provide attribute values or through modification of attribute values manipulate modelled aspect of Physical Entity

23 IoT Service and Virtual Entity Abstraction Levels
Give me the indoor temperature in Room 1.23 Example Interactions value of Temperature Sensor 456 Set Actuator 867 To “on” Set light level In Room 2.57 to 15 Virtual Entity Level IoT System Physical World Virtual entity-based model models relevant aspects of Physical World Association of IoT Services to modelled Virtual Entities Resources exposed as IoT Services measure, observe and actuate on Physical World IoT Service Level sensor actuator IoT-A Bosch – 13th March 2013

24 Functional Model (FM) 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-A Bosch – 13th March 2013

25 Later: Detailing the Functional Model in the “Functional View”
Service Organisation VE Service VE & IoT Service Monitoring VE Resolution Business Process Execution Modeling IoT Service Resolution Orchestration Service Composition QoS Energy Optimisation Routing & Addressing Error Detection & Correction Flow Control & Reliability Gateway Management Security Application IoT Business Process Management Virtual Entity Communication QoS Manager Device Manager Authorisation Key Exchange & Trust & Reputation Identity Management Authentication Device IoT-A Bosch – 13th March 2013

26 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-A Bosch – 13th March 2013

27 Trust, Security and Privacy Model
Functional Component Functional Component Functional Component Functional Component Functional Component Based on Communication Model Security features and general layering Communication Security IoT-A Bosch – 13th March 2013

28 IoT-A Reference Architecture
Martin Bauer, NEC Europe Slide 28 IoT-A Bosch – 13th March 2013

29 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 IoT-A Bosch – 13th March 2013

30 Functional View Information View + Deployment & Operational View
Several Core Views Functional View Information View + Deployment & Operational View IoT-A Bosch – 13th March 2013

31 From the Functional Model…
Application IoT Business Process Management Service Organisation Security Virtual Entity Management IoT Service Communication Device IoT-A Bosch – 13th March 2013

32 …To the Functional View
Service Organisation VE Service VE & IoT Service Monitoring VE Resolution Business Process Execution Modeling IoT Service Resolution Orchestration Service Composition QoS Energy Optimisation Routing & Addressing Error Detection & Correction Flow Control & Reliability Gateway Management Security Application IoT Business Process Management Virtual Entity Communication QoS Manager Device Manager Authorisation Key Exchange & Trust & Reputation Identity Management Authentication Device IoT-A Bosch – 13th March 2013

33 Deployment & Operation
CORE Internet 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 Cellular Networks Cabled networks (ethernet/DSL) LOCAL RFID and WSN WiFi networks Tags Sensors Users Other IoT-A Bosch – 13th March 2013

34 Information View: Example of a hierarchical EntityType model
IoT-A Bosch – 13th March 2013

35 IoT Service: SensorData
Information flow from Device to VirtualEntity Attribute Application Management IoT Business Process Management Security Service Organisation Virtual Entity VE Service: Attribute IoT Service IoT Service: SensorData Communication Sensor value Flow Control & Reliability Sensor Device Device Slide 35 IoT-A Bosch – 13th March 2013

36 IoT Service: SensorData
Information flow: Publish/subscribe from Sensor to User Application User 1 User 2 User 3 Management IoT Business Process Management Security Notify Service Organisation Virtual Entity VE Service: Attribute IoT Service IoT Service: SensorData Sensor value Flow Control & Reliability Communication Sensor Device Device IoT-A Bosch – 13th March 2013

37 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 IoT-A Bosch – 13th March 2013

38 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-A Bosch – 13th March 2013


Download ppt "IoT-A IERC AC1 Expert Workshop"

Similar presentations


Ads by Google