AVEVA剑维软件
本文并非讲述数字化交付标准，如CFIHOS、GB/T 51296-2018等，而是重点关注交付标准执行层面的核心——“标准类库”。数字化交付标准类库，是数字化交付项目的最重要基础，也是数据校验的最核心依据。
目前几乎所有交付项目其实都有一套统一规定文件，但是对于“标准类库”的管理，往往停留在系统基础定义和模板的层级上，而数据的校验，往往又是另一张皮，最终导致交付的数据不完全符合标准，所以“标准类库”的管理仍然有待加强，这样才能在系统层级上保证交付质量。
从“交付统一规定”到标准类库管理
数字化交付的本质，是将设计、采购、施工等阶段产生的工程信息，转化为结构化、可追溯、可复用的数据资产。而交付标准（或称交付统一规定）正是这一转化过程的“度量衡”和“通用语言”，是交付项目的基础，其重要性与必要性体现在以下四个方面：
• 统一数据规则，保障数据可用性
数字化交付涉及设计院、供应商、施工单位、业主方等众多参与方，各方的工具软件、数据格式、编码习惯差异巨大。若没有统一的交付标准，交付物将呈现“多源异构、各自表述”的局面——数据虽已交付，却无法被系统有效解析、集成与利用，形成“数字孤岛”。统一规定通过明确数据模型、属性深度、文件格式、命名规则和编码体系，确保所有交付数据“同频同调”，从源头保障数据质量。
• 明确交付边界，避免责任模糊
交付标准清晰界定了“交付什么、交付到什么深度、何时交付、如何验收”，为各参与方提供了可执行、可校验的工作依据。这既是承包商组织生产的基准，也是业主组织审查、验收的标尺，有效避免因交付深度理解不一致导致的返工、扯皮与工期延误。
• 支撑全生命周期数据贯通
智能工厂建设的目标是实现设计、施工、运维各阶段数据的连续传递。只有在交付阶段就将数据按照面向运维的深度和结构组织好，后续的资产管理系统、设备维护系统、模拟操作系统才有可能“接得住、用得上”。交付标准正是打通“设计数据 → 交付数据 → 运维数据”链条的制度保障。
• 沉淀企业数据资产，实现复用增值
严格执行统一标准交付的项目数据，可逐步汇聚为企业级工程数据中心，支撑后续改扩建、检维修、对标分析和知识复用，使一次性交付成本转化为长期数据资产价值。
交付标准的落地，最终要落实到一套可执行、可维护的类库体系上。RDL（Reference Data Library）是交付标准的技术载体，它将标准中规定的对象分类、属性要求、编码规则、计量单位、连接关系等，固化为结构化的参考数据，供各方在设计工具、交付平台中直接调用，实现“标准即数据、执行即合规”。因此，RDL 管理是交付标准管理的核心组成部分。
RDL有多种不同的称呼，在CFIHOS中称为RDL（Reference Data Library），在厂家的产品或者方案里面也被称为Class Library（类库），但是“类库”这个词往往太IT化，非IT专业的人员，尤其是EPC的项目部门或业主方的运营部门往往难以理解，RDL同样如此，所以笔者通常将其称为“数字化交付标准库”或“资产信息管理标准库”。现在越来越多的工程技术人员对于数字化交付有了更深的理解，所以本文中仍然称为“标准类库”。
类库，顾名思义其核心为“类”，我们可以通俗地理解为交付里面的“资产类别”，典型的类定义及关系如下（以CFIHOS中“往复泵”的定义为例）：
图1 - 类及其属性定义、关系定义的整体结构
标准类库不仅是交付或企业资产的数据基础，而且是交付的重要校验依据。这一点，经常被实际项目忽略，或者在实际项目中得不到足够重视，导致交付的质量不理想。
标准类库不仅限于定义和输入到交付系统，还需要尽可能映射到源设计系统，从源头上保证设计的规范化。
标准类库包含的内容
标准类库包括以下几部分内容：
位号继承关系、位号类型的定义
位号继承关系是对位号类型的逐级细分，例如“设备->机械设备类->泵->往复泵”。
设备（equipment）是机械设备类（mechanical equipment class）的父类，机械设备类是泵（pump）的父类，泵是往复泵（reciprocating pump）的父类，反之是子类。
这样划分的目的是更容易管理工厂业务对象，例如，对于泵来说，会有各种类型泵通用的属性，如：“绝缘等级（insulation class）”、“正常操作温度（normal operating temperature）”这些通用的属性会统一定义在“泵（pump）”上。而“往复泵（reciprocating pump）”又会有自己独特的属性，这些独特的属性会单独定义在“往复泵”上，当父类发生更改时，新增加的属性会传递到子类上，而子类新增加的属性则不会影响到父类，同时也便于基于现有的类型增加新的类型，提高位号类型管理的效率。
这种方式和软件编程里的“继承”概念完全一样，都是为了便于管理对象。
如下是CFIHOS中的部分继承关系：
图2 - 类的分解结构
位号类型的定义，包括唯一标识ID、名称、相关标识符、命名模板等。
唯一标识 ID：用来定义位号类型的唯一编号，类似每个人的身份证号一样。
相关标识符：用来对应不同的标准，如在CFIHOS中，“往复泵”的ID号是“CFIHOS-30000862”，在ISO-15926中是“8023”，这样保证了同一个类型，在不同标准之间可以相互映射。
命名模板：可以理解为编码规则，在实际项目中每种具体位号类型都会有特定的编码规则
位号类型的定义如下所示：
图3 - 位号类型的定义
除了位号继承关系和类型定义外，通常还会定义分类法（taxonomy），分类法是类型定义的重要补充。在实际工厂里面，位号分类不可能按照上述的继承关系呈现，否则对于普通用户会难以理解。实际的做法是对类型进行简化和重新归类，归类的方式多种多样，只要方便用户使用即可，比如按照专业、按照重要程度、按照特定用户习惯分类等等。
图4 - 同一大分类下，包含子类型的属性差异对比表（GB/T 51296仪表控制类）
类型定义主要用来确保进入交付系统中的数据，符合标准类型的定义，不能任意增加类型，不符合定义的位号会被筛选出来，并提示给数据提交方。
国外的业主，有的会要求国内EPC在设计的不同阶段提交Tag Register，这其实是一个规范格式的Excel表，其中会有位号和类型列，提交后业主会校验位号的编码规则，以及类型的正确性。
“Register”是“登记、注册”的意思，除了Tag Register，还有Property Register，以及Tag to Tag Register、Tag to Document Register等，这些都是在业主的资产信息系统中对数据注册用的表格，因此会习惯称之为“Register”，刚刚接触国外交付项目的EPC往往在提交这些Register上被反复地要求修改、重新提交，甚至因为在截止期前无法完成而被罚款，原因就是没有注意或者不理解规范性的要求。
类型填写错误和位号不按规范填写，是数字化交付中最常见的错误类型之一。
如果数据提交方希望增加或者修改新的类型，应知会业主或者标准制定方，统一增加或修改现有的类型定义。
属性的定义及约束
交付项目中，每个属性的填写都有一定的规范要求，比如属性的名称要正确，属性的值要有一定的规范，例如是数值型？还是字符型？如果是数值型，取值范围是多少？如果是字符型，是否有枚举列表（即可以填哪些选项）等？这些规范化的要求就是属性的定义和约束。
图5 - 属性的定义
属性的定义，包括唯一标识ID、名称、相关标识符、数据类型、UoM（度量系统）、是否必须、验证类型及规则、最大最小值等。
唯一标识 ID：用来定义属性的唯一编号。
相关标识符：用来对应不同的标准，如在CFIHOS中，“normal operating temperature”的ID号是“CFIHOS-40000514”，在ISO-15926中是“6398”，这样保证了同一个属性，在不同标准之间可以相互映射。
数据类型：定义属性属于数值型还是字符型。
测量类：属于长度、还是温度、压力、流量等，不同的类型有特定的换算系统。
需要UoM：是否需要单位，绝大多数数值型都需要单位。
必须：设定此属性是否必填（Required）、选填（Optional）、最好填写（Preferred）。
验证类型：枚举还是正则表达式等，即使用何种方法验证数据。
验证规则：具体的验证规则，如果是枚举值，则需要提供枚举列表。
最大最小值：取值范围。
属性的填写错误也是交付过程中最常见的错误之一，而且种类多样，例如属性名称填写错误、属性值填写未按枚举列表要求、必填属性没有填写等等。
如果需要的属性值没有定义，数据提交方可以要求业主或者标准定义方统一定义新属性，并和特定的位号类型关联。
类型和属性的关联关系
类型和属性的关联关系，即特定的类型有哪些允许填写的属性。
图6 - 类型和属性的关联关系定义
不同的位号类型会有不同的属性（或者叫类型允许的属性），例如容器和泵的属性肯定是不一样的，即便是泵，离心泵和旋转泵的属性也会不同，这些都是通过类型和属性的关联关系体现的。
国外的业主，通常会要求提交Property Register，其实就是位号所包含各种属性的Excel表格，其中会要求填写各种位号的ID，以及有哪些属性值。
国内的交付项目，一般也会要求按照规范化表格提交位号的属性清单表，然后业主或者交付实施方会对清单表进行各种数据校验。
不按照允许的属性填写数据，也是数字化交付最常遇到的问题之一，例如本来没有要求的属性，却多填了，或者要求的属性没有填写等等。
度量系统的定义
度量系统是为了便于对于数值型数据进行统计，例如对于长度单位，会定义千米（km）、米（m）、厘米（cm）、毫米（mm）等，这样无论数值型属性单位用的是米，还是毫米，都能换算成统一的单位进行数量统计。
度量系统的定义由于比较具有通用性，此处不再赘述。
命名模板的定义
命名模板（Naming template）可以理解为编码规则，对各种位号类型定义编码规则是具体项目中交付标准必须定义的内容。命名模板会包含多个命名元素，包括前缀、后缀、分隔符、数值、字符等等，可以把编码规则非常清晰的定义出来。命名模板不会单独使用，而是绑定在特定的位号类型上。
目前交付项目中经常定义的各种类型的交付规范，往往把编码规则定义在纸面上，虽然很明确，但是在实际项目中，各种不按规则编码的情况仍然很多，据笔者多个项目的校验统计，大概能占到错误总数的40%以上。使用RDL的方式把编码规则具象化，有利于后期对于数据的质量校验，其他的标准项也是一样。
生命周期定义
生命周期用来标识数据的成熟度，例如在交付过程中，标识不同阶段的数据。或者在数据的审核过程中，标记“工作中”，还是“已批准”。还有一种应用是在运营过程中，用来标记“工作”状态，还是“停机”状态，以便于和CMMS（计算机化设备维护管理系统）中的状态同步。
各种生命周期状态或者成熟度状态，应允许客户自行扩展定义，以便于适应不同的应用场景。
枚举类型定义
枚举类型定义是属性约束的一种形式，即只能选取枚举列表中的值，其他值是不被允许的。
枚举类型通常绑定在属性上应用。在交付标准中，属性能填写哪些值，应事先定义清楚，以免在交付过程中填写得不规范，导致数据反复修改提交。
类库的使用和维护
对于EPC来说，面向不同行业、不同国家或地区的客户，有可能执行多套交付标准，而对于同一行业的客户，有可能执行的标准也不一样，面对众多标准，如果没有体系化的维护管理方式，很容易造成项目执行的越多，标准维护的越复杂和混乱。
对于业主/运营方（Owner Operator，OO）来说，通常情况下尽可能使用同一标准，尽量避免多个项目采用不同标准，多个标准意味着后期维护的困难加大，例如对于物料编码，多个编码会导致库存管理困难。
EPC多标准的维护
标准实际上是有层级的，EPC的标准应进行层级化管理，典型的层级如下：
图7 - EPC对于标准类库的维护层级
理论上，企业标准应该采用行业的标准并进行扩展，在某些项目上，再针对业主的需求或者实际情况进行扩展，例如增加类型定义，或者细分类型定义等等。项目标准的调整只影响本项目，不会影响其他项目，也不会影响企业标准。而企业标准的调整，一般是通用化的调整，这些调整会被下面的项目继承，这样既方便企业统一管理项目标准，也方便每个项目单独管理自己的标准。而再上层的行业标准，也可能会几年一更新，可以通过导入更新的标准文件对行业标准进行升版，同样会更新企业标准，以及项目标准。需要注意的是，每一次更新，其实都会用版本对标准做记录和升版，保证标准变更的可追溯性，如果发现错误，可以回退回上一版本。类库变更应遵循“申请—影响评估—审批—发布”流程，确保项目侧可控。
项目实践上，目前国内市场上有众多的交付标准，所以EPC可能要维护的标准有很多，除了上面提到的继承自国际上行业的企业标准，还有各工程公司根据自己传统应用而改造的标准，还有国内各行业的标准，所以可能维护的标准会有不少。但是依据上述的办法，仍然可以让企业能对标准做到精准和高效率的维护，当然这也需要管理上的到位才行。
如果在一个项目中，假设业主采用CFIHOS标准，而EPC希望仍然沿用自己的企业标准，那怎么办呢？
这就需要用到我们前面提到的标准映射了。
如下图，是GB/T 51296-2018（假设是企业标准）中对“反应器”的定义，我们在“对应标识符”下，可以映射到CFIHOS对应的“process reactor”，ID为“CFIHOS-30000758”，这样，即便EPC使用自己的标准，也能通过映射，输出符合CFIHOS标准的数据。这也为EPC简化交付标准的管理提供了另一种更灵活的方式，即EPC只维护少量标准，其他均通过映射对应到其他标准上，而不用每一个项目都定义一个新的标准。
图8 - 不同标准之间的映射
交付标准也是业主资产数据管理标准
这里顺便提一下业主（OO）对于标准需要注意的问题。
通常情况下，面向一个行业的OO应该只有一套交付标准，交付标准同时也是企业资产数据管理标准，只需要把这一套标准维护好就可以，要比EPC简单的多。
但是有些业主的不同项目，如果是不同的EPC做的，且在建造过程中，没有意识到统一标准，就会产生两套标准。或者早期的项目，采用传统的交付方式，已经有一套编码体系，而新的项目，采用了另外一套编码体系（包含在交付标准中），也会存在这种情况。
维护多套标准是业主应该极力避免的情况，存在这种情况也从一个角度说明了我们对于交付标准的重视程度还不够，不了解对企业运营产生的影响。OO应该在项目的一开始就提出使用和早期项目一致的标准，或者在交付过程中对标准进行映射，否则交付后再统一会很难。
总结
数字化交付的成败，始于交付标准（统一规定），落于标准类库。交付标准是多方协作的“度量衡”与“通用语言”，而标准类库（RDL）则是这套规定的技术载体和落地工具——它把对象分类、属性约束、编码规则、度量系统等纸面要求固化为系统可执行、可校验的结构化数据，做到“标准即数据、执行即合规”。实践中的问题恰恰在于：规定停留在文件里，类库停留在模板上，校验另成一张皮，导致交付数据质量不理想。
因此，类库管理必须覆盖从定义到维护的全过程：
1) 在内容上，管好位号类型及其继承关系、属性约束、类型与属性的关联、命名模板、度量系统、生命周期与枚举等要素；
2) 在维护上，EPC 应对多标准实行层级化管理（行业标准 → 企业标准 → 项目标准），并善用标准映射以少御多，业主则应始终坚守一套标准，极力避免多套并存。更重要的是，标准类库不应止步于交付系统，而要尽可能映射回源设计系统（如AVEVA E3D等），从源头保证数据规范。
AVEVA AIM系统可以提供全套的标准类库定义、维护、数据校验的工具，不仅能在统一的交付标准上提供内容的定义、数据的校验，也能够帮助EPC和OO维护好交付标准。业主可以在发布交付标准文件时，附带一个导出的类库文件，可以最大程度上量化交付的要求，保证数据的落地执行（例如沙特阿美Aramco、Shell、Azule等）；而对于EPC，可以将此类库文件发给分包商，让各个参与方都能在统一的标准类库上协同工作（例如Wood等）。
唯有如此，才能让交付数据真正成为可贯通全生命周期、可持续增值的企业资产。
点击【阅读原文】，留言进一步咨询
