英飞凌AURIX™ TC4x最详技术解读

2.5 信息安全

2.5.1 TC4x信息安全系统概述

随着 R155R156 、国家标准《汽车整车信息安全技术要求》等汽车网络安全法规逐步强制执行，汽车网络安全的重要性被提升了到新的高度，因此从 OEM 到 Tier 1 再到 Tier 2 急需从 Security 方面优化各自产品。

TC4x 系列在吸纳 TC3x HSM 子系统的优点后，针对当前区域控制器重构信息安全系统，首创 CyberSecurity Cluster 的概念，规划出 CSRM（ Cyber Security Real-time Module）和 CSS （ Cyber Security Satellite） 两个子系统，如下图所示：

图29

CSRM 和 CSS 主要负责密码算法硬件加速，除了支持国际密码算法，还支持国家密码算法 SM234 ，其中：

CSRM 包含：

●   非对称算法加速引擎，支持 RSA 和 ECC；

●   随机数生成器，支持 TRNG、DRNG 和 HRNG；

●   CSCU 用于与其他核通信、控制调试访问、PIN 脚输出等

CSS 主要用于对称和摘要算法加速，包含：

●   内部私有 RAM 用于存储密钥和 IV；

●   内部支持多达 21 个通道(1 个给 CSRM 独享)支持不同密码任务；

在 Cluster里，除 CSRM、CSS 外，还包括 TC1.8替代 TC3x中HSMM3内核、内部独立的 PFlash 和DFlash，同时可以用过软件配置各种外设成为 Cluster 里的部件，例如配置 Secure SPI与外部 TPM 交互。在 inSE的大背景下，该方案提升了 OEMTier 1 在布局汽车网络安全的灵活性和可靠性。

2.5.2 针对通信场景的优化

从上图可以看到支持 sym 和 hash 算法的 CSS 在布局中更为靠近 Host CPU，这样做的目的是什么呢？简单来讲，架构变化要么是性能优化，要么是安全优化，安全这块目前看不出来，但是从性能的优化我们需要从特定场景进行思考。

在 CP AUTOSAR 中，基础软件开发工程师大多从 SecOC 入门信息安全。在现有 MCU 里，针对 SecOC 数据验签的做法通常是 Hsot CPU 将待校验数据放置 Host 共享内存并置起请求 Flag，HSM CPU 侧轮询或者中断接收该 Flag 后去共享内存获取数据并进行加解密，如下图：

图30

这种针对 ECU 间的安全通信在当前架构下对 MCU 的 HSMSHE 等要求不算严苛，但是在区域控制器多功能融合、多 VM 通信的场景下，当前 MCU 就存在加密引擎实例和性能不够、多 Host 通道不足的问题，例如当区域控制器里融合了网关和 BMS 功能，当二者同时要使用 HSM 时，势必会形成资源竞争；

在车联网的大背景下，TLS 被引入到 DoIP 安全会话流程，在车机端也被用于车云通信，而 TLS 的引入也带来了巨大的通信负载（ 4 次握手，比 TCP 还多一次），流程定义了，那么只能在密码服务的性能做优化。

为此 CSS 站了出来，它提供独立的 SRISlave 接口（类似 TC3x 的 Bridge 模块）来实现与 CPU 之间的通信，内置 21 个独立通道和多个对称、摘要实例来实现多主机的并行访问，相较于之前 Host、HSM 之间交互，Host 仅需配置 SRISlave 接口里的特殊寄存器，即可完成 SYM 和Hash 引擎的使用。理论上省却了 Host 与 HSM 通信交互，提供了多通道平行接口，确实可以提高不少效率。

咱们做出这样一个畅想：在 SecOC AES-CMAC 校验时只需要告诉引擎在哪里获取数据，引擎自动获取数据并分块、填充完成数据校验，不需要像以前通知 HSM CPU 去获取数据，手写代码对数据进行分块、做填充。从代码层面上至少省却了通信这一大模块，然后减少 For 循环分块填充数据到引擎的代码，效率大大增加。

2.5.3 针对强标的对策

随着车辆网的发展，汽车网络安全已经被提升到了需要强制 OEM 考虑和执行的阶段，耳熟能详的就是 UNECE R155、 R156 以及对应国标《汽车整车信息安全技术要求》、《汽车软件升级通用技术要求》。

以 R155 为例，读过这份标准的同学应该最开始都是云里雾里，它主要涉及汽车的网络安全管理体系（ CSMS）及特定车辆型式认证（ VTA）两部分。

