企业官网建设流程全解析

工业边缘网关选型这件事，看着像是查参数表，实际上是一场需求翻译和预算博弈。今年我负责一个汽车零部件厂的设备数据采集项目，要把37台PLC、86块智能仪表的数据统一收到私有化MES，还要在产线侧做轻量的边缘规则判断，前前后后拉了8个候选网关，最终筛到2个进入现场实测。这个过程中踩的坑比想象中多，今天把整个选型思路和筛选过程整理出来，希望能给正在做类似选型的人一点参考。

当时项目背景不复杂：客户工厂里西门子S7-200 SMART、S7-1200、三菱FX5U这些PLC混着用，还有一部分老旧设备走Modbus RTU仪表输出，既有485总线，也有网口。客户要求很明确：数据必须稳定采集、断网不能丢、要能跑本地规则、还要支持远程运维。预算卡得不算紧，但也不能随便超。基于这个前提，我花了差不多三周时间，从需求梳理、候选池搭建、硬性过滤、加权评分，一直到两台设备现场实测，才算把选型这件事定下来。

1. 先把业务需求翻译成选型指标

1.1 项目背景和我们要解决什么问题

很多选型失败，不是产品不好，而是需求没想清楚。客户说“我要数据上云”，这句话听起来简单，实际落到网关选型上会变成一堆技术指标：现场有多少种设备、走什么协议、数据量多大、断网容忍多久、边缘计算跑什么逻辑、有没有人专职维护、机柜空间多大、供电是否稳定、环境温度多少。

我这次先带着笔记本去现场转了一圈，不是简单抄设备铭牌，而是把机柜、走线、网络环境、电源情况都拍照记录。设备清单出来后，发现真正的需求比客户口头描述的复杂：PLC型号跨度大，老设备走Modbus RTU，新设备走Modbus TCP，还有两台设备要用OPC UA对接。数据量方面，正常采集频率是1秒一轮询，每条数据几百字节，峰值情况下网关要能一秒处理几百个点位。

这些信息汇总后，我给自己列了一个问题清单：

• 现场需要多少个串口，多少个网口？
• 支持哪些工业协议，能否同时跑多协议？
• 边缘计算是跑轻量规则还是复杂容器应用？
• 4G和有线网络同时在线还是切换？
• 断网时数据缓存能撑多久？
• 有没有远程维护和远程升级需求？
• 工作温度、湿度、振动条件是怎样的？
• 供电是24V直流还是现场存在电压波动？
• 预算上限是多少，需要含配件还是裸机价格？

1.2 需求清单怎么列：从业务要求反推硬指标

把业务问题翻译成硬件指标，这一步是整个选型的核心。我习惯的做法是先把“业务描述”列一列，再翻译成“网关硬性指标”，最后标出“必须满足”和“最好满足”两档。这样才能在后续筛选中做到不感情用事。

当时的需求翻译结果大致如下：

这里有个关键点：硬性指标一定要“可验证”。比如“支持Docker”，要能问清楚是完整版Docker还是阉割版；比如“支持Modbus”，要问清楚是网关自己跑协议，还是必须在云平台做解析。很多产品宣传页写得模模糊糊，后面实测才发现跟预期差很远。

1.3 哪些需求最容易在选型时被忽略

前面列的需求都算显性需求，真正让选型翻车的是隐藏需求。我这次吃了几个亏，提前说出来：

第一是断网缓存的数据格式。有些网关断网缓存是私有格式，恢复联网后只能传到自家云平台，如果客户用的是私有化MES，数据就取不出来。必须确认缓存数据能不能按标准格式导出，或者能否本地读取。

第二是远程运维的安全边界。客户要求在出差时能远程改配置、看日志，但内网环境不能暴露太多端口。有些网关的远程功能必须连接厂家云平台，有些支持自建跳板机。这个需求要在选型前问清楚，否则项目实施阶段会很被动。

第三是安装空间和供电。很多网关标称性能很强，但体积巨大，客户机柜里根本塞不下；有些网关电源接口特殊，现场没有对应适配器。这些小问题看起来不起眼，实际上会影响选型结果。

