基于AUTOSAR标准的以太网诊断通信实现

章鸿滨,徐旭,黄熙,钟再敏

(同济大学汽车学院，上海 200092)

基于AUTOSAR标准的以太网诊断通信实现

章鸿滨,徐旭,黄熙,钟再敏

(同济大学汽车学院，上海 200092)

在AUTOSAR标准下实现了基于以太网的诊断，并简要分析了基于以太网诊断通信的优势。将开源的TCP/IP协议栈LwIP移植进AUTOSAR的基础软件层，在此基础上，构建基于以太网的通信协议栈，从下到上依次为以太网驱动、以太网接口、TCP/IP协议栈、套接字适配器。在以太网通信协议栈的基础之上加入与诊断通信相关的模块，分别是基于IP协议的诊断、PDU Router 和诊断通信管理，实现基于AUTOSAR标准的以太网诊断通信。并设计相应的诊断上位机测试UDS诊断服务，说明基于以太网诊断通信在大数据量传输过程中具有基于CAN诊断通信无可比拟的优越性。

AUTOSAR标准；TCP/IP协议栈；UDS协议；基于IP协议的诊断通信

0 引言

车载诊断通信长期以来是以CAN网络为主，但是CAN网络的带宽限制了诊断仪与ECU之间的通信速率，尤其在读取的故障码涉及成百上千个字节的数据时，诊断仪与ECU之间通信的时间开销亟待优化。基于以太网的诊断通信将充分利用以太网高带宽的优点，让诊断仪与ECU之间建立起高速率的数据传输通道。文中基于AUTOSAR标准，移植开源TCP/IP协议栈LwIP到AUTOSAR的软件架构下，实现了基于以太网和UDS协议的诊断通信，并对其相关的UDS诊断服务进行测试和验证。

1 AUTOSAR架构下以太网通信协议栈

在AUTOSAR架构下以太网的通信协议栈[1]如图1下半部

分双点划线框所示，其中标准化的模块包括以太网驱动模块(Ethernet Driver)、以太网接口模块(Ethernet Interface)、中间的TCP/IP协议栈以及套接字适配器模块(Soaket Adaptor)。这4个模块都属于基础软件层，其中以太网驱动模块属于微控制器抽象层(Microcontroller Abstraction Layer )，以太网接口模块属于ECU抽象层，TCP/IP协议栈和套接字适配器模块属于通信服务层。后续，基于以太网的诊断就是在以太网通信协议栈进行通信的。考虑诊断应用的实现，以太网通信协议栈之上还有3个标准的基础软件模块，分别是基于IP协议的诊断通信(Diagnostic Communication Over IP)、协议数据单元路由器(PDU Router)和诊断通信管理者(Diagnostic Communication Manager)，如图1上半部分双点划线框所示。

图1 AUTOSAR架构下基于以太网的诊断通信

1.1 以太网驱动层

以太网驱动层[2]在AUTOSAR架构下属于基础软件层中的微控制器抽象层，提供初始化、配置和数据传输服务，是与微控制器类型直接相关的。文中实验采用的平台是英飞凌的TC275芯片，主芯片内部带有以太网MAC层，控制板上集成了以太网物理层芯片TJA1100，如图2所示。

图2 TJA1100周边电路原理图

因此在对以太网控制器进行初始化的时候，必须对以太网MAC层和物理层芯片同时初始化，并保证两者工作模式匹配。TC275芯片以太网控制器的工作模式是RMII，因此以太网MAC层和以太网物理层之间数据传输用了4根数据线，收发各占两根数据线，在RMII模式下以太网数据传输的时钟频率是50 MHz。以太网MAC层可以通过MDIO控制和读取物理层芯片的工作状态，避免数据链路拥堵时传输数据，导致数据链路进一步恶化。MDIO控制包含两根线，一根是时钟线，另一根是数据线，标准情况下时钟线的时钟频率是5 MHz。在初始化以太网物理层芯片时，作者正是利用MDIO初始化以太网物理层芯片内部的寄存器。

1.2 以太网接口层

