企业官网建设流程全解析

我在做本体平台架构评审时，被问得最多的往往不是“总体架构怎么画”，而是这类问题：某台设备的断网数据回来后怎么补？设备报警之后，车间大屏上的视频画面从哪里拉、延迟多少？这条工艺参数波动超过阈值，是边缘端判断还是云端算？这些问题如果在方案细化阶段没有答案，后面开发时大概率会靠“边写边想”来救火。

这篇文章是“本体平台总体架构”系列的第三篇。前两篇我把总体蓝图和技术演进逻辑讲完了，这篇就专门拆两件事：业务需求怎么收敛，技术架构实现方案怎么细化。为了不让讨论悬在概念层，我会沿用同一个场景：一家装备制造工厂建设数字化车间平台，覆盖设备、生产、质量、仓储物流、能源安全以及视频监视等业务域。如果你正在做类似的工业互联网平台、智慧工厂底座，那么这篇里大部分取舍和链路设计可以直接拿去参考。

1. 先把“本体平台”的边界钉死，再说业务需求

1.1 为什么很多需求讨论会“越聊越散”

我见过不少项目，第一轮需求访谈去了几天，回来之后整理出一百多条用户愿望清单，从“车间温度异常要能提醒”到“未来最好接入AI质检”，全往一个平台里面塞。这种需求清单看似丰富，实际没法指导架构，因为大家根本还没回答一个问题：这个平台到底承接什么，不承接什么？

最开始团队对“本体平台”的理解也五花八门。有些人以为是设备监控系统的升级版，有些人觉得应该是MES的底座，还有人说干脆做成大屏展示工具。为了统一口径，我在项目里把本体平台定义为：面向工厂数字化场景的公共技术底座，它沉淀的是设备接入、数据治理、对象模型、事件分发、统一权限、可视化渲染等横向能力，而不是某个具体业务应用。也就是说，业务系统的个性化流程由MES、WMS、质量系统各自承担，本体平台负责把数据打通、把对象描述清楚、把通用能力开放出来。

1.2 需求分类：从“愿望清单”到“平台能力清单”

需求归纳阶段，我习惯先做两层切分。第一层看需求属于“业务应用需求”还是“平台能力需求”。比如“库存低于安全水位要报警”，这背后是业务库存阈值规则，通常由WMS定义；但“平台需要接收仓库库存事件并分发给订阅方”就是典型的平台能力。第二层看需求的公共性，如果多个业务域都有类似诉求，那基本可以判断为公共能力，要往“本体层”沉淀。

下面的表格是我们在项目早期整理出来的需求优先级，全部先统一编号，后面评审和排期都用编号说话，避免大家口口相传产生歧义。

这份清单有两个价值。第一，它让每个人清楚知道哪些需求范围在本体平台内、哪些需要协调外部业务系统。第二，它为后面技术实现方案的模块划分提供了输入，每个编号最终都能对到一条技术链路，而不是停在口头描述上。

1.3 几个容易忽略的非功能性需求

功能性需求之外，还有几个非功能点必须在方案阶段就明确，不然上线之后非常难受。

一是数据可靠性。车间网络不能假设永远稳定，边缘网关和中心端会断网，断网期间的采集数据不能丢，必须支持本地缓存和断点续传。这个需求直接决定要不要在边缘层放存储，以及消息队列的ack机制怎么设计。

二是时间基准。现场很多设备自身没有时间同步机制，如果网关不统一做时间校准，不同设备的事件先后顺序会错乱，OEE和告警分析直接失真。所以边缘网关需要具备NTP同步能力，或者统一以上报到达平台的时间为准，在元数据里标明时间戳来源。

三是接口遵从。前期必须把“哪些对象以哪个系统为唯一数据源”定义清楚，例如设备台账以资产管理系统为准、工单以MES为准，本体平台不另维护一套主数据，只同步数据和维护关联关系。这是避免后期数据打架的关键约束。

2. 用主线场景推演：业务需求怎么变成平台能提供的服务

2.1 走一遍“从工单下达到成品入库”的业务主线

需求清单列完后有一个很有效的动作：把业务主流程从头到尾走一遍，看看每个环节里本体平台应该出现在哪里。

我举一条典型机加工生产主线来做场景推演：

