AUTOSAR初了解

转载于：https://www.zhihu.com/question/313797183

不知道题主是否有看过AUTOSAR的最新版本规范？如果要用A4纸打印出来，估计要超过2米多高。光是看到这么厚的规范，估计很多朋友内心已经已经很绝望了。

那么，这么厚的AUOTSAR规范，我们要怎么去掌握它呢？

一、角色定位

先别急，首先我们得问问自己目前的角色是什么？对于题主来说，你得问问自己，即将成为什么角色。因为你的角色不同，那么AUTOSAR应用的场景也不同，自然AUTOSAR工程师要做的事情也是不同的，对AUTOSAR掌握的程度和角度也不一样。

提供你下述几个选项：

1. 整车厂OEM

2. 零部件Tier1

\3. 基础软件包/工具供应商

\4. 半导体厂商

现在对于大多人来说，应用AUTOSAR的角色都是整车厂OEM或者零部件Tier1。在这里，我们就先谈这两个。

基于OEM或者Tier 1的角色去学习AUTOSAR，我们就会轻松很多，2米多高的AUTOSAR规范，我们需要关心的或者需要精通的就不是很多，AUTOSAR很多规范是给基础软件包/工具供应商或者半导体厂商参考去实现具体的BSW协议栈或者芯片对应的MCAL.

如果是整车厂OEM角色学习AUTOSAR的话,主要的应用场景:

\1. 整车E/E架构设计

\2. 应用层的软件组件设计

基于这两个应用场景，我们只需要去深入了解AUTOSAR的方法论及基于AUTOSAR的方法论的SWC设计。

如果是零部件供应商Tier1角色学习AUTOSAR的话，又可以细分你目前工作的主要职责是什么，提供你几个选项:

1. 架构工程师

2. 算法工程师

3. 底层芯片驱动工程师

4. BSW协议栈工程师

5. 复杂设备驱动工程师

6. 集成工程师

针对不同工作职责，你需要深入了解AUTOSAR的侧重也有差别:

针对**架构工程师，**你仅仅需要深入了解AUTOSAR的方法论及SWC的设计方法及技巧

针对**算法工程师，**你仅仅需要深入了解SWC的设计方法

针对**底层芯片驱动工程师，**你仅仅需要深入了解芯片抽象层MCAL的各个功能模块的具体应用细节

针对BSW协议栈工程师，你仅仅需要了解OS，ComStack，DiagStack，Memory Stack，WgdStack等协议栈的功能及应用细节

针对复杂设备驱动工程师，你仅仅需要了解复杂设备驱动的AUTOSAR接口定义方式

针对集成工程师，你仅仅需要深入了解RTE的运行集成及RTE相关的应用配置

二：掌握技能Classic AUTOSAR、Linux和C++

如果你已经知道你的角色定位，你就知道你该学习哪些内容。那么，接下来就是怎么去学AUTOSAR？

先来结论：从Classic AUTOSAR 入门，你需要的基础：Linux和C++

上述更多谈的是Classic AUTOSAR，目前很多大数据，车联网，自动驾驶等等新需求，需要新的Adaptive AUTOSAR支持，但不等于说Adaptive AUTOSAR出现，Classic AUTOSAR就可以淘汰了。两者是是可以共存的一种方式。

Classic AUTOSAR 适用于实时控制，资源有限的控制器上，目前大多数的跟传感器或者执行器相连的控制器都适用。

Adaptive AUTOSAR 更适用于具有较强计算能力的芯片的控制器上，可以实现较大数据吞吐和计算能力的控制器上，一般不用于实时控制，如Domain/Zone控制器及“Vehicle Computer”。

【如果你还不了解CP和AP是什么，可以查看文章：【精通AUTOSAR】第一章：AUTOSAR的未来: AP是否会取代CP？，在此我就不多赘述了】

针对Adaptive AUTOSAR的入门，也建议你从Classic AUTOSAR入门，Adaptive AUTOSAR规范中定义的很多中间件功能族或者服务都是从Classic AUTOSAR演化而来，如果你有一定的Classic AUTOSAR的基础，那么理解Adaptive AUTOSAR也会简单很多。

