结论：控制器的验证重点不是正常工作，是失效之后的行为
控制器在正常状态下能驱动轮椅，这是基本功能，验证起来不难。真正需要验证的是它失效之后会怎样——是安全地停下，还是失去控制继续运动。
后者的后果很严重：使用者多数行动不便，无法在失控时自行脱离。所以控制系统的安全设计和对应的验证，重要性高于性能指标。
主要故障模式与应对设计
| 故障模式 | 可能后果 | 对应的安全设计 |
|---|---|---|
| 摇杆信号异常 | 意外加速或转向 | 信号合理性检查、双通道冗余 |
| 功率器件击穿 | 电机持续通电 | 硬件切断、独立制动回路 |
| 电机反馈丢失 | 速度失控 | 冗余检测、超时保护 |
| 电源波动或中断 | 突然停止或重启 | 断电抱闸、状态恢复逻辑 |
| 通信中断 | 指令丢失 | 超时判定、安全状态默认 |
| 软件死机 | 失去控制 | 看门狗、独立安全回路 |
| 温度过高 | 器件损坏 | 热保护、降功率策略 |
第二行和第六行需要特别注意。 功率器件击穿导致电机持续通电时，软件已经无能为力，必须靠独立的硬件回路切断；软件死机时同理——安全功能不能完全依赖软件本身。
单一故障状态怎么验证
验证的基本方法是人为制造故障，观察系统行为。常见的做法包括：
断开某个传感器的连接，看系统是否识别并进入安全状态；短接或断开关键信号线；模拟电源电压跌落或中断；强制软件进入异常分支；使某个功率器件失效。
验证的判定标准是：故障发生后，轮椅是否进入安全状态。 安全状态通常指停止运动并保持制动，而不是继续运动或不受控。
需要注意一点：验证时应当在运动状态下制造故障，而不是静止时。静止时断开某根线，系统报错，这不能说明问题；车在行驶中断线，能否安全停下，才是真正的考察。
冗余设计的验证
采用冗余的地方，要验证冗余确实有效：单路失效时另一路能接管、两路的失效不会由同一原因引起（共因失效）、以及冗余切换过程中不会出现异常输出。
共因失效常被忽略。 两路信号如果走同一束线、用同一个电源、放在同一个位置，那么一次机械损伤、一次电源故障就可能同时影响两路，冗余就失效了。验证时应当考虑这类情形。
软件参与时的额外考察
现代轮椅控制器几乎都有软件。软件带来的考察点包括：
安全相关功能是否独立于普通功能。 制动、限速这类安全功能，理想情况下不应当与用户界面、蓝牙通信这些功能跑在同一套逻辑里且互相影响。
参数配置的保护。 很多控制器允许调整加速度、速度上限等参数。这些参数如果能被随意修改，安全边界就不确定了。验证要看是否有权限保护、修改是否留痕。
升级过程的安全。 固件升级过程中断电或中断会怎样，能否恢复。
看门狗的有效性。 不是有看门狗就够了，要验证它在软件真的卡死时确实起作用。
与 EMC 的关联
控制器的故障行为与电磁兼容直接相关。EMC 试验中，控制器可能在干扰下出现误动作，而这属于安全问题而不只是性能问题。
所以 EMC 试验的基本性能判定里，应当包含控制行为的安全性：受到干扰时，轮椅是否出现意外运动、制动是否仍然有效。只判定「显示是否正常」是不够的。
验证记录该留什么
故障注入类的验证，记录应当包括：注入的是什么故障、怎么注入的、当时轮椅处于什么状态、系统的响应是什么、恢复过程如何。
「通过」两个字不构成有效记录，因为后续如果设计变更，需要判断哪些验证要重做，而这依赖于当初验证了什么、怎么验证的。
验证与风险分析的对应
控制系统的验证项目应当直接来自风险分析。做法是把风险分析中识别的每一条与控制相关的失效模式列出来，对应到一个验证方法。
这张对应表有两个用途：确认验证没有遗漏；在设计变更时判断哪些验证需要重做。表里如果有某条风险找不到对应的验证，那就是一个缺口，应当补上或者说明为什么不需要验证。
失效后的可恢复性
除了进入安全状态，还应当考察失效后的可恢复性：使用者能否自行恢复、需要什么操作、恢复过程是否安全。
这一点对实际使用影响很大。如果某个故障需要专业人员才能复位，使用者在户外遇到就会被困住。安全停下是底线，能安全恢复才是好设计。
老化与失效率的关系
控制器中的电子元件会随使用时间老化，失效概率随之变化。这意味着新机状态下的验证结论，不完全代表产品在寿命后期的安全性。
可行的补充手段包括：对关键元件做加速老化后重新验证安全功能；在设计中留出元件参数漂移的裕度；对失效后果严重的功能设置定期自检。
定期自检是性价比较高的一项。 系统在每次开机时自检关键安全回路，能在故障累积成危险之前发现问题。
使用者可感知的失效提示
安全设计除了让系统进入安全状态，还应当让使用者知道发生了什么。故障指示应当能区分故障类型，至少区分「可自行处理」和「需要维修」。
只给一个笼统的故障灯，使用者无法判断该怎么办，可能反复尝试重启而忽略了真正的问题。
我们的做法
做控制系统验证时，我们会与委托方一起列出故障模式清单，再逐项设计注入方法。这份清单较好的来源是委托方的风险分析文件——风险分析里识别的失效模式，应当在验证中被覆盖，两者要能对上。
实际中常见的情况是，风险分析文件写得很全，但验证只做了标准要求的那几项，中间存在缺口。把两份文件并排核对一遍，缺口通常就显出来了。
有需要可以把控制系统方案和风险分析发过来一起梳理，或者直接联系：132 4819 8029。检测能力见服务介绍，产品分类见电动轮椅检测与代步车检测，标准信息见标准查询。
English version
Conclusion. A controller that drives the chair correctly in normal operation is basic functionality and not hard to verify. What genuinely needs verification is behaviour after a fault: does the chair stop safely, or does it continue moving out of control. The latter carries serious consequences, since most users cannot extricate themselves from a runaway chair. Safety design of the control system and its verification therefore matter more than performance figures.
Fault modes and corresponding design. Abnormal joystick signals can cause unintended acceleration or steering, addressed by plausibility checking and dual-channel redundancy. A shorted power device can leave the motor permanently energised, addressed by hardware disconnection and an independent braking path. Loss of motor feedback can cause speed runaway, addressed by redundant sensing and timeout protection. Supply fluctuation or interruption can cause abrupt stops or restarts, addressed by fail-safe braking and defined recovery logic. Communication loss causes command loss, addressed by timeouts and a defined safe default state. Software lockup causes loss of control, addressed by a watchdog and an independent safety circuit. Overtemperature damages devices, addressed by thermal protection and power derating.
Two of these deserve emphasis. When a power device fails short and the motor stays energised, software can do nothing and an independent hardware path must interrupt it. The same applies to software lockup. Safety functions cannot depend entirely on the software itself.
Verifying single-fault conditions. The method is to induce faults deliberately and observe behaviour: disconnect a sensor and see whether the system detects it and enters a safe state; short or open a critical signal line; simulate supply dropout; force the software into an abnormal branch; make a power device fail. The criterion is whether the chair reaches a safe state, meaning motion stops and braking holds, rather than continuing to move or behaving unpredictably.
One point matters: induce faults while the chair is moving, not while stationary. Disconnecting a wire at rest and seeing an error message proves little. Whether the chair stops safely when a wire fails while it is travelling is the real question.
Verifying redundancy. Where redundancy is used, confirm that it works: that the remaining channel takes over, that both channels cannot fail from a single cause, and that no abnormal output occurs during changeover. Common-cause failure is often overlooked. Two channels sharing a loom, a supply or a location can both be lost to one mechanical impact or one supply fault, and the redundancy is then illusory.
Additional points where software is involved. Safety-related functions such as braking and speed limiting should ideally be independent of ordinary functions such as the user interface and wireless communication. Parameter configuration needs protection, since controllers commonly allow acceleration and speed limits to be adjusted and unrestricted modification leaves safety boundaries undefined; check for access control and change logging. Firmware update needs examining for what happens if power is lost mid-update and whether recovery is possible. And the watchdog needs verifying in a genuine lockup rather than merely being present.
Relationship to EMC. Fault behaviour and electromagnetic compatibility are directly connected. Under disturbance a controller may malfunction, which is a safety matter rather than merely a performance one. The essential performance criteria used in EMC testing should therefore include control safety: whether unintended motion occurs under disturbance and whether braking remains effective. Judging only whether the display behaves correctly is insufficient.
What to record. For fault injection, record which fault was injected, how, what state the chair was in, how the system responded and how it recovered. The word passed does not constitute a usable record, because a later design change requires knowing what was verified and how in order to judge what must be repeated.
How we handle it. We build a fault mode list with the client and design an injection method for each. That list is best drawn from the client's risk analysis, since the failure modes identified there should be covered by verification and the two documents should reconcile. A frequent finding is a thorough risk analysis alongside verification covering only the items the standard requires, leaving a gap that becomes visible as soon as the two are compared side by side.
Send us the control system design and the risk analysis and we will work through it. Phone or WeChat: +86 132 4819 8029.