机器人技术系列第19篇：产线多设备时间同步与故障日志对齐

EVST以物思

174人浏览 · 2026-08-05 14:13:31

EVST以物思 · 2026-08-05 14:13:31 发布

一条机器人产线里，PLC 显示 10:15:03，机器人报警记录是 10:15:01，视觉电脑写 10:15:05，MES 又在 10:15:07 收到停线事件。四个时间都“看起来正常”，但工程师无法判断到底是视觉先拒绝、机器人先停止，还是 PLC 先撤销允许。多设备时间同步要解决的不是让屏幕右下角都显示北京时间，而是让一次事件在不同设备里的发生时间、采集时间、传输时间和显示时间可以被区分、比较和追溯。

先给结论：只为班组查看报警先后，通常不需要全线 PTP；先统一 UTC、打戳位置和 NTP 来源，常常已经够用。需要毫秒以下对齐的场景，应先证明业务确实依赖这种精度，再检查终端、交换机和测量方法是否共同支持。机器人运动控制总线的同步、视觉硬触发与普通日志对时不是一回事，不能因为设备写着“支持 PTP”，就把三种问题混成一个项目。

标准题录显示，GB/T 25931-2010《网络测量和控制系统的精确时钟同步协议》仍为现行标准，2025 年复审结论为继续有效；本稿查询日期为2026年8月4日。它为精确时钟同步提供协议框架，却不会替产线决定日志应该在哪里打时间戳、断网后能漂多久、恢复时能不能直接跳时。真正落地需要从事件用途倒推时间设计。

一、先把五个“时间”分清楚

时间同步项目最先开的会，经常直接讨论 NTP 服务器地址。我们更愿意先把时间字段定义清楚，因为字段语义错了，再高的同步精度也救不回事件顺序。

名称	含义	常见错误
设备时钟	设备内部当前时间	只看界面显示，没确认内部存的是 UTC 还是本地时间
发生时间	物理或逻辑事件真正发生的时刻	把上位机收到消息的时间当成发生时间
采集时间	控制器读到状态变化并生成记录的时刻	忽略扫描周期、相机处理和设备缓存
到达时间	消息到达上位系统或 MES 的时刻	网络拥堵会改变它，不能反推真实先后
显示时间	经时区和格式转换后给人看的时间	夏令时、时区或格式设置造成重复、跳变

同一个事件可以同时保留多个时间。例如拧紧机完成一次拧紧：控制器完成判定的时间是事件时间，PLC 收到结果位的时间是采集时间，MES 接口收到结果包的时间是到达时间。三个字段都能用，但用途不同。质量追溯应优先保留源设备的事件时间，同时记录接收时间用于判断通信延迟；若只留一个“上传时间”，事后很难区分设备慢、网络慢还是平台入库慢。

还要定义时间分辨率和可比性。某个设备只记录到整秒，另一个虽然显示毫秒却每 500 ms 批量刷新，两者不能因为格式更长就被视为毫秒级证据。需求文档应写“允许比较到什么粒度、用什么方法验证”，而不是只写“所有设备时间一致”。

二、从业务问题反推精度，而不是从协议反推项目

常见需求可以分为四层：

业务用途	需要回答的问题	设计关注点	典型策略
班组报警回看	哪个设备先报错，先后差几秒	时区一致、秒级顺序可靠	统一 NTP，源设备打戳
跨工位故障链	多个控制器事件能否按几十毫秒排序	扫描周期、缓存和网络延迟	评估 NTP 实测偏差与打戳位置
质量结果绑定	哪个结果属于哪个工件和循环	工件 ID 比绝对时间更重要	时间戳 + 循环号/产品 ID 双键
精密采样关联	多源测量是否在同一时间基准下	终端硬件、网络时钟能力、测量不确定度	PTP 或设备专用同步机制

第一层上 PTP 往往是过度设计。日志本身只到整秒，或设备内部先缓存数秒再上传，即使网络时钟达到微秒级，最终记录仍不具备同样的事件精度。第四层又不能只配一台 PTP 服务器：如果终端不支持硬件时间戳、交换机不透明、边界时钟配置不当，系统标称支持与实际偏差会相差很大。

第三层尤其容易走偏。质量追溯如果只靠时间窗口把结果和工件匹配，产线暂停、返工、并行工位或缓存输送都会造成错绑。更稳妥的做法是让工件 ID、托盘 ID、循环号或序列号成为主关联键，时间戳用于排序、审计和异常分析。时间同步是追溯的基础设施，不应承担本该由业务标识承担的唯一性。

三、建立一个时间源层级，而不是每台设备各自找公网

产线时钟架构至少要明确四层：权威时间源、厂区时间服务、产线时间服务和终端设备。每层都要写主用、备用、失联行为和监测方式。

