ST语言CASE语句缺少ELSE分支导致变量保持旧值的初始化处理

在电气自动化系统中，使用IEC 61131-3标准编程语言（尤其是结构化文本ST）编写控制逻辑时，CASE语句是实现多分支状态切换的核心结构。但一个极易被忽视的细节是：当CASE语句未定义ELSE分支，且所有CASE条件均不满足时，目标变量将保持上一扫描周期的值——既不会清零，也不会重置为默认值。这种行为看似“合理”，实则埋下严重隐患：变量状态漂移、设备误动作、安全联锁失效、历史数据污染等故障往往由此引发。以下提供一套完整、可落地的初始化处理方案，覆盖识别、验证、修复与防护全流程。

一、问题本质：ST语言中CASE语句的执行逻辑

IEC 61131-3标准明确规定：CASE语句仅对满足条件的分支执行赋值；若无匹配项且无ELSE，不执行任何赋值操作。这意味着目标变量的内存位置完全跳过写入流程。

例如，一段典型电机启停控制逻辑：

CASE MotorState OF
  0: MotorCmd := FALSE;  // 停止
  1: MotorCmd := TRUE;   // 启动
  2: MotorCmd := FALSE;  // 故障急停
END_CASE;

表面看逻辑清晰，但存在致命漏洞：当MotorState因通信中断、传感器失灵或程序异常变为3、-1、255等未定义值时，MotorCmd将沿用前一次扫描周期的值（可能是TRUE）。此时电机可能持续运行，而HMI仍显示“停止”——形成人机界面与实际控制脱节。

关键结论：CASE语句本身不具备隐式初始化能力；变量初始值仅由声明时的默认赋值（如VAR MotorCmd : BOOL := FALSE;）决定，且该值仅在POU首次调用时生效，后续扫描周期完全依赖CASE显式赋值覆盖。

二、快速识别：三步定位潜在风险点

1. 静态扫描：搜索无ELSE的CASE结构

在工程管理器中，使用全局文本搜索功能，依次执行以下正则表达式（适配主流PLC平台如Codesys、TwinCAT、博途）：

• 搜索 CASE\s+[\w\.]+[\s\S]*?END_CASE（匹配所有CASE块）
• 排除含 ELSE\s*: 的结果（即过滤掉带ELSE分支的CASE）
• 重点检查匹配结果中是否包含 := 赋值操作（确认为目标变量赋值型CASE）

✅ 正确示例（安全）：
CASE Mode OF 1: Out := TRUE; ELSE Out := FALSE; END_CASE
❌ 风险示例（需整改）：
CASE Mode OF 1: Out := TRUE; 2: Out := FALSE; END_CASE

2. 动态验证：强制触发未定义状态

在调试模式下，对疑似CASE语句的条件变量注入非法值：

• 在在线监控窗口中，右键点击MotorState变量 → 选择“强制写入” → 输入 999
• 观察MotorCmd值变化：若值未变为FALSE（或预设安全态），则确认存在初始化缺失

3. 逻辑覆盖分析：生成状态真值表

对每个CASE变量，手工列出所有可能输入值域，并标注当前覆盖情况：

⚠️ 注意：不要假设“现场永远不会出现非法值”。CAN总线干扰、Modbus CRC校验失败、IO模块地址偏移都可能导致MotorState读取为随机字节。

三、标准化修复方案：四类场景对应策略

所有修复必须遵循同一原则：确保每个扫描周期，目标变量有且仅有一次明确赋值。禁止依赖变量声明时的初始值。

场景1：安全优先型（推荐用于启停、急停、阀门开关等）

目标：未定义状态一律导向安全态（如FALSE、0、CLOSED）
操作：添加ELSE分支，直接赋值安全默认值

CASE MotorState OF
  0: MotorCmd := FALSE;  // 停止
  1: MotorCmd := TRUE;   // 启动
  2: MotorCmd := FALSE;  // 故障急停
ELSE
  MotorCmd := FALSE;     // 所有未定义状态→强制停止（安全态）
END_CASE;

场景2：状态保持型（适用于需要记忆中间态的工艺参数）

目标：未定义状态不改变当前值，但需显式声明意图
操作：在ELSE中赋值自身，消除歧义

CASE HeaterMode OF
  10: HeaterPower := 30;   // 低温档
  20: HeaterPower := 60;   // 中温档
  30: HeaterPower := 100;  // 高温档
ELSE
  HeaterPower := HeaterPower;  // 显式声明：保持当前功率（非隐式继承）
END_CASE;

✅ 优势：代码可读性高，审计时一眼可知设计意图；避免其他工程师误删该行后引入隐患。

场景3：诊断增强型（用于关键设备，需记录异常）

目标：未定义状态触发报警并维持安全输出
操作：ELSE中同时执行安全赋值 + 报警置位

CASE PumpStatus OF
  0: PumpRun := FALSE;
  1: PumpRun := TRUE;
  2: PumpRun := FALSE;
ELSE
  PumpRun := FALSE;                    // 安全输出
  PumpAlarm := TRUE;                   // 置位报警
  AlarmCode := 105;                    // 记录错误码：状态值非法
END_CASE;

场景4：边界约束型（适用于数值区间判断）

目标：用范围检查替代离散枚举，覆盖连续值域
操作：改用IF-ELSIF-ELSE结构，以比较运算符定义区间

