— Scan the QR code —Join the architecture gathering group
Students interested in technology can join the group (Note: Java)
There are currently many discussions online regarding the Internet of Things (IoT), but most are focused on theoretical introductions or hardware and communication-related issues, such as IoT modules and communication protocols like MQTT, XMPP, and NB_IOT. I personally believe that these are only a part of the IoT. Managing IoT devices, user management, packet parsing, and big data visualization are also very important aspects of IoT modules. Therefore, the author would like to share a basic architecture for an IoT platform built in the cloud, based on their own work experience, and how to develop an IoT platform step by step based on this architecture.
The IoT platform should be built on current internet and communication technologies, without relying on specific hardware modules, allowing users to easily connect to the IoT based on their own device technology architecture. The following diagram illustrates the core architecture of the IoT:
1. Four Core Modules
There are four core modules in the IoT: device management, user management, data transmission management, and data management. Only with these four core modules can we consider it a complete IoT platform, and all other functional modules are extensions based on these four core modules.
1.1 Device Management
-
Device Type Management: Defines the type of device, generally defined by the device manufacturer. The most important aspect of a device type is its association with a unique data parsing method, data storage method, and device specifications. Only the device manufacturer can edit the data related to the device type, while the user can only browse related information about the device type.
-
Device Management: Device management defines the relevant information of the device. Each device must define its device type, which has user attributes. After the device is sold and activated by the user, the device belongs to the user, who then has complete control over the device, including which data can be viewed by the manufacturer and other users.
1.2 User Management
-
Organization Management: An important concept in the IoT platform is organization. All devices, users, and data are managed based on organizations. The device manufacturer is an organization, the device user is another organization, and a household can also be considered an organization.
-
User Management: Users are the personnel composition under an organization. Each organization has an administrator role, who can add different users to their organization and assign different permissions to each user. A user can also belong to multiple organizations and play different roles in each.
-
User Groups: A group of users, also managed based on organization user groups, where users in the same group share the same permissions.
-
Permission Management: Similarly based on organizational permission management, mainly focusing on object-level permission details, such as device browsing permissions, which can control whether each user can see this device; device data browsing permissions define whether the device’s operational data can be viewed.
1.3 Data Transmission Management
1.31 Basic Format
Data transmission management defines the data transmission protocol for a type of device, with the basic format:
-
Each device has a unique serial number assigned by the manufacturer, as each manufacturer has its own coding format; thus, this serial number does not have a fixed format.
-
Command Code: the purpose of this data, such as uploading data or commands sent from the server to the device, generally using a two-digit numeric code from 00 to 99.
-
Data: This part contains the data of this message. Each protocol can define different parsing methods. For example, when the server receives a data packet, it will parse the data fields according to the pre-defined parsing method and store them according to the rules.
1.32 Data Parsing Definition
-
Each device type can define multiple commands, each with its own parsing method. The organization’s administrator can define parsing methods for their device types.
-
After the server receives the data, it will automatically parse the data fields according to the pre-defined parsing method.
-
Device developers must develop their device’s parsing code according to the data format defined on the IoT platform.
-
Data fields are transmitted in HEX format.
1.33 Data Storage
Storage must support a distributed architecture, allowing different storage locations to be defined for each device. In Diego IoT, data storage uses MySQL databases, allowing different devices to be stored in different MySQL databases.
Each piece of data defines a lifecycle, and after the lifecycle ends, the system will automatically delete it.
1.4 Data Management
-
Permission Management: Data permissions are crucial in the IoT platform. Who owns the data is a very important concept; only the device owner can define who can see the data.
-
Big Data: IoT data itself is massive. We can use some open-source big data platforms to achieve visual analysis of the data. Only analyzed data is valuable data.
-
Data Export: Users can export data to their local for analysis.
2. Network Communication
Currently, all communications between cloud-based IoT platforms and devices are fundamentally built on the TCP/IP protocol, merely repackaging the data packets. Based on this, we can use WiFi and 4G to facilitate communication between devices and cloud platforms. However, communication between devices can occur via WiFi, Bluetooth, Zigbee, etc. Below are a few common communication architectures.
2.1 Based on Mobile 3/4G Communication
This architecture is the simplest; devices connect to the internet like our mobile phones, primarily considering the following points:
-
Each device requires a SIM card, which can be obtained from mobile service providers specifically for IoT.
-
Data traffic issues: This architecture entirely relies on data traffic; if there is video data, it will incur significant traffic costs, which must be considered.
-
Communication quality issues: This entirely depends on the mobile service provider’s network coverage, similar to our mobile phones. In some environments, there may be no signal, making it impossible to send or receive data.
2.2 Based on WiFi Local Area Network
This architecture is suitable for all IoT devices operating in a local environment, where devices connect to a router via WiFi or wired connections, and the router connects to the IoT server, similar to how we set up a WiFi router at home. Key considerations include:
-
Smart devices within the local area network do not have independent public IPs, only a local IP. This means devices can send data packets directly to the IoT server, but the IoT server cannot send data packets directly to devices since they lack a public IP.
-
Power consumption issues: For devices using WiFi, it is preferable not to use battery power, as WiFi consumes a lot of power.
-
Interference issues: If deploying this architecture in large factories, it is essential to consider whether there are strong interference sources, such as electromagnetic interference. Industrial-grade routers, which generally have stronger anti-interference capabilities, can be used.
2.3 Based on Bluetooth Communication
Generally, Bluetooth-based IoT will consider deploying through a Bluetooth gateway.
Due to its point-to-point communication method, Bluetooth must consider the following issues:
-
Bluetooth gateway capacity: how many Bluetooth devices a Bluetooth gateway can connect to, depending on how many Bluetooth devices are used in the gateway.
-
Bluetooth pairing issues: Bluetooth devices must pair before communicating. If automatic pairing can be achieved, it will be easier to deploy on a large scale; if not, it will be a hassle.
Another scenario is for IoT devices that do not need to be online continuously but need to connect to the server under specific conditions. In this case, we can use the Bluetooth function of mobile phones to connect devices to the IoT.
Bluetooth bracelets are a typical application mode of this architecture.
2.4 Based on Zigbee
ZigBee is also a popular networking mode, designed for sensor networking, with strong low-power capabilities.
Zigbee networks rely on Zigbee gateways, which are themselves Zigbee devices. Zigbee devices are self-organizing networks. Important considerations during use include:
-
Data volume issues: the capabilities of the device and power consumption are contradictory. Since ZigBee is an ultra-low-power solution, its communication capabilities are also limited. It is suitable for collecting sensor data, such as temperature and humidity, but not for large data volumes like video.
This section mainly introduced several common IoT deployment architectures. As for IoT protocols, there are many articles online, so I won’t elaborate here.
3. Smart Devices
The original intention of Diego IoT design is to free smart device developers from dependence on special modules. For smart device development, as long as networking capability is present, there are no special requirements.
Click to like, and this year you will get a raise ^-^↓