一、OSEK与AUTOSAR概述

各位同学好，我是老张。做嵌入式实时系统二十年了，从OSEK一路干到AUTOSAR。今天咱们聊聊这个课程的起点——为什么会有OSEK，AUTOSAR又是怎么来的，以及我们为什么要从OSEK往AUTOSAR迁移。

说实话，我刚入行那会儿，车载操作系统还是一片混乱。每家芯片厂、每个ECU供应商都有自己的RTOS，接口不统一，移植一次脱层皮。后来有了OSEK，大家总算有了共同语言。再后来，AUTOSAR来了，把整个架构又往上提了一个层次。

嗯，咱们一步步来看。

1.1 OSEK标准历史与核心概念

OSEK全称是"Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug"，德语，翻译过来就是"汽车电子开放系统和接口"。1993年，德国几所大学和汽车公司（宝马、奔驰、博世等）联合发起了这个项目。

我当年第一次接触OSEK是在一个发动机控制项目上。那时候文档还是德文和英文混着写的，看得我头大。但不得不说，OSEK解决了当时最痛的问题——操作系统接口标准化。

说白了，OSEK定义了一套标准API。你写一个任务，用ActivateTask、TerminateTask、WaitEvent这些函数，不管底层是什么芯片，接口都一样。这在当年可是革命性的。

举个例子，一个典型的OSEK任务代码长这样：

// OSEK任务示例
TASK(EngineControlTask)
{
    EventMaskType event;
    
    while(1)
    {
        // 等待曲轴位置信号
        WaitEvent(EVENT_CRANK_SYNC);
        ClearEvent(EVENT_CRANK_SYNC);
        
        // 计算喷油脉宽
        CalculateInjectionTiming();
        
        // 设置输出比较寄存器
        SetOutputCompare(INJECTION_CH1, injectionPulse);
        
        // 终止任务
        TerminateTask();
    }
}

这段代码我用了十几年，从16位单片机一直移植到32位多核芯片，接口几乎没变过。这就是标准化的力量。

1.2 AUTOSAR标准演进与分层架构

AUTOSAR是2003年启动的，比OSEK晚了整整十年。为什么需要它？因为OSEK只解决了操作系统的问题，但汽车软件越来越复杂，ECU之间的通信、网络管理、诊断、标定……这些OSEK管不了。

我记得2010年第一次做AUTOSAR项目，当时的感觉是：这东西太庞大了。一个简单的CAN报文收发，在OSEK里写个中断服务程序就完了，在AUTOSAR里要经过CAN驱动、CAN接口、PDU路由器、COM模块……一层一层往上走。

但后来我明白了，这种分层是有道理的。你想想看，一个现代汽车有上百个ECU，如果每个ECU都自己管通信、自己管诊断、自己管网络管理，那整车集成就是一场噩梦。

AUTOSAR的分层架构，我习惯用这张图来理解：

这张图我画了很多遍。你看，从下往上：

• MCAL：直接跟硬件打交道，操作寄存器。这部分移植工作量最大
• ECU抽象层：把硬件接口封装成标准API。比如不管你是哪个厂家的CAN控制器，上层看到的接口都一样
• 服务层：提供操作系统、网络管理、诊断等公共服务
• RTE：这是AUTOSAR的精华，它负责SWC之间的通信，屏蔽了ECU内部和ECU之间的差异
• 应用层：写业务逻辑的地方，跟硬件完全解耦

1.3 为什么需要从OSEK迁移到AUTOSAR

这个问题我经常被问到。有些团队OSEK用得挺好的，为什么要折腾？

我的回答是：看你的项目复杂度。

如果你做一个简单的车窗控制器，一个MCU，一个CAN节点，几个IO口，OSEK完全够用。但如果你做的是域控制器、自动驾驶控制器、或者整车控制器，OSEK就力不从心了。

我举几个实际例子：

对比维度	OSEK	AUTOSAR
通信机制	任务间通过事件、资源通信	SWC通过RTE通信，支持S/R、C/S等多种模式
网络管理	没有标准定义，自己实现	标准化的CAN NM、UDP NM
诊断	没有标准接口	标准化的DCM、DEM模块
标定	没有标准支持	通过XCP、CCP标准协议
多核支持	基本不支持	原生支持多核、多分区
软件复用	困难，与硬件耦合度高	容易，硬件无关的SWC可跨项目复用

你看这个表格就明白了。OSEK本质上是一个实时操作系统内核标准，它管的是"任务怎么调度、资源怎么共享"。但现代汽车电子需要的是"整个ECU软件怎么组织、怎么通信、怎么诊断、怎么标定"——这些OSEK管不了。

从OSEK迁移到AUTOSAR，说白了就是：

• 从"操作系统"思维升级到"软件架构"思维
• 从"手写代码"升级到"配置生成代码"
• 从"单ECU开发"升级到"整车级协同开发"

当然，迁移是有代价的。AUTOSAR的学习曲线比OSEK陡得多，配置工具也贵。但如果你做的是中高端项目，这笔投资是值得的。

嗯，这一章就讲到这里。下一章我们开始动手，我会带着大家把一个OSEK项目一步步迁移到AUTOSAR。到时候你们会发现，很多概念其实是相通的，只是换了个马甲。

---