简介面向工业自动化系统集成与标准化领域的国际标准IEC 81346-2-2019第2部分类对象和代码的分类提供完整PDF原文适合自动化工程师、系统集成人员、电气设计师及标准化从业者使用。该标准在IEC 81346系列框架下规定了类对象设备、机器、过程、系统的分类体系与代码编制方法定义了字母数字代码的基本结构与命名规则用于统一工程文档、原理图标识、数据交换中的对象标识从而降低系统集成复杂度、提升维护效率。压缩包内共1个文件为PDF格式整体大小约26.44MB内容清晰完整便于检索、阅读、打印及内部培训。标准全文已有317人学习/下载既可作为日常研发中的参考依据也适合项目评审、标准宣贯及自动化专业教学场景使用。1. 拿到IEC 81346-2:2019之前先把它想成一套对象分类法搜索“IEC 81346-2-2019第2部分类对象和代码的分类.pdf”搜出来的大多是存档链接但真正让工程师头疼的不是这份PDF放在哪个文件夹而是图纸里那些“K01”“-B02”“X10”到底按什么规则定出来的。这套标识体系叫参考命名reference designationIEC 81346-2:2019就是它的“代码字典”。它把工程对象按功能、位置、产品三个维度分成不同类对象再给每个类分配可机读的代码。流程工业的仪表回路、离散制造的电气柜、风电场的SCADA点表都要靠这套体系保证“图纸、实物、台账”编号一致。适用人群是所有画图纸、做BOM、建资产台账的工程师和软件开发者先理解类对象的分类逻辑再把它变成能落地执行的编码规则和校验手段。2. 先立住模型类对象、方面与参考命名的解析规则2.1 类对象是“对象的类别”不是编程语言里的类看到“类对象”三个字学过Python和Java的人会下意识想到面向对象里的class object。我一般会先做一个翻译上的校正IEC 81346-2:2019里的“类对象”对应英文class of objects直译过来容易产生歧义准确的理解是“对象的类别”。它讨论的不是内存里的数据结构而是把一组具有共同特性的工程对象归成一个类别。标准定义类对象的目的是让编码人不用记成千上万个设备型号只根据对象在系统里承担的抽象角色来给标识。比如B类对象是“把物理量转成信号的对象”压力变送器、热电阻、接近开关都属于这一类F类是“以保护为主要任务的对象”熔断器、热继电器、保护型断路器都往这里放。设计评审时看到B就知道是测量环节看到K就知道信号经过处理维护人员不翻点表也能顺着命名走通回路。要再往下分就要把“对象个体”和“对象类”分开看。3号压力变送器是实例写全称可以叫“B01-03”而B是它所属的类代码类用大写字母表达实例用“类代码加序号”表达。这样分离之后资产台账的“型号”字段和参考命名是两回事换厂家、换型号只要功能角色不变代码就不变。这一条是整套体系的根基很多项目编码混乱起点就在把“设备型号”和“对象类别”混在一起。2.2 三个方面决定代码放在哪一段用类代码不是孤立使用的。一个对象在参考命名里出现时必须先带“方面aspect”信息。IEC 81346-1把对象的观察视角分成三大方面而每一方面用独立的前缀引导方面前缀方面名称语义典型应用功能方面对象承担的“功能角色”控制回路、逻辑节点、功能组位置方面对象所在的“物理空间”柜体、房间、区域、桥架段-产品方面对象对应的“具体产品实体”安装的元器件、采购的设备三个方面回答的问题完全不同。功能方面回答“它是干什么的”位置方面回答“它在哪”产品方面回答“它到底是什么型号的实物”。查看一条参考命名时先看前缀再读后面的类代码语义才不会偏。位置方面适合在现场挂牌产品方面适合做采购清单功能方面适合做控制逻辑图不同专业各取一段互不干扰。这三者可单独使用也可嵌套。嵌套的规则在2.3节用一条真实命名串起来讲。2.3 拆解一条参考命名一条典型的参考命名长得像“O01-K01”。拆开看前缀“”表示整条命名从功能方面开始O01是项目自定义的系统单元多数项目用它代表一套泵组、一面控制柜或一条工艺线后面的“-”表示转入下一层对象K01则是IEC 81346-2里的类代码加序号K代表“信号处理类对象”01是它在该单元内的序号。“O01”这一段值得多说一句。如果完全按标准走系统单元本身也应该给出类代码和序号但工程上更常见的做法是项目先定义自己的单元编码表把O01这种代号在项目命名规则里登记清楚。标准允许这种受控的项目扩展前提是编码规则文档必须写明哪些段位属于标准类代码哪些段位属于项目自定义。否则三年后接手的工程师会把O当成某个标准类来猜。从右往左读这条命名可以得到一条路径先知道对象是K类再知道它挂在O01功能单元下。这个顺序对维护人员很重要现场故障处理时标识串本身就是一张迷你路由表。类代码的正确位置是“紧随方面前缀之后”而绝非随手写在描述字段里。2.4 同一台设备可以有多个编码一个物理泵可以同时拥有三条合法参考命名功能方面是“O01-K01”代表它在驱动控制回路里是信号处理对象产品方面是“-M01”代表采购安装的那台电机位置方面是“R02-M01”代表它装在2号房间的特定基础上。同一对象多个标识不是错误而是模型本身支持的视角拆分。数据库设计时要把它当多对多关系处理而不是强行压成一个字段。台账主标识的选定有惯例日常维护以功能方面为主采购以产品方面为主现场巡检以位置方面为主。多套标识之间建立交叉引用表图纸上标注哪一个方面取决于这张图要支撑什么业务。理解这层关系之后再看第三部分那张代码表才算真正读得懂。3. 表1怎么读代码聚类逻辑与一个能直接用的速查表3.1 先把表1的文件结构看清楚IEC 81346-2:2019正文的核心就是一张分类表通常以Table形式出现在标准前部。拿到PDF后不要先翻附录直接找代码表左列是代码右列是类对象名称和定义部分版本还带典型对象示例。2019版在上一版基础上重排了类目分组代码形式仍然是单字母加大写双字母双字母用于在大类下细分。读表时要注意代码和类对象不是“元件字典”而是“角色字典”。同一行里写的是“把物理量转换为可处理信号的对象”而不是“压力变送器”这个具体型号。理解这个区别后再往项目里映射才不会把代码表用成选型手册。标准文本里的定义是判定依据工程中遇到描述模糊的对象时以文字定义为准不以常见产品名称为准。3.2 按功能角色分类是唯一的编码原则接触器是最典型的例子。一个接触器拆开看线圈接入控制回路接收继电器或PLC的输出信号并放大驱动按81346-2的类定义编码为K类“信号处理对象”而它的主触点接入功率回路执行电路接通和分断编码为Q类“功率回路通断对象”。同一个物理元件因为承担两种不同功能角色在图纸上会有两个不同类代码。反过来看不同元件也可能归入同一类继电器线圈和PLC输出模块都归K类因为它们都做信号处理塑壳断路器和接触器主触点都可能归Q类只要它们在回路里承担的是“通断”角色。按元件名称编码的人会问“断路器为什么不全是F”答案是只在故障时动作的纯保护器件才用F正常操作也靠它分合闸的断路器主要角色是Q类。语义边界一旦建立图纸评审时就能抓出大量模板默认值导致的错码。3.3 一个能直接开始用的类代码速查表下面这张表按工程常见用法整理覆盖电气和仪表专业八成以上场景。正式做公司级规范时还得以标准原文的表1为准。代码类对象识别要点工程常见对象B把物理量转换为可处理信号输入物理量输出电信号压力变送器、PT100、接近开关F以保护为主要任务故障状态下动作保护设备熔断器、热继电器、保护型断路器G产生电能或信号输出功率或信号源发电机、信号发生器、UPS部分K处理信号并输出动作信号有逻辑、放大、延时功能继电器、接触器线圈、PLC通道M提供机械动力输出旋转或直线机械能电机、电动头Q在功率回路中通断执行电路合分断路器主触头、接触器主触点、隔离开关S接收人工操作输入来自人的动作按钮、选择开关、急停T变换电能形式电压、电流、频率变换变压器、变流器X实现电气连接连接与转接端子排、插头、接线盒Y把信号转为机械动作输出位移或力电磁阀、电动执行器提示上表只是工程上手摘录个别代码的正式定义和边界以官方标准为准。做跨组织协作时必须统一使用同一版本的表1。使用这张表时不建议一次选到双字母先用单字母把对象归入大类项目运行一段时间后再根据痛点决定是否细分。代码的连续性和稳定性比代码字面的“精确度”更重要。3.4 练手一台供水机组怎么分码假设有一台由变频器驱动的水泵机组控制柜里有断路器、接触器、中间继电器、压力变送器、就地按钮和端子排。按功能方面“O01”统一挂接清单可以这样分对象承担的功能角色类代码参考命名示例压力变送器把管网压力转成标准信号BO01-B01中间继电器处理启停逻辑信号KO01-K01接触器线圈接收信号并驱动主触点KO01-K02接触器主触点通断电机主回路QO01-Q01断路器保护为主短路和过载保护FO01-F01电机输出机械能带动泵MO01-M01就地按钮接收人工启停操作SO01-S01端子排柜内外信号连接XO01-X01这组示例里接触器出现了两次一次是K02、一次是Q01恰好演示了“按功能角色分类”和“按元件分类”的结果差异。变频器本身属于哪一类在项目里常有争议常见做法是看它在回路里承担的角色如果主要做调速变换按T类处理如果把它当作一个可编程逻辑装置也有项目按K类扩展。关键是项目命名规则里必须写清楚不允许同一图纸里出现两种默认。3.5 代码不够用的时候怎么扩标准类的粒度不能满足项目特殊需求时常见做法是使用双字母扩展。例如K类下定义KA表示“模拟量信号处理”、KB表示“数字量信号处理”只要在项目文档中登记说明就不会破坏标准体系。我一般会在编码规则文档里增加一个“自定义子类登记表”记录代码、类名、定义、适用范围和生效日期。要避免的做法是直接发明一个单字母代码覆盖标准语义比如把“网关”编成N类而标准里没有N定义。这样短期看很灵活长期看会让全厂标识系统失去“可机读”的基础。旧图迁移时也一样单体字母代码尽量保持稳定只对新增对象启用新类能大幅降低改造工作量。4. 落地从对象清单到可校验的类代码字典4.1 先建字典再建清单项目落地第一个动作不是画图而是建两张表一张是类代码字典一张是对象清单。类代码字典来自IEC 81346-2:2019的代码表加上项目自定义扩展对象清单是每个需要编码的对象实例。类代码字典我习惯用CSV维护列结构至少包含五列code表示类代码class_name表示类对象名称allowed_aspect表示允许出现的方面前缀description表示标准定义source表示代码来源标准或项目扩展。对象清单则包含object_id、parent_id、aspect、class_code、serial、description。两张表分开放代码通过脚本校验引用关系不允许在图纸工具里直接手工输入任意字符串。4.2 用Python脚本自动校验对象清单下面这个脚本读取两张CSV检查四个方面类代码是否存在、方面是否对该类合法、同一父节点下的序号是否重复、CSV编码是否为UTF-8可读。逻辑不复杂但能挡住大部分人为错误。import csv import sys # class_dict.csv 结构code,class_name,allowed_aspect,source,description # allowed_aspect 用竖线分隔例如 ||- 表示三类方面都允许 DICT_FILE class_dict.csv OBJ_FILE objects.csv def load_class_dict(path): d {} with open(path, encodingutf-8-sig) as f: for row in csv.DictReader(f): d[row[code].strip().upper()] row return d def validate_object(row, class_dict): code row[class_code].strip().upper() aspect row[aspect].strip() parent row.get(parent_id, ).strip() serial row.get(serial, ).strip() if code not in class_dict: return f{row[object_id]}: 未知类代码 {code} allow set( s.strip() for s in class_dict[code][allowed_aspect].split(|) ) if aspect not in allow: return ( f{row[object_id]}: 类 {code} 不允许出现在 f方面 {aspect}允许值为 {allow} ) if not serial.isdigit(): return f{row[object_id]}: 序号不是数字 {serial} return None def main(): class_dict load_class_dict(DICT_FILE) seen set() errors [] with open(OBJ_FILE, encodingutf-8-sig) as f: for row in csv.DictReader(f): err validate_object(row, class_dict) if err: errors.append(err) continue key ( row[aspect].strip(), row.get(parent_id, ).strip(), row[class_code].strip().upper(), row[serial].strip().zfill(2), ) if key in seen: errors.append( f{row[object_id]}: 重复命名 f{row[aspect]}{row.get(parent_id, )} f-{row[class_code]}{row[serial]} ) seen.add(key) if errors: print(\n.join(errors)) sys.exit(1) print(f校验通过共 {len(seen)} 个唯一命名) if __name__ __main__: main()脚本里几个参数需要说明编码用utf-8-sig是为了兼容Excel另存的CSV它会自动去掉文件头BOMallowed_aspect字段来自字典表如果某个类只允许功能方面就填“”校验时输入“”会直接报错重复命名检查的粒度是“方面父对象类代码序号”也就是说每个父对象下的同类序号只从01开始排而不是全厂全局流水号。这个脚本跑通之后可以把它挂到图纸导出流程或PDM系统的提交钩子里每次发布前强制跑一遍。错误信息直接返回给设计人员替代人工翻图核对。4.3 脚本查不出来的两类问题脚本只能保证“引用正确”和“命名唯一”保证不了“语义正确”。最常见的语义错误是选错类把供给电机主回路的断路器编成F而实际上它在正常运行中承担频繁分合闸应当编Q。这种错误要靠在设计评审里增加一道抽检工序每次随机抽五个编码反查设计者的功能描述是否与类定义一致。另一类查不出的是“跨方面冲突”。同一台电机可能出现在功能清单、位置清单和采购清单里三个清单如果分别录入很容易出现类代码不一致。常见做法是以功能方面清单为基准位置和产品方面通过交叉引用表关联而不是各自独立编码。交叉引用表维护在数据库里脚本只负责在生成参考命名时检查主标识是否存在。4.4 老图纸从2009版迁到2019版存量项目升级到2019版时先不要急着改所有编码。实际经验是单字母代码的语义基本稳定改动集中在双字母扩展和部分类定义的文字表述上。迁移步骤通常是先导出现有对象清单再建立新旧代码映射表然后批量替换最后按3.4节的方式做语义抽检。只有两种情况值得动存量数据一是原编码明显违反功能角色分类原则二是公司要上资产管理平台需要把图纸编码和CMMS台账做严格的机器对照。这两种情况都建议在新版本数据冻结后再改图纸避免图纸和数据库两边同时变动造成对不上。迁移过程中输出的“旧编码-新编码-变更原因-变更日期”四列记录本身就是后期审计的证据链。5. 用一条自查链快速验证设计编码是否合规验证编码合规性不用等第三方审查设计阶段就能用几个轻量命令完成第一轮筛查。先把对象清单整理成CSV第一列是class_code用awk统计各类代码出现次数观察分布是否符合系统特征。awk -F, NR1 {print $3} objects.csv | sort | uniq -c | sort -rn如果一台装置里K类和Q类占比异常高F类微乎其微有两种可能要么设计人员把所有带线圈的元件都编成了K要么把本该用F保护的回路用Q代替。分布表不能直接判断对错但能快速定位需要人工复查的图号。接着用SQL检查“字典里不存在的类代码”。对象清单入库后执行一条左连接查询就能把所有非法代码抓出来SELECT o.object_id, o.class_code FROM objects o LEFT JOIN class_dict c ON o.class_code c.code WHERE c.code IS NULL;这条查询会返回全部在对象清单里出现、但类代码字典里找不到的记录。和Python脚本的差别在于它直接落到数据库适合集成到发布流程的自动检查任务里。跑通这两条命令后再回到图纸做人工语义抽查重点看三类坑按元件名而不是按功能角色选码一个对象只保留一个编码而没有建立多方面的交叉引用项目自定义子类没有在命名规则文档里登记生效日期和适用范围。把这三条连同前面的脚本检查项一起写进设计交付检查表新图纸的编码质量会比只靠人工强得多。本文还有配套的精品资源点击获取