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.