点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

• 你知道为什么传统的Classic AUTOSAR架构，跑不动AI模型吗？

• 你知道Adaptive AUTOSAR到底"Adaptive"在哪里，为什么说它是AI上车的关键基础设施？

• 你知道在实际项目中，Classic和Adaptive如何协同，才能让AI算法既跑得快又跑得稳？

2026年，"软件定义汽车"（SDV）已经不是PPT上的概念了。各大主机厂和Tier1都在疯狂招AI算法工程师，自动驾驶、智能座舱、预测性维护……AI正在渗透到汽车的每一个角落。

很多做AI的同学觉得，模型训练好了，推理引擎一跑，完事了。但在汽车领域，事情远没有这么简单。你的AI模型要跑在一个有功能安全要求（ISO 26262）、有实时性约束、有资源限制的嵌入式平台上——而这个平台的软件架构，大概率就是AUTOSAR。

2.1 AI上车的三大场景

当前车端AI主要集中在三个方向：

场景一：自动驾驶/ADAS

这是最热的方向。感知（摄像头、激光雷达、毫米波）→ 融合 → 决策 → 控制，整条链路都离不开AI。目标检测用YOLO/Transformer，路径规划用强化学习，端到端方案更是把整条链路都交给了神经网络。

场景二：智能座舱

语音助手、手势识别、驾驶员监控（DMS）、疲劳检测……这些功能背后都是AI模型在跑。而且用户对交互体验的要求越来越高，模型越来越大，算力需求越来越猛。

场景三：预测性维护与虚拟传感器

用AI模型替代物理传感器（Virtual Sensor），或者根据历史数据预测零部件寿命。这类应用对实时性要求相对低，但对可靠性要求极高——毕竟你不能让一个预测模型误判导致车辆抛锚。

2.2 AI落地的痛点：不是算法问题，是工程问题

• 算法团队在GPU服务器上训练好了模型，精度很漂亮

• 拿到车端一跑，推理延迟爆炸，根本满足不了实时性要求

• 好不容易优化到能跑了，又发现跟AUTOSAR的任务调度冲突

• 功能安全评审的时候，评审专家问："你这个AI模块的ASIL等级是什么？"——算法团队一脸懵

问题的根源在于：AI算法和汽车软件架构之间，存在一条巨大的鸿沟。

AI的世界是Python、PyTorch、CUDA、云端GPU；AUTOSAR的世界是C语言、RTOS、确定性调度、功能安全。两个世界的思维方式、开发流程、工具链完全不同。

而Adaptive AUTOSAR，就是为了弥合这条鸿沟而生的。

3.1 Classic AUTOSAR：稳如老狗，但跑不动AI

Classic AUTOSAR诞生于2003年，设计目标是标准化ECU软件开发。它的核心理念是：

静态配置

所有软件组件（SWC）在编译时就确定了，运行时不能动态加载

确定性调度

基于OSEK/VDX的RTOS，任务优先级固定，调度行为可预测

信号级通信

SWC之间通过RTE传递信号（Signal），类似于传统的CAN信号模型

资源受限

目标硬件是MCU（如Infineon TC3xx、NXP S32K），RAM通常只有几MB

这套架构非常适合传统的车身控制、底盘控制、动力总成等场景。但面对AI，它有几个致命短板：

简单说：Classic AUTOSAR是为"确定性"设计的，而AI天生需要"灵活性"。两者基因不合。

3.2 Adaptive AUTOSAR：为AI而生的新架构

2017年，AUTOSAR组织发布了Adaptive Platform，这是一次彻底的架构革新。小T总结一下它的核心变化：

关键点来了——Adaptive AUTOSAR为什么能承载AI？

POSIX接口

AI推理框架（TensorRT、ONNX Runtime、TFLite）都依赖POSIX API，Adaptive平台原生支持

C++支持

AI推理引擎基本都是C++写的，无缝对接

动态内存

神经网络推理需要动态分配Tensor内存，不再受限

SOA架构

AI模块可以作为独立Service，通过SOME/IP与其他模块通信，松耦合

高性能硬件

跑在SoC上（如NXP S32G、Qualcomm SA8650、NVIDIA Orin），有GPU/NPU加速

3.3 一张图看懂两者的定位

