软件控制器械的 EMC 判定准则怎么写

结论：软件设备的异常不只是「坏了」，还有很多中间状态

纯硬件设备在干扰下的表现相对简单——要么正常，要么输出异常。软件控制的设备则复杂得多： 可能出现程序复位、死机、数据错误、显示异常、通信中断、参数丢失、状态机异常、以及各种间歇性的怪现象。

这些状态在判定时怎么处理，必须事先写清楚。 否则测试现场会出现争议——设备重启了一次算不算失效？显示闪了一下算不算？参数保住了但要重新确认算不算？

准则写在前面，判定就简单；准则不清楚，测试现场没法判。

软件相关的失效表现

「输出异常」是风险分量最重的一类，因为它可能直接导致设备做出危险动作。对于带运动功能的产品，意外输出比无输出更危险。

准则的写法

针对每种可能的表现，准则应当说明是否可接受，以及可接受的条件：

程序复位。 是否允许？如果允许，复位后是否要求自动恢复到原状态？恢复需要多长时间？复位期间设备的输出是什么状态（应当是安全状态）？

死机。 通常不可接受，因为需要人工干预。但如果设备有看门狗能自动恢复，则要说明允许的恢复时间。

数据错误。 允许的偏差范围是多少？超出范围是否有检测和提示？

参数丢失。 是否可接受？关键参数是否应当有保护？

显示异常。 短暂的显示扰动是否可接受？显示恢复后数值是否正确？

通信中断。 前面讲过，取决于链路是否承载基本性能。

输出异常。 通常不可接受。应当明确：干扰期间输出的允许偏差、以及是否允许输出中断。

「复位后回到什么状态」是需要特别明确的。 有些设备复位后回到默认参数，如果使用者之前设定了特定参数，复位就等于设定丢失，而使用者可能没注意到。

安全状态的定义

软件设备在异常时应当进入安全状态，这个状态要定义清楚：

对于运动设备。 停止运动通常是安全状态。但要考虑停在什么位置——比如起立床停在中间角度、移位机停在半空，这些位置本身可能不安全。

对于治疗设备。 停止输出通常是安全状态。

对于监护设备。 停止监护不一定安全，因为使用者失去了监护。这种情况下应当有报警。

对于支撑设备。 保持当前状态通常比停止更安全。

安全状态不是统一的「停机」，要根据设备的功能和使用场景确定。这个判断应当来自风险分析。

监测的安排

软件设备的监测比硬件设备复杂：

需要监测的内容多。 输出、显示、内部状态、通信、参数。

内部状态难以外部观察。 可能需要通过调试接口或日志获取。

间歇性异常需要连续记录。 偶发的异常如果不连续记录会错过。

监测本身不应影响被测设备。 调试接口的连接可能改变设备的电磁特性。

实用的做法包括： 用视频记录显示屏；通过光纤隔离的接口读取内部状态；记录输出信号的连续波形；以及在设备中加入状态日志功能。

「通过调试接口监测会改变设备特性」是需要注意的问题。 连接了调试线的设备与实际使用的设备不同，测出的结果可能不代表实际。如果必须连接，应当说明并评估影响。

恢复行为的要求

干扰消失后设备应当能恢复，恢复行为的要求包括：

是否自动恢复。 不需要人工干预。

恢复的时间。 应当有明确的上限。

恢复后的状态。 回到原状态还是初始状态。

恢复过程中的输出。 不应出现异常输出。

恢复的提示。 使用者是否应当被告知发生过异常。

最后一项值得强调。 设备静默地复位并恢复，使用者不知道发生过什么，可能错过了重要的信息（比如监测数据的缺失段）。记录异常事件并在适当时候提示，是更稳妥的设计。

与软件开发的衔接

EMC 相关的要求应当反映到软件设计中：

数据校验。 关键数据加校验，检测到错误时的处理。

看门狗。 检测程序异常并复位。

参数的非易失存储。 关键参数掉电不丢。

状态机的健壮性。 处理未定义的状态转换。

输出的安全默认值。 异常时输出进入安全状态。

异常日志。 记录复位和异常事件。

这些措施在软件设计阶段加入成本低，产品做完之后再加则可能涉及大范围修改。建议在需求阶段就把 EMC 相关的要求写进去。

间歇性异常的处理

软件设备的一个特点是会出现偶发的、难以复现的异常。处理这类情况的建议：

先确认异常是否真实发生。 区分是设备异常还是监测环节的问题。

记录发生时的条件。 干扰类型、强度、频率、设备状态。

尝试复现。 在相同条件下重复施加干扰，看是否再次出现。

评估风险。 即使偶发，如果后果严重，仍应当处理。

不要简单归为「偶然」。 偶发异常往往提示设计上存在裕度不足的环节。

建议在测试中保持连续记录，这样偶发异常发生时有完整的现场数据可供分析，而不是事后凭印象回忆。

预测试的价值

正式测试之前做一轮预测试，对软件设备尤其有价值：

发现明显问题。 在正式测试前解决，避免正式测试失败。

验证监测方案。 确认监测手段是否可行。

摸清敏感点。 知道设备在哪些频率、哪些状态下较敏感。

校准判定准则。 实际看到设备的异常表现之后，准则可以写得更贴切。