计划员在MES系统下达生产任务。WMS根据工单齐套发料，AGV把物料送到对应机台料架。设备读取任务后开始加工，边缘网关持续采集设备状态、主轴转速、主轴负载、冷却液温度、产量计数等数据。一个产品完工后报工。质检人员录入检验结果，发现不良时触发处置流程。成品完工后，AGV搬运入库。如果中途发生主轴报警、物料缺料或者温度超限，需要维修和调度人员快速介入。

在这个主线上，MES、WMS本身已经有完整的功能界面和业务流程。本体平台不是把这些流程重写一遍，而是负责提供三个底层支撑：实时状态感知、对象间的关联关系、跨系统的事件分发。

2.2 平台介入的四个关键节点

第一是“感知节点”。设备的启停、加工、报警状态，以及主轴负载等工艺参数，由边缘网关采集后进入平台，形成统一设备状态模型。业务侧不再需要分别找不同厂商拿数据。

第二是“同步节点”。当MES把工单下发给设备时，平台把工单信息与采集到的设备实时状态关联起来。例如同样一台CNC发生报警，有工单上下文时，系统能判断当前影响的是哪个订单、哪些批次，重要程度完全不同。

第三是“质量追溯节点”。质量检验数据进来后，平台根据设备号、工单号、物料批次号、操作工账号建立一张关系网络，让一个不良品可以关联回当班人员、来源批次、工序参数、加工时段视频片段。

第四是“异常处置节点”。设备报警事件触发后，平台把事件推送给责任角色，同时联动视频模块，把报警前后一段时间的现场画面抽出来，供处理人员快速判断现场状况。这一个场景在本体平台里具有代表性，因为事件需要同时驱动消息推送、对象状态变更、视频联动、历史归档四个子模块。

2.3 需求向平台能力的映射关系

把上面这些场景再提炼一层，可以得到业务需求与平台能力之间的对应关系：

我在评审会上经常把这个映射表称作“翻译层”。业务提需求，技术部画架构图，中间少了这层翻译，就会出现业务觉得技术不懂现场、技术觉得业务提需求不过脑子的情况。映射表一旦明确，后续排期和技术边界就都有了共同依据。

3. 技术架构实现方案：分层、落位与关键决策

3.1 平台分层的落地视角

技术架构在总体层面仍然延续前一篇的逻辑分层，但细化时我更习惯从部署视角重新组织。实际部署分为三个区域：车间边缘侧、中心机房、展示终端侧。

车间边缘侧是数据的第一入口。工控机或者边缘网关部署在产线附近，通过Modbus TCP、S7、OPC UA、FOCAS等协议连接PLC、数控系统、传感器和第三方设备。视频摄像头也接入这一侧的视频网关，完成RTSP拉流和转封装。

中心机房承载平台的公共能力，包括设备对象模型、消息总线、实时计算、时序数据库、关系数据库、对象存储和API服务。这里既是数据流转的中枢，也是前端访问的后端。

展示终端侧指车间看板、中控室大屏、办公区PC和移动端。这一侧通过WebSocket接收实时状态，通过HTTP接口查询统计报表，通过HTTP-FLV拉取实时视频流。

这套分层让“平台”不再是一张抽象的云上架构图，而是能看到数据在每个物理位置如何流动。架构评审时把部署拓扑图画出来，比评审一堆组件名称有用得多。

3.2 关键技术选型与理由

消息总线用的是Kafka，主要用于处理高频点位数据和设备事件。边缘采集数据可能是成千上万的点位，如果直接用业务服务消费高频点位数据，任何业务接口抖动都会造成消费阻塞。Kafka在削峰填谷和应用解耦上是成熟选项，而且后续如果需要接Flink做流式计算，生态也最顺。

时序数据库方面，我倾向工业原生IoTDB。点位数据是典型的写多读少、按时间区间查询、需要压缩存储的数据。IoTDB在工业协议支持、批量写入、压缩算法和降精度查询方面更贴合。如果团队非常熟悉InfluxDB，也不是不能用，但要注意在连接数和查询优化上留足余量。点位规模只有几千、查询并发极低的小项目，甚至可以先不单独引时序库，用MySQL按时间分区过渡，但架构上要有替换时序库的接口边界。

