企业官网建设流程全解析

上一篇我们聊了一个最基础的问题：

AUTOSAR到底是什么？为什么现在越来越多的汽车ECU离不开它？

但理解AUTOSAR之后，很多人马上会遇到第二个问题：

我以前写单片机程序也能把车控制起来，为什么还要搞AUTOSAR？

AUTOSAR Classic和Adaptive又是什么关系？

它们是不是一个新、一个旧？

如果你刚开始接触AUTOSAR，这几个概念确实很容易混在一起。

其实它们并不是简单的“低级、中级、高级”关系。

更准确地说：

传统嵌入式、AUTOSAR Classic和AUTOSAR Adaptive，本质上是在解决三种不同规模、不同复杂度的软件问题。

这一篇，我们先不碰复杂的配置工具，也不讲ARXML。

先把这三种开发方式放到一张桌子上看明白。

01 从一个最简单的ECU开始

假设现在让你开发一个很简单的控制器。

功能只有几个：

• 读取一个开关
• 采集一个ADC电压
• 控制两个继电器
• 接收几帧CAN报文
• 根据状态发送几帧CAN报文

如果这是一个小项目，其实根本不需要AUTOSAR。

你完全可以自己写：

intmain(void){MCU_Init();CAN_Init();ADC_Init();GPIO_Init();while(1){Read_Input();Read_CAN();Application_Control();Update_Output();Send_CAN();}}

是不是很熟悉？

很多嵌入式开发，最开始就是这么干的。

初始化MCU。

初始化外设。

然后进入一个死循环。

周期性采集输入、运行控制逻辑、更新输出。

只要功能不复杂，这套方案非常直接。

甚至可以说：

简单项目里，传统嵌入式往往才是效率最高的方案。

02 问题出现在ECU越来越复杂之后

现在我们把需求稍微扩大一点。

这个ECU开始需要：

• 300多帧CAN报文
• 诊断UDS
• 网络管理NM
• Bootloader
• NVM数据存储
• 故障管理DEM
• Watchdog
• CAN休眠和唤醒
• LIN通信
• 多核调度
• 功能安全
• E2E保护
• 标定
• OTA升级

这时候，你会发现事情开始失控了。

以前一个CAN模块可能只有：

Can_Init();Can_Send();Can_Receive();

现在CAN下面却突然多出来一堆东西：

CAN Driver CanIf CanTp PduR Com CanSM CanNm ComM DCM DEM E2E

而且每个模块之间还有调用关系。

更麻烦的是，公司里可能有几十个ECU项目。

A项目有一套CAN代码。

B项目又自己写一套。

C项目换了MCU之后全部重写。

换一个供应商，又重新适配一次。

软件越来越大以后，真正麻烦的已经不是：

“这个CAN报文怎么发？”

而是：

这么多软件模块，怎么统一组织？

这就是AUTOSAR Classic开始发挥作用的地方。

03 AUTOSAR Classic是什么？

如果一定要用一句比较容易理解的话解释AUTOSAR Classic：

它是在传统MCU嵌入式开发之上，建立了一套标准化的软件架构。

它并没有抛弃我们熟悉的MCU。

也没有让汽车ECU突然变成电脑。

Classic Platform下面跑的，很多依然是：

• Infineon AURIX
• NXP S32K
• Renesas RH850
• STM32一类MCU架构

程序依然是C语言为主。

依然有中断。

依然有ADC。

依然有PWM。

依然有CAN Controller。

依然需要GPIO。

所以做Classic AUTOSAR的人，本质上还是嵌入式开发。

只是软件被重新组织了。

04 Classic最大的变化：软件开始“分层”

传统项目可能是这样：

Application ↓ 自己写的CAN代码 ↓ 自己写的Driver ↓ MCU

Classic AUTOSAR则开始分层。

大概可以理解成：

这里出现了几个后面会经常见到的名词：

ASW

Application Software。

也就是应用软件。

比如：

整车状态管理 扭矩控制 热管理 高压控制 充电控制 能量管理

这些是真正和“这台车要实现什么功能”有关的代码。

RTE

Runtime Environment。

可以暂时理解成：

应用层和底层之间的中间层。

应用软件不需要到处直接调用底层模块。

很多接口通过RTE连接。

BSW