前者要求每个 OEM 都必须有一个稳定的网络安全管理体系，但是没有具体说应该如何去建立；后者要求 OEM 去识别特定车型的相关网络安全风险，但传统汽车人对这块确实一头雾水。

为此，ISO 和 SAE 与 2021 年联合发布了 ISOSAE 21434 标准，旨在指导 OEM、Tier1 如何建立起有效的网络安全组织，同时为车辆的整个生命周期(从研发到报废)建立起有效的流程体系，以保证其免受信息网络安全攻击。

换句话说，R155 是指导性文件，告诉做什么；ISOSAE 21434 是执行性文件，告诉 OEM 怎么做。

图31

由于 R155 针对 OEM 提出了宏观纲领，那么分解到 Tier 1 、2 ，自然就需要 21434 来进行指导如何干活；

TC4x 信息安全子系统不仅符合 EVITA-Full，还通过了 ISOSAE 21434 的认证，英飞凌从企业内部建立起 CSMS(Cyber Security Management System) ，针对风险评估方法、概念阶段、产品开发、运维、持续网络安全活动等方面定义了相关流程，致力于辅助加速 OEM 针对 R155 的认证。

2.6 功能安全

2.6.1 SMU继续发挥作用

如果说重构的信息安全系统是 TC4x 在跨域融合产品的亮点，那么 TC4x 的功能安全则是整个芯片正常运行的基石。

在 TC4x 中，大部分功能安全机制沿用 TC3x，而与我们开发最相关的 SMU 仍继续发光发热。在 TC3x SMU 的基础上，新增了关于 Security Domain 的 alarm 处理模块，同时设计了 Security 方面的 alarm；为满足区域控制下多 vECU 对于 alarm 处理的资源竞争，设计了两个 safety  alarm 处理模块。

其结构如下图：

图32

虽然没有了解到具体 Safety Manual，但是从 SMU 整体架构我们不难得出，所有功能安全机制触发的 alarm 可以被分为三大类：

●   Safety相关的alarm；

●   Security相关的alarm；

●   Safety和Security兼顾的alarm。

因此，针对这些 alarm 的处理，首先就是需要选择路由给哪些 alarm 处理模块。在 SMU 模块里提供了 alarm 选择功能，可以根据寄存器配置路由给不同的处理模块等，那么路由到目标处理模块后，对应行为是什么呢？

不难推测，为实现 TC3x 到 TC4x 的平稳迁移，当然就是继续采用内部行为和外部行为，如下图：

图33

内部行为对应 NMI、 IRQ、SYS_RESET、CPU_RESET，外部行为毫无疑问就是 FSP 等。

不过在 SMU_CS 的处理上，由于涉及到 Security，因此行为多在 Security 子系统里内部处理，包括 CSIRQNMIRET，以及特殊的对所有秘钥上锁、对 Debug 方面进行上锁等。

针对信息安全子系统设计的相关 SecuritySafety 机制，解答了我一直以来的疑惑，Security 与 Safety 到底应该如何融合：个人理解，虽然 Safety 和 Security 有各自的重点和侧重点，但它们的共同目标都是保护车辆、乘员和其他道路使用者的安全；同时二者关系也非常紧密，例如车辆的信息系统受到黑客攻击或恶意软件感染，可能会导致车辆失去控制、系统故障或其他安全问题，从而危及车辆和乘员的安全。

正如我们设计系统安全启动功能时，不仅要从 Safety 角度进行 HARA 分析，还需要从 Security 角度进行 TARA 分析，双剑合璧，才能加固系统。

2.6.2  功能安全闭环设想

在区域控制器架构下，不同 vECU 都会有自己的功能安全方案，有些方案甚至已有量产经验，那么在做跨入融合如何降低集成成本？我们这样设想，vECU 在运行中感觉不到自己是虚拟环境里，那么我们仍然可以从以往控制器的功能安全方案中吸取经验。

英飞凌官方应用笔记对于TC3xxSMU使用上强烈推荐与之搭配的PMICTLF35584、TransceiverTLE9252v，从而形成较为完整的系统级功能安全解决方案，如下图所示：

图34

TC3x 的 ErrorPin(P33.8) 与 PMIC TLF35584 的 Error PIN 相连接， 35584 在接收到相应的错误状态后，可以通过 SSx(Safety State)脚再向外输出错误状态，例如控制逆变器功能降级、通知 Transceiver 关闭通信等，使 ECU 进入到安全状态。

