IoT from the systems point of view - itabok.iasaglobal.org · • IoT is an uber-complex,...
Transcript of IoT from the systems point of view - itabok.iasaglobal.org · • IoT is an uber-complex,...
IoT from the systems point of view
Alexander SAMARIN
• An enterprise architect
– from a programmer to a systems architect (systems of various sizes: company, corporate, canton, city, country, continent)
– have created production systems which work without me
• Some of my professional roles
– “cleaning lady” (usually in an IT department)
– “peacemaker” (between the IT and business)
– “swiss knife” (for solving any problem)
– “patterns detective” (seeing commonalities in “unique” cases)
– “assembler” (making unique things from commodities)
– “barriers breaker” (there is always a bigger system)
– “coordinator” (without any formal authority over components)
2017-04-26 IoT from the systems point of view 2
About me
• Internet of Things (IoT) is one of the essential technologies right now
• IoT uses many existing and emerging information technologies, and IoT serves a lot of new exciting applications for healthcare, smart home, smart cities and smart manufacturing
• Therefore IoT must be considered as a system which perfectly delivers its desired capabilities
2017-04-26 IoT from the systems point of view 3
WHY of this talk
• This presentation will discuss how several modern techniques and methodologies can be combined together to improve IoT-centric and IoT-enabled digital solutions:
– systems approach
– explicit security
– explicit and machine-executable coordination
– reference architecture
2017-04-26 IoT from the systems point of view 4
HOW of this talk
• Adapted from the Alliance for IOT Innovation (AIOTI) report http://ec.europa.eu/newsroom/dae/document.cfm?action=display&doc_id=11810
• IoT is style of computing in which autonomous networked cyber-physical systems (also known as THINGs or IoT Devices) are able to interact and cooperate with various networked actors to create new applications/services and reach common goals
2017-04-26 IoT from the systems point of view 5
Definition of IoT to be used
• IoT is an uber-complex, socio-technical system of cyber-physical systems with the following characteristics:
– huge volume of digital data and information
– software-intensive (“software is eating the world”)
– distributed and decentralized
– great influence on our society (including economy)
– ability to interact with the physical world
– contradictory requirements
• Other examples of similar systems: AAL for people with disabilities, Smart Cities, Smart Homes, Smart Energy, IoT and Smart Manufacturing
2017-04-26 IoT from the systems point of view 6
IoT as a system
• systems approach
– holistic approach to understanding a system and its elements in the context of their behaviour and their relationships to one another and to their environment
– Note: Use of the systems approach makes explicit the structure of a system and the rules governing the behaviour and evolution of the system
• Four levels of abstraction
– reference model
– reference architecture
– solution architectures
– implementations
2017-04-26 IoT from the systems point of view 7
Definitions (1)
• reference model
– abstract framework for understanding concepts and relationships between them in a particular problem space (or subject field)
• reference architecture
– template for solution architectures which realizes a predefined set of requirements
• Note: A reference architecture uses its subject field reference model (as the next higher level of abstraction) and provides a common (architectural) vision, a modularization and
the logic behind the architectural decisions taken
• solution architecture
– architecture of the system-of-interest
• Note: A solution architecture (also known as a blueprint) can be a tailored version of a particular reference architecture (which is the next higher level of abstraction)
2017-04-26 IoT from the systems point of view 8
Definitions (2)
Reference architecture
2017-04-26 IoT from the systems point of view 9
Big picture
Reference model
Implementation A2
Solution architecture B
Solution architecture A
Implementation A1
Reference Implementation
Reference solution architecture
build and test
build and testdesign and experiment
field feedback
feasibility feedback
design and engineer
architect
extract essentials
constraints and opportunities
refinement
A few scenario reference architectures may be derived from the reference architectureAAL: personal telehealth, home Smart Cities: metropolis, city, village, island
Scenario 2 reference
architecture
Scenario 1 reference
architecture
constraints and opportunities
design and engineer
Problem space Solution space
Various needs
architect
extract
• Explain to any stakeholder how future implementations (which are based on the reference architecture) can address his/her concerns and change his/her personal, professional and social life for the better
– explicitly link needs (or high-level requirements) with the principles of reference architecture
• Provide a common methodology for architecting cyber-physical systems in the particular system domain
– different people in similar situations find similar solutions or propose innovations
• Help stakeholders, programmes and projects to collaborate and coordinate their efforts
– common agreements (i.e. standards) on various system elements (e.g. services, interfaces, data, etc.)
2017-04-26 IoT from the systems point of view 10
Purpose of reference architecture
• INPUT
– High-level requirements (or needs)
• domain needs
• transversal needs (or guiding principles), e.g. security, privacy, safety, low cost of operation, short time to market
• system needs, e.g. life cycle, software-intensive, etc.
– Reference model
• OUTPUT
– Architecture principles (top-level decisions, trade offs)
– Explicit link (or dependency matrix) between needs and principles
– Architecture description via viewpoints, models kind, views and models (in accordance with ISO/IEC/IEEEE 42010)
– Reference specification of various artefacts
2017-04-26 IoT from the systems point of view 11
Essential elements of any reference architecture
• Stakeholders of the IoT
• Stakeholders’ concerns are used to derive the domain needs
2017-04-26 IoT from the systems point of view 12
But some pre-requisites first
IoT
Smart manufacturing
Smart Homes
AAL
Smart Cities
Smart Energy
1. Any time, any place, any THING communication
2. Autonomic functioning
3. Services must be delivered as per Services Level Agreements (SLAs)
4. Safety, Security and Privacy
5. Ability to collaborate or group functioning
6. Functioning of any THING can be programmed(to some extent) by authorised networked actors
7. Low cost of implementation and operations
2017-04-26 IoT from the systems point of view 13
IoT high-level requirements (or “being a good citizen in the digital world”)
IoT reference architecture must explain how to satisfy all these requirements by design
2017-04-26 IoT from the systems point of view 14
How to satisfy the “security” requirement – big picture
Attack
Vulnerability
Technical asset
Risk
can exploit
causes harm
Threat
provokes
Security
define the level of
undermines
leads
Adverse impact
Likelihood
Predisposing conditions
Processes
Services
Outcomes
Objectives
slows down
underperforming
missing
exposing toArchitecture
Organisation
occurs with
Risk management
• Threats and vulnerabilities are universal
• There is a registry for publicly known information-security vulnerabilities and exposures https://cve.mitre.org/
• The level of adverse impact from an attack depends on the architecture of the system-of-interest
• Security and risk can be objectively link by architecture
2017-04-26 IoT from the systems point of view 15
Improving security (1)
• Architecture must know all the relationships between all the artefacts (technical assets, services, processes, etc.) to statically evaluate risks
• If the implementation of a system is based on business processes then it can dynamically evaluate risks
• Knowing the level of risk, one can implement a set of changes to reduce this level to acceptable one
2017-04-26 IoT from the systems point of view 16
Improving security (2)
security measureResidual risk
Widely acceptable risk Acceptable risk Unacceptable risk
• Any process-centric solution “knows” services, servers and other assets used to carry out its processes. Thus various impact to organisational goals may be objectively estimated via processes. Simulation may help.
2017-04-26 IoT from the systems point of view 17
Use of business processes (1)static risk evaluation
Inter-services communication may be implemented with CORBA, web services and microservices
• Use business processes to invoke security and risk controls
2017-04-26 IoT from the systems point of view 18
Use of business processes (2)dynamic risk evaluation
Risk monitoring and evaluation
Risk mitigation
Normal operations
• Risk must be carefully monitored, evaluated and acted upon with the pace of business processes
2017-04-26 IoT from the systems point of view 19
Use of business processes (3)integrated risk management
Enterprisedata warehouse
Risk-related rules, logic and knowledge
Risk-related events, reports, alerts, indicators, etc.
Enterprise document management and collaboration
1. Enterprise business functions should be enriched to generate the risk-related data.
2. Those risk-related data need to be collected at the enterprise data warehouse together with other business data.
3. Some business processes need to be updated to embed risk-related activities.
4. A set of risk-related rules, logic and risk-related knowledge should be able to use the risk-related and other business data to detect acceptable limits of risk as well as interdependencies and correlations between different risks.
5. Some business processes for risk mitigation maybe automatically activated.
6. A lot of risk-related indicators, alerts should be available in the form of dashboards and reports available for different staff members.
7. Staff members should be able to initiate business processes based on the observed risk-related information.
2017-04-26 IoT from the systems point of view 20
Use of business processes (3)dynamic access rights
• If the “Activity_B” validates the results of “Activity_A” then no actor should be simultaneously in “Role_1” and “Role_2”
• Note: “Activity_A” and Activity_B” may be in different processes and different applications
2017-04-26 IoT from the systems point of view 21
Use of business processes (4)dynamic separation of duties
• Each system element (tangible assets, intangible assets, peoples) must be explicitly protected
– for its confidentiality, integrity and availability
– in rest, in transit and in use
– throughout its life cycle (within the system-of-interest life cycle)
• Relationships between system elements are used to know how changes in one system element effects other system elements
– those relationships must be protected as well
– ideally, those relationships are explicit and machine-executable
2017-04-26 IoT from the systems point of view 22
Systems approach to security (1)
• The system must be protected from undesirable behavior of its system elements by the explicit definition of their desired behavior as a contract between the system-in-interest and each its system element
– contract must be explicit and machine-executable with veritable processes and rules
– contracts must be protected as well
• Permanent monitoring of all system elements is mandatory
• Predictive analytics on all system elements is highly desirable
2017-04-26 IoT from the systems point of view 23
Systems approach to security (2)
• Reference architecture description has to consider 3 groups of system elements
– some system elements are treated as black-boxes by defining for them required functionality, interfaces, performance, security assurance, etc.
– some system elements are treated as grey-boxes by defining also their internal structure (e.g. as illustrative processes)
– some system elements (which act as system-forming ones) are treated as white-boxes by defining their (reference) implementation
2017-04-26 IoT from the systems point of view 24
Systems approach to security (3)
• The best, so far, privacy regulation is EU General Data Protection Regulation (GDPR) to be applied from May 2018
• Challenges of the GDPR
– privacy by design and by default
– EU citizen is the new data owner
– explicit confidentiality and sensitive data protection
– very process-driven
– data protection officer
2017-04-26 IoT from the systems point of view 25
How to satisfy the “privacy” requirement
• In general, no problems with the GDPR compliance:– Use of explicit and machine-executable business processes– Request GDPR compliance from all partners – Use digital contracts (to be discussed later)
2017-04-26 IoT from the systems point of view 26
Addressing privacy
• At present, many devices from the IoT “world” act as wild animals thus being dangerous in the our world
• As in our world, we follow contracts, let us consider rules / regulations / laws for IoT as cyber-physical systems to tame IoT
• But we need something more simple and more concrete than the famous “The three laws of robotics”
• Let us consider “digital contracts”
• Each digital contract is a set of explicit and machine-executableprocesses between Things, Services and Persons
2017-04-26 IoT from the systems point of view 27
How to satisfy the “group functioning” requirement
– with Persons who are living in a particular household
– with a producer of this Fridge
– with a service company for maintenance of this Fridge
– with some online shops to order various food
– with some other Things within a particular household to achieve together some goals of energy consumption
• Note: The in-house network Router knowsthat this Fridge has rights to connect only to a few external sites; any other contacts will be blocked by the Router
• More info http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html
2017-04-26 IoT from the systems point of view 28
Example: Smart Fridge’s digital contracts
• The “point-to-point” pattern can be implemented by simple processes
– master-slave processes
– co-processes
• The “majordomo” pattern is about interactions between one master (major-domo, castellan, concierge, chamberlain, seneschal, mayor of the palace, maître d'hôtel, head butler and chief steward) and many servants; several coordination techniques are mandatory:
– shared calendars
– event-processing
– resource allocation, levelling and balancing
– processes and cases
2017-04-26 IoT from the systems point of view 29
A couple of group functioning patterns
• Because group functioning depends on sharing data and information (including certificates, ID, etc.) their security must be enhanced by a solid records management
• Blockchain-based implementations may be considered for more secure records management
2017-04-26 IoT from the systems point of view 30
Improving security for group functioning
• Certainly, various IoT cyber-physical systems are similar and different at the same time. Platforms can synergize diversity and uniformity to reduce the cost:– The platform frees up resource to focus on new opportunities
– Successful agile innovations are rapidly scaled up when incorporated into the platform
– An agile approach requires coordination at a system level
– To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives
– Existing elements of the platform also need periodic challenge
2017-04-26 IoT from the systems point of view 31
How to satisfy “low cost of implementation and operations”
2017-04-26 IoT from the systems point of view 32
Example: Platform for Smart Cities
Platforms combine:- diversity - uniformity
More info about platforms http://improving-bpm-systems.blogspot.ch/search/label/%23platform
• 5 interacting subsystems
S1 primary activities
S2 coordination of S1 and link with S3
S3 audit, exception handling S1, performance management of S1
S4 looking outwards to the environment
S5 responsible for policy decisions
• S4 and S5 are not necessary
• S2 and S3 may be combined
• S1 is unique for each IoT system
• S2 and S3 may be common
2017-04-26 IoT from the systems point of view 33
Logic of decompositionvia Viable System Model (VSM)
1. Explicit IoT architecting and engineering to achieve the required level of operational excellence, security, privacy and safety
2. Separation of concerns between IoT, AAL, Smart Homes and Smart Cities system domains
3. Built-in flexibility
4. IoT is a coordination environment for many actors
5. Adaptive connectivity
6. Use of digital contracts (internal and external)
7. Explicit internal IT governance
2017-04-26 IoT from the systems point of view 34
IoT reference architecture principles
Explicit
architecting
Separation of
concerns
Flexibility Coordination
environment
Connectivity Digital
contracts
IT
governance
AnyX X
Autonomic
functioning X X X X
SLAsX X X
Safety, security
and privacyX X X X
Group
functioning X X X
Programmability X X X X
Low costX X X X X
2017-04-26 IoT from the systems point of view 35
IoT RA dependency matrix: High-level requirements (rows) vs Principles (columns)
“X” is a cell means that the particular requirement (row) is covered by the particular principle (column)
2017-04-26 IoT from the systems point of view 36
Architecture description: Viewpoints, models kind, views and models
Many viewpoints are possible.Each viewpoint is a set of model kinds (or model types).
Each model kind consists of artefacts (e.g. applications, servers, etc.) and relationships between them (those applications are deployed on this servers).
2017-04-26 IoT from the systems point of view 37
Some standard viewpoints
• Stakeholders and their concerns
• Needs (or high-level requirements)
• Mission
• Vision
2017-04-26 IoT from the systems point of view 38
CPS reference architecture viewpoints:motivation
2017-04-26 IoT from the systems point of view 39
CPS reference architecture viewpoints:modularisation
Managerial group (grey-box)
Operational group (grey-box)
Primary group(black-box)
Coordination group
(white-box)
Supporting group(white-box)
Networked actors
API+UI
Security group(white-box)
•Drivers group to connect the IoT with various sensors, actuators and other things•Supporting group to provide functionality shared within a digital system (e.g. logging, monitoring, data handling, collaboration, process management, decision management, analytics, etc.)•Security group to provide security functionality•Primary group to provide core business functionality•Coordination group to execute digital contracts between various networked actors and IoT itself;•Managerial group to reconfigure the IoT system itself•Operational group to maintain the proper functioning of the IoT system itself
Drivers group(black-box)
Physical groupsensors, actuators and thing(s)
Structural decomposition of the problem space in groups or domains or value streams
• eTOM (enterprise-like modularisation)
2017-04-26 IoT from the systems point of view 40
CPS reference architecture viewpoints:capability map (on top of modularisation)
• Draft proposal for the IoT RA (modularization in domains)
2017-04-26 IoT from the systems point of view 41
CPS reference architecture viewpoints:capability map
Solution 1
…
Platform
Security management
Business process management
Operational and analytical data
Decision management
Master and reference data
Reporting management
Analytics management
Drivers…
Solution 2
IoT-specific layer
Service management
Event management
2017-04-26 IoT from the systems point of view 42
CPS reference architecture viewpoints:implementation framework as a platform
IoT devices in edge computing
Platform in cloud
computing
Platform in fog
computing
Platform in local
computing
2017-04-26 IoT from the systems point of view 43
CPS reference architecture viewpoints:deployment topology
…
…
…
§
2017-04-26 IoT from the systems point of view 44
CPS reference architecture viewpoints:operational patterns (example)
Data analysis
Data enrichment
Decision selection
Action activation
Continuous monitoring
Observe, Orient, Decide, Act (OODA) pattern
Coordination, Event Streams, Analytics, Rules (CESAR) pattern
Sensor A
Sensor B
Sensor C
Situation prediction
Case (e.g. incident) coordination
Rules application
Actions execution
Case (e.g. incident) data
flow-of-control
flow-of-data
flow-of-events
1. motivation outline viewpoint2. illustrative viewpoint3. modularisation outline viewpoint4. capability map viewpoint 5. business outline viewpoint6. operational viewpoint7. functional map viewpoint8. service map viewpoint 9. process map viewpoint 10.data flows viewpoint11. operational patterns viewpoint12.performance viewpoint13. security framework viewpoint14.privacy framework viewpoint15. safety framework viewpoint16. implementation framework viewpoint17.deployment topology viewpoint
2017-04-26 IoT from the systems point of view 45
Typical CPS architecture viewpoints
The first several viewpoints are for the reference architecture, the rest is already some tailoring of the reference architecture as scenario or solution architectures
• Existing IoT reference architectures are still weak in
– stakeholders and their concerns
– high-level requirements
– security
– privacy
– group functioning
– serving “bigger” domains
2017-04-26 IoT from the systems point of view 46
Conclusions (1)
• The proposed use of digital contracts, explicit process and blockchain can make an impression that they will increase the complexity of IoT. In accordance with the Cynefinframework explicit linking allows progressing
– from “Complex” situation (in which the relationship between cause and effect can only be perceived in retrospect, but not in advance)
– to “Complicated” situation (in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge)
• A lot of painful standardisation and regulatory work is necessary ahead, but, in accordance with a Russian proverb “volkov boyat'sya — v les ne khodit'”, or “If you can't stand the heat, stay out of the kitchen” or no pain no gain
2017-04-26 IoT from the systems point of view 47
Conclusions (2)
• Personal website: http://www.samarin.biz
• Blog http://improving-bpm-systems.blogspot.com
• LinkedIn: http://www.linkedin.com/in/alexandersamarin
• E-mail: [email protected]
• Twitter: @samarin
• Mobile: +41 76 573 40 61
• Book: www.samarin.biz/book
2017-04-26 IoT from the systems point of view 48
Questions?
• system capability
• capability, <systems approach>
– ability of a system or a system element to do something at a required level of performance
– Think football – a lot people can play football, but only some of them can play football at the level required to win EURO 2016
2017-04-26 IoT from the systems point of view 49
About the concept `capability’ (1)
• A business capability is a concept that captures – “what” an enterprise must do to achieve its mission and – “how well” or “wow” an enterprise must doing that “what” to
achieve its mission
• Capability is independent from “how” do we do it, “where” we do it, “who” does it, “which tools” are used– The concept “capability” is more generic than technical
components, data, interfaces, functions, services, applications, processes, roles and organisations
– But to provide a capability, several technical components, data, interfaces, functions, services, applications, processes, roles and organisations are, usually, required
• There are two major extensions of the concept ‘capability’:– capability as a discrete-unit-of-purpose– capability as a measure-of-performance
2017-04-26 IoT from the systems point of view 50
About the concept `capability’ (2)