3. 被控对象建模与故障注入点识别
虚拟调试的价值,取决于被控对象模型是否足以“承载”故障。如果模型只画了执行机构的外形,却没有把机械传动链、电气回路和控制逻辑之间的因果链表达清楚,那么注入的故障往往只能停留在信号层面,无法验证真实系统在异常工况下的行为。因此,本节的核心任务是:先建立机械、电气、控制逻辑三类模型,再借助FMEA与功能分析,把“可能失效的组件”和“可注入故障的信号”对应起来,形成一份可执行的故障注入点清单。
一、三类模型各自要表达什么
机械模型关注的是运动传递与约束关系。以典型的丝杠滑台为例,伺服电机经联轴器驱动滚珠丝杠,丝杠螺母带动滑台沿导轨直线运动。建模时至少要明确:传动比、丝杠导程、有效行程、限位位置、负载质量与摩擦特性。这些参数决定了位置、速度、力矩之间的换算关系,也是后续判断“卡滞”“打滑”“越程”等机械故障是否成立的依据。
电气模型关注的是能量与信号的传递路径。它应包含供电回路、驱动器、接触器/继电器、传感器供电与信号回路,以及急停、安全门等安全链。电气模型不必精确到每根线,但必须能回答:某个信号断开后,驱动器是否仍使能?急停触发后,哪些输出被切断?传感器失电时,控制器读到的是“0”还是“保持上一值”?
控制逻辑模型关注的是程序层面的状态与判断。它通常由PLC或运动控制器的程序结构表达,包括使能条件、模式切换、互锁、报警处理与复位逻辑。控制逻辑模型的关键不是代码本身,而是“输入条件—内部状态—输出动作”的映射关系。只有把这三类模型对齐到同一套信号命名和坐标系约定上,故障注入才有统一的落点。
二、用功能分析拆出“功能—组件—信号”链
功能分析的目的是把被控对象从“一堆零件”转化为“一组功能”。仍以丝杠滑台为例,其顶层功能是“按指令将滑台定位到目标位置”。向下分解可得:接收位置指令、闭环调节速度与位置、驱动电机输出力矩、通过丝杠将旋转转为直线运动、由导轨约束运动方向、由限位开关提供越程保护。每项功能都对应若干组件和信号。
把功能链展开后,故障注入点就自然浮现。例如“闭环调节位置”对应编码器反馈信号、位置偏差计算和速度环输出;“驱动电机输出力矩”对应使能信号、电流给定和驱动器报警;“越程保护”对应限位开关输入和安全逻辑输出。此时我们不再问“哪里可以注入故障”,而是问“哪个功能失效后,系统应表现出什么行为”。
三、FMEA驱动的故障注入点识别
FMEA提供了一种结构化的提问方式:该组件的失效模式是什么?失效原因有哪些?局部影响和系统影响分别是什么?现有探测手段能否发现?对虚拟调试而言,我们额外关心两点:该失效能否在模型中复现?复现后应观察到什么现象?
以丝杠滑台为例,可整理出如下故障注入点识别表(示例参数为教学假设,非实测数据):
| 功能 | 组件/信号 | 失效模式 | 注入方式 | 预期现象 |
|---|---|---|---|---|
| 位置闭环 | 编码器反馈 | 信号丢失/跳变 | 将反馈置零或叠加脉冲 | 位置偏差突增,驱动器报跟随误差 |
| 力矩输出 | 驱动器使能 | 使能丢失 | 强制使能位为0 | 电机失力,滑台停止或下滑 |
| 直线传动 | 丝杠/联轴器 | 打滑、间隙增大 | 在传动比中叠加增益衰减 | 指令与反馈出现固定比例偏差 |
| 越程保护 | 限位开关 | 常闭触点粘连 | 强制输入保持为1 | 越程时安全链不触发,需软件限位兜底 |
| 安全链 | 急停回路 | 触点拒动 | 屏蔽急停输入 | 急停按下后输出未切断,安全逻辑报警 |
这张表的价值在于:它把FMEA的分析结果直接翻译成虚拟调试可执行的注入动作和判据。注入方式一栏决定了在模型或仿真环境中如何操作,预期现象一栏则决定了验证时看什么、判断是否通过。
四、从识别到落点:建立信号映射
识别出故障注入点后,还需要把它们映射到具体的模型变量或接口信号上。建议采用统一的命名规则,例如“设备_组件_信号_方向”,如 Slide_Encoder_Pos_FB、Slide_Drive_Enable_Cmd、Slide_Limit_Neg_DI。映射时需明确每个注入点是作用于机械参数、电气回路还是控制逻辑,以及它是“替换真实信号”还是“在真实信号上叠加偏差”。
五、模型与注入点的对应关系
下图展示了机械、电气、控制逻辑三类模型如何通过功能链汇聚到故障注入点,并最终形成可验证的注入清单。图中以丝杠滑台为示例对象,标注了典型注入位置与对应信号。
图中左侧三类模型分别提供机械参数、电气回路和控制逻辑的约束;中间的功能分析把模型对象转化为可失效的功能;FMEA进一步把功能失效细化为具体的失效模式与探测手段;最终在底部形成可执行的注入点清单。右侧标注提示每个注入点都需要明确其所属模型类别、注入执行方式和结果判据。
六、识别过程中的常见偏差
实际工作中,故障注入点识别容易出现三类偏差。第一类是“只盯信号、不看功能”,导致注入点零散、缺乏验证目标;第二类是“只做FMEA、不建模型”,分析结果无法在仿真环境中复现;第三类是“注入点与探测手段脱节”,故障注入了却无法判断系统是否按预期响应。避免这些偏差的关键,是始终把“功能—组件—信号—注入—判据”作为一条完整链路来检查,任何一环缺失都应视为识别未完成。
完成本节工作后,应得到一份可追溯的故障注入点清单:每个注入点都能说明它对应哪项功能、属于哪类模型、采用什么注入方式、预期产生什么现象、由哪个信号或逻辑判断结果。这份清单将直接作为后续故障注入脚本编写和异常验证用例设计的基础。