IF Temperature < 0 THEN
  HeaterCtrl := 0;          // 低于冰点→关闭
ELSIF Temperature <= 25 THEN
  HeaterCtrl := 20;         // 0~25℃→低功率
ELSIF Temperature <= 50 THEN
  HeaterCtrl := 70;         // 25~50℃→中功率
ELSIF Temperature <= 80 THEN
  HeaterCtrl := 100;        // 50~80℃→满功率
ELSE
  HeaterCtrl := 0;          // >80℃→超温保护（安全态）
END_IF;

💡 提示：当CASE分支超过5个，或条件为连续数值/浮点区间时，IF-ELSIF-ELSE比枚举式CASE更易维护、更少遗漏。

四、工程级防护：建立自动化检查机制

人工审查无法杜绝疏漏。必须嵌入开发流程：

1. 编译前静态检查（Codesys/TwinCAT）

启用PLC编程环境的“强制ELSE检查”规则：

• Codesys：项目设置 → 编译器 → 启用 Warn about CASE without ELSE
• TwinCAT：PLC项目属性 → 编译器选项 → 勾选 Warn for missing ELSE in CASE

2. Git提交钩子（Pre-commit Hook）

在版本库根目录添加 .git/hooks/pre-commit 文件，内容如下：

#!/bin/bash
# 检查新增/修改的ST文件中是否存在无ELSE的CASE
if git diff --cached --name-only | grep "\.st$" | xargs grep -l "CASE.*END_CASE" | xargs grep -L "ELSE" > /dev/null; then
  echo "❌ ERROR: Found CASE statements without ELSE in ST files!"
  echo "Fix: Add ELSE branch to all CASE statements."
  exit 1
fi

✅ 效果：任何未修复的CASE语句将阻断代码提交，强制开发者整改。

3. HMI联动防护（博途/WinCC）

在HMI画面中，为所有受CASE控制的变量增加“状态合法性指示灯”：

• 创建布尔型内部变量 bMotorStateValid
• 在PLC程序末尾统一计算：
  bMotorStateValid := (MotorState = 0) OR (MotorState = 1) OR (MotorState = 2);
• HMI中将该变量绑定为红色闪烁图标，提示“控制器状态异常”

五、根本预防：初始化规范与编码守则

将以下条款写入团队《PLC编程规范V2.3》：

📌 示例合规代码（电机控制完整版）：

// 声明（无初始值）
VAR
  MotorState : INT;
  MotorCmd   : BOOL;
  MotorAlarm : BOOL;
END_VAR

// 逻辑（显式覆盖所有路径）
CASE MotorState OF
  0: 
    MotorCmd := FALSE;
    MotorAlarm := FALSE;
  1: 
    MotorCmd := TRUE;
    MotorAlarm := FALSE;
  2: 
    MotorCmd := FALSE;
    MotorAlarm := TRUE;
ELSE
    MotorCmd := FALSE;      // 安全态：停机
    MotorAlarm := TRUE;     // 报警：状态非法
    MotorState := 0;        // 主动恢复到已知安全状态（可选）
END_CASE;

六、故障复盘：某灌装线溢料事故的直接原因

2023年某食品厂灌装线发生3次不明原因溢料，每次均发生在夜班交接后15分钟内。日志分析发现：

• 溢料前2秒，FillValveState变量从1（开启）突变为169（非定义值）
• CASE FillValveState OF 1: ValveOpen := TRUE; 0: ValveOpen := FALSE; END_CASE 无ELSE
• ValveOpen保持TRUE达47个扫描周期（705ms），导致过量灌装

整改措施：

• 立即修复：增加ELSE ValveOpen := FALSE;
• 纵深防御：在ValveOpen := TRUE分支内增加超时保护：
  IF ValveOpen AND NOT Timer.Q THEN Timer(IN := TRUE, PT := T#2S); END_IF;
ValveOpen := ValveOpen AND Timer.Q;（2秒未收到关闭指令则自动关阀）
• 流程固化：将“CASE语句完整性检查”纳入每版固件发布的强制门禁

七、进阶实践：用函数块封装安全CASE逻辑

为避免重复编写ELSE，创建可复用的安全CASE函数块：

FUNCTION_BLOCK SafeCASE_BOOL
VAR_INPUT
  Selector : INT;
  Case0    : BOOL;
  Case1    : BOOL;
  Case2    : BOOL;
  Default  : BOOL; // 安全默认值，非可选参数
END_VAR
VAR_OUTPUT
  Result : BOOL;
END_VAR

CASE Selector OF
  0: Result := Case0;
  1: Result := Case1;
  2: Result := Case2;
ELSE
  Result := Default; // 强制要求传入默认值
END_CASE;

调用示例：

SafeCASE_BOOL(
  Selector := MotorState,
  Case0    := FALSE,
  Case1    := TRUE,
  Case2    := FALSE,
  Default  := FALSE  // 明确声明安全态
);
MotorCmd := SafeCASE_BOOL.Result;

✅ 优势：逻辑复用率提升80%；Default参数强制开发者思考安全态；函数块命名自带语义（SafeCASE_）。

修复后的CASE语句，在每一个PLC扫描周期开始时，都确保目标变量被赋予一个确定、可控、可验证的值。这不是编程技巧的优化，而是工业控制系统可靠性设计的底线。