预测试的条件可以简化，目的是筛查而不是判定，所以成本可以控制。

我们的做法

承接软件控制设备的抗扰度测试时，我们会与委托方一起把判定准则写成表格形式——每种可能的异常表现对应一条判定，明确可接受还是不可接受、以及可接受的条件。 这样现场判定就有依据。

监测方面，我们会提前确认能否获取设备的内部状态，以及获取方式是否影响测试。如果只能靠外部观察，某些内部异常可能被漏掉，这一点要事先说明。

如果你有软件控制的设备需要做抗扰度测试，想先把判定准则理清楚，可以把设备功能和软件架构发过来一起讨论，或者直接联系：132 4819 8029。能力范围见服务介绍，送检要求见送检要求，流程见检测流程。

English version

Conclusion. Purely hardware equipment behaves relatively simply under disturbance: either it works or its output goes wrong. Software-controlled equipment is far more varied, exhibiting program resets, lock-ups, data errors, display anomalies, communication drops, loss of parameters, state machine faults and assorted intermittent oddities. How each is to be judged must be written down in advance, or disputes arise at the test site: does one restart count as a failure, does a momentary display flicker, does retaining parameters but requiring reconfirmation? Criteria written beforehand make judgement simple; unclear criteria leave nothing judgeable on the day.

Software-related failure manifestations. A program reset restarts the equipment into its initial state. A lock-up stops response and requires intervention. Data errors corrupt measured or calculated results. Parameter loss clears user settings. Display anomalies produce corruption, garbled characters or jumping values. Communication drops break the external data connection. State machine faults enter undefined states. Output anomalies produce incorrect or unintended control output. And intermittent anomalies occur sporadically and resist reproduction. Output anomalies carry the highest risk, because they can drive the equipment into a dangerous action; for products with motion functions, unintended output is more dangerous than no output.

Writing the criteria. For each possible manifestation, state whether it is acceptable and under what conditions. For program reset: is it permitted, must the original state be restored automatically, within what time, and what is the output during reset, which should be a safe state. For lock-up: generally unacceptable because intervention is required, though where a watchdog restores operation automatically the permitted recovery time should be stated. For data errors: what deviation is permitted, and is there detection and indication beyond it. For parameter loss: is it acceptable, and should critical parameters be protected. For display anomalies: is brief disturbance acceptable, and are values correct once the display recovers. For communication drops: as discussed, depending on whether the link carries essential performance. And for output anomalies: generally unacceptable, with the permitted deviation during disturbance and whether interruption is allowed both stated explicitly. What state a reset returns to needs particular clarity: some equipment returns to default parameters, so that a reset discards a user's specific settings, possibly unnoticed.

Defining the safe state. Equipment should enter a safe state when abnormal, and that state needs definition. For motion equipment, stopping is usually safe, though the position matters: a tilt table stopped at an intermediate angle or a hoist stopped mid-lift may not itself be safe. For therapeutic equipment, ceasing output is usually safe. For monitoring equipment, ceasing to monitor is not necessarily safe since the user loses supervision, so an alarm is needed. And for supporting equipment, holding the current state is usually safer than stopping. The safe state is therefore not a uniform shutdown but depends on function and context, and the judgement should come from risk analysis.

Arranging monitoring. Monitoring software equipment is more complex than monitoring hardware. More must be monitored, covering output, display, internal state, communication and parameters. Internal state is hard to observe externally and may require a debug interface or logs. Intermittent anomalies require continuous recording or they are missed. And monitoring must not affect the equipment under test, since connecting a debug interface can alter its electromagnetic characteristics. Practical approaches include video recording the display, reading internal state through a fibre-isolated interface, recording output waveforms continuously, and building a state log into the equipment. The effect of debug connections deserves attention: equipment with a debug lead attached is not the equipment in service, and results may not represent reality. Where a connection is unavoidable, state it and assess the effect.

Recovery requirements. Equipment should recover once disturbance ceases, and the requirements cover whether recovery is automatic without intervention, the maximum permitted recovery time, the state recovered to, whether original or initial, the absence of abnormal output during recovery, and whether the user should be informed that an anomaly occurred. The last deserves emphasis: equipment that resets and recovers silently leaves the user unaware, possibly missing important information such as a gap in monitoring data. Logging abnormal events and indicating them at an appropriate moment is the safer design.

Connection to software development. EMC requirements should feed into software design. Data validation adds checks to critical data with defined handling on error. A watchdog detects program faults and resets. Non-volatile storage retains critical parameters through power loss. State machine robustness handles undefined transitions. Safe default outputs bring output to a safe state on abnormality. And event logging records resets and anomalies. These cost little to include during software design and may require extensive modification if added after the product is complete, so write EMC-related requirements into the requirements phase.

How we handle it. For immunity testing of software-controlled equipment we work with the client to put the acceptance criteria into a table, with one entry per possible anomaly stating whether it is acceptable and under what conditions, giving site judgement a clear basis. On monitoring we confirm in advance whether internal state can be obtained and whether the means of obtaining it affects the test; where only external observation is possible, some internal anomalies may be missed, and we say so beforehand.

Send us the equipment functions and software architecture and we will work through the criteria. Phone or WeChat: +86 132 4819 8029.