TrustMotion：构建软件定义汽车的系统架构方案

2026年9月17日，在第四届AI定义汽车论坛上，TrustMotion首席系统架构总监傅申分享，当前多数车企正处于从功能域向区域化架构过渡的阶段，虽然域控数量和成本已有明显下降，但软硬件耦合问题仍然存在，跨车型、跨平台开发时仍需要进行大量软件和硬件适配。进一步向中央化架构演进后，软件和算力将更多集中于中央控制器，区域控制器则逐步“做薄”，主要承担物理接口、网关和配电等功能，从而实现不同车型平台间更高程度的软件复用，并简化整车OTA和信息安全管理。

傅申指出，中央化架构落地仍面临延迟、任务调度和功能安全等挑战。随着原本分散在不同控制器中的软件集中运行，控制链路被拉长，同时多个应用需要共享中央算力，对任务优先级和安全隔离提出更高要求。针对这些问题，TrustMotion采用基于时间触发的确定性调度方案，从整条控制链路出发进行系统级优化，目前已完成跨ECU、跨计算核心及跨以太网的多任务调度验证，可支持不同延迟要求的数十项任务稳定运行。在此基础上，TrustMotion已推出覆盖不同架构层级的产品和确定性调度方案，并构建软硬件一体化平台，为车企推进中央化架构提供支持。

傅申丨TrustMotion首席系统架构总监

以下为演讲内容整理:

经过多年持续迭代，整车架构正从功能域架构逐步向区域化架构转型。当前多数车企处于左起第三张强区域阶段，入门车型或经济型车辆一般配置两个域控，高端车型则可扩展至三至四个域控。在这类域控中，大量软件从MCU或功能域向域控端融合，相比以往能够大幅降低成本。但该架构下，域控制器集成了大量软件与硬件接口，软硬件耦合度仍然较高。

图源:演讲嘉宾素材

可以设想，如果车企需要维护两至三套架构平台，部分车型采用双区域控方案，部分车型采用三区域控方案，在平台切换时，仍需对软件功能重新排布，并开展软硬件重新集成工作，因此尚未真正实现软件定义汽车或AI定义汽车的理念。

因此，部分车企希望统一低端至高端全系列车型架构，由此衍生出第四种中央化架构。理论上所有软件向中央集中，区域端则做薄，区域单元主要承担物理层与IO接口扩展工作。以上图6个IO Aggregator为例，这6个轻量化区域控制器可采用相同零部件，实现最大限度的通用化。软件与算力扩展均交由中央单元处理，以此真正落地软件定义汽车或AI定义汽车。

中央化座舱主要包含三个层级。第一层级为单一本体的中央控制器。如果暂不考虑独立的ADAS与座舱芯片或电路板，整车控制会配备专用中央控制器，所有软件控制逻辑均集中于此。该方案对OTA的优势在于，整车OTA不再涉及其他各类节点，仅围绕这一个ECU开展，能够大幅简化OTA流程。

第二层级中，对于车辆而言，所有AI相关数据及其处理工作均可部署在中央控制器内，AI数据的存储与采集不再依赖各类分布式单元。此外，ECU对外暴露的接口、软件对外提供的能力均集中于这一中央控制器，这使得机密信息与信息安全管理更为简便，全部信息安全防护措施也可集中部署在该控制器上。而区域单元将持续轻量化，算力负载逐步降低，主要承担IO扩展、区域网关以及配电这类稳定、变更较少的工作，核心目标是实现低成本、标准化与可复制。

最后一层端点为RCP节点，这也是我们常探讨的对象。该架构同样面临诸多挑战。第一，原有功能为本地化部署，单个ECU管控自身执行器、采集自身传感器信号。而当前控制链路大幅延长，控制指令从中央控制器下发至整车末端的RCP节点，由此带来新增的时延挑战。第二，全部软件集中部署于中央，各类任务的优先级如何排布，是否存在资源抢占问题，这对软件集成而言是巨大挑战。第三是功能安全层面的问题，中央控制器内同时存在AOD以及QM类应用，需要实现各类应用之间的隔离，保障相互不产生干扰。上述挑战通常无法依靠单一硬件或单独软件解决，属于系统性挑战。

