产品
车载以太网的出现背景楼主就不多做赘述了，其实主要是因汽车E/E架构和功能的复杂度提升而带来的对车辆数据传输带宽提高和通讯方式改变（基于服务的通讯-SOA）的需求。
就目前汽车总线的应用情况，成本低、可靠性高、应用普遍的有Lin、CAN通讯，CAN FD也是最近几年才逐渐得到应用，而FlexRay、车载Ethernet等基于成本因素，目前主要在高端车型中使用。
其中楼主之前介绍的FlexRay后续得到普遍应用的可能性楼主认为不是很大，首先成本方面与车载以太网差不多而通讯速率又远低于它，而伴随着未来智能化、网联化的趋势，车载Ethernet在未来得到推广的可能性要比FlexRay高很多。需要注意的是CAN FD在市场推广实施还没有几年，第三代CAN总线-CAN XL也即将登场，CAN XL传输速率将达到10Mbit/s，可填补CAN FD和百兆车载以太网（100BASE-T1）之间的鸿沟，从这点也可以看出车载通讯的快速发展及对通讯带宽的越来越高的要求，同时也可从另一方面说明FlexRay的尴尬。当然所有总线的应用都是分所在的域和场景的，例如对于安全要求很高的场合，采用了基于时间触发机制的FlexRay因实时性和确定性更高则更合适。
在车载网络方面，玩家是很多的，也推出了各自的标准，如下：
其中OPEN Alliance和电气与电子工程师协会（IEEE）制定的标准是车载以太网领域比重最大和应用最广泛的，例如我们熟知的100BASE-T1和1000BASE-T1。
自1980年以来，IEEE一直负责以太网的维护、开发和标准化。尽管各个公司都可提供专有的以太网解决方案，但大多数时候公司都会交给IEEE进行标准化以确保更广泛的应用。802工作组则专门负责以太网，因此，所有与以太网相关的标准都以802开头（例如，IEEE 802.1，IEEE 802.2，IEEE 802.3等）。
OPEN Alliance SIG是由汽车制造商和供应商组成的联盟，目的是促进以太网在汽车工业中的进一步发展。OPEN Alliance SIG与IEEE合作，将汽车以太网转换为通用标准。就目前的车载以太网标准方面，主流标准的是如下几个，目前主要是第二个100BASE-T1：用单对双绞线实现100Mbit/s的数据传输，走的靠前的OEM则使用更快的千兆以太网。
OSI七层网络模型（OSI=Open Systems Interconnection）是互联网发展过程中一个很重要的模型。OSI是一个开放性的通信系统互连参考模型，其含义就是建议所有公司使用这个规范来控制网络。只有统一通信规范时，才能实现真正的互联化。OSI 七层模型及通信互联的传输过程，如下图所示：
OSI 七层网络模型是一个理想的网络参考模型，TCP/IP模型是已经被实际广泛应用于因特网的网络分层模型。TCP/IP 模型没有对 OSI 的 5~7 层做严格区分，统称为应用层。
车载以太网是基于 TCP/IP 的网络分层模型，并由 OPEN 和 AUTOSAR 等联盟对以太网相关协议进行了规范和补充。
以太网的网络拓扑结构有点对点形式、类似于CAN或LIN的总线形式、链式和星型等形式：
也有由上面几种形式的组合形式：
当然现在多个节点的车载以太网的互联互通需要交换机Switch，Switch的作用如下：
从硬件的角度看，以太网接口电路主要由MAC（Media Access Control）控制器和物理层接口PHY（Physical Layer，PHY）两大部分构成，如下图所示：
MAC及PHY工作在OSI七层模型的数据链路层和物理层，如下
PHY和MAC之间是如何传送数据和相互沟通的呢？MAC与PHY之间通过两个接口连接，分别为SMI接口和MII接口。
MII（Media Independent Interface）即媒体独立接口，MII接口是MAC与PHY连接的标准接口，以太网MAC通过该接口发出数据帧经过PHY后传输到其他网络节点上，同时其他网络节点的数据先经过PHY后再由MAC接收。MII是IEEE-802.3定义的以太网行业标准，MII接口提供了MAC与PHY之间、PHY与STA(Station Management)之间的互联技术，该接口支持10Mb/s与100Mb/s的数据传输速率，数据传输的位宽为4位。"媒体独立"表明在不对MAC硬件重新设计或替换的情况下，任何类型的PHY设备都可以正常工作。802.3协议最多支持32个PHY，但有一定的限制：要符合协议要求的connector特性。
SMI叫串行管理接口，以太网MAC通过该接口可以访问PHY的寄存器，通过对这些寄存器操作可对PHY进行控制和管理。SMI接口包括MDIO（控制和管理PHY以获取PHY的状态）和MDC（为MDIO提供时钟）。MDC由MAC提供，MDIO是一根双向的数据线。用来传送MAC层的控制信息和物理层的状态信息。MDIO数据与MDC时钟同步，在MDC上升沿有效。
由此可见，MAC 和PHY，一个是数据链路层，一个是物理层；两者通过MII传送数据。 因此Ethernet的接口实质是MAC通过MII总线控制PHY的过程。
MII接口后续又衍生了很多其他版本，如RMII、GMII、SGMII、RGMII等。这里简要介绍其中的MII和RMII，如下图所示。MII共使用了16根线。其中CRS与COL只在半双工模式有效，而车载以太网固定工作在全双工模式下，故应用在汽车环境需要14根线。
RMII是精简版的MII，数据发送接收均为两根，相比MII减少了4根，另外它整合或减去了一些线，最终RMII只有8根线RMII的接口如下：
在实际的设计中，以上三部分并不一定独立分开的。由于，PHY整合了大量模拟硬件，而MAC是典型的全数字器件。考虑到芯片面积及模拟/数字混合架构的原因，通常，将MAC集成进微控制器而将PHY留在片外。更灵活、密度更高的芯片技术已经可以实现MAC和PHY的单芯片整合，可分为下列几种类型:
CPU集成MAC与PHY，目前来说并不多见：
CPU集成MAC，PHY采用独立芯片，这种在车载以太网上是主流方式，因嵌入式芯片厂商一般都将MAC集成在MCU内部，而PHY芯片则由OEM或控制器供应商自己选择：
CPU不集成MAC与PHY，MAC与PHY采用集成芯片。这种在消费用以太网上比较比较常见，如电脑的网卡有这种方式的。
在以太网连接线束上，车载以太网与消费用以太网也是不同的，首先消费用以太网的标准主要采用10BASE-2、10/100BASE-TX和1000BASE-T，其中1000BASE-T是使用RJ45接口，需要四对双绞线共8根线进行数据传输，而10/100BASE-TX则是只使用四对双绞线其中的两对共4根线进行数据传输，如下是100BASE-TX的示意图（使用了两对双绞线）。
在很早之前的10BASE-2则是同轴电缆进行数据传输，因此消费类以太网采用线束总结如下：
而车载以太网一般都基本采用带T1的标准，如IEEE 100BASE-T1（以前称为OABR）、IEEE 1000BASE-T1，这些都使用一对双绞线共两根线进行数据传输：
其次在编码方式上，1000BASE-T主要采用PAM5的编码方式：
而车载以太网100BASE-T1和1000BASE-T1主要采用PAM3的编码方式。
从上面可知，车载以太网主要采用基于一对双绞线进行数据传输的100BASE-T1或1000BASE-T1标准，而我们电脑则使用RJ45接口采用基于4对双绞线进行数据传输的1000BASE-TX标准，因此当我们用电脑测量控制器以太网时，有时需要转换器，如下：
以太网帧的格式如下：
以太帧有多种类型，不同类型的帧具有不同的格式和MTU值，但在同种物理媒体上都可同时存在。常见有两种帧格式，第一种是上世纪80年代初提出的DIX v2格式，即Ethernet II帧格式。Ethernet II后来被IEEE802标准接纳，并写进了IEEE802.3x-1997的3.2.6节。
第二种是1983年提出的IEEE802.3格式。
这两种格式的主要区别在于，Ethernet II格式中包含一个Type字段，标识以太帧处理完成之后将被发送到哪个上层协议进行处理。IEEE802.3格式中，同样的位置是长度字段。
不同的Type字段值可以用来区别这两种帧的类型，当Type字段值小于等于1500（或者十六进制的0x05DC）时，帧使用的是IEEE802.3格式。当Type字段值大于等于1536（或者十六进制的0x0600）时，帧使用的是Ethernet II格式。以太网中大多数的数据帧使用的是Ethernet II格式。
以太帧中还包括源和目的MAC地址，分别代表发送者的MAC和接收者的MAC，此外还有帧校验序列字段，用于检验传输过程中帧的完整性。
汽车行业通常使用Ethernet II格式，该格式还可包含VLAN信息作为扩展，因此，又分基本MAC帧（无VLAN）和标记MAC帧（包括VLAN）两种。
MAC addresses: Ethernet II帧通常以接收者目标地址开头。 作用是指定要接收消息的网络节点。 与随后的发送者源地址相反，除单播地址外，还可以使用多播或广播地址。对于以太网帧，只能有一个发送方，但可以有多个接收方。
Ether type: 基本和标记的MAC帧通过类型字段（以太类型）进行区分。 这通常标识有效载荷数据区域中包含的分组，并给出有关较高层中使用的协议（例如，IPv4）的信息。如果以太类型的值为0x8100，则将类型字段向后移四个字节，并在其原始位置插入一个VLAN标签。
VLAN Tag：VLAN标签由协议标识符（TPID）和控制信息（TCI）组成。TPID包含原始类型字段的值，而TCI由优先级（PCP），符合丢弃要求或规范的形式指示符（DEI或CFI）和标识符（VID）组成。标识符和优先级主要用于汽车行业。标识符区分不同应用区域的相应虚拟网络。优先级允许通过交换机优化运行时间，以便优先转发重要信息。
Payload：在类型字段之后，以太帧包含有效载荷数据区域。 有效负载的最小长度为不带VLAN标记的46字节或带VLAN标记的42字节, 在汽车工业中，它最多可以包含1500个字节。
CRC校验：CRC校验在以太帧的末尾发送。 校验中包含的值是使用标准化算法计算的，该算法在发送方和接收方中以相同的方式实现。该计算是在以太帧的所有字段中进行的，因此可以确保整个消息的完整性。
以太网Packet: 对于以太网II帧的传输，以太网控制器在开头插入前同步码和起始帧定界符（SFD）,用于指示传输开始。前同步码，开始帧定界符和以太帧的组合称为以太网数据包。
上面我们已经提到，车载以太网是基于TCP/IP的网络模型，因此我们先不考虑应用层数据是根据哪种应用层协议组织的，从应用层来的数据，经过传输层会加上TCP/UDP报头，再到网络层的IP报头，然后到链路层增加MAC地址等信息，最后由PHY转换成线路上的二进制流实现在发送端和接收端的数据传输。
其中上面传输层的TCP协议和网络层的IP协议，楼主在本篇文章中就不过多赘述了，大家感兴趣的请自行查询了解。而应用层协议有不少，例如DoIP、DHCP、SOME/IP等，而最重要的车载以太网应用层协议主要是SOME/IP协议。
SOME/IP介绍
如上篇阐述的，车载以太网采用基于 TCP/IP 的网络分层模型，TCP/IP 模型没有对 OSI 的 5~7 层做严格区分，统称为应用层，如上。
其中应用层协议有关的协议有SOME/IP、AVB/TSN、DoIP等，本篇我们主要阐述SOME/IP协议。SOME/IP (Scalable Service-Oriented MiddlewarE Over IP) ，即“运行于IP之上的可伸缩的面向服务的中间件”，它是车载以太网技术中的核心内容，可用于控制消息及应用数据传输，该技术是SOA架构的重要支撑。它在系统中其实就是一个中间件的存在，所谓“Middleware中间件”是一种独立的系统软件或服务程序，分布式应用软件可借助Middleware在不同的技术之间共享资源。所谓的分布式应用软件，在这里指的就是“服务”；不同的技术之间，在这里指的就是“不同的平台或操作系统，比如Adaptive AUTOSAR系统等。因此SOME/IP用于面向服务的通讯，可实现方法复用和扩展、可降低负载（因SOME/IP是在接收方有需求的时候才发送，这种方法的优点在于总线上不会出现过多不必要的数据，从而降低负载。）并适用于不同操作系统
上文的我们也已经说过了输出的传输过程：数据从应用层到物理层是经过一层一层封装然后传输的，上三层的数据流在传输层被封装成数据段，在网络层数据段被封装成数据报，在数据链路层数据报被封装成数据帧，最后在物理层编码成比特流进行传输，这次我们重点关注TCP/IP模型中应用层数据经SOME/IP协议是如何封装的。
服务是SOME/IP的最核心概念，在一个服务中，定义了Server和Client两个角色：Server提供服务，Client调用服务。对于同一个服务，只能存在一个Server，但可以同时存在多个Client调用服务，一个Service由Event/Method/Field组成。
Method类型：即函数调用的形式，Client通过函数调用的方式向Server端请求数据。
Event类型：即事件类型，Client会向Server端订阅信息，Server则会以事件触发的形式向Client端发送所订阅的内容。
Filed类型：是Method和Event的组合，由以下三项内容构成：
Notifier：通知，Client订阅了服务后，Server第一时间主动向其发送数据-Event方式
Getter：获取，由Client向Server请求数据-Method方式
Setter：设置，由Client修改Server的数据--Method方式
从上面可看到Notification分为Event和Field 两类，这两类通知都需要首先使用SOME/IP-SD(Service Discovery)来进行服务订阅，然后才能发布通知。
区别在于，Event是某一时刻的快照，只是事件通知，而Field除了事件通知之外，还具有Getter和Setter的功能，即对信息进行读写的操作。
对于上面三种方法的总结如下：
SOME/IP 的数据格式如下：
Message Type用来识别不同的消息类型，目前类型如下图，其中TP用来表示分包的报文：
REQUEST、REQUEST_NO_RETURN、RESPONSE属于同一类远程过程调用方法，当Client有需求的时候，发送一个Request消息，Server根据这个消息类型（REQUEST或REQUEST_NO_RETURN）来决定是否发Rresponse消息。
Return Code则用于表示请求是否被成功的处理，下表是AUTOSAR标准中定义的Return Code类型：
Payload就是用于自定义原始数据了。
上面我们提到Event和Field这两类的通知都首先需要使用SOME/IP-SD(Service Discovery)来进行服务订阅，然后才能发布通知并且服务需要由Server和Client共同完成，因此在进行正常的数据传输之前，需要一系列的准备工作确认Server和Client之间是否已有网络连接。之后，Client还要询问Server能否提供所需的服务，并对服务的Event进行订阅。
那么Client是怎么知道Server提供哪些服务呢，就是通过SOME/IP-SD来实现服务发现过程的。SOME/IP服务发现用于定位服务实例、检查服务是否可用以及部署发布和订阅句柄,。服务发现只能通过UDP实现。SOME/IP-SD是一种特殊的SOME/IP格式，它对SOME/IP-SD报文中的Payload进行了定义和实现,。而Message ID字段则是固定的0xFF FF 81 00。
其主要功能就是：定位服务实例、检测服务实例是否在运行（即服务实例的状态）、发布/订阅行为的管理。格式如下：
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