Basic Software。

基础软件。

比如：

CAN通信 诊断 网络管理 NVM 故障管理 ECU状态管理 Watchdog

很多原来每个项目自己写的公共功能，被标准化了。

MCAL

Microcontroller Abstraction Layer。

微控制器抽象层。

它直接和MCU外设打交道。

比如：

Can Adc Dio Pwm Spi Icu Port Mcu

如果你以前做过单片机开发，这一层会非常亲切。

因为到了这里，终于又能看到寄存器和硬件外设了。

05 所以Classic解决的到底是什么问题？

很多人刚学AUTOSAR的时候，会觉得它特别“绕”。

以前发一帧CAN：

CAN_Send();

现在可能变成：

SWC ↓ RTE ↓ COM ↓ PduR ↓ CanIf ↓ CanDrv ↓ CAN Controller

第一反应通常是：

为什么要搞这么复杂？

因为它解决的不是“发这一帧CAN”。

它解决的是：

当一个整车项目有几十个ECU、几百个开发人员、上万个信号的时候，软件怎么还能继续维护。

这是Classic AUTOSAR真正的价值。

所以Classic最适合的，其实是那些：

实时性强、资源相对受限、功能确定性要求很高的控制类ECU。

比如常见的：

VCU BMS OBC DC/DC MCU BCM EPS ABS/ESC 底盘控制器 热管理控制器

当然，不同车企的架构划分会不一样。

但大方向基本如此。

06 那Adaptive又是什么？

接下来问题来了。

如果Classic已经解决了汽车软件标准化，为什么还需要Adaptive？

因为汽车变了。

以前的ECU主要负责：

控制。

现在很多控制器开始负责：

计算。

尤其是：

智能驾驶 智能座舱 域控制器 中央计算平台 高性能计算HPC

这些系统和传统VCU、BMS完全不是一个量级。

比如自动驾驶控制器可能需要：

• 多核CPU
• GPU
• 几GB甚至几十GB内存
• Linux/QNX
• 以太网
• SOME/IP
• 服务发现
• 动态部署
• 大量算法
• 进程间通信

这时候，再用Classic那一套思路就不太合适了。

于是有了：

AUTOSAR Adaptive Platform。

07 Adaptive更像“汽车里的计算机软件”

Classic通常面对的是MCU。

Adaptive更多面对的是高性能处理器。

可以简单对比一下。

Classic的世界比较像：

TC377 S32K RH850

Adaptive的世界更像：

ARM Cortex-A 高性能SoC 多核CPU GPU Linux / QNX POSIX系统

所以Adaptive的软件开发体验，也会明显不一样。

Classic常见：

C 静态配置 固定Task 固定Runnable 固定内存 确定性调度

Adaptive则更多是：

C++ Process Service POSIX 动态通信 面向服务架构

它已经开始非常接近我们平时看到的Linux应用程序。

08 一个很重要的区别：信号 vs 服务

这个区别非常重要。

Classic的通信思维更多是：

Signal。

比如：

VehicleSpeed BatteryVoltage MotorSpeed TorqueRequest

每个Signal属于某个CAN Message。

然后周期性发送。

例如：

VCU_01 周期：10ms VehicleSpeed TorqueRequest DriveMode

这是典型的Classic汽车通信思维。

Adaptive更倾向：

Service。

比如一个软件提供：

VehicleStateService

其他软件不需要关心：

这个数据到底在哪个CAN ID里？

而是直接：

我要VehicleState这个服务。

服务里面再提供：

GetVehicleSpeed() GetDriveMode() GetPowerState()

这种思维和互联网软件、分布式系统已经越来越接近。

这也是为什么现在汽车行业经常讲：

SOA，Service-Oriented Architecture。

也就是面向服务架构。

09 Classic和Adaptive不是谁替代谁

这里有一个非常容易误解的地方。

很多刚入门的人会认为：

传统嵌入式 ↓ AUTOSAR Classic ↓ AUTOSAR Adaptive

好像这是三代技术。

Adaptive比Classic先进，所以未来Classic会消失。

其实不是。

它们更像三种不同的工具。

就像：

单片机 PLC 工业PC

不能简单说工业PC出来之后PLC就没用了。

汽车里面也是一样。

例如一辆车未来可能同时存在：