所以我的建议是：在圈候选产品之前，先把上述需求整理成一张表格，发给厂商让他们逐条确认。回答含糊的，直接在候选池里往后排。

2. 8个候选是怎么圈出来的

2.1 选型池从哪来：供应商和渠道

候选产品不是凭空来的。我的渠道主要有三个：以前项目里用过的、同行口碑推荐的、以及工业电商平台上搜索出来的热门型号。这三个渠道覆盖了不同定位：老牌厂商的产品稳定但贵，初创品牌的灵活但资料少，中间派产品可能是性价比相对合适的。

我当时圈了8个候选，没有刻意追求品牌覆盖面均衡，只要求它们都是工业级产品、都能在网上找到公开规格书。品牌来源包括国际知名工控厂商、国内老牌工业通信厂商、从DTU转型做边缘网关的厂商、以及新兴边缘计算公司。这里不具体点名，用G1到G8代号说明。

2.2 候选清单与主打卖点

这份清单最大问题是产品定位差异很大，直接比价格没意义。所以必须先统一“评标口径”，通过硬性指标过滤掉明显不合格的，再通过评分拉开差距。

2.3 第一轮硬性过滤的淘汰逻辑

硬性过滤就是“一票否决制”，不满足需求清单里“必须”项的，直接出局。这样可以避免后面评分时被其他优点带偏。

我按需求清单逐条核对，第一轮硬性过滤的淘汰情况：

• G2虽然是PLC厂商出身，但它的网关对自家PLC支持确实好，对Modbus RTU和OPC UA的支持偏弱，尤其OPC UA需要额外买授权，项目成本会超，淘汰。
• G5是从DTU转过来的，4G和上网能力没问题，但Docker支持不完整，很多常用镜像跑不起来，边缘计算需求满足不了，淘汰。
• G6功耗低、体积小，但内存只有512MB，串口只有2路，接口不够用，淘汰。
• G8价格确实低，但工作温度范围标称只有0到50℃，客户车间夏天温度接近45℃，加上柜内升温，余量太小，不敢用，淘汰。
• G7是x86方案，性能和软件生态不错，但功耗偏高，客户现场机柜没有额外散热，长时间运行不放心，虽然它没被硬性淘汰，但后面评分会受影响。

第一轮下来，8个候选剩4个：G1、G3、G4、G7。这个结果符合预期：能走到评分阶段的产品，至少是“参数上没有明显短板”的。

3. 第二轮打分：给剩下候选排优先级

3.1 评分模型怎么建

剩下4个产品，直接看参数表已经分不出绝对好坏，必须上评分模型。我采用的是一种很常见的加权评分法：列出选型关注的维度，按项目需求的重要程度分配权重，再让参与选型的几个人分别打分，最后取平均分。

我当时设的维度权重如下：

这套权重不是拍脑袋定的。对这个项目来说，软件生态和硬件性能直接决定边缘计算能不能跑起来，所以权重最高；接口丰富度是现场接入的基础；工业可靠性是长期稳定运行的底线；价格和供货反而排得靠后，因为预算本身够用，但也不能完全不管。

3.2 评分过程要避免的坑

评分环节最大的坑是“信息口径不一致”。我在向厂商要参数时发现，有些产品明面上说支持Docker，但实际是裁剪版或需要定制固件；有些说支持Modbus TCP，但只做客户端，不做服务端；有些说支持OPC UA，但只支持DA，不支持HA，现场对接MES时很麻烦。

解决方法是先发一份“功能确认函”，把每个关键技术点都列出来，让厂商逐条回复“支持/不支持/定制支持”并附证据。比如：

• 是否内置完整版Docker Engine，能否跑标准容器？
• 是否内置Node-RED、Python运行时？
• 是否支持Modbus主站和从站两种模式？
• 是否支持协议转换并同时写入多个云端？
• 断网缓存的数据能否通过标准API读取？
• OTA升级失败后能否自动回滚？

厂商回复越具体，评分越靠谱。如果厂商只给一句“支持”，后面实测大概率会踩坑。

3.3 打分结果：4进3

按百分制打分，4个候选的结果拉开了一些差距：

