4. 远程诊断接口需求分析
远程诊断接口不是“把机床数据全部上传”这么简单。接口需求必须从三个源头反向推导：机床实际会以什么方式失效（故障模式）、维修人员按什么顺序处理故障（维护流程）、不同角色在什么时刻需要什么信息（用户角色）。只有把这三条线索对齐，才能确定采集哪些数据、告警如何分级、控制权限开放到什么程度、日志保留多久。本节以一台典型立式加工中心（VMC，配FANUC 0i-MF或类似数控系统）为对象，说明如何把故障模式、流程和角色转化为可实现的接口需求。
一、从故障模式提取数据采集需求
故障模式决定了“必须采什么”。数控机床的故障大致可分为机械类、电气类、伺服与主轴类、数控系统与程序类、辅助系统类。每一类故障都有可观测的前兆信号，接口设计就是把这些信号变成可采集的测点。
以主轴轴承磨损为例，其前兆是主轴负载电流缓慢上升、振动加速度增大、主轴转速跟随误差变大。对应采集需求为：主轴电机电流（采样周期100 ms）、主轴振动加速度（采样周期10 ms，带宽≥5 kHz）、主轴转速与指令转速偏差（采样周期20 ms）。再如滚珠丝杠预紧力下降，表现为反向间隙增大、定位误差超差，需要采集伺服电机电流、位置偏差、反向间隙补偿量。而刀库换刀故障，则要采集刀库电机电流、换刀位置传感器状态、换刀计时（从T指令发出到换刀完成的时间）。
把这些整理成接口需求时，不能只写“采集主轴数据”，而要给出测点、采样率、精度、触发条件。例如：
测点: spindle_load_current
类型: 模拟量
量程: 0~30 A
采样周期: 100 ms
上传策略: 周期上传 + 阈值触发(>22 A 连续3 s)
关联故障: 主轴轴承磨损、切削过载
故障模式还决定了“哪些数据需要高频、哪些可以低频”。振动、电流等用于故障预测的信号需要高频采集和边缘缓存；而报警代码、运行状态、程序号等可以低频上传。若不分层，全部按10 ms上传，网络和存储成本会迅速失控。
二、从维护流程提取告警与控制需求
维护流程决定了“告警怎么发、控制怎么给”。典型远程维护流程为：异常发现→告警推送→远程确认→初步诊断→远程操作或现场派工→恢复验证→记录归档。接口需求必须覆盖每一步。
异常发现阶段，接口要支持阈值告警和趋势告警。阈值告警如“主轴负载电流>22 A持续3 s”，趋势告警如“X轴反向间隙在7天内从0.008 mm增大到0.020 mm”。告警信息应包含设备编号、报警代码、发生时间、当前值、阈值、建议动作。例如：
{
"device_id": "VMC-01",
"alarm_code": "SP_LOAD_HIGH",
"level": "warning",
"value": 24.6,
"threshold": 22.0,
"timestamp": "2025-03-18T10:23:41+08:00",
"suggest": "检查主轴轴承与切削参数"
}
远程确认和初步诊断阶段，接口要允许维护人员读取PLC梯形图状态、伺服参数、报警历史、程序段号。此时需要“只读控制”接口，例如读取PMC地址、读取参数No.、读取当前程序行。远程操作阶段则涉及“写控制”，如远程复位报警、远程修改刀补、远程启动暖机程序。这类接口必须分级授权：复位报警属于低风险，修改刀补属于中风险，修改伺服参数属于高风险。高风险操作应要求二次确认并记录操作者、时间、原值和新值。
恢复验证阶段，接口要能回读关键状态，确认报警消除、负载恢复正常、定位精度在允许范围内。记录归档阶段，则要求日志接口保存告警、操作、参数变更和恢复结果，保留周期建议不少于180天，以满足追溯和复盘需要。
三、从用户角色提取接口权限与视图需求
不同角色对接口的需求差异很大。操作工关心“现在能不能继续加工”，需要看到当前报警、主轴负载、程序状态；班组长关心“这台设备今天是否影响产出”，需要看到停机时长、报警次数、OEE相关数据；维修工程师关心“故障根因是什么”，需要看到历史曲线、PLC状态、参数、日志；设备主管关心“多台设备健康趋势”，需要看到横向对比和劣化排名；系统集成商关心“接口是否稳定、数据格式是否统一”，需要看到接口状态、心跳、数据质量。
因此，接口不能只提供一套“全量数据”，而应按角色提供不同粒度的视图。例如，操作工视图只开放只读状态和报警确认；维修工程师视图开放只读诊断数据和受限写控制；设备主管视图开放统计聚合数据。权限模型可采用“角色—资源—操作”三元组：
role: maintenance_engineer
resource: /device/VMC-01/parameter
action: read, write_limited
constraint: write_limited 仅允许刀补与零点偏移，禁止修改伺服增益
角色还决定了告警的推送方式和时机。操作工需要现场声光报警和HMI弹窗；维修工程师需要手机推送和邮件；设备主管需要日报和周报。接口应支持多通道分发，并允许按角色订阅不同级别告警。
四、接口需求汇总与优先级
把上述三条线索合并，可得到四类接口需求：数据采集接口、告警接口、控制接口、日志接口。数据采集接口要求测点明确、采样率分层、支持边缘缓存；告警接口要求分级、可订阅、含建议动作；控制接口要求分级授权、操作留痕、高风险二次确认；日志接口要求完整、可检索、保留期明确。
在工程实施中，建议按“先只读、后写控制；先高频关键测点、后全量测点；先本地告警、后远程推送”的顺序推进。第一版接口可先实现主轴负载、伺服位置偏差、报警代码、运行状态四类数据采集，以及报警推送和日志记录；第二版再开放远程复位和刀补修改；第三版再引入振动等高频预测性维护接口。这样既能快速形成远程诊断能力，又能控制风险。
五、需求分析中的常见偏差
实际项目中最容易出现的偏差有三种。第一种是“采集越多越好”，把大量与故障无关的工艺参数也纳入高频上传，导致网络拥塞和存储浪费。纠正方法是每个测点必须关联至少一个故障模式，否则降为低频或暂不采集。第二种是“告警只报代码”，例如只推送“ALM 401”，维修人员无法判断是伺服过载还是编码器断线。纠正方法是告警必须携带当前值、阈值、发生时间和建议动作。第三种是“控制权限一刀切”，要么全部只读、要么全部可写。纠正方法是按风险分级，低风险操作可直接执行，中风险需二次确认，高风险需审批并记录。
此外，接口需求还要考虑断网、重启、时钟同步等工程细节。例如，机床侧应缓存最近24小时的告警和关键测点，网络恢复后补传；所有设备与服务器应通过NTP同步时钟，否则日志时间错乱会导致故障复现困难。这些细节虽然不直接来自故障模式或角色，但会直接影响远程诊断的可用性，应在需求阶段一并明确。