把数字产品护照要求映射到 ETIM 字段

数字产品护照的相关法规，对它想要的形状讲得异常清楚，对内容却异常沉默。产品信息必须做到机器可读、结构化、可互操作，并以国际公认的开放标准为依托。至于究竟是哪一部标准，法规没有说。那被留给了按产品组逐一出台的授权法案，而这些法案中的大多数至今还不存在。

对电气、暖通空调、给排水或建材类产品的制造商来说，这造成了一种颇为奇特的处境。您知道有一项要求正在路上。您也大致知道它会要些什么。但您还无法知道确切的字段名称。与此同时，您的 PIM 系统里已经躺着一套分类标准，它早已把您产品的大部分技术属性描述得毫不含糊。

明智的做法，是把手上已有的东西映射到可以合理预判的要求上，现在就把记录建起来，把监管层面的管道工程留到管辖您产品的那部法案发布之后再说。本文就是这份映射——而且很重要的一点是，它同样包含映射失效的那些部分。

ETIM 到底给了您什么

ETIM 是一部字典，不是一种文件格式。它要解决的问题是：让同一项技术属性，对德国制造商、荷兰批发商和波兰承包商而言含义完全一致，而不必先由他们私下商定一套专有的数据结构。

承载这层含义的，是三类代码：

ETIM 8.0 在 5,145 个类别中包含 18,766 项特征。每一项特征都属于四种数据类型之一：数值型、数值范围型、字母数字型或逻辑型。

真正对合规起作用的那条约束，很容易被忽略。字母数字型特征不接受自由文本。每一项这样的特征都绑定着一份允许值清单，而清单里的每一个值都有自己的 EV 代码。您没法在防护等级字段里写上“大约 IP66”。要么选一个值，要么就空着不填。

正是这一条限制，划出了机器能读的数据与机器能评估的数据之间的界线。核查符合性的监管机构、按阈值做筛选的经销商采购系统，以及回答“这些里面哪些可以用于户外”的 AI 助手，查询这个字段的方式完全一样。一旦您不再把“可互操作”当成“共享”的同义词，它的含义就是这个。

DPP 的各项要求落在这套结构的什么位置

这些要求可以归为四组，其中只有两组是 ETIM 要解决的问题。

标识——大体上不归 ETIM 管

护照需要一个唯一产品标识符、一套为其签发标识的体系，以及一个经营者标识符。ETIM 对产品是什么做分类；它并不签发身份。这属于 GS1 或同等方案的地盘，而且这是第一件必须敲定的事，因为其余所有内容都以它为索引键。

技术特性——正是 ETIM 的主场

这正是 ETIM 当初被造出来要处理的部分，映射关系几乎是一对一的。尺寸、材料、性能参数、电气特性、防护等级、温度范围：这些早已作为 EF 特征存在于您的产品类别之中，并带有既定的单位和允许值。如果您的产品已经完成分类，这部分工作其实大都已经做完，只不过您一直没把它当成合规数据来看待。

环境与循环性——ETIM xChange 2.0

有一项进展，大多数人还没注意到。2025 年 11 月发布的 ETIM xChange 2.0，新增了用于承载生命周期评价与环境产品声明数据的扩展环境字段，这批字段由 ETIM International 的环境数据工作组共同制定。它还新增了一个面向《包装与包装废弃物法规》的包装材料元素。

这些字段与某一部具体的授权法案是否一一对应，在该法案发布之前无从得知。但结构已经存在，有版本管理，而且制造商已经在往里填数据了。这个位置，比一个标着“碳足迹”的空白列要实在得多。

载体、注册库与访问权限——完全不归 ETIM 管

实体产品上的数据载体、在 2026 年 7 月上线的欧盟注册库中完成登记，以及分层的访问控制——部分字段公开，部分字段只对监管机构或回收企业可见——统统落在分类标准的范围之外。ETIM 告诉您某项属性是什么意思。至于谁可以读它，它一个字也不会说。

一份合规形态的记录长什么样

ETIM xChange 是 JSON 格式，并配有已公开发布的 JSON Schema；它把通用产品数据与承载这些数据的贸易项目分开来处理。下面这段结构展示的就是这种分离，主角是一只小型断路器。

有一处刻意的省略需要说明。ETIM 模型以 ODC-BY 许可发布，本文不会复制它的内容。EC000001 和 EF000007 之所以出现在这里，是因为 ETIM International 及其各国组织在自己的文档中就是把它们当作示例公开的。下面其余的代码一律以占位符形式呈现。真正的代码请从您自己的 ETIM 发布版本里取——那才是获得许可、注明出处且始终最新的来源；而转载一部并不属于您的字典，绝不是合规记录应有的地基。

