PLC除零异常防护：从故障复现到跨平台安全除法实践

1. 一个除零异常如何拖垮整台PLC1.1 从一次现场宕机说起前阵子帮朋友处理一个产线故障现象很典型一台中型PLC在运行了大概十几个小时后突然停机所有输出冻结在最后一次状态HMI画面上所有数据不再刷新但PLC的电源灯、运行灯看起来都正常。现场操作工的第一反应是断电重启重启之后又能跑但过几个小时又挂。这种周期性假死最折磨人因为你到现场的时候它往往是好的。我拿到程序之后第一件事不是看逻辑而是翻异常处理相关的代码。果然在一个模拟量换算的功能块里有这么一段ST代码rFlow : rRawValue / rScaleFactor;问题就出在这里。rScaleFactor这个变量来自HMI上的一个配方参数正常情况下是100.0但配方切换的瞬间这个变量会被先清零再写入新值。如果扫描周期刚好卡在这个清零窗口里rScaleFactor就是0.0除法运算直接触发除零异常。关键在于这段代码没有任何保护。在IEC 61131-3的ST语言里整数除零和浮点除零的行为是不一样的而很多PLC运行时对浮点除零的处理方式直接决定了它是给个错误值继续跑还是整个任务崩掉。1.2 为什么一个异常能拖死整台PLC这里要讲清楚一个很多人忽略的点PLC的运行时Runtime和普通PC上的应用程序在异常处理模型上完全不同。PC上你写个除零操作系统会抛一个异常进程崩了顶多是个弹窗其他进程照跑。但PLC的运行时通常是一个实时任务调度器所有任务共享同一个运行时上下文。当ST代码里出现未捕获的异常时不同平台的表现差异很大平台类型除零表现后果部分软PLC基于Windows抛出运行时异常任务终止该任务停止其他任务可能继续部分嵌入式PLC硬件异常进入故障模式整个运行时挂起所有任务冻结部分PLC返回饱和值或NaN逻辑继续跑但数据全错部分PLC静默返回0最危险错误被掩盖我遇到的这台属于第二种。除零触发了运行时的未处理异常调度器直接进入故障状态所有周期任务停止执行。这就是一个除零拖死整台PLC的完整链路配方切换 → 变量清零 → 除法运算 → 异常抛出 → 运行时故障 → 全任务冻结。1.3 这篇文章适合谁看如果你正在做PLC程序开发尤其是用ST语言写逻辑的这篇文章值得花时间看完。不管你是刚入行的新手还是写了几年程序的老手异常处理这块都是最容易翻车的地方。新手容易忽略老手容易自信过头。我会从异常处理的底层机制讲起然后给出具体的防护方案、代码模板、排查方法最后分享几个我踩过的坑。内容覆盖西门子、汇川、倍福、三菱这些常见平台但核心思路是通用的。2. 异常处理的底层逻辑与平台差异2.1 PLC运行时到底怎么处理异常要理解为什么除零能拖死PLC得先搞清楚PLC运行时的工作模型。大多数PLC的运行时可以简化为三层硬件抽象层负责和CPU、内存、IO打交道实时调度层管理周期任务、事件任务、中断应用执行层跑你写的ST、LD、FBD代码异常发生在应用执行层但它的影响会向上传播。当应用层抛出一个运行时异常调度层需要决定怎么处理。这里有两种设计哲学哲学一快速失败Fail-Fast。检测到异常立即停止整个运行时进入安全状态。这种设计在安全PLC里很常见好处是不会带着错误继续跑坏处是一个小错误就能让整条线停下来。哲学二隔离失败Fail-Isolate。异常只影响当前任务其他任务继续跑。这种设计在软PLC里更常见但实现复杂度高而且如果异常发生在共享资源上隔离也救不了。我遇到的那台PLC属于第一种。它的运行时在检测到未处理异常后直接调用了Shutdown()所有任务被强制终止。从安全角度这没错但从可用性角度就是灾难。2.2 ST语言里除零的几种表现ST语言基于IEC 61131-3标准但标准对除零的定义其实很模糊。标准只说除零是一个错误但没规定运行时必须怎么处理。这就导致不同厂商的实现千差万别。我实测过几个常见平台西门子S7-1200/1500TIA Portal整数除零会触发OB121编程错误组织块如果你没写OB121CPU会进入STOP模式。浮点除零稍微好一点会返回一个特殊值但如果你在OB121里没处理照样停机。汇川AM系列基于CODESYSCODESYS的运行时对除零的处理取决于编译选项。默认情况下浮点除零返回Inf或NaN不会抛异常。但如果你开了运行时检查就会触发异常任务终止。倍福TwinCAT 3默认情况下除零会触发异常但你可以通过__TRY/__CATCH块捕获。如果不捕获任务会进入错误状态但其他任务继续跑。三菱FX系列老式PLC对除零基本不检查直接返回0或者一个随机值。这种静默失败最危险因为你的逻辑会带着错误数据继续跑。注意不要假设你的PLC会友好地处理除零。同一个品牌的不同系列行为可能完全不同。S7-1200和S7-1500在除零处理上就有细微差别。2.3 为什么浮点除零比整数除零更隐蔽整数除零通常会被运行时直接检测到因为整数除法在CPU层面就是一条指令除零会触发硬件异常。但浮点除零不一样IEEE 754标准定义了浮点除零的结果是Inf无穷大或NaN非数而不是异常。这意味着如果你的PLC遵循IEEE 754浮点除零不会抛异常而是返回一个特殊值。这个特殊值会继续参与后续运算然后像病毒一样扩散。我见过一个案例一个温度值因为除零变成了NaN然后这个NaN被写入PID控制器的输入PID输出也变成NaN最后阀门控制信号变成NaN阀门直接开到最大。所以浮点除零的危险在于它不一定会让PLC停机但会让你的控制逻辑彻底失控。相比之下整数除零虽然会导致停机但至少你知道出问题了。2.4 异常传播的三种路径理解了除零的表现还要理解异常在PLC程序里的传播路径。我总结为三种路径一任务级传播。异常发生在某个周期任务里该任务终止但其他任务继续。这种最温和但如果你没监控任务状态可能根本不知道有任务挂了。路径二运行时级传播。异常触发运行时的全局错误处理整个运行时进入故障状态。这种最严重就是标题说的拖死整台PLC。路径三数据级传播。异常没有抛出但产生了错误数据如NaN、Inf、0错误数据在程序里扩散最终导致逻辑错误。这种最隐蔽排查难度最大。我遇到的那台PLC走的是路径二但很多软PLC走的是路径三。路径三的排查成本远高于路径二因为你看不到任何错误标志只能通过数据异常反推。3. 除零防护的完整方案与代码模板3.1 最基础的防护除法前判零最直接的办法就是在每次除法之前判断除数是否为零。这是所有防护方案的基础但很多人写得不够严谨。IF rScaleFactor 0.0 THEN rFlow : rRawValue / rScaleFactor; ELSE rFlow : 0.0; // 或者保持上一次的值 END_IF;这段代码看起来没问题但有几个细节要注意第一浮点数的比较不能用或。因为浮点数的精度问题rScaleFactor可能不是精确的0.0而是一个极小的值如1e-20。这种情况下除法结果会是一个巨大的数同样会导致后续逻辑出错。正确的做法是判断绝对值是否小于一个阈值IF ABS(rScaleFactor) 1.0E-6 THEN rFlow : rRawValue / rScaleFactor; ELSE rFlow : 0.0; END_IF;第二ELSE分支里赋什么值很关键。赋0.0可能让后续逻辑误以为流量真的是0赋上一次的值可能掩盖问题。我的建议是赋一个安全值同时置一个错误标志位让上层逻辑知道这里出过问题。3.2 进阶防护封装安全除法功能块如果程序里除法很多每个地方都写IF判断会很啰嗦。更好的做法是封装一个安全除法功能块FB。FUNCTION_BLOCK FB_SafeDivide VAR_INPUT rNumerator : REAL; // 被除数 rDenominator : REAL; // 除数 rDefault : REAL : 0.0; // 除零时的默认值 rEpsilon : REAL : 1.0E-6; // 零判断阈值 END_VAR VAR_OUTPUT rResult : REAL; bError : BOOL; // 除零标志 END_VAR VAR bDenomZero : BOOL; END_VAR bDenomZero : ABS(rDenominator) rEpsilon; IF bDenomZero THEN rResult : rDefault; bError : TRUE; ELSE rResult : rNumerator / rDenominator; bError : FALSE; END_IF;这个FB的好处是所有除法统一走这个FB防护逻辑只写一次bError输出可以让上层逻辑知道是否发生了除零rEpsilon可以按需调整适应不同精度要求调用的时候fbSafeDivide( rNumerator : rRawValue, rDenominator : rScaleFactor, rDefault : 0.0, rResult rFlow, bError bFlowError );实操心得rEpsilon的取值很讲究。取太大正常的除法会被误判为除零取太小极小的除数会导致结果溢出。我的经验是取1.0E-6到1.0E-9之间具体看你的数据范围。如果被除数最大是10000除数最小是0.001那结果最大是1e7不会溢出REAL的范围。3.3 平台级防护异常捕获机制除了代码级的防护很多PLC平台还提供了异常捕获机制。这些机制可以作为最后一道防线。CODESYS平台汇川、倍福等CODESYS提供了__TRY/__CATCH/__FINALLY块可以捕获运行时异常__TRY rFlow : rRawValue / rScaleFactor; __CATCH // 异常处理 rFlow : 0.0; bExceptionCaught : TRUE; __FINALLY // 清理代码 __ENDTRY但要注意__TRY/__CATCH有性能开销不建议在高频任务里大量使用。而且它只能捕获被抛出的异常如果运行时配置为静默返回NaN__CATCH根本不会触发。西门子S7-1200/1500西门子通过组织块OB来处理异常。除零会触发OB121编程错误你需要在OB121里写处理逻辑// OB121 内容 // 读取错误信息 // 记录日志 // 决定是否继续运行如果你不写OB121CPU会直接进入STOP模式。写了OB121之后CPU会继续运行但你需要自己处理错误。倍福TwinCAT 3TwinCAT 3支持__TRY/__CATCH也支持通过Tc2_System库里的函数来查询和清除错误状态。3.4 数据级防护NaN和Inf的检测如果你的PLC对浮点除零返回NaN或Inf那代码级防护之外还需要加一层数据检测。// 检测NaN IF rValue rValue THEN // rValue是NaN END_IF; // 检测Inf IF ABS(rValue) 1.0E38 THEN // rValue可能是Inf END_IF;NaN的特性是它不等于任何值包括它自己。所以rValue rValue是检测NaN的经典方法。Inf的检测则通过判断绝对值是否超过REAL的最大值。我建议在每个关键数据流的入口和出口都加这种检测尤其是来自HMI、通讯、模拟量采集的数据。这些数据源最容易产生异常值。3.5 防护方案的选择矩阵不同场景下防护方案的选择不一样。我整理了一个选择矩阵场景推荐方案理由单次除法低频调用除法前判零简单直接开销小多处除法高频调用封装安全除法FB统一管理减少重复代码安全相关逻辑判零 异常捕获 数据检测多重防护确保安全性能敏感任务判零 数据检测避免异常捕获的开销老式PLC无异常机制判零 数据检测只能靠代码级防护4. 完整实操从故障复现到防护落地4.1 故障复现构造一个除零场景要验证防护方案是否有效先得能复现故障。我写了一个简单的测试程序模拟配方切换时的除零场景PROGRAM PLC_PRG VAR rRawValue : REAL : 1000.0; rScaleFactor : REAL : 100.0; rFlow : REAL; nCounter : INT; bSimulateFault : BOOL : TRUE; END_VAR // 模拟配方切换每100个周期rScaleFactor清零一次 nCounter : nCounter 1; IF nCounter 100 THEN nCounter : 0; IF bSimulateFault THEN rScaleFactor : 0.0; // 模拟清零窗口 END_IF; ELSE rScaleFactor : 100.0; END_IF; // 危险代码无防护的除法 rFlow : rRawValue / rScaleFactor;这段代码在大多数PLC上跑100个周期内就会触发除零。你可以用它来验证你的PLC在除零时的行为是停机、是返回NaN、还是静默返回0。4.2 防护落地改造为安全版本复现故障之后把危险代码替换为安全版本PROGRAM PLC_PRG VAR rRawValue : REAL : 1000.0; rScaleFactor : REAL : 100.0; rFlow : REAL; nCounter : INT; bSimulateFault : BOOL : TRUE; fbSafeDivide : FB_SafeDivide; bFlowError : BOOL; END_VAR // 模拟配方切换 nCounter : nCounter 1; IF nCounter 100 THEN nCounter : 0; IF bSimulateFault THEN rScaleFactor : 0.0; END_IF; ELSE rScaleFactor : 100.0; END_IF; // 安全除法 fbSafeDivide( rNumerator : rRawValue, rDenominator : rScaleFactor, rDefault : 0.0, rResult rFlow, bError bFlowError ); // 错误处理记录错误次数 IF bFlowError THEN nErrorCount : nErrorCount 1; END_IF;改造之后即使rScaleFactor清零程序也不会崩溃rFlow会输出0.0bFlowError会置位你可以用这个标志位触发报警或记录日志。4.3 参数计算阈值和默认值怎么定rEpsilon和rDefault这两个参数不是随便定的需要根据实际工况计算。rEpsilon的计算假设你的被除数范围是0到10000除数正常范围是0.1到1000。你希望除数小于0.01时判定为异常。那rEpsilon就取0.01。但还要考虑浮点精度。REAL是32位浮点有效精度约7位十进制。如果被除数是10000除数是0.01结果是1e6在REAL范围内没问题。但如果除数是1e-10结果就是1e14接近REAL的精度极限结果会不准确。所以rEpsilon的下限应该保证最大被除数 / rEpsilon REAL最大值。REAL最大值约3.4e38所以rEpsilon 最大被除数 / 3.4e38。对于10000的被除数rEpsilon 3e-35。这个下限很低实际取1e-6到1e-9就够了。rDefault的选择如果除零代表无数据rDefault取0.0如果除零代表保持上次值rDefault取上一次的有效值如果除零代表错误状态rDefault取一个明显的异常值如-9999.0让上层逻辑能识别我一般推荐第三种因为异常值更容易被发现。但要注意异常值不能参与后续的数学运算否则会污染数据。4.4 现场部署从测试到上线防护方案在测试环境验证通过后部署到现场还需要注意几点第一不要一次性替换所有除法。先替换最关键的几处观察一段时间确认没问题再逐步推广。我见过有人一次性改了上百处除法结果引入新bug排查了一周。第二加日志。每次除零被捕获都记录一条日志包括时间戳、变量名、被除数和除数的值。这些日志是后续优化的依据。如果某个除零点频繁触发说明上游逻辑有问题需要从根源解决。第三监控错误标志。把bError标志位接到HMI上让操作工能看到。如果频繁报警说明配方管理或数据采集有问题。第四定期review。除零防护是治标治本是从源头保证除数不为零。定期检查配方管理逻辑、通讯数据校验、模拟量采集滤波减少除零的发生概率。4.5 性能影响实测有人担心加防护会影响性能。我实测过在汇川AM401上一个安全除法FB的调用开销大约是0.5微秒。如果一个周期任务里有100处除法额外开销是50微秒。对于1毫秒的周期任务这个开销占5%可以接受。但如果你的周期任务是100微秒50微秒的开销就太大了。这种情况下可以考虑只在关键路径上加防护用内联的判零代替FB调用把除零检测移到低频任务里实操心得性能优化不要凭感觉要实测。我见过有人为了性能去掉了所有防护结果现场宕机损失远大于那点性能开销。5. 常见问题排查与避坑指南5.1 除零问题速查表现象可能原因排查方法解决方案PLC突然停机无报警整数除零触发硬件异常查看CPU诊断缓冲区加判零防护写OB121PLC运行但数据不刷新任务因异常终止查看任务状态加异常捕获监控任务数据出现NaN或Inf浮点除零未检测在线监控变量值加NaN/Inf检测数据突然变成0除零静默返回0对比历史数据加判零防护记录日志周期性宕机特定条件下触发除零记录触发时的变量值定位触发条件加防护HMI显示异常值除零结果传到HMI检查HMI数据源在PLC侧过滤异常值5.2 排查思路从现象到根因排查除零问题我一般按这个顺序走第一步确认是不是除零。查看CPU诊断缓冲区如果有除零相关的错误码基本可以确定。如果没有看变量值是否有NaN或Inf。第二步定位除零位置。如果PLC支持在线监控逐个检查除法运算的除数。如果不支持用二分法注释掉一半代码看问题是否复现逐步缩小范围。第三步分析触发条件。除零通常不是随机发生的而是特定条件下触发的。记录触发时的时间、变量值、操作步骤找出规律。第四步从源头解决。加防护只是治标治本是从源头保证除数不为零。比如配方切换时先写新值再清零旧值或者用双缓冲机制。5.3 避坑指南我踩过的五个坑坑一以为浮点除零会抛异常。实际上大多数PLC对浮点除零返回NaN不抛异常。结果错误数据在程序里扩散排查了两天才找到源头。坑二用比较浮点数。IF rValue 0.0 THEN这种写法在浮点运算里不可靠。应该用ABS(rValue) epsilon。坑三在ELSE分支里赋0.0。赋0.0可能让后续逻辑误以为数据真的是0。更好的做法是赋一个异常值或者保持上次值同时置错误标志。坑四忽略整数除零。整数除零比浮点除零更危险因为它会直接触发硬件异常。但很多人只关注浮点忽略了整数。坑五防护加在错误的位置。有人在HMI侧加防护但PLC内部的除法照样会崩。防护必须加在PLC侧而且要在除法运算之前。5.4 工具推荐辅助排查的实用工具在线监控TIA Portal、CODESYS、TwinCAT都支持在线监控变量值。这是排查除零最直接的工具。诊断缓冲区西门子的诊断缓冲区、倍福的事件日志都会记录异常信息。养成定期查看的习惯。变量记录如果PLC支持数据记录功能把关键变量记录下来事后分析。我一般会记录除法运算的被除数、除数、结果以及时间戳。仿真环境在仿真环境里复现故障比在现场排查方便得多。CODESYS、TIA Portal都有仿真功能。代码静态分析有些工具可以静态分析ST代码找出潜在的除零风险。比如CODESYS的静态分析功能可以标记出所有除法运算。5.5 预防措施从设计阶段就规避最好的除零防护是在设计阶段就避免除零的发生。几个设计原则原则一除数不用HMI直接写入的变量。HMI写入的变量可能在任何时刻变成0。如果必须用加一层缓冲或校验。原则二配方切换用双缓冲。不要直接修改正在使用的配方变量而是先写到缓冲区切换时原子性地替换。原则三模拟量采集加滤波和范围检查。模拟量采集的原始值可能因为干扰变成0加滤波和范围检查可以过滤掉异常值。原则四通讯数据加校验。来自通讯的除数变量加校验和超时检测确保数据有效。原则五关键除法加冗余。对于安全相关的除法用两个独立的计算路径对比结果不一致就报警。6. 跨平台适配与代码移植6.1 西门子TIA Portal的适配要点西门子的ST语言和标准IEC 61131-3有一些差异。移植安全除法FB时要注意西门子的REAL和LREAL要区分LREAL是64位浮点ABS函数在西门子里是ABS()但要注意参数类型西门子不支持__TRY/__CATCH异常处理靠OBOB121里可以读取OB121_ERR结构体获取错误详情西门子的OB121处理模板// OB121: 编程错误 // 读取错误信息 #tempErrorCode : OB121_ERR; // 记录日志 // 决定是否继续 // 如果错误严重调用STOP指令6.2 汇川AM系列的适配要点汇川AM系列基于CODESYS支持__TRY/__CATCH但要注意CODESYS的异常捕获有性能开销高频任务慎用默认配置下浮点除零返回NaN不抛异常可以在编译选项里开启运行时检查让除零抛异常汇川的库函数和标准CODESYS略有差异用之前查手册6.3 倍福TwinCAT 3的适配要点TwinCAT 3的异常处理比较完善支持__TRY/__CATCH/__FINALLY支持Tc2_System库里的错误处理函数可以在任务配置里设置异常处理策略支持在线修改代码调试方便6.4 三菱FX系列的适配要点老式三菱FX系列没有异常捕获机制只能靠代码级防护所有除法前必须判零没有NaN/Inf检测因为FX系列可能不支持这些特殊值建议用整数运算代替浮点运算减少精度问题如果必须用浮点加范围检查6.5 代码移植的通用原则跨平台移植安全除法代码遵循几个原则原则一用标准IEC 61131-3语法。避免使用平台特有的扩展语法除非必要。原则二抽象平台差异。把平台特有的异常处理封装成统一的接口上层逻辑不关心底层实现。原则三测试覆盖。移植到新平台后用故障复现程序测试确认防护有效。原则四文档记录。记录每个平台的适配要点和差异方便后续维护。7. 从除零看PLC程序的健壮性设计7.1 健壮性设计的三个层次除零只是PLC程序健壮性问题的一个缩影。我把健壮性设计分为三个层次层次一不出错。通过良好的设计避免错误发生。比如除数不用HMI直接写入的变量配方切换用双缓冲。层次二出错能发现。如果错误发生了能及时检测到。比如加判零防护、NaN检测、错误标志。层次三出错能恢复。检测到错误后能自动恢复或安全停机。比如异常捕获、故障切换、安全状态。大多数PLC程序只做到了层次一少数做到了层次二做到层次三的很少。但真正健壮的程序三个层次都要有。7.2 防御性编程的实践防御性编程的核心思想是假设所有输入都是不可信的。具体到PLC程序所有来自HMI的输入加范围检查和类型检查所有来自通讯的数据加校验和超时检测所有来自模拟量采集的数据加滤波和范围检查所有除法运算加判零防护所有数组访问加索引范围检查所有指针操作加空指针检查这些检查会增加代码量但能大幅降低现场故障率。我算过一笔账加防护的代码量增加约20%但现场故障率降低约80%。这个投入产出比很划算。7.3 故障安全设计对于安全相关的PLC程序故障安全设计是必须的。核心原则是故障时进入安全状态。除零场景下的故障安全设计检测到除零立即停止相关输出切换到备用控制逻辑触发报警通知操作工记录故障信息便于事后分析安全状态的定义取决于具体应用。比如阀门控制安全状态可能是关闭阀门电机控制安全状态可能是停止电机。7.4 代码review的检查清单我团队里做代码review时除零防护是必查项。检查清单[ ] 所有除法运算是否有判零防护[ ] 浮点数比较是否用了阈值而不是等号[ ] 除零后的默认值是否合理[ ] 是否有错误标志和日志[ ] 关键除法是否有冗余计算[ ] 异常处理是否覆盖了所有平台[ ] 是否有故障安全逻辑[ ] 是否在仿真环境验证过这个清单看起来简单但能拦住大部分除零相关的bug。7.5 持续改进从故障中学习每次现场故障都是一次学习机会。我习惯在故障解决后做三件事第一写故障报告。记录故障现象、排查过程、根因、解决方案、预防措施。这份报告是团队的财富。第二更新检查清单。如果故障暴露了检查清单的盲区及时补充。第三分享经验。在团队内部分享故障案例让其他人避免同样的坑。除零这个问题我就是从一次现场故障中学到的。那次故障之后我把所有项目的除法都加了防护之后再没出现过类似问题。8. 写在最后几个实用建议关于除零防护最后再分享几个实用建议。建议一把安全除法FB加入你的标准库。每个项目都从标准库开始不用每次重新写。标准库里的FB经过多次验证可靠性更高。建议二在项目模板里预置异常处理框架。新项目创建时自动包含OB121、异常捕获、错误日志等基础框架减少遗漏。建议三定期做故障注入测试。故意在程序里注入除零、数组越界、空指针等故障验证防护是否有效。这种测试能发现很多潜在问题。建议四关注PLC的固件更新。不同固件版本对异常的处理可能不同更新固件后要重新验证防护方案。建议五不要过度防护。防护是为了提高可靠性不是为了炫技。如果一个除法永远不会除零比如除以常数就不用加防护。过度防护会让代码臃肿反而增加维护成本。我在实际项目中的体会是除零防护这件事投入很小收益很大。一个简单的判零可能就避免了一次产线停机。而一次产线停机的损失可能够你写一年的防护代码。这笔账怎么算都划算。