对于Adaptive AUTOSAR的学习，还需要你有一定的Linux基础，毕竟Adaptive AUTOSAR是在Linux这种操作系统之上的中间件规范。同时Adaptive AUTOSAR是基于C++实现的，故还需要你有C++的基本编程经验，满足上述两个先入条件，我们就可以大胆尝试学习Adaptive AUTOSAR的应用了，Adaptive AUTOSAR不同于Classic AUTOSAR，职责划分很明晰，Adaptive AUTOSAR更侧重于应用层的应用，故学习Adaptive AUTOSAR，我们着重学习：

\1. Adaptive AUTOSAR的方法论

\2. SOA的架构

\3. SOA的基于SOME-IP的实现机理

\4. Application的SWC设计

三、最后

说起来简单，但现实很残酷，虽然你只需要仅仅深入关注某一方面，但没有一个人给你指引入门，其实是很难学会的。

现实工作单位中有两种接受知识方式：

一种是比较稳定型的单位，比如汽车电子行业大多数企业，老员工通常不会把自己掌握的知识和技能无私传授给新进的员工，新进的员工通常需要在项目中自己积累，这种知识积累相对比较慢，通常需要好几年时间才会有些许积累。

另一种是竞争非常激烈的单位，如金融行业，企业一旦招了新员工，需要短时间类胜任工作，那么就需要把知识系统地在短时间类传授给新员工。针对汽车电子行业，就吹笙了很多专业的培训机构，聘请专业有相关的经验的专业，把相关的知识和经验在短时间类传授给学员，这样学员就可以在短时间入门，成长自己。

---

本文主要以普及CAN通信基本原理为目的，如有从事相关领域或者有意从事车载嵌入式开发的读友们欢迎留言探讨。

本文为「AUTOSAR CAN Communication/AUTOSAR CAN通信」的基础篇。

嵌入式攻城狮：AUTOSAR CAN Communication/AUTOSAR CAN通信10 赞同 · 3 评论文章

本文含有关键字如下。

CAN通信应用，CAN的概要规格，CAN特征，CAN数据通信机制，CAN数据帧

CAN通信应用

CAN是Controller Area Network（控制器区域网络）的缩写，它是一种串行总线协议，旨在代替用于连接组成车载应用程序的系统和传感器的传统多线配置方法。 CAN于1986年在SAE世界代表大会上正式发布，此后于2008年被要求在美国销售的车辆上使用CAN。 在开发CAN时，请记住，车载微控制器和设备可以在不通过主机的情况下进行通信。 单线或双线网络数据总线用于组件间通信，并且最高可以达到1 Mbps的通信速度。

CAN网络由多个ECU（电子控制器单元）组成并且通过事先在ECU中写好的代码与所定义好的ECU进行互动并且实现汽车制造商所定义好的某一类功能（如汽车上的仪表盘就是通过多个ECU互动将信息反映在仪表盘上）。车辆内部CAN参考图如下。

图1 CAN通信应用参考图

CAN的概要规格

常用到的高速CAN(HighSpeed CAN)在ISO11898-2中的定义如下。

网络配置	多主竞争式(CSMA/CA方式)
通信速度	MAX1Mbps
传输类型	2线制
链接方式	总线类型
传输方式	半双工通信
同步方式	Recessive→Dominant时，所有节点同步
其他特征	● 系统灵活性（易于添加和删除节点） ● 错误检测/通知/恢复功能 ● 内置控制器的通用MCU，收发器数量多，开发工具丰富
适用范围	用作独立系统间耦合、车辆运动控制系统等汽车核心单元的主网络

CAN特征

连接到网络的通信设备一般称为节点，但在CAN中，它是电子控制单元（ECU）。通信线路称为总线，向总线传输数据称为总线访问。

图2 线型总拓扑概念图

ECU（电子控制器单元）是由微控制单元(Microcontroller Unit；MCU) 与收发器（Transceiver）组成。ECU使用电子控制控制器不仅控制发动机和底盘控制之类的核心，而且还控制诸如前灯，汽车音响和空调之类的电气设备，从而为汽车的电气化和自动化提供支持。

电子控制单元（ECU）一般由MCU和CAN收发器组成，CAN收发器向CAN总线或者MCU负责传输和接收CAN帧（CAN Frame），MCU则按照CAN通信协议进行进一步处理。

图3 ECU组成概念图

CAN的特性如下所示。

1. 线型总线拓扑

连接多个节点的网络拓扑结构（对网络的形状进行建模）有环型、星型和线型，但CAN采用线型。 它具有简单的结构，可以轻松添加和删除节点以及设计网络。

图4 CAN线型总拓扑概念图