我们不建议机器人、PLC、视觉电脑各自访问不同公网 NTP。公网可达性、网络隔离、DNS、代理和安全策略都会改变，外部源之间也可能存在差异。更可控的做法是由厂区统一时间服务对外或对上级时间源同步，OT 区终端只访问规划内的服务器。对不能跨区访问的独立产线，可设置本地时间服务，并明确它与厂区源的校准关系。

架构图之外，还要定义“谁有资格成为主时钟”。PTP 环境若允许非规划设备参与最佳主时钟选择，新增或误配设备可能抢占主时钟。NTP 环境如果终端同时配置多个来源，也要验证设备的选择算法、切换行为和告警能力。不是填四个服务器地址就自动获得冗余；有的设备会顺序轮询，有的只在主地址彻底不可达后切换，有的配置了多个地址却从不产生可见告警。

时间服务本身应纳入设备管理：版本、地址、时区、上游状态、偏差、最后同步时间、主备切换次数都需要被监视。否则时间源失联几天后，现场只会在一次大故障复盘时才发现所有日志已经逐渐漂开。

四、统一 UTC 存储，显示层再转本地时间

跨时区设备、出口项目和 Windows 工控机最常见的问题，不是时钟偏几秒，而是把 UTC 与本地时间混存。同一数据库里有的设备写 UTC，有的直接写北京时间；界面又统一加八小时，最终出现一部分记录正确、一部分记录超前。

推荐的原则是：系统内部记录 UTC，并明确时间戳是否带时区信息；人机界面、报表和导出文件在显示层转换为本地时间。若某台旧设备只能保存本地时间，就在接口文档里标出其时区与转换责任，不要假装全线已经统一。

还要处理以下边界：

设备重启后 RTC 无效，是否会回到一个默认日期；
控制器时间结构是否包含时区或只是一组年月日时分秒；
上位机是否受 Windows 域策略自动校时，和 OT 时间源产生冲突；
数据库字段是否保存时区偏移；
导出 CSV 后，电子表格软件会不会再次按本机时区解释；
跨时区远程运维时，工程师看到的是设备时间还是自己电脑时间。

中国境内没有夏令时切换，但出口设备或总部集中数据平台可能会遇到。只要系统跨时区，就应优先使用 UTC 时间线；它不会因时区切换或夏令时回拨而重复，而本地时间可能出现两个相同的 01:30，单凭显示字符串无法排序。闰秒边界仍要单独约定：终端采用重复秒还是平滑处理可以不同，但同一产线必须统一处理方式并留存状态。

五、时间戳应尽量靠近事件源生成

假设视觉系统在 12:00:00.120 判定 NG，PLC 在 12:00:00.150 读到结果，MES 在 12:00:00.480 收到接口消息。如果只由 MES 在入库时打戳，记录会把 360 ms 的传输与排队时间误认为事件发生时间。

更可靠的优先级是：源设备能提供可信事件时间，就原样保留；源设备无法提供时，由最靠近事件的控制层打戳；上层接收时间作为附加字段。每条数据还可以带上数据质量标记，例如“时间已同步”“本地守时”“时钟状态未知”，让后续分析知道这段记录能比较到什么程度。

有些设备虽然提供时间戳，但时间戳在上传前才生成，而不是事件发生时生成。验证时不能只看字段名，要制造一个可观察事件，同时记录物理触发、设备日志和上位接收，判断打戳位置。厂商手册对字段语义的说明应进入接口规格，不能靠集成人员猜。

对于 PLC 周期采集，还要考虑扫描方式。多个输入在同一扫描周期被读取，日志可能得到相同时间；异步任务和中断任务又可能在不同优先级下打戳。若业务需要区分同一周期内的先后，普通周期程序未必提供足够证据，需要更靠近设备的事件机制，而不是把显示格式从毫秒改成微秒。

六、断网时先守时，再决定怎样回到主时间

时间源不可达时，终端不会立刻停止计时，而是依赖本地晶振继续运行。漂移量可以用一个简单模型估算：

time_error ≈ oscillator_error × outage_duration

假设某设备在当前温度和状态下实测频率误差为 20 ppm，失去时间源 4 小时，线性估算偏差约为：

20 × 10^-6 × 4 × 3600 = 0.288 s

这个数只演示计算路径，不是对任何控制器 RTC 的承诺。真实漂移受温度、老化、电源状态和设备算法影响，必须用实际设备测量。它告诉我们：断网可接受时长应由允许偏差倒推，而不是写“支持断网运行”。

恢复同步时有两种基本行为：一步跳到新时间，或通过调整频率逐渐靠拢。跳时收敛快，却可能导致时间倒退、重复时间戳、定时器异常和报表顺序混乱；缓调更连续，但偏差会在一段时间内持续存在。不同终端支持能力不同，项目必须验证，不能只在服务器端规定。