G7虽然性能和软件不错，但工业可靠性和体积功耗拖了后腿，最终没有进入下一轮。G1、G3、G4进入现场实测阶段。

需要说明的是，评分结果不能当结论用。它是一个排序工具，告诉你哪些产品值得花时间实测，不能直接选总分最高的就下单。所以下一步是把这三个候选都拿到手，在真实环境里跑一跑。

4. 最终2个候选的现场实测对比

4.1 实测环境怎么搭

选型到这一步，只看资料已经不够了。我在项目现场借了一个空机柜，把三台候选网关同时接上模拟设备和部分真实PLC，搭建了几乎等同于正式部署的测试环境。

测试环境包含：

• 一台西门子S7-1200，用Modbus TCP协议读数据
• 一台三菱FX5U，用三菱专用协议读数据（当然这是后话，实际测试中那台FX5U后来用Modbus TCP通了）
• 一组温度传感器，通过Modbus RTU 485总线接入
• 一个本地MQTT Broker，模拟客户MES的数据接收端
• 一台Windows笔记本，用来跑协议仿真工具、做压力测试
• 一个可调电源，用来测试9~36V宽压是否包得住

三台网关都刷到最新固件，按厂商提供的文档配置网络、协议和Docker环境。我给自己定了一个原则：厂商文档没写清楚的地方，就按“能正常生产部署”的标准去尝试，不能因为某个产品文档烂就降低测试标准。这个原则执行下来，很快就能看出哪家的工程化水平更高。

4.2 核心测试项目和结果

测试项目不是随便挑的，每一项都对应选型时的核心需求。我最后整理了一份测试对比如下：

这个测试结果说明几个问题：G3在Docker运行稳定性上确实差一些，可能是内存分配策略过于保守；G1在各项数据上比较平稳，没有明显短板但也没有特别亮眼的地方；G4在CPU占用、断电重连速度上有优势，但功耗略高，需要确认现场供电是否扛得住。

4.3 最终对比：2个怎么选

测试之后，G3被我淘汰了，理由不是某个指标不好，而是它表现出来的是一个“系统性问题”：Docker OOM不是偶发现象，调过容器内存限制后仍然出现，说明它的软件栈对容器生态的适配还不够成熟。以我们未来要长期跑自定义容器的需求，不能把风险压在一个需要不断调优的平台上。

最终进入“二选一”的是G1和G4。两者其实代表了两种选型思路：

G1的优势是稳定、皮实、文档完整，售后也让人放心，适合部署规模大、现场技术人员少、希望“出了问题有人管”的项目。缺点是操作系统偏保守，想装一些比较新的软件包要自己折腾依赖，容器内要用的部分第三方库版本旧，有一次我为了装一个Python包，前后折腾了一个小时。

G4的优势是性能强、软件栈新、容器生态顺畅，很多在G1上装不动的软件在G4上一条命令搞定。缺点是硬件功耗稍高，云平台是厂家的私有方案，数据默认先走他们的平台，我们用私有化MES要额外配置推送规则，而且产品上市时间短，案例不够多，长期可靠性存在不确定性。

最后我的决定是：G1作为项目主力，G4作为技术验证平台。原因很简单，这个项目里稳定性优先级最高，我不能拿整个产线的数据去赌一台刚上市不久的设备。但G4管用，后续如果客户有新项目需要跑复杂视觉模型或更重的容器应用，G4可以作为备选方案加测。

5. 选型过程中的常见坑和排查思路

5.1 “真Docker”和“假Docker”的判断方法

Docker是边缘网关最热门的卖点之一，但“支持Docker”和“能稳定跑Docker容器”是两码事。第一个坑是阉割版Docker：有些网关为了省资源，只实现了部分Docker API，常用docker run命令都缺参数。第二个坑是系统库缺失，很多容器内依赖glibc、libssl等系统库，如果在裁剪版系统上跑，分分钟报错。

判断方法其实不复杂：拿到设备后，先执行docker version和docker info，看服务端完整程度；再从Docker Hub拉一个带完整运行时的镜像，比如alpine:latest，跑一个hello world；然后再跑一个Node-RED、一个Python脚本，连续运行24小时以上观察内存和日志。这一步能过滤掉绝大多数“假Docker”。

