卷六 · 硬件与现场：逆向的部分

开篇

一家烘焙连锁,二十三家门店,全部同城（已有实际记录）。

这门生意里有一个被讲了几千遍、没人真当数据看的现象:产品的保温保湿窗口短,卖不完的当天报废,报多了的第二天口感塌（方案结构判断）。配送量的决定权一直在凭经验的报数环节（方案结构判断）。改造前一年浪费约一百三十万,改造后压到六十万（已有实际记录）,过程顺利（已有实际记录）。

实际记录显示，改造做了两件事。第一件,改造门店已有的监控取数,启用摄像机自带的客流统计能力,把客流曲线从原本就有的录像流里要出来（方案结构与实际记录均已确认）。第二件,加装温湿度传感器,把「保温保湿窗口短」从经验说法变成可计算的时间窗（已有实际记录）。两条数据放在一起,逐店逐时段生成配送建议,配送量从拍脑袋改成按店按日调整（方案结构判断）。

这件事最让人不安的部分,不是浪费数字本身。是数据一直在那台摄像机里,从来没有一天不在过。摄像机一开机就在数过路人,只是从来没有人向它要这个数。

这件事的工程教训,后面这一卷会拆开来写。它不是孤例。它是一条规律:很多公司花了钱装好了设备,设备在替他们数着一切,但数据躺在那里没人要,因为没人知道能要。这一卷要回答的核心问题是,FDE 怎么把那些「从来没人要过的数据」要出来,要出来之后怎么守住合规,以及,销售说做不到时,应该往哪里翻。

第一章　数据不在系统里,在设备里

卷一第三章拆过那堵墙的形状,把它分成了四层。第一层最表层,却最常被低估:数据不在系统里。一家公司真正驱动决策的数据,大量存在于系统之外,私人 Excel、微信群、手写台账、纸质单据、某个人的记忆。你把模型接到 ERP 上,接到的是这家公司的官方叙事,不是它的实际运行。

这一卷把第一层物理化。它不只存在于人的经验里。它还存在于机器里。摄像机在数人头,PLC 在记转速,网关在缓存运行日志,称重传感器在记每一次下料的重量,温湿度变送器在按秒上报数值。这些数据从机器启动的那一秒就在产生,只是没有人知道怎么把它们要出来,或者知道但懒得去做。

把数据从设备里要出来这件事,在传统实施方法论里被归类为「系统集成」,被外包给第三方,被当成项目预算里的「硬件接口费」一笔带过。但对一个 FDE 来说,这是侦察的一部分,而且是代价最小、信号最干净的那一部分,因为设备的物理动作无法撒谎。客流经过一个门,头肩模型就在检测器里产生一次触发;一台冲压机每完成一次冲程,计数器就加一;一个保温柜的温度在三十秒内升高了一度,温湿度传感器的寄存器值就会跳变。这些数据没有人能事后改口,也没有人能在汇报里选择性忘掉。它们存在于物理世界,不在人的意志里。

卷一第四章写过,执行成本在过去两年塌了一个数量级。塌得最快的,是数据接入这一段。一条 RTSP 流、一组 Modbus 寄存器、一个 ONVIF 设备,过去要花资深工程师几天才能调通,现在一个熟练从业者两三个小时就能把它读进数据库。但塌方只发生在执行端,不在判断端。判断端要做的事,是分辨出「这个数据真的能要吗?」「要出来之后,客户能不能用?」「用完之后,合规边界会不会塌?」这三件事在过去两年里既没有变快,也没有变便宜,反而因为合规收紧变得更重。

这也是为什么这一卷被命名为「逆向的部分」。

它的真实含义不是「破解」。「逆向」在这里指的是,当销售说做不到、当集成商说需要换设备、当甲方说这个数据我们没有的时候,FDE 的标准动作是翻开协议文档,看看那里写的是什么。这个动作贯穿这一卷的每一章。烘焙案监控改造的进场动作,几乎原样演示了这个方法论（方案结构与实际记录均已确认）。摄像机里一直有人在数人头,只是从来没有人向它要这个数。当 FDE 把这条数要出来,后面所有的工作就有从「拍脑袋」切换到「按数据」的可能。具体的改造代价与节省结构按合理推断处理,本卷不替代用户口述与卷七案例稿。

下面这一卷按四个主线展开。视频侧的协议世界四条主线,GB/T 28181、ONVIF、RTSP、厂商 SDK,各自的能力边界决定 FDE 能向摄像机要到什么东西、要不到什么东西。工业侧协议三条主线,Modbus、OPC UA、PLC 私有协议,决定 FDE 能向机器要到什么东西、要不到什么东西。逆向方法论一章把销售做不到这件事拆成协议边界、商业边界、激励边界三类,分别给出处理方式。合规红线一章把 2024 到 2025 年集中收紧的法规和执法案例摆出来,把动作翻译成 FDE 在现场的三个标准姿态:边缘侧处理、只取统计量、原始帧不落盘。

把这条主线放回卷一的全景里看,这一卷回答的是那堵墙第一层的物理形态。卷二第六章给过 FDE 的全流程方法论,卷四把整个交付拆成五个阶段,卷五把人和机器的分工切到底。卷六要做的是其中硬件现场这一段的具体落地。

把这一层和卷五第一章那条「输入能不能被送进去」的判据放在一起,设备数据的特殊性就显出来了。设备数据大部分是结构化的。Modbus 寄存器、OPC UA 节点、ONVIF 事件,都是规整的数字、规整的字段、规整的协议。它们送得进模型,模型能读、能加工、能吐、能告警。

设备数据里也有一小部分是非结构化的,某个老工程师对「这个寄存器代表什么」的口述、某台机器旁边那张手写便条,这些不是协议层的事,是现场的事。设备数据里最危险的是伪结构化,仪表盘上跳动的曲线看起来像结构化数据,但曲线的语义被埋在一台 PLC 的某段梯形图里,没有人能在仪表盘上看出那条曲线在 PLC 程序里是怎么算出来的。

把这条判据和卷一第三章的四层信息断层放在一起看,设备数据是四层里第一层「数据不在系统里」在物理世界的延伸。第一层讲的是公司系统之外的隐性信息,设备数据是其中一类载体,它的特殊性在于:它是可以被接口读取的,只是从来没人去读。

设备数据与影子系统

设备数据还有一个卷一没展开的工程性质:它天然与影子系统互补。

卷五讲过,影子系统是正式系统之外的、用 Excel/微信群/手写台账运行的真实业务系统。它在制造业里几乎是普遍现象。一家工厂的 ERP 跑的是 SOP 版本的报工流程,车间主任每天上午拿一张 Excel 表填实际报工数据,这张表里藏着真实报工节奏与官方流程之间的差额。

设备数据在物理层提供了一份独立于影子系统的实时真实。ERP 里写的报工曲线是 SOP 版本的影子,PLC 里的计数器是真实版本的实时。两者对不上,差额就浮出来了。FDE 进现场,把这层对不上记下来,这三件事就同时被钉在了同一张表上:ERP 写的、Excel 跑的、PLC 计的。

把这一层叠在卷一第三章的四层上,就是:影子系统(卷一第三章第三层的物理形态)与设备数据(这一卷的物理形态)之间,默认存在一个差额。把这个差额做出来给客户看,后面所有的工作,无论是补数据、改流程、还是撤回需求,都有了物理证据,而不是依赖任何一方的口头确认。

---

第二章　视频侧:四套协议的能力边界

视频侧的协议世界有四条主线。它们各自的能力边界,决定了 FDE 能向摄像机要到什么东西、要不到什么东西。这一章只讲能力边界,不展开具体的报文样例、调用流程、配置示例。这些属于实现细节,放在工程师自己的笔记里更合适。参考实现：烘焙案里那条客流曲线最终落到了协议层与厂商实现层之间存在标准接口的那一类上,具体协议选型按工程常识推断,真实技术栈未逐条留档。FDE 在现场的标准动作是先查接口,再决定走哪条路径。

GB/T 28181:政务视频联网的事实标准