中央计算平台可能运行Adaptive。

下面很多实时控制ECU仍然运行Classic。

而非常简单的小控制器，甚至可能继续使用传统嵌入式架构。

三种架构完全可以同时存在于同一辆车上。

10 用一个程序员更容易理解的比喻

如果非要做一个不太严谨但比较容易理解的比喻：

传统嵌入式

像自己盖一栋农村自建房。

地基自己搞。

水电自己接。

门窗自己装。

想怎么改就怎么改。

小项目非常快。

但房子越来越大之后，维护会越来越麻烦。

AUTOSAR Classic

像按照统一建筑规范开发一个大型住宅小区。

水、电、消防、电梯、管道都有标准。

每个供应商按照标准接口交付。

前期设计复杂很多。

但项目规模越大，标准化的价值越明显。

AUTOSAR Adaptive

更像建设一个大型商业综合体或者数据中心。

里面已经不只是：

开灯 关门 控制水泵

而是需要：

服务器 网络 服务 应用 动态部署 高性能计算

所以整个软件架构自然也会发生变化。

11 三种开发方式放在一起看

当然，这张表只是为了帮助入门理解。

真实项目中并不会切得这么绝对。

12 为什么很多AUTOSAR新人学的是Classic？

如果你现在做的是：

VCU BMS OBC DC/DC 车身 底盘 热管理

那你目前最值得学习的，通常还是：

AUTOSAR Classic。

因为现在大量量产控制器仍然基于Classic Platform。

而且Classic里面有一套非常完整的知识体系：

MCAL OS EcuM BswM ComM CanSM CanNm CanIf PduR Com Dcm Dem NvM RTE SWC

你后面看到的绝大部分AUTOSAR工程问题，基本都会围绕这些模块展开。

所以这个系列接下来的主要路线，也会先放在：

AUTOSAR Classic Platform。

Adaptive后面我们也会专门讲。

但如果Classic的基础都没建立起来，一开始同时学两个平台，反而容易把概念搅在一起。

13 做ASW的人还需要懂这些吗？

需要。

这是我特别想说的一点。

很多公司会把软件团队分成：

ASW BSW MCAL

于是很容易产生一种想法：

我是做应用层的，只要把Simulink模型或者控制逻辑写好就行，底层不用懂。

短期来看可能确实可以。

但一旦项目出了问题，例如：

为什么报文没有发出去？ 为什么CAN醒了又睡？ 为什么Runnable没有执行？ 为什么一个Signal写了但是总线上没有？ 为什么ECU启动后几十毫秒应用层才起来？ 为什么诊断能收到请求但没有回复？ 为什么掉电以后数据没有保存？

你会发现这些问题几乎全部跨层。

如果你只知道自己的SWC，很难定位。

所以我们这个系列不会只讲：

“这个参数在DaVinci哪里配置。”

而是会尽量把后面的逻辑讲清楚：

为什么需要这个模块？ 它在整个ECU里面处于什么位置？ 上游是谁？ 下游是谁？ 一次请求到底经过哪些模块？

这也是从0到1系列真正想解决的问题。

14 到这里，你只需要记住三句话

如果这一篇你看完之后只记住三句话，其实就够了。

第一句：

传统嵌入式解决的是“怎么把这个ECU功能做出来”。

第二句：

AUTOSAR Classic解决的是“大规模汽车嵌入式软件怎么标准化地做出来”。

第三句：

AUTOSAR Adaptive解决的是“高性能汽车计算平台上的复杂软件和服务怎么运行”。

至于：

RTE到底怎么工作的？ BSW为什么有这么多模块？ ARXML到底是什么？ DaVinci到底在配置什么？

这些我们后面一篇一篇拆。

不用急。

下一篇

下一篇我们开始正式进入AUTOSAR Classic的内部：

《一张图看懂AUTOSAR Classic完整软件架构》

下一篇非常重要。

因为后面你会见到的：

SWC RTE Com PduR CanIf CanDrv

全部都要先放回这张架构图里。

只要这张图真正看懂，后面AUTOSAR就不会再像一堆莫名其妙的缩写。

车控码农｜AUTOSAR从0到1

不堆概念，不背配置项。

从一个真正的汽车ECU工程开始，把AUTOSAR一点一点拆开。