点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
![]()
Eth Driver将作为配置以太网的底层驱动，不仅能够被EthIf来进行调用，同时能够满足Eth收发器驱动的调用需求，因为有必要深入了解下车载以太网驱动(Eth Driver)在整个AUTOSAR层级中所扮演的重要作用。
如下图1所示，Ethernet If模块不仅会直接控制Ethernet Driver，如果存在Ethernet Switch驱动或者Ethernet Transiver驱动时，那么就会间接控制Ethernet Driver模块，总而言之，以太网驱动不仅能够完成以太网数据的正常收发，同时也能够实现针对以太网网关或者以太网收发器的直接配置。
![]( "image-20230405182321227")
图1 Ethernet Driver与其他以太网驱动关系AUTOSAR层次关系
按照AUTOSAR标准文档规范，有关Eth Driver模块在整个AUTOSAR软件架构的具体位置描述如下图2所示：
![]( "image-20230405182929275")
图2 Eth Driver与以太网协议栈关系如上图所示，可以得出如下几个基本结论：
一个以太网协议栈中可以存在多家供应商的以太网控制器，同时针对每家供应商的控制器进行单独控制，互不影响；
同一供应商的以太网控制器可以存在多个，但使用的以太网控制器驱动可以仅使用同一套；
上述三家不同供应商的以太网驱动作为标准AUTOSAR MCAL的一部分，能够完全实现与底层硬件的解耦；
模块主体功能
Eth Driver作为车载以太网协议栈最为重要的底层构件，小T将带领大家从以下几个层面初步了解认识以太网驱动：
驱动索引规则
如下图3所示，每个以太网驱动彼此都是独立的，同时其索引编号是从0开始，但是每个驱动内部的bufidx均可以从0开始，彼此之间互不干扰。
![]( "image-20230405183402454")
图3 Eth Driver索引关系数据发送过程
上层应用如果需要通过Eth Driver将数据发送出去，那么就需要通过EthIf模块间接调用Eth Driver的发送函数Eth_Transmit来完成数据的发送。
其中EthIf模块的数据发送功能分为两者模式，一种是Polling模式，另外一种就是Interrupt模式，一般而言都优先采用中断模式来满足系统实时性要求。
如下图4为Polling模式，在Polling模式中可以看到在EthIf_MainfunctionTx函数中会去轮询是否发送成功的标志，这个也是Polling模式的典型特征。
Polling模式
![]( "image-20230318105955057")
图4 数据发送Polling模式Interrupt模式
如下图5所示为以太网数据发送的中断模式，中断模式相比Polling模式可以看出并没有使用到EthIf_MainfunctionTx函数，而是使用Eth模块的中断函数来确认发送是否成功。
![]( "image-20230318110050920")
图5 数据发送中断模式数据接收功能
同理相比数据发送功能，EthIf模块的数据接收功能也可以分为Polling模式与中断模式两种，如下图9所示为EthIf模块的数据接收Polling模式。
如下图6所示，如果EthIf模块数据接收采用Polling模式，那么就需要使用到EthIf_MainfunctionRx函数，在该函数中去调用EthIf_RxIndication来告知上层数据已成功被接收，使用该模式会大大降低数据接收效率，一般接收优先采用中断模式。
Polling模式
![]( "image-20230318111736031")
图6 数据接收Polling模式Interrupt模式
如下图7所示为EthIf模块的数据接收中断功能，在该模式中可以看到通过Eth模块通过中断函数来进而告知上层数据已被接收。
![]( "image-20230318111835722")
图7 数据接收中断模式驱动特性简介
以太网驱动相比其他驱动而言，存在很多诸多独有的特性，小T将会带领大家来了解这些特性，争取对这些特性有个基本的认识，以便我们对以太网驱动有个较为全面的了解，应用它时也会更加得心应手。
以下列举了以太网驱动(网卡)常见的三种特性：Offloading 特性，硬件TimeStamp特性，QoS特性。
Offloading特性
“Offload"顾名思义表示卸载的意思，那么给谁卸载以及卸载什么呢？其实该特性存在的目的就是为了给CPU卸载，卸载的方式如将CRC计算交给硬件来做，或者分包组包的动作也放在硬件中来处理，从而减小这部分在以太网协议栈中的占用时间，降低软件运行延迟造成的性能不足以及CPU loading过高等问题。
在AUTOSAR规范中针对以太网驱动(Eth Driver)发送或者接收报文的CRC进行了Offloading的特别说明如下：
对于IPV4帧，如果EthCtrlEnableOffloadChecksumIPv4设置成TRUE，那么就可以Offloading CRC；
对于ICMP帧，如果 EthCtrlEnableOffloadChecksumICMP设置成TRUE，那么就可以Offloading CRC；
对于TCP帧，如果 EthCtrlEnableOffloadChecksumTCP 设置成TRUE，那么就可以Offloading CRC；
对于UDP帧，如果 EthCtrlEnableOffloadChecksumUDP设置成TRUE，那么就可以Offloading CRC；
值得注意的是这些CRC计算都仅会在硬件中完成，对于接收方而言，CRC校验检测会通过硬件来完成，如果CRC校验不通过，那么就会丢弃该接收到的帧。
硬件TimeStamp特性
大家相比CAN时间同步有了一个基本的认识与了解，与CAN时间同步对比，以太网时间同步协议采用的IEEE1588或者IEEE802.1AS的PTP(Precise Time Protocal)协议，该协议需要确认使用的网卡(MAC)是否本身支持。
该协议使用到通过底层硬件MAC来打上对应的以太网报文收发的时间戳，能够最大限度地降低软件时间戳所带来的不确定性，将时间同步精度能够做到微秒甚至是纳微秒级别。
AUTOSAR规范中定义的EthTsync模块使用的是双步端延时PTP时间同步协议，如下为基于该协议的Time Master与Time Slave两者之间的交互关系，后期也会针对EthTsync模块进行单一讲解，敬请关注。
![]( "PTP时间同步")
图8 双步以太网端延时机制PTP时间同步协议如上图8所示，如果是基于单步模式下的以太网端延时机制的PTP时间同步，那么虚线标注的部分则不会有，如果是基于双步模式下的以太网端延时机制的PTP时间同步，那么虚线标注的部分必须要有。
值得注意的是在IEEE802.1AS存在一个GrandMaster概念，需要通过BMCA(Best Master Clock Algorithm)来实现，不过由于汽车内部属于静态网络，因此只会存在唯一的GrandMaster，无需使用到BMCA动态分配确认算法。
以太网硬件实现PTP协议有如下两种方式：
QoS特性
Qos是IEEE 802.1P协议，该协议运行在以太网第二层，用来保证在以太网数据转发拥堵时通过优先级方式来保证重要的数据包能够及时发送出去。
普通的以太网二层报文是不包含优先级字段的，IEEE802.1P是IEEE802.1Q(VLAN标签技术)标准的扩充技术，彼此之间协同工作。
802.1Q虽然定义了标签字段，但是并没有定义与使用优先级，而使用802.1P协议补充之后便可以正常使用优先级，正如IEEE 802.1P与IEEE802.1Q两者协同定义的标签字段如下图9所示：
![]( "QoS协议定义")
图9 IEEE802.1Q标签头信息以太网帧通过QoS特性来通过802.1Q标签中的802.1P用户优先级(COS)来进行标记，其优先级具备8级，从优先级0至优先级7，如下图10所示：
![]( "QoS优先级定义")
图10 COS优先级说明通讯协议介绍
在使用车载以太网驱动的过程中，我们经常性会碰到如下三种常见的通讯协议，这三种通讯协议对于车载以太网正常工作，非常重要：
MII接口通讯协议，用于以太网MAC层与物理层收发器PHY之间的数据传输协议；
MDIO通讯协议，用于以太网MAC层控制PHY的状态设置与获取协议；
DMA通讯协议，用于以太网MAC层与CPU之间的数据搬运通讯协议，提高数据搬运效率，降低CPU负载；
MII接口通讯协议基础介绍
MII接口是IEEE802.3定义的以太网行业标准，该标准就是为了解决，以太网MAC层与PHY之间的兼容性，保证即使更换了不同类型的MAC，PHY始终能够正常工作。
MII接口随着技术的发展与进步，目前已经衍生出了多种增强型MII接口，常用的就有MII，RMII，SMII，SSMII，SSSMII，GMII，RGMII，SGMII ，其中对于车载以太网最为常用的还是RGMII接口。
具体的通讯协议介绍不在本文中进行展开，该接口的选择只要软件上MCAL配置使用对应的MII接口类型，其余都是硬件行为，硬件上保证接口正常连接即可，如下图11所示，介绍了MII接口在以太网硬件连接上的所处关系：
![]( "MII接口传输")
图11 以太网MAC与PHY之间的MII物理连接示意图MDIO协议基础介绍
首先，MDIO是Management Data Input/Output的缩写，且该接口协议在IEEE802.3中也有所体现，是一种专门用于管理MAC与PHY之间的串口数据接口，基本功能如下：
读取PHY相关寄存器的值；
获取PHY的Link及其他工作状态等；
设置对应PHY的工作模式等；
除此之外，MDIO协议接口是一种实时，半双工，串行的数据接口，由两个线组成，一个被称为MDIO线，另外一根则是MDC线。
MDIO线负责数据的传输，MAC与PHY之间可以双向传输，写寄存器时由MAC驱动，读寄存器由PHY驱动，先传高位(MSB)，再传低位(LSB)，且该Pin脚需要上拉1.5kΩ-10kΩ范围内的电阻。
MDC线负责传递时钟同步信号，只能单向通过MAC驱动，且只能在MDC上升沿对MDIO线上的数据进行采样，该MDC允许最大的时间频率一般都通过PHY决定。
一个MDIO接口可支持32个PHY地址，该接口有32个寄存器地址，其中前16个寄存器已经在标准中定义，其余16个则有各个器件厂商自行定义。
根据IEEE802.3协议中将MDIO协议分为两种帧格式，分别为Clause 22与Clause 45，其中Clause 22主要用于千兆以下的以太网PHY，而Clause 45则用于千兆以上的以太网PHY。
接下来就针对Clause 22与Clause 45两者协议的基本使用与区别做个简要说明：
Clause 22读数据帧格式如下：
![]( "image-20230409124146870")
图12 Clause 22 读数据帧格式Clause 22写数据帧格式如下：
![]( "image-20230409124544430")
图13 Clause 22 写数据帧格式Clause 45 地址帧格式如下：
![]( "image-20230409124902076")
图14 Clause 45 地址帧格式Clause 45 读数据帧格式如下：
![]( "image-20230409125023619")
图15 Clause 45 读数据帧格式Clause 45 写数据帧格式如下：
![]( "image-20230409125201789")
图16 Clause 45 写数据帧格式如下图17，小T根据上述Clause 22与Clause 45的帧格式定义，列举了两者之间的帧格式的定义说明以及区别联系，这样便于大家对两者格式的使用有个基本认识。
![]( "clause22与clause 45区别与联系")
图17 Clause 22与Clause 45帧格式区别与联系DMA协议基础介绍
DMA协议对于使用过它的朋友而言，特别是做底层驱动开发的朋友应该不会陌生，DMA就是为了在不需要CPU干预的前提下来实现外设与内存之间的搬运或者内存与内存之间的搬运，那么以太网DMA也是如此，就是为了实现以太网外设与内存之间的数据交换。
本文不会对DMA协议本身做过多的解释说明，旨在说明DMA在以太网数据收发过程中如何起作用，通过如下的两张图来了解认识DMA在以太网数据收发过程中的用途。
以太网DMA发送
如下图18所示，Tx ringbuffer作为DMA描述符，DMA在以太网发送过程中的作用表现：
![]( "以太网DMA发送")
图18 以太网DMA发送过程以太网DMA接收
如下图19所示，Tx Ringbuffer作为DMA描述符，DMA在以太网接收过程中的作用表现：
![]( "以太网DMA接收")
图18 以太网DMA接收过程常用函数总结
为了便于大家更好地使用Eth Driver这个模块，小T整理了关于车载以太网驱动这部分常用的函数接口与功能说明，如下图19所示：
![]( "常用函数接口说明")
图19 以太网驱动常用函数接口2023第六届无人驾驶及智能驾舱中国峰会，5月11-12日，上海
AutoSec 7周年年会暨中国汽车网络安全与数据安全合规峰会，5月11-12日，上海
AES 2023 第四届中国国际汽车以太网峰会，6月8-9日，上海
更多文章
智能网联汽车信息安全综述
会员权益: (点击可进入)谈思实验室VIP会员
谈思实验室专注智能汽车信息安全、预期功能安全、自动驾驶、以太网等汽车创新技术，为汽车行业提供最优质的学习交流服务，并依托强大的产业及专家资源，致力于打造汽车产业一流高效的商务平台。
每年谈思实验室举办数十场线上线下品牌活动，拥有数十个智能汽车创新技术的精品专题社群，覆盖BMW、Daimler、PSA、Audi、Volvo、Nissan、广汽、一汽、上汽、蔚来等近百家国内国际领先的汽车厂商专家，已经服务上万名智能汽车行业上下游产业链从业者。专属社群有：信息安全、功能安全、自动驾驶、TARA、渗透测试、SOTIF、WP.29、以太网、物联网安全等，现专题社群仍然开放，入满即止。
扫描二维码添加微信，根据提示，可以进入有意向的专题交流群，享受最新资讯及与业内专家互动机会。