以太网接口层[3]负责封装底层以太网控制器的差异包括以太网控制器在硬件上的分布，为上层提供一个统一的接口。如图3所示，硬件上可能会有多个不同类型的以太网控制器(A、B、C型)存在，以太网接口层主要工作是将底层Ethernet Driver的函数进一步封装成统一的API，在统一的API中会有一个参数表示不同以太网控制器的ID，方便应用程序中使用不同的以太网控制器。例如下面以太网接口层的标准函数EthIf_SetControllerMode(uint8 CtrlIdx, Eth_ModeType CtrlMode)，它有两个参数，一个参数CtrlIdx用于指定以太网控制器的ID，另一个参数CtrlMode用于指定该以太网控制器的工作模式。若需设定不同以太网控制器的工作模式，上层模块调用的API都是一样的，只需修改参数CtrlIdx。

图3 以太网接口层

1.3 TCP/IP协议栈

该部分的主要工作是寻找一个适合嵌入式系统的TCP/IP协议栈，并把它移植到AUTOSAR软件架构下。嵌入式设备要连入因特网，它就必须遵循网络的通信协议，即TCP/IP协议。从协议分层模型方面来讲，TCP/IP由4个层次组成：网络接口层、网络层、传输层、应用层。LwIP是一款主要应用于嵌入式领域开源的TCP/IP协议栈。

LwIP的移植可以分为两类：第一类是只移植内核核心，此时用户应用程序编写只能基于Raw/Callback API进行；第二类是移植内核核心和上层API函数模块，此时用户可以使用所有3种API进行编程，即除了Raw/Callback API外，还有Sequential API和BSD-style socket API。第一种移植比较简单，移植者只需完成几个头文件的定义，同时根据使用的具体的以太网控制器完成驱动的编写即可。第二种移植在第一种移植的基础之上，还必须使用操作系统提供的邮箱和信号量机制，完成操作系统模拟层的移植[4]。

AUTOSAR中的OS源于OSEK，在OSEK的OS基础上加入了调度表、时间保护和内存保护[5]，但是没有提供邮箱和信号量。因此，若要完成带操作系统模拟层的LwIP协议栈的移植，就必须利用AUTOSAR的OS实现邮箱和信号量机制。

1.3.1 邮箱的实现

在LwIP中，上层API函数(应用层调用的API)与协议栈内核之间的数据交互都是通过邮箱来实现的。邮箱的本质是队列，它通常支持两种主要操作：入队和出队。入队操作是把元素添加到队列中，即投递消息到邮箱。出队操作是从队列中删除元素，即从邮箱中取消息。队列遵循先进先出(FIFO)原则，即第一个添加到队列的元素也是第一个离开队列的元素。用链表来实现队列，入队操作就是将节点添加到链表头，出队操作就是从链表尾删除节点。

邮箱中消息的本质是一个指针，API将这个指针传递给内核，内核通过这个指针找到相应的数据处理，反之亦然。在操作系统模拟层环境下，LwIP作为系统的一个任务运行(Tcpip_Task)，该任务完成相关初始化后，会阻塞在一个邮箱上，等待消息、处理数据。这个邮箱内的消息可能来自底层硬件驱动接收到的数据包，也可能来自上层应用程序的API函数调用。当在邮箱内取得消息后，LwIP会对消息进行解析并处理相关的数据，处理结束后任务继续阻塞在邮箱上等待下一条消息。

如图4所示，作者在操作系统中配置了3个任务。Eth_Task负责处理LwIP协议栈提交上来的信息，它与协议栈的任务Tcpip_Task之间利用邮箱进行通信。通过邮箱1将信息传递给Tcpip_Task。Eth_Task通过邮箱2来获取Tcpip_Task提交上来的信息。Tcpip_Task为LwIP协议栈运行所在的任务，负责收发来自上下层任务的以太网报文。收取消息利用的是邮箱1，发送消息给应用层利用邮箱2，发送消息到以太网控制器则直接调用相关API发送，不利用邮箱机制。NetIf_Task为网络接口层任务，负责接收以太网的帧，然后将相关的消息发送到LwIP协议栈的任务Tcpip_Task，消息递交给LwIP协议栈利用邮箱1。

图4 邮箱的工作图解