对此，我们有很多应对产品。我们有RIO、S32N/C200、CoreRide、IO Aggregator、K51/Z248，以及MotionWise，作为确定性调度的系统性方案，用以应对中央化架构带来的挑战。

现有架构中的VCU，也就是整车控制器，在不少车企方案中会作为区域控制器的重要功能单元。多数区域控制器由ECU演化而来，作为整车纵向控制的核心器件，其下方连接多个CAN节点。它需要通过CAN总线获取整车信息，同时经由CAN总线对逆变器下发指令，或是向制动系统输出信号。

图源:演讲嘉宾素材

原有方案是在区域控制器端依靠CAN总线对各类节点实施控制。若推进中央化改造，则需要将ECU逻辑，包括全部计算逻辑与底层逻辑迁移至中央单元，区域单元将转变为兼具以太网与CAN能力的网关类结构。但由此带来传输链路延长的问题，同时原有性能指标仍需维持。此外CPU内部还会运行数百乃至上千项其他应用，如何保障整车ECU控制性能与原有架构保持一致，就是软件全部集中于中央所面临的一项十分具体的挑战。

我们应当如何看待该挑战？将该实例抽象建模，形成区域至中央再返回区域的时延分析课题，此时可以发现，我们的诉求不只是单纯提升速度，还需要保证时延可预测以及系统高效运行，这正是E2E时延议题背后对应的工程需求。

追求速度，意味着需要高性能硬件与高速网络这类硬件层面的支撑。在软件层面，则需要设计优良的软件架构以保障传输速率，例如轻量化的通信层，依靠通信层的优异性能实现提速。但仅保障单条功能链路的速度并不充分，还需要兼顾全部功能，因此要求所有应用的时间行为具备可预测性。

如何实现可预测性？很大程度上需要保障全部任务的时间需求均可得到满足。每个任务都有对应的时延指标、最大执行时间，以及自身的启动时间与截止时间。我们期望通过一套科学的调度方式，满足所有任务的时间需求。同时我们还希望具备足够的稳定性。对于时间敏感任务与功能安全任务而言，除了可在物理内存层面实现空间隔离，也能够完成时间维度的隔离，从而真正做到互不干扰。

因此我们提出的理念是:在开展架构设计、确定各项约束之后，可通过一套方法完成任务的规划与排布。当生成的排布方案能够满足全部要求时，测试阶段通常不会出现大量问题。若测试中发现问题，则可回溯调整相关约束并迭代优化。该方式相较于将所有问题留至测试验证阶段处理，效率将大幅提升。

为满足上述需求，我们认为采用时间触发调度是较为理想的方案，可达成相关要求。整车功能链路包含数据采集、数据处理、数据传输与执行环节，车端AI同样属于该链路的组成部分。这类任务的排布以时间为维度，时间构成其约束条件。

在整车层面探讨相关功能时，核心诉求是保障功能具备良好性能。这意味着我们不能仅考量单个任务在单一环节的指标，而是需要从整个系统的角度开展分析。我们在与众多客户交流时了解到，为满足功能需求，若投入大量精力优化单一环节，例如优化某一任务在SOC或MCU中的耗时，其边际效益通常不及调整整条链路与整个系统的调度安排，后者的边际效益更高。因此我们认为，如果要满足中央化架构下的功能需求，时间确定性会是一个很好的技术方向。倘若工程师在设计初期就可以借助离线可视化工具完成全部调度规划，便能获得具备确定性、可预测性的结果，保障各类任务在系统内稳定运行，各项功能达到预期效果。

我们实现了数十个任务的跨ECU调度，覆盖从M核至A核、跨以太网的全局调度。该调度方案运行数十项任务，各任务链，也就是各项功能，具备不同的时限要求，分别为1毫秒、2毫秒、5毫秒、10毫秒。在确定性约束与确定性调度机制下，全部任务均可满足对应的时延要求，最低时延可达1毫秒，能够匹配中央化架构的应用需求。

最后，作为系统平台产品线，我们正基于分立器件打造CoreRide系列产品。这不仅是硬件平台，还配套对应的软件、操作系统以及具备确定性能力的相关软件，是软硬件一体化平台。依托MotionWise、区域控制器、中央控制器以及后续的RCP节点，我们能够搭建整车中央化架构环境，助力客户满足各项功能与中央化架构的相关要求。