Thing-as-a-System reference architecture for #IoT

This article is a continuation of “Domesticate the #IoT as cyber-physical systems” article ( see http://improving-bpm-systems.blogspot.ch/2016/11/domesticate-iot-as-cyber-physical.html ). It uses the systems approach to define a reference architecture for Thing-as-a-System (TaaSy) which forms the IoT.

1 Basic concepts

Networking actors are humans, digital services, digital applications and systems interacting over the Internet.

Networking human actors: owner, manager, operator or customer.

Cyber-Physical System (CPS) is a system (comprises physical and computational discrete parts) that can interact with the physical world and networking actors.

Examples of CPS include autonomous automobile systems, process control systems, robotics systems, automatic pilot avionics, data acquisition and control systems for particle detectors at CERN, etc.

CPS for IoT is an CPS which makes a Thing as a System (TaaSy)which is accessible, programmable and collaborative via digital services.

Here is clarification of mentioned above characteristics of TaaSy:

1. Being a system, any TaaSy can carry out its essential functions without being rely on any other TaaSy(s).
2. Any TaaSy is a networking actor.
3. Any TaaSy provides some digital services for networking actors (as GUI for humans and as API for others).
4. Functioning of any TaaSy can be programmed (to some extent) by authorised networking actors.
5. Any TaaSy can collaborate with some networking actors in accordance with some digital contracts ( see “#IoT as a system of digital contracts” http://improving-bpm-systems.blogspot.ch/2016/08/iot-as-system-of-digital-contracts.html ).

TaaSy physical parts: TaaSy devices, computational hardware parts, networking hardware parts.

TaaSy device types: sensor or actuator.

TaaSy cyber parts: various software parts.

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. 

2.2 Functional domains viewpoint

TaaSy functional domains:

• physical – the thing and all TaaSy devices;
• device drivers to connect cyber parts with device-specific and network-specific equipment;
• supporting to provide typical functionality of a digital system (e.g. logging, monitoring, etc.);
• enabling to provide essential shared functionality (e.g. data handling, collaboration, process management, decision management, analytics, etc.);
• purpose-specific to provide core business functionality,
• IoT-specific to execute contracts between various networking actors, and
• managerial to reconfigure the system; [look at COBIT, ITIL, IT4IT]
• operational to maintain the proper functioning of the system. [look at ITIL, IT4IT]

Functional domains viewpoint

Standard networking (i.e. over the Internet) and commodity computing software and hardware parts are deliberately not discussed.

There are also several cross-domain functions which address typical quality requirements:

• security (confidentiality integrity availability)
• data and services interoperability
• safety
• resilience
• privacy

2.3 Application architecture viewpoint

Application architecture of any TaaSy follows the platform pattern ( see http://improving-bpm-systems.blogspot.ch/search/label/%23platform ).

Such a platform comprises drivers, supporting and enabling functionality as well as a layer with TaaSy-specific functionality.

Solutions which are built on top of this platform are from the following functional domains: operational domain, managerial domain, purpose-specific domain and IoT-specific domain. Those solutions use patterns, tools, services available in the platform. Preferably, those solutions are assembled from microservices ( see http://improving-bpm-systems.blogspot.ch/2016/08/better-application-architecture-apparch.html ).

Application architecture viewpoint

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.

3.2 Majordomo

The majordomo collaboration pattern is about interactions between master (i.e. Majordomo TaaSy) and slaves (other networking actors but, primarily, TaaSy).

3.3 Digital contracts

The digital-contract collaboration pattern is about interactions between several networking actors as peer (see http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html ).

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. 

Thanks,
AS