Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "IoT-A IERC AC1 Expert Workshop 15./16. April 2013, Heidelberg."— Presentation transcript:

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

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

4 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? 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 Slide 6 IoT-A Bosch – 13th March 2013 IoTReference Model IoTReference Architecture Application- Specific Requirements Unified Requirements extrapolate Compliant Domain-Specific Architectures Business Scenarios, Existing Architectures & Stakeholders guides define steer define guides through Guidelines understand

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

8 Connecting the dots: generation of architectures Slide 8 IoT-A Bosch – 13th March 2013

9 Platform- Independent Model Plattform- Specific Model Transformation Model-Driven Engineering ARM Guidelines Application- Independent Model Transformation Architectural Reference Model Concrete Architecture Implementation From Architectural Reference Model to Concrete Architecture and Implementation 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 Device Physical Entity User interacts invokes Service exposes Resource hosts Virtual Entity models Domain Model (Example) Use Concepts to Specify Main IoT Elements IoT-A Bosch – 13th March 2013 Slide 11 Association

12 Operation Specialists Architects Modelling Specialists ARM Purpose 2 – Reference model as a common grounding Slide 12 Domain Information Functional Operation Deployment timeline Planning and Organizing IoT-A Bosch – 13th March 2013

13 ARM Purpose 3 – Generation of architectures Slide 13 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 OrganisationDC2.1 Service Orchestration with mandatory security +/-0+0 DC2.2 Service Orchestration with optional security -0-0 VE ResolutionDC3.1 VE Resolution with mandatory security +/-0+0 DC3.2 VE Resolution with optional security -0-0 DC3.3 VE Resolution with QoS 00+0 DC3.4 VE Resolution domain-oriented ++++ DC3.5 VE Resolution location-oriented -++/- DC3.6 Resolution Semantic Web-oriented 00++/- DC3.7 Resolution Peer- to-Peer-oriented 0++0 Design Choices Architecture Creation Process Guidelines (Examples) IoT-A Bosch – 13th March 2013

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

15 ARM Purpose 5 – Benchmarking Service Organisation VE Service VE & IoT Service Monitoring VE Resolution Business Process Execution Business Process Modeling IoT Service Resolution Service Orchestration Service Composition QoSEnergy Optimisation Routing & Addressing Error Detection & Correction Flow Control & Reliability Gateway ManagementSecurity Application IoT Business Process Management Virtual Entity IoT Service Communication QoS Manager Device Manager Authorisation Key Exchange & Management Trust & Reputation Identity Management Authentication Device 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 Bosch – 13th March 2013 Slide 15

16 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 Slide 17 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 Bosch – 13th March 2013

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

19 IoT-A Domain Model Slide 19 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-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 Slide 21 IoT-A Bosch – 13th March 2013

22 Mapping of Domain Model Concepts to Information Model Slide 22 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

23 IoT Service and Virtual Entity Abstraction Levels Physical World IoT Service Level sensor actuator 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 23 IoT-A Bosch – 13th March 2013

24 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 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 Business Process Modeling IoT Service Resolution Service Orchestration Service Composition QoSEnergy Optimisation Routing & Addressing Error Detection & Correction Flow Control & Reliability Gateway ManagementSecurity Application IoT Business Process Management Virtual Entity IoT Service Communication QoS Manager Device Manager Authorisation Key Exchange & Management Trust & Reputation Identity Management Authentication Device Slide 25 IoT-A Bosch – 13th March 2013

26 Slide 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 Slide 27 Trust, Security and Privacy Model Security features and general layering Communication Security Based on Communication Model Functional Component 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 Slide 29 IoT-A Bosch – 13th March 2013

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

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

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

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

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

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

36 IoT Service: SensorData Flow Control & Reliability IoT Service Communication Device Sensor Device Service Organisation ManagementSecurityIoT Business Process Management Sensor value VE Service: Attribute Virtual Entity User 1 Application User 2User 3 Notify Information flow: Publish/subscribe from Sensor to User Slide 36 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 Slide 37 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 Slide 38 IoT-A Bosch – 13th March 2013


Download ppt "IoT-A IERC AC1 Expert Workshop 15./16. April 2013, Heidelberg."

Similar presentations


Ads by Google