标签: 协议一致性测试

DoIP简介 以太网最早由BMW引入车内，其应用场景就是刷写，满足类似HMI的地图数据、液晶仪表等软件数据更新，感兴趣的可查阅Thomas Konigseder 的 Automotive Ethernet 书中的介绍。由于其突出的特性，而后得到主要OEM的推崇和更广泛的应用，遂开始了国际标准化（汽车行业一直以来的“套路”）。 DoIP全称：Diagnostic communication over Internet Protocol。顾名思义，通过以太网来实现车辆诊断，其对应的国际标准为ISO 13400，其定义了DoIP协议（基于UDS）并描述了外部测试设备与车辆进行诊断数据交互的流程。 下图为DoIP及基于以太网诊断在OSI 7层模型中及在“7层之外”的“角色”和“位置”。 图1 DoIP及以太网诊断规范框架 DoIP协议要点简述 DoIP报文 DoIP报文在以太网报文中的位置如下图。 图2 DoIP报文在以太网报文中的位置示意图 DoIP报文分为三大类：节点管理类、车辆信息类、诊断类。 节点管理类主要包括报头处理流程、车辆信息获取（如EID、GID、VIN等）、路由激活流程（包括授权以及确认功能）、TCP_DATA socket处理流程。 图3 节点管理类DoIP报文 车辆信息类主要包括获取DoIP实体状态信息、车辆电源模式信息。 图4 车辆信息类DoIP报文 诊断类主要包括诊断报文处理流程以及UDS数据交互。 图5 诊断类DoIP报文示 DoIP会话流程 关闭TCP_DATA socket。 图6 DoIP会话流程 图片来源：ISO 13400-2:Road vehicles - Diagnostic communication over Internet Protocol 边缘和内部节点差异 关于DoIP协议，ISO 13400规范做了框架性的定义，但OEM会依据整车功能需求自定义细节内容，同时会区分边缘节点和内部以太网节点，聊到此处有的小伙伴可能会有疑问，“以太网节点为何要区分边缘节点和内部节点？两者是否可以支持完整的DoIP协议？”接下来我们通过实例讨论边缘节点和内部节点在DoIP报文配置方面的差别。 问题一：内部节点需要支持诊断报文肯定应答(0x8002)么？ 分析：当Tester向内部节点发送诊断请求时，首先边缘节点会先向Tester发送0x8002报文，如果内部节点也支持0x8002报文，随后边缘节点又再一次转发内部节点发送的0x8002报文和诊断应答报文到Tester。 根据DoIP协议，Tester完成诊断报文发送后会等待0x8002报文同时开启P6Client定时器来接收诊断应答报文(暂时不考虑0x8003)。所以如果内部节点支持0x8002报文从系统设计方面考虑不符合DoIP协议，而且会导致以太网系统级诊断刷写测试P6Client参数超时。 图7 内部节点支持0x8002报文交互过程示例 问题二，笔者抛块砖：不同类型节点对路由激活报文该采用何种策略？ 有兴趣的，可就此类技术细节约聊，同样此话题可扩展包括DoIP其他报文针对边缘和内部节点不同的配置和支持方案，当然还有区别最明显的对硬线激活特性支持的差异。 万变不离其宗，以太网节点DoIP报文的配置要服务于整车功能,这部分更应该是OEM设计工程师需要从应用场景角度考虑而进行设计的。仁者见仁,智者见智,在不同拓扑、不同需求情况下设计方案也应当有所差异。 DoIP及以太网诊断测试方案和实践 DoIP及以太网诊断测试实现可以分层来介绍,当然在各层中OEM会在ISO标准需求的基础上做自定义开发。 针对ISO 13400-2的测试 测试内容包括DoIP报文格式、DoIP流程以及DoIP时间参数等，其测试脚本和测试工程通过CANoe（CAPL）定制实现。 图8 基于CANoe开发的部分测试项及测试脚本 图9 某控制器Alive_Check_Message测试报告 针对ISO 13400-3的测试 测试内容包括激活使能线等相关的测试，测试脚本同样通过CANoe（CAPL）开发实现，测试环境需借助于Vector的VT板卡，如VT2004实现硬线的仿真。 针对ISO 14229-1/-5的测试 可基于CANoe Option DiVa可实现，DiVa是Vector公司一款便捷、高效的诊断测试用例生成工具，使用DiVa实现UDSonCAN的测试大家都比较熟悉，那么对于以太网UDS测试DiVa是否也可以覆盖？答案是肯定的。DiVa可基于DoIP协议（ISO 13400）生成以太网UDS测试工程，即按照标准DoIP流程与ECU进行诊断数据交互。 图10 基于DiVa的以太网UDS测试工程 介绍到这里小伙伴们可能会有疑问，对于非标准DoIP协议的以太网节点是否也可用DiVa覆盖其测试需求？比如笔者曾遇到的OEM所定义的以太网节点仅支持DoIP净荷类型中特定的报文，或者以太网节点仅支持OEM自定义格式的诊断报文等情形。 总结 接着上面的问题，对于支持非标准DoIP协议的以太网节点UDS测试需做一 定的定制开发方可。另外，DiVa自动生成的UDS测试工程是否直接满足边缘和内部两种类型节点的测试需求呢，该如何适配？这也是笔者在项目实践过程中遇到的一些工程问题，还曾“遭遇”在DoIP测试过程中由于ARP配置而引起的“异象”以及端口固定等各类疑难杂症！限于篇幅，不做一一介绍了，感兴趣的小伙伴约起来吧！ 北汇信息已为多家主流OEM完成DoIP、以太网诊断、刷写测试相关的项目，为客户提供完整交钥匙工程服务，包括： 设计需求规范的审核完善 测试规范开发 测试脚本定制开发和测试实施服务 车载以太网技术扩散越来越快，相关测试验证工作及对测试验证深度、广度的要求也备受重视，所以实践实战的经验积累、对系统宏观层面的了解也更为关键，北汇信息希望与各位共同进步，价值分享。

