A Crash Course on Industrial Internet of Things Architecture

01

—

Paradigm Model

The development of an industry generally starts with unregulated growth, followed by gradual standardization.

The Industrial Internet of Things is no different; first, there are numerous and varied application systems appearing, which allows for the abstraction of a conceptual model (highly abstract);

Based on the conceptual model and the common features/requirements of these diverse application systems, a standard system architecture (reference standard) is guided out, indicating that various standards in this industry are already on the way or even taking shape;

Subsequently, players in this industry build or improve their product’s application system architecture (product architecture) based on the standards, thereby outputting or refining their application systems (products).

Therefore, the first architecture we examine today is called: the Paradigm Model; we attempt to include various Industrial Internet of Things architectures within this model to build our knowledge system.

Note: This paradigm model is modified by CC based on the national standard “Internet of Things Reference Architecture | GB/T 33474-2016“

Conceptual Model

Different countries and organizations are striving to build their own “Industrial Internet of Things standards.” The conceptual model and standard system architecture of the Industrial Internet of Things that we are currently studying are based on our national industry standards.

The ‘conceptual model’ in the diagram below originates from our national standard “Internet of Things Reference Architecture | GB/T 33474-2016”.

Note: ‘Domain’ is a collection of entities with specific purposes; ‘Associative Relationships’ are not introduced here; this model is the conceptual model of the Internet of Things, which should be understood here as the conceptual model of the Industrial Internet of Things

• User Domain: A collection of entities of different types of IoT users and user systems.

• Target Object Domain: A collection of entities of objects that IoT users expect to obtain relevant information or perform related controls.

• Perception Control Domain: A collection of hardware and software systems that obtain information from perception objects or control objects.

• Service Provision Domain: A collection of hardware and software systems that realize basic IoT services and business services.

• Operation and Maintenance Control Domain: A collection of hardware and software systems that realize IoT operation maintenance and regulatory compliance supervision.

• Resource Exchange Domain: A collection of hardware and software systems that realize the sharing and exchange of information resources between IoT systems and external systems, as well as the centralized trading of IoT system information and services.

Standard System Architecture

This standard system architecture is constructed based on the ‘conceptual model’, from the perspective of functional system composition.

Combining this diagram with the seven functional domains of the ‘conceptual model’ above, I believe everyone will have a deeper understanding.

Application System Architecture

The first four sections are abstract knowledge learning, and the ‘conceptual model’ and ‘standard system architecture’ are too abstract to truly help us implement products from a business perspective.

So, what is the ‘application system architecture’? Literally, it means an architecture that can be applied; there can be different architectures from different perspectives, with different emphases; at the same time, the architectures of different players will also vary, but they are basically similar.

Product managers often focus on the business function perspective of the ‘system architecture’, mainly reflecting the position of modular products/systems in the architecture and their association with other products/systems.

This time, CC will also provide the ‘network architecture’ and ‘technical architecture’ to clarify the Industrial Internet of Things.

5.1 Business Perspective: System Architecture

Not seeking completeness, but seeking refinement! This architecture is constructed from a SaaS perspective.

It is overall divided into: Edge, Boundary, Cloud.

1. Edge: Corresponds to the target object domain, which is the object from which you want to collect data, generally devices, logistics vehicles, etc., which are the objects generating data.

2. Boundary: Corresponds to the perception control domain, which is at the ‘edge’ of the ‘end’; although the ‘end’ generates data, it cannot transmit or store data, so there often needs to be middleware; for example, the data from the die-casting machine is collected from its PLC, or controlling the actions of the die-casting machine also requires PLC, while some PLCs cannot connect to upper-level systems, so industrial gateways are also needed; the scenarios are quite complex, and you can focus on CC’s CSDN blog (you can scan the code at the bottom of this article), which has a series of articles on ‘data collection solutions’.

3. Cloud: The most basic business perspective architecture is IaaS, PaaS, SaaS.

IaaS: Infrastructure-as-a-service, this is a heavy asset model, where large companies spend large sums to build super-large servers and then rent out hard disk space;

PaaS: Platform-as-a-service, the platform does not directly create value for customers but is very important, so it can be understood.

SaaS: Software-as-a-service, this is where the user truly needs services and is willing to pay, so QQ email is a product at the SaaS layer that can be used directly by entering the website on a browser.

We will not overly break down this diagram, but from a popular science perspective, it is still important to emphasize one point: ‘The Industrial Internet of Things’ is an industry, while the red part of the above diagram is an independent product, such as ‘Industrial Internet of Things platform’ is a type of product.

Thus, it can be seen that the Industrial Internet of Things can have many applications, with different players focusing on different aspects; some excel at data collection, so they will focus on ‘industrial gateways’ or ‘edge computing’; some who do algorithms will study ‘predictive maintenance’; and some who only focus on energy data will do ‘energy management’.

Of course, you will find that the ‘Industrial Internet of Things platform’ is the core product that connects upstream and downstream.

5.2 Interconnectivity Perspective: Network Architecture

Do you remember the definition of the Industrial Internet of Things in ’01: Concept’? CC marked three key words: network interconnection, data communication, system interoperability.

What we often call interconnectivity actually needs to be split into two parts: network interconnection and data communication. This requires some knowledge of the OSI model, which you can learn by clicking on the image below:

1. Network Interconnection: Corresponds to the physical layer, link layer, network layer, and transport layer in the OSI (Open System Interconnection Reference Model); it refers to the connection between entities via a network to achieve data transmission;

2. Data Communication: Corresponds to the session layer, presentation layer, and application layer of the OSI reference model; it refers to establishing standard data structures and specifications so that the transmitted data can be effectively understood and applied.

The diagram below is the ‘network architecture’ of interconnectivity in the Industrial Internet of Things, sourced from the “Industrial Internet of Things Interconnectivity White Paper”.

5.3 Technical Perspective: Technical Architecture

Below is a technical architecture case provided for reference and learning:

Application System Case

Due to space limitations, we will not provide a detailed introduction to the “Industrial Internet of Things platform” system here; a separate article will be published later to introduce it, and below are some screenshots of the ‘Industrial Internet of Things platform’ made by CC.

Industrial Internet of Things platform directory

Diagram of the working principle of the functional modules of the Industrial Internet of Things platform

==CC says==

Is the design of a B-end product this complex? Does it have to be analyzed and examined step by step from the height of the paradigm, creating a bunch of architecture diagrams?

Of course not! The core ability of a junior B-end product manager is simply one word: copy! If what you copy is still quite useful, then you are a senior product manager.

Architecture has a very basic benefit for junior B-end product managers: it is a way of reporting upward!

1. “Industrial Internet of Things White Paper (2017 Edition)”: Released by the China Electronics Standardization Institute in September 2017

2. “Internet of Things Reference Architecture | GB/T 33474-2016”: National standard released on December 30, 2016
3. “Industrial Internet of Things Interconnectivity White Paper”: Released by the China Electronics Standardization Institute in September 2018

==Follow · CSDN Blog==

Follow ‘CC Talks Nonsense’

Let’s grow into excellent B-end product managers together!