「汽车出海，登陆欧洲」- VTA认证与实战攻防检验 - Part 2

写在前面

知乎仅有的一篇关于R155/R156合规的专栏文章，很长！更是樵兄及团队正在经历中的真实写照，绝对值得你订阅！

如果想进「汽车出海，登陆欧洲」的社区/圈子探讨和碰撞，请私信或回复留言。

关于此次深入探讨的R155/R156合规的背景，要解决的痛点和草稿版大纲，可以参考之前的文章，大家多提问题！！！

全文三千九百九十一字。

路阻且长，行则将至。

Part 1我们针对的是VTA的整体思路以及基于R155 Annex 5 靶标的渗透测试的高风险模块四大重点命门，接下来Part 2来阐述R156 核心要求以及测试用例。

证明更新不影响“功能安全”的硬性证据 (R156 核心要求)

讲完了防黑客（R155），我们来讲讲升级（R156）。在软件更新管理系统（SUMS）的VTA认证中，欧洲交通部最害怕的不是你没修好Bug，而是你越修越糟，直接把车修成了失控机器。

因此，向审批当局证明OTA更新绝对不会破坏车辆原有的功能安全（Functional Safety，ISO 26262）和行驶安全，是R156不可触碰的红线。你必须像法庭对质一样，交出以下三大维度的“硬性铁证”：

流程层：执行HARA分析，评估法规依赖性影响

• 硬性要求：国内很多车企推OTA是“拍脑袋”，觉得改个UI不影响安全。欧洲法规要求，必须有一套严密的流程，来识别所有控制器的相互依赖性。你必须要评估：这次更新，会不会连带改变当初做型式批准（VTA）时的关键参数（如制动距离、电机扭矩曲线、排放策略）？
• 证据交付（你要拿什么给考官看）：你不能光用嘴说“没影响”。必须提供基于 ISO 26262 的 HARA（危害分析和风险评估）报告。报告中必须详细列出：更新包设计阶段，我们考虑了哪些危害场景（比如高速行驶时屏幕重启导致仪表丢失），评估了ASIL（汽车安全完整性等级），并采取了哪些软件冗余手段来缓解风险。

门禁层：严苛的安全审查发布门禁 (Readiness Gates)

• 硬性要求：OTA代码从程序员的电脑里，到推送到车上，中间不能是“一路绿灯”的。必须有类似航天发射一样的“安全审查门禁”。防止代码被内鬼篡改，或带着致命Bug上线。
• 证据交付：

权限绝对分离的记录：证明写代码的人（开发）、打包签名的人（安全）、和最终点击“下发更新”的人（发布），在系统里绝对不是同一个账号。
数字签名与合规文档：提供更新包使用了HSM机密私钥进行数字签名的系统校验Log，以及所有高管和合规官在“发布门禁（Readiness Gates）”上的官方电子签批文档。没有这些签名，哪怕代码再完美，也是非法更新。

物理层：强制更新前置条件与回滚底线

这是中国车企在国内最喜欢“炫技”，但在欧洲摔得最惨的地方。把国内“无感升级、边开边升”的规则搬去欧洲，就是找死。

• 硬性要求：车辆端必须具备极其死板、硬性的物理与逻辑防御机制来保障更新动作的执行安全。