SomeIP学习笔记:基础知识
在整车功能开发以及调试过程中,ECU与ECU之间使用车载以太网的比例越来越多,所以区别于之前的CAN总线报文的,对于以太网数据包的抓取和分析越来越普及了,而其中又绕不开SOME/IP,每一个搞过车载功能开发都或多或少接触过或者使用过SOME/IP。我在了解这个协议过程中走了不少弯路,后来发现并没那么复杂,于是打算把自己的心得记录下来。 主要从3个角度记录我所学习的SOME/IP,首先是一些基本的知识,其次是怎样用Vector CANoe来调试一个结合了AUTOSAR通信,包括怎样在CANoe里边调整数据库实现自定义调试;最后做一个实践,使用开源的SOME/IP协议栈vsomeip,来和我们CANoe的SOME/IP协议栈做一个真实的通信。 SOME/IP基础知识 SOME/IP是基于TCP/UDP/IP协议之上的应用层协议,很像网络开发中前后端交互的HTTP的方式。如果之前做过前后端的开发,对于客户端和服务器的连接有一定的知识储备,那么在了解SOME/IP的过程中会觉得很简单的。SOME/IP依托于TCP或UDP,所有的数据都是作为TCP/UDP的Payload通过IP协议进行传输。可以理解成在Payload中又做了进一步的切分,并且比特位以及长度做了事先约定,例如下图中的前16个Bit固定为Service ID,紧接着的16个Bit为Method ID或者Event ID。 目前网络中常见的SOME/IP学习路径和学习资料,包括我之前看的一些,大多是在CAN总线技术路线以及实现方式的基础上介绍SOME/IP的特点以及技术细节的,很多从以太网IP以及UDP和TCP开始讲起,然后再说到SOME/IP的各种Header头部还有服务订阅等等内容,这样的一个学习路径,非常容易把很多的类似的概念参合到一起,比如IP层、UDP、TCP以及SOME/IP都有Header头部,IPv4和IPv6头部又不一样,TCP的三次握手四次挥手和SOME/IP的Subscribe订阅以及UDP和Notification,太太太容易混淆了。可能看了好久还觉得云里雾里,觉得这个太高深了,其实真的SOME/IP没啥,将其理解成ECU之间的HTTP类似协议,下层依赖的TCP/UDP和电脑手机服务器用的没有任何区别,明白这个就已经学会了一大半。关于车载以太网和普通以太网的区别,我在另外一个学习记录贴中有记录,一句话总结就是物理层数据链路有区别,到了IP层以上就完全一样了。 不过从另外一个角度也可以理解,很多汽车软件的开发人员是从传统技术栈比如CAN总线时代过来的,对于以太网的了解不像互联网人那样深入,所以有一定的需求再详细了解一些IP/TCP/UDP的知识。我的建议是将这两部分分开学习,先回顾一下计算机网络,七层协议啥的,再了解一个应用层协议比如HTTP,最后再详细学习SOME/IP,绝对会事半功倍,发现真的好简单,半天时间SOME/IP入门足够。 另外在车载应用开发中,SOME/IP的Payload部分填充,考虑到和其他ECU以及功能的兼容性问题,会使用AUTOSAR的规则定义方式,这和CAN总线的Frame帧非常的像。在CAN总线Data Field数据场一次最多传输8字节,通常会把这对应的64个比特拆分成传输数据的最小量,比如一个布尔型只分配1个比特,然后一个0-255的Uint8只分配8个比特,总共8字节64比特能拆分成很多个Signal信号,从而有限的资源传输更多数据,各个Bit对应的Signal信号长度以及数据类型的记录成一个表格,即得到了CAN总线数据库DBC。在车载SOME/IP开发中Payload部分多数情况下也沿用了类似的思路,所以在Payload部分解析也需要一些额外的信号矩阵,结合了SOME/IP支持的数据结构和AUTOSAR数据结构,就能组合出很多复杂的结构体,实现更多上层应用间的数据传输。 这样的实现方式也可以很好的复用迁移传统汽车行业稳定成熟的软件解决方案,在必要的情况下,只需要在传输层做一些技术更新,核心逻辑不需要任何变动,从而降低潜在的风险。但是这一块是互联网人来做汽车软件的话,可能就不是很熟悉了,尤其对于不常见的Bit位的数据拆分,再结合这大端小端数据类型,还有信号矩阵有Scale放大缩小以及Offset偏移,八成互联网人转过来的开发第一次会搞错。建议之前对于汽车总线了解较少的开发人员可以系统学习一下CAN总线以及结合项目了解一下AUTOSAR信号矩阵,可以避免很多低级的错误。 传统车载网络CAN总线在面向信号的数据传输中,发送方会根据自身需求(如数值更新或变更时)主动发送信息,而无需考虑网络中是否有接收方当下需要这些数据。与之不同的是面向服务的数据传输模式即发送方仅当网络中至少存在一个接收方需要该数据时才会进行传输。这种方式的优势在于避免了不必要的数据对网络及所有连接节点造成的负载。因此,面向服务的数据传输要求服务器必须通过某种方式获知哪些接收方正在等待其数据。在SOA架构中,服务是构成系统的基本单元,它代表了系统中的某个功能或操作。服务通过明确的接口与外界进行交互,实现了功能的封装和重用。SOA架构的核心就是服务,它通过将应用程序划分为一系列的服务来降低系统的复杂度,提高系统的灵活性和可维护性。在SOA中,服务是通过其接口被定义和访问。接口是服务与外界交互的桥梁,它定义了服务的输入、输出和行为规范。在SOA架构中,以太网通信作为服务的传输载体,负责在不同的ECU或服务之间传递数据和信息,根据AUTOSAR平台的规范与推荐,一般选择以太网应用层协议SOME/IP协议或者DDS协议作为跨域通信协议。 在SOME/IP协议中,服务接口被明确划分为三种类型: Event、Field、Method,每种类型都服务于不同的通信需求。 Event and Field Notification 服务器基于活跃订阅发送的内容可呈现两种格式:事件通知(Event Notification)和字段通知(Field Notification)。这两种格式的共同特性是事件驱动生成机制,但其数据结构存在本质差异: 事件通知Event:采用自包含的静态快照形式,其字段填充的属性仅反映事件触发时的瞬时状态,与历史事件无任何关联 字段通知Field:包含具有时序关联性的动态值,除当前值外还隐含历史状态。因此字段可扩展为包含Getter/Setter方法,允许客户端对目标内容进行读写操作。 需要特别说明的是,在SOME/IP协议中,事件总是以事件组(Event group)的形式进行组织,客户端仅能订阅整个事件组,而无法单独订阅组内某个特定事件。Field的Setter/Getter 方法遵循请求/响应(REQUEST/RESPONSE)模式,变更通知则通过事件机制实现,所有订阅操作都需通过SOME/IP服务发现(SOME/IP Service Discovery)协议完成。 Method 另一种数据交换方式是通过方法调用(Method Call)实现信息传递。客户端通过发起远程过程调用(Remote Procedure Call, RPC),触发目标服务器上的函数执行。具体流程如下: 调用过程:客户端通过网络发送请求来调用服务器函数,该请求可包含作为参数传递至被调用方法的数据; 响应机制:服务器执行函数后,可能通过响应消息向客户端返回执行结果。 需注意,当客户端主动调用函数时,通常意味着需要获取返回数据,通常被称作RR模式(Method Request with Response),但服务器方法也可能不返回任何值(Void类型),常被称作FF模式(Method Fire & Forget),此时客户端在确认方法被成功调用后即完成整个流程。 Service Discovery 为了让客户端能够获知当前可用的服务,SOME/IP-SD(服务发现协议)提供了两种动态服务发现机制: 服务提供(Offer Service): 服务器通过该机制向网络宣告其提供的所有可用服务 每个设备通过组播(multicast)方式广播消息 消息内容包含该设备提供的所有服务列表 传输层采用UDP协议 服务查找(Find […]