实现自己的AI视频监控系统-第三章-信息的推送与共享1
文章目录
- 前言
- 一、基本的信息通信机制及简介
- 1. 通信基础：TCP与UDP的本质
- 2. 不同设备类型的通信方案
- 2.1 服务器间通信
- 2.2 嵌入式设备通信
- 2.3 工业设备与控制通信
- 3. 协议选择决策矩阵
- 4.系统通信架构示例
- 总结
- 下期预告
前言
经过了第一章多路视频展示系统设计和第二章AI分析模块的嵌入，我们设计的AI视频监控系统已经具备了基本的框架和雏形，具备基本的视频展示和AI分析功能，但是该系统仅有内部信息的流转，缺少有效的社会或生产价值，因为我们并没有有效的利用AI视频分析系统有效的分析结果，如将报警信息推送至信息汇总中心，及时消除报警威胁，或是将AI视频监控系统信息数据推送至数据分析中心，依靠大数据技术和数据分析算法有效提高信息的利用效率。所以在本章节我们需要完善AI视频监控系统的信息共享功能，具备数据生态圈的接入能力，使之成为工业生产、社会行为规范等领域的有力工具。
一、基本的信息通信机制及简介
一个完整的AI视频监控系统要实现信息共享与生态接入，必须根据不同的设备类型、应用场景和性能要求，采用多样化的通信机制。现代工业通信是一个分层体系，需要从传输层、协议层和应用层综合考量。本节将深入分析各类设备的通信需求，并详细介绍相应的通信协议与技术。
1. 通信基础：TCP与UDP的本质
在讨论具体协议前，必须明确TCP和UDP在网络体系结构中的位置。它们都属于传输层（Transport Layer） 协议，为应用层提供端到端的通信服务，但其特性截然不同。
为了更好地理解它们在协议栈中的位置及其核心区别，请见下图：
-
TCP（传输控制协议）：面向连接、可靠传输、保证顺序、流量控制
-
适用场景：需要可靠数据传输的应用，如Web服务（HTTP）、邮件（SMTP）、文件传输
-
特点：三次握手建立连接，保证数据包完整性和顺序，适合重要数据传输
-
-
UDP（用户数据报协议）：无连接、不可靠传输、不保证顺序、低延迟
-
适用场景：实时性要求高的应用，如视频流、语音通话、实时状态监测
-
特点：无需建立连接，直接发送数据包，适合对实时性要求高于可靠性的场景
-
2. 不同设备类型的通信方案
2.1 服务器间通信
服务器间通信通常要求高可靠性和数据完整性，系统的复杂性要求我们为不同类型的设备选择合适的通信协议，其决策流程可概括如下：
低频次数据交互：
-
HTTP/HTTPS（RESTful API）：
-
协议层级：应用层协议（基于TCP）
-
工作方式：请求-响应模式，客户端发起请求，服务器返回响应
-
适用场景：配置管理、报表生成、低频事件上报
-
优势：标准化、易于实现和调试、防火墙友好
-
劣势：每次请求需要建立TCP连接（HTTP1.1支持持久连接但仍有头部开销）
-
示意如下：
-
高频次实时数据交互：
-
WebSocket：
- 协议层级：应用层协议（基于TCP）
工作方式：先通过HTTP握手，然后升级为全双工通信通道
-
适用场景：实时仪表盘、高频状态更新、实时协作应用
-
优势：单连接持久化，减少连接建立开销，支持双向实时通信
-
自定义TCP协议：
-
协议层级：传输层+自定义应用层协议
-
工作方式：基于TCP长连接，自定义二进制或文本协议
-
适用场景：极高性能要求的内部系统通信
-
优势：极致性能，最小化协议开销
-
劣势：需要自行处理粘包、拆包、重连等机制
-
2.2 嵌入式设备通信
嵌入式设备通常资源有限（计算能力、内存、功耗），需要轻量级协议：
MQTT（消息队列遥测传输）：
-
协议层级：应用层协议（基于TCP）
-
架构：发布/订阅模式，中心代理（Broker）架构
-
适用场景：物联网设备数据上报、远程控制、状态监控
-
QoS级别：
-
QoS 0：最多一次交付（可能丢失）
-
QoS 1：至少一次交付（可能重复）
-
QoS 2：恰好一次交付（可靠但开销大）
-
-
优势：
-
极低的协议开销（最小报文仅2字节）
-
支持离线消息（持久会话）
-
适应不稳定网络环境
-
一对多消息分发
-
-
典型应用：AI边缘计算盒子上报分析结果、接收远程配置更新
-
示意图如下:
CoAP（受限应用协议）：
-
协议层级：应用层协议（基于UDP）
-
特点：专为受限设备设计，类似HTTP的语义但更轻量
-
适用场景：极低功耗设备，如电池供电的传感器
-
优势：基于UDP，头部开销极小，支持多播
2.3 工业设备与控制通信
对于直接控制声光报警器、门禁控制器等工业设备，需要实时可靠的工业协议：
Modbus协议：
-
协议变体：
-
Modbus RTU：基于串行通信（RS-485/RS-232），二进制格式
-
Modbus TCP：基于以太网/TCP，封装Modbus帧
-
-
工作模式：主从架构，主机发起请求，从设备响应
-
数据模型：
-
线圈（Coils）：读写布尔值（1位）
-
离散输入（Discrete Inputs）：只读布尔值
-
输入寄存器（Input Registers）：只读16位值
-
保持寄存器（Holding Registers）：读写16位值
-
-
适用场景：PLC控制、传感器数据采集、设备状态监控
典型应用流程：
-
AI分析服务器检测到安全事件（如入侵）
-
通过MQTT上报云端管理平台
-
管理平台通过Modbus TCP/RTU向现场的PLC发送控制指令
-
PLC驱动声光报警器启动，同时控制门禁系统锁闭相关区域
示意流程如下:
3. 协议选择决策矩阵
| 设备类型 | 典型场景 | 推荐协议 | 优势 | 注意事项 |
|---|---|---|---|---|
| 云端服务器 | 数据聚合、API提供 | HTTP/REST | 通用性强，生态完善 | 高频场景性能开销大 |
| 服务器集群内部 | 微服务通信、数据同步 | gRPC/Thrift | 高性能，接口严格 | 需要服务发现机制 |
| 实时Web应用 | 监控仪表盘、实时通知 | WebSocket | 全双工实时通信 | 需要连接管理 |
| 嵌入式AI设备 | 分析结果上报 | MQTT | 轻量，支持不稳定网络 | 需要Broker服务器 |
| 极低功耗传感器 | 周期性数据采集 | CoAP | 极低功耗，简单 | 可靠性较低 |
| 工业控制设备 | 设备控制、状态读取 | Modbus | 工业标准，广泛支持 | 功能相对简单 |
| 实时音视频传输 | 视频流、语音对讲 | RTP/UDP | 低延迟，实时性好 | 需配合QoS机制 |
4.系统通信架构示例
- 一个完整的AI视频监控系统的通信架构可能如下所示：
- 参考的文本流程图如下：
┌─────────────────┐ MQTT over TLS ┌─────────────────┐
│ 边缘AI计算设备 │ ←─────────────────→ │ MQTT Broker │
│ (摄像头+分析盒) │ JSON数据上报 │ (消息中间件) │
└─────────────────┘ └─────────┬───────┘│ HTTP Webhook▼
┌─────────────────┐ Modbus TCP/RTU ┌───────────────┐ WebSocket ┌───────────────┐
│ 工业控制设备 │ ←─────────────────→ │ 边缘网关/PLC │ ←──────────────→ │ Web监控平台 │
│ (声光报警器/门禁)│ 控制指令、状态读取 │ │ 实时状态更新 │ │
└─────────────────┘ └───────────────┘ └───────────────┘│ HTTP API▼┌───────────────┐ REST API ┌───────────────┐│ 后端微服务集群 │ ←──────────────→ │ 移动APP/第三方 ││ │ 业务数据交互 │ 系统集成 │└───────────────┘ └───────────────┘│ gRPC/Thrift▼┌───────────────┐│ 数据分析服务 ││ (大数据分析) │└───────────────┘
总结
本小节主要的目的是为了让大家明白基本的通信机制和原理，可以根据使用情况合适的选择有效的通信机制，在下一小节，我们将针对常用的通信机制，实现最小单元级别的案例。
下期预告
- http请求推送数据。
- mqtt请求推送数据。
- modbus请求控制设备。