【功能安全软件实践】软件安全机制3--CP安全通信

E2E保护的基本原理

E2E保护模式

E2E实践建议

在《【功能安全软件实践】软件安全机制3--安全通信要求》中，我们深入探讨了Adaptive Platform（AP）的端到端（End-to-End, E2E）保护机制，重点分析了基于SOME/IP通信的服务级数据完整性保障方法。然而，在当前以Classic Platform（CP）为主导的车载嵌入式系统中，E2E保护同样扮演着不可或缺的角色——尤其是在涉及功能安全的信号交互场景中。与AP依赖操作系统和中间件不同，CP的E2E实现深度集成于AUTOSAR基础软件栈，通过PDU级别的校验机制确保通信数据在传输过程中免受篡改、丢失或重放攻击。本文将聚焦于CP端E2E保护的设计原理、配置流程与运行时行为，帮助开发者构建符合ISO 26262要求的高可靠通信系统。

1. E2E保护的基本原理

在AUTOSAR架构中，E2E保护被实现为一个独立的函数库，主要提供三项关键功能：

1）发送端保护：为待传输的安全相关数据添加校验信息（如CRC、序列号等）；

2）接收端验证：对接收到的数据进行完整性、顺序性和时效性校验；

3）错误指示：在检测到异常时，向诊断事件管理器（Dem）或上层应用报告通信故障，以便触发相应的安全响应机制。

在CP端，E2E保护应优先采用Profile 01或Profile 02，如下表所示。

图1 Profile01&Profile02说明

2. E2E保护模式

如何将E2E机制集成到通信栈中，存在多种技术路径。工程上常见的三种方式包括：应用层手动封装的E2E Wrapper、基于Com模块回调的Com Callout，以及符合AUTOSAR 标准的PduR Transformer机制。这三种方式在架构层级、耦合度、可维护性及功能安全合规性方面存在显著差异。选择何种方案，不仅影响开发效率，更直接关系到系统能否通过ISO 26262认证。下面将从多个维度对这三种集成模式进行了系统对比，为项目选型提供清晰参考。

Wrapper模式，会在RTE接口之上插入一层适配逻辑，每当SWC调用Rte_Write/Read时，实际先经过一个封装层，由该层调用E2E Library对数据进行保护/检查。弊端是每个涉及安全信号的SWC都需配备专属的Wrapper层，导致代码冗余、维护成本上升；SWC无法再直接访问“原生”的RTE接口，破坏了RTE作为标准化通信抽象层的设计初衷；应用逻辑与通信安全机制紧耦合，违背了AUTOSAR分层解耦的核心原则。

图2 E2E_Protection_Wrapper(E2EPW)

另一种Transformer方式是从系统角度去实现，不需要在SWC的设计阶段去做适配。系统描述文件已经把PDU和E2E绑定，且最终在RTE内部自动实现，无需手动添加代码。

图3 E2E Transformer(E2EXF)

最后一种方式是Com Callout：当PDU从ASW经RTE到达Com模块时，若其配置启用了Send/Receive Callout，Com会在转发前调用用户定义的回调函数。在此函数中调用E2E接口，对PDU数据进行保护或校验，再将处理后的完整数据包向下传递。但该方式存在明显盲区：E2E仅覆盖Com到对端Com的链路，而ASW→RTE→Com这段路径未受保护。若数据在此阶段被破坏（如SWC逻辑错误、RTE映射异常），Callout无法检测，因此并非真正的端到端保护。因此在项目开发过程中，要结合实际情况选择安全相关数据的链路（见图1），确保符合ISO 26262的要求。

图4 Com E2E Callout(ComCallout)

3.E2E实践建议

在大型项目实践过程中，通常选择已通过ISO 26262认证的E2E库来加快项目进度。若由工程师自行开发E2E组件，需严格按照ISO 26262完成功能开发和功能安全测试流程。此外还建议测试工程师按照下图流程编写测试用例，避免功能测试遗漏。并通过状态返回值检查各个状态结果是否满足测试的预期要求。

图5 Counter与Cycle逻辑关系

最后，请大家思考及回顾以下问题：

问	请问CP和AP的E2E保护链路有什么区别？CP端还有其他Profile可选吗？
答	通常情况下，AP实施的E2E和CP的ComCallout模式最为相似，以ARA::COM中间件实施为主，也有部分类似PW模式，在ASW层实施。 CP端的Profile选择具体以实际项目为主，包括CRC的选型均可调整。
问	同一个ECU的数据交换是否需要启用E2E保护？
答	E2E是保护通信路径上的随机硬件故障和系统性失效的安全措施，常用来保护不同ECU上的SWC之间的数据交互。若单ECU上的SWC之间存在数据污染，也可参考PW模式添加合理性检查和冗余校验等安全措施来满足ISO 26262要求。

本文系统阐述了CP端的E2E保护机制。与前文AP端基于SOME/IP服务通信的E2E实现不同，CP端E2E深度集成于基础软件栈，以PDU级别的校验为核心，主要采用Profile 01（完整性保护）和Profile 02（完整性+新鲜度保护）满足功能安全需求。在集成方式上，三种方式均可实现保护，但分别在架构侵入性或保护范围等方面存在差异。最终，无论CP还是AP，E2E保护的本质目标一致——确保安全关键数据在传输过程中的可信性，这使其成为ISO 26262功能安全体系中不可或缺的关键技术。

我们功能安全团队成立于2008年，是国内较早从事功能安全技术研究的团队，作为功能安全国家标准委员会成员参与功能安全、预期功能安全标准制定，作为芯片创新联盟核心成员参与车规级自主芯片功能安全国标制定。目前有专职的功能安全技术人员80余人，团队成员大多来自985/211高校，核心项目实施团队拥有8年以上电控产品开发经验，可以提供面向量产车型开发从概念设计到正式投产的全栈功能安全咨询服务，当前已成功为国内外整车及零部件企业提供150+项工程咨询服务。