做工业软件这些年我见过太多“算法很美、现场翻车”的项目。几年前去某水处理项目处理一起报警频繁误触发的问题值班员半夜被吵醒后直接告诉我“这报警我早就不信了。”排查后才知道现场信号线上有一个挺隐蔽的干扰源把4-20mA信号带着乱跳。项目组此前用了一套效果不错的平滑算法仿真里误差曲线漂亮得很可面对这种不讲理的数字毛刺照样误判。后来我们改了个很“土”的方案先限幅、再延时确认、最后才出报警。代码量少了三分之二报警从那以后基本绝迹。这件事让我把多年浓缩成一句话也是这篇想聊透的核心观点工业软件中的数据处理跟学术科研是两套完全不同的价值体系。学术追求的是在干净数据上逼近最优解工业软件追求的是在极端恶劣环境下不炸、不误报、不失控。这三件事全做到比任何华丽的算法都值钱。1. 一次现场事故让我改写了数据处理策略的排序1.1 项目组引以为傲的滤波算法败给了一根干扰线那个水处理项目的具体问题是这样的现场的流量计和液位计信号偶尔会出现几秒的毛刺数值跳动范围能到量程的百分之三四十。项目组之前用了一款带预测补偿的滤波算法初衷是既要平滑噪声又要快速跟踪真实变化。实验室里确实测过信号在正弦波、阶跃、随机噪声三种典型输入下表现都很好。但到了现场毛刺不是“噪声”而是“故障”——它并不符合算法对噪声分布的任何假设。算法把跳变当成“真实信号的大幅变化”进行跟踪于是滤波输出跟着毛刺一起跑再叠加后续的判断逻辑就产生了大量误报。这个案例的教训不是算法有问题而是我们把它放错了位置。算法的前提是“输入基本靠谱只需要滤掉小幅噪声”。但工业现场的数据在进入算法之前可能已经突破了所有前提数值变成NaN、直接跳到量程之外、连续掉线、时间戳错乱。这些场景任何基于统计假设的平滑算法都束手无策。所以我现在做任何数据处理第一道工序永远是“数据有效性检查”而不是“滤波”。1.2 “最优解”与“可接受解”两套价值体系学术界处理数据追求的是某个准则下的最优比如最小均方误差、最大似然估计。这些方法都有一个隐含前提数据基本可靠噪声服从某种已知分布计算资源相对充足失败了大不了重跑一次。工业现场完全不满足这些前提。数据可能是坏的通信可能是断的算力是固定的更关键的是——误动作可能导致设备损坏或者安全事故。用开车来类比学术优化追求的是“平均车速最快”工业追求的是“任何路况下都不翻车”。你可以把平均速度做得很高但山路、雨雪、爆胎这些情况一旦出现一次翻车就全完了。我把这两套体系做了个简单对照维度学术数据处理工业软件数据处理数据环境相对干净分布可假设脏、乱、缺、错都可能算力资源充足、可扩展受限、固定周期失败代价重新跑一次停机、安全事故评价指标RMSE、MAE等精度指标可用率、误报率、漏报率、平均无故障时间核心诉求最优解恶劣环境下仍可控这个对照不是否定学术方法的价值而是提醒我们在工业项目里评价一个算法好不好看的不是实验室指标而是它在“最坏情况”下的行为。你把正常工况下的误差缩小1%远不如把极端工况下的行为做对。1.3 把目标拆成三个词不炸、不误报、不失控这三个词看似简单其实是对工业软件数据处理目标的完整概括不炸系统在数据异常、通信异常、资源紧张时不死机、不崩溃、不出现内存溢出或任务超时始终保持可用。不误报正常工况下不产生错误报警不让真实的故障被海量无效报警淹没维护操作员对系统的信任。不失控即使数据失效或设备异常系统也能进入安全、可预期的状态并让操作员有办法干预。三者的优先级有先后。不炸是地基地基没了什么都不用谈。不误报和不失控共同保障“安全且可信”但两者有时会发生冲突为了防误报而增加确认延时可能拖累故障响应速度为了快速动作而减少确认又可能误跳。这个张力后面章节会反复遇到。2. “不炸”的地基原始数据进入系统前的那道闸门2.1 模拟量限幅与跳变抑制先把物理世界的不讲理挡在外面工业现场的数据进入系统后第一个动作不应该是滤波而是一组“物理合理性”检查。原因很简单滤波解决的是“信号在合理范围内的小幅抖动”而现实经常出现的是“信号在合理范围外的大幅跳变”。我的做法分三步量程检查、变化率检查、连续确认。量程检查最直观数值超出传感器量程连“超量程”的这种数据都算无效。有些变送器在断线或故障时会输出0mA或超过20mA对应数值可能低于量程下限或高于上限。我会在量程上下各留一个较小的余量作为超量程判定区。变化率检查是筛选“物理不可能”的跳变。比如一个温度传感器量程0到200度工艺上温度每秒最多上升5度如果采样周期是100ms那么相邻两个有效值之间的差值就不应该超过0.5度。一旦差值远大于这个数要么是传感器坏了要么是线缆干扰要么是信号被污染。连续确认是为了区分“单次干扰”和“真实突变”单次跳变大概率是干扰连续N个周期都跳变可能是真实的工艺突变也可能是传感器彻底坏了。两种情况都不该静默接受至少要在日志里记一笔甚至触发告警。下面是我常用的伪代码逻辑function checkRawValue(raw, lastGood, dt): # 第一步数值合法性 if not isFinite(raw): invalidCount return INVALID if raw RANGE_MIN - OVERSHOOT or raw RANGE_MAX OVERSHOOT: invalidCount return INVALID # 第二步变化率合理性 maxDelta MAX_PHYSICAL_RATE * dt if abs(raw - lastGood) maxDelta: jumpCount if jumpCount REPEAT_THRESHOLD: return INVALID_LIKELY_INTERFERENCE else: # 连续多次大幅跳变可能是真实突变或传感器故障 sensorFaultFlag true return SUSPICIOUS_VALID else: jumpCount 0 return VALID这段逻辑的关键点在于跳变不是被直接拒绝而是被标记为“可疑”。因为有些工况下真实信号就是会突变比如阀门突然打开、管道泄漏导致压力骤降。你要做的是让后续逻辑知道“这个数据我不是很有信心”而不是武断丢弃。2.2 NaN、Inf、除零浮点世界的魔鬼细节如果说量程和变化率是“宏观检查”那么浮点特殊值就是“微观地雷”。NaN是传染性的一个NaN进入平均值计算整个窗口的结果都会变成NaNNaN进入比较判断所有比较都返回falseNaN进了PID运算输出可能直接失控。更麻烦的是NaN不一定来自通信软件自身的运算也能产生。比如分母极小的除法得到Inf或者两个Inf相减得到NaN。很多项目在实验室没出问题是因为数据源干净一到现场传感器量程配置错误、某个参数除出来变成Inf问题就爆出来了。我的建议是设置一道“数据标准化门”。所有外部数据进入系统后统一走一个入口函数强制做有限性检查if (!isfinite(raw)) { // 记日志来源、时间戳、原始位串 // 返回值判定为无效 }值得注意的细节C语言里判断NaN可以用raw ! raw因为NaN与任意值包括自身比较都不相等。但用isfinite更稳妥它能同时处理NaN和Inf。很多老工程师在代码评审时专门看有没有“裸奔”的浮点值——凡是外部传入的浮点数入口必须过一遍这道检查。还有一个容易被忽视的是整数溢出。比如用32位毫秒计数器计算时间差两个时间戳相减时如果直接按有符号整数处理计数器回绕后可能算出负的间隔。这种问题不复杂但很隐蔽隐蔽到日志里看着是正常数值实际已经完全错误。2.3 时序完整性与时间戳纪律数据可以晚但不能错乱通信链路不稳定时数据会晚到、丢包、乱序。很多数据处理逻辑默认“数据按顺序到达、周期恒定”这个假设在现场根本不成立。我一直在强调一条纪律每条数据必须携带两个时间——数据产生时间戳和系统接收时间戳。控制运算以接收时刻为时间基准数据新鲜度判断以产生时刻为依据。两者分开才能准确判断“这个数据到底多老了”。处理乱序时如果用了滑动窗口或平均值滤波窗口内的数据必须按产生时间戳排序实在排不了就把超过一个周期的数据当作缺口处理而不是当作有效样点塞进窗口。否则一个迟到的旧数据会把窗口里的平均值拉偏输出就会出现莫名其妙的毛刺。同时所有接收缓冲队列必须有界。队列无限增长会拖垮内存最终拖垮整个进程。超过最大长度的数据怎么处理可以商榷——丢弃最旧、丢弃最新都行但一定要丢弃并且要计数、上报告警。2.4 执行资源余量算法再好也不能吃掉看门狗的口粮实时系统里算法做不做得漂亮是其次能不能在规定周期内跑完才是生死线。你在开发机上跑得飞快不代表它在老旧控制器上也跑得动。这里要引入一个概念最坏执行时间WCET预算。评估算法占用时必须按最坏情况估计不能按平均情况。我的习惯是把任务负载率控制在60%以下。留出的余量不是浪费而是应对通信洪峰、报警风暴、故障处理这些突发场景。你永远不知道哪个瞬间会有100个测点同时上报异常但如果CPU已经被正常负载吃掉90%那这个瞬间系统大概率就“炸”了。内存方面工业控制器上尽量避免运行期频繁动态分配。环形缓冲、静态数组、内存池是更常规的选择。看门狗也不是万能的它能防“逻辑死锁”但恢复不了物理世界。所以看门狗只能作为最后一道网不能把安全希望全押在它身上。3. “不误报”的判定报警与状态确认为什么宁可迟钝不可机灵3.1 报警抖动是信任杀手迟滞死区不是可有可无报警系统最大的敌人不是漏报而是“狼来了”。液位在设定值附近波动时每次越过阈值都报警、回到阈值内又消除一分钟能响几十次。要不了多久操作员就会把报警音关掉或者在心理上彻底无视它真正的故障来了反而没人反应。解决报警抖动的经典手段是迟滞死区也就是让“触发报警的电平”和“恢复正常的电平”不在同一个点上。比如高报阈值是90可以设置恢复阈值为88。数值升到90以上报警之后必须回落到88以下才解除报警。参数含义经验考虑报警阈值触发报警的边界值由工艺要求确定恢复阈值报警解除的边界值通常取阈值减去一个回滞量回滞量触发与恢复之差建议取正常噪声波动范围的2到4倍有人担心死区设置太大会掩盖真实故障这个担心有道理但要分清“报警层”和“联锁层”。报警层的防抖可以大胆些它的目的是提示联锁层要单独设计必须更快、更稳。两个层级共用一套防抖参数是最常见的错误。3.2 延时确认与计数判稳给报警装一道“双确认”门槛迟滞死区解决的是临界波动延时确认解决的是瞬时脉冲。现场经常出现这样的数据某个值在极短时间内冲到阈值以上然后又立刻回落。如果不做处理系统就会报一次假警。延时确认的机制很简单不是一超阈值就报警而是“持续超阈值达到一定时间”才确认报警。我一般用计数方式实现每扫描一个周期超阈值就加一未超就减一计数达到N时才输出报警信号。这里的“减一而不是清零”是为了避免临界点上的反复抖动造成计数反复清零。伪代码大致是这样alarmCount 0 ALARM_CONFIRM 3 # 连续3个扫描周期确认 every scan: if value threshold: if alarmCount ALARM_CONFIRM: alarmCount else: outputAlarm true else: if alarmCount 0: alarmCount-- else: outputAlarm false这个“计数降级而不是清零”的思路是现场抗脉冲报警的关键。但要记住延时确认必须应用于“报警提示层”绝不能用于安全联锁层。联锁逻辑必须宁快勿慢哪怕是冒一点误动作的风险也不能让真故障拖到不可收拾。3.3 变化率比绝对值更会“说谎”跳变与缓变的区别对待有些故障绝对值还没超限变化率已经暴露了问题。轴承振动、流量突降、压力骤变都属于这一类。只看绝对阈值等触发报警时故障已经发展得很严重了。但变化率报警本身有个数学陷阱一阶差分会放大高频噪声。原始信号里只要有微小的抖动差分出来可能就是很大的尖峰。直接用“相邻两点差值”来判断变化率会给报警系统引入大量误报。我的经验是用移动窗口内的直线拟合斜率或者先对信号做一阶低通滤波再求差分。窗口越长抗噪越好但反应越慢。这个取舍要针对具体物理量来做物理量特征建议时间窗口说明慢变过程量温度、液位数秒到数十秒噪声小变化慢快变过程量流量、压力几百毫秒到数秒噪声中等振动、冲击类信号几十到几百毫秒噪声大必须配合带通或拟合实际项目中我见过一个泵的振动信号运行正常时变化率噪声在0.1mm/s²以内。某次内部卡涩振动在几十秒内从1mm/s涨到3mm/s绝对值距离5mm/s的超限阈值还早但变化率已经异常。变化率报警帮我们提前了十几分钟发现故障。这就是“绝对值变化率”双通道报警的价值。3.4 冗余表决一个传感器说了不算三个传感器也别乱信多传感器冗余并不是“三个里有两个一致就信”那么简单。假设有三个液位计其中有一个被淤泥堵了读数固定在某个值不再变化。另外两个读数是正常的表决结果是2:1大多数获胜看起来没问题。但如果另外两个正好都受到同一股干扰源的影响读数一起偏了2:1的表决就会把错误结果当成正确的来用。所以冗余表决必须和一致性检查、卡住检测配合使用。一致性检查是指多个测点的读数偏差在合理范围内卡住检测是指数值长时间不变而关联变量在变化。任何被判定为“可疑”的测点都应该被隔离出表决组不能参与投票。表决之后的处理也很有讲究。2oo3表决通过后我通常取中间值而不是平均值因为平均值会被一个极端值拉偏。剔除离群点后用中位数或者基于一致样本的平均值会更可靠。还需要记录“表决组健康度”今天是否有测点被隔离、隔离了几次、持续多久。这些信息对运维很有价值它告诉你“冗余”到底还剩多少。4. “不失控”的兜底数据失效之后系统到底该怎么活4.1 分级响应把故障按照危重程度排队处理故障不一定要“停车跳闸”也不能都等着“自动恢复”。更好的方式是把故障按严重程度分级每一级规定明确的系统行为让操作员清楚地知道当前处于什么状态。我的常见分级级别名称典型场景系统行为L1观察单项数据短暂无效记录日志、标记数据质量L2提醒测点掉线超过阈值界面提示、输出保持、尝试切换备用L3干预关键参数失效自动进入安全模式、通知操作员确认L4应急安全联锁条件成立直接触发联锁动作、停止危险工况设计原则是越往后动作越不可逆判定条件就越要“多源确认”。L4级别的联锁不能因为单个数据的一次瞬时跳变而触发至少要结合趋势、变化率、相关测点一起做决策。4.2 保持旧值还是安全值卡住失效带来的老坑数据失效之后最纠结的问题是输出到底保持旧值还是切到安全值Hold保持最后有效值在很多场景下是合理的因为它能避免输出大幅波动。但这个策略有一个致命弱点如果传感器是“卡住”失效——读数停在某个值不再变化——那么保持旧值就是把错误延续下去而且延续多久都看不出来。举个真实教训某水处理项目里的pH传感器失效输出一直停在7.0而实际药剂的投加已经过量pH早就不在该在的范围。系统因为采用Hold策略始终用7.0这个“旧值”做判断没有触发任何告警。直到后续化验才发现问题。后来我给这套系统加了两个东西卡住检测数值持续不变超过设定时间同时判断相关的工艺变量是否在变化保持时限任何Hold策略都必须有时限——比如最多保持10秒超过后强制切到安全值或进入故障模式。这个思路可以推广到很多场景保持旧值不是不可以但必须让它“过期”。安全值也不是拍脑袋定的。安全值的选取一定要从设备安全状态反推阀门关到位是安全还是保持当前位置是安全风机降速到某个转速是安全还是直接停机是安全不同设备、不同工艺答案完全不同。4.3 手动/自动切换与输出平滑别把切换做成一次事故数据失效后的系统行为最终都要落到执行机构上。手动切自动、自动切手动、主备控制器切换这些操作如果处理不好会让系统在“最需要稳定”的时候产生剧烈输出跳变。最经典的坑是手动模式下操作员把输出调到一个值比如50%这时候切换到自动PID的目标输出是80%。如果没有做任何缓冲切换那一瞬间输出直接从50%跳到80%执行机构猛地动一下轻则设备震动重则导致工艺波动。解决方案是输出限速器在输出通道上限制每秒最大变化量。切换的瞬间输出按照限速斜率从当前值逐渐过渡到目标值。冗余控制器的切换也有同样的道理。主备两个控制器要持续同步状态备机的输出要一直跟踪主机的当前输出。切换发生时才能做到“无扰切换”——输出不出现可见的阶跃。如果两个控制器采样不同步切换瞬间可能会有微小偏差再加上输出限速机制就能把切换毛刺限制在可接受范围内。4.4 操作员要被看见数据质量位和诊断信息的可视化我见过太多系统界面上一堆数字在跳动但操作员根本不知道哪些值是真实采集的哪些是降级后的备用值哪些是保持的旧值。拿着错误的地图开车出事故是早晚的事。所以数据输出不能只有数值还必须带一个质量位Quality。至少要有四种状态好、坏、可疑、手工强制。界面上用颜色区分正常绿色、可疑黄色、无效灰色。当系统从主信号切到备用信号或者进入保持/安全值模式时界面上必须明确提示“当前使用的是备用信号”或者“该测点数据已失效”。事件序列记录SOE也很重要。当故障发生时事后追溯需要把“数据失效、报警触发、信号切换、执行动作”这几个事件的时间顺序完整还原出来。没有质量位和SOE你根本说不清是“先有故障再有报警”还是“误报之后导致操作员误判断”。5. 那些“看起来很美”却在现场翻车的实战复盘5.1 卡尔曼滤波模型失配噪声协方差写错之后的连环误报某流量测量项目为了让信号更平滑用了卡尔曼滤波器。仿真阶段一切正常因为我把测量噪声协方差R调得比较小滤波器对测量值的信任度很高跟踪效果相当漂亮。到了现场信号里偶尔出现突发脉冲。按卡尔曼理论如果模型准确它可以自动平衡“预测”和“测量”。但问题恰恰是模型不准确——现场的脉冲噪声根本不是正态白噪声。结果滤波器被脉冲带偏经过几轮迭代后输出出现缓慢的偏移又叠加报警阈值判断产生了连环误报。排查到最后真正的问题其实是“现场没法做正规的系统辨识来校准噪声参数。”这也不是卡尔曼不能用而是它的性能高度依赖模型而模型需要大量现场数据来标定。大多数项目根本没有这个时间和环境。最后我们改成了“限幅一阶低通”的组合参数只有两个一个管跳变幅度一个管平滑系数。误报消失信号也够平滑。这件事的启示不是“卡尔曼不好”而是“在没有现场建模条件的项目里别用依赖精确模型的算法”。5.2 “保持最后有效值”让一台风机烧了风道这个案例我前面提过一半这里把完整链路说清楚。某监测系统用温度传感器监控风机出口温度传感器因为接线松动间歇性掉线。掉线期间数据处理逻辑按照默认策略“保持最后有效值”运行输出停在当时的50度。实际温度在掉线后继续上升很快超过了高温报警阈值但因为输出一直是50度联锁自然没有被触发。风机就这么在超温状态下继续运行最后风道变形损失不小。事故复盘时发现系统里根本没有“数据失效超过多久必须切到安全值”的时限概念也没有“温度读数长期不变但相关量在变化”的卡住检测。后来我们给所有“保持”策略加了三道闸卡住检测、保持时限、失效计数。传感器掉线超过设定秒数即使数值没变也强制标记为无效并按工艺安全需求选择安全值或报警提示。5.3 报警延时设得太大真报警被“消音”了某个团队为了消灭误报把所有报警的确认时间统一设置为30秒。思路是超过30秒才算真报警短时间的波动一律忽略。结果某次管道压力骤升因为是真实故障压力持续超限。理论上30秒后应该报警但系统里还有其他逻辑在叠加延时真正触发时已经过去了四十多秒设备已经受损。虽然最终动作了但错过了最佳响应窗口。复盘结论非常清楚报警“防抖”和联锁“响应”是两个层级不可混用。报警层可以延时确认它的目的是过滤无效干扰联锁层必须以安全响应时间作为硬约束它的目的是在故障发生时第一时间动作。层级的严谨分离是设计工业报警逻辑的第一原则。5.4 冗余切换时的0.5秒毛刺双机冗余系统做主备切换时输出出现了一个0.5%的阶跃。执行机构对这个阶跃反应很敏感阀门瞬间动了一下引发了一次小的工艺波动。表面看0.5%不算大但在高精度控制回路里这个阶跃足以打破稳定。深入排查后问题出在两方面一是备用机虽然一直在运行但它的输出量并没有持续跟踪主机的实际输出切换瞬间两者之间存在差值二是切换逻辑和数据源切换同时发生两个扰动叠加造成了可见的输出跳变。解决方法是标准的三件套持续输出跟踪、切换时刻输出锁定一小段时间、切换后加输出限速。从那以后我在评审任何冗余切换逻辑时都会单独检查“切换瞬间输出是否可能出现阶跃”这一条。6. 把“极端工况全覆盖”变成设计规则的几条经验6.1 先列失效模式清单再选算法很多项目选算法的顺序是反的先看到某个算法很流行或者看起来很高端然后往里套数据。正确的顺序应该是反过来的——先穷举失效模式再决定用什么东西去应对。我的设计流程是这样的把系统里所有可能的失效模式列成清单覆盖传感器断线、供电噪声、通信丢包、数据乱序、CPU过载、内存不足、看门狗超时等。对每一个失效模式定义明确且可验证的预期行为。选择算法前先问这个算法在这些失效模式下表现怎么样最简可用优先。算法每增加一层复杂度就必须明确指出它覆盖了清单里的哪个失效模式。如果没有对应关系这一层复杂度就是风险。这听起来像是降低标准实际上是在做减法。工业系统每多一个复杂环节就多一个出问题的可能。用最简单的逻辑把极端情况都兜住比用复杂的模型去追求“平均情况更优”要可靠得多。6.2 三层防线采集防护、逻辑防护、执行防护把数据处理拆成三层独立的防线每层职责清晰问题也容易定位。采集防护层限幅、死区、断线检测、NaN过滤、时间戳校验。这一层的任务是“不让坏数据进入逻辑层”。逻辑防护层状态机、延时确认、冗余表决、卡住检测、数据质量标记。这一层的任务是“用逻辑判断剔除可疑数据在多个信号之间做决策”。执行防护层安全值、速率限制、手动切换、看门狗监控。这一层的任务是“即使数据和逻辑都不完美执行机构也不能乱动”。三层一旦分开调试和定位问题就变得非常直接。数据异常看采集层报警误报看逻辑层输出跳变看执行层谁的问题一目了然。6.3 自诊断和健康监测机器要学会自己汇报“我可能病了”数据处理的健壮性不能只靠外部的“故障发生后的兜底”还应该在正常运行时持续自省。每个功能模块都要有健康状态指标运行周期、上次执行时间、每次循环的耗时、异常计数。心跳机制是其中最典型的应用。边缘网关要周期性地向SCADA上送心跳包上层系统一旦检测到心跳丢失就应立即将该节点标记为异常不能等到数据不更新了才发现问题。数据新鲜度也是同一个道理每个测点数据都带有“有效期”超过有效期即使数值不变也该视为无效。自诊断的意义是让系统在“真正炸掉之前”先发出呻吟。呻吟可能不准确但总比一声不吭地带病运行要强得多。日志里记录的数据质量、异常计数、卡住标志都是运维和故障分析的宝贵素材。6.4 故障注入测试至少要在测试里逼死系统一次测试不能只测“正常工况下的精度”更重要的是一套故障注入矩阵。我会在每个项目的测试计划里强制加入注入项目验证目标传感器断线、短路不误报、数据标记为坏信号大幅跳变、NaN注入入口拦截生效不污染后续通信丢包、乱序、延迟队列有界时序逻辑正确并发报警风暴系统不超时、不崩溃CPU长时间过载看门狗与降级逻辑正确冗余切换瞬间输出无阶跃故障注入测试的目的不是看系统崩溃得有多难看而是验证设计好的降级路径真的被执行了。很多系统在代码评审阶段看不出问题故障注入一跑就露馅。这比在现场翻车再排查成本低了不知道多少倍。写到这里顺便说些个人体会。刚做这行的时候我也喜欢“炫技”总想着用更高级的模型证明自己。这几年被现场教育过太多次之后反而越来越尊敬那些朴素的规则入口处拦截非法数据、报警前确认几次、失效后按预定路径降级。技术领域没有万能的算法但一套把极端工况全覆盖的简单逻辑可以稳定运行很多年。我现在评审每个新功能都会先问三句话数据如果坏了会怎样算法如果失效了会怎样操作员如果误操作会怎样三个问题都有明确答案代码才允许提交到现场。这篇内容的初衷就是希望后来者少走一点我走过的弯路尤其是不必再为“学术最优解”盲目焦虑——先想清楚系统在最坏情况下怎么活再谈优化也不迟。 
长河君 · 2026/10/22 12:01:05 · 阅读 1.2k 工业软件数据处理：极端工况下不炸、不误报、不失控
做工业软件这些年我见过太多“算法很美、现场翻车”的项目。几年前去某水处理项目处理一起报警频繁误触发的问题值班员半夜被吵醒后直接告诉我“这报警我早就不信了。”排查后才知道现场信号线上有一个挺隐蔽的干扰源把4-20mA信号带着乱跳。项目组此前用了一套效果不错的平滑算法仿真里误差曲线漂亮得很可面对这种不讲理的数字毛刺照样误判。后来我们改了个很“土”的方案先限幅、再延时确认、最后才出报警。代码量少了三分之二报警从那以后基本绝迹。这件事让我把多年浓缩成一句话也是这篇想聊透的核心观点工业软件中的数据处理跟学术科研是两套完全不同的价值体系。学术追求的是在干净数据上逼近最优解工业软件追求的是在极端恶劣环境下不炸、不误报、不失控。这三件事全做到比任何华丽的算法都值钱。1. 一次现场事故让我改写了数据处理策略的排序1.1 项目组引以为傲的滤波算法败给了一根干扰线那个水处理项目的具体问题是这样的现场的流量计和液位计信号偶尔会出现几秒的毛刺数值跳动范围能到量程的百分之三四十。项目组之前用了一款带预测补偿的滤波算法初衷是既要平滑噪声又要快速跟踪真实变化。实验室里确实测过信号在正弦波、阶跃、随机噪声三种典型输入下表现都很好。但到了现场毛刺不是“噪声”而是“故障”——它并不符合算法对噪声分布的任何假设。算法把跳变当成“真实信号的大幅变化”进行跟踪于是滤波输出跟着毛刺一起跑再叠加后续的判断逻辑就产生了大量误报。这个案例的教训不是算法有问题而是我们把它放错了位置。算法的前提是“输入基本靠谱只需要滤掉小幅噪声”。但工业现场的数据在进入算法之前可能已经突破了所有前提数值变成NaN、直接跳到量程之外、连续掉线、时间戳错乱。这些场景任何基于统计假设的平滑算法都束手无策。所以我现在做任何数据处理第一道工序永远是“数据有效性检查”而不是“滤波”。1.2 “最优解”与“可接受解”两套价值体系学术界处理数据追求的是某个准则下的最优比如最小均方误差、最大似然估计。这些方法都有一个隐含前提数据基本可靠噪声服从某种已知分布计算资源相对充足失败了大不了重跑一次。工业现场完全不满足这些前提。数据可能是坏的通信可能是断的算力是固定的更关键的是——误动作可能导致设备损坏或者安全事故。用开车来类比学术优化追求的是“平均车速最快”工业追求的是“任何路况下都不翻车”。你可以把平均速度做得很高但山路、雨雪、爆胎这些情况一旦出现一次翻车就全完了。我把这两套体系做了个简单对照维度学术数据处理工业软件数据处理数据环境相对干净分布可假设脏、乱、缺、错都可能算力资源充足、可扩展受限、固定周期失败代价重新跑一次停机、安全事故评价指标RMSE、MAE等精度指标可用率、误报率、漏报率、平均无故障时间核心诉求最优解恶劣环境下仍可控这个对照不是否定学术方法的价值而是提醒我们在工业项目里评价一个算法好不好看的不是实验室指标而是它在“最坏情况”下的行为。你把正常工况下的误差缩小1%远不如把极端工况下的行为做对。1.3 把目标拆成三个词不炸、不误报、不失控这三个词看似简单其实是对工业软件数据处理目标的完整概括不炸系统在数据异常、通信异常、资源紧张时不死机、不崩溃、不出现内存溢出或任务超时始终保持可用。不误报正常工况下不产生错误报警不让真实的故障被海量无效报警淹没维护操作员对系统的信任。不失控即使数据失效或设备异常系统也能进入安全、可预期的状态并让操作员有办法干预。三者的优先级有先后。不炸是地基地基没了什么都不用谈。不误报和不失控共同保障“安全且可信”但两者有时会发生冲突为了防误报而增加确认延时可能拖累故障响应速度为了快速动作而减少确认又可能误跳。这个张力后面章节会反复遇到。2. “不炸”的地基原始数据进入系统前的那道闸门2.1 模拟量限幅与跳变抑制先把物理世界的不讲理挡在外面工业现场的数据进入系统后第一个动作不应该是滤波而是一组“物理合理性”检查。原因很简单滤波解决的是“信号在合理范围内的小幅抖动”而现实经常出现的是“信号在合理范围外的大幅跳变”。我的做法分三步量程检查、变化率检查、连续确认。量程检查最直观数值超出传感器量程连“超量程”的这种数据都算无效。有些变送器在断线或故障时会输出0mA或超过20mA对应数值可能低于量程下限或高于上限。我会在量程上下各留一个较小的余量作为超量程判定区。变化率检查是筛选“物理不可能”的跳变。比如一个温度传感器量程0到200度工艺上温度每秒最多上升5度如果采样周期是100ms那么相邻两个有效值之间的差值就不应该超过0.5度。一旦差值远大于这个数要么是传感器坏了要么是线缆干扰要么是信号被污染。连续确认是为了区分“单次干扰”和“真实突变”单次跳变大概率是干扰连续N个周期都跳变可能是真实的工艺突变也可能是传感器彻底坏了。两种情况都不该静默接受至少要在日志里记一笔甚至触发告警。下面是我常用的伪代码逻辑function checkRawValue(raw, lastGood, dt): # 第一步数值合法性 if not isFinite(raw): invalidCount return INVALID if raw RANGE_MIN - OVERSHOOT or raw RANGE_MAX OVERSHOOT: invalidCount return INVALID # 第二步变化率合理性 maxDelta MAX_PHYSICAL_RATE * dt if abs(raw - lastGood) maxDelta: jumpCount if jumpCount REPEAT_THRESHOLD: return INVALID_LIKELY_INTERFERENCE else: # 连续多次大幅跳变可能是真实突变或传感器故障 sensorFaultFlag true return SUSPICIOUS_VALID else: jumpCount 0 return VALID这段逻辑的关键点在于跳变不是被直接拒绝而是被标记为“可疑”。因为有些工况下真实信号就是会突变比如阀门突然打开、管道泄漏导致压力骤降。你要做的是让后续逻辑知道“这个数据我不是很有信心”而不是武断丢弃。2.2 NaN、Inf、除零浮点世界的魔鬼细节如果说量程和变化率是“宏观检查”那么浮点特殊值就是“微观地雷”。NaN是传染性的一个NaN进入平均值计算整个窗口的结果都会变成NaNNaN进入比较判断所有比较都返回falseNaN进了PID运算输出可能直接失控。更麻烦的是NaN不一定来自通信软件自身的运算也能产生。比如分母极小的除法得到Inf或者两个Inf相减得到NaN。很多项目在实验室没出问题是因为数据源干净一到现场传感器量程配置错误、某个参数除出来变成Inf问题就爆出来了。我的建议是设置一道“数据标准化门”。所有外部数据进入系统后统一走一个入口函数强制做有限性检查if (!isfinite(raw)) { // 记日志来源、时间戳、原始位串 // 返回值判定为无效 }值得注意的细节C语言里判断NaN可以用raw ! raw因为NaN与任意值包括自身比较都不相等。但用isfinite更稳妥它能同时处理NaN和Inf。很多老工程师在代码评审时专门看有没有“裸奔”的浮点值——凡是外部传入的浮点数入口必须过一遍这道检查。还有一个容易被忽视的是整数溢出。比如用32位毫秒计数器计算时间差两个时间戳相减时如果直接按有符号整数处理计数器回绕后可能算出负的间隔。这种问题不复杂但很隐蔽隐蔽到日志里看着是正常数值实际已经完全错误。2.3 时序完整性与时间戳纪律数据可以晚但不能错乱通信链路不稳定时数据会晚到、丢包、乱序。很多数据处理逻辑默认“数据按顺序到达、周期恒定”这个假设在现场根本不成立。我一直在强调一条纪律每条数据必须携带两个时间——数据产生时间戳和系统接收时间戳。控制运算以接收时刻为时间基准数据新鲜度判断以产生时刻为依据。两者分开才能准确判断“这个数据到底多老了”。处理乱序时如果用了滑动窗口或平均值滤波窗口内的数据必须按产生时间戳排序实在排不了就把超过一个周期的数据当作缺口处理而不是当作有效样点塞进窗口。否则一个迟到的旧数据会把窗口里的平均值拉偏输出就会出现莫名其妙的毛刺。同时所有接收缓冲队列必须有界。队列无限增长会拖垮内存最终拖垮整个进程。超过最大长度的数据怎么处理可以商榷——丢弃最旧、丢弃最新都行但一定要丢弃并且要计数、上报告警。2.4 执行资源余量算法再好也不能吃掉看门狗的口粮实时系统里算法做不做得漂亮是其次能不能在规定周期内跑完才是生死线。你在开发机上跑得飞快不代表它在老旧控制器上也跑得动。这里要引入一个概念最坏执行时间WCET预算。评估算法占用时必须按最坏情况估计不能按平均情况。我的习惯是把任务负载率控制在60%以下。留出的余量不是浪费而是应对通信洪峰、报警风暴、故障处理这些突发场景。你永远不知道哪个瞬间会有100个测点同时上报异常但如果CPU已经被正常负载吃掉90%那这个瞬间系统大概率就“炸”了。内存方面工业控制器上尽量避免运行期频繁动态分配。环形缓冲、静态数组、内存池是更常规的选择。看门狗也不是万能的它能防“逻辑死锁”但恢复不了物理世界。所以看门狗只能作为最后一道网不能把安全希望全押在它身上。3. “不误报”的判定报警与状态确认为什么宁可迟钝不可机灵3.1 报警抖动是信任杀手迟滞死区不是可有可无报警系统最大的敌人不是漏报而是“狼来了”。液位在设定值附近波动时每次越过阈值都报警、回到阈值内又消除一分钟能响几十次。要不了多久操作员就会把报警音关掉或者在心理上彻底无视它真正的故障来了反而没人反应。解决报警抖动的经典手段是迟滞死区也就是让“触发报警的电平”和“恢复正常的电平”不在同一个点上。比如高报阈值是90可以设置恢复阈值为88。数值升到90以上报警之后必须回落到88以下才解除报警。参数含义经验考虑报警阈值触发报警的边界值由工艺要求确定恢复阈值报警解除的边界值通常取阈值减去一个回滞量回滞量触发与恢复之差建议取正常噪声波动范围的2到4倍有人担心死区设置太大会掩盖真实故障这个担心有道理但要分清“报警层”和“联锁层”。报警层的防抖可以大胆些它的目的是提示联锁层要单独设计必须更快、更稳。两个层级共用一套防抖参数是最常见的错误。3.2 延时确认与计数判稳给报警装一道“双确认”门槛迟滞死区解决的是临界波动延时确认解决的是瞬时脉冲。现场经常出现这样的数据某个值在极短时间内冲到阈值以上然后又立刻回落。如果不做处理系统就会报一次假警。延时确认的机制很简单不是一超阈值就报警而是“持续超阈值达到一定时间”才确认报警。我一般用计数方式实现每扫描一个周期超阈值就加一未超就减一计数达到N时才输出报警信号。这里的“减一而不是清零”是为了避免临界点上的反复抖动造成计数反复清零。伪代码大致是这样alarmCount 0 ALARM_CONFIRM 3 # 连续3个扫描周期确认 every scan: if value threshold: if alarmCount ALARM_CONFIRM: alarmCount else: outputAlarm true else: if alarmCount 0: alarmCount-- else: outputAlarm false这个“计数降级而不是清零”的思路是现场抗脉冲报警的关键。但要记住延时确认必须应用于“报警提示层”绝不能用于安全联锁层。联锁逻辑必须宁快勿慢哪怕是冒一点误动作的风险也不能让真故障拖到不可收拾。3.3 变化率比绝对值更会“说谎”跳变与缓变的区别对待有些故障绝对值还没超限变化率已经暴露了问题。轴承振动、流量突降、压力骤变都属于这一类。只看绝对阈值等触发报警时故障已经发展得很严重了。但变化率报警本身有个数学陷阱一阶差分会放大高频噪声。原始信号里只要有微小的抖动差分出来可能就是很大的尖峰。直接用“相邻两点差值”来判断变化率会给报警系统引入大量误报。我的经验是用移动窗口内的直线拟合斜率或者先对信号做一阶低通滤波再求差分。窗口越长抗噪越好但反应越慢。这个取舍要针对具体物理量来做物理量特征建议时间窗口说明慢变过程量温度、液位数秒到数十秒噪声小变化慢快变过程量流量、压力几百毫秒到数秒噪声中等振动、冲击类信号几十到几百毫秒噪声大必须配合带通或拟合实际项目中我见过一个泵的振动信号运行正常时变化率噪声在0.1mm/s²以内。某次内部卡涩振动在几十秒内从1mm/s涨到3mm/s绝对值距离5mm/s的超限阈值还早但变化率已经异常。变化率报警帮我们提前了十几分钟发现故障。这就是“绝对值变化率”双通道报警的价值。3.4 冗余表决一个传感器说了不算三个传感器也别乱信多传感器冗余并不是“三个里有两个一致就信”那么简单。假设有三个液位计其中有一个被淤泥堵了读数固定在某个值不再变化。另外两个读数是正常的表决结果是2:1大多数获胜看起来没问题。但如果另外两个正好都受到同一股干扰源的影响读数一起偏了2:1的表决就会把错误结果当成正确的来用。所以冗余表决必须和一致性检查、卡住检测配合使用。一致性检查是指多个测点的读数偏差在合理范围内卡住检测是指数值长时间不变而关联变量在变化。任何被判定为“可疑”的测点都应该被隔离出表决组不能参与投票。表决之后的处理也很有讲究。2oo3表决通过后我通常取中间值而不是平均值因为平均值会被一个极端值拉偏。剔除离群点后用中位数或者基于一致样本的平均值会更可靠。还需要记录“表决组健康度”今天是否有测点被隔离、隔离了几次、持续多久。这些信息对运维很有价值它告诉你“冗余”到底还剩多少。4. “不失控”的兜底数据失效之后系统到底该怎么活4.1 分级响应把故障按照危重程度排队处理故障不一定要“停车跳闸”也不能都等着“自动恢复”。更好的方式是把故障按严重程度分级每一级规定明确的系统行为让操作员清楚地知道当前处于什么状态。我的常见分级级别名称典型场景系统行为L1观察单项数据短暂无效记录日志、标记数据质量L2提醒测点掉线超过阈值界面提示、输出保持、尝试切换备用L3干预关键参数失效自动进入安全模式、通知操作员确认L4应急安全联锁条件成立直接触发联锁动作、停止危险工况设计原则是越往后动作越不可逆判定条件就越要“多源确认”。L4级别的联锁不能因为单个数据的一次瞬时跳变而触发至少要结合趋势、变化率、相关测点一起做决策。4.2 保持旧值还是安全值卡住失效带来的老坑数据失效之后最纠结的问题是输出到底保持旧值还是切到安全值Hold保持最后有效值在很多场景下是合理的因为它能避免输出大幅波动。但这个策略有一个致命弱点如果传感器是“卡住”失效——读数停在某个值不再变化——那么保持旧值就是把错误延续下去而且延续多久都看不出来。举个真实教训某水处理项目里的pH传感器失效输出一直停在7.0而实际药剂的投加已经过量pH早就不在该在的范围。系统因为采用Hold策略始终用7.0这个“旧值”做判断没有触发任何告警。直到后续化验才发现问题。后来我给这套系统加了两个东西卡住检测数值持续不变超过设定时间同时判断相关的工艺变量是否在变化保持时限任何Hold策略都必须有时限——比如最多保持10秒超过后强制切到安全值或进入故障模式。这个思路可以推广到很多场景保持旧值不是不可以但必须让它“过期”。安全值也不是拍脑袋定的。安全值的选取一定要从设备安全状态反推阀门关到位是安全还是保持当前位置是安全风机降速到某个转速是安全还是直接停机是安全不同设备、不同工艺答案完全不同。4.3 手动/自动切换与输出平滑别把切换做成一次事故数据失效后的系统行为最终都要落到执行机构上。手动切自动、自动切手动、主备控制器切换这些操作如果处理不好会让系统在“最需要稳定”的时候产生剧烈输出跳变。最经典的坑是手动模式下操作员把输出调到一个值比如50%这时候切换到自动PID的目标输出是80%。如果没有做任何缓冲切换那一瞬间输出直接从50%跳到80%执行机构猛地动一下轻则设备震动重则导致工艺波动。解决方案是输出限速器在输出通道上限制每秒最大变化量。切换的瞬间输出按照限速斜率从当前值逐渐过渡到目标值。冗余控制器的切换也有同样的道理。主备两个控制器要持续同步状态备机的输出要一直跟踪主机的当前输出。切换发生时才能做到“无扰切换”——输出不出现可见的阶跃。如果两个控制器采样不同步切换瞬间可能会有微小偏差再加上输出限速机制就能把切换毛刺限制在可接受范围内。4.4 操作员要被看见数据质量位和诊断信息的可视化我见过太多系统界面上一堆数字在跳动但操作员根本不知道哪些值是真实采集的哪些是降级后的备用值哪些是保持的旧值。拿着错误的地图开车出事故是早晚的事。所以数据输出不能只有数值还必须带一个质量位Quality。至少要有四种状态好、坏、可疑、手工强制。界面上用颜色区分正常绿色、可疑黄色、无效灰色。当系统从主信号切到备用信号或者进入保持/安全值模式时界面上必须明确提示“当前使用的是备用信号”或者“该测点数据已失效”。事件序列记录SOE也很重要。当故障发生时事后追溯需要把“数据失效、报警触发、信号切换、执行动作”这几个事件的时间顺序完整还原出来。没有质量位和SOE你根本说不清是“先有故障再有报警”还是“误报之后导致操作员误判断”。5. 那些“看起来很美”却在现场翻车的实战复盘5.1 卡尔曼滤波模型失配噪声协方差写错之后的连环误报某流量测量项目为了让信号更平滑用了卡尔曼滤波器。仿真阶段一切正常因为我把测量噪声协方差R调得比较小滤波器对测量值的信任度很高跟踪效果相当漂亮。到了现场信号里偶尔出现突发脉冲。按卡尔曼理论如果模型准确它可以自动平衡“预测”和“测量”。但问题恰恰是模型不准确——现场的脉冲噪声根本不是正态白噪声。结果滤波器被脉冲带偏经过几轮迭代后输出出现缓慢的偏移又叠加报警阈值判断产生了连环误报。排查到最后真正的问题其实是“现场没法做正规的系统辨识来校准噪声参数。”这也不是卡尔曼不能用而是它的性能高度依赖模型而模型需要大量现场数据来标定。大多数项目根本没有这个时间和环境。最后我们改成了“限幅一阶低通”的组合参数只有两个一个管跳变幅度一个管平滑系数。误报消失信号也够平滑。这件事的启示不是“卡尔曼不好”而是“在没有现场建模条件的项目里别用依赖精确模型的算法”。5.2 “保持最后有效值”让一台风机烧了风道这个案例我前面提过一半这里把完整链路说清楚。某监测系统用温度传感器监控风机出口温度传感器因为接线松动间歇性掉线。掉线期间数据处理逻辑按照默认策略“保持最后有效值”运行输出停在当时的50度。实际温度在掉线后继续上升很快超过了高温报警阈值但因为输出一直是50度联锁自然没有被触发。风机就这么在超温状态下继续运行最后风道变形损失不小。事故复盘时发现系统里根本没有“数据失效超过多久必须切到安全值”的时限概念也没有“温度读数长期不变但相关量在变化”的卡住检测。后来我们给所有“保持”策略加了三道闸卡住检测、保持时限、失效计数。传感器掉线超过设定秒数即使数值没变也强制标记为无效并按工艺安全需求选择安全值或报警提示。5.3 报警延时设得太大真报警被“消音”了某个团队为了消灭误报把所有报警的确认时间统一设置为30秒。思路是超过30秒才算真报警短时间的波动一律忽略。结果某次管道压力骤升因为是真实故障压力持续超限。理论上30秒后应该报警但系统里还有其他逻辑在叠加延时真正触发时已经过去了四十多秒设备已经受损。虽然最终动作了但错过了最佳响应窗口。复盘结论非常清楚报警“防抖”和联锁“响应”是两个层级不可混用。报警层可以延时确认它的目的是过滤无效干扰联锁层必须以安全响应时间作为硬约束它的目的是在故障发生时第一时间动作。层级的严谨分离是设计工业报警逻辑的第一原则。5.4 冗余切换时的0.5秒毛刺双机冗余系统做主备切换时输出出现了一个0.5%的阶跃。执行机构对这个阶跃反应很敏感阀门瞬间动了一下引发了一次小的工艺波动。表面看0.5%不算大但在高精度控制回路里这个阶跃足以打破稳定。深入排查后问题出在两方面一是备用机虽然一直在运行但它的输出量并没有持续跟踪主机的实际输出切换瞬间两者之间存在差值二是切换逻辑和数据源切换同时发生两个扰动叠加造成了可见的输出跳变。解决方法是标准的三件套持续输出跟踪、切换时刻输出锁定一小段时间、切换后加输出限速。从那以后我在评审任何冗余切换逻辑时都会单独检查“切换瞬间输出是否可能出现阶跃”这一条。6. 把“极端工况全覆盖”变成设计规则的几条经验6.1 先列失效模式清单再选算法很多项目选算法的顺序是反的先看到某个算法很流行或者看起来很高端然后往里套数据。正确的顺序应该是反过来的——先穷举失效模式再决定用什么东西去应对。我的设计流程是这样的把系统里所有可能的失效模式列成清单覆盖传感器断线、供电噪声、通信丢包、数据乱序、CPU过载、内存不足、看门狗超时等。对每一个失效模式定义明确且可验证的预期行为。选择算法前先问这个算法在这些失效模式下表现怎么样最简可用优先。算法每增加一层复杂度就必须明确指出它覆盖了清单里的哪个失效模式。如果没有对应关系这一层复杂度就是风险。这听起来像是降低标准实际上是在做减法。工业系统每多一个复杂环节就多一个出问题的可能。用最简单的逻辑把极端情况都兜住比用复杂的模型去追求“平均情况更优”要可靠得多。6.2 三层防线采集防护、逻辑防护、执行防护把数据处理拆成三层独立的防线每层职责清晰问题也容易定位。采集防护层限幅、死区、断线检测、NaN过滤、时间戳校验。这一层的任务是“不让坏数据进入逻辑层”。逻辑防护层状态机、延时确认、冗余表决、卡住检测、数据质量标记。这一层的任务是“用逻辑判断剔除可疑数据在多个信号之间做决策”。执行防护层安全值、速率限制、手动切换、看门狗监控。这一层的任务是“即使数据和逻辑都不完美执行机构也不能乱动”。三层一旦分开调试和定位问题就变得非常直接。数据异常看采集层报警误报看逻辑层输出跳变看执行层谁的问题一目了然。6.3 自诊断和健康监测机器要学会自己汇报“我可能病了”数据处理的健壮性不能只靠外部的“故障发生后的兜底”还应该在正常运行时持续自省。每个功能模块都要有健康状态指标运行周期、上次执行时间、每次循环的耗时、异常计数。心跳机制是其中最典型的应用。边缘网关要周期性地向SCADA上送心跳包上层系统一旦检测到心跳丢失就应立即将该节点标记为异常不能等到数据不更新了才发现问题。数据新鲜度也是同一个道理每个测点数据都带有“有效期”超过有效期即使数值不变也该视为无效。自诊断的意义是让系统在“真正炸掉之前”先发出呻吟。呻吟可能不准确但总比一声不吭地带病运行要强得多。日志里记录的数据质量、异常计数、卡住标志都是运维和故障分析的宝贵素材。6.4 故障注入测试至少要在测试里逼死系统一次测试不能只测“正常工况下的精度”更重要的是一套故障注入矩阵。我会在每个项目的测试计划里强制加入注入项目验证目标传感器断线、短路不误报、数据标记为坏信号大幅跳变、NaN注入入口拦截生效不污染后续通信丢包、乱序、延迟队列有界时序逻辑正确并发报警风暴系统不超时、不崩溃CPU长时间过载看门狗与降级逻辑正确冗余切换瞬间输出无阶跃故障注入测试的目的不是看系统崩溃得有多难看而是验证设计好的降级路径真的被执行了。很多系统在代码评审阶段看不出问题故障注入一跑就露馅。这比在现场翻车再排查成本低了不知道多少倍。写到这里顺便说些个人体会。刚做这行的时候我也喜欢“炫技”总想着用更高级的模型证明自己。这几年被现场教育过太多次之后反而越来越尊敬那些朴素的规则入口处拦截非法数据、报警前确认几次、失效后按预定路径降级。技术领域没有万能的算法但一套把极端工况全覆盖的简单逻辑可以稳定运行很多年。我现在评审每个新功能都会先问三句话数据如果坏了会怎样算法如果失效了会怎样操作员如果误操作会怎样三个问题都有明确答案代码才允许提交到现场。这篇内容的初衷就是希望后来者少走一点我走过的弯路尤其是不必再为“学术最优解”盲目焦虑——先想清楚系统在最坏情况下怎么活再谈优化也不迟。