略去一些只运行一次的初始化任务和与以太网诊断无关的任务，自上而下包含了4个任务Bsw_Task、Eth_Task、Tcpip_Task和NetIf_Task，其中包括两个基本任务(Bsw_Task、NetIf_Task)、两个扩展任务(Eth_Task、Tcpip_Task)。Bsw_Task任务运行DCM、BswM、EcuM等基础软件模块；Eth_Task任务运行DoIP和Socket Adaptor；Tcpip_Task运行TCP/IP Module和Ethernet Interface；NetIf_Task任务运行以太网控制器驱动。其中Bsw_Task、Eth_Task和NetIf_Task是由调度表(Schedule Table)周期性地调度，调度周期为10 ms。Tcpip_Task由系统初始化时激活，一旦激活就一直驻留在操作系统内核中，根据邮箱中是否有消息需要处理，Tcpip_Task会在睡眠状态和运行状态间切换。信号量的实现需要操作系统的支持，此处需要定义操作系统事件给信号量使用，同时让两个扩展任务关联。因为引入了扩展任务，因此需要预估任务堆栈的使用情况，为任务分配合适的堆栈空间,如表1所示。

表1 操作系统任务的堆栈配置

1.3.2 信号量的实现

在使用上层API函数时，上层API函数的实现需要调用内核相关函数来完成，信号量为上层API函数与内核函数执行提供了同步与互斥支持。在应用程序调用某个API函数时，例如Socket绑定特定的服务端口bind函数，API函数会阻塞在一个信号量上，同时请求Tcpip任务调用LwIP内核对应的bind函数，当内核函数执行完成后，便释放信号量，这样原来被阻塞的API函数得以继续执行。在信号量的实现上，作者引入事件机制，让协议栈内核和应用层任务同时绑定同一个事件，并利用相关的算法，实现同步与互斥。

让操作系统事件EVENT_MASK_OsEvent1关联两个任务Eth_Task和Tcpip_Task。系统在初始化时，会先将信号量分配给Tcpip_Task。如图5所示，当Eth_Task需要调用Lwip协议栈的API时， Eth_Task将相关的API调用消息投递到邮箱后，Eth_Task获取信号量，但是此时的信号量已经被占用，信号量结构体中used字段的值为1，因此，Eth_Task主动进入等待事件的状态。在Eth_Task将相关的消息投递到邮箱后，Tcpip协议栈进行处理，调用协议栈的API，处理完成后，将被Tcpip_Task占用的信号量释放。同时，激活Eth_Task等待的事件，使Eth_Task继续运行。

图5 信号量的实现图解

1.4 套接字适配器

套接字适配器[6]是介于TCP/IP 协议栈和DoIP之间的模块，它负责建立诊断通信时需要用到的Socket连接，Socket连接既可以基于UDP协议，也可以基于TCP协议，取决于DoIP中用该连接进行通信的服务是采用UDP协议还是TCP协议，具体可以参看标准文档ISO13400。套接字适配器在接收到诊断相关的报文后，会向上递交给DoIP模块，DoIP处理的报文形式是PDU，因此套接字适配器需要将Socket连接的报文转化成PDU报文。套接字适配器中Socket连接数是静态配置的，连接的个数可以根据需要自行定义，以满足需求为准，因为过多的连接会占用大量的内存。

套接字适配器具有自己的调度函数SoAd_MainFunction()，该调度函数需要被任务周期性地运行。套接字适配器负责建立和维护Socket连接，开发板作为服务端，套接字适配器新建完Socket连接后，绑定特定的端口号会进入监听状态，等待客户端的连接请求。

2 基于AUTOSAR标准的以太网诊断通信

2.1 基于AUTOSAR标准的以太网诊断通信协议栈

如前文所述，基于AUTOSAR标准的以太网诊断通信协议栈是建立在之前的以太网通信协议栈之上，它在以太网通信协议栈之上还有3个标准的基础软件模块，分别是DoIP、PduR和DCM。

2.1.1 DoIP

DoIP[7]是基于IP协议的诊断，是标准文档ISO13400-2的具体实现。进入DoIP的PDU报文结构如表2所示。

表2 DoIP的报文结构