{
  "product": {
    "manufacturerProductNumber": "MCB-C16-1P",
    "manufacturerGLN": "<GS1 Global Location Number>",
    "productIdentifier": {
      "scheme": "GS1",
      "value": "<GTIN>"
    },
    "classification": {
      "system": "ETIM",
      "release": "ETIM-8.0",
      "class": "EC000001",
      "features": [
        { "code": "EF000007", "type": "A", "value": "<EV code for colour>" },
        { "code": "EF<rated-current>", "type": "N", "value": 16, "unit": "A" },
        { "code": "EF<poles>", "type": "N", "value": 1 },
        { "code": "EF<tripping-characteristic>", "type": "A", "value": "<EV code for C>" },
        { "code": "EF<ip-rating>", "type": "A", "value": "<EV code>" }
      ]
    },
    "environmental": {
      "epd": {
        "declarationNumber": "<EPD registration>",
        "validUntil": "2029-11-30",
        "gwpTotal": { "value": 2.41, "unit": "kg CO2e" }
      },
      "recycledContent": { "value": 18, "unit": "%" }
    },
    "packaging": {
      "materials": [
        { "material": "corrugated board", "weight": { "value": 42, "unit": "g" }, "recycledContent": { "value": 82, "unit": "%" } }
      ]
    }
  },
  "tradeItems": [
    {
      "gtin": "<GTIN>",
      "packagingQuantity": 1,
      "orderUnit": "PCE"
    }
  ]
}

关于这份记录，有三点值得特别拎出来讲。

分类区块自带发布版本。"release": "ETIM-8.0" 不是摆设。特征会在不同发布版本之间发生变动，一份没有声明自己依据哪一版字典写成的记录，在下一个版本发布的那一刻就变得含混不清。这是现实世界的 ETIM 数据中最常见的一种缺陷。

每一项特征都自带类型。数据消费方可以按数值去校验 "type": "N"，按允许值清单去校验 "type": "A"，全程不需要懂任何关于断路器的知识。正是这一点，让这份文件从只能被解析变成可以被校验。

通用数据与贸易项目彼此分离。一款产品，多种包装规格，但只有一套技术事实。把它们压平成一层——大多数基于电子表格的数据交换正是这么干的——十只装的包装最后就会声称自己只有单只的重量。

把缺口摊开来讲

一篇声称覆盖无遗的映射文章，多半是在推销什么东西。这里有四个如实相告的缺口：

1. 01大多数产品组还没有授权法案。目前唯一确定的日期是 2027 年 2 月 18 日，适用于部分工业电池、电动汽车电池和轻型交通工具电池，其依据是《电池法规》而非 ESPR。谁要是给您报出一个统一的 DPP 截止日期，那就是把事情简化过头了。
2. 02ETIM 的环境字段还很新。它们于 2025 年 11 月发布，尚未经过任何一部已公布的授权法案的检验，因为根本还没有这样一部法案可供检验。
3. 03访问控制在格式层面尚未解决。法规设想的是分层可见性。ETIM xChange 表达不了这一点。这件事最终得由对外提供护照的那套服务来承担。
4. 04分类的覆盖程度参差不齐。5,145 个类别听上去不少，但如果您的产品恰好落在一个特征稀疏的类别里，字典就承载不了您的差异化卖点，您又会被打回到附件和自由文本上去。

为什么这份记录无论如何都值得建

就算把法规这一层完全拿掉，这同一份文件，仍然是您能为自己的产品目录建起来的最有价值的东西。

一份结构化、带类型、有字典背书的产品记录，能让经销商不必立项做映射就把您的全系产品接入进去，能让采购系统按阈值而不是按关键词做筛选，也能让 AI 助手在回答关于您产品的选型问题时引用您、而不是靠猜。就最后这一点，我们测量了 984 个工业产品目录，中位得分是 100 分里的 50 分——瓶颈几乎从来不在产品本身，而在于描述产品的数据被困在 PDF 和 JavaScript 里。

合规期限，不过是在倒逼一件本来就能自负盈亏的工作。这是一个难得舒服的处境，值得把它当成一个机会来正视。

从哪里开始

请按以下顺序推进，因为每一步都会让下一步变得更便宜：

1. 01按您当前使用的 ETIM 发布版本完成分类，并把版本记录下来。如果您已经完成分类，请核实导出文件中是否写明了发布版本——通常并没有。
2. 02导出为 ETIM xChange 2.0，并用已公开发布的 JSON Schema 做校验。这一步出现的校验失败，都是您原本就存在、只是一直没看见的数据质量问题。
3. 03把环境区块填起来，用今天手上有的 EPD 和 LCA 数据，哪怕不完整也填。不完整的结构化数据，胜过完整的非结构化数据。
4. 04把标识敲定——GTIN 或同等标识，以及签发体系——因为整本护照都以它为索引键。
5. 05把数据载体和注册库留到您的授权法案发布之后再做。照着草案去建，结果就是同一件事做两遍。

前三步产出的是一项资产：它从建成的那一天起就有用，与授权法案最终怎么写无关。这也是您可以拿来检验任何一项别人向您提议的 DPP 工作的试金石：如果脱离了法规它就一文不值，那它多半为时过早。