GB/T 28181 是公共安全视频监控联网系统信息传输、交换、控制技术的国家标准。它的现行版本是 2022 版,2023 年 7 月 1 日起实施,版本标识为 3.0。

它的设计目标是解决一个问题,全国几万、几十万家不同厂商生产的摄像机和平台,如何能在同一张网上互相看得见、能互相调用。它的工作方式是基于 SIP 协议的信令通道加基于 RTP 的媒体通道。设备开机后主动向上级平台发起注册,平台通过 INVITE 等信令发起媒体请求。媒体流通常使用 PS 封装,在 UDP 上传输。

它对 FDE 有意义的边界有五条。

边界一:它解决的是「能不能连上」的问题,不解决「连上之后能不能用上智能」的问题。

协议本身只规定了信令交互、设备目录、媒体分发、设备状态上报、PTZ 控制这些基础能力。客流统计、区域人数、热度图、跨线计数这些智能分析能力,是否走 GB/T 28181 的扩展接口,取决于厂商在自家 SDK 里做了什么。大部分主流厂商的主流机型支持,小厂商不一定。

边界二:它支持 H.265 和 AAC,但具体到一台机器,是否真的开了,要去设备能力集里查,不能在协议层假设。

2022 版相对 2016 版的媒体流通道扩展里新增了 H.265 和 AAC。这是协议层的规定。但一台 2019 年部署、固件没升级过的设备,实际能送的码流很可能仍是 H.264。FDE 在第一周就要查清楚这件事,而不是在交付周发现码流不对再回头查。

边界三:它对媒体流的获取给了标准化的方式,但对元数据的获取仍然不完整。

智能分析的结果,客流数、热度值、目标框,是否被作为元数据送上 28181 信令通道,2022 版新增了图像抓拍信令、设备软件升级信令,但客流曲线的周期性回传,各家实现差异很大。FDE 拿到的很可能只有「视频流 + 偶尔的抓拍图片」,而不是「结构化的客流时间序列」。后者往往要走厂商私有 SDK 才能稳定取到。

边界四:它要求国密算法支持,但这只对接到公共安全联网的项目有意义,商业项目用不到。

GB/T 28181-2022 配合 GB 35114 形成的安全体系,要求设备支持 SM 系列国密算法。政务项目必须满足。商业零售、连锁门店的监控改造,如果不需要并入政务平台,这一层可以略过。

边界五:它的 2022 版相对 2016 版是实质升级,而不是文字微调。

这一点容易被低估。2022 版统一帧率到 25 fps,新增了 H.265、G.722.1、AAC 编码格式,要求媒体流使用 RTP 时间戳以保证视频时间的真实性与不可篡改性,新增了看守位信息查询、巡航轨迹列表查询、PTZ 精准状态查询、存储卡状态查询、设备软件升级、图像抓拍信令流程等多个工程实用项。这些改动在政务项目中是「必须升级」的理由,在商业项目中是「升级固件就能解锁新能力」的工程红利。一个 FDE 进现场查设备能力集的时候,如果发现设备跑的是 2016 版固件,先把升级路径问清楚再谈数据规划。

把五条边界合在一起,GB/T 28181 在中国视频现场的角色是「能连上」的最低公约数。能让全国不同厂商的几万台设备在同一张网上被看见、被调度,但「看见之后能用出什么智能」要回到各家厂商。FDE 在商业连锁项目里通常不会用 28181 取智能数据,但必须把 28181 当成设备兼容性的兜底检查项。一台摄像机如果连 28181 注册都过不了,在多品牌混合环境里基本可以判定不能进网。

把 28181 与它配套的 GB 35114 接起来看,这条边界还会在政务项目里进一步收窄。GB 35114 是公共安全视频监控联网信息安全的技术要求,它的核心是为视频监控联网系统提供端到端的身份认证与媒体流加密,与 28181 配合形成「信令 + 媒体 + 身份 + 加密」的完整安全体系。GB 35114 把接入设备分等级,其中等级三要求设备支持基于国密 SM 系列的数字证书认证、信令完整性保护、媒体流加密。

政务项目要并入上级平台,等级要求由上级下发,通常是等级二或等级三。商业项目不需要 GB 35114,但 FDE 进现场时如果发现客户同时做政务与商业两条线,要分清两条线对设备能力的要求,不要把商业项目用的高性价比设备直接并入政务平台。

把这一条加进 FDE 的第一周侦察清单,意味着除了设备品牌与固件版本,还要问:这台设备支持 GB 35114 哪个等级?如果不知道答案,平台对接的当天就会卡死。

ONVIF:国际设备管理的事实标准

ONVIF 是国际开放行业论坛制定的协议,目标是在不同厂商的网络视频设备之间实现互操作。它的工作方式是基于 WS-Discovery 的设备发现、基于 SOAP/WSDL 的设备管理接口、基于 RTSP/RTP 的媒体传输。

它对 FDE 有意义的边界有四条。

边界一:它对单设备的管理做得最深。

PTZ 控制、视频流配置、编码参数调整、事件订阅、设备能力查询,这些是 ONVIF 的强项。它的接口描述语言严格,能力强但门槛高,初学者面对一份 WSDL 文件很容易被劝退。FDE 在现场,会用 ONVIF 做的第一件事是设备能力查询。把设备真正支持的协议子集、编码格式、流媒体 URI、事件类型一次性问清楚,后面所有的工作才有依据。

边界二:它在 AI 元数据接口上有持续扩展。

ONVIF 在近年版本里持续扩展智能视频分析相关的元数据接口,目标是把客流统计、目标检测这类分析结果标准化。Profile M 是这一方向上最重要的 Profile 之一,它在 2020 年正式发布,经过几年迭代到 2026 年已成为智能元数据的事实标准之一。

Profile M 支持元数据的分析配置和信息查询,定义了几类通用对象分类接口,地理位置、车辆、车牌、人脸、人体,并对对象计数、人脸识别、车牌识别这类分析功能给出了事件处理接口。Profile M 设备或客户端如果支持 IoT 系统常用的 MQTT 协议,可以以 JSON 格式发送 ONVIF 事件,扩展到商业智能与物联网场景。Profile M 通常与 Profile S、T 组合使用,前者管视频流,后者管元数据流与事件流,二者结合能完成从取流到取结构化数据的完整链路。

但厂商支持度参差不齐。2026 年的实际情况是,支持设备能力查询的不一定能取到客流统计,支持抓图的未必支持结构化元数据。这一条边界决定了 FDE 在连锁门店或工厂园区的协议选型不能用「统一一份 ONVIF 接口搞定一切」的态度来做。

边界三:它的复杂接口与它的高兼容性是同一件事。

ONVIF 的接口体系复杂,正是因为它要让所有厂商的所有设备都能描述自己的能力。这种「能描述一切」的设计,在现场的实际效果往往是「能问出来,但答案很泛」。一台设备的 ONVIF GetCapabilities 响应可能列出了十项能力,其中只有三项能真的工作。FDE 的常见动作是先用 ONVIF 探测设备支持哪些分析能力,再回到 RTSP 取流,或者切到厂商 SDK。

边界四:Profile T 把 H.265 写进了标准,Profile M 把元数据写进了标准,二者不是替代关系。

Profile T 解决的是视频流的高级配置,H.264、H.265 编码、成像设置、运动侦测、双向音频、PTZ 配置;Profile M 解决的是元数据与事件的标准化传递。

FDE 在现场要做的事不是选 T 还是 M,而是判断设备同时支持哪几个 Profile。如果设备同时是 Profile T 和 Profile M 合规产品,那么视频流从 T 走,客流/事件从 M 走,中间用一条统一的元数据通道接住。这一组合在 2026 年的主流商用摄像机里已经普及,但普及不等于全覆盖。参考实现：在类似烘焙案的多店连锁改造中,FDE 进场要做的第一件事之一,就是逐台摄像机查它的 Profile 支持清单,具体怎么走以现场为准。

把四条边界合在一起,ONVIF 在中国视频现场的角色是「单设备智能能力的事实说明书」。它能让 FDE 在不写代码的情况下搞清楚这台摄像机到底支持什么,但不能保证它真的按说明书工作。协议层能做的是把问题问清楚,验证是另一件事。

