3. 资产生命周期概述

资产全生命周期数据管理(AAS,Asset Administration Shell)的核心思想,是让一台设备、一条产线甚至一座工厂,在从概念设计到报废回收的整个过程中,始终拥有一个可被机器读取、可被跨系统交换的“数字身份”。这个身份不是静态的档案,而是随生命周期演进而不断丰富、变更、沉淀的数据集合。理解各阶段的数据特征与管理需求,是设计 AAS 子模型、规划数据接口与治理策略的前提。

核心原理:资产生命周期数据具有“阶段递进、粒度变化、责任转移、价值衰减”四个特征。设计阶段数据以模型和参数为主,制造阶段以工艺和批次为主,运维阶段以状态和事件为主,退役阶段以处置和合规为主。AAS 通过统一的元模型与子模型机制,把这些异构数据挂接到同一个资产标识下,实现跨阶段的可追溯与可交换。

一、四个阶段的数据特征

设计阶段的数据以“定义型”为主,包括 CAD 模型、材料清单、电气原理图、功能规格、仿真参数等。这些数据的特点是结构化程度高、版本迭代频繁、变更影响面大。一个设计参数的修改,可能同时影响制造工艺和运维备件策略。因此设计阶段的管理需求是版本可控、变更可追溯、与需求可关联。

制造阶段的数据以“过程型”为主,包括工单、工艺路线、设备参数、检验记录、批次号、序列号等。这一阶段数据量迅速膨胀,且与物理实体一一绑定。管理需求是批次可追溯、质量数据可关联、序列号与资产标识可映射。制造阶段往往是 AAS 实例真正“落地”的起点,因为此时资产获得了唯一序列号。

运维阶段的数据以“状态型”和“事件型”为主,包括运行参数、振动温度、报警记录、维修工单、备件更换、点检报告等。数据具有时序性、高频性和多源异构性。管理需求是实时采集、状态可判断、维修历史可追溯、与设计参数可对比。运维阶段是数据价值密度最高、也是管理难度最大的阶段。

退役阶段的数据以“处置型”为主,包括报废审批、拆解记录、危废处理、回收材料重量、合规证明等。管理需求是处置合规、环保可审计、数据可归档、资产标识可注销。这一阶段常被忽视,但在法规日益严格的今天,退役数据的完整性直接影响企业的合规风险。

资产生命周期四阶段数据特征与管理需求 ① 设计阶段 数据特征 CAD / BOM / 规格书 仿真参数 / 原理图 版本迭代频繁 管理需求 版本可控 变更可追溯 需求可关联 AAS子模型 TechnicalData ② 制造阶段 数据特征 工单 / 工艺路线 检验记录 / 批次号 序列号绑定实体 管理需求 批次可追溯 质量数据关联 序列号映射 AAS子模型 Nameplate ③ 运维阶段 数据特征 运行参数 / 振动温度 报警 / 维修工单 时序高频多源 管理需求 实时采集 状态可判断 维修历史追溯 AAS子模型 OperationalData ④ 退役阶段 数据特征 报废审批 / 拆解记录 危废处理 / 回收重量 合规证明 管理需求 处置合规 环保可审计 标识可注销 AAS子模型 EndOfLife 统一资产标识(Asset ID)贯穿全生命周期 · AAS 元模型实现跨阶段数据挂接与交换

二、阶段之间的数据衔接关系

四个阶段并非孤立存在,而是通过资产标识和关键数据对象形成链条。设计阶段的物料清单和功能规格,是制造阶段工艺规划的输入;制造阶段生成的序列号和检验数据,是运维阶段建立设备档案的基础;运维阶段积累的故障模式和维修记录,又反过来为设计改进提供反馈。退役阶段则要求把前面所有阶段的关键数据归档,形成完整的合规证据链。

在 AAS 中,这种衔接通过子模型(Submodel)实现。例如,设计阶段的 TechnicalData 子模型记录额定参数,制造阶段的 Nameplate 子模型记录铭牌和序列号,运维阶段的 OperationalData 子模型记录实时状态,退役阶段的 EndOfLife 子模型记录处置信息。它们共享同一个 Asset ID,从而在数字空间中形成一条完整的时间线。

三、各阶段管理需求对比

阶段 核心数据对象 数据特征 关键管理需求 典型 AAS 子模型
设计 CAD、BOM、规格书、仿真参数 结构化、版本多、变更影响大 版本可控、变更可追溯、需求可关联 TechnicalData
制造 工单、工艺路线、检验记录、序列号 过程型、数据量大、与实体绑定 批次可追溯、质量可关联、序列号可映射 Nameplate
运维 运行参数、报警、维修工单、备件更换 时序性、高频、多源异构 实时采集、状态可判断、历史可追溯 OperationalData
退役 报废审批、拆解记录、危废处理、合规证明 处置型、合规驱动、低频但关键 处置合规、环保可审计、标识可注销 EndOfLife

四、案例场景:一台工业泵的全生命周期数据流

以一台工业离心泵为例。设计阶段,工程师在 PLM 系统中定义泵的流量、扬程、功率等参数,并生成 AAS 的 TechnicalData 子模型。制造阶段,泵体铸造、叶轮加工、装配测试完成后,系统写入序列号、出厂检验数据和铭牌信息,形成 Nameplate 子模型。交付客户后,泵接入运维平台,振动、温度、电流等数据持续写入 OperationalData 子模型;一次轴承故障触发维修工单,更换记录同步更新。十年后泵退役,拆解记录、废金属回收重量和合规证明写入 EndOfLife 子模型,资产标识正式注销。

关键点:全生命周期数据管理的价值,不在于每个阶段单独做得多好,而在于阶段之间的“接缝”是否平滑。设计参数能否被运维对比?制造序列号能否被运维识别?退役合规数据能否从运维记录中自动提取?这些接缝问题,正是 AAS 要解决的核心问题。

五、常见误区与复盘

  • 误区一:把 AAS 当成静态档案库。实际上 AAS 是动态的,子模型会随资产状态变化而更新,需要设计写入接口和更新机制。
  • 误区二:只关注运维阶段。设计阶段的参数定义和制造阶段的序列号绑定,决定了运维数据能否被正确关联。前期数据质量差,后期治理成本极高。
  • 误区三:退役阶段数据“可有可无”。在环保法规和循环经济要求下,退役数据的完整性直接影响企业合规审计结果。
  • 误区四:各阶段系统各自为政。PLM、MES、EAM、ERP 之间如果缺乏统一资产标识,AAS 就退化成又一个孤岛。
# 典型 AAS 资产标识与子模型挂接示意(伪代码)
asset_id = "urn:asset: pump:SN-2024-00187"

submodels = {
  "TechnicalData":   { "flow_rate": "120 m3/h", "head": "45 m", "power": "22 kW" },
  "Nameplate":       { "serial_no": "SN-2024-00187", "mfg_date": "2024-03-12" },
  "OperationalData": { "vibration": "2.1 mm/s", "temperature": "68 C", "status": "running" },
  "EndOfLife":       { "retire_date": "2034-06-01", "recycle_weight": "186 kg" }
}

从设计到退役,资产数据经历了从“定义”到“过程”再到“状态”最后到“处置”的演变。每一阶段都有其独特的数据特征和管理需求,而 AAS 的作用,就是用统一的元模型和资产标识,把这些阶段串联成一条可追溯、可交换、可审计的数据链。只有理解每个阶段的特征与需求,才能设计出真正可用的子模型和接口,让资产数据在全生命周期中持续产生价值。