Internet of Things Reference Architectures
0 likes737 views
The document discusses several IoT reference architectures: - RAMI 4.0 is a three-dimensional model for Industrie 4.0/Industry 4.0 that structures the issues into layers, value streams, and hierarchy levels. - The Industrial Internet Consortium Reference Architecture (IIRA) specifies a common framework with business, usage, functional, and implementation viewpoints. It decomposes systems into five functional domains. - The Industrial Internet Security Framework (IISF) addresses security and safety concerns that arise from converging industrial control systems with business systems and the internet. It provides guidelines to make IIoT systems trustworthy.
Internet of Things Reference Architectures
- 1. 2: IoT Reference Architectures
- 2. IoT Reference Architectures • Industrie 4.0 – Reference Architecture Model Indutsrie 4.0 • Industrial Internet Consortium – Industrial Internet Consortium Reference Architecture – Industrial Internet of Things Security Framework • OpenFog Consortium – OpenFog Reference Architecture
- 3. RAMI 4.0
- 4. Industrie 4.0 • I4.0 connects / merges production with information and communications technology • I4.0 merges customer data with machine data • Machines communicate with machines • Components and machines autonomously manage production in a flexible, efficient, and resource-saving manner
- 5. Reference Architecture Model Industrie 4.0 • RAMI 4.0 is a three-dimensional map/model showing how to approach the issue of Industrie 4.0 in a structured manner • RAMI 4.0 ensures that all participants involved in Industrie 4.0 discussions understand each other
- 6. RAMI 4.0 3D Model • Architecture axis (Layers): models functionalities at different granularities of the system – comprises six different layers, from the asset to the business level • Process axis (Value Stream): models the stages of an asset’s lifecycle, along with a corresponding value creation process – based on IEC 62890 • Hierarchy axis (Hierarchy levels): models the breakdown structure of assembled components – based on a taxonomy that starts from the product and goes up to the connected smart factory
- 7. RAMI 4.0
- 8. Axis 1 – Hierarchy: The Factory The Old World: Industrie 3.0 • Hardware-based structure • Functions are bound to hardware • Hierarchy-based communication • Product is isolated
- 9. Axis 1 – Hierarchy: The Factory The New World: Industrie 4.0 • Flexible systems and machines; functions are distributed through the network • The network can cross company boundaries • Participants interact across hierarchical levels • All participants are able to communicate with each other • Products are part of the network
- 10. Axis 1 – Hierarchy: The Factory (1/2) • Product: abstracts the product that is manufactured in a factory • Field device: captures and/or controls data from the field – sensor and electronic devices • Control device: corresponds to the Operational Technology (OT) that manages input and output – PLCs (Programmable Logic Controllers) and DCSs (Distributed Control Systems) • Station, enables operators to coordinate several processes and monitoring the results, by means of automation systems – SCADA
- 11. Axis 1 – Hierarchy: The Factory (2/2) • Work Center: keeps track of manufacturing information and parameters that enable quality management • Enterprise: comprises the core business processes that are usually managed through an ERP system – production planning, production scheduling, marketing and sales, financial modules • Connected World: deals with the interlinking of all stakeholders as part of their supply chain interactions – including information sharing and exchange among them
- 12. Axis 2 – Architecture
- 13. Axis 2 – Architecture Questions about the business idea
- 14. Axis 2 – Architecture Communications Layer Basis for standardized comms between admin shells
- 15. Axis 3 – Product Life Cycle
- 16. RAMI 4.0
- 17. Requirements • Globally standardized communication • Easy installation and operation (“plug and play”) • Standardized language for the exchange of information
- 18. Administration Shell The Administration Shell provides interpretation • is the interface connecting I4.0 to the physical Thing • stores all data and information about the asset • serves as the network’s standardized communication interface • integrates passive assets
- 19. Roles and Responsibilities of the A.S. • Each physical thing has its own administration shell. • Several assets can form a thematic unit with a common administration shell, several thematic units
- 20. Industrie 4.0 Component • The connection takes place over the I4.0 communication • The administration shell forms the digital part • The Thing forms the real part Each object has its own administration shell that allows its integration into Industrie 4.0
- 21. INDUSTRIAL INTERNET CONSORTIUM REFERENCE ARCHITECTURE (IIRA)
- 22. IIRA Architecture Framework • An architecture framework contains information identifying the fundamental architecture constructs and specifies concerns, stakeholders, viewpoints, model kinds, correspondence rules and conditions of applicability
- 23. ISO/IEC/IEEE Architecture Description • A viewpoint comprises conventions framing the description and analysis of specific system concerns – Frames one or more concerns. • The term concern refers to any topic of interest pertaining to the system • A stakeholder is an individual, team, organization or classes thereof, having an interest in a concern and by extension an interest in the viewpoint and system • A model kind of a viewpoint is a modeling construct that is defined to aid the tasks of describing, analyzing and resolving concerns
- 26. IIRA • Specifies a common architecture framework for developing interoperable IoT systems for different vertical industries • Presents the structure of IoT systems from four viewpoints – Business – Usage – Functional – Implementation
- 27. IIRA Viewpoints • The business viewpoint attends to the concerns of the identification of stakeholders and their business vision, values and objectives in establishing an IIoT system in its business and regulatory context • It identifies how the IIoT system achieves the stated objectives through its mapping to fundamental system capabilities.
- 28. IIRA Viewpoints • The usage viewpoint addresses the concerns of expected system usage. It is typically represented as sequences of activities involving human or logical (e.g. system or system components) users that deliver its intended functionality in ultimately achieving its fundamental system capabilities.
- 29. IIRA Viewpoints • The functional viewpoint focuses on the functional components in an IIoT system, their structure and interrelation, the interfaces and interactions between them, and the relation and interactions of the system with external elements in the environment, to support the usages and activities of the overall system.
- 30. IIRA Viewpoints • The implementation viewpoint deals with the technologies needed to implement functional components (functional viewpoint), their communication schemes and their lifecycle procedures. These elements are coordinated by activities (usage viewpoint) and supportive of the system capabilities (business viewpoint).
- 31. Relationships among Viewpoints • Crosscutting concerns: require consistent consideration across the viewpoints – Safety – Security
- 32. IIRA Business Viewpoint Vision and value-driven model
- 33. IIRA Usage Viewpoint Is concerned with how an IIoT system realizes the key capabilities identified in the business viewpoint
- 34. IIRA Functional Viewpoint • The functional viewpoint specifies the functionalities of an IIoT system – specifies distinct functionalities in the form of functional domains • Functional domains are used to decompose an IoT system in a set of important building blocks – applicable across different vertical domains and applications – Used to conceptualize concrete functional architectures
- 35. IIRA Functional Domains • The IIRA decomposes an IoT system into five functional domains – control domain – operations domain – information domain – application domain – business domain Green Arrows: Data/Information Flows Grey/White Arrows: Decision Flows Red Arrows: Command/Request Floes
- 36. IIRA Control Domain Represents the collection of functions that are performed by industrial control systems
- 37. IIRA Operations Domain Represents the collection of functions responsible for the provisioning, management, monitoring and optimization of the systems in the control domain
- 38. IIRA Information Domain Represents the collection of functions for gathering data from various domains, most significantly from the control domain, and transforming, persisting, and modeling or analyzing those data to acquire high-level intelligence about the overall system
- 39. IIRA Application Domain Represents the collection of functions implementing application logic that realizes specific business functionalities
- 40. IIRA Business Domain The business domain functions enable end-to- end operations of the industrial internet of things systems by integrating them with traditional or new types of industrial internet systems specific business functions including those supporting business processes and procedural activities
- 41. Functional Domains, Crosscutting Functions and System Characteristics
- 42. IIRA Implementation Viewpoint • Based on a three-tier architecture – follows the edge/cloud computing paradigm
- 43. Mapping 3-tier Architecture to Functional Domains
- 44. INDUSTRIAL INTERNET SECURITY FRAMEWORK (IISF)
- 45. IIoT Security and Safety • IIoT: convergence of IT and OT worlds – IT security is a well studied domain with strong mathematical foundations – OT security in trustworthy industrial systems relied on physical separation and network isolation of vulnerable components, and on the obscurity of the design and access rules for critical control systems. • Convergence of – control systems – business systems, and – the Internet
- 46. IIoT Risks Systems that were originally designed to be isolated are now exposed to attacks of ever-increasing sophistication and the design assumptions of existing OT systems no longer apply Approach: make their IIoT systems trustworthy
- 47. Enabling Trustworthiness • Key system characteristics: affect the trust decisions of an IIoT deployment – Security: the condition of a system being protected from unintended or unauthorized access, change or destruction – Safety: the condition of the system operating without causing unacceptable risk of physical injury or damage to the health of people, either directly or indirectly, as a result of damage to property or to the environment – Reliability: the ability of a system or component to perform its required functions under stated conditions for a specified period of time – Resilience: the emergent property of a system that behaves in a manner to avoid, absorb and manage dynamic adversarial conditions while completing the assigned missions, and reconstitute the operational capabilities after causalities – Privacy: the right of an individual or group to control or influence what information related to them may be collected, processed, and stored and by whom, and to whom that information may be disclosed
- 48. Trustworthiness Trustworthiness is the degree of confidence one has that the system performs as expected in respect to all the key system characteristics in the face of environmental disruptions, human errors, system faults and attacks
- 50. Functional and Implementation Viewpoints • IIoT implementations must provide end-to- end security from the edge to the cloud
- 51. Security Functionalities • They have to be deployed for the various edge points according to the IISF • Functional Viewpoint of IISF
- 52. IISF Mapping • Alignment of and IoT system with IIRA and IISF
- 54. IISF Comms and Connectivity Protection
- 55. IISF Security Monitoring and Analysis
- 56. IISF Security Configuration and Management
- 58. IISF Security Model and Policy
- 60. OpenFog Consortium • A consortium of high tech industrial enterprises companies and research/academic institutions collaborating towards standardizing and promoting the fog computing paradigm – Cisco – Intel – Microsoft – Princeton – Dell – ARM – … • Merged with IIC, January 31, 2019
- 61. Fog Computing An extension of the traditional cloud-based computing model where implementations of the architecture can reside in multiple layers of a network’s topology A horizontal, system-level architecture that distributes computing, storage, control and networking functions closer to the users along a cloud-to-thing continuum All benefits of cloud should be preserved with these extensions to fog, including containerization, virtualization, orchestration, manageability, and efficiency
- 62. OpenFog Architecture Advantages OpenFog architectures offer unique advantages over other approaches • Security: Additional security to ensure safe, trusted transactions • Cognition: awareness of client-centric objectives to enable autonomy • Agility: rapid innovation and affordable scaling under a common infrastructure • Latency: real-time processing and cyber-physical system control • Efficiency: dynamic pooling of local unused resources from participating end-user devices
- 63. OpenFog Reference Architecture • Describes a generic fog platform that is designed to be applicable to any vertical market or application – applicable across many different markets – Transportation, agriculture, smart-cities, smart– buildings, healthcare, hospitality, financial services, and more • Provides business value for IoT applications that require real-time decision making, low latency, improved security, and are network-constrained
- 64. Pillars of OpenFog RA
- 65. Hierarchical Fog Deployment Models Cloud vs. Fog deployments
- 69. OpenFog RA Perspectives • Performance: Low latency – Critical computing, time sensitive networking • Security: end-to-end security – Data integrity is of particular importance – Builds security hierarchically • From low level silicon devices to higher levels of node-to-x communications • Manageability: all aspects of fog deployment – RAS, DevOps • Data analytics and Control: autonomy requires localized analytics and control • IT Business and Cross Fog Applications: In multi-vendor applications need the ability to migrate and properly operate at any level of a fog deployment’s hierarchy
- 70. References • Reference Architecture Model Industrie 4.0 – https://www.plattform- i40.de/I40/Redaktion/EN/Downloads/Publikation/rami40-an- introduction.pdf?__blob=publicationFile&v=4 • Industrial Internet Consortium Reference Architecture – https://www.iiconsortium.org/IIC_PUB_G1_V1.80_2017-01- 31.pdf • Industrial Internet of Things Security Framework – https://www.iiconsortium.org/pdf/IIC_PUB_G4_V1.00_PB.pdf • OpenFog Reference Architecture – https://www.iiconsortium.org/pdf/OpenFog_Reference_Archite cture_2_09_17.pdf