把 ONVIF 的 Profile 体系完整看一遍,会看到一个比想象的更细的能力地图。Profile S 是流媒体,负责 RTSP/RTP 取流;Profile G 是录像,负责录像存储与回放;Profile T 是高级视频流,加上 H.265、双向音频、运动侦测;Profile C 是门禁;Profile A 是访问控制;Profile M 是元数据与事件。

Profile M 出现之前的若干年里,FDE 在做客流统计与人脸识别集成时,几乎只能依赖厂商 SDK,或者用 Profile T 的视频流去跑自有模型做检测。Profile M 出现之后,这件事有了标准化的接口,设备可以把客流计数、人脸抓拍、车牌识别这些分析结果以结构化元数据形式送出,客户端可以按规则订阅、过滤、消费。

Profile M 解决的,不是「能不能做智能」的问题,不是「做得好不好」的问题,而是「不同厂商做的智能,能不能用同一套接口消费」的问题。这是一个非常具体的工程价值:它在 2026 年的事实标准层面,把客流曲线的取数从「每家厂商各做一套 SDK 适配」拉到了「按 ONVIF Profile M 的标准接口订阅」。这件事对 FDE 的现场工作量是数量级的影响。

Profile M 的工程价值在单品牌方案的连锁项目里通常不直接发挥,因为直接走厂商 SDK 取数更稳定（根据现有材料推断）。但在多品牌混合、连锁门店超过三十家、跨城市的项目里,Profile M 的价值会被放大。FDE 在现场要不要上 Profile M,不是看 Profile M 多先进,而是看项目的品牌混合度与门店规模,这两个条件满足,上 Profile M;不满足,直接走厂商 SDK 更简单。

RTSP:实时流的事实标准

RTSP 是实时流传输协议,设计上类似 VCR 控制,PLAY、PAUSE、TEARDOWN。它配合 RTP 做媒体数据传输。

它对 FDE 有意义的边界有两条。

边界一:它是取流协议,不是控制协议。

RTSP 能拿到实时的视频流、音频流,但拿不到设备状态、拿不到分析结果、拿不到配置。它在现场的最大用途,是 ONVIF 或厂商 SDK 完成控制后,真正去取媒体流。FDE 的标准动作是先用 ONVIF 拿到流媒体 URI,再用 RTSP 去拉。绕开 ONVIF 直接 RTSP 也能取,但鉴权、URI 管理、断流重连全要自己处理。

边界二:它对单设备很轻量,对大规模组网不适用。

RTSP 适合一台摄像机对一个取流方。当平台要同时管理几百、几千路摄像机时,RTSP 的连接管理、鉴权、心跳机制都不够用。平台侧的解决方案往往是 RTSP 入网关,网关再以 GB/T 28181 或私有协议向上接平台。

把两条边界合在一起,RTSP 在 FDE 工作流里的位置很清晰:它是「取视频」的标准动作,但不是「取智能」的标准动作。参考实现：在类似烘焙案的多店连锁改造中,客流曲线大概率最终走的是厂商 SDK,RTSP 只用来在调试阶段看视频流的稳定性,具体走法以现场为准。FDE 在现场不要在 RTSP 上多做停留。

把 RTSP 与 RTMP、GB/T 28181 的媒体流通道做一次对比,可以把取数侧的几个协议位置看清楚。RTSP 是单设备单连接的标准取流方式,适合客户端直连摄像机的场景;RTMP 是早年直播与监控流媒体的常见协议,过去几年逐步被 RTSP 与 GB/T 28181 取代,主要留存于部分存量系统;GB/T 28181 媒体流通道是基于 RTP/PS 封装的,适合设备注册到平台后的统一取流,适合大规模组网。

FDE 在现场选哪个,取决于设备是直连客户端还是注册到平台、组网规模有多大、是不是政务对接。

参考实现：在类似烘焙案的多店连锁改造中,常见组合是每家门店放一台轻量盒子,盒子上同时跑 RTSP 取流与厂商 SDK 取数,盒子上游走 GB/T 28181 上行到中央平台服务器,具体拓扑以现场为准。这一组合,反映了三种协议在工程上的自然分工。

厂商 SDK:便利与锁定的一体两面

主流监控厂商都有自己的设备 SDK,通常支持 Windows、Linux、嵌入式三种平台,提供 C/C++/Java/Python 等多语言绑定。

它对 FDE 有意义的边界有三条。

边界一:它能取到协议层取不到的东西。

客流时间序列、区域计数、热度矩阵、设备运行状态、固件版本、网络诊断信息,这些东西往往只通过 SDK 暴露。协议层要么没有,要么不稳定。参考实现：在类似烘焙案的多店连锁改造中,客流曲线之所以能稳定取出来,大概率是因为厂商 SDK 暴露了周期性的客流统计推送接口;GB/T 28181 和 ONVIF 在这种场景下要么没有这个数据,要么回传频率达不到建模要求,具体协议层支持度以现场为准。FDE 在第一周就必须做的一件事情是,把厂商 SDK 的能力清单和协议层的能力清单做一份对照,标出哪几项只能走 SDK。

边界二:它把 FDE 锁在一家厂商身上。

一家烘焙连锁如果在不同时期采购了不同品牌的摄像机,SDK 的不兼容会让 FDE 在「统一取数」这一关前先撞墙。解决方案是边缘盒子做协议归一化,但这件事本身需要规划。统一 SDK 的成本在初期不高,后期每一次换厂商都会变成集成项目。一个 FDE 进现场,如果发现这家公司的摄像机是三个品牌,要在第一周就把「未来换品牌的成本」讲给客户听,避免锁死之后的被动。

边界三:它的接口变更不通知。

厂商升级一次 SDK,接口签名可能改了、字段语义可能改了、行为可能改了。FDE 的代码一夜之间停止工作。版本快照是这一层的纪律要求,具体细节进附录 F。FDE 在现场每次升级 SDK 前必须做三件事:把当前 SDK 版本号记下来、把当前依赖项的版本号记下来、在测试环境跑一遍完整冒烟用例。这三件事要写进现场的工作日志,不能只在脑子里过一遍。

四套协议在场内的角色

把它们放回现场。

政务项目、连锁门店的视频改造、工厂园区的安防联网,这三种场景的协议选型逻辑如下。

政务项目强制 GB/T 28181,没有第二个选择。设备必须支持国密、信令通道必须符合标准,平台必须能级联到上级。这是合规底线。

商业连锁的视频改造,通常组合是,摄像机同时支持 ONVIF 和 RTSP,平台侧用 ONVIF 做设备管理、用 RTSP 取流,智能分析走厂商 SDK 或者边缘盒子。参考实现：该组合也是类似烘焙案的多店连锁改造的常见选型,具体协议搭配以现场为准。

工厂园区的安防联网,通常组合是,摄像机侧协议杂、品牌杂,网关做协议归一化向上接平台。

FDE 在第一周的侦察清单里,有五件事必须问清楚。

一,项目需不需要并入政务平台?需要,GB/T 28181 是底线。

二,设备品牌和型号清单能不能拿到?决定 SDK 是否统一。

三,智能分析能力走协议层还是 SDK 层?决定后续代码工作量。

四,媒体流要不要长期存储?决定带宽与存储预算。

五,设备固件版本与协议 Profile 支持清单能不能拿到?决定 28181 升级与 ONVIF Profile 组合的实际可获取能力。

这五问的答案,决定了协议选型的整条路径。

协议层的两层失败

在协议层有两个失败模式,FDE 必须能识别。

第一种是「协议版本错配」。GB/T 28181 跑在 2016 版固件上,平台按 2022 版去调设备能力,取数接口对不上,平台日志里全是设备拒绝响应。这种失败可以通过「跑一次设备能力查询,把协议版本和子能力集打印出来」提前识别,不用等到交付周才发现。

