MICROSAR ETH 简介

以太网即 ETH （Ethernet） 是 MICROSAR (*MICROSAR 是由 **Vector** 开发的一套符合 AUTOSAR 标 准的基础软件代码包，包含了 MICROSAR.RTE 以及 MICRO- SAR.BSW，覆盖了 AUTOSAR 的所有标准，还具有一些扩展功能模块，每一个AUTOSAR 的BSW 模块都能对应到具体的 MICROSAR 模块。Vector DaVinci Configurator Pro 工具用于对 MICROSAR 模块进行具体配置，并生成代码。* )中的一个 BSW 模块，其概念是由 Xerox 公司创建并由 Xerox、Intel 和 DEC/' 公司联合开发的基带局域网规范，是当今现有局域网 采用的最通用的通信协议标准。

图1 汽车以太网

图2 以太网无线充电

以太网包括标准的以太网 （10Mbit/s）、快速以太网（100Mbit/s）和 10G（10Gbit/s）以太网。IEEE 组织的 IEEE 802.3 标准制定了以太网的技术标准，它规定了包括物理层的连线、电子信号和介质访问层协议的内容。 图3 Vector全栈解决方案 AUTOSAR 对于车载以太网的架构提出了新的解决方案，不同于计算机网络通信的 7 层 OSI 架构模型，AUTOSAR 规范首次提出了一种适用于车载以太网的 TCP/IP 模型。如图 4 所示，以太网在 OSI 七层模型定义于物理层和数据链路层，相对应地在 TCP/IP 模型中处于网络接口层。由于 OSl 七层模型对于车用网络架构而言过于复杂，而 AUTOSAR 使用的TCP/IP 模型更贴近实用，故其在车载以太网领域获得了更广泛的应用。

图4 OSI 模型与车载以太网 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（Scalable service-Oriented MiddlewarE over IP） 是车载以太网通信领域的一个概念，是一种位于应用层的通信协议。在目前主流的以 CAN 总线为主的车载网络中，通信过程是面向信号的（除了诊断通信之外），这是一种根据发送者需求实现的通信过程，当发送者发现信号的值变化了或者到达预定的发送周期，就会向外发送该信号，而不考虑接收者是否有需求。而 SOME/IP 则不同，它是在接收方有需求的时候才发送，这种协议使得总线上不会出现过多不必要的数据收发，从而有效地降低总线负载。 在车载网络中，某个 ECU 有时会需要调用实现在其他 ECU 上的服务，此时两个ECU 就分别扮演了网络通信中client 和 server 的角色，而 SOME/IP 就是实现这种远程服务调用的接口，如图 5 所示。

图 5 SOME/IP 通信示意图
从图 5 和图 6 可以看出，SOME/IP 本质上是构架在传输层之上的应用层通信协议，它是位于TCP/UDP 报文的Payload 部分内的。

图 6 SOME/IP 报文位置SOME/IP
数据的 Header 部分的 Message Type 字段是 SOME/IP 功能实现的重要部分，其长度为 8 bit，有以下五种取值：REQUEST（期待响应的请求）、REQUEST_NO_RETURN （不期待响应的请求）、NOTIFICATION （事件通知）、RE- SPONSE（响应消息）和 ERROR（报错消息）。

图 7 SOME/IP 协议通信方法
如图 7 所示，当 ECU A 作为 Client 端对 ECU B 的某个服务有需求时，发送一个Request 消息，之后ECU B 作为Ser- ver 端根据接收到的 Request 类型决定是否返回一个 Re- sponse 消息。在二者经过上述通信没有发生错误后，首先由 Client 向 Server 订阅服务内容，然后 Server 向 Client 自动发 布服务内容。 3 实现方法 MICROSAR ETH 模块功能的实现需要一个上位机与单片机上的 ETH 模块进行信息交互，为了更好的进行交互过程观察和单片机上的变量观察，本文使用德国 Vector 公司的产品 VN5640 配合电脑上的 CANoe 软件作为上位机。

图 8 实现方法示意图
在 MICROSAR 中，DaVinci 配置工具将以太网相关的配置内容分为如图 9 所示的多个分层模块结构。用户需要自下而上进行配置，即从底层的Eth 收发器、接口和驱动模块开始， 之后配置网络传输协议 TCP/IP 模块，配置对 TCP/IP 协议进行封装的SoAd 模块，然后将其和信号相关的PduR、Com 模块相互配合，最后和上层的 SOME/IP 协议应用相关联。其设计路线与上文 MICROSAR 提出的车载以太网 TCP/IP 模型结构的顺序基本符合。

