随着处理器运算能力和硬件的高速发展，汽车整车功能越来越多、越来越强。鉴于 ADAS 技术、高品质车载娱乐以及 OTA 远程升级等新增功能的需求，使得 ECU 的网络带宽需求也呈现爆发式增长。这一需求超出了传统车载网络的容量极限，同时也促使车载以太网总线成为车载网络的一员。

由于汽车电子领域硬件平台的多样性，ECU软件开发严重依赖系统硬件和系统配置。整车厂尝试在原有平台或开发新的平台来实现新的功能，而整车厂或零部件生产商原有开发平台不支持硬件，软硬件相关性比较大，一旦硬件发生更改，软件都会被要求重新开发。因此，如何以合理的成本更快地为这些硬件开发或移植嵌入式软件是嵌入式系统开发人员急需解决的问题。汽车开放系统架构( automotive open systems architecture，AUTOSAR） 规范从系统整体结构入手，采用易于理解的、适应变化的分层体系结构，为各分层制定标准接口，从而能很好地解决上述问题。因此，基于 AUTOSAＲ标准实现车载以太网具有一定实用价值。本文以Vector公司的配置工具Da Vinci 和英飞凌AUＲIX /TC297开发板为实验工具，介绍实现符合AUTOSAR 标准的车载以太网。

车载以太网

什么是车载以太网？

车载以太网是一种用以太网连接车内电子单元的新型局域网技术。与普通的以太网使用4对非屏蔽双绞线（UTP）电缆不同，车载以太网在单对非屏蔽双绞线上可实现100Mbit/s甚至1Gbit/s的数据传输速率，同时还应满足汽车行业对高可靠性、低电磁辐射、低功耗、带宽分配、低延迟以及同步实时性等方面的要求。

车载以太网的物理层采用了博通公司的BroadR-Reach技术，BroadR-Reach的物理层（PHY）技术已经由单线对以太网联盟（One-pair Ethernet Alliance，OPEN）标准化，因此有时也称车载以太网为BroadR-Reach（BRR）或OABR（Open Alliance BroadR-Reach）。

车载以太网的MAC层采用IEEE 802.3的接口标准，无需做任何适配即可无缝支持广泛使用的高层网络协议（如TCP/IP）。

车载以太网标准化

在车载以太网的标准化方面，如下4个标准化组织或联盟起到了主要的推动作用，它们是IEEE 802.3和IEEE802.1工作组、汽车开放系统架构联盟AUTOSAR、OPEN联盟以及AVnu联盟，标准化情况汇总见下图。

（1）IEEE

IEEE 802.3制定的局域网标准代表了业界主流的以太网技术，车载以太网技术是在IEEE802.3基础上开发研制的，因此IEEE是目前最为重要的车载以太网国际标准化机构。为了满足车内的要求，涉及到IEEE 802.3和802.1两个工作组内的多个新规范的制定和原有规范的修订，包括PHY规范、AVB规范、单线对数据线供电等。

另外，AVB中有关AV的传输、定时同步等规范还需IEEE的其他技术委员会的标准化，如IEEE1722、IEEE1588等。

（2）OPEN

OPEN联盟于2011年11月由博通（Broadcom）、恩智浦（NXP）以及宝马（BMW）公司发起成立的开放产业联盟，旨在推动将基于以太网的技术标准应用于车内联网。相关单位可通过签署OPEN联盟的规范允可协议成为其成员，参与其相关规范的制定活动。

（3） AUTOSAR

AUTOSAR是由汽车制造商、供应商以及工具开发商发起的联盟，旨在制定一个开放的、标准化的车用软件架构。AUTOSAR的规范包括车用TCP/UDP/IP协议栈。AUTOSAR获得了汽车产业的普遍认可，各制造商将放弃私有标准的开发转而在标准实现上展开竞争，实现AUTOSAR的标准可使多个设备无缝的运行在同一个共享网络上。

（4）AVnu

AVnu联盟是由博通联合思科、哈曼和英特尔成立，致力于推广IEEE 802.1的AVB标准和时间同步网络（TSN）标准，建立认证体系，并解决诸如精确定时、实时同步、带宽预留以及流量整形等重要的技术和性能问题。

软件架构下的车载以太网

AUTOSAR简介

作为汽车电子软件的主要标准，AUTOSAR在总线网络通信方面提供了完整的架构。

在此仅简单介绍AUTOSAR，更多关于AUTOSAR的干货以及资料，可查看牛喀网往期文章：

AUTOSAＲ是面向汽车领域的嵌入式软件体系结构标准。该体系结构采用了分层模型，每一层只能使用下一层的接口，并向上一层提供服务接口，从上至下依次为应用层、运行时环境( run time environment，RTE) 、服务层、ECU 抽象层、微处理器抽象层和一个特殊的复杂驱动。

应用层由各应用软件组件构成。在开发中，可根据其功能进行划分、封装，对各组件实施符合规范的标准接口。各组件通过与RTE的标准接口对实现组件间的通信以及各组件与BSW的通信。

RTE的思想是提供一个虚拟功能总线(virtual functional bus，VFB) ，RTE实质是一个虚拟功能总线的具体实现，支持软件组件之间、基础软件间以及软件组件与基础软件之间的通信。RTE使应用层软件脱离于具体的单个ECU和 BSW。BSW 层又被划分为服务层、ECU抽象层、微处理器抽象层 3 个子层。

服务层主要包含系统服务、内存服务、通信服务等模块，它为应用和基础模块 提供基本服务。

ECU抽象层分为板载设备抽象、内存设备抽象、通信硬件抽象与I/O抽象等。ECU抽象层封装了MCAL以及MCU外围设备的驱动，并且对MCU外围设备的访问进行了统一，使上层应用与ECU硬件相剥离。

MCAL分为MCU驱动、内存驱动、通信驱动与I/O驱动等。MCAL是BSW的最底层，包含了访问 MCU 的驱动。MCAL使上层软件与MCU分离，避免上层软件直接操作硬件。复杂驱动位于RTE层与硬件平台之间，用于驱动复杂的有特殊功能的外设。

复杂驱动位于RTE层与硬件平台之间，用于驱动复杂的有特殊功能的外设。

想学习AUTOSAR的导入实践技术，可参加牛喀网本月21日举办的专题培训班，课程将结合主流工具，对AUTOSAR的理论、思想和实际操作进行全面讲解，一次性解决您在AUTOSAR导入方面的全部问题。

AUTOSAR各层软件的通信通过三类接口实现，分别是标准接口、AUTOSAR接口和标准AUTOSAR接口。其中，标准接口用于BSW各个模块之间的通信，已用C语言定义，如void Adc_Init(const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于软件构件(SW-C)之间的通信或者软件构件和ECU固件(IO硬件抽象、复杂设备驱动)之间的通信，这类接口命名以“Rte_”为前缀。标准AUTOSAR接口用于软件构件存取AUTOSAR服务。依赖这种分层架构和接口定义，AUTOSR显著提高了汽车电子嵌入式软件的可重用性——层级越高者，可重用性越强。值得注意的是：

* 微控制器抽象层层级最低，随微控制器的更换而更换；

* RTE虽然层级仅低于应用层，但由于它负责着应用层和BSW之间的桥梁作用，和硬件的耦合性最高，不具有可重用性；

* 应用层(除传感器、执行器相关的软件构件外)完全独立于硬件，具有绝对的可重用性。

AUTOSAR车载以太网

在 AUTOSAＲ 软件架构中车载以太网主要包含ETH、ETHTRCV、ETHSWT、ETHIF、ETHSM、TCPIP、SOAD 等子模块。AUTOSAR车载以太网软件架构见下图：

ETH 程序抽象Ethernet硬件，为以太网接口提供 统 一 的 接 口，发 送 和 接 收数据并控制Ethernet控制器状态。ETHTRCV提供统一以太网收发器驱动程序，提供独立于硬件统一的接口，用于驱动不同的以太网收发器。ETHSWT 提供统一以太网交换机驱动程序，为控制和配置以太网交换机提供统一的接口，用于驱动不同的以太网交换机并协调MAC学习。ETHIF模块提供标准化接口提供与 ECU 的以太网总线系统的通信，API独立于特定的以太网控制器和收发器。从概念上以太网接口能够通过一个统一接口访问一个或多个以太网驱动程序和以太网收发器驱动程序。这一模块还负责管理VLAN。ETHSM模块为通信管理器提供统一的接口。用于启动和关闭以太网通信。TCP/IP协议栈旨在处理ISO/OSI层模型的2层到4层。这包括但不限于IPv4、IPv6、DHCPv4、DHCPv6、ARP、NDP、TCP、UDP、ICMPv4、ICMPv6 等协议。SOAD 模块是一个适配器层，将 AUTOSAＲ API 与标准套接字API相匹配，并且将PDU ID映射到套接字连接。SOAD模块将AUTOSAR中定义的PDU通信转换成基于Socket的通信。

车载以太网通信流程

车载以太网基于信号/PDU ( protocol data unit) 的通信过程与传统的车载网络CAN通信相似，即多个信号映射到一个PDU，然后一个PDU映射到一个 CAN帧上，最后通过CAN驱动将信号发送出去。

车载以太网基于信号/PDU的通信过程与CAN通信不同的是: 为了节约资源，在传输和接收过程中多个PDU在一个以太网帧中，Fan—Out机制允许通过单播向多个目的地发送一个PDU。PDU映射到以太网帧的位置是动态的，套接字适配器通过添加和删除小标题(PDU标识符和长度) 以区分不同的PDU。

车载以太网发送流程

上层应用通过RTE向LDCOM请求并调用请求函数 Ld Com_Transmit( ) 。基于所提供的PDU ID，将传输请求和有效载荷信息转发到PDUR模块，进行一次数据的传输；其中ID是以太网数据包的PDU ID，PduInfoPtr是一个指向数据结构的指针，该指针包含指向待发送数据的指针以及待发送数据的长度。

在PDUＲ模块中，函数PduＲ_LdComTransmit( )调用函数PduＲ_GetTransmitFctPtr( ) ，通过查表的方式选择数据传输路径，选择使用 CAN 还是使用以太网通信。

SOAD模块提供基于PDU的通信和基于TCP/IP的套接字的通信。通过API TCP / IP _Get Socket For User( ) 指定 Socket 协议(UDP/TCP)和Internet协议版本( IPv4/IET或IPV6/ITE6) 。

TCP/IP模块向上层( 用户)提供UDP和TCP套接字。

传输层将待发送数据传递至 ETNIF 接口层，调用一个函数EthIf_Transmit( ) 并发起以太网数据发送。该函数检查以太网控制的状态和申请发送 Buffer 的状态。若申请发送 Buffer 成功，则直接调用底层 Eth _Transmit ( ) 函数进行发送，ETH 主函数调用 Eth_TxConfirmation( ) 向上层发送确认。

车载以太网接收流程

当总线上有接收数据时:

① 程序配置为接收中断时，将触发EthIsr_0( )来接收数据;

② 当程序配置为查询接收时，将触发 Eth_MainFunction( ) 来接收数据。通过调用 Eth_Ｒeceive( ) 函数，将数据存入对应的存储区中; 若接收成功，则调用接收指示函数 EthIf_ＲxIndication( ) 并通知接口层成功接收一帧数据。

在TCP/IP模块中，调用API Tcp Ip_Ｒx Indication( )并收到 ETHIF 模块返回的接收指示; 通过 Call-Back 函数 TCP / IP _ＲxIndicationFunctions( ) ，通知SOAD模块。

SOAD模块调用API So Ad _ Ｒx Indication ( ) ，收到TCPIP模块返回的接收指示，调用PDUR_So Ad IfＲx Indication( )函数并通知PDUＲ模块；

PDUR模块通过数组 PduＲ _ IfＲx Indication Fct Ptr，选择通过 COM 模块还是 LDCOM 模块传递接收数据；最后应用层通过 ＲTE 读取接收数据。

基于AUTOSAR的车载以太网实现

运用 Vector 公司提供的Da Vinci Developer和Da Vinci Configurator 进行车载以太网的配置，用EB Tresos配置PORT口和MCU模块，使用Tasking 编译软件进行软件集成编译。系统运行于英飞凌AURIX/TC297开发板上。。

车载以太网配置

Vector 公司提供的车载以太网开发流程如下图所示。

Da Vinci Configurator主要用来配置BSW和RTE并进行配置代码的生成。因篇幅原因，本文只对SOAD模块和TCP/IP模块配置进行描述。

SOAD主要完成Socket Connection、发送路径和接受路径配置; 为了支持一个本地套接字上的多个通信伙伴( 例如，在一个服务器上的多个客户端) ，套接字适配器可以定义多个套接字连接，这些套接字之间的链接一般通过远程地址进行区别。

在UDP的情况下，如果在套接字连接组中启用消息接受筛选器并且设置远程地址或通配符，则可以在其自身打开套接字连接。

Vector支持未设置的IP地址或端口的特殊值，将端口设置为通配符，设置端口为0。将IP地址配置为通配符空出远程IP地址字段；如果未设置 IP 地址或端口，则不会打开套接字链接。

发送路径配置，添加PDU路由并选择引用的PDU和上层API类型。

添加一个或多个( Fan-Out)PDU路由目的地并引用上述步骤中创建的套接字连接。接收路径配置，添加套接字路由和引用套接字连接，添加一个( 不支持Fan—Out) 套接字路由目的地并选择上层 PDU。

TCP/IP配置主要包括 Socket Owner 和地址分配配置。

TCP/IP允许多用户使用TCP/IP模 块，AUTOSAＲ统称它们为“socket owners ”。Sock Adaptor( SOAD) 是标准的套接字使用者，其他的socket使用者可以方便地被添加，例如 CDD( 复杂设备驱动程序) 。Vector 还添加了一个特殊的socket 所有者“DHCPv4Server”。多播、单播地址分配方法的配置在IPv4和IPv6之间有所不同，原因是IPv6可以同时处理一个 IP 控制器上的多个单播地址，而 IPv4 仅支持每个 IP 控制器的一个单播地址。

车载以太网集成测试

使用Tasking编译软件进行软件集成编译，最后生成可执行文件。编译流程见下图。

使用 Wireshark 以太网测试软件进行系统测试，测试结果见下图。

测试结果分析

由上图可知，以太网数据帧中源MAC地址为02∶00∶00∶00∶00∶02目的MAC地址为A8∶1E∶84∶4F∶82∶D9，这与Vector Da Vinci软件开发工具配置一致。Vector Da Vinci 软件开发工具配置的源 MAC 地址见下图。

目的MAC地址是通过ARP查询配置的ARP静态表来获取的，ARP静态表配置见下图。

以太网数据帧中源IP地址为192.168.1.200，目的IP地址为192.168.1.203，这与Vector DaVinci软件开发工具配置一致。Vector DaVinci软件开发工具配置的源IP地址见下图。

由测试结果可知，以太网数据帧中发送数据为0x0C和0x12，数据长度为2，这与在测试软件中测试数据和长度一致。

结束语

基于Vector公司的AUTOSAR软件开发工具和EB Tresos软件开发工具可实现基于UDP的车载以太网的通信。本文只是对基于UDP以太网协议进行了详细介绍，为了满足汽车多方面的需求以及功能应用，还需要对以太网上层协议加以研究( 例如 SOME /IP、DOIP 等) 。随着ADAS技术和智能汽车的发展以及BroadＲ-Ｒeach和TSN技术的推动，车载以太网逐渐成为下一代车载网络标准。AUTOSAR规范采用易于理解的、适应变化的分层体系结构为各分层制订标准接口，使得软件具有良好的移植性，以合理的成本快速开发出可靠的软件。因此，研究符合AUTOSAR标准的车载以太网对车载以太网的发展有着重要的意义。