第二种是「Profile 误用」。把 Profile M 当成 Profile T 用,把元数据流当视频流处理,或者反过来。Profile M 和 Profile T 都涉及元数据,但 Profile T 的元数据是视频流的一部分,Profile M 的元数据是独立通道。这种误用不会让设备拒绝响应,但会让数据对不上,FDE 会被困在「为什么我的脚本取到的不是客流数」这种调试地狱里。识别方法是,在脚本启动时先把设备报告的合规 Profile 列表打出来,再决定走哪一条。

---

第三章　工业侧:Modbus / OPC UA / PLC

视频侧处理的是「谁来过」。工业侧处理的是「机器做了什么」。两条侧的能力边界不一样,取数逻辑也不一样。

Modbus:工业协议的「通用语」

Modbus 是 1979 年由施耐德电气发布的工业通信协议。它极其简单,主从结构、寄存器读写、功能码有限。正因为简单,所以三十多年没死,在中小工厂里仍然是事实标准之一。

据工业网络市场研究机构 2025 至 2026 年度的报告,在新安装节点中,Modbus TCP 在工业以太网协议里占比稳定在 5% 上下;Modbus RTU 和 TCP 合计在所有现场总线与工业以太网新装节点里占比约 7%。这个数字看上去不大,但加上存量设备的绝对数量,Modbus 在中国中小工厂里仍然占据绝对多数的接入协议份额。一家典型的国内规模以上制造企业,平均同时使用 5 种以上工业通信协议,其中 Modbus RTU 与 TCP 是最常见的两种。来源类型,公开报道,综合 2025 年工业网络市场份额报告与公开行业研究。

它对 FDE 有意义的边界有三条。

边界一:它取的是「寄存器值」,不解释语义。

Modbus 告诉你某个保持寄存器的当前值是 12345,但 12345 代表温度、压力、转速还是计数器读数,Modbus 自己不知道。语义由设备手册、PLC 程序、网关配置决定。FDE 拿到的第一手数据是数字,不是解释。这个数字是不是当前车间温度,要看 PLC 程序里把哪个变量映射到那个寄存器,要看 PLC 程序是不是对的,要看传感器有没有漂移。Modbus 只负责把这串数字从 A 送到 B。

边界二:它没有内置的安全机制。

原始 Modbus 协议没有任何鉴权和加密。生产环境里如果直接暴露在网络上,任何能连上设备的人都能读写所有寄存器。现实里很多中小工厂就是这样部署的。公开行业安全研究多次披露过 Modbus TCP 部署不当导致的安全事件,典型形态是端口暴露在公网或办公网、缺乏网络隔离、缺乏访问控制。FDE 的第一周侦察里,这件事必须问清楚,必须在交付方案里加一层网络隔离。具体的安全事件细节,属于公开报道中的典型案例,FDE 引用时只需保留「不安全部署会导致生产中断」这一结论,不展开技术细节,避免变成操作指南。

边界三:它对实时控制很合适,对长期存储不友好。

Modbus 的设计目标是读写当前值。它没有时间戳,没有历史缓冲,没有变化通知。FDE 要做时间序列分析,必须在网关或边缘盒子侧做实时缓存。参考实现：在类似烘焙案的多店连锁改造中,温湿度传感器这一类低速采样场景下,常见做法是走 Modbus RTU 或 TCP 接入本地网关,网关按周期轮询并写入本地数据库,再按日聚合成时间窗;具体协议、轮询周期、聚合粒度以现场设备与建模需求为准。这一段的数据通路如果走 Modbus 直连云端,既不实时,也不可靠。

把三条边界合在一起,Modbus 的角色是「能让现场设备互相讲话的最小公分母」。它的优点是简单、低成本、几乎所有设备都支持。缺点是没有语义、没有安全、没有时间。FDE 在中小工厂的现场几乎必然会遇到 Modbus,处理方式不是替换它,而是在它之上加一层网关,补齐语义、安全、时间三件事。

OPC UA:工业信息建模的事实标准

OPC UA 是 OPC 基金会制定的下一代工业通信协议,目标是替代老一代的 OPC Classic。它基于服务导向架构,内置信息模型、统一命名空间、安全机制、平台无关的二进制或 XML 传输。

它对 FDE 有意义的边界有三条。

边界一:它不只传值,还传「这个值是什么」。

OPC UA 的核心是信息模型,一个数据点不是孤立的数字,而是带有元数据的节点。节点有名称、单位、工程师描述、数据类型、读写权限、历史采样率。这些元数据写在设备端的地址空间里,FDE 拿到的不只是当前值,还有这个值的语义。一台中高端 PLC 内置的 OPC UA 服务器,会把每个变量的标签、单位、量程、当前质量码(Good/Bad/Uncertain)都暴露出来,这意味着 FDE 不需要再去翻 PLC 程序,可以直接从节点读出「这是电机电流,单位安培,当前质量 Good」。具体到某一型号 PLC 的真实节点树,作为案例放在附录 F 的 OPC UA 实例专题里。

边界二:它对工业 4.0 友好,但对中小工厂不友好。

OPC UA 的协议栈完整,但部署门槛高。设备端需要支持,网关需要配置,证书需要管理。中大型工厂、跨国公司的产线部署比例不低;但对中小工厂、单条产线、几个 PLC 的场景,OPC UA 往往因为部署成本被绕开,继续用 Modbus + 自定义映射表。从公开行业资料看,OPC UA 在国内中小工厂的部署比例显著低于 Modbus,多品牌 PLC 混用、有 MES / SCADA 集中取数需求的项目会更倾向选 OPC UA。来源类型,公开报道,行业研究与多家供应商技术资料综合判断。

边界三:它的安全模型完整,但默认配置往往最弱。

OPC UA 支持证书、加密、签名、用户鉴权。但大量设备的默认配置是关闭鉴权或使用空密码。FDE 在第一周要查清设备的鉴权状态,不能用协议标准的能力假设现场的配置。一个常识,标准定义了安全,部署没有强制启用,这之间的差额是绝大多数工业安全事件的真正入口。

把三条边界合在一起,OPC UA 的角色是「多品牌多 PLC 工厂的统一数据接口」。它解决的是 Modbus 解决不了的语义问题,但它要求的部署成本也比 Modbus 高一个量级。FDE 在现场做协议选型时,要根据设备的规模、品牌混合度、MES / SCADA 是否集中取数这些条件,而不是根据「哪个更先进」来选。

PLC 与私有协议:最后一公里的现实

PLC 是可编程逻辑控制器,工业现场的「小脑」。主流品牌西门子、三菱、欧姆龙、罗克韦尔各自有私有的通信协议,S7 协议、MELSEC 协议、Host Link、EtherNet/IP 等等。

这些协议大多不开放,部分开放(西门子 S7 有社区解析,但不在官方文档里),部分需要付费授权。

FDE 在中小工厂现场几乎必然遇到私有协议。它的处理方式有两种。

第一种,找原厂或授权的网关,把私有协议转成 Modbus 或 OPC UA。这种方案稳定但需要钱。

第二种,使用边缘计算盒子或工控机,装开源或商用的协议解析库,自行做协议转换。这种方案便宜但有维护负担,协议升级或固件变更时可能一夜失效。

第一种方案适用于预算充足、设备品牌统一的工厂。第二种适用于预算紧、设备品牌杂、愿意承担维护责任的工厂。

FDE 选哪种,不是技术判断,是商业判断。把这两条决策路径摆给客户,让他自己选,不要替客户决定。

主流 PLC 品牌生态一瞥

FDE 进现场看 PLC 清单,经常需要快速判断「这一家 PLC 用什么私有协议」。下面给一份常见 PLC 与私有协议的速查,做现场识别用,不展开技术细节。

西门子 S7 系列,私有协议 S7 Communication / S7Comm / PUT/GET,可以通过西门子的以太网模块、原厂网关或开源库解析。S7 系列中高端型号内置 OPC UA 服务器,中大型项目走 OPC UA 更稳。

三菱 MELSEC 系列,私有协议 MELSEC Communication Protocol(MC Protocol),支持串口与以太网。原厂网关支持把它转成 Modbus TCP 或 OPC UA。

欧姆龙的多个产品线,私有协议 Host Link 与 FINS。原厂网关支持 Modbus TCP 转换。

