一张图看懂 eCoC 数据流转：从 ERP 到欧盟登记系统

为什么架构图比文字更重要

eCoC 项目启动时，最常见的误判是把它当成一个"填表导出"的工作，以为把现有纸质 CoC 的字段搬到 XML 里就完事了。实际上，eCoC 的核心挑战在于：数据来自哪里、签名如何嵌入、文件如何推送，以及每一个环节的责任系统是什么。

下图展示了一个完整的 eCoC 生产级数据流转架构，覆盖从主机厂内部系统到欧盟 EUCARIS 的全链路，以及 vSign API 在其中承担的角色。

eCoC 全链路数据流转图

逐层解读：各系统的职责边界

第一层：主机厂内部数据源

eCoC 的 50+ 个 XML 字段来自企业内部多个系统，这是数据整合最复杂的一层。主要包含三类来源：

ERP / 生产系统负责提供车辆识别信息，最核心的是 VIN（车辆识别代码）。VIN 是整个 eCoC 体系的主键，EUCARIS 跨境查询依赖它精确匹配，任何格式错误（大小写、禁用字符 I/O/Q、前后空格）都会导致查询失败。

PDM / PLM 系统提供车辆的技术参数——发动机功率、排放值、整备质量、外廓尺寸等。这类数据通常按车型存储，但同一车型存在多个配置变体时，不同变体的参数不同，必须建立以配置为维度的映射关系，而不是用车型级"默认值"填充所有车辆。

合规台账由法规合规部门维护，记录每个车型的欧盟型式认证编号、认证机构代码（如 e4 代表荷兰 RDW、e1 代表德国 KBA）。这些字段直接决定 eCoC 与哪个成员国 NAP 对接。

在进入下一层之前，数据聚合与校验模块需要完成字段格式验证和 XML Schema 预检，确保送往签名层的数据已经合规。

第二层：vSign 集成层

这一层是整个流程中技术复杂度最高的部分，也是系统边界最清晰的地方。

XML 生成引擎按照 EU 2020/683 附件规定的 IVI v2.0 Schema（可从 ecoc.eucaris.net 下载 XSD 文件）将聚合后的数据序列化为标准 XML。生成时需严格控制字符编码（UTF-8 无 BOM）、命名空间声明和空白字符，任何不规范的处理都可能导致后续签名验证失败。

vSign API 负责 XAdES 签名的核心流程：调用存储在 HSM（硬件安全模块）中的合格电子印章私钥，对 XML 文档进行 XAdES-B-LT 格式的 Enveloped 签名，并嵌入 TSA（时间戳机构）颁发的签名时间戳。完成后输出的是一份具有法律效力、可被独立第三方验证的 eCoC XML 文件。

批量生产场景下，vSign API 需要支持并发签名，并提供完整的签名状态跟踪，确保每辆车的 eCoC 可查、可重试。

第三层：欧盟数字基础设施

NAP（国家接入点） 是制造商推送 eCoC 的法定入口。每个欧盟成员国有自己的 NAP，接口技术规范（REST/SOAP）、认证机制和字段校验规则各有差异。制造商推送 eCoC 后，NAP 会返回接受或拒绝的状态回执；这个回执必须被系统捕获并记录，以便追溯和排障。

EUCARIS 是欧盟成员国之间进行车辆信息共享的互联网络，各国 NAP 收到的 eCoC 数据最终汇入其中，供其他成员国登记系统查询。

成员国登记系统在车辆申请上牌时向 NAP/EUCARIS 查询 eCoC，查询成功才允许登记。这是整条链路对最终用户可见的最后一步。

集成难度在哪里

对大多数整车厂而言，架构图上看起来"只有三层"，但实际集成难度集中在以下几个节点：

数据整合是隐性工作量最大的部分。ERP、PDM、合规台账通常属于不同部门管理的不同系统，字段格式不统一，数据责任人分散，存在大量需要手动对齐的历史数据问题。

XAdES 签名的正确实现是技术门槛最高的单点。XML 规范化（Canonicalization）的细节错误、证书链不完整、时间戳服务不可用——任何一个问题都会导致 NAP 验证失败，而且错误信息往往不直观，定位耗时。

NAP 联调往往比预期耗时更长。测试环境行为与生产环境存在差异，加之各国 NAP 的响应速度和文档完善程度参差不齐，联调阶段建议预留至少两周的缓冲时间。

如果你的团队正在对照这张图评估当前系统的集成缺口，欢迎联系我们——我们可以基于你的实际 IT 架构，给出具体的集成方案建议。