DoIP模块接收到报文后，会根据装载信息类型值来解析装载信息的具体内容，如表3所示。不同的装载信息类型对应着不同的传输层协议，ISO13400里做了具体的规定，例如与诊断相关的装载信息类型(0x8001-0x8003)规定必须是基于TCP协议的连接。DoIP中保存了一张连接许可表，包含诊断仪和ECU的地址，用于判断当前诊断仪请求的连接是否合法。诊断仪在与DCM取得通信之前，必须激活DoIP的路由服务即请求激活路由(0x0005)，这样发送给DCM的诊断报文，即装载信息类型值等于0x8001的报文才会经PDU Router模块路由到DCM模块。DoIP与诊断仪之间的连接是有时间窗口的，因此若要保持长时间的连接，需要发送请求保持连接的报文(0x0007)，请求保持会话窗口。

表3 装载消息的类型

2.1.2 PDU Router

PDU Router[8]模块是PDU报文转发的模块，处理不同通信系统(CAN，Lin，Eth和FlexRay)之间或者不同模块(Com，CanTp，CanIf和DoIP等)的通信数据包。PDU Router没有自己的调度函数(MainFunction)，也没有自己的Buffer，不对报文内容做任何处理，只是根据内部维护的一张静态的路由表进行PDU的转发。

2.1.3 DCM

DCM[9]是实现AUTOSAR诊断通信功能的核心模块，DCM收到支持的诊断服务请求时，通过调用诊断事件管理者(Diagnostic Event Manager)、应用层软件组件或者其他基础软件模块提供的接口，进行相应的故障诊断处理操作。在DCM模块中包含3个子模块，分别是诊断会话DS(Diagnostic Session)、诊断服务调度DSD(Diagnostic Service Dispatcher)、诊断服务处理DSP(Diagnostic Service Processing)。DS模块负责与PDU Router的交互，接收从PDU Router转发来的请求报文并将处理后的响应报文发出,管理整个诊断对话的状态，确保诊断协议的时间性要求。DSD模块作为一个中间模块，负责将诊断请求从DS模块转发到DSP模块中处理，并将DSP处理完诊断请求产生的响应报文转发给DS模块。DSP模块是实际处理诊断服务请求的模块，分析接收到的请求信息，检查信息格式和请求服务是否支持，通过调用DEM、应用层软件组件或者其他基础软件模块提供的接口，进行相应的故障诊断处理操作。

文中采用的诊断服务协议是UDS，DCM模块的实质是在内存中维护一张UDS诊断的服务表，根据接收到的诊断仪的诊断服务请求报文做出相应的处理，其中包含了诊断会话和安全访问的管理。常见的UDS服务见表4。

表4 常用的UDS服务

2.2 以太网诊断通信的测试

以太网诊断通信的测试工具采用MFC进行开发，MFC(Microsoft Foundation Classes)是微软基础类库的简称，诊断测试的上位机界面如图6所示。从面向对象编程的角度看，类是对象的抽象，而对象是类的具体化，是类的实例[10]。一个CAsyncSocket对象就是CAsyncSocket类的一个实例，它最核心的成员是Windows套接字。除套接字本身外，它还封装了所有与套接字直接相关的WinSock函数和各种网络事件的处理函数，其中的网络事件处理函数又被称为回调函数或通知函数。当网络事件发生时，MFC会自动调用套接字对象中相应的回调函数。

在进行诊断通信测试前，先用Ping命令测试下LwIP协议栈的IP层是否正常工作，开发板设置的IP地址是192.168.1.2，主机在进行测试时必须保证网卡的IP地址和开发板的IP地址在同一网段，如图7所示。

诊断客户端的服务器IP设置为192.168.1.2，点击连接按钮，此时诊断上位机与开发板经过3次TCP的握手，与Socket Adaptor模块建立连接。点击激活按钮，诊断上位机会发送包含诊断仪自身地址和请求访问的ECU的地址，DoIP收到请求激活的报文，经过认证后，后续有关诊断的报文就会从DoIP经PDUR路由到DCM模块。此后，用户可以通过点击界面上不同的按钮发送UDS诊断服务请求，与ECU进行诊断通信。

图6 诊断测试的上位机界面

图7 测试电脑与开发板的网络连接