罗克韦尔 Logix 系列(AB),私有协议 EtherNet/IP,基于 CIP 协议族。Logix 系列中高端型号同时支持原生 EtherNet/IP 标签与 OPC UA。

施耐德 Modicon 系列,私有协议 Modbus TCP 是其原生协议,这一点让 Modicon 在 Modbus 生态里占了一个特殊位置,与第三方 Modbus 设备集成成本最低。

把这五家放在一起看,行业里有一条不成文的「协议友好度」排序。Modicon(原生 Modbus TCP)→ 西门子(S7 + OPC UA)→ 罗克韦尔(EtherNet/IP + OPC UA)→ 三菱(MC Protocol + 原厂网关)→ 欧姆龙(Host Link/FINS + 原厂网关)。FDE 在现场看 PLC 品牌,就能大致判断集成难度。

这一条要写在第一周的设备清单上,而不是写在脑海里。设备品牌决定协议难度,协议难度决定方案成本,方案成本决定报价。FDE 在第一周没有把品牌清单做出来,后面所有的工作都会偏。

边缘盒子:协议归一化的物理位置

边缘计算盒子是过去几年在工业现场和商业现场同时出现的一类设备。它通常是一台小型的 x86 或 ARM 工控机,带 NPU 或 GPU,运行 Linux,装几个 Docker 容器,分别做协议接入、智能分析、本地缓存、向上传输。

它在 FDE 工作里的角色是「协议归一化层 + 智能分析层 + 数据缓冲层」三合一。

它对 FDE 有意义的边界有三条。

边界一:它把协议复杂性从前端甩到了盒子内。

摄像机侧可以是 GB/T 28181、ONVIF、RTSP、厂商 SDK 任意组合,盒子把它们统一成一个内部数据格式,向上送平台。这件事降低了平台侧的协议复杂度,但把复杂性转移到了盒子选型与维护上。

边界二:它有算力限制,选型决定能跑什么模型。

盒子的 NPU 算力从几 TOPS 到几十 TOPS 不等。客流统计、人数统计、车牌识别这些轻量模型可以在一台几 TOPS 的盒子上跑几十路;ReID、行为分析、复杂场景理解需要更高算力,选型时要按实际负载算余量。

边界三:它的位置决定数据合规的边界。

盒子如果放在门店本地,数据可以不离开这栋楼,合规风险显著降低;如果盒子放在云端,数据出境问题就要重新评估。本地优先是这一层的默认姿态。

边缘盒子选型:按判据,不按型号

边缘盒子的型号很多,价位覆盖从经济型到中高端多个档位,具体价格进附录 F 的当日快照,FDE 在正文里不展开。FDE 在现场最容易掉进去的坑是「按型号选」,看了一圈行业资料、问了几家代理商、比了三家方案,最后挑了一个销量高的型号。这条路径几乎一定是错的,因为型号是供应侧的产物,不是需求侧的判据。

按判据选,逻辑是下面这套。

第一问,这条盒子要跑什么模型?客流统计?目标检测?ReID?车牌识别?行为分析?不同模型对算力的要求差一个数量级。把要跑的模型列出来,标注峰值算力需求,这是第一步。

第二问,这条盒子要接多少路视频或多少设备?8 路 1080P 视频做客流统计,与 32 路 4K 视频做人脸识别,对算力的需求是不同档次的。路数与分辨率一乘,得到总通量,再除以单盒算力,得到盒子的理论最低数量。这一步把「型号」问题转成「数量与档次」问题。

第三问,数据要不要出这栋楼?出不了,本地盒子、本地存储、本地推理。这把选型从「哪个云端盒子好」简化成「哪个本地盒子稳定」。本地部署的盒子在工业级宽温、防尘、断电保护上要求更高,选型逻辑完全不同。

第四问,客户的运维能力如何?客户的 IT 团队能不能远程登录盒子做固件升级、模型热加载、日志巡检?如果能,工业级 ARM + Linux 是合理选择;如果不能,需要盒子出厂预装完整镜像、远程运维平台、以及 7×24 小时的供应商支撑。

第五问,预算的边界在哪一档?预算敏感,选经济型,够用即可;预算充足,选中高端,为未来三年留余量。

把这五问的答案凑齐,再去翻型号目录。具体型号与价位在采购当时重新核对,附录 F 给一份按日期的快照,正文不写型号不写价格。

参考实现：在类似烘焙案的多店连锁改造中,边缘盒子的常见角色是协议归一化层加客流统计层。一种典型做法是每家门店放一台轻量盒子,负责把摄像机的客流曲线取下来、按一定周期缓存、按日聚合成时间窗,再同步到中央平台服务器;客流统计模型在盒子上跑,原始视频帧在盒子上就处理完,不向上传,不落盘。具体盒子数量、缓存周期、聚合粒度、上行拓扑以现场条件为准。这件事的设计直接对应第五章的合规三动作:边缘侧处理、只取统计量、原始帧不落盘。

工业侧第一周的五问

工业项目进场时,FDE 的侦察清单里有五件事必须问清楚。

一,设备清单能不能拿到?PLC、变频器、传感器、仪表的型号、固件版本、当前通信方式。

二,数据语义有没有人知道?寄存器值到物理量的映射表、量程、单位、采样率,这些信息往往只存在于某个老工程师的脑子里。

三,网络拓扑是什么样的?设备在哪个网段、网关在哪里、能不能加新设备而不影响现有通信。

四,合规边界在哪里?数据能不能出这栋楼?哪些数据是商业敏感、哪些是个人信息、哪些是工业控制系统的关键参数。

五,设备品牌混合度有多高?单品牌多型号可以走协议归一化网关;多品牌混合要么走 OPC UA 统一接口,要么做协议解析库,这两条路的成本与维护负担完全不同。

这五问决定后续方案能不能落。

---

第四章　逆向方法论:从「厂商说做不到」到「协议文档里写着能做」

这一章是这一卷的方法论核心。

它的标题里「逆向」一词,不是指破解或绕过安全机制。它指的是一种标准动作,当销售说做不到、当集成商说需要换设备、当甲方说这个数据我们没有的时候,FDE 翻协议文档。烘焙案里那条客流曲线能要出来,本质就是这条方法论的一次落地（方案结构与实际记录均已确认）。摄像机厂商与集成商在常规报价口径里不会主动列出「门店客流曲线按周期取数」这一能力,门店与运营人员不知道这条数据已在摄像机里（根据现有材料推断）。FDE 进现场,翻设备规格书,确认能力,打开功能,取数据,送到配送决策流程里。从「没人知道」到「按数据配送」,中间隔的是翻开协议文档这一个动作。

三种「做不到」

FDE 在现场会反复遇到三种「做不到」。它们的性质完全不同,处理方式也不同。

第一种,「技术上做不到」。协议层或设备能力确实不支持。这种「做不到」是可证伪的。FDE 打开协议文档,查到对应章节,看到设备能力集,结论明确。如果是这种,接受现实,改方案。

第二种,「商业上做不到」。技术上能,但需要付费、需要授权、需要签合同。这种「做不到」的形态是销售的口头拒绝。它不写在任何文档里。FDE 的处理是问出具体卡点,是授权问题、是商务问题、还是销售个人的边界。如果授权可以谈,谈;如果商务流程卡,绕过去找商务接口人。

第三种,「懒得做」。技术上能,商业上能,但没人愿意为这个工作量做。这种「做不到」最常见,也最难处理。它的典型形态是销售说「可以,但要做定制开发,周期三个月」,而 FDE 自己查文档发现两小时能配出来。处理方式是拿出文档依据,要求按文档支持的能力交付。

第三种是 FDE 价值最大的地方。它解决的不是技术问题,是激励错位问题。销售没有动机去做一个不在报价单里的功能,FDE 有动机去做一个能让客户验收的功能。

把第三种「懒得做」放在硬件现场的具体形态上,会更清楚它为什么难处理。

