Architectural Reference Model (ARM) Presenter: Martin Bauer (NEC Europe)

Transcription

1 Architectural Reference Model (ARM) Presenter: Martin Bauer (NEC Europe)

2 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

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

4 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

5 Dependencies and Model Influences understand IoT Reference Model guides Unified Requirements steer IoT Reference Architecture extrapolate guides with Best Practices Business Scenarios, Existing Architectures & Stakeholders define Application- Specific Requirements define Compliant Domain-Specific Architectures Slide 5

6 IoT-A Reference Model Slide 6

7 Reference Model (RM) Overview The RM provides a common understanding of the IoT domain Communication Model T, S&P Model The RM contains: Domain Model Information Model Functional Model Communication Model Trust, Security and Privacy Model Information handled by functional components Information Model Functional Model Concepts explicitly represented Comm FG Sec. FG Concepts as foundations of functional groups Domain Model Slide 7

8 class Domain Model IoT-A Domain Model invokes / subscribes User User * The DM defines the main concepts of the Internet of Things and the relations between these concepts invokes Activ e Digital Artefact Passiv e Digital Artefact Digital Artefact Human User interacts contains interacts with invokes exposes exposes Resource A Virtual Entity is either an Active Digital Artefact or a Passive Digital Artefact. Service is associated with Association contains 1 Virtual 0..1 Virtual Entity Entity is associated with hosts hosts contains Augmented Entity 1 models * Physical relates to 1 Physical Entity Entity is attached to 1 monitors Device contains Network Resource On-Dev ice Resource Actuator Tag reads Sensor identifies acts on has Information about / acts on Slide 8

9 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 class Information Model VirtualEntity entitytype identifier Serv icedescription Attribute attributename attributetype Association ValueContainer metadata Value 1 MetaData metadataname metadatatype metadatavalue Resource Description 0..1 Dev ice Description Slide 9

10 Mapping of Domain Model Concepts to Information Model class Domain Model invokes / subscribes User * class Information Model Digital Artefact Human User Value Activ e Digital Artefact Passiv e Digital Artefact interacts with 1 contains invokes A Virtual Entity is either an Active Digital Artefact or a Passive Digital Artefact. Augmented Entity VirtualEntity entitytype identifier Attribute attributename attributetype ValueContainer Serv ice Service is associated with 1 contains exposes contains 0..1 Virtual Virtual Entity * relates to 1 Physical Entity is attached to 1 Association metadata Network Resource Resource Resource is associated with On-Dev ice Resource contains 0..1 Device hosts 1 Actuator Tag reads identifies acts on has Information about / acts on monitors Sensor Resource Description Serv icedescription 0..1 Dev ice Description MetaData metadataname metadatatype metadatavalue Associates Virtual Entities and Services based on Attributes Services provide attribute values or through modification of attribute values Slide 10 manipulate modelled aspect of Physical Entity

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

12 Management Service Organization Serurity 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 Application IoT Business Process Management Virtual Entity IoT Service Communication Device Slide 12

13 Communication Model Typical Internet 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 specialization of the model Slide 13

14 Trust, Security and Privacy Model Functional Component Based on Communication Model Security features and general layering Communication Security Slide 14

15 IoT-A Reference Architecture Slide 15

16 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

17 Several Core Views Functional View Information View + Deployment & Operational View Slide 17

18 Management Service Organisation Security From the Functional Model Application IoT Business Process Management Virtual Entity IoT Service Communication Device Slide 18

19 Service Composition Service Organisation Service Orchestration To the Functional View Application Management IoT Business Process Management Security Business Process Modeling Business Process Execution Virtual Entity Authorisation QoS Manager VE Resolution VE & IoT Service Monitoring VE Service Key Exchange & Management Device Manager IoT Service Trust & Reputation IoT Service Resolution IoT Service Identity Management Gateway Communication Flow Control & Reliability Authentication Routing & Addressing Energy Optimisation QoS Error Detection & Correction Device Slide 19

20 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 Tags LOCAL RFID and WSN Cabled networks (ethernet/dsl) Sensors WiFi networks Internet Other CORE Cellular Networks Users Slide 20

21 Information View: Example of a hierarchical EntityType model Slide 22

22 Service Organisation Information flow: Publish/subscribe from Sensor to User Application User 1 User 2 User 3 Management IoT Business Process Management Security Virtual Entity Notify VE Service: Attribute IoT Service IoT Service: SensorData Sensor value Flow Control & Reliability Communication Sensor Device Device Slide 23

23 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

24 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 25

25 Best Practice / Guidelines Build your own Architecture Slide 31

26 What s the Best Practices activity in IoT-A about? understand IoT Reference Model Architectural Reference Model Best Practice Concrete Architecture guides Implementation Application- Independent Model Transformation extrapolate steer Platform- Independent Unified Requirements Model Plattform- IoT Reference Specific Architecture Model Transformation guides with Best Practices Business Scenarios, Existing Architectures & Stakeholders define Application- Specific Requirements define Compliant Domain-Specific Architectures Slide 32

27 Connecting it to something more familiar Slide 33

28 Scope of Best Practices Domain-specific architecture Manual Steps Illustration IoT ARM Domain-specific architecture Perspectives Deployment Security FM usage CM usage IM usage DM usage Risk analysis Requirements engineering Design choices Use cases Reverse mapping IoT ARM Slide 34

29 Domain-model usage & examples Domain Model:: Augmented Entity Automobile manufacturer data base Active Digital Artefact Digital Artefact Domain Model::Virtual Entity relates to 1 Domain Model:: Physical Entity VE Chassis number Manufacturing land Manufacturing date... Vehicle registration station data base «is instance of» «is instance of» «is instance of» VE Plate number Model Color Owner name... UAV Controller : Virtual Entity controls UAV Body :Physical Entity Insurance company data base VE Plate number Model Owner name Insurance type... Unmanned Aerial Vehicle :Augmented Entity Slide 35

30 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 Slide 36

31 Summary and Outlook Slide 37

32 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 Slide 38

33 Outlook A final version of the ARM will be compiled as an IoT-A deliverable in May 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! Slide 39

34 Please provide feedback! Currently v2.0 of the IoT-A ARM (D1.4) available as a project deliverable ( or direct link: Feedback collection: Everybody can provide comments at: Slide 40

35 Internet of Things European Research Cluster (IERC) Activity Chain 1 - Architecture approaches and models Slide 41

36 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) Slide 42

37 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 Slide 43