4. 故障代码标准化设计

设备维修知识库能否长期可用，很大程度上取决于故障代码是否被“设计”过。如果每台设备、每个厂商、每位工程师都按自己的习惯写代码，知识库很快就会退化成一张无法检索、无法统计、无法复用的日志表。故障代码标准化设计的目标，是让同一类故障在不同设备、不同厂商、不同批次之间拥有一致的表达方式，同时保留足够的扩展空间。

一、命名规范：让代码本身可读、可判、可检索

命名规范解决的是“代码长什么样”。推荐采用“分段定长 + 分隔符”的结构，例如：

域-部件-现象-等级
DRV-MOT-OVL-E01
PWR-SUP-UVL-W02
SEN-TMP-OOR-I03

其中域表示系统大类（DRV 驱动、PWR 电源、SEN 传感），部件表示具体对象（MOT 电机、SUP 供电单元、TMP 温度探头），现象表示故障机理（OVL 过载、UVL 欠压、OOR 超范围），等级表示严重度（E 故障、W 警告、I 提示）。命名规范应明确三点：一是字符集只允许大写字母、数字和短横线，避免中文、空格和特殊符号；二是每段长度固定，便于程序解析；三是保留段位含义表，任何新增段位必须登记，不能临时拼写。

命名规范还要规定“禁止项”：禁止用设备编号、日期、工位号作为代码主体，因为这些信息属于实例属性，不属于故障类型；禁止同一现象出现多种拼写，例如 OVL 与 OVERLOAD 不能并存；禁止用等级段表达维修优先级，等级只描述故障对设备功能的影响程度。

二、层级结构：从系统到实例的可展开树

层级结构解决的是“代码之间如何组织”。建议采用四层模型：系统层、子系统层、部件层、故障实例层。前三层由标准化代码定义，第四层由现场记录生成。例如：

L1 系统：DRV 驱动系统
L2 子系统：DRV-MOT 电机驱动
L3 部件：DRV-MOT-ENC 编码器
L4 实例：DRV-MOT-ENC-SIG-LOSS-20240612-001

前三层是“类型树”，用于知识库分类、统计和检索；第四层是“事件记录”，用于追踪具体维修工单。层级结构的关键约束是：父层代码必须是子层代码的前缀，任何跨层跳转都必须通过映射表完成，不能直接拼接。这样，当现场只记录到部件层时，系统仍能向上归集到子系统层进行趋势分析。

三、语义规则：代码不能只“像”，还要“准”

语义规则解决的是“代码到底代表什么”。同一段位在不同系统里可能有不同含义，因此必须为每个段位建立语义表。例如现象段 OVL 只能表示“负载超过额定值导致的保护动作”，不能同时表示“电机堵转”；堵转应使用 STL。等级段 E 表示设备停机或安全功能失效，W 表示可降级运行，I 表示仅记录不触发停机。

语义规则还要处理“同义归一”和“多因一码”两个问题。同义归一是指把“过流”“过载”“电流过大”统一到 OVC 或 OVL，不能混用；多因一码是指一个代码可能对应多个根因，例如 DRV-MOT-OVL-E01 可能由机械卡阻、参数错误或电源缺相引起。此时代码只描述现象，根因通过维修知识库的“原因—措施”关联表补充，不能把根因写进代码主体。

四、版本管理：让标准可演进、可追溯

故障代码标准不是一次定稿就结束。版本管理要回答三个问题：改了什么、为什么改、旧代码怎么办。建议采用“主版本.次版本”两级：主版本变更表示段位结构或语义发生不兼容调整，例如从三段改为四段；次版本变更表示新增现象、新增部件或修正描述，不影响已有解析。

每次变更必须记录变更单，字段包括：变更编号、变更类型、影响段位、影响代码数量、生效日期、旧代码映射关系。旧代码不能直接删除，应保留在历史映射表中，确保三年前的历史工单仍可被检索和统计。版本管理还应规定“冻结期”：在设备大修或产线切换前一个月，不发布不兼容的主版本变更，避免现场记录混乱。

五、跨厂商映射：把异构代码收进同一张网

跨厂商映射是标准化落地中最费力的环节。不同厂商对同一故障可能使用完全不同的编码方式：有的用十六进制故障字，有的用英文缩写，有的用数字区间。映射方法建议分三步走。

第一步，建立“厂商原始码—标准码”对照表。字段至少包括：厂商名称、设备型号、原始代码、原始描述、标准代码、映射置信度、生效版本。例如厂商 A 的 A-0x21 与厂商 B 的 B-OCP 都映射到 DRV-MOT-OVC-E01，置信度分别为高和中等。

第二步，处理“一对多”和“多对一”。一个厂商代码可能对应多个标准码，例如“通信故障”可能细分为超时、校验错、断线；多个厂商代码也可能映射到同一个标准码。此时不能强行一对一，而应保留映射表的多对多关系，并在知识库查询时按置信度和设备型号排序展示。

第三步，设置“待归类”队列。现场遇到无法映射的代码时，先进入待归类队列，由标准化小组在约定周期内确认并回写映射表。回写后，该代码自动获得标准码，后续同类记录即可直接归集。这样，映射表会随着维修实践不断增厚，而不是一次性写完就僵化。

最后需要强调，故障代码标准化不是追求“代码好看”，而是让知识库具备可统计、可检索、可迁移的能力。命名规范保证机器能解析，层级结构保证数据能归集，语义规则保证含义不漂移，版本管理保证标准能演进，跨厂商映射保证异构设备能进入同一张知识网。五者缺一，标准化就会停留在纸面。