第一种典型场景:摄像机自带客流统计功能,但默认不启用,启用要在摄像机后台里点几个开关。销售不会主动提,因为他要推的是「智能分析盒」或「AI 摄像头」这类带报价单的产品。FDE 进现场,翻设备能力清单,发现功能已包含在固件里,启用后五分钟内拿到数据,处理方式是「我来做这件事,你按文档支持的能力验收」。把「启用摄像机自带功能」这件事从「销售报价之外的隐形成本」转成「按合同已包含的交付项」,激励错位就被解开了。

第二种典型场景:PLC 自带的 OPC UA 服务器,默认鉴权配置是关闭的,关闭状态下任何能连上设备的人都能读写所有变量。销售也不会主动提「建议启用鉴权」,因为这会增加客户的部署复杂度,FDE 进现场,翻 OPC UA 节点,把鉴权状态查出来,如果发现是关闭的,需要做两件事,一是把鉴权配置改成启用,二是把变更这件事写进交付文档与客户对齐,让客户知道这件事是被显式做过的,而不是被默默改掉的。变更的可见性,在 OPC UA 这种自带安全模型的协议里,比「关掉还是启用」更重要。

第三种典型场景:边缘盒子出厂固件里已经预装了几款主流算法模型,启用这些模型不需要额外授权费。销售按品牌方给的报价单报价,默认报价里不含「预装模型启用」这一项。FDE 进现场,跑一遍模型清单,会发现能直接启用的模型覆盖了客流统计、人数统计、车牌识别等常见任务。处理方式是「按设备已含的能力启用,按实际效果验收」,而不是「重新买一套商业模型授权」。

把这三种场景合起来,「懒得做」的共同特征是:能力在设备里、在协议里、在 SDK 里、在固件里,但不在销售口径里。FDE 的标准动作是翻文档、查能力清单、做验证,把这部分「已含但未提」的能力显式落到交付项里,激励错位就被解开。

五步排查法

面对「做不到」的答复,FDE 的标准动作有五步。

第一步,听清原话。销售说做不到的时候,具体是指哪一步做不到、卡在哪一层。问法,「您说的做不到,是指协议不支持、设备不支持、还是商务不支持?」

第二步,定位文档。如果是协议或设备能力问题,找对应的协议标准文档、设备规格书、SDK 接口说明。这些文档要么公开,要么可以从厂商技术支持拿到。

第三步,验证声称。文档里写的能力,要在自己的环境里实测验证一次。文档说支持 H.265,实际取流可能是 H.264;文档说支持客流统计,实际启用要单独买授权。

第四步,隔离变量。如果验证不通过,逐项隔离,是协议不匹配、是设备固件旧、是网络限制、还是鉴权问题。每一项排除掉一个假设。

第五步,回到人。技术问题排除完之后,如果仍然做不到,剩下的就是商务问题或人的问题。这时候 FDE 要做的不是继续挖技术,而是换对接人,找技术支持、找研发、找商务负责人,而不是和同一个销售反复绕。

把五步合在一起,这条方法的本质是「把做不到的答复变成可证伪的命题」。这是 FDE 在现场最有效的姿态,因为销售面对的是一个会查文档、会验证、会隔离变量、还会换对接人的人。

B4 案例:一个「返回 200 不等于送达」的工程教训

这一卷需要一个技术事故案例来说明「证据分层」这件事。

B4 是一次内部工程验收事故的素材。一名工程师在测试一个消息发送接口时,反复发送实验样本,造成了数据库损坏。事故之后的整改引入了三件事,数据库的快照机制、只读副本、数据安全红线。事故的具体链路在卷四的交付章里被作为「本地通过不等于上线」的工程教训详细拆过,这一卷从另一个角度复用,作为「证据分层」的判据样本。

这件事里最值得写进这一卷的,不是事故本身,而是事故中暴露出来的「接口成功 ≠ 业务成功」的认知盲区。

这个接口的调用路径有四层证据。

S1,接口返回 200。这只证明请求被接收、参数校验通过、消息进入了发送队列。它证明「服务器处理到了这一步」,不证明任何后续环节。

S2,消息离开本地队列,进入下游通道。这要查下游通道的回调或日志。

S3,下游通道把消息送达接收方。这要查接收方的回执。

S4,接收方把消息处理完毕,业务动作发生。这要查接收方的业务日志。

只有 S4 完成,业务才真的完成。但在绝大多数项目的验收里,「接口返回 200」就被当成「业务成功」。这是一个非常常见的偷懒。

事故之后的整改里有一步是把这四层证据显式写进验收模板,每一层都要求独立验证,而不是只看 S1。事故恢复后的回归测试 199 项用例全部 GREEN,验证模板本身的可用性。来源类型,内部工程记录,事故经过、整改措施、回归测试结果均有磁盘证据。

把 B4 的判据迁移到硬件现场,会看到大量同构问题。

摄像机返回推流成功,不证明推流到了平台。推流成功的含义是摄像机的 SDK 把帧写进了它的发送缓冲区,中间经过交换机、网关、平台侧的取流服务、平台侧的解码器、平台侧的存储,任何一环掉链子都让业务失败。FDE 在交付周要查的不是「摄像机有没有报错」,是「平台侧取到的流能不能解、能不能落、能不能按时间序列拼起来」。这两件事差三个数量级。

PLC 寄存器写入成功,不证明执行器真的动了。寄存器写入成功的含义是 PLC 把命令写进了它的内存,中间经过现场总线、伺服驱动器、电机编码器反馈,任何一环掉链子都让动作不发生。FDE 在交付周要查的不是「PLC 有没有报错」,是「执行器有没有真的动、动到位、动完之后状态码是不是回到预期」。这两件事差两个数量级。

传感器上报数值,不证明传感器没有漂移。传感器上报数值的含义是变送器把它当前的物理量转换成了数字,中间经过标定、补偿、A/D 转换、通信链路,任何一环都可能引入误差。FDE 在交付周要查的不是「传感器有没有在报数」,是「报的数跟另一个独立来源的数对不对得上」。这两件事差一个数量级。

每一层证据都要独立验证。这是 FDE 在现场建立信任的基本动作,不依赖任何一方的口头确认,自己查每一层。

把 B4 的 S1-S4 框架迁移到本章第一节的视频侧与第三章的工业侧,会得到一份可以贴在现场工作日志上的证据分层模板。

视频侧的 S1-S4。S1,摄像机 SDK 推流返回成功。S2,帧进入 RTSP 或 GB/T 28181 媒体流通道。S3,平台侧取到流并写入存储。S4,平台侧按时间序列拼出可查询的视频片段。参考实现：在类似烘焙案的多店连锁改造中,把这一模板放在客流取数上,S4 真正的成功标志是「按设定的粒度拼出当日全店客流曲线,且每条记录可回溯到具体时间点的视频片段」;具体粒度以现场建模需求为准。仅 S1 通过不算成功。

工业侧的 S1-S4。S1,PLC 程序里把某个值写进了变量。S2,变量通过现场总线或以太网被读取到网关。S3,网关把数据写入数据库或 MQTT 消息队列。S4,平台侧把数据按时间序列拼出可查询的历史曲线。参考实现：把这一模板放在低速采样传感器场景中,S4 真正的成功标志是「按设定的粒度拼出当日全店温湿度/计数器曲线,且每条记录可与同一时段的其它曲线对齐」;具体粒度、对齐口径以现场建模需求为准。仅 S3 通过不算成功。

把这两段放回 B4 案例的判据里,S1-S4 不是「接口成功」的代名词,它是「业务成功」的工程结构。FDE 在现场把每一层证据写进交付文档,客户验收时按这四层逐项核,「接口返回 200 就算成功」的偷懒就被堵住了。

烘焙案的逆向落地(参考实现)

参考实现：以下按工程常识给出该案五步排查法的形态参考,该案真实实施链路未逐条留档,落地前应以现场记录与卷七案例为准。

第一步,听清原话。FDE 在现场要听清甲方对「数据不存在」的完整表述,包括字面意思与隐含假设。这一步的判据是「把「做不到」翻译成可验证的命题」,而不是接受字面结论。

