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


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


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


Definition of IoT to be used

http://ec.europa.eu/newsroom/dae/document.cfm?action=display&doc_id=11810

• 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


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


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)


Definitions (2)

Reference architecture


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.)


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


Essential elements of any reference architecture

• Stakeholders of the IoT

• Stakeholders’ concerns are used to derive the domain needs


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


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


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


Improving security (1)

https://cve.mitre.org/

• 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


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.


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


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


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.


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


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


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



• 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



• 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


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)


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


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


Example: Smart Fridge’s digital contracts

http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html

• 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


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


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


How to satisfy “low cost of implementation and operations”


Example: Platform for Smart Cities

Platforms combine:- diversity - uniformity

More info about platforms http://improving-bpm-systems.blogspot.ch/search/label/%23platform

http://improving-bpm-systems.blogspot.ch/search/label/#platform

• 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


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


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


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)


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).


Some standard viewpoints

• Stakeholders and their concerns

• Needs (or high-level requirements)

• Mission

• Vision


CPS reference architecture viewpoints:motivation


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)


CPS reference architecture viewpoints:capability map (on top of modularisation)

• Draft proposal for the IoT RA (modularization in domains)


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


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


CPS reference architecture viewpoints:deployment topology

…

…

…

§


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


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


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


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


Questions?

http://www.samarin.biz/

http://improving-bpm-systems.blogspot.com/

http://www.linkedin.com/in/alexandersamarin

mailto:[email protected]

http://www.twitter.com/samarin

http://www.samarin.biz/book

• 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


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


About the concept `capability’ (2)

Date post:	05-Aug-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

IoT from the systems point of view - itabok.iasaglobal.org · • IoT is an uber-complex,...

Documents