2026年5月，CEN/CENELEC JTC 24 发布产品数字护照（Digital Product Passport，DPP）系列基础标准，围绕唯一标识符、数据载体、数据交换协议、生命周期管理API、数据存储归档与持久性、系统互操作性等关键环节提出要求。其中，EN 18216《产品数字护照——数据交换协议》聚焦DPP数据在不同系统之间如何传输，规定了通信协议、接口架构和数据格式等基础要求。
产品数字护照并不是一份固定存放在某个平台上的电子文件。制造商、进口商、监管部门、维修商、回收商和消费者，都可能从不同系统访问同一产品的信息。数据能否安全传输、能否按照约定格式被接收和处理，直接影响DPP能否真正跨主体使用。EN 18216所解决的，正是不同系统之间“用什么方式通信、按什么格式交换数据”的问题。
EN 18216面向产品数字护照的技术互操作，规定安全、高效的数据交换协议和数据格式。其目标不是重新设计一套专用网络，而是在成熟、开放的互联网技术基础上，为DPP访问建立共同规则。无论数据由企业自建系统、第三方服务平台还是公共系统提供，交换过程都应遵循一致的通信和格式要求。
标准特别强调，DPP数据应当同时具备人类可读和机器可读能力，并能够通过开放、可互操作的网络进行结构化、检索和传输，避免被封闭在单一供应商或专有平台中。换句话说，EN 18216关注的不只是数据能不能发出去，还包括数据是否安全、接收方能否处理，以及系统接入成本是否可控。
在通信协议方面，EN 18216明确采用基于TLS的HTTP，也就是HTTPS，用于DPP数据的标准化访问。TLS负责在客户端和服务器之间建立加密通道，降低传输过程中被窃听、篡改或冒充的风险。标准将TLS 1.2设为最低支持版本，并推荐使用TLS 1.3；更早的TLS版本不应继续使用。
HTTP版本同样设有门槛。标准要求至少支持HTTP/2，并推荐采用HTTP/3，更早版本不应继续用于DPP数据交换。HTTP/2能够提高并发请求和连接复用效率，HTTP/3则基于QUIC，在复杂网络和移动场景下具有更好的连接恢复和传输表现。对DPP而言，这些要求有助于在大量产品查询、移动端访问和跨境网络环境下保持稳定性。
需要注意的是，HTTPS解决的是传输通道的安全，并不等同于所有数据都可以公开访问。哪些用户能够读取哪些字段，仍需结合身份认证、授权规则和产品组法规确定。EN 18216提供安全通信的底层条件，具体访问权限则由其他制度和系统机制进一步落实。
EN 18216提出，基于数据交换协议设计的API应遵循RESTful架构风格。RESTful接口通常通过标准HTTP方法表达读取、创建、更新和删除等操作，便于不同开发语言和业务系统接入。具体到产品数字护照，生命周期管理和查询接口由EN 18222进一步规定，EN 18216则提供其通信协议基础。
这种分工意味着，数据交换协议和业务API并不是一回事。EN 18216主要回答“通过什么通道、采用什么技术约束进行交换”，EN 18222则进一步回答“可以调用哪些接口、提交什么参数、返回什么结果”。把两项标准结合起来，才能形成从通信传输到业务操作的完整调用链。
标准附录还提到输入校验、响应校验、状态码和错误处理等机制。例如，服务端应检查传入数据是否符合预期格式，客户端也可以通过校验和或哈希值核验响应内容。接口出现认证失败、权限不足或请求错误时，应通过规范的HTTP状态码返回结果，避免各系统使用互不兼容的错误表达。
在数据格式方面，EN 18216将JSON规定为DPP句法互操作的基础格式。JSON结构相对轻量，便于网页、移动应用和后台系统处理，也是当前API交换中使用最广泛的格式之一。对产品数字护照而言，采用共同的基础格式可以降低系统之间的数据转换成本。
在JSON之外，标准允许根据HTTP内容协商机制使用XML、JSON-LD和HTML。XML适合既有企业系统、文档交换和复杂结构化数据场景；JSON-LD能够在JSON中加入关联数据语义，便于不同数据源之间建立语义联系；HTML则主要用于浏览器端的人类可读展示。
这里的“多格式支持”并不意味着同一份DPP必须重复建设多套数据。更合理的做法是以统一的数据模型为基础，根据调用方和使用场景输出相应表达格式。标准还要求面向人的内容展示符合相关可访问性要求，网页内容应遵循W3C HTML规范，并在不同浏览器和平台上进行测试。
除了加密传输，EN 18216还把数据完整性作为一项核心要求。标准附录进一步说明，HTTPS可通过消息认证码、密码套件、序列号和证书校验等机制，确认数据在传输过程中没有被非授权修改。证书验证也可以降低中间人攻击和虚假服务器带来的风险。
标准附录还列举了若干认证、授权和完整性保护机制。JSON Web Token可以结合HMAC或RSA签名验证令牌完整性，OAuth 2.0和OpenID Connect可以用于认证和授权。对创建、更新等操作，还需要考虑幂等性，避免网络重试导致同一请求被重复执行。
附录同时提到限流、流量过滤和拒绝服务攻击防护等问题。这些内容说明，DPP数据交换不能只关注接口能否连接。随着访问量增加，系统还要具备异常请求识别、速率限制、日志记录和安全事件处置能力，才能维持服务的可用性和数据可信度。
EN 18216规定的是DPP数据交换所需的共同技术规则，并不要求所有参与方采用同一套业务系统。其附录列举了可以适配这些协议要求的系统和方式，包括基于ebMS 3.0的AS4配置文件、资产管理壳（AAS）以及电子数据交换（EDI）等。该清单并非封闭目录，而是说明现有工业和供应链系统可以在满足协议要求的前提下接入DPP。
标准也明确了自身边界。DPP内部数据如何存储，由EN 18221处理；具体API操作，由EN 18222规定；数据模型和语义互操作，则需要结合EN 18223。EN 18216的作用，是在这些不同环节之间提供统一的传输通道和格式基础，而不是替代其他标准。
因此，企业接入DPP不一定需要推翻现有ERP、PLM、PIM、AAS或EDI体系。更现实的路径，是在现有系统上增加符合HTTPS、RESTful和标准数据格式要求的接口层，再通过字段映射和权限控制与DPP服务连接。
EN 18216的发布，明确了产品数字护照跨系统运行的一组基础技术条件：以HTTPS建立安全通信通道，以较新的TLS和HTTP版本保障传输安全与效率，以RESTful方式组织接口交互，并以JSON为主要数据格式，兼顾XML、JSON-LD和HTML等表达需求。
但标准并没有给出一套可以直接复制的完整系统方案。它规定的是交换协议和格式的共同底线，至于身份认证如何配置、不同角色能够访问哪些数据、JSON字段如何映射到具体产品规则、接口容量如何规划，仍需要结合EN 18222、EN 18223、产品组法规以及企业自身系统架构进一步设计。
对企业而言，现阶段应重点梳理现有系统的数据交换能力。首先，要检查对外接口是否支持HTTPS、TLS 1.2及以上版本和HTTP/2，并完善证书管理、身份认证和访问控制。其次，要评估ERP、PLM、PIM、供应链平台与DPP数据模型之间的字段映射，明确JSON等格式的输出规则。再次，要建立接口版本、错误处理、日志审计、限流和安全监测机制，避免数据在跨系统传输中出现格式不一致、权限失控或记录断裂。只有协议、格式和业务数据同时打通，产品数字护照才能真正实现跨平台流通。
联系方式：
录老师：15313551063
关于“CAICT数据基础设施”
CAICT数据基础设施以促进数据要素市场化配置为出发点，专注于数据基础设施的关键技术研究和数据智能服务网络建设，释放数据要素价值，推动数字经济与实体经济融合创新发展。
