设备远程诊断与维护
设备厂商如何远程诊断已交付到客户现场的机器:连接模式怎么选、工业网络的限制、以及为什么现场那个人不是工程师这件事决定了整套设计。
更新于
你卖出去一台设备。它现在在客户的车间里,运行着你的软件, 而客户打电话说它不工作了。
派人过去要一两天,机器停一两天。这是远程诊断最直接的价值。 但把它做扎实,要面对的约束和「给办公室电脑做远程支持」完全不同。
三个不一样的地方
第一,被控的机器是你的产品,不是客户的资产。 你比客户更清楚它该有什么状态、日志在哪、哪个参数不对。 所以你要的不是「看到屏幕」,而是「拿到诊断所需的一切」。
第二,现场那个人不是工程师。 办公室里你可以说「点一下右下角那个图标」, 车间里对方可能是操作工、也可能是客户的行政。指望他完成一串操作步骤是不现实的, 这直接决定了连接模式的选择。
第三,网络往往是隔离的。 产线网段常常不通外网,或者只开了有限出口。 这不是可以绕过的技术细节,是选型时第一个要确认的事。
连接模式:这个场景默认是无人值守
| 客户支持 | 设备诊断 | |
|---|---|---|
| 默认模式 | 请求式(对方点击接受) | 无人值守 |
| 为什么 | 客户在电脑前,需要看见并同意 | 机器跟前可能根本没人 |
这是和面向客户的远程技术支持最本质的分歧。 客户支持的默认是请求式——让客户看见每一次接入; 而一台夜里报警的设备,等不到有人来点「接受」。
但无人值守把风险全部转移到了凭据和审计上。 没有人在现场把关, 那么「谁在什么时候连了哪台设备、做了什么」就必须完全由系统记录。 这不是可选项,是无人值守成立的前提。详见安全与审计。
网络:先确认,再谈方案
产线网络通常有三种形态,对应三种做法:
- 能出外网——最简单,装上客户端即可,NAT 穿透会处理内网地址的问题
- 只开有限出口——需要客户 IT 放行特定域名与端口,这是一次沟通成本, 但只需做一次
- 完全隔离——远程诊断在这里不成立,不要承诺。 这种情况下能做的是让设备把日志导出到可携带介质,或者走客户自己的跳板机
第三种要早说。 销售阶段答应了做不到,比一开始说清楚代价大得多。
把被控能力做进设备本身
给每台出厂设备额外装一个远程控制软件,是一道多余的门槛—— 装机率会掉,而且出问题时客户往往正处在最不耐烦的时刻。
客户端 SDK 可以把被控能力嵌进你自己的软件里,设备装了你的产品就具备被控能力, 不需要客户再装第二个东西。SDK 跨平台,Windows、Linux、macOS 都能集成—— 这一点对工业场景尤其重要,因为不少 HMI 和工控机跑的不是标准 Windows 桌面。
配套的还有 Web SDK(让你的售后系统直接发起连接)和 REST API(把会话记录写回工单)。 三个集成面的区别见把远程控制集成进自有系统。
⚠️ 需要说明的是:WorksLink 自己的独立客户端目前只有 Windows 与 macOS 版本。 如果你的设备跑 Linux,走 SDK 集成是可行的路径,装成品客户端不是。
一个务实的落地顺序
- 先确认网络。三种形态里是哪一种,决定了后面所有事
- 从最常出问题的那类设备开始,不要一次铺全部机型
- 无人值守和审计一起上,不要先开无人值守、审计留到以后—— 顺序反了的话,中间那段时间的操作没有记录,事后追不回来
- 量上来之后再做集成。十几台设备手工装客户端是可以接受的; 到了几百台、或者设备要出厂即带远程能力时,SDK 才变得划算
计费上值得知道的一点
WorksLink 按并发通道计费,不按设备数。
这条在设备场景下影响很大:你可能接入了几千台设备, 但同一时刻真正在诊断的通常只有几路。按通道付费意味着你为实际并发付费, 而不是为装机量付费——这和按端点收费的产品是完全不同的成本曲线。