墙钟时间戳只用于记录事件落在日历时间线上的位置。持续时长、超时、节拍和循环间隔应使用单调递增计数器计算，不能直接拿可能被校时跳变的墙钟时间戳相减；两类时间应分开存储，并通过同一事件或锚点关联。

对生产日志，可以划出“不可信时间段”：时间源失联时记录失联开始、设备守时状态和估算偏差；恢复时记录恢复方式和完成时间。这样复盘人员知道哪些记录只能比较到秒，哪些仍可进行更细排序。直接把旧日志批量改成新时间，会破坏原始证据，不建议作为默认补救。

断电与断网还要分开。断网时设备通常继续守时；断电后 RTC 是否有电池、超级电容或非易失存储，行为完全不同。验收必须分别测试短时断网、时间服务器重启、终端重启、整线断电和主备切换。

七、一个故障链算例：日志怎样把因果顺序写反

设真实事件如下：

真实相对时刻	事件	各设备显示时刻
0 ms	视觉判定定位失败	+180 ms
35 ms	PLC 撤销机器人运行许可	−5 ms
62 ms	机器人停止并生成报警	+82 ms
210 ms	上位系统收到停线事件	+280 ms

现场四台设备的时钟偏差分别为：视觉快 180 ms，PLC 慢 40 ms，机器人快 20 ms，上位机快 70 ms。直接按各自显示时间排序，顺序必然变成 PLC→机器人→视觉→上位机：PLC 撤销许可和机器人报警都被排到了视觉判定之前，整条因果链被倒置。

处理这类问题，不能事后凭感觉给每条记录“加减几毫秒”。应先取得同一时间点的设备偏差测量或同步状态，再区分事件时间与到达时间。若历史记录没有保存偏差和时钟状态，只能降低结论置信度，不能把修正后的顺序写成确定事实。

这个例子也说明精度预算要覆盖整条链：时钟偏差、设备采集延迟、程序扫描、消息缓存和网络传输都会贡献误差。只测 NTP 往返延迟而忽略设备内部缓存，得到的是网络状态，不是事件顺序的总不确定度。

八、验收不能只看“同步成功”图标

时间同步验收应同时验证配置、偏差和业务结果。

1. 配置核对

每台设备的时间源、协议、同步周期和时区；
主备地址与切换条件；
时间戳字段的单位、分辨率、时区和打戳位置；
设备重启、网络中断和时间源失联时的行为；
监控指标与告警接收人。

2. 偏差测量

选定统一参考事件，在多个设备上同时生成可观察记录，重复测量而不是只测一次。偏差报告至少给出最大值、最小值、分布、测试时长和负载条件。若业务要求几十毫秒排序，测量方法本身也要有更好的分辨能力，拿手机拍两个屏幕不能作为严谨验收。

3. 业务验证

制造一条已知先后的故障链，例如先断开视觉就绪、再由 PLC 停止机器人，检查各日志能否还原既定顺序。再制造消息延迟，确认系统保留的是源事件时间而非单纯到达时间。最后测试跨日、重启和导出，避免界面正确、CSV 错八小时。

4. 降级测试

断开主时间源，观察终端是否切到备用、是否告警、偏差怎样增长；恢复后观察是否跳时、是否出现倒序记录；重启失去 RTC 的终端，确认它在重新同步前会不会生成看似正常但日期错误的数据。

可以用简化脚本持续采集各设备时间差。伪代码如下：

repeat every sample_interval:
    reference = read_reference_clock()
    for device in devices:
        device_time, sync_state = read_device_clock(device)
        offset = device_time - reference
        append(device, reference, offset, sync_state)
    alert_if_offset_or_state_exceeds_project_rule()

脚本的难点不在减法，而在 read_device_clock 的语义。有的接口返回设备系统时间，有的返回上次同步状态，有的经过上位机缓存。采集方式必须在验收文件里说明，不能用一个字段名掩盖测量路径。

九、监控指标至少覆盖“偏差、状态、来源”

上线后只监控时间服务器是否在线远远不够。建议按设备能力至少保留：当前偏差或估算偏差、同步状态、当前时间源、最后成功同步时间、主备切换记录、时钟跳变记录、RTC 异常和终端重启时间。

不能直接读取偏差的旧设备，可以定期用业务事件或上位轮询做趋势测量。重点不是追求一个看起来精确的小数，而是发现偏差是否持续增长、设备是否长期未同步、某次重启后是否突然跳变。

告警也要分层。单次采集超限可能来自网络抖动或测量路径，应先复测；持续超限、时间源改变、同步状态失效则需要进入维护流程。项目阈值应来自业务允许的事件排序误差和实测能力，而不是复制互联网的“毫秒级标准值”。