图 9 MICROSAR 配置工具的分层模块架构
因此，本文采用的技术路线如下： （1）使用Vector DaVinci 开发工具搭建操作系统，实现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 通信的收发功能。

测试与验证

本文测试硬件平台为英飞凌公司生产的 Aurix TC397 单片机，通过 Mini-Wiggler 与计算机上的 pls 公司的 UDE 调试软件相连，另以德国 Vector 公司生产的 VN5610 控制器作为测试上位机，配合该公司的 CANoe 软件进行测试。

图 11 测试系统示意图

• ETH 基础通信测试
  通过网线将 VN5610 与 TC397 单片机相连接，另一端通过数据线将 VN5610 与电脑相连接。保持单片机上的程序正常运行，建立的 CANoe 工程，测试 UDP 与 TCP 协议通信，其中单片机的 IP 地址设置为 192.168.1.50，上位机 CANoe 的 IP地址设置为 192.168.1.254，另外设置上位机的 UDP/TCP 报文以周期 1000ms 进行发送，发送的报文 Payload 部分内容为十六进制数值“112233445566778899AABB”。

图 12 UDP Message
在单片机运行的程序中添加代码，目的是使单片机收到上位机CANoe 发送来的数据时，直接将收到的数据转发出去， 即发回 CANoe。这样只要分别对比在 UDP 与 TCP 协议下， 发送与接收到的 UDP/TCP 的 Payload 数据是否一致，以及 UDP/TCP 的Header 部分是否相互匹配，即可确认以太网基础 通信功能是否正常。 点击 CANoe 的运行按键，在 Trace 窗口可以看到以太网网络的数据帧，Trace 结果的片段如下图所示。在 Trace 窗口中点击任意一帧接收报文Rx，可以在Detail View 中查看UDP报文和 TCP 报文的详细信息，从图 13 中可以看到帧类型、物理地址、本地和目标地址及其端口，在 UDP 与 TCP 下的 Pay- load 是主要的用户数据。

图 13 UDP 报文 Trace
在 UDP 协议下，将 CANoe 接收到的数据报文与之前预设在 CANoe 中发送的数据报文进行对比，可以看出两者的 Payload 部分相同，其他部分严格对应无误。 在 UDP 协议下，将 CANoe 接收到的数据报文与之前预设在 CANoe 中发送的数据报文进行对比，可以看出两者的 Payload 部分相同，其他部分严格对应无误。

图 14 TCP 报文 Trace
在 TCP 协议下，可以看出 TCP 协议特有的识别过程，首先进行 ARP 协议传输，根据 IP 地址解析 MAC 地址，之后是客户端（CANoe）与服务端（TC397）建立连接的“三次握手”。与 UDP 协议不同的是，TCP 协议中的任何以此收发均会给对方产生一个反馈信息，由于在代码中设置了将单片机收到的报文数据立刻发送出去，因此该报文数据会与反馈信息相结合形成一个报文，故在上位机中以此完整通信只收到一次 Rx 报文。将 CANoe 接收到的数据报文与之前预设在 CANoe 中发送的数据报文进行对比，可以看出两者的Payload 部分相同， 其他部分严格对应无误。 综上所述，验证了以太网基础通信功能的正确实现。

• 以太网 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 通信功能是否正常。

图 15 SOME/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 语言中设置好的信号的内容。

图 16 SOME/IP 通信发送测试
使用 UDE 调试器的 Watches 窗口查看单片机收到的结构体数据，和 CANoe 中预设的报文数据进行对比。可以看到单片机收到的信号中的结构体与 CANoe 中设置的名称相同，数据｛1，34，51，68｝一致，报文其他部分互相对应无误。 综上所述，验证了以太网 SOME/IP 通信功能的正确实现。

小结

本文概述了 AUTOSAR 规范的架构，基于该规范内容 在 Aurix TC397 单片机上实现了 ETH 基础通信和 SOME/ IP 通信。本文为两类通信模式分别设计了技术路线和测试方案，并通过测试验证了以太网 TCP/UDP 基础通信和SOME/IP 通信功能的正确性和有效性。基于 AUTOSAR 的以太网通信软件开发可以为智能交通、ADAS 等领域的信息交互提供极大便利，具有广阔的发展前途和极高的实际应用价值。