采用这样的思路，在区域控制器的大背景下，需要解决的就是多 vECU 对于 SMU 的资源竞争。

我们以 SMU 中 Alarm 行为 IRQ 为例来预估这样一条路径，如下图所示：

图35

当功能安全机制触发对应 IRQ 行为的 alarm 给到 SMU 后，通过 IR 给到目标 CPU，然后就是中断虚拟化的处理，Hypervisor 下对 VM 调度进行上下文切换，并通知相应 VM 进行功能降级。

如果使用到了 FSP，我们最关心的 Error Pin 继续兼容 TC3x， 并在此基础上新增了两个 PIN，这样相对来说资源上是能够支持与外部 PMIC 或者用户自定义引脚相连。

在 TC4x 推出的同时，配套 PMIC TLF4xx85 也同时推出，提供整套电源管理方案。

2.7 TC4x在调试、标定上的优化

2.7.1 Overlay继续沿用

TC1.8 继续沿用 CPU 视角下的 Overlay，这个功能我之前已经讲过多次，主要是用于 XCP 中页切换的实现同时也减少软件标定栈集成工作，具体如下：

当我们在上位机选择 WP 时，此时对应下位机(ECU)应该反馈 RAM 的值；选择 RP 时，对应下位机应该反馈 Flash 的值，如下图：

图36

在最初没有 Overlay 功能，要实现页切换，需要定义多块 RAM，其中包括一块临时 RAM，如下图：

图37

切换 WP 或者 RP，为保证 WP 数据不丢失，此时需要将 WP copy 至 Temp RAM；然后将 Flash 值 Copy 至 RAM；而这样内存 COPY 对于资源消耗和性能都有比较大的影响，为此英飞凌基于内核视角提出了 overlay 机制，如下图：

图38

这样的好处在于，假设修改标定量导致系统进入临界工况，例如车速突然增加(同一油门踏板开度，不同输出曲线)；此时快速切回 RP，可有效降低工程事故。

需要注意的是，当虚拟化开启后，如何通过 MPU 、Hypervisor 来保证不同 VM 的资源隔离，特别是对于 overlay 的 Flash 的选定，这是需要在实际工程中进行重新布局和调整。

2.7.2 调试系统

在调试系统上继续沿用 TC3x 的 Debug 接口，例如 JTAGDAPDAPE； 不过针对 Trace 接口提出了新的优化。整体架构如下图：

图39

在之前我们做高速测量时供应商都会针对 Trace 接口设计相应的 POD 接口，具体结构如下图所示：

图40

这对于 OEM 或者 Tier 1 在使用上有成本和性能上的综合考虑。

在 TC4x 的设计中，Trace 的数据可以通过 SRI 总线路由到 ETH 和 SRAM；我们做出这样猜想，在高速测量场景中，可以直接通过 ETH 将 Trace 数据给到上位机，这样不仅节省了成本，也提高了效率：

图41

在上图中，Trace数据通过 Trace 模块存放在 SRAM(作为临时 Buffer) ，CPU 仅需触发 DMA 搬运数据到 ETH 模块，通过 Ethernet 与标定测量系统进行数据传输，虽然会消耗很少部分 CPU 资源，但是相较于之前 MCU 从通用性和成本上确实提升了不少。

2.8 工具链及生态解读

2.8.1 集成开发环境及调试器

据统计，目前我们常用的商业版集成开发环境(含编译器)Tasking、Hightec、GHS 全面支持 TC4x 产品，调试器劳特巴赫、iSystem、PLS 均已全面支持。

图42

图43

英飞凌也推出里免费集成开发环境 ADS Limited，将代码编写、编译、调试融为一体，供 TC4x 新用户上手评估。

图44

2.8.2 基于 TC4x 的 AUTOSAR 基础软件

英飞凌本身不提供 AUTOSAR 基础软件，但行业中的主流 AUTOSAR 工具链厂商都已完成了 TC4X 的适配，国产的包括东软睿驰、普华基础软件、经纬恒润，国际厂商包括 Vector、ETAS、EB、SIEMENS 都对 TC4x 做了适配。

图45 东软睿驰基于TC4x的配套产品

#03

区域控制器MCU资源对比

#04

区域控制器市场前景预测

2019 年，特斯拉这条鲶鱼带来的汽车电动化、智能化、网联化震撼人心，随着这股风潮的推动，汽车电子电气架构逐步由传统分布式 ECU 向域控/中央集中架构方向发展。