第二步,定位文档。FDE 让监控厂商技术支持把设备规格书与 SDK 接口说明发过来,翻客流统计相关章节,确认摄像机是否自带客流统计能力,以及该能力是否暴露周期性的推送接口。

第三步,验证声称。FDE 在单一现场环境里启用该功能,实测一段时间,确认数据稳定性。这一步的判据是「不在协议层假设,要在自己的环境里跑一次」。

第四步,隔离变量。单点稳定不代表多店稳定。逐家门店启用功能,逐家实测,把固件版本、网络带宽、权限限制等因素逐项隔离。

第五步,回到人。把验证后的数据通路写进现场工作日志,与甲方负责人对齐责任边界(数据从哪来、谁来维护、谁来订阅、出问题找谁)。把责任落到具体的人,而不是落到一句「应该可以」。

这套方法论的代价是尽量复用现有设备能力,只在新能力所必需的地方加装最少的新硬件。改造的实际代价、节约数字与失败代价,按用户口述（已有实际记录）与脱敏六段稿的素材为准,本卷不复述数字。它的根因是一个标准的「懒」字(销售不会主动提,集成商不会主动提,甲方不会主动问,只有 FDE 进现场,翻文档,验证,落地)。

边界的来源

这一卷最重要的判据,在这一章里要写完。

协议的边界是文档定义的;商业的边界是合同定义的;人的边界是激励定义的。

FDE 的工作,是分辨出每一个「做不到」到底落在哪一类边界上。

落在协议边界上,接受现实,改方案。

落在商业边界上,谈授权、谈合同、谈钱。

落在人的边界上,换对接人、换协作方式、换激励结构。

这三类边界混淆,是绝大多数硬件项目失败的根因。一个项目死掉,事后复盘时如果只说「厂商说做不到」,这个复盘是浅的。它要分清,做不到的是协议、是合同、是激励。同样的「做不到」,处理方式完全不同。把这一层分开,FDE 才有可能在三个月之后回看这件事时,看清自己的判断错在哪、对在哪。

把这一章与卷三原则篇接起来,边界判断这件事在卷三里被升格为诚实律与立法者思维。卷三讲为什么 FDE 必须能说出「这件事不成立」,卷六讲 FDE 在现场怎么分辨「这件事不成立」属于哪一类。卷三给原则,卷六给判据,两者合在一起是 FDE 在硬件现场的核心姿态。

---

第五章　合规红线:三种边界与三条动作

硬件与现场的逆向部分,如果不做合规,就是埋雷。

合规边界在中国现场有三条主线,且在 2025 年集中收紧。FDE 第一周就必须把这三条主线问清楚,否则方案到了交付周才发现推倒重来。

边界一:个人信息,尤其是人脸

中国对个人信息的法律保护已经形成完整框架。敏感个人信息,人脸、指纹、声纹、虹膜等生物识别信息,的采集、存储、使用有专门约束。

2025 年 6 月 1 日起施行的《人脸识别技术应用安全管理办法》是这一领域的首部专门规章。它对人脸验证、人脸辨识两类场景作了严格要求,包括单独同意、显著提示标识、个人信息保护影响评估、不得作为唯一验证方式等。这部规章由国家互联网信息办公室与公安部联合发布,经 2024 年 9 月 30 日国家网信办第 23 次室务会会议审议通过并经公安部同意。来源类型,政策文件原文,中央网信办公开发布。

但这部规章有一个关键的适用范围切割。它针对的是「人脸验证」「人脸辨识」两类场景,即把人脸用于身份确认的应用。「人脸分析」,只对人脸图像进行统计、检测、特征分析,不进行身份识别,不在该办法的直接适用范围,转而适用《个人信息保护法》和相关国家标准的一般规则。

这个切割对 FDE 极其重要。它意味着,客流统计、性别比例、年龄段分布、热区分析这类「只要统计、不要身份」的应用,在合规上比人脸识别宽松得多。参考实现：在类似烘焙案的多店连锁改造中,合规姿态是把摄像机的客流统计能力用起来,而不是把人脸识别用起来。客流统计是「人脸分析」级别,合规压力显著低于「人脸验证」级别。FDE 在第一周必须做的合规动作是,确认项目要做的是人脸分析还是人脸识别。前者要按统计量处理,后者要按身份验证处理。

把这一边界展开,2024 年到 2025 年的执法案例可以给 FDE 一个清晰的现场判据。

2024 年 9 月公开报道,四川某县一家大型超市自 2022 年 11 月开业起提供人脸识别储物柜供消费者使用,17 个月内被认定违规采集消费者人脸信息超过 10 万人次。检察机关以行政公益诉讼立案,向当地商务和经济合作局送达检察建议,要求整改。整改后,涉案超市增加了传统的条码储物柜,消费者可自行选择。来源类型,公开报道,最高人民检察院公开发布的检察公益诉讼案例。

2024 年 5 月公开报道,上海某区一家健身房在进入环节与更衣室储物柜环节均要求人脸识别。检察机关经实地走访认定,更衣室「刷脸」打开储物柜时,摄像头可能拍摄到消费者的隐私部位,与直接刷卡的功能基本一致,不具有法律规定的「特定的目的和充分的必要性」。来源类型,公开报道,解放日报、新华社公开报道。

2024 年 12 月公开报道,上海「亮剑浦江·2024」消费领域个人信息权益保护专项执法行动覆盖全市 600 余家商超门店、6300 余家酒店、1200 余个游泳馆及健身场所、2900 余个公共厕所,完成「强制性」「滥用化」刷脸的自查整改,确立公共场所「不刷脸为原则、刷脸为例外」的总目标。来源类型,公开报道,解放日报、上海市政府公开发布的总结交流会议内容。

2025 年 9 月公开报道,国家网信办通报的典型案例中,上海某科技有限公司运营的自动售货机在用户支付环节未经同意收集人脸信息,且未建立个人信息保护影响评估制度、相关系统存在 SQL 注入高危漏洞,被属地网信办依法责令改正并予以警告处罚。来源类型,公开报道,国家网信办公开发布的执法典型案例。

把这四起案例放在一起,它们给出了 FDE 在商业现场做合规判据的四条边界。

第一,人脸识别设备的安装位置敏感,更衣室、卫生间、浴室、试衣间、储物柜、健身房入口这类与个人隐私高度相关的位置,默认禁止安装。

第二,人脸识别不能作为唯一验证方式,必须同时提供非人脸识别的替代路径。最高人民法院 2024 年发布的司法解释明确,物业服务企业以人脸识别作为业主出入的唯一验证方式,业主有权请求提供其他合理验证方式。

第三,采集人脸信息前必须单独同意,且要以显著方式、清晰易懂的语言告知。默认勾选、捆绑授权、模糊提示,均不构成合规同意。

第四,公共场所安装人脸识别设备应为维护公共安全所必需,且要设置显著提示标识。商业客流统计的目的如被认定为「非公共安全必需」,则不能借这个口子布设采集设备。

把四条边界合在一起,FDE 在商业现场做合规设计的标准动作是,第一件事就问客户,「这个项目会不会涉及人脸信息的采集、存储、传输?」如果客户说不会,接下来确认摄像头的能力清单里有没有人脸识别相关功能,如果有,把功能关掉并验证;如果客户说会,接下来按上面四条边界逐项对齐,在合同与隐私政策里把「目的、方式、范围、保存期限、删除机制」全部写死。

边界二:公共场所视频

2025 年 4 月 1 日起施行的《公共安全视频图像信息系统管理条例》对公共场所的视频建设与管理作了系统规定。条例由国务院公布,共 34 条,明确县级以上地方人民政府加强统筹规划,除负有经营管理责任、安全防范义务的部门、单位或者个人为维护公共安全所必需建设外,其他任何单位或者个人不得在公共场所安装图像采集设备设施。来源类型,政策文件原文,中国政府网公开发布的国务院令。

它对 FDE 有意义的几条。

场所内的视频建设应当为维护公共安全所必需,设置显著提示标识。所收集的个人图像、身份识别信息原则上只能用于维护公共安全的目的,除取得个人单独同意外,不得用于其他目的。

