IoT Technology Selection and Deployment for an Automated Quality Inspection Center

1. Background

In the ZhiZhi Smart Inspection Center, rapid business growth has led to an increasing variety of automated testing hardware and devices (phones, pads, etc.) for automated testing.

The following images show several of the current automated testing devices.

During early development, the design and development of each automation capability focused on individual functions, lacking a unified architecture, which resulted in high maintenance and iteration costs.

High system maintenance cost: Diverse communication protocols among devices caused a bloated system.

Insufficient device status monitoring: Failures were not detected promptly, increasing downtime.

Data latency and incompleteness: Offline devices made real‑time, complete data hard to guarantee.

High device maintenance cost: Manual maintenance was inefficient and expensive.

Growing integration of automation capabilities: As business expands, the system must orchestrate not only hardware but also testing of devices such as phones, pads, laptops.

To address these issues, the team introduced Internet of Things (IoT) technology to achieve unified architecture, lower development and maintenance costs, and provide real‑time monitoring of automation devices.

2. IoT Introduction

2.1 Opening Story

In the 1970s, Carnegie Mellon students faced a similar problem when a vending machine often ran out of cold drinks, wasting time.

In 1982, a group of students installed micro‑switches in a vending machine to report inventory and temperature over the Internet, creating the first IoT‑like device.

This early experiment inspired later research, leading to modern IoT applications such as smart homes, agriculture, and manufacturing.

2.2 What is IoT?

IoT (Internet of Things) connects physical devices to the Internet via sensors, software, and other technologies, enabling communication and data sharing. Examples include remote control of smart home devices and automatic monitoring of industrial machines.

2.3 Basic Components of IoT

Sensors and devices: Collect data and perform actions (e.g., temperature sensors, smart bulbs).

Network connectivity: Wi‑Fi, Bluetooth, cellular, etc., to link devices to the Internet.

Data processing and analysis: Cloud or edge computing analyzes collected data.

User interface: Applications or control panels for user interaction.

3. IoT Technology Selection and Deployment方案

3.1 Application‑Layer Protocol Selection

IoT protocols span device, network, transport, data link, and application layers. This section focuses on application‑layer protocols.

3.1.1 HTTP/HTTPS

Advantages: Standardized, widely supported, HTTPS provides encryption.

Disadvantages: High overhead, poor real‑time performance, unsuitable for resource‑constrained devices.

3.1.2 MQTT (Message Queuing Telemetry Transport)

MQTT is a lightweight publish/subscribe protocol designed for low‑bandwidth, high‑latency, or unstable networks.

Advantages: Light‑weight, efficient, supports QoS levels, flexible topology, optional TLS/SSL authentication.

Disadvantages: Requires a broker, long connections add network overhead.

3.1.3 CoAP (Constrained Application Protocol)

CoAP is a UDP‑based protocol designed for constrained devices and networks.

Advantages: Connectionless, lightweight, low power, suitable for low‑bandwidth, high‑latency environments.

Disadvantages: No built‑in reliability (needs extra mechanisms), security via DTLS is complex.

3.1.4 Selection Criteria and Conclusion

Key concerns for the inspection devices are stability, real‑time performance, and network cost.

HTTP/HTTPS incurs large packet sizes and high network cost.

CoAP fits resource‑constrained devices but not large‑scale bidirectional communication.

MQTT offers lightweight packets, QoS control, and reliable delivery, making it the optimal choice.

3.2 Broker Selection

MQTT brokers manage message routing between publishers and subscribers.

3.2.1 HiveMQ

High availability: Cluster deployment, automatic failover (enterprise version required).

Security: TLS/SSL, OAuth2, X.509 (enterprise version required).

Ease of use: Rich UI, extensive documentation, strong community support (enterprise version costly).

3.2.2 RabbitMQ

High availability: Clustering, mirrored queues, persistence.

Security: TLS/SSL, fine‑grained access control (configuration complex).

Ease of use: Multi‑protocol support, rich plugin ecosystem (initial setup can be complex).

3.2.3 EMQX

High availability: Native clustering, supports millions of connections.

Security: TLS/SSL, LDAP, JWT, ACL.

Ease of use: Rich plugins, visual management tools.

3.2.4 Selection Criteria and Conclusion

HiveMQ: Open‑source version limited, lacks TLS in free tier.

RabbitMQ: MQTT support is via plugin, not native, affecting performance.

EMQX: Open‑source version meets most medium‑scale needs with TLS, ACL, and clustering.

Therefore, EMQX was chosen as the MQTT broker.

3.3 QoS (Message Quality) Selection

MQTT defines three QoS levels:

QoS 0 – At most once: Minimal overhead, possible loss.

QoS 1 – At least once: Guarantees delivery but may duplicate messages.

QoS 2 – Exactly once: Guarantees single delivery, highest overhead.

For the inspection center, duplicate commands could damage devices, so QoS 2 was selected despite its slightly higher latency.

3.4 Broker Deployment方案

Three deployment models were evaluated:

3.4.1 Cloud Server Deployment

Broker runs on a central cloud server; devices connect over the Internet.

Advantages: Unified management, simplified monitoring.

Disadvantages: Higher latency due to cross‑region traffic.

3.4.2 Local Deployment

Broker installed within each inspection center’s LAN.

Advantages: Near‑zero latency.

Disadvantages: Multiple brokers increase operational complexity.

3.4.3 Hybrid Deployment (Edge Computing)

Edge nodes handle local traffic and sync with a central cloud broker.

Advantages: Extremely low latency, offloads central load.

Disadvantages: Management complexity at large scale.

3.4.4 Selection Criteria and Conclusion

Factors considered: network latency across regions and system scalability.

Cloud deployment adds ~2 seconds per device flow due to ~50 ms inter‑region latency.

Local deployment yields almost zero latency, greatly improving responsiveness.

Hybrid deployment offers the best balance of low latency and load distribution.

Performance tests (QoS 2, 1 KB payload) showed:

Client Connections

Local Latency

Cloud Latency

10

6 ms

42 ms

100

7 ms

47 ms

1000

10 ms

57 ms

Given the current requirements, the team adopted the local deployment model while planning a future hybrid edge‑computing approach.

4. Conclusion

The introduction of IoT technology solved many traditional inspection challenges, unified communication protocols, and enabled efficient, stable operation of the smart inspection center.

Through systematic evaluation of application‑layer protocols, MQTT brokers, and QoS levels, the optimal technical stack was selected, and a local deployment architecture was implemented to achieve low latency and high reliability.

Future work will focus on hybrid edge deployment to further reduce regional latency and support scaling of additional automation devices.

5. References

https://mqtt.org

https://www.emqx.io

https://www.sciencedirect.com/science/article/pii/S1389128621003364

https://www.kepuchina.cn/article/articleinfo?business_type=100&classify=2&ar_id=455497

About the author Wen Junting, backend team of ZhiZhi R&D Center – responsible for backend development of the ZhiZhi quality‑inspection automation project.