实时计算的引入要克制。如果一开始设备量只有几百台、点位只有几千个，并且只做阈值告警和设备状态判定，没有必要上Flink，规则引擎加定时聚合任务就能解决问题。但平台里如果存在按全班次聚合、多设备联合判定、长时间窗口计算等需求，脚本化规则会变得非常难维护。我遇到的取舍是：点位的标准化和清洗放在Kafka消费者流里用规则完成，涉及需要跨设备、跨时间窗口的统计才抽出来交给流式计算任务。这样既保证了扩展性，也不至于从一开始就把链路做重。

对象存储选择了MinIO，用来存视频事件片段、质量照片、大屏截图等非结构化数据。关系数据库和缓存分别选PostgreSQL和Redis，承担元数据管理和高频状态缓存。

3.3 不要盲目微服务化的提醒

关于应用层的服务划分，一条非常容易被忽略的原则是：微服务不是目标，业务边界和运维能力才是。如果团队只有四五个人，却计划在平台一期拆出二十个微服务，基本上等于给自己挖坑。

我在这类平台项目里更推荐“模块化单体加清晰API边界”。在代码工程内部按设备接入、事件中心、对象管理、视频联动、可视化服务划分清晰模块，定义好内部接口。只有当某个模块确实有独立水平扩展需求，例如视频网关并发路数远超其它模块时，才把它单独拆成一个服务部署。这样的架构在一期压力不大，后期演进也很平滑。

以下是我们一期落地的服务边界清单：

4. 数据从车间到展示端要经过几道工序

4.1 设备点表是数据链路的源头

设备接入阶段最费时间、最容易被低估的其实是点表。点表是什么？就是每台设备采集点位的一张配置清单，例如一个温度点，需要知道它是Modbus的哪个寄存器地址、数据类型是16位还是32位、有没有缩放系数、采集周期多少、超限阈值多少。

如果不把点表当成正式交付物来做，实施时就会出现采集变量名混乱，这台设备叫Temp01，另一台设备叫temperature，后期写质量相关性分析时，代码里全是魔法字段。我的做法是：接入前由技术人员根据设备说明书记录点位四元组（协议、地址、类型、缩放），并统一按“设备型号_部件_参数名”的规范命名，例如cNC01_spindle_speed代表1号加工中心的主轴转速。点位数据进入平台后，要根据规范自动生成标准模型字段，而不是把原始地址直接丢给上层。

4.2 数据链路从采集到落库的完整工序

一条数据从设备端走到前端大屏，中间要经过四道工序：

第一道是边缘侧采集与边缘预处理。网关按点表周期读取数据，做单位转换、量程校验、设备在线状态判断，再推送到消息队列。这样做的好处是中心端收到的已经是规范数据，不需要反复处理脏值。

第二道是消息排队与缓冲。数据进入Kafka后，分为原始点位Topic、标准化点位Topic和事件Topic。不同Topic定义不同分区策略，设备点位Topic按deviceId分区，保证同一台设备的数据有序。

第三道是流式清洗与存储。消费者服务从标准化点位Topic取数，完成异常值剔除（例如超过量程一定比例的数据直接丢弃并告警）、变化率检测（短时间跳变超过阈值标记为突变），然后写入时序数据库。事件型数据则交给事件中心。

第四道是指标计算与状态更新。实时指标如设备状态、开机率、当前产量，在数据到达时以较小窗口聚合，并推送到Redis。历史指标如班次OEE，通过离线或准实时任务计算后写入关系表和结果集，供报表和大屏查询。

4.3 一个OEE计算的实际口径

OEE是管理者最关注的指标之一，但计算口径如果没有在方案阶段定清楚，实施时一定会被反复挑战。OEE等于可用率、性能开动率、合格率的乘积，其中每个子项都需要明确的统计口径。

举例来说，一台设备计划早上8点开机，计划开8小时，中间设备故障停机1小时，理论节拍是60秒一件，实际加工了400件，其中380件合格。这里的时间开动率是（计划时间480分钟-停机60分钟）/计划时间480分钟，等于87.5%。性能开动率是（理论节拍60秒乘以实际产量400件）除以实际运行时间420分钟乘以60秒，约等于95.2%。合格率是380除以400，等于95%。最终OEE约等于87.5%乘以95.2%乘以95%，大约79.1%。

