第4章以太网协议栈模块总览

4、以太网协议栈模块总览：EthDrv, EthIf, EthTrcv, TcpIp, SoAd, DoIP, SomeIp, Sd, UdpNm

好，咱们进入正题。这一章我打算带你快速过一遍AUTOSAR以太网协议栈的各个核心模块。说白了，就是给你一张「地图」。你以后做项目，遇到问题能知道该找谁。

我个人习惯，拿到一个新项目，第一件事就是看协议栈的模块划分图。为什么？因为每个模块的职责边界清楚了，调试时你才知道日志该看哪一段，代码该改哪个文件。

这两个模块是硬件打交道的主力。

EthDrv（以太网驱动）：直接操作MAC控制器。发送、接收帧，配置MAC地址，处理中断。我在项目中遇到过一个问题，EthDrv的接收描述符配置错了，导致高速数据包频繁丢帧。查了两天才定位到，嗯，底层的东西一旦出问题，上层根本看不出来。
EthTrcv（以太网收发器驱动）：管理PHY芯片。比如初始化、链路检测、唤醒/休眠。说白了，它负责让物理层「通」起来。

我的建议：调试链路不通时，先看EthTrcv的Link Status。如果它没报Link Up，上层TcpIp再折腾也没用。

EthIf是EthDrv和上层之间的抽象层。你想想看，一个控制器可能有多个端口，每个端口可能接不同的PHY。EthIf的作用就是帮你管理这些「通道」。它提供统一的接口，上层不用关心底层用的是哪个MAC、哪个PHY。

我曾经在一个项目中，因为EthIf的控制器索引配置错了，导致数据发到了错误的端口。从那以后，我每次都会仔细核对EthIf的Controller配置。

TcpIp模块实现了TCP/IP协议栈。注意，AUTOSAR的TcpIp不是完整的Linux协议栈，它是为嵌入式实时系统裁剪过的。支持IPv4、IPv6、TCP、UDP、ICMP等。

这里有个坑：AUTOSAR的TcpIp默认不支持IP分片。如果你要传输大于MTU的数据包，得在应用层自己处理。我建议你提前确认好需求，别等到集成测试才发现。

SoAd（Socket Adapter）是TcpIp和上层应用之间的桥梁。它把TcpIp的Socket接口，映射到AUTOSAR的通信接口（比如PDU Router）。

说白了，SoAd让你可以用AUTOSAR的标准方式（发送PDU）来发送以太网数据。你不用直接调用Socket API，SoAd帮你封装好了。

  重点：SoAd的配置非常关键。Socket ID、PDU ID、端口号、协议类型，一个都不能错。我见过因为SoAd的Socket路由配置错误，导致DoIP无法建立连接的情况。

这几个是真正干活的应用层模块。

DoIP（诊断 over IP）：用于UDS诊断。支持车辆发现、路由激活、诊断请求/响应。我在项目中用DoIP刷写ECU，速度比CAN快太多了。但要注意，DoIP的TCP连接管理要做好，否则容易资源耗尽。
SomeIp（可扩展的面向服务的中间件）：这是以太网上的「服务发现+远程调用」协议。它支持事件通知、方法调用、字段访问。说白了，SomeIp让ECU之间可以像调用本地函数一样调用远程服务。
Sd（服务发现）：Sd是SomeIp的「侦察兵」。它负责发现谁提供了什么服务，谁需要什么服务。没有Sd，SomeIp就是瞎子。
UdpNm（UDP网络管理）：用于以太网的网络管理。它通过UDP报文来同步ECU的休眠和唤醒状态。我建议你注意UdpNm的报文发送周期，太频繁会占用带宽，太稀疏会导致唤醒延迟。

这些模块不是孤立的。我给你画个简单的数据流：

应用层（DoIP/SomeIp）
    ↓↑
SoAd（Socket适配）
    ↓↑
TcpIp（传输层）
    ↓↑
EthIf（接口抽象）
    ↓↑
EthDrv + EthTrcv（底层驱动）
    ↓↑
硬件（MAC + PHY）

数据从应用层一路往下，最终变成电信号发出去。反过来也一样。每个模块只负责自己的那一层，职责清晰。

注意：千万不要跨层调用。比如应用层直接操作EthDrv，这违反了AUTOSAR的分层原则。一旦这么做了，后续的维护和升级会非常痛苦。

好了，这一章的内容就这些。最后给你几个实用建议：

先看配置，再看代码。 以太网协议栈的问题，80%是配置错误。EthIf的Controller配置、SoAd的Socket路由、TcpIp的IP地址，这些配置项一定要仔细核对。
用好日志。 每个模块都有详细的调试日志。打开它们，看数据流走到哪一步断了。我曾经靠EthTrcv的日志，发现PHY的复位时序不对，导致链路不稳定。
不要贪多。 刚开始做项目，先跑通DoIP或SomeIp中的一个。两个同时上，出了问题你都不知道该查谁。