关于UDS诊断服务的测试结果如表5所示。最后一行测试读取特定DTC快照信息，该测试中DTC(0x000001)包含3个字节长度，其包括24个快照信息，用于记录出现该故障时系统此刻的一些状态信息，该快照信息ID的编号从0x0d00到0x0d17，每个快照信息占一个字节，不过分配给每个快照信息的存储空间是4个字节，这样出现故障时可以通过读取DTC的快照信息查看出现故障前3个测试循环的快照信息[11]。该测试中，人为注入系统故障，对应于快照信息0x0d00记录的系统状态。当诊断仪向ECU发送读取DTC快照信息的诊断请求时，ECU需要向诊断仪发送152字节的DTC信息，以太网可以通过一帧报文将所有的DTC信息发送给诊断仪，但是如果采用CAN网络进行传输，至少需要二十几帧的CAN报文才能完整地将DTC信息发送给诊断仪。由此可见，在长报文传输过程中，以太网通信具有CAN无法比拟的优越性，因此在诊断通信中采用以太网进行通信是很有意义的。

表5 UDS诊断服务的测试结果

3 结束语

在AUTOSAR标准下，实现了基于以太网和UDS协议的诊断通信，并对相关的UDS诊断服务进行测试和验证。采用AUTOSAR软件架构，有利于基础软件模块的复用，提高软件的可移植性。基于以太网的诊断通信，充分利用以太网高带宽、传输可靠的优点，让诊断仪与ECU之间建立起高速率、可靠的数据传输通道，在车载诊断中是很有意义的。

【1】AUTOSAR Administration. Specification of TCP/IP Stack V1.1.1[EB/OL].http://www.autosar.org/.

【2】AUTOSAR Administration.Specification of Ethernet Driver V1.5.0[EB/OL].http://www.autosar.org/.

【3】AUTOSAR Administration.Specification of Ethernet Interface V2.2.0[EB/OL].http://www.autosar.org/.

【4】朱升林，欧阳骏，杨晶.嵌入式网络那些事[M].北京：中国水利水电出版社，2015.

【5】AUTOSAR Administration.Specification of Operating System V5.0.0[EB/OL].http://www.autosar.org/.

【6】AUTOSAR Administration.Specification of Socket Adaptor V2.2.0[EB/OL].http://www.autosar.org/.

【7】AUTOSAR Administration.Specification of Diagnostic over IP V1.2.0[EB/OL].http://www.autosar.org/.

【8】AUTOSAR Administration.Specification of PDU Router V4.2.0[EB/OL].http://www.autosar.org/.

【9】AUTOSAR Administration.Specification of Diagnostic Communication Manager V5.2.0[EB/OL].http://www.autosar.org/.

【10】杨传栋,张焕远.Windows网络编程基础教程[M].北京:清华大学出版社,2015.

【11】AUTOSAR Administration.Specification of Diagnostic Event Manager V5.2.0[EB/OL].http://www.autosar.org/.

Implementation of Ethernet Diagnostic Communication Based on AUTOSAR Standard

ZHANG Hongbin,XU Xu, HUANG Xi,ZHONG Zaimin

(Automotive Colleges,Tongji University, Shanghai 200092,China)

Ethernet diagnostic communication based on the AUTOSAR standard was realized and the advantages of Ethernet diagnostic communication were analyzed briefly.The open source TCP/IP protocol stack LwIP was transplanted into the AUTOSAR basis software layer, and then the communication protocol stack based on Ethernet was built which included the Ethernet driver, Ethernet interface, TCP/IP protocol stack , socket adapter.The module of the diagnosis communication was added on the basis of the Ethernet communication protocol stack.Finally, the corresponding upper computer was designed to test the UDS diagnosis services.It is proved that Ethernet diagnostic communication is better than CAN diagnostic communication in the large data transmission process.

AUTOSAR standard;TCP/IP protocol stack;UDS protocol; Diagnostic communication over IP

2016-09-26

国家科技支撑计划资助项目(2015BAG17B00)；国家自然科学基金资助项目(51075301)

章鸿滨(1991—)，男，硕士研究生，研究方向为基于AUTOSAR标准的车用控制器开发和以太网诊断通信。E-mail：15000137017@163.com。

10.19466/j.cnki.1674-1986.2017.01.001

U463.67

A

1674-1986(2017)01-003-06