2. 多主竞争式总线结构，其中所有电子控制单元 (ECU) 都充当主站

只要总线空闲，就可以从任何单元开始通信。

无需指定电子控制单元（ECU）即可发送，任何电子控制单元（ECU）都可以成为主站。

3. 通过 CSMA/CA 方法根据优先级访问总线

提前访问总线的单元可以获得发送权。

如果多个单元同时开始发送，则发送优先级高（ID值较小）的报文的电子控制单元（ECU）获得发送权。在CSMA/CA方式中，尽量避免在使用总线的同时从其他节点传输数据，但现实中存在多个节点同时传输数据而发生冲突的情况。CAN 具有确定其优先级的通信仲裁机制。

4. 使用差分电压传输提高抗噪性能

通过两条通信线（双绞线）产生的电压差传输数据。

CAN 使用称为 CANH / CANL 的通信线路执行传输和接收。没有电位差的信号称为隐性(Recessive)信号，其逻辑值为1。具有电位差的信号称为显性（Dominant）信号，其逻辑值0。如果通信总线上发生显性和隐性(Recessive)冲突，则显性（Dominant）优先。

由于从外部施加的噪声是相同的，因此不会产生电压差，即使产生噪声也不易受到影响。

图5 CAN差分电压原理图

5. 错误检测和处理

所有电子控制单元（ECU）都可以检测到错误。

检测到错误的电子控制单元（ECU）立即将错误通知所有其他电子控制单元（ECU）。当发送消息的电子控制单元（ECU）检测到错误时，它会强制终止传输并重复传输，直到消息正常传输为止。

CAN数据通信机制

CAN 通信以称为帧(Frame)的单位进行。

每个祯（Frame）的作用如下所示。

• 数据帧(Data Frame)

发送单元向接收单元发送数据的帧。

• 远程帧(Remote Frame)

接收单元请求发送单元发送数据的帧。

• 错误帧(Error Frame)

当在传输/接收过程中检测到某些错误时，用于通知其他单元错误的帧。

• 超载帧(Overload Frame)

接收单元通知它未准备好接收的帧。

在CAN中，通过从需要数据的 ECU 发送远程帧并从具有该数据的 ECU 返回数据帧来建立通信。 排除数据帧中的控制位，实际可传输的最大数据量为 8 个字节（CAN FD 最多 64 个字节）。

近年来，各个ECU之间的信息交换量变得非常大，因此为了降低总线占用率，很少使用远程帧，常见的是周期性地向各个ECU传输数据帧的方法。

CAN数据帧

数据帧有两种帧格式：标准格式（Standard Format）和扩展格式(Extended Format)。

在扩展格式中，在Base ID 11bit的基础上增加了ID Extension 18bit，可以表示一个总长度为29bit的ID。

如果标准格式和扩展格式同时发送相同的ID，则标准格式优先。

• 标准格式（Standard Format）：

图6 标准格式（Standard Format）数据帧

SOF(Start Of Frame)，是一个 1 位显性区，用于通知数据帧的开始。

Arbitration Field（仲裁领域），判断帧优先级的区域。

Base ID：设置标准 ID 11 位

RTR：区分数据帧和远程帧

Control Field（控制领域），由IDE、FDF、DLC组成的区域。

IDE：区分标准格式和扩展格式

FDF：区分CAN和CAN FD的位

DLC：代表数据长度

Data Field（数据字段），储存数据的区域。

CRC Field（CRC字段），判断帧传输错误的区域。

ACK Field（确认字段），表示正常接收信号的区域。

EOF(End Of Frame)，用于通知数据帧结束的区域。

• 扩展格式(Extended Format) ：

图7 扩展格式(Extended Format)数据帧

仲裁字段和控制字段在扩展格式上不同于标准格式，其余部分与标准格式相同。

扩展格式是一种常用于公共汽车和卡车等大型车辆的CAN通信的格式。

Arbitration Field（仲裁领域），判断帧优先级的区域。

Base ID：设置标准的 11 位 ID

SRR：1 位隐性固定，带替代远程请求位

IDE：标识符扩展位用于区分 1 位隐性固定、标准格式和扩展格式。

ID Extension：可设置18位扩展ID，与Base ID共可显示29位ID。

RTR：区分数据帧和远程帧

Control Field（控制领域），由 FDF、r0、DLC 组成的区域。

FDF：区分CAN和CAN FD的位

R0：保留区域

DLC：表示数据长度