1 / 38

IoT -A IERC AC1 Expert Workshop

IoT -A IERC AC1 Expert Workshop. 15./16. April 2013, Heidelberg. General Introduction and Goals of IoT -A Architectural Reference Model (ARM) . Martin Bauer, NEC Europe. Slide 2. IoT-A Workshop @ Bosch – 13th March 2013. Current IoT status

thetis
Download Presentation

IoT -A IERC AC1 Expert Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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 FP7 IoT-A: Internet of Things Architecture IoT-A Workshop @ 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 Workshop @ 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 • Guidelinesto help in developing an architecture for a specific system based on the IoT Reference Architecture • Provide guidance for system architects Slide 5 IoT-A Workshop @ Bosch – 13th March 2013

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

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

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

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

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

  11. ARM Purpose 1– Cognitive aid: common language, common concepts Domain Model (Example) VirtualEntity Device PhysicalEntity User Service Resource invokes interacts Use Concepts to SpecifyMain IoT Elements Association models exposes hosts Slide 11 IoT-A Workshop @ Bosch – 13th March 2013

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

  13. ARM Purpose 3 – Generation of architectures Guidelines (Examples) Architecture CreationProcess Design Choices Slide 13 IoT-A Workshop @ Bosch – 13th March 2013

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

  15. ARM Purpose 5 – Benchmarking Functionalities # Functional Groups addressed # Functional Components covered Application Management IoT Business Process Management Security Business Process Modeling Business Process Execution Service Orchestration Authorisation Virtual Entity Service Organisation QoS Manager VE Resolution VE & IoT Service Monitoring VE Service Key Exchange & Management Device Manager Trust & Reputation Service Composition IoT Service Evolution and Interoperability Identity Management IoT Service Resolution IoT Service Benchmarking forhigh-level comparison Authentication Qualities addressed + Level Evolution and Interoperability: +Availability and Resilience: -Security and Privacy: -- Performance and Scalability: + Availability and Resilience Communication Flow Control & Reliability Gateway Routing & Addressing Energy Optimisation QoS Error Detection & Correction Security and Privacy Device Performance and Scalability Slide 15 IoT-A Workshop @ Bosch – 13th March 2013

  16. IoT-A Reference Model Carsten Magerkurth, SAP Slide 16 IoT-A Workshop @ 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 Sec. FG CommFG Information handled by functional components InformationModel Concepts as foundations offunctional groups Concepts explicitly represented Domain Model IoT-A Workshop @ 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 channelmodel and communication functionalities VirtualEntity Device PhysicalEntity Service Resource Functional Model: Functionalgroups of an IoT system and theirrelations Association models exposes Information Model: structure (e.g. relations, attributes) of all the information (data) that is handled in an IoT system hosts Domain Model: Core concepts of IoT and their relations - independent of specific technologies IoT-A Workshop @ Bosch – 13th March 2013

  19. IoT-A Domain Model The DM defines the main concepts of the Internet of Things and the relations between these concepts VirtualEntity Device PhysicalEntity User Service Resource invokes interacts Association models exposes hosts IoT-A Workshop @ 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 IoT-A Workshop @ Bosch – 13th March 2013

  22. Mapping of Domain Model Concepts to Information Model VirtualEntity Resource Service Device Associates Virtual Entities and Services based on Attributes  Services provide attribute values or through modification ofattribute values manipulate modelled aspect of Physical Entity

  23. IoT Service and Virtual Entity Abstraction Levels ExampleInteractions IoT System Physical World Virtual entity-based model models relevant aspects of Physical World Give me the indoor temperature in Room 1.23 Set light level In Room 2.57 to 15 Virtual Entity Level Association of IoT Services to modelled Virtual Entities Give me the value of Temperature Sensor 456 sensor Resourcesexposed as IoTServices measure, observe and actuate on Physical World sensor sensor sensor IoT Service Level actuator Set Actuator 867 To “on” IoT-A Workshop @ 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 Workshop @ Bosch – 13th March 2013

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

  28. IoT-A Reference Architecture Martin Bauer, NEC Europe Slide 28 IoT-A Workshop @ 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 Workshop @ Bosch – 13th March 2013

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

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

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

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

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

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

More Related