Autosar-以太网及-SOME-IP-实现

("Autosar以太网及SOME/IP实现以太网即ETH（Ethernet）是MICROSAR(MICROSAR是由Vector开发的一套符合AUTOSAR标准的基础软件代码包，包含了MICROSAR.RTE以及MICRO-SAR.BSW，覆盖了AUTOSAR的所有标准，还具有一些扩展功能模块，每一个AUTOSAR的BSW模块都能对应到具体的MICROSAR模块。VectorDaVinciConfiguratorPro工具用于对MICROSAR模块进行具体配置，并生成代码。)中的一个BSW模块，其概念是由Xerox公司创建并由Xerox、Intel和DEC/'公司联合开发的基带局域网规范，是当今现有局域网采用的最通用的通信协议标准。图1汽车以太网图2以太网无线充电以太网包括标准的以太网（10Mbit/s）、快速以太网（100Mbit/s）和10G（10Gbit/s）以太网。IEEE组织的IEEE802.3标准制定了以太网的技术标准，它规定了包括物理层的连线、电子信号和介质访问层协议的内容。图3Vector全栈解决方案AUTOSAR对于车载以太网的架构提出了新的解决方案，不同于计算机网络通信的7层OSI架构模型，AUTOSAR规范首次提出了一种适用于车载以太网的TCP/IP模型。如图4所示，以太网在OSI七层模型定义于物理层和数据链路层，相对应地在TCP/IP模型中处于网络接口层。由于OSl七层模型对于车用网络架构而言过于复杂，而AUTOSAR使用的TCP/IP模型更贴近实用，故其在车载以太网领域获得了更广泛的应用。图4OSI模型与车载以太网TCP/IP模型在TCP/IP模型中，网络通信架构被分为4层，其中应用层是应用程序访问网络的通道，常见FTP、HTTP、DNS和TEL-NET协议，AUTOSAR内还包含了SOME/IP、DoIP和XCP等协议；传输层主要指的是TCP协议和UDP协议；网络层包括IP协议，ARP、RARP协议，ICMP协议等；网络接口层是TCP/IP协议的基层，负责数据帧的发送和接收。车载以太网SOME/IP协议简介SOME/IP（ScalableService-OrientedMiddlewarEoverIP）是车载以太网通信领域的一个概念，是一种位于应用层的通信协议。在目前主流的以CAN总线为主的车载网络中，通信过程是面向信号的（除了诊断通信之外），这是一种根据发送者需求实现的通信过程，当发送者发现信号的值变化了或者到达预定的发送周期，就会向外发送该信号，而不考虑接收者是否有需求。而SOME/IP则不同，它是在接收方有需求的时候才发送，这种协议使得总线上不会出现过多不必要的数据收发，从而有效地降低总线负载。在车载网络中，某个ECU有时会需要调用实现在其他ECU上的服务，此时两个ECU就分别扮演了网络通信中client和server的角色，而SOME/IP就是实现这种远程服务调用的接口，如图5所示。图5SOME/IP通信示意图从图5和图6可以看出，SOME/IP本质上是构架在传输层之上的应用层通信协议，它是位于TCP/UDP报文的Payload部分内的。图6SOME/IP报文位置SOME/IP数据的Header部分的MessageType字段是SOME/IP功能实现的重要部分，其长度为8bit，有以下五种取值：REQUEST（期待响应的请求）、REQUEST_NO_RETURN（不期待响应的请求）、NOTIFICATION（事件通知）、RE-SPONSE（响应消息）和ERROR（报错消息）。图7SOME/IP协议通信方法如图7所示，当ECUA作为Client端对ECUB的某个服务有需求时，发送一个Request消息，之后ECUB作为Ser-ver端根据接收到的Request类型决定是否返回一个Re-sponse消息。在二者经过上述通信没有发生错误后，首先由Client向Server订阅服务内容，然后Server向Client自动发布服务内容。3实现方法MICROSARETH模块功能的实现需要一个上位机与单片机上的ETH模块进行信息交互，为了更好的进行交互过程观察和单片机上的变量观察，本文使用德国Vector公司的产品VN5640配合电脑上的CANoe软件作为上位机。图8实现方法示意图在MICROSAR中，DaVinci配置工具将以太网相关的配置内容分为如图9所示的多个分层模块结构。用户需要自下而上进行配置，即从底层的Eth收发器、接口和驱动模块开始，之后配置网络传输协议TCP/IP模块，配置对TCP/IP协议进行封装的SoAd模块，然后将其和信号相关的PduR、Com模块相互配合，最后和上层的SOME/IP协议应用相关联。其设计路线与上文MICROSAR提出的车载以太网TCP/IP模型结构的顺序基本符合。图9MICROSAR配置工具的分层模块架构因此，本文采用的技术路线如下：（1）使用VectorDaVinci开发工具搭建操作系统，实现RTE、任务配置和运行实体的映射，配置应用层用于测试的简单应用；（2）配置Eth/EthIf/EthTrcv模块，即以太网通信底层模块，包括以太网接口、以太网收发器和以太网驱动的相关配置；（3）配置TCP/IP模块，即以太网通信协议，对传输层和网络层进行配置。（4）配置SoAd模块，每一条TCP连接通过一个双向的通信连接实现数据的交换，连接的两个端点称为一个Socket。其本质是编程接口（API），即一种对TCP/IP的封装。（5）配置信号定义（该步骤用于SOME/IP通信），主要通过以太网描述文件(.arxml)完成，通过Com相关模块和Pdu相关模块进行配置实现其具体功能。（6）在Tasking编译器中集成静态代码以及配置工具生成的代码，生成可执行文件；（7）使用调试工具进行测试验证，使用CANoe对所需变量进行观测；本文设计了如下方案以验证ETH基础通信及SOME/IP通信的功能的正确性。在验证ETH基础通信功能时，如下图所示，设计了一个以太网接收数据的中断服务，即每当单片机成功接收到上位机发来的以太网报文后，产生一个二类中断。为了验证以太网基础通信在UDP和TCP两种协议下均可正常工作，故设计适用于UDP和TCP两种协议的中断服务程序，在其内部调用以太网发送函数SoAd_IfTransmit()，即当单片机成功接收到上位机发来的以太网报文后，立刻向外发出一个以太网报文，本文设计发送内容与接收到的数据一致，以此验证以太网基础通信的收发功能。图10验证通信功能的中断服务程序及任务的简单代码在验证SOME/IP通信功能时，如图10所示，设计了一个包含一个Runnable的TASK，该Runnable运行周期为20ms。在Runnable外部预先定义两个信号，分别对应单片机向外发送的信号A和单片机接收到的信号B。信号A的数据为图中的结构体aSOAData_RDA_HSC4_S00，而信号B的数据对应为图中的结构体aSOAData_IECU_HSC4_RDA_FrP01。每当单片机上的操作系统运行20ms，即进行一次对信号B的读取和对信号A的写入并发送。通过观察单片机是否正确接收上位机发来的信号B数据，以及上位机是否正确接收单片机发出的信号A数据，以此验证以太网SOME/IP通信的收发功能。测试与验证本文测试硬件平台为英飞凌公司生产的AurixTC397单片机，通过Mini-Wiggler与计算机上的pls公司的UDE调试软件相连，另以德国Vector公司生产的VN5610控制器作为测试上位机，配合该公司的CANoe软件进行测试。图11测试系统示意图\uf0b7ETH基础通信测试通过网线将VN5610与TC397单片机相连接，另一端通过数据线将VN5610与电脑相连接。保持单片机上的程序正常运行，建立的CANoe工程，测试UDP与TCP协议通信，其中单片机的IP地址设置为192.168.1.50，上位机CANoe的IP地址设置为192.168.1.254，另外设置上位机的UDP/TCP报文以周期1000ms进行发送，发送的报文Payload部分内容为十六进制数值“112233445566778899AABB”。图12UDPMessage在单片机运行的程序中添加代码，目的是使单片机收到上位机CANoe发送来的数据时，直接将收到的数据转发出去，即发回CANoe。这样只要分别对比在UDP与TCP协议下，发送与接收到的UDP/TCP的Payload数据是否一致，以及UDP/TCP的Header部分是否相互匹配，即可确认以太网基础通信功能是否正常。点击CANoe的运行按键，在Trace窗口可以看到以太网网络的数据帧，Trace结果的片段如下图所示。在Trace窗口中点击任意一帧接收报文Rx，可以在DetailView中查看UDP报文和TCP报文的详细信息，从图13中可以看到帧类型、物理地址、本地和目标地址及其端口，在UDP与TCP下的Pay-load是主要的用户数据。图13UDP报文Trace在UDP协议下，将CANoe接收到的数据报文与之前预设在CANoe中发送的数据报文进行对比，可以看出两者的Payload部分相同，其他部分严格对应无误。在UDP协议下，将CANoe接收到的数据报文与之前预设在CANoe中发送的数据报文进行对比，可以看出两者的Payload部分相同，其他部分严格对应无误。图14TCP报文Trace在TCP协议下，可以看出TCP协议特有的识别过程，首先进行ARP协议传输，根据IP地址解析MAC地址，之后是客户端（CANoe）与服务端（TC397）建立连接的“三次握手”。与UDP协议不同的是，TCP协议中的任何以此收发均会给对方产生一个反馈信息，由于在代码中设置了将单片机收到的报文数据立刻发送出去，因此该报文数据会与反馈信息相结合形成一个报文，故在上位机中以此完整通信只收到一次Rx报文。将CANoe接收到的数据报文与之前预设在CANoe中发送的数据报文进行对比，可以看出两者的Payload部分相同，其他部分严格对应无误。综上所述，验证了以太网基础通信功能的正确实现。\uf0b7以太网SOME/IP通信测试通过网线将VN5610与TC397单片机相连接，另一端通过数据线将VN5610与电脑相连接。首先测试从TC397单片机向外发送数据，在代码中声明要发送的信号为如图10所示结构体aSOAData_RDA_HSC4_S00，赋值为｛1，0，0，4｝。正常运行单片机之后，可以在UDE调试器中通过Watches窗口查看到代码中设置好的信号的值。保持单片机上的程序正常运行，建立CANoe工程。只要分别对比：（1）上位机CANoe发送出的报文，即上述结构体的值，是否被单片机正确接收，即单片机内存中该结构体的值与发送报文的相应值是否一致。（2）上位机CANoe接收到的报文，即上述结构体的值，是否与单片机发出的报文相应值一致，即上位机中收到的数据是否与单片机内存中该结构体的值一致。以及各自的Header部分是否相互匹配，即可确认以太网SOME/IP通信功能是否正常。图15SOME/IP通信接收测试使用CANoe的Trace窗口观测报文，和UDE调试器中看到的单片机预设数据进行对比。可以看到CANoe收到的信号中的结构体与代码中设置的名称相同，数据｛1，0，0，4｝一致，报文其他部分互相对应无误。之后测试从上位机CANoe向单片机发送数据，在CANoe中利用CAPL语言手写代码，声明要发送的信号为如图10所示结构体aSOAData_IECU_HSC4_RDA_FrP01，赋值为｛1，34，51，68｝。正常运行单片机和CANoe工程之后，可以在CA-Noe的Trace窗口查看在CAPL语言中设置好的信号的内容。图16SOME/IP通信发送测试使用UDE调试器的Watches窗口查看单片机收到的结构体数据，和CANoe中预设的报文数据进行对比。可以看到单片机收到的信号中的结构体与CANoe中设置的名称相同，数据｛1，34，51，68｝一致，报文其他部分互相对应无误。综上所述，验证了以太网SOME/IP通信功能的正确实现。小结本文概述了AUTOSAR规范的架构，基于该规范内容在AurixTC397单片机上实现了ETH基础通信和SOME/IP通信。本文为两类通信模式分别设计了技术路线和测试方案，并通过测试验证了以太网TCP/UDP基础通信和SOME/IP通信功能的正确性和有效性。基于AUTOSAR的以太网通信软件开发可以为智能交通、ADAS等领域的信息交互提供极大便利，具有广阔的发展前途和极高的实际应用价值。",)