十、网络延迟不能直接当成时钟偏差

现场排查时，经常有人用 ping 延迟判断对时是否准确。ping 能反映某类往返通信的可达性和时延，却不能直接证明两台设备的时钟差。对时协议会估计网络传播延迟，路径又可能上下行不对称；设备内部处理、操作系统调度和软件时间戳位置都会改变测量结果。

如果 A 到 B 的请求去程花 2 ms，回程花 18 ms，简单把往返 20 ms 除以二，会假设双向各 10 ms，从而引入 8 ms 的误差。普通网络上这种不对称可能来自队列、路由、无线链路或不同优先级。对于只需要秒级日志的项目，8 ms 也许完全可接受；对于需要比较十几毫秒先后的项目，它已经足以改变结论。

因此，验收报告应同时说明：偏差测量采用软件还是硬件时间戳，报文经过哪些交换机，测试时网络负载如何，是否观察到路径不对称。只给一张“ping 小于 1 ms”的截图，不能证明终端时钟已经对齐。

PTP 的价值之一，是在支持的网络设备和终端上更精确地处理报文时间，但它仍需要完整路径共同配合。普通交换机转发造成的驻留时间、终端软件栈调度、虚拟机时间源和网卡能力都可能成为边界。透明时钟、边界时钟和硬件时间戳是具体能力，不应被营销资料里一个“1588”勾选框替代。

同样，NTP 也不等于低质量。稳定、有监测、路径可控的 NTP，配合源端打戳和正确的业务标识，往往足以支撑生产日志。选择协议时应比较实际误差预算、现有设备能力和维护复杂度，而不是按“PTP 比 NTP 高级”排序。

十一、旧设备纳管有三种诚实做法

旧机器人、仪表或专机可能不支持 NTP，也不允许外部写系统时间。面对这种设备，强行宣布“全线统一对时”只会制造文档假象。可以按能力采用三种方式，并在数据上保留差异。

1. 周期写时钟

若设备允许 PLC 或上位机写入时间，可以在受控条件下周期校准。要验证写入时是否导致任务阻塞、日志跳变、定时器异常，以及设备重启后是否保留。写时动作本身要留记录，方便区分生产事件与人工校时造成的时间跳变。

2. 上游代理打戳

设备只提供状态位或结果报文时，由 PLC、边缘网关或采集程序在收到事件时打戳。此时字段名称必须写成“采集时间”，不能冒充设备内部发生时间。可以测量并记录采集路径的典型延迟和波动，明确结论能比较到什么粒度。

3. 相对序列 + 锚点

部分设备有单调递增的循环计数器、报文序号或设备运行时间，却没有可信日历时间。可以保留相对序列，并在与 PLC 交互时建立时间锚点。复盘时先按设备内部序列恢复顺序，再用锚点映射到全线时间。这样的数据不如源端绝对时间方便，但比伪造一个精确时间戳可靠。

无论采用哪种降级方式，都要给数据打质量标签。新旧设备混在同一报表时，界面可以统一显示格式，却不能隐藏证据等级差异。否则工程师会把代理打戳的毫秒字符串与硬件事件时间当成同一精度。

十二、日志模型最好保留原值，而不是只留转换结果

为支持跨设备复盘，一条事件记录可以包含以下字段：

其中 payload（事件负载）用于保存与该事件相关的业务数据，不承担时间语义。

event_id
source_device
source_sequence
source_timestamp_raw
source_timezone_or_scale
normalized_utc
collector_received_utc
sync_state
clock_source
estimated_uncertainty
product_or_cycle_id
event_code
payload

source_timestamp_raw 对应源设备记录的原始事件时间，normalized_utc 是按接口规则转换后的统一事件时间，collector_received_utc 对应采集或到达时间，用于显示传输和排队结果。转换规则如果后来发现有误，可以从原值重新计算；若数据库只保存转换后的时间，修正会失去依据。

source_sequence 对识别丢报和乱序很有用。两条消息时间相同，但序号连续，说明可能同一周期生成；序号跳号则提示中间记录丢失。estimated_uncertainty 不一定是一个精确小数，也可以是项目定义的等级，如“硬件同步”“NTP 正常”“本地守时”“代理打戳”“状态未知”。关键是让使用者知道能否据此下因果结论。

数据模型还应规定时间跳变的处理。若设备时钟从 10:00:05 回拨到 10:00:02，数据库主键不能只用时间戳；排序也要结合序号和接收时间。报表可以按统一 UTC 展示，但审计记录应保留回拨事件，避免后续清洗把异常静默抹掉。

归档时不要只导出格式化后的 PDF。可机读的原始记录、字段说明、转换版本和时钟状态，才支持后续重新分析。时间同步方案一旦升级，也要保留变更前后的边界，不能把历史数据按新规则解释。