什么是 中间件（Middleware） 在了解SOME/IP之前，我们先要了解“中间件（Middleware）”技术。简单来说，中间件是存在于操作系统和用户软件之间的一些中间层软件。它将操作系统提供的接口重新封装，并添加一些实用功能，以提供给用户软件更好的服务。 举例来说，在设计复杂的软件系统时，我们往往会设计很多互相独立的软件单元，一个很大的难题是如何在不同软件单元之间交换数据。对于开发者而言，如果在实现应用软件的同时，再把很多精力放在软件单元之间的通信上，会非常影响效率。于是我们可以设计一个“中间件”，用来管理不同软件之间的数据交互，这使得开发者不用去关心底层的通信，不同软件单元之间的“墙”变得透明。 中间件也有它的缺点，那就是体积和对计算资源的消耗。但是随着时代的发展，硬件的计算能力不断提高，所以中间件的缺点也就不那么明显了。为了简化复杂软件系统的开发（尤其是分布式系统），提高软件的可靠性，中间 件技术越来越不可缺少。除此之外，由于中间件使得用户软件和操作系统实现了“解耦”，也为测试工作带来便利。 在汽车电子领域也存在类似问题。在汽车电子的研发过程中，软件部分的占比越来越高，软件复杂度不断上升，当然ECU的计算能力也不断提升。类似传统的CAN通信——只是简单地把信号广播到总线上——越来越捉襟见肘，难以适应软件/ECU开发新要求。另外，不同的ECU可能有不同的软件架构（不同的操作系统），比如Linux、QNX或AUTOSAR，那么中间件技术将是这些不同系统之间重要的桥梁。 SOME/IP 简史 车载以太网技术伊始，AUTOSAR联盟最初的想法是直接移植现有的中间件解决方案，最好是开源的。列入备选清单的有Etch，Google Protocol Buffers，Bonjour等，理论上这些技术都可以移植到嵌入式系统这种计算能力有限的平台上，但最大的问题并不在于此。需要解决的问题是： 兼容性问题 我们知道AUTOSAR架构下有很多软件组件，它们已经实现了一些类似中间件的功能，并且可以通过专门的工具进行配置。为了避免不兼容，在集成中间件时必须绕过这些AUTOSAR 组件，或者使用完全相同的数据类型，而且需要对中间件进行重新拆分，才能“塞进”AUTOSAR的架构里。 开源软件的知识产权问题 虽然在备选清单上的这些方案都是开源的，但是当采用这些技术时却回避不了相应的知识产权及专利问题。这些开源软件的知识产权一般都掌握在 大型IT公司手中，存在不可预知的变数，即便解决了所有技术问题，也无法完全避开这些知识产权及专利问题。这也是AUTOSAR联盟决定开发一个全新的中间件解决方案（SOME/IP）的主要原因。 所以，SOME/IP天生就是为AUTOSAR量身打造的。从AUTOSAR 4.1起，SOME/IP就是AUTOSAR规范体系的一部分了。 SOME/IP的特点 为了满足汽车内的应用，SOME/IP进行了特殊的设计，特点如下： 面向服务的通信 轻量化 兼容AUTOSAR（唯一兼容AUTOSAR的中间件） 适配不同规模的计算平台 报头格式 图1：S OME/IP 报头格式 （图片引用自 《AUTOSAR SOME/IP Protocol Specification》 ） Message ID Message ID的前两个字节是服务（Service）的唯一识别号，定义为Service ID。每个服务都被分配了一个唯一的Service ID。服务包含了一系列的方法（Method），事件（Event）和字段（Field）。 他们都有一个唯一的Method ID，也就是Message ID的后两个字节，其中0 - 32767为方法（包括Method，Field.Getter以及Field.Setter），32768 – 65535为事件（包括Event和Field.Notify）。比如，多媒体系统中的“音乐播放器”可以作为一个服务“，切换到下一曲目”可以作为一个方法。 Length 包括Request ID，Protocol Version，Interface Version，Message Type，Return Code，Payload在内的长度，占用4个字节。 Request ID Request ID的前两个字节称为Client ID，可以用来识别一个具体的客户端。在整车范围内，Client ID必须是唯一的。比如用户想要通过多功能方向盘模块（客户端）向多媒体系统 （服务 端）发送请求来切换到下一首音乐，而后排娱乐影音控制面板也可以做出相同的请求，那么这两个请求就可以通过Client ID去区分。 后两个字节称为Session ID，可以用来识别来自同一客户端的多次请求。比如多功能方向盘模块（客户端）向多媒体系统（服务端）连续发送了多次请求，服务端可以通过这个字段来区分不同的请求。而服务端也会把Request ID复制到响应消息的相同字段中，这样客户端也能通过Request ID来判断收到的响应是针对哪个请求的。 Protocol Version SOME/IP的版本号，目前为1。 Interface Version 用来识别服务接口的主版本号，由用户定义。比如当服务增加了新的功能，或者发生变更，用户可以定义新的版本号，而客户端或服务端可以通过这个版本号来自动判断兼容性。 Message Type 用来识别不同的消息类型，目前存在五种类型，分别是： REQUEST(0x00) REQUEST_NO_RETURN(0x01) NOTIFICATION(0x02) REPONSE(0x80) ERROR(0x81) Return Code 用来指示请求是否被成功的处理了。 Payload 包含用户自定义的数据。 传输 层协议 SOME/IP 使用的传输层协议可以是TCP、UDP或SOME/IP TP。 如果传输的数据长度超过了1400字节，并且没有严苛的时间延迟要求，使用TCP传输 如果有时间延迟的要求（小于100毫秒），使用UDP传输 如果传输的数据长度超过1400字节，同时要求较小的延迟，可以使用SOME/IP TP 具体使用哪一种传输层协议跟具体的应用场景有关，如果以上提到的传输层协议均不能满足需求，用户还可以选择其他协议，比如1722等。 远程过程调用（R PC ） SOME/IP客户端和服务端之间的通信支持以下几种机制： 有响应的方法（Method with response） 客户端发送请求消息（Request）调用某一方法，服务端通过响应消息（Response）将结果返回给客户端。 图2： 有响应的方法 无响应的方法（Method fire & forget） 客户端发送请求消息（Request）调用某一方法，服务端不回复响应。 图3：无响应的方法 事件（Event） 客户端首先订阅（Subscribe）某一事件组（Event Group），当事件组中的包含的事件发生之后，服务端将通过Notification消息（Notify）通知客户端。Notification 消息不需要接收方进行回复，这一点有点像Fire & Forget消息。 图4：事件 字段（Field） 字段（Field）是客户端可以远程访问的服务端中的变量。 客户端可以通过远程调用Getter方法获取Field的值，也可以通过远程调用Setter方法设置Field的值。另外和Event相似，当客户端订阅了某个事件组，若事件组中包含的Field发生变化，服务端会主动的通过Notification消息通知客户端；当然，用户也可以选择周期发送Notification消息，这就和传统的周期性CAN报文很像了。 Field和Event的区别是：Field是一个持续存在的变量，比如多媒体音量，内灯亮度，车速，环境温度等；而Event指的是一个事件，事件没有发生就不存在，比如发生碰撞，出现故障等。 图5：字段 S OME/IP-SD SOME/IP-SD（Service Discovery，服务发现）是SOME/IP中的服务发现机制，客户端可以通过SOME/IP-SD来查找服务的位置，判断服务的可用性，或者订阅事件组等等，基于SD可以实现车内节点的“即插即用（Plug & Play）”。 SD在传统IT行业并不是一个新鲜事物，但是当这个机制被引入汽车电子领域时却引起了很多争议——因为车内环境是相对比较固定的，和互联网完全不同，我们完全可以将所有配置都固化以提高速度。但是需求和技术是不断动态交替发展的，我们不能以静态的眼光去评价一项技术存在的价值。所以究竟SD何去何从，现在还很难下结论，只能交给时间来验证。 S OME/IP 协议一致性测试 OPEN联盟发布的TC8是目前行业内关于车载以太网的标准测试规范之一，在2.0版本中加入了对SOME/IP协议的测试。 这里需要解释的是，SOME/IP本身只是中间件，它仅提供了若干接口，运行在其上的应用可以使用这些接口来完成通信。所以为了验证中间件的一致性，我们必须依赖应用来触发中间件产生特定的行为。这个应用可以是DUT自带的应用功能，或者是专门为了测试而开发的应用（也就是Test Stub）。按照应用类型的不同，在TC8中SOME/IP的测试分成以下两个部分： SOME/IP Server 这部分测试依赖DUT自身的SOME/IP应用功能，我们会在其中抽取一些典型的服务、方法，用来验证一些比较基础的内容，比如报文格式，基本的RPC和SD机制等。 在测试中，我们通过测试系统来仿真客户端发送请求，并接收DUT的响应。除此之外，在触发应用产生特定行为时，部分测试可能需要某些特殊手段。比如在触发DUT发送Event报文时，可能需要仿真I/O输入，或者开发一个测试用的软件接口。 下面我们通过一条典型测试用例，比如SOMEIPSRV_FORMAT_01，来具体说明测试过程（测试规范原文可参考TC8）： 启动DUT的服务 Tester监听DUT的发送端口 DUT发送Offer Service报文 确认DUT发送的Offer Service报文的Client ID字段为0x0000 停止DUT运行的服务 在这条测试用例中索引的需求为如图6所示，即在SD报文中不使用Client ID，必须将这个字段配置为0x0000。此条测试用例检验DUT发送的SD Offer Service报文中的Client ID字段是否和AUTOSAR规范中定义的是否一致。 图6： SOMEIPSRV_FORMAT_01 引用的A UTOSAR 需求 （图片引用自《 Specification of Service Discovery 》） 下图展示了通过思博伦的TTsuite 完成的部分SOME/IP Server测试报告与测试数据。 图7：部分SOME/IP Server测试报告与测试数据 这里需要注意的是，有些测试用例的执行有一些特殊要求，比如要求DUT实现多个服务，或同一个服务实现多个实例。但是DUT实现的应用和具体的业务流程有关，不一定能够满足这个要求，那么如果要执行这些测试用例，必须在原有应用上做一些修改，才能满足测试的前提条件。 SOME/IP ETS 这部分测试突破了被测控制器自身应用的限制，能够弥补上面提到的Server测试在覆盖度方面的不足。简言之，TC8定义了一个服务，称为ETS（Enhanced Testability Service）。 ETS中包含的各种Method，Event，Field等覆盖了SOME/IP所支持的全部数据类型，并包含了一些特殊的Method，比如resetInterface（用于重启ETS服务）等。 被测控制器集成了ETS后，我们能够对SOME/IP以及SOME/IP-SD进行充分而且全面的验证。关于ETS的更多信息，欢迎垂询北汇信息来进一步了解，我们可为您提供ETS集成的咨询服务。 我们同样选取一条典型测试用例，比如SOMEIP_ETS_21: echoINT8，来说明ETS的测试过程（测试规范原文可参考TC8）： “伪造”一个SOME/IP Request 报文，Method ID为0x000E，也就是echoINT8，在Payload中填入一个INT8类型的数据 发送“伪造”的SOME/IP Request 报文 DUT返回Response报文，Payload中的值和第一步中发送的值相同 这条测试用例索引的AUTOSAR需求如图8所示，即SOME/IP需支持的基本数据类型。在这条测试用例中验证了SINT8（INT8）类型。收到测试系统仿真的SOME/IP请求后，DUT首先会将请求中的Payload进行反序列化，如果得到了一个合法的INT8数据，那么再将这个数据通过序列化填入响应报文的Payload中，这样就验证了INT8类型的序列化功能。 图 8 ： SOMEIP_ETS_21: echoINT8 索引的A UTOSAR 需求 (引用自《 SOME/IP Protocol Specification 》 ) 下图展示了通过思博伦的TTsuite 完成的部分SOME/IP ETS测试报告与测试数据。 图9：部分SOME/IP ETS 测试报告与测试数据 总结 人们常把车载以太网看作是一种仅仅是带宽更大的车内总线技术而已，实际上车载以太网还带来了很多更重要的变革。 比如车载以太网提供的“面向服务”的架构思想。在此之前只有MOST总线才有这种设计，而受制于高昂的成本以及封闭性，目前仅有少数几家厂商在信息娱乐域使用了MOST总线。 站在技术的角度，MOST总线使用面向服务的设计不是没有原因的，因为信息娱乐域所需要的软件接口和数据类型往往十分繁杂，而近些年来在非信息娱乐域的控制器网络中，类似的情况也逐渐显现，而面向服务的架构，包括远程过程调用（RPC），能够很好地简化系统设计。 目前除了发展不太乐观的MOST，其他几乎全被面向信号的通信方式独占了，包括CAN，LIN等。但是近些年来兴起的这些新需求，类似CAN的这种面向信号的通信方式已经越来越不适用了。随着汽车电子系统的功能不断丰富以及车载以太网的应用，我们相信，面向服务的通信将是未来。 部件级SOME/IP一致性测试在测试条件和方法上与传统车载通信测试存在一定差异，而且TC8测试规范以及测试工具链都处于迭代和完善中，给测试人员带来了多方面的挑战。测试过程中的问题需要结合数据进行分析，需不断积累实践经验，这是笔者比较深刻的体会。 另外，从部件级SOME/IP定制应用测试、从系统级和实车级验证的角度，SOME/IP测试已将传统网络测试和功能测试的边界模糊化，这也是需提前储备知识应对的新局面。 参考文献： 《 Automotive Ethernet 》 KIRSTEN MATHEUS and THOMAS KÖNIGSEDER 《 AUTOSAR SOME/IP Protocol Specification 》 《 AUTOSAR SOME/IP Service Discovery Protocol Specification 》