远程控制电脑软件

设备远程诊断与维护

设备厂商如何远程诊断已交付到客户现场的机器:连接模式怎么选、工业网络的限制、以及为什么现场那个人不是工程师这件事决定了整套设计。

更新于

你卖出去一台设备。它现在在客户的车间里,运行着你的软件, 而客户打电话说它不工作了。

派人过去要一两天,机器停一两天。这是远程诊断最直接的价值。 但把它做扎实,要面对的约束和「给办公室电脑做远程支持」完全不同。

三个不一样的地方

第一,被控的机器是你的产品,不是客户的资产。 你比客户更清楚它该有什么状态、日志在哪、哪个参数不对。 所以你要的不是「看到屏幕」,而是「拿到诊断所需的一切」。

第二,现场那个人不是工程师。 办公室里你可以说「点一下右下角那个图标」, 车间里对方可能是操作工、也可能是客户的行政。指望他完成一串操作步骤是不现实的, 这直接决定了连接模式的选择。

第三,网络往往是隔离的。 产线网段常常不通外网,或者只开了有限出口。 这不是可以绕过的技术细节,是选型时第一个要确认的事。

连接模式:这个场景默认是无人值守

客户支持设备诊断
默认模式请求式(对方点击接受)无人值守
为什么客户在电脑前,需要看见并同意机器跟前可能根本没人

这是和面向客户的远程技术支持最本质的分歧。 客户支持的默认是请求式——让客户看见每一次接入; 而一台夜里报警的设备,等不到有人来点「接受」。

但无人值守把风险全部转移到了凭据和审计上。 没有人在现场把关, 那么「谁在什么时候连了哪台设备、做了什么」就必须完全由系统记录。 这不是可选项,是无人值守成立的前提。详见安全与审计

网络:先确认,再谈方案

产线网络通常有三种形态,对应三种做法:

  1. 能出外网——最简单,装上客户端即可,NAT 穿透会处理内网地址的问题
  2. 只开有限出口——需要客户 IT 放行特定域名与端口,这是一次沟通成本, 但只需做一次
  3. 完全隔离——远程诊断在这里不成立,不要承诺。 这种情况下能做的是让设备把日志导出到可携带介质,或者走客户自己的跳板机

第三种要早说。 销售阶段答应了做不到,比一开始说清楚代价大得多。

把被控能力做进设备本身

给每台出厂设备额外装一个远程控制软件,是一道多余的门槛—— 装机率会掉,而且出问题时客户往往正处在最不耐烦的时刻。

客户端 SDK 可以把被控能力嵌进你自己的软件里,设备装了你的产品就具备被控能力, 不需要客户再装第二个东西。SDK 跨平台,Windows、Linux、macOS 都能集成—— 这一点对工业场景尤其重要,因为不少 HMI 和工控机跑的不是标准 Windows 桌面。

配套的还有 Web SDK(让你的售后系统直接发起连接)和 REST API(把会话记录写回工单)。 三个集成面的区别见把远程控制集成进自有系统

⚠️ 需要说明的是:WorksLink 自己的独立客户端目前只有 Windows 与 macOS 版本。 如果你的设备跑 Linux,走 SDK 集成是可行的路径,装成品客户端不是。

一个务实的落地顺序

  1. 先确认网络。三种形态里是哪一种,决定了后面所有事
  2. 从最常出问题的那类设备开始,不要一次铺全部机型
  3. 无人值守和审计一起上,不要先开无人值守、审计留到以后—— 顺序反了的话,中间那段时间的操作没有记录,事后追不回来
  4. 量上来之后再做集成。十几台设备手工装客户端是可以接受的; 到了几百台、或者设备要出厂即带远程能力时,SDK 才变得划算

计费上值得知道的一点

WorksLink 按并发通道计费,不按设备数

这条在设备场景下影响很大:你可能接入了几千台设备, 但同一时刻真正在诊断的通常只有几路。按通道付费意味着你为实际并发付费, 而不是为装机量付费——这和按端点收费的产品是完全不同的成本曲线。