在以往传统分布式 E/E 架构下，汽车智能化程度的提高主要依靠整车 ECU 数量的增加，往往一台高端车型的 ECU 数量就超百个；然而 ECU 数量的增加势必造成整车布线复杂冗长、线束成本剧增，同时不同 ECU 之间信息交互的效率和精度也大打折扣，为此域控概念开始提出。

博世关于整车EE 架构的演进在之前文章里已经谈过多次，它主要是依据控制器功能划分为动力域、底盘域、信息娱乐域、自动驾驶域和车身域五大域控，这也是目前多数 OEM 的架构；

特斯拉领先一步，根据空间位置分为 CCM（中央计算模块）、LBCM（左车身域控）、RBCM（右车身域控），这也是中央集中架构的雏形。

虽然上述两类控制器均带有域，但是英语单词上存在比较大的差异，

●   域控制器：DomainController，针对的是控制器功能，我们常见的是五域架构：智驾域、座舱域、动力域、底盘域、车身域就是此类域控制器；它按功能对整车布线，以提供对整个车辆的控制。但随着智能网联汽车发展，新的需求和功能导致ECU 增多（据统计智能汽车含 100-150 个ECU），汽车内部布线逐步复杂。从电源到ECU 再到执行器的连接导致了整车布线多半是打补丁的方式，冗余且浪费。这种方式在未来智能驾驶的实现有着极大的扩展限制。

●   区域控制器：Zonal Controller，面向的是整车空间的一个布局，在区域控制器下可能会实现多个功能，这也是下一代 MCU 考虑的事情，在硬件层面重新规划 I/O 等硬件资源，打破域控架构下的原有功能边界，大大缩短了布线长度，简化了电源和信号传输，并释放了更多空间，为下一次电子电气架构演进奠定了基础。

当架构逐渐集中，对于汽车软件功能新增和聚合的需求也日益凸显。据《中国汽车基础软件发展白皮书》统计，智能网联汽车运行代码量已经高达 2 亿行，在未来 L3L4 及以上级别的自动驾驶汽车代码量甚至会增加到4 亿行 。代码量的增加对汽车芯片的资源、算力、外设、性能的要求与日俱增，这对在汽车芯片占比高达 30% 的 MCU 提出了更大的挑战，各大国际 MCU 厂商纷纷加大投入，融入新技术，即将推出的汽车 MCU 产品更像是一颗低端 SoC 芯片，这对以往基于 MCU 研发的工程师来说将会是一个新的领域。

那么具体来看，区域控制器会为整车带来什么的好处？

1.线束减少影响整车重量

据统计，在当前功能域架构下的整车线束在 50-60 公斤，展开长度可达 5-6 公里，这对于电动汽车的成本、日常使用续航等有着重大影响；采用区域架构可以有效减少线束，减轻了车辆的重量。这对电动汽车尤其有益，因为每节省一公斤就意味着里程的增加和性能的提高。特斯拉采用类区域控制架构，将整车线束重量减小至至 20 公斤，大家可以发现在 18 、19 年续航里程上国产电动车宣传都有一点虚高，特斯拉则是实打实标称；

值得一提的是随着车辆从 12V 电气系统迁移到 48V 电气系统，可以在更低的电流下提供相同的功率，从而减少电线的厚度和相应的重量，这种重量进一步得到改善。通过更细的线束和更简单的布线，也为其他功能系统腾出了更多的空间。

2.提升整车制造装配的效率

随着区域架构采用标准化和模块化的设计，整车装配线进一步简化，模块化使得线束可以预组装，标准化使得整车装配模块即插即用。这些进步带来了更大的灵活性，更容易自动化，更少的错误，并大大降低了电气子系统的制造成本。

3.简化OTA难度

在分布式甚至功能域架构下，ECU 个数仍居高不下；如今智能网联大背景下，汽车软件 OTA 更加频繁，因此 OEM 需花费大量成本、人力资源来协调和管理 ECU 供应商的软件更新和管理。

在中央集成+区域控制架构下，ECU 数量减少，中央计算平台与区域控制器采用以太环网进行数据交互，区域控制器下挂节点利用高速总线接入网络，不仅简化了 OTA 升级节点个数，还提高了 OTA 升级速度。

就目前来说，域集中已经成为了汽车行业共识，我们可以从主机厂发布的域架构可以看出，汽车电子电气架构沿着预轨道发展，正朝着中央式进发，如下图所示：

图46

“ 中央集成+ 区控制器”架构将是长期趋势，也是当前汽车未来研发重点。