这意味着,在公共场所用摄像机做客流统计,即「维护公共安全」之外的商业目的,技术上不违法,但如果摄像机的位置和标识不清晰,采集过程不透明,就处在灰色地带。

FDE 的判据。

第一,客流统计的物理位置必须在显著标识下进行。摄像机的覆盖区域、拍摄角度、用途提示,要让进入这片区域的人在合理范围内知情。

第二,只取统计量,不留可识别信息。具体动作是边缘侧处理,摄像机或边缘盒子当场完成客流计数、区域统计、热度图计算,原始视频帧不向上传输、不长期存储。

第三,如果必须保留原始帧用于回溯,保留时间要严格限定,访问权限要严格控制,删除机制要可证明。

把这一边界展开,2024 年的执法数据可以给 FDE 一个量级感。

公开报道显示,2024 年全国公安机关深入推进「净网」专项行动,共侦破侵犯公民个人信息案件 7000 余起,公安部公开了 10 起典型案例,涉及物流快递、教培行业、招聘平台等多个行业。来源类型,公开报道,公安部公开发布的典型案例。同期国家网信办集中查处 82 款违法违规 App,涉及未公开收集使用规则、未按法律规定提供删除或更正个人信息功能等问题。来源类型,公开报道,国家网信办公开发布的查处通报。

这些数据给出的不是「具体哪家公司」,而是「全国范围内此类违规被查处的量级」。FDE 在现场对客户讲合规风险时,可以引用这个量级,提示客户这件事不是潜在风险,而是被实际查处的现实风险。

边界三:数据出境与本地优先

数据出境是另一条硬线。企业的运营数据、生产数据、设备数据,凡是被识别为「重要数据」或达到一定规模,出境前要经过安全评估。

具体到硬件现场,出境风险最容易发生在两个动作。

一,送境外模型做推理。哪怕只是为了试一下效果,只要数据离开了境内网络,就可能违反出境规则。

二,边缘盒子或云平台的部署位置。如果盒子必须部署在境外,或者平台租用了境外的云服务,数据出境的事实就已经发生。

FDE 在第一周要问清楚的三个合规问题。

第一,数据出不出得了这栋楼?出不了,方案从第一天起按本地部署设计。

第二,项目里的数据是不是「重要数据」或达到出境申报规模?是,提前做安全评估。

第三,涉及个人信息吗?是,按敏感个人信息规则处理,获得单独同意或书面同意。

把这一边界展开,本地优先是硬件现场合规设计的默认姿态。不是因为云端一定不行,而是因为本地优先把合规复杂度的上限压到了最低。参考实现：在类似烘焙案的多店连锁改造中,合规姿态是从一开始就把原始客流与温湿度数据留在门店本地与中央平台本地,云端只做最终聚合后的统计查询,且查询口径设计为「当日各店建议配送量」这种不包含可识别信息、不包含个人轨迹的数据;具体云端聚合范围以现场架构为准。云端那点数据出境风险,通过本地优先被直接规避。

三条动作:边缘侧处理 / 只取统计量 / 原始帧不落盘

把上述三条边界翻译成 FDE 在现场的三个标准动作。

动作一,边缘侧处理。智能分析尽量在摄像机侧或边缘盒子侧完成,不要把原始视频流送到云端做推理。物理上把数据留在本地,合规上的优势显著。参考实现：在类似烘焙案的多店连锁改造中,合规姿态是每家门店的客流统计在本地边缘盒子完成,原始视频帧在盒子上处理后即被丢弃,不向上传输,不留存;具体盒子职责与上行数据范围以现场架构为准。

动作二,只取统计量,不取身份。项目设计阶段就明确,要的是客流数,不是人脸;要的是热区分布,不是个体轨迹;要的是异常事件告警,不是异常人员身份。这一刀切下去,合规风险直接降低一个量级。参考实现：在类似烘焙案的多店连锁改造中,合规姿态是从一开始就不启用、不消费人脸识别相关功能,所有分析都在「只取统计量」的口径下做,具体功能开关以现场设备能力为准。

动作三,原始帧不落盘。即使必须保留视频用于回溯,保留的位置、保留的时间、访问的权限、删除的证明,都要写进设计文档,并在交付时验证。

这三条动作不是技术清单,是 FDE 在现场对客户和对自己同时负责的纪律。

合规的第一周动作

硬件项目的第一周,FDE 必须把以下四件事在客户面前问清楚、记下来、写进合同或工作说明。

一,项目是否涉及个人信息?涉及,按敏感个人信息处理;不涉及,把「不涉及」写进合同。

二,摄像机的位置、覆盖范围、是否有显著标识?没有,先整改再继续。

三,数据是否限制在境内?是,本地部署;否,做安全评估。

四,是否使用人脸识别相关功能?使用,按人脸验证或人脸辨识的高压合规处理;不使用,关闭相关功能并在合同里写死。

这四件事如果不能在第一周形成书面结论,后续每一个动作都埋雷。

把这一节再补一段实操判据:FDE 在现场要能讲清楚「什么时候做隐私影响评估,什么时候不做」。

判定标准是项目是否触发《个人信息保护法》第五十五条所列的任一情形。处理敏感个人信息、利用个人信息进行自动化决策、委托处理个人信息向境外提供、公开个人信息、其他对个人权益有重大影响的处理活动。这五条里只要触发一条,就必须做个人信息保护影响评估,记录处理目的、处理方式、对个人权益的影响、安全保护措施等。

把人脸识别这一项单独拆开,GB/T 44248-2024《信息技术 生物特征识别 人脸识别系统应用要求》是当前国家对人脸识别系统应用的基础标准,系统建设完成后应符合网络安全等级保护第三级及以上保护要求。这一条对 FDE 的实操意义是,人脸识别项目不能拍脑袋做,要有合规自评、有安全等保备案、有个人信息保护影响评估报告留底,这三件事在合同里就要写清楚,而不是交付周再补。

把这一条翻译给客户,话术是:「如果项目涉及人脸识别,我们要先做隐私影响评估和等保备案,这两件事的工时和成本要写进合同。如果项目只做客流统计这种'只要统计量、不要身份'的分析,可以按个人信息保护法的一般规则处理,不需要走人脸识别的高压流程,但仍然要明确告知与合理标识。」

FDE 把这一段讲给客户,客户才知道「分析」与「识别」在合规上不是一回事,商业项目里绝大多数「智能摄像头」的需求其实只是「分析」级别,合规压力比客户自己想象的小一个量级。

合规边界的失效条件

合规这一节比协议和逆向都更容易过时。法律在更新,执法力度在调整,各地方法规在补充。本节按 2026 年 8 月情况写,失效条件如下。

如果未来三年内出现以下任一情况,本节需要重写。

一,《人脸识别技术应用安全管理办法》或其后继规章把「人脸分析」纳入适用范围,或者显著提高商业场所使用人脸分析的合规门槛。

二,公共场所视频的相关条例对商业目的使用作出更严格的限制,或对原始帧留存的默认期限作出强制规定。

三,数据出境规则进一步收紧,边缘部署的本地化要求扩展到中小型企业。

四,公开报道中出现了对「边缘侧处理 + 只取统计量 + 原始帧不落盘」这套姿态的执法否定或行业自律否定案例。

失效条件的意义不是吓唬读者,是让三个月后读到这本书的人能自己判断哪一节该跳过。

---

本卷法条

FDE 第六法 · 现场律

数据不在系统里,在设备里;在现场的人有义务也有权利把它要出来,但要拿协议文档做边界、拿合同做边界、拿合规红线做边界。

推论:FDE 的现场判断由三类边界共同决定,协议定义的「能不能取」、商业定义的「愿不愿意给」、合规定义的「该不该取」。三类边界混淆,项目必败。逆向方法论是分清这三类边界的标准动作,边缘侧处理、只取统计量、原始帧不落盘是把分清边界后的合规姿态落到现场的三条默认动作。

失效条件:如果出现一种自动化的现场数据采集方式,能让 FDE 不需要阅读协议文档、不需要与销售和客户谈判、不需要做合规评估就能拿到正确的数据,本法作废。