第1章 冲突现象分类与定义
机器人功能冲突排查的第一步是精确描述“看到了什么”，而不是“认为哪里出了问题”。现象分类与定义是整个排查流程的入口，决定了后续数据采集的方向和原因分析的深度。本章将建立冲突现象的通用分类框架、结构化描述方法及严重等级标准，确保团队内部对同一现象的理解无歧义。
1.1 常见冲突类型
根据机器人系统架构层级与作用域，功能冲突可归纳为以下四种基本类型。多数现场复杂冲突是多种类型的叠加表现。
| 冲突类型 | 发生层级 | 典型现象示例 | 排查关键词 |
|---|---|---|---|
| 资源争抢 | 计算/总线/电源 | 关节电机电流波动、控制周期抖振、视觉丢帧 | CPU占有率、带宽占用、互斥锁 |
| 控制指令冲突 | 运动学/动力学 | 末端执行器高频震颤、两个控制器同时下发位姿 | 指令优先级、仲裁逻辑、死区 |
| 状态机互锁 | 任务调度/逻辑 | 机器人卡在“取货-放置”中间态、无法进入下一工序 | 状态跃迁条件、互斥任务、超时 |
| 协议干扰 | 通信/中间件 | ROS2 Topic数据乱序、EtherCAT报文丢失、CRC校验失败 | QoS配置、网络拓扑、时间同步 |
1.2 现象描述方法（5W2H结构化记录）
所有现场上报的冲突现象必须按照统一模板记录，禁止使用模糊词汇如“卡顿”、“异常”、“跑飞”。
- What（现象）：可量化的行为偏差，例如“末端位置误差 > 2mm 持续 500ms”。
- When（时间）：系统运行时长、任务阶段、是否周期性发生。
- Where（模块）：明确的硬件编号、进程名或服务接口。
- Who（任务/线程）：当前持有资源与请求资源的任务ID。
- How（复现路径）：手动操作步骤或自动化测试用例编号。
- How much（影响范围）：产线节拍损失百分比、故障恢复耗时。
结构化日志配置示例（JSON格式） – 所有冲突事件须按此结构输出：
{
"timestamp": "2025-03-20T14:32:10.123Z",
"event_type": "conflict_detected",
"conflict_category": "control_command_conflict",
"source_node": "motion_controller_01",
"target_node": "arm_joint_3",
"task_id": "pick_and_place_007",
"severity_label": "major",
"raw_message": "Joint 3 velocity command exceeds safety limit (set: 1.5 rad/s, max: 0.8 rad/s)"
}1.3 严重等级划分
等级划分直接影响响应时效与资源投入。所有冲突事件在记录时必须携带等级标签，作为排查队列排序的依据。
| 等级 | 定义 | 响应要求 | 举例 |
|---|---|---|---|
| 致命 | 设备受损、安全系统触发、人员受伤风险 | 立即停机，联动急停，上报安全团队 | 关节超速导致硬限位撞击 |
| 严重 | 核心功能瘫痪、任务链断裂、产线停产 | 30min内建立排查群组，启动应急恢复 | 主控与视觉服务通信中断 |
| 一般 | 功能降级但不中断生产，需人工干预 | 纳入当日缺陷单，24h内定位原因 | 抓取成功率从99%降至92% |
| 建议 | 性能波动、潜在冲突隐患 | 记录至观察清单，定期回顾 | CPU负载波动幅度超过10% |
等级判定原则： 当同一个冲突现象同时满足多个等级条件时，按“就高不就低”原则标注。例如：资源争抢同时导致“关节过热（一般）”与“安全系统降级（致命）”，最终等级应为致命。
1.4 现场排查检查清单（现象识别阶段）
到达现场或收到告警后，按以下清单完成现象确认与信息固定，不得在未完成前尝试修改系统。
- 确认现象是否可复现：至少复现3次，记录复现操作步骤。
- 确认冲突类型归属：使用1.1节四分类法完成归类。
- 完成5W2H结构化记录：使用1.2节的JSON模板落盘。
- 标注当前严重等级：参照1.3节标准。
- 采集原始日志快照：截取冲突前后各60秒的完整报文。
- 冻结现场环境：记录当前负载、网络拓扑、固件版本。
常见返工原因： 现象描述中使用模糊词汇、未记录复现步骤、跳过等级标注直接进入原因猜测。以上三种情况须退回重新填写。
完成现象识别与分类后，排查流程将进入第2章——数据采集与现场信息固定。