两者不是替代关系，而是协同关系。Classic管"稳"，Adaptive管"智"。

4.1 典型的车端AI部署架构

以一个L2+ ADAS系统为例，小T画一下实际项目中的软件架构分层：

4.2 AI模型如何封装为AUTOSAR Service？

在Adaptive AUTOSAR中，AI模块被封装为一个独立的Service。以目标检测为例：

关键设计要点：

服务化封装

AI模块对外暴露标准的ara::com接口，其他模块通过SOME/IP调用，不关心内部用的是TensorRT还是ONNX Runtime

异步调用

推理是耗时操作，用Future/Promise模式，不阻塞调用方

模型热更新

通过ara::per（持久化）+ OTA机制，可以在不重启ECU的情况下更新AI模型

健康监控

通过ara::phm（平台健康管理）监控推理延迟、GPU利用率，异常时触发降级策略

4.3 Classic与Adaptive的协同：一个真实案例

小T分享一个实际项目中的架构设计——AEB（自动紧急制动）系统：

为什么要这样分？

AI感知和融合决策

跑在Adaptive平台（SoC），因为需要GPU加速、动态内存、高算力

制动控制

跑在Classic平台（MCU），因为需要ASIL-D级别的功能安全、确定性实时响应

两者通过SOME/IP over Ethernet通信，Adaptive端发送"制动请求"，Classic端执行"制动控制"

这就是所谓的"混合架构"——AI负责"看"和"想"，Classic负责"做"。各司其职，各取所长。

5.1 挑战一：功能安全与AI的矛盾

ISO 26262要求软件行为是"可预测、可验证"的。但AI模型本质上是个黑盒——你无法用传统的MC/DC覆盖率来测试一个神经网络。

业界目前的做法：

AI模块本身不定ASIL等级

而是在架构层面做安全包络（Safety Envelope）

用一个ASIL-D的"安全监控模块"监督AI的输出，如果AI的决策超出合理范围，安全监控直接接管

这就是所谓的"E-Gas三层监控架构"在AI场景下的延伸

5.2 挑战二：实时性保障

AI推理的延迟是不确定的——同一个模型，不同帧的推理时间可能差几毫秒。但ADAS系统对端到端延迟有硬性要求（通常<100ms）。

实战中的应对策略：

模型量化

FP32 → INT8，推理速度提升3-5倍，精度损失可控

算子融合

TensorRT会自动把多个算子合并，减少GPU kernel launch开销

流水线并行

前处理、推理、后处理三级流水线，充分利用CPU/GPU并行

Deadline监控

通过ara::exec的执行管理，设置推理任务的deadline，超时则用上一帧结果兜底

5.3 挑战三：模型OTA更新

AI模型需要持续迭代——修bug、提精度、适配新场景。但车端不像手机，你不能随便推个更新就完事。

AUTOSAR框架下的模型OTA流程：

关键点：UCM（Update and Configuration Management）是Adaptive AUTOSAR的标准模块，专门管软件更新。模型文件作为Adaptive Application的一部分，走标准的UCM流程，安全可靠。

6.1 AUTOSAR R24-11 的AI相关更新

AUTOSAR组织已经意识到AI的重要性，在最新标准中增加了：

AI Framework Integration

标准化AI推理框架的集成接口

Adaptive Machine Learning API

为ML推理提供统一的ara接口

Safety of AI

与ISO 21448（SOTIF）对齐，定义AI模块的安全分析方法

写到这里，小T想说几句掏心窝的话：

• AUTOSAR工程师不要排斥AI。AI不是来抢你饭碗的，而是给你的系统加了一个"大脑"。你依然是那个让"大脑"安全可靠运行的关键人物。

• AI工程师不要忽视AUTOSAR。你的模型再牛，如果不能在车规级平台上安全、实时、可靠地运行，那就只是个实验室玩具。

• Adaptive AUTOSAR是桥梁。它不完美，生态还在成熟中，但它是目前最靠谱的"AI上车"标准化方案。

• 混合架构是现实选择。别想着一步到位全换Adaptive，Classic + Adaptive协同才是未来3-5年的主流架构。

• 持续学习是唯一出路。AUTOSAR在变，AI在变，整车架构在变。唯一不变的是——你得跟着变。