注意：不要只看宣传页有没有Docker字样，一定要问清楚是“内置Docker Engine”还是“容器化平台”，后者很多是厂商私有格式，无法直接跑标准镜像。

5.2 串口和网口的实际能力

标称参数和实际能力之间的差距，在工业网关里最明显的就是串口和网口。有的网关标称4路RS485，但所有串口共用同一组中断，轮询频率一高就出现响应超时；有的网关网口是交换芯片扩展出来的，不是独立MAC，多端口同时跑流量时吞吐腰斩。

测试时我建议至少做这样几件事：

• 把所有串口接到不同设备上，以1秒间隔同时轮询，看是否存在随机超时；
• 用两个网口分别跑数据采集和上行上传，观察CPU占用和时延；
• 在弱网环境下测试4G模块的掉线重连时机，看是否影响采集任务；
• 用示波器检查串口波形，确认抗干扰能力是否达标，不过这个很多小团队没有条件，可以通过在现场机柜里做较长距离布线模拟。

5.3 断网缓存、远程升级、看门狗的细节

断网缓存是最容易埋雷的功能。有些网关断网后数据写入本地文件，恢复联网后一律全量补传，没有按时间戳去重，导致云端出现重复数据；有些网关缓存满了之后就丢最老的数据，而且没有任何告警。最稳妥的做法是选支持“本地数据库缓存+按时间戳回补”的产品，并且在测试阶段故意断网一小时再恢复，查看数据是否有遗漏和重复。

远程升级也值得重点验证。工业现场网关往往部署在机柜里，不可能像开发板一样随便重启，所以OTA必须具备“失败自动回滚”能力。我遇到过一款设备跨大版本升级后起不来系统，只能返厂刷机，这种产品在正式项目里绝对不能碰。

看门狗同样不能忽略。很多网关的看门狗只监控系统进程，如果容器内应用卡死，系统层面看起来还是正常的。好一点的网关会提供应用级看门狗接口，允许用户在脚本里自定义心跳检查。测试时我故意kill掉容器主进程，看设备能不能自动拉起，这一步能真实反映它的可用性。

5.4 现场实测阶段的小技巧

最后分享几个实测阶段很实用的小技巧。一是测试时一定要用正式项目的采集点位数量级去跑，比如只用10个点位测过一个小时，和用1000个点位连续跑72小时，结论可能完全相反。二是要给每个候选网关编一个测试台账，记录固件版本、测试时间、测试项、通过与否、异常截图，这样后期写选型报告时不只是拍脑袋说“某产品不行”，而是有据可查。三是同时被测的网关最好接到同一个网络环境里，排除现场网络波动对结论的干扰。

我也吃过亏：第一轮测试时G4先接的是有线网络，G1因为位置原因走了4G，结果两者在上传时延上差异巨大，差点误判。后来把网络统一了才恢复正常。

6. 一些选型之外的思考

设备选型定下来只是一个开始。真正的项目稳定运行，还要靠调试时的配置细节、现场运维规范、以及和厂商的长期配合。比如我们最终选择G1为主力之后，我做的第一件事是把所有现场设备的点位表整理出来，按协议、寄存器地址、数据类型建了一个标准模板，后续新增设备只需要往模板里填内容，配置网关的时间从原来的大半天缩短到一小时左右。

另外，我建议项目早期就找厂商要一个“技术支持对接人”的企业微信或电话，不一定是销售，最好是售前工程师。选型测试阶段多跟他们沟通，遇到文档没写清的问题直接问，比自己在论坛上折腾省太多时间。我测试G3时有一个串口参数问题，厂商官网查不到，问技术工程师也语焉不详，这种厂商即使产品便宜，合作起来也很累。

最后一点，工业网关选型不是一锤子买卖。同一款产品，固件更新之后可能补了一堆功能，也可能引入了新问题。所以选型完之后最好把候选产品的固件更新历史保留下来，定期关注更新日志，尤其是涉及安全补丁和关键协议修复的版本，有条件就找厂商要测试固件先验证再上线。