1. 课程导入与协同开发总览

在汽车电子电气架构快速演进的今天，微控制器不再只是执行逻辑运算的“计算单元”，而是承载安全关键功能与信息安全防护的“可信根”。英飞凌AURIX系列（以TC3xx、TC4xx为代表）正是面向这一需求设计的多核安全微控制器：它同时具备锁步核、内存保护、硬件安全模块（HSM）、安全启动等机制，使其成为动力总成、底盘域控、智能驾驶域控以及区域控制器中的常见主控芯片。理解AURIX的定位，是理解信息安全（Cybersecurity）与功能安全（Functional Safety）为何必须协同开发的起点。

一、AURIX在汽车电子中的定位

AURIX的典型特征可以概括为三点：多核架构、安全机制内建、面向实时控制。以TC3xx为例，它通常包含多个TriCore内核，其中部分内核可组成锁步对（Lockstep Core），用于检测随机硬件失效；同时集成HSM作为独立的安全子系统，负责密钥管理、加解密、安全启动校验等任务。这种“功能安全机制+信息安全机制”共存的硬件结构，决定了软件层面不能把两者割裂处理。

从整车视角看，AURIX往往处于“承上启下”的位置：向上通过CAN/CAN FD、以太网与域控制器或网关通信，向下驱动执行器、采集传感器信号。它既可能接收来自外部网络的诊断、OTA或V2X数据，也可能输出影响车辆运动控制的关键指令。因此，AURIX既是功能安全关注的“失效可能造成危害”的节点，也是信息安全关注的“可能被攻击利用”的入口。

二、为什么必须协同开发

信息安全与功能安全的目标看似不同：功能安全关注“系统在随机失效或系统性失效下仍能保持安全状态”，信息安全关注“系统在恶意攻击下仍能保持机密性、完整性与可用性”。但在AURIX这类芯片上，两者会相互影响。例如，攻击者通过篡改标定数据或固件，可能使功能安全机制失效；反过来，功能安全机制若设计不当，也可能被攻击者利用来触发拒绝服务或绕过安全启动。

更具体地说，协同开发要解决三类交叉问题：第一，安全启动与功能安全启动自检的时序耦合——HSM校验固件完整性的同时，锁步核需要完成LBIST/MBIST等自检，两者若顺序或资源冲突，可能导致启动超时或安全状态误判；第二，安全通信与功能安全端到端保护的重叠——E2E保护与SecOC可能同时作用于同一报文，需要明确谁先谁后、谁负责什么；第三，故障响应与攻击响应的协调——功能安全要求进入安全状态，信息安全要求记录并上报攻击事件，两者若各自为政，可能造成响应冲突或日志丢失。

三、核心挑战：资源、时序与责任边界

协同开发的第一类挑战是资源竞争。HSM与主核共享Flash、RAM和总线带宽。安全启动时，HSM需要读取并校验固件，主核需要执行自检，两者同时访问Flash会导致启动时间显著增加。在TC3xx的实际项目中，常见做法是把HSM校验与主核自检分阶段执行，或利用HSM的独立RAM缓存校验结果，避免总线争用。第二类挑战是时序耦合。功能安全要求在上电后规定时间内完成自检并进入安全状态，而信息安全的安全启动可能引入额外延迟。若安全启动失败，系统应进入何种状态？是禁止启动，还是降级运行？这需要功能安全与信息安全团队共同定义。第三类挑战是责任边界。当一条CAN报文同时需要E2E保护和SecOC认证时，谁负责完整性、谁负责真实性、失败时谁触发何种响应，必须在需求阶段就明确，否则会在集成阶段产生“都以为对方处理了”的漏洞。

四、标准依据：ISO 26262与ISO 21434的衔接

ISO 26262从危害分析（HARA）出发，确定ASIL等级，再通过安全机制、安全案例和确认措施保证功能安全。ISO 21434则从资产识别与威胁分析（TARA）出发，确定攻击可行性与影响，再通过安全控制、安全案例和监控响应保证信息安全。两者在AURIX项目中的衔接点主要有三个：一是安全目标与信息安全目标的联合定义，例如“防止非授权固件执行”既是信息安全目标，也支撑功能安全的“防止系统性失效”；二是安全机制的共享，例如HSM既用于安全启动，也用于功能安全相关的密钥存储；三是安全案例的整合，功能安全案例与信息安全案例需要相互引用，形成统一的整车安全论证。

五、整体开发流程概览

在AURIX项目中，协同开发通常按以下主线推进：概念阶段并行开展HARA与TARA，输出功能安全目标与信息安全目标；系统设计阶段将安全需求分配到硬件（锁步核、HSM、SMU）与软件（安全启动、SecOC、E2E、诊断）；实现阶段完成HSM固件配置、安全启动链、通信保护与故障响应逻辑；验证阶段执行功能安全测试（故障注入、自检覆盖）与信息安全测试（渗透测试、密钥管理审计），并进行联合确认。整个过程中，需求追溯矩阵需要同时覆盖ISO 26262与ISO 21434的条款，确保每个安全目标都有对应的实现与验证证据。