这个例子不复杂，但真正做起来，难点往往在于设备停机时间从哪里来、理论节拍由谁维护、产量计数由设备硬点信号确认还是人工报工结果为准。这些主数据口径一旦确定，要写进方案文档并在验收时逐项核对，不能到做报表时才跟业务部门争论。

4.4 断网补传与时间线校准

边缘侧到中心端的网络不可能永远稳定，所以链路设计里必须有断点续传策略。我们的边缘网关会在本地落盘一段时间的原始报文，每批次数据带一个递增序号。正常时实时推送并确认，网络恢复后从最后确认的序号继续补传，平台侧对补传数据打上“迟达”标记。

为什么一定要标记迟达？因为实时统计和报表查询可能需要区分数据是实时到达还是补传过来的。如果补传数据和实时数据混在一起且时间序错乱，OEE分钟级曲线就可能出现回退，大屏展示会非常奇怪。迟达标记至少可以让前端判断是否触发局部刷新。

5. 智慧工厂“看得见”：低延迟视频与前端可视化

5.1 视频在本体平台里的定位不是“装个监控”

设备报警之后，大屏或移动端如果能直接弹出对应机位的现场画面，处理人员能马上判断是刀具有明显破损、还是只是临时报警，响应效率完全不同。所以视频接入在本体平台中属于“对象关联”的一部分，它与设备事件、工单、时间线绑定，而不只是提供一个独立的视频墙页面。

视频链路采用RTSP加HTTP-FLV的组合，这是一个我自己反复对比后的选择。摄像头普遍支持RTSP协议，但浏览器不能直接播放RTSP流。RTMP过去需要Flash插件，HLS协议在浏览器原生支持较好但延迟太高，而智慧工厂监看场景需要在设备发生报警时快速看到现场，延迟目标在一到三秒。HTTP-FLV在这种场景下恰好合适，flv.js在浏览器端几乎做到了全覆盖，不需要额外安装插件。

5.2 FFmpeg、流媒体服务与flv.js组成的主链路

从摄像头到页面的详细链路是：IPC通过RTSP协议接入视频网关，视频网关调用FFmpeg把RTSP拉流转封装为FLV格式并推送到ZLMediaKit流媒体服务，页面端再用flv.js拉取HTTP-FLV流播放。

控制面会单独走WebSocket或者HTTP接口，例如前端请求某个机位的播放地址，ZLMediaKit返回可播放的URL，页面只对接到这一个地址，不直接暴露摄像头IP。这样避免了大范围暴露现场设备，也让多个业务页面可以复用同一路视频流，不至于一台摄像头同时被多路请求拉到卡死。

需要特别提醒的是编码格式兼容性。FLV封装通常承载H.264视频，flv.js对H.265支持很差。如果现场采购的摄像头编码默认是H.265，方案阶段就应该要求设备端同时输出H.264子码流，或者视频网关对H.265做转码。否则等到现场实施再发现播放黑屏，处理成本会高很多。

5.3 事件联动录像回看的实现思路

回看报警前3分钟录像，这在本体平台场景里价值很高。平台判断到设备报警后，事件中心把带时间戳的报警事件推给视频联动模块，该模块再去存储系统里查找对应通道的录像。如果是部署了边缘录像的摄像头，可以直接读SD卡使用车牌算法类似事件定位；如果是后端统一录像，就需要按通道、时间段做索引。

更实用的一种做法是：视频网关配置持续循环录像到本地磁盘，当平台侧产生报警事件时，视频联动模块自动截取报警前120秒、报警后60秒范围内的视频片段，转存到MinIO并生成一张报警时间点的现场截图。这样处理人员不需要去翻录像，点击告警详情就能直接看当时的现场画面。这个机制的底层逻辑是“把视频作为一种事件附件交给业务系统”，比把视频系统做成一个孤立的观看工具要贴近生产场景得多。

5.4 前端智慧工厂可视化方案：从“满屏图表”到“场景对话”

前端可视化呈现，我建议按三个层次渐进设计。

第一层是数据驾驶舱。通常展示全厂关键KPI，OEE趋势、产量完成率、今日报警数、能耗数据和Top异常事件。数据变化频率不高的用HTTP接口轮询即可，高频变化的如设备实时状态，走WebSocket推送。避免所有指标都用WebSocket刷新，否则前端大量渲染计算会拖垮浏览器。

第二层是三维车间场景。基于Three.js加载车间和设备模型，把设备状态与三维对象绑定。设备正常运行时显示绿色，故障显示红色，停机显示灰色。当设备状态变化时后端推送标准的事件消息。

{ "type": "device.status.update", "deviceId": "CNC-0158", "status": "fault", "ts": 1721300000000 }

前端收到这个消息后，根据deviceId找到场景中对应的三维模型，更新材质颜色、弹出标注面板，同时联动右侧的告警列表和设备实时视频窗口。

第三层是事件驱动的联动页面。报警事件发生时，页面自动聚焦到对应设备，展示设备最近趋势曲线、报警前后视频、当前工单和最近几天同类型故障的处理记录。这个页面实际上在做跨对象的数据关联，前端写得再好看，背后依赖的还是对象模型服务把关系维护好。

前端实际开发中踩过的坑也要分享一下。flv.js连续播放一段时间后偶尔卡死，我遇到的更多是流媒体服务端连接超时或者网络闪断导致浏览器端进入异常状态。解决思路是不要依赖播放器内部自动恢复，要监听异常事件，错误发生时主动释放当前实例，延时重建播放器并重新拉流。大屏页面上同时播放的视频路数也不要贪多，普通PC上超过十几路HTTP-FLV并发后，CPU和内存占用会明显上升，建议大屏默认只展示关键设备，其它画面做成轮播或者按需打开，必要时用定时截图代替实时视频。

6. 细化后的落地路线与常见风险

6.1 三个阶段的推进节奏

方案细化完成之后，项目落地要有明确的节奏，不能妄图一口气建完所有能力。我习惯把时间切成三段。

第一阶段目标是打通“数据链”。选定一两条有代表性的产线设备，完成协议接入、点位标准化、时序存储、设备状态模型和总览看板。这个阶段的验收标准不是功能多丰富，而是数据准确率，例如设备状态与现场实际状态不一致率是否低于某个指标，报警从发生到页面弹出是否在数秒内。

第二阶段目标是打通“事件链”。在数据链基础上接入工单信息、质量检验和告警通知，让平台不再只是一个显示大屏，而是一个能推送事件、辅助处置的业务支撑系统。视频联动也可以在这个阶段接入。

第三阶段目标是扩展“对象链”。从几条产线扩展到一个车间甚至整个工厂，接入仓储物流、能源、环境系统，丰富三维场景，把质量追溯和数据分析做深。第三阶段才适合考虑AI分析类应用，因为底层数据和事件链路已经稳定。

6.2 分阶段时容易犯的错

一个典型误区是第一阶段就把所有业务域的看板全做出来。接口对接还没稳定，指标口径还没对齐，页面做得再好看，上线后也会被业务部门怀疑数据的可信度，后面再做任何动作都要先解释数据为什么不对。

另一个误区是把全部设备状态接入做完再去做业务功能。很多现场设备通讯协议标准不统一，要对接的设备又多，纯接入工作很容易延后。正确做法是不追求接入数量，而是先把一个场景从设备到页面完整跑通，让业务部门看到闭环价值，后续推广才有说服力。

6.3 团队配置和长期演进

从实施角度，平台项目至少需要四类角色：边缘接入工程师负责协议对接和现场实施，后端工程师负责链路、数据服务和事件中心，前端工程师负责大屏与三维场景，测试加运维的人保障交付质量和环境稳定。这个配置不需要很庞大，但缺一不可。

长期演进的关键在于规范化约束。点表命名规范、topic命名规范、事件格式规范、对象模型变更流程，这些约束能不能在项目初期沉淀下来，直接决定后期平台还能不能继续扩展。技术框架可以换，数据结构可以通过中间层适配，但如果规范崩塌，改造代价会越来越高。

我在本体平台项目里最深的体会是：业务需求和技术架构实现方案之间没有一蹴而就的对齐动作，需要一轮一轮细化、一个主场景一个主场景推演。只有让自己站到业务人员的工位旁边走完一遍流程，你才会知道设备报警后的那声通知、那段录像、那条工单关联关系，到底比画一百个架构图更重要。