1 Basic concepts

The systems approach is a holistic approach to understanding a system and its discrete parts in the context of their behaviour and their relationships to one another and to their environment.

System domain is a subject field to which the systems approach is applied.

Examples are Smart-Energy, Smart-Home, Smart-Cities and Active Assisted Living (i.e. supporting people of any age with a temporary or permanent disability or impairment). The IoT is considered as a system domain as well.

Functional domain is a set of functions for fulfilment of top-level unit-of-purpose of a particular system.

Thing as a System (TaaSy) is accessible, programmable and collaborative via digital services Thing which is considered as an CPS system. See [ref1].Final-beneficiary is a person or an organisation served by a particular system domain (e.g. person who lives in a smart-home).

Wikipedia defines the “smart-home” concept or “home-automation” concept (also known as domotics or domotica) as the residential extension of building automation and involves the control and automation of lighting, ventilation, air conditioning, and security, as well as home appliances such as washer/dryers, ovens or refrigerators/freezers that use WiFi for remote monitoring.

Unfortunately, this definition has a few drawbacks, namely:

it does not emphasize that all the cyber-physical devices within a particular home must work together as a system to achieve synergy and guarantee a good level of security and other desirable outcomes;

home is place where one lives permanently, especially as a member of a family or household (thus final-beneficiaries for homes and buildings are different);

other factors must be considered, e.g. political, socio-cultural, legal, etc.;

smart-home systems is a class of cyber-physical systems.

Chapter 3 offers another definition of the smart-home concept to overcome these drawbacks.

2 Requirements for any smart-home implementation as a cyber-physical system

Many various intellectual cyber-physical devices can be used synergistically at the same time.

Many various intellectual cyber-physical devices can be used synergistically at the same time and in the same place.

Some final-beneficiary can add new intellectual cyber-physical devices, digital applications and digital services.

Some functions of the intellectual cyber-physical device may be used at the smart-home scale, for example, a stereo could be used to broadcast an alert.

Various aspects of the smart-home functioning (e.g. level of security, environmental impact, comfort, etc.) must be integrally (i.e. including all the available information) monitored, analysed, controlled, alerted and acted on.

High level of trustworthiness (includes security, privacy, safety, reliability, and resilience) of any smart-home implementation.

3 System-forming considerations for any smart-home implementation

Note: The highlighted texts below are the essence of system-forming considerations.

The guiding motif of the smart-home system domain is that all the intellectual cyber-physical devices within a particular smart-home implementation must work together as a system. Explicit systems architecting and engineering is only a way to achieve security and operational excellence of smart-home implementations. In other words, the role of any smart-home implementation is to make a “forest” from individual “trees” (i.e. intellectual cyber-physical devices).

The key architectural decision about the smart-home reference architecture is that two primary concerns, namely, IoT (i.e. intellectual cyber-physical devices ) and smart-home, are separated. Because each intellectual cyber-physical device is, actually, a cyber-physical system then the smart-home is a digital system which includes many Thing-as-a-System (TaaSy) and is aimed for improving functioning of people’s home as a system.

Thus, it is possible to consider Smart-Home as a System of Systems (SHaaSoS). The SHaaSoS primary parts are:

final-beneficiaries;

other people involved in the smart-home lifecycle;

various TaaSy, and

various digital services and digital applications.

Technically, the SHaaSoS is a smart composition of various, even non-existing yet, TaaSy. The SHaaSoS as a composition environment must be also very adaptive, flexible and secure, for example:

recognise some functionality of TaaSy as essential for the whole system;

allow different functional domains to cooperate: for example, healthcare domains may use video surveillance functionality from the security domain;

isolate, at the same, various functional domains, subsystems and TaaSy, and

integrate everything via explicit and machine-executable processes.

Any SHaaSoS may interact with many external (relatively to a particular smart-home system) networking actors.

Considering that many TaaSy may be added to and removed from the SHaaSoS, the later must be able to control the lifecycles of all its TaaSy. This is something likes configuration management in ITIL.

with the SHaaSoS of a particular home to achieve common goals of energy consumption, to inform about available food, etc.

The fulfilment of some of those digital contracts may require the usage of the Internet. Thus, the TaaSy fridge must be able to “demonstrate” to an in-house Internet router that the TaaSy fridge has rights to exchange data with some external digital services. Any data exchange with other digital services will be prohibited by the in-house router.

Any SHaaSoS itself follows its own digital contracts with people who live in a particular home. Please note, that any SHaaSoS is a bit “more” complex than a major-domo (or castellan, concierge, chamberlain, seneschal, mayor of the palace, maître d'hôtel, head butler and chief steward), because any SHaaSoS has its own contracts with its producer and its supporting services.

In smart home systems it is mandatory to consider the 3D geometry of any smart home because some functions are location-dependent (e.g. the same room); also some TaaSy may be mobile. Another very important factor is the time, because something must occur at a particular time, after some time, etc. The both factors, time and place must be integrated.

Potentially, each the behaviour of each final-beneficiaries must be planned, monitored and anticipated because some functions may operate differently when final-beneficiaries are in groups or individual. Imagine that each final-beneficiary has a trajectory in place x time space and those trajectories may intersect.

Coordination group to execute digital contracts between various networking actors, TaaSy and SHaaSoS itself;

Managerial group to reconfigure the SHaaSoS, and

Operational group to maintain the proper functioning of the SHaaSoS.

5.2 Functional viewpoint

The smart-home system domain has the following functional domains: security, food & cooking, health, communication, comfort, entertainment, cleaning and maintenance.

Each of those functional domains brings its own TaaSy and usually contributes to some systemic groups.

5.3 Operational patterns viewpoint

Two followings operational patterns are mainly used by the SHaaSoS:

Observe, Orient, Decide, Act (OODA) ( see https://en.wikipedia.org/wiki/OODA_loop ). This pattern is used to detect important events to be reacted with some actions (actually, initiated processes). It is illustrated in the “Event-processing viewpoint”.

Coordination, Event Streams, Analytics, Rules (CESAR). This pattern is used after the OODA pattern because a process (initiated by the OODA) must coordinate some activities, continuously monitor the current situation, make some predictions via analytical tools, and select the best next actions in accordance to existing rules.

This architecture is optimised for flexibility (separation of functionality into units-of-deployment), diversity (each SHaaSoS is different), uniformity (to avoid reinventing the wheel) and security (explicit and machine-executable processes).

5.6 Processes (flow of control) viewpoint

Potential processes in the coordination group are the following:

Adding a digital contract to the repository of digital contracts

Validation of a digital contract

Execution (running) of a digital contract

Control (including monitoring) of a running digital contract

Execution of individual activities within a running digital contract

Suspension of a digital contract

Resuming of a suspended digital contract

Termination (cancellation) of a running digital contract

Archiving of a digital contract

Removing a digital contract from the repository of digital contracts

5.7 Services viewpoint

All functionality is available as digital services and microservices. All of them have APIs which are developed under the same guidelines (a reference to be provided).

6 Conclusion

To achieve this, data formats and APIs must be flexible enough to be able to add more and more complex TaaSy. Thus, standardization of data formats and APIs must be based on the following practices:

7 ANNEX Functions of home (as an example)

Protective - Home gives us protection from outside heat and cold, sun, wind, rain, etc. It also gives protection to small children and old people who need special care.

Economic - Your home facilitates income generating activities like pickle or papad making or any other similar activity. Families also save money by staying together and sharing everything available. The money thus saved can be more effectively utilized elsewhere.

Religious - A home provides a place for a number of religious activities. You celebrate various festivals while staying in a home.

Educative - A home is the centre of family life. A child’s basic education starts from the home, which helps in the development of personality.

Social - A home facilitates meeting with other people and promotes social interaction.

Affectional - Home is a place where all family members stay together with love and affection.

Status-giving - You enjoy a particular status in the society if you are staying in a home.

A good source of home internal activities to be potentially automated comes from roles of staff who are working for rich people. Normal people would like that, such services will be carried out by appliances or robots or B2B partners.

A reigning UK monarch typically had 1,000 staff in the royal household. The biggest department was the Lord Chamberlain’s department, which had on average 700 staff and was responsible for the ceremonial and social life of the Court. Traditionally, employees in this department included the ‘above stairs’ servants such as pages, craftsmen, chaplains, physicians, musicians, watermen and Yeomen of the Guard. There is also a number of fabulous occupation titles listed among the royal household staff:

Chocolate Maker to the Queen

Yeoman of the Mouth to Her Majesty Queen Mary in the Pantry

Necessary Woman to the Corridor and Entrance Hall

Keeper of the Lions in the Tower

Moletaker

Master of the Game of Cock Fighting

Groom of the Removing Wardrobe

Groom of the Stole

Strewer of Herbs

Laundress of the Body Linen

8 ANNEX Influencing factors (as an example) to be considered by the smart home system domain

Housing preferences change

The “concept of dwelling” is going to be changed as general housing preferences among customers, designers and real estate managers, including lifestyle/activity changes and spatial changes

internal spatial organisation

space saving

flexibility in between

Environmental trends change

“Energy-Saving” will increase due to home automation and energy monitoring and controlling.

“Material-Saving” will increase due to the reduction in number of device.

“Time-Saving” will increase.

“Transportation-Saving” between home and workspace or other spaces will increase so traffic flows and pollution are going to be controlled.

“Land-Saving” will increase and rapid extension of cities will be controlled.

Economic trends change

“Space saving with higher quality” is going to be increased as general economic trends

2016-12-08

The patterns OODA (Observe, Orient, Decide and Act) is very well know ( see https://en.wikipedia.org/wiki/OODA_loop ). But what’s happen AFTER it? In other words, is it possible to recommend a generic behavioral pattern when an action is taken by the OODA pattern?

This blogpost proposes a Coordination, Event Streams, Analytics, Rules (CESAR) pattern. This pattern is used after the OODA pattern because a process (initiated by the OODA) must coordinate some activities, continuously monitor (from many different sources) the permanently changing situation, make some predictions via analytical tools, and select the best next actions in accordance with existing rules.

TaaSy gateway: networks and connectivity adapter for various TaaSy devices which may use various networks (e.g. Bluetooth, cables, etc.). This gateway collects and homogenizes the various mechanical signals or network-based data streams into manageable data.

2 Essential views of Reference Architecture (RA)

2.1 Viable system model viewpoint

The Viable System Model (VSM) – see https://en.wikipedia.org/wiki/Viable_system_model – describes principal functions and flow of data between them for viable (i.e. autonomous) systems. A viable system is composed of five interacting subsystems which may be mapped onto aspects of organizational structure.

Viable system model

By applying the VSM for TaaSy, it is reasonable to say that Systems 4 and 5 are almost absent because they are carried out by the owner and the manufacturer of the Thing. Systems 2 is about of routine coordinating various activities and System 3 is about exceptions handling and performance management. Considering the digital nature of TaaSy, Systems 2 and 3 can be combined together as well as necessary support for System 4.

This architecture is optimised for flexibility (quick delivery of new functionality), diversity (each TaaSy is different), uniformity (to avoid reinventing the wheel) and security (separation of functionality into units-of-deployment).

Such a platform may be deployed at the same
time in cloud-computing, local-computing and fog-computing environments. Of
course, different functions will be in different environments; on the contrary,
some software may be the same in all three environments.

Multi-environment usage of the platform

2.4 Processes (flow of control) viewpoint

Potential processes in operational and managerial domains are the following:

ITIL service design (partially)

ITIL service transition

ITIL service operations

ITIL CSI (partially)

COBIT DSS01 Manage Operations

COBIT DSS02 Manage Service Request and Incidents

COBIT DSS03 Manage Problems

COBIT DSS04 Manage Continuity

2.5 Services viewpoint

All functionality is available as digital services and microservices. All of them have APIs which are developed under the same guidelines.

3 TaaSy collaboration patterns in the IoT

The specific feature of IoT is the ability of TaaSy(s) to collaborate between them and other networking actors.

3.1 Point-to-Point (P2P)

The P2P collaboration pattern is about ad-hoc interactions between one networking actor and a particular TaaSy.

4 Conclusion

To manage the security of IoT, it is mandatory to define explicitly individual and collective behavior of Things. This is addressed in the proposed reference architecture by intensive used of processes, internally within a Thing-as-a-System and between them as digital contracts.

1 Introduction

The recent IoT-based DDOS attack confirmed the urgent necessity for more serious and systemic integration of the IoT into our civilisation. At present, many devices from the IoT “world” act as wild animals thus being dangerous.

Each member in our civilisation has to follow many rules & regulations & laws depending on contexts and his/her roles as citizen, husband/wife, father/mother, driver, employee, etc. Those rules and laws are wrapped as, usually, time-bound contracts. Just using a taxi is a short-time contract with its rules for a passenger and a driver.

IoT as cyber-physical systems must follow some rules & regulations & laws to become a very useful member of our civilisation. The famous example of such laws is “The three laws of robotics”.

Let us apply this practice of contract-based rules & regulations & laws to the Internet of Things – let us teach Things to follow their contracts thus domesticate Things.

2 External digital contracts

For example, a future household fridge will have, as minimum, five types of external contract simultaneously:

with People who are living 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, and

with some other Things within a particular household to achieve together some goals of energy consumption.

The fulfillment of some of those contracts requires the usage of the Internet. Thus, the Fridge must be able to “demonstrate” to the in-house network Router that the Fridge has rights to exchange data with some Internet-based services. Any data exchange with other internet-based services will be prohibited by the Router.

3 Internal digital contracts

In addition, being a cyber-physical system, a Thing must follow many internal contracts. Governance of all software components must be carried out as contracts for requesting a change, approval of a change, etc. Actually, all the typical IT governance and operations processes are already well-defined in COBIT, ITIL and IT4IT. They, being designed for IT departments, have to be scaled-down to the needs of Things. Even a minimalistic patch-management processes will be a huge improvement.

Considering that, capabilities of particular Things may be rather different, some kind of a “majordomo” Service may be necessary to execute various digital contracts; Things will be participants in their workflows.

Also, in complex households some coordination between various digital contracts must be carried out (e.g. no preventative maintenance during receptions). This is a natural job for a “majordomo” Service. Obviously, it has its own digital contracts with the People who are living a particular household.

5 Conclusion

The proposed use of digital contracts, explicit governance and blockchain can make an impression that it will increase the complexity of IoT. Fortunately, this is not correct, because although more components will be necessary, the links between them become explicit.

2016-10-27

There is a Russian proverb “Ugovor dorozhe deneg” which means “Contractual agreement is more important than money”. Breaking a contract is a huge risk (reputational, financial, etc.) that is difficult to “pay back”. Also, having business with an unknown business party may be a high risk because of anti money laundering.

Blockchain (as the best, so far, records storage) provides integrity and traceability (see “Beauty of #blockchain - doveryai, no proveryai (trust but verify)” http://improving-bpm-systems.blogspot.ch/2016/10/beauty-of-blockchain-doveryai-no.html ). This is a mandatory component of digital contracts as enablers of the safe digital economy, but not sufficient one. Let us see in a few following scenarios what is missing yet for the trustful sharing of data and documents in digital business transactions within digital contracts.

Variant 1 - P2P anonymous

As simple as giving a few coins to a poor person.

Variant 2 - P2P with zero-knowledge proof

Transaction participants may verify that their counterparts are a real and respectable person. In case of problems with a transaction, its participants can be reveal by court’s request.

Variant 3 – simple B2B

Some documents (e.g. offer, payments, certificates of digital assets, etc.) must be exchanged between participants. Thus they must be managed properly within each transaction by specialised “chains” as docs-chain and assets-chain. Their lifecycles are bounded by the relevant transaction. Actually, they are temporary secured storages that may use the blockchain for storing digital hashes of their content (see also “Electronic Health Records ( #EHR ) implementation with #blockchain, #BPM, #ECM and #platform” http://improving-bpm-systems.blogspot.ch/2016/07/electronic-health-records-ehr.html ).

Variant 4 – B2B and partners

If the PartyB has a partner (PartnerB1) to produce PartyB’s goods then some documents from the PartnerB1 may be embedded (like a Russian doll) into the documents from the PartyB. In some cases, such documents may be anonymised.

To be able to run comprehensive monitoring and, potentially, some global optimisation, all the partners, all related data and all related documents must be in one secured storage of records, ideally, blockchain-based.

Conclusion

By looking at those variants, it is prudent to say that blockchain is only one of many serious issues to be addressed and architecture together to enables the digital economy. Fortunately, the current hype around blockchain is accelerating the better understanding of many things to be done together and, I hope, in well architected way.

2016-10-07

The aim of this document is to provide a big picture of voting with the use of various modern technologies, primarily #blockchain. This technology is ideal to implement the “doveryai, no proveryai” (trust but verify) principle to achieve the trust.

1 Basic concepts

Each vote sheet has its unique ID which has its address in the Voting BlockChain (VBC) as VBC-ref1, which also encoded as QR-code-1.

2 Remote voting through the Internet

A Registered Voter (RV) receives a Voting Sheet (VS) via a secured channel or in a secured envelope.

The RV using a Server-Less App (SLA) in his/her internet browser.

RV:

Opens the VS

Fills it

Hits the button “FILLED”

SLA:

Uploads the VS and some metadata into the VBC at VBC-ref1

Asks the VC to verify the voting results at VBC-ref1

RV:

Scans QR-code1 (e.g. mobile) to see the voting results at VBC-ref1 (optional)

Hits “OK” (and may save VBC-ref1)

SLA:

Starts a smart-contract to release VBC-ref1 to the voting authorities AFTER the ballot period is over

System is a set of interacting discrete parts organised as a whole which exhibits (as the result of interaction between the parts) some emergent characteristics indispensable to achieve one or more stated purposes.

Any system-of-interest has an architecture which is a totality of fundamental concepts or properties of a system in its environment embodied in its discrete parts and relationships, and in the principles of its design and evolution. Architecture of a system-of-interest maybe accidental or intended depending on the way of constructing this system. In any case, any serious change in an enterprise-of-interest implies changing in its EA.

Enterprise is an emotive or motivational structure, bounded by a shared vision, shared values and mutual commitments for joint efforts to achieve one or more stated purposes. An enterprise is realized by an organisation which is a legal structure, bounded by rules, roles and responsibilities. Obviously, any modern enterprise together with its organisation is a socio-technical system (in which the interaction between people and technology is a dominant consideration). Also, an enterprise is a self-evolution system.

Thus Enterprise Architecture (EA) is architecture of an enterprise as a socio-technical system. (Although, it is correct, it is a useless definition for many people). The main and unique power of EA is the ability to objectively estimate effect (cost, benefits and risks) of potential internal changes. For example, what could be the effect of changes in a business unit which necessitates some modifications in some enterprise and departmental applications?

A good EA is the primary enabler for any internal transformations of different extent: project, program and strategy. For any transformation, EA is used to define and validate the future version of EA (called target architecture or blueprint). For example, a good EA can evaluate a level of implementability of a proposed strategy.

Usually, EA is described via a set of architecture viewpoints. Those architecture viewpoints define a set of model kinds which establish relationships between various artefacts: vision, mission, objectives, rules, servers, etc. Architecture viewpoints applied to a system-of-interest generates views whcih comprise some models.

Ideally those viewpoints are aligned, but in the reality it is not the case because different viewpoints are created by different people.

Because of the socio-technological nature of enterprises and their high-level of complexity, EA historically considered as two domain architectures:

Business architecture is architecture of an enterprise considered as a social system for delivering Value (as products and/or services). Main artefacts in business-centric viewpoints are: mission, vision, products, services, directives, objectives, processes, roles, etc.

IT-architecture is architecture of an enterprise considered as an IT-system. Main artefacts in IT-centric viewpoints are: IT tools, processes, and methodologies and associated equipment employed to collect, transform, transport and present information.

The dependency between those architectures is, in theory, very straightforward. The business architecture defines the IT-architecture. But, in practice, very often, the IT-architecture evolves much slower than the business architecture, thus there is always a gap or misalignment between them.

To avoid this gap, it is necessary:

version all the artefacts during their lifecycle;

evlove artefacts to become digital, externalised, virtual and components of clouds;

To be efficient, their work must be explicitly coordinated. Certainly, this is strongly applied to all the microservices comprise an application. Of course, it is considered that an application is a several very loosely-coupled clusters of microservices to be coordinated (for example, each such a cluster is responsible for the lifecycle of a particular business entity).

Although there is an opinion that “Service is not comprised of other services due to the independence requirement” (see https://www2.opengroup.org/ogsys/catalog/W169), it is considered that some (with bigger responsibility) microservices can be assembled from other (with smaller responsivity) microservices.

There are several techniques to implement coordination.

Orchestration

nature: centralised at design-time and centralised at run-time thus may be explicit

specific: there is a misconception that it uses only synchronous communication (à la RPC) although it may use also asynchronous communication (à la message-passing)

Choreography

nature: decentralised at design-time and decentralised at run-time thus implicit

specific: uses only asynchronous communication (à la message-passing)

Reactive streams and runnable graphs

nature: decentralised at design-time and centralised at run-time thus implicit

specific: optimised for high volume event processing

Business-process-based

nature: centralised at design time and decentralised at run-time thus explicit

specific: each case is a completely separate instance with its own lifecycle; and the process may be another microservice

3 Implementation of business-process-based coordination

Of course, it should be a DSL to define an explicit coordination (e.g. BPEL, BPMN, etc.). Using the terminology from the section 7 of [REF1], a DSL-processor may act as a specialised container for DSL-scripts. Also, some microservices which are coordinated by a DSL-script may use some specialised containers. For example, a specialised container for human-operations, a specialised container for business rules, a few specialised containers for automated-operations.

4 Conclusion

Some advantages of the business-process-based technique:

Assembled microservices have no routing logic (thus they follow SRP).

All the necessary microservices (assembled and dependent) can be instance-bound (help to predictive analytics).

All the necessary microservices (assembled and dependent) can be instantiated on demand (this minimises DEVOPS).

A particular instance may be stopped for the error-recovery without influencing other instances (operational isolation).

A few versions of the same coordination (i.e. business process) may co-exist (versioning is easy).

Different instances of the same process and their may be executed on different nodes (linear scaling out).

Considering the SRP is one of commonly-agreed characteristics of microservices, the “Smart endpoints and dumb pipes” characteristic is in the direct contradiction to the SRP. Making endpoints (i.e. microservices) “smart” requires that they have to have many various functionality in addition to their “core” functionality. Thus the question is how to allow simplify microservices and thus simplify the life of software developers.

I used several types of nested primitive containers:

generic – JVM on top of any popular OS (experience in programming of portable software helped);

language-specific – Jython on top of JVM to run small Python programs, and

specialised – particular environment on top of Jython on top of JVM; this environment considerably simplified the development of automation and integration functionality.

With each nested container, my microservices became more functional and easier to evolve. Finally, each of them was as small text fragments stored in a source version control tool; they were loaded into containers dynamically (at the run-time) and they could dynamically load some modules. Devops was minimal.

3 Conclusion

Keep pipes dumb (no logic!).

Create your own smart containers (maximum housekeeping and specialisation) from some standard ones.

Help your microservices be functionally minimalistic (thus simplify the life of your software developers).