标签: 通信协议

一 . 引言 在当今快速发展的汽车行业中，车载以太网正逐步成为推动汽车智能化、网联化浪潮的核心技术之一。作为传统以太网技术在汽车领域的创新应用，车载以太网不仅继承了以太网的开放性、成熟性和互操作性，还针对车辆特有的环境和需求进行了优化与定制，为车载内部的复杂数据传输提供了高速、可靠、低延迟的通信平台。 在复杂的车载网络拓扑中，主机间通信最初只知道目标设备的IP地址，那如何获取目标设备的MAC地址呢，这就不得不提到一个关键协议——ARP协议。 二．ARP概念 ARP协议（Address Resolution Protocol，地址解析协议）在车载以太网中的作用与传统以太网中作用相同，是一种网络层协议，在网络世界中扮演着至关重要的角色，它就像是网络中的地址翻译官，负责将网络层的IP地址转换为数据链路层的MAC地址。 三．ARP工作原理 当主机A向主机B发送数据包时，会经过以下几步： ARP缓存查询：主机A首先会在自己的ARP缓存表中查找主机B 的IP地址对应的MAC地址，如在缓存表中存在映射关系，则将IP数据包封装成以太网帧并发送给主机B。 ARP请求广播：如果主机A在本地ARP表中查询不到主机B对应的MAC地址，主机A会以广播方式发送一条ARP请求报文，ARP报文中源IP地址和MAC 地址为主机A的IP地址和MAC地址，目标IP地址是主机B地址，目标MAC地址设置为00:00:00:00:00:00 。 ARP响应：因ARP报文以广播方式发送，网段上所有主机都会接收到ARP请求，当主机B收到ARP请求后会比较自己的IP地址和报文中的目标IP地址是否相同，如果相同则回复一条单播ARP响应报文给主机A，响应报文中包含了主机B的IP地址和MAC地址，同时将发送端的IP地址和MAC地址存入主机B的ARP缓存表中。 缓存更新：主机A收到ARP应答后，将主机B的IP地址和MAC地址的对应关系存入自己的ARP缓存表中。 数据传输：主机A知道了主机B的IP地址和MAC地址，将IP数据包封装到以太网帧中发送到主机B。 四．ARP数据格式 1.以太网帧头： 目的MAC地址：占6字节，表示目标主机的MAC地址，作为ARP请求帧，目标MAC地址应设置为FF:FF:FF:FF:FF:FF; 源MAC地址：占6字节，表示源主机的MAC地址； 帧类型：占2字节，表示后面报文类型，对于ARP报文来说该字段值为0x0806； 2.ARP报文格式(以常用ARP报文为例)： 硬件类型：占2字节，表示硬件地址的类型。它的值为 1即表示以太网地址； 协议类型：占2字节，表示要映射的协议地址类型，值等于0x0800时为IPv4协议； MAC地址长度：占1字节，表示MAC地址长度，值为6； IP地址长度：占1字节，表示IP地址长度，值为4； 操作类型：占2字节，表示ARP报文类型，值等于1时为APR请求报文，值等于2时为ARP应答报文； 源MAC地址：占6字节，表示源主机的MAC地址； 源IP地址：占4字节，表示源主机的IP地址； 目的MAC地址：占6字节，表示目标主机的MAC地址，在ARP请求报文中该字段值全为0 ； 目的IP地址：占4字节，表示目标主机的IP地址； 五．报文解析示例 ARP请求报文解析示例： ARP应答报文解析示例： 六．ARP表 ARP表是主机内部的一个高速缓存表，用于临时存储IP地址和MAC地址的映射关系，可分为静态ARP表和动态ARP表： 静态ARP表：通过手工配置和维护，不会被老化，不会被动态ARP表项覆盖。 动态ARP表：动态ARP表由ARP协议通过ARP报文自动生成和维护，可以被老化，可以被新的ARP报文更新，也可以被静态ARP表项覆盖。 七：常见ARP老化过程 ARP 老化是指 ARP 缓存表中的条目在一定时间内没有使用而被删除的过程： 1. 老化时间内：当一个缓存条目在老化时间内没有被使用（即没有通过该条目发生过通信），它就会被视为过时并从ARP表中删除。 2. 更新重置：在老化时间内有新的数据包需要通过此ARP条目转发，该条目的老化周期将被重置，即其老化计时器会被重新开始计算。 3. ARP探测报文：当达到老化时间后，系统会发送一定次数的ARP探测报文，以确认该条目是否仍然有效，若探测失败，则删除该缓存条目。 八．免费ARP 当主机发送ARP请求，但请求的目标IP地址是自己本身的IP地址。这种类型的ARP不是为了获取MAC地址，而是用于更新网络中的ARP缓存、检测IP地址冲突或宣告主机更换了新的IP地址。 因免费ARP这些特性使其在DHCP(动态主机配置协议)过程中扮演着重要角色，当DHCP客户端从服务器获得了一个新的IP地址后，会发送一个免费ARP广播包，其目的是检查网络中是否有其他设备在使用相同的IP地址，如果存在另一台设备使用相同IP地址，它将响应这个ARP请求，从而客户端可以意识到地址冲突并重新向DHCP服务器请求一个新的IP地址。在此过程中确保了新分配的IP地址的唯一性，并促进了网络中的设备能迅速识别出客户端的IP地址和MAC地址映射关系。 九．总结 ARP协议是网络通信的基石之一，它的实现也需要符合特定的标准和规范（如IEEE 802.3以太网标准）。作为车载以太网相关测试人员了解ARP协议概念及原理是重要的，在车载网络中可能包含来自不同制造商的主机，它们在实现ARP协议时可能存在差异，通过测试可以验证整个网络中所有主机都能遵循相同的规则进行地址解析。同时为了提高车载网络中不同主机间的兼容性，OPEN联盟发布了相应的测试规范，其中《OPEN Alliance Automotive Ethernet ECU Test Specification Layer 3-7》文档中定义了ARP协议相关测试内容，如字段检测、动态学习、老化机制等。 北汇信息是一家专注于汽车电子测试领域的企业，对车载以太网测试有着丰富经验，并可提供相关培训、咨询服务以及测试解决方案，帮助汽车制造商和零部件供应商确保其车载以太网系统的可靠性和安全性。如果需要具体的测试服务或了解更多信息，欢迎大家来联系我们。 参考文献： 【1】《TCP/IP详解 卷1：协议》 【2】《车载以太网权威指南》 【3】《RFC 826文档》

在工作期间，我有机会仔细地研究现代车辆上的一些最新传感器技术。虽然这些特殊的传感器已经存在一段时间了， 但是SENT技术越来越多地出现在车辆中。在汽车论坛中，我发现有关使用这些传感器的问题和讨论有所增加。这些现象促使我去研究如何利用虹科Pico示波器从这些传感器中获得尽可能多的信息。 我不会在SENT协议上花费太多时间，因为网络上有很多关于该协议如何工作的资料。但是，我会简单介绍一下这个网络。 SENT代表单边半字节传输，并遵循J2716标准。它是低成本且单向的（仅一个方向），这意味着传感器只能发送数据。 SENT 传感器 与其他传感器的不同之处在于，可以通过一根导线“发送”多个数据。 例如，一个SENT传感器可以使用一根导线同时发送压力和温度测量值。这使其成本低廉，并减少了布线需求，而这正是制造商一直想要做的。这意味着您很可能会看到MAF传感器只有三根线，当需要测量时，会有一个5V电源线，一个GND和一个信号线。 如上所述，SENT可以传输多个数据，它可以通过从FAST消息中取出的“半字节”创建SLOW消息来实现此目的。要建立一条SLOW消息，它需要多条FAST消息。这里重要的一点是，可以使用PicoScope 6 Automotive软件中的串行译码功能对这两个消息进行译码。 那么，SENT数据包是什么样子的呢? 图1 如图1所示，SENT数据包很容易被误认为是一个脉宽调制信号（PWM），这是因为它的电压为0-5V，工作周期在不断变化。在本文中您可能还注意到，SENT似乎还存在反转信号。这不是故意的，这只是发送协议的另一个特征，信号的极性可以改变，但数据保持不变。 图2 我将介绍如何设置译码器的参数，但是为了让大家都能看到SLOW信号是如何构成的，我已经在提前设置好了译码器。由图2可见，组成一个SLOW消息需要几个FAST数据包。请注意这一点，因为SLOW消息包含与传感器相关非常有用的信息。 但是请注意，为了确保您 采集到 所有数据， 通常 需要花足够长的时间捕获 信号波形 。 如果我们继续使用上面的波形，最实际的做法是先从SLOW译码器开始。 图3 单击工具 串行 译码 SENT Slow 我建议您首先从SLOW消息开始的原因是，通常您可以在此数据中找到有关传感器的信息，这是设置SENT Fast译码器所必需的，比如传感器的类型。为了完成译码，软件将根据所选通道自动设置阈值和滞后量。您会注意到该信号并不是“完美的”信号，存在一些干扰。 您可以使用通道选项中的低通滤波器来“清除” 干扰 信号 ， 我发现300 kHz的 过滤 效果很好。 您也可以自定义设置电压阈值以及滞后量，下面的设置是在低通滤波器被激活后完成的，可以将电压阈值设置为3 V，滞后最小设置为40mv（图4）。完成后，单击“确定”并确保在再次单击“确定”之前勾选中译码器（图5）。在波形的底部将生成一些可读的数据。不幸的是，我们仍然缺少一些其他传感器信息。如果在屏幕上捕获更多的时间，我们就可以获得有关传感器的更多信息，这也意味着我们可以更准确地创建SENT Fast译码器。 图4 图5 我们本可以继续进行此捕获并猜测传感器的类型，但是需要更长的捕获时间才能将其与其他信息一起译码。如图6所示，我对捕获到的波形应用了Slow译码器，该传感器是EGR冷却器中的压力传感器，捕获发动机启动时快速WOT(节气门全开)测试的信号。 图6 数据包越多，我们就越有机会找到在SLOW信号中传输的一些其他信息。图6中第8个数据包是我们感兴趣的数据包，如您所见，它为我们提供了有关传感器类型的信息。在设置FAST译码器时，有一点很重要，我们可以看到在传感器类型中可以选择压力/安全传感器（图8）。但是其他数据也同样重要，尤其是制造商代码（图7）。消息ID可用于确定是哪个制造商制造的传感器，可以在Internet上进行快速搜索，下面列出了我到目前为止发现的，仅供参考： 图7 让我们回到PicoScope 6软件，图8中A通道蓝色波形是在油轨高压 传感器信号线测得的，该传感器通过SENT向ECU发送信号。在串行译码中，我们从列表中选择SENT FAST，然后配置参数（图8）。 图8 您会发现知道传感器类型对我们很重要，可以从列表中选择特定的传感器类型（图8），在这里我们从较早时就知道它是压力/安全传感器。对于这个我不做过多介绍，因为这不是本文的目的，重要的是数据字段的格式会根据传感器类型而变化。PicoScope允许您从标准J2716列表中选择所需的格式类型。 图9 如图9所示，译码表中同时包含 Slow data和 Fast data。要在两者之间切换，请单击屏幕底部每个表的选项卡，其中显示了SENT Slow和SENT Fast的标签。为了更好地了解传感器的功能，下一步是使用PicoScope中的导出功能。 在译码表中，确保已选中“SENT Fast ”选项卡，并且仅查看当前缓冲区的译码数据，然后单击“导出”（图10）。然后将文件保存在易于查找的位置，找到已保存的文件，并在Excel中打开它。 图10 图11导出的是EGR冷却器中的压力传感器SENT Fast译码后的数据，您将看到PicoScope的译码表，但仍需进一步处理数据。 图11 这么多的数据看起来有点复杂，但是我们将以熟悉的方式做一些非常简单的操作来可视化传感器的工作情况。SENT消息的数据包会根据传感器的类型进行拆分，分别标记为通道1和通道2。图12是一个示例，对此进行了更详细的说明。 图12 在PicoScope中应用SENT Fast串行译码器时，会告诉软件如何分割数据。在图12中，将数据字段进行了常见的偶数拆分，拆分为通道1的12位和通道2的12位。我们知道在PicoScope中查看的传感器类型是压力/安全传感器。根据J2716标准，可知通道1上存储的是压力数据。返回Excel工作表时，我们可以通过创建图表来可视化数据，选择通道ch1列D（图13）。 图13 选择数据后，单击“插入”并找到“折线图”选项，如图14和图15。 图14 图15 现在我们有了从SENT传感器捕获的数据的图形化图像。我们可以放大图形，选择数据源并修改范围能够将图形集中在我们想重点分析的数据区域上。在图16和图17中，我选择查看D5625和D12140之间的数据。 图16 图17 在图18中，我将数据范围修改为D5625和D6625之间，图像有点类似于排气脉动波形。 图18 图19是对MAF传感器SENT Fast译码后的数据做了相同的处理，MAF这个SENT传感器发送气流和温度信号。我使用PicoScope捕获了数据，将其译码并导出。然后，我根据通道1上的数据创建了一个图表。在WOT快速测试之前，我还在发动机怠速时进行了类似的测试。 图19 图20是我们通过修改范围得到的曲线图。 图20 但是到目前为止，我遇到了一个小问题。我无法正确解释通道1或2的值，并将其转换为我们可以关联的度量单位，比如压力单位和温度单位。传感器转换数据的方式和SENT Slow消息中的特征相关，我还没有成功地关联测量值。话虽如此，但我觉得这是一种以前所未有的方法，可以帮我们可视化传感器信号。对于排气压力传感器和MAF传感器，我发现最好把时基设置为1s/div至2s/div之间以进行长时间捕获，同时保持较高的采样率（目标是10MS），以确保可以正确译码。否则译码后会出现一个黄色警告三角形，提示“采样率可能太低”，除此之外，在译码方面还没有任何其他问题。您可以通过添加一个触发器来避免数据丢失，但是您必须准备好执行快速测试，我们也将继续研究触发器的功能，因为这是我在捕获时遇到的一个比较棘手的问题。 希望本文中的内容对您有所帮助，并请您提供任何相关的建议，如果我后续有其他想法，会继续进行更新。 作者：Ben

众所周知，Pico汽车示波器可以解码CAN Bus、LIN Bus协议，但好多人还不知道我们强大的Pico示波器还能解码SENT总线协议。本文将详细说明如何进行SENT协议的解码。 SENT 全称：Single Edge Nibble Transmission，是美国机动车工程师学会SAE推出的一种点对点的、单向传输的方案，被用来在汽车中的传感器和电子控制单元(ECU)之间传输高清传感器数据。传感器数据通过两个下降沿周期之间的一系列脉冲序列来传输。 1.布线 SENT总线仅需要一根信号线和5V电源导轨和地线。 2.信号传递 SENT用节拍（ticks）作为时间单位，一个节拍一般是3us。 SENT报文起始位是一个同步脉冲，该脉冲与后续的下降沿之间的时间间隔等效于56个时钟节拍。 同步脉冲之后，状态/通信半字节按照SENT格式传送状态和/或慢速通道数据位。 数据通过4个数据位为一个单元来传输，或称“半字节”。用半字节时，原始逻辑0时间是一个固定的5个或更多个节拍，跟着是可变周期的逻辑1。总半字节时间计算节拍单位中编码4位的数据。12个节拍= 二进制0000（16进制0），13个节拍= 二进制0001（16进制1），14个节拍= 二进制0010（16进制2）等等。在每条报文的尾部插入一个固定长度不超过1ms的暂停脉冲。 3.基于PicoScope的SENT解码 第一步是使用PicoScope获取感兴趣的SENT信号。然后从工具菜单中选择 串行解码 。 然后从可选择的协议表中选择SENT协议。 第二步在SENT确认对话框中选择PicoScope数据 输入通道 、 节拍时间 、 传感器类型 和其它需要的参数。 第三步点击 下一步 ，填写名称、选择显示格式和显示方式等，点击“完成”。 在PicoScope图形显示中查看解码发送信息。

DDS概述 DDS是OMG在2004年发布的中间件协议和应用程序接口（API）标准，它为分布式系统提供了低延迟、高可靠性、可扩展的通信架构标准。DDS目前在工业、医疗、交通、能源、国防领域都有广泛的应用。OMG（Object Management Group）成立于1989年，是一个开放性的非营利性的计算机行业标准联盟。OMG多年来致力于为工业分布式系统提供可互操作的，可移植的，可复用的软件标准。它的成员包括IT行业的设备供应商，终端用户，政府部门，以及学术组织等。很多我们熟知的标准都来自OMG，比如UML（Unified Modeling Language），CORBA（Common Object Request Broker Architecture）等。 在关于SOME/IP的文章中我们曾简单解释过中间件的概念，即在分布式系统中，中间件是位于操作系统和用户应用程序之间的软件层，它将操作系统提供的资源进行抽象和封装，为应用程序提供各种各样的高级的服务和功能，比如通信或数据共享。中间件的存在简化了应用程序开发者的工作，这使他们能够将注意力放在应用程序本身上，而不必在不同应用程序之间或不同系统之间的数据传输上花太多精力。 DDS最重要的特性是以数据为中心，这是与其他很多通信中间件不同的地方。必依赖其他的上下文信息。同时，DDS能够按照用户定义的方式自动地进DDS的数据共享以Topic为单元，应用程序能够通过Topic判断其所包含的数据类型，而不行存储、发布或订阅数据，使应用程序能够像访问本地数据一样去写入或者读取数据。 DDS实现的数据共享可以理解成一个抽象的“全局数据空间”，任何应用程序，不论开发语言，或者运行的操作系统类型，都可以通过相同的方式访问这个“全局数据空间”，就好像访问本地的存储空间一样。当然“全局数据空间”仅仅是一个抽象的概念，在实现时仍然是分别存储在每个应用程序的本地空间当中。在系统运行时，数据是按需传输或存储的，数据的发布者仅仅发送对方需要的数据，而订阅者仅接收并存储本地应用程序当前需要的数据。 DDS还提供了非常灵活的QoS（Quality of Service）策略，以满足用户对数据共享方式的不同需求，比如可靠性，故障处理等等。针对数据安全性要求比较高的系统，DDS还提供了细颗粒度的数据安全控制，包括应用程序身份认证，权限控制，数据加密等等。 类似于SOME/IP-SD，DDS提供了对数据发布者和订阅者的动态发现机制，这意味着用户不必去配置通信节点的地址或其他属性信息，因为他们在运行的过程中会自动发现对方，并自动完成相关配置，即实现了“即插即用“。 DCPS模型 DCPS（Data-Centric Publish-Subscribe）是DDS标准中定义的以数据为中心的订阅-发布模型。在这个模型中，向“全局数据空间“写入数据的一方称为 Publishers 和 DataWriter ，同样地，在”全局数据空间“中读取数据的一方称为 Subscriber 和 DataReader ，下图中展示了它们之间的逻辑关系。除了DCPS模型，DDS标准中还定义了一套完整的应用程序接口（API），该接口标准是与平台无关的，这意味着不论应用程序使用什么开发语言，或运行在什么平台之上，只要DDS中间件的实现符合DDS标准，那么相关的应用程序即可实现不同平台间的移植。 数据的发送过程，简单来说就是应用程序调用DataWriter对象提供的write方法，把数据传递给Publisher对象，而Publisher负责将数据在网络上发送出去。 数据的接收过程，简单来说就是Subscriber负责从网络上接收数据，并把它存储在对应的DataReader中。应用程序可以为对应的DataReader注册一个回调函数，或者使用DataReader提供的read和take方法来轮询DataReader中的数据。 具体来说，DataWriter在逻辑上从属于Publisher，并受Publisher管理。一个DataWriter只能从属一个Publisher，而Publisher可以拥有多个DataWriter。每一个DataWriter都绑定一个Topic，所以同一个应用程序中可能存在多个DataWriter和Topic，此外还可以为同一个Topic绑定多个DataWriter。 同理，DataReader在逻辑上从属于Subscriber，并受Subscriber管理。一个DataReader只能从属一个Subscriber，而Subscriber可以拥有多个DataReader。每一个DataReader都绑定一个Topic，所以同一个应用程序中可能存在多个DataReader和Topic，此外还可以为同一个Topic绑定多个DataWriter。 这个DSCP模型的工作过程实际上很像日常生活中报纸的发行过程。我们以《人民日报》为例，其中Topic就是“人民日报“，数据即报纸中的文字或者图片，DDS中间件负责报纸发行的所有中间环节和渠道，包括报纸的印刷，存储，运输等等。 QoS策略 用户可以通过设置QoS策略来控制数据在应用程序之间共享的方式，每个DCPS实体，包括Topic，DataWriter，Publisher，DataReader，Subscriber等，都能够独立配置相应的QoS策略。 下面是几种常用的QoS策略： DEADLINE 如果希望某个Topic能够周期更新，可以设置DEADLINE属性。在数据的发布方设置DEADLINE，这意味着应用程序必须以小于DEADLINE的周期去更新Topic，而在数据的订阅方设置DEADLINE，这意味着数据的发布方必须以小于DEADLINE的周期去发布Topic。 LIFESPAN 通过设置LIFESPAN，可以使DataWriter写入的每个数据样本都有一个关联的“到期时间”，超过该时间后，该数据样本不再传送给任何应用程序，并且这些数据将从DataReader缓存中清除。 HISTORY 设置HISTORY属性可以让DataWriter保存并发送旧的采样数据，新的DDS节点如果订阅了相关的Topic，它不仅能够接收到数据的当前值，也能收到一部分历史值，从而了解数据近期的变化趋势 RELIABILITY 为DataWriter设置RELIABILITY属性，可以使数据实现“可靠”的传输，当出现通信错误导致数据采样没有被接收到时，DataWriter会持续重传，直到所有数据被正确接收。 RTPS协议 DDS的标准中并不包含传输层协议，所以不同的DDS实现可能使用不同的消息交互方式，甚至使用不同的传输协议，这就可能导致来自不同厂家的DDS实现是不能互操作的。而随着DDS在大型分布式系统中的应用越来越广泛，制定统一传输层标准的需求越来越强烈。 RTPS（Real-Time Publish Subscribe）就是在此背景下诞生，它主要为了满足工业自动化领域大规模分布式系统的需求，也能够很好的契合DDS协议特点。规范中定义了消息格式，各种使用场景下的消息交互方式等。它的主要特点包括： 1. 提供容错机制，避免单点故障 2. 高扩展性，支持“即插即用” 3. 模块化设计，针对计算能力较弱的平台，可 只实现R TPS 的一个子集功能，并且不会出现兼容性问题 RTPS基于多播、无连接的传输模型，这个模型可以映射到不同的传输协议上，如UDP/IP（这也是目前RTPS标准中唯一被标准化的传输协议）。除此之外，基于TCP的传输，以及基于TSN（Time-Sensitive Networks）的传输的相关标准也在制定中。很多DDS的实现支持除UDP/IP之外的多种传输协议，但并没有遵循统一的标准，因此不同供应商的DDS实现之间可能存在互操作问题。 DDS与SOME/IP DDS与SOME/IP存在诸多不同，但是需要强调的是，二者的设计需求不同，目标应用场景不同，所以我们不能简单的判定孰优孰劣。在选取技术方案时，应考虑具体的应用场景，结合各个方案的功能，性能，成本等多个维度，才能做出合理的选择。我们可以从以下几个方面进行对比，为读者提供参考。 l 通信模式 SOME/IP是面向服务的通信，服务端将方法和数据以服务的形式暴露给其他节点。而DDS最大的特点是以数据为中心，侧重数据的分发，这种模式其实很像传统的面向信号的通信，只不过DDS更灵活，功能更强大。 l 应用程序接口 SOME/IP协议标准中没有定义标准API，所以基于不同SOME/IP实现的应用程序一般是不能互相移植的。DDS制定了多种编程语言的标准API，因此DDS应用程序理论上能够在不同的DDS实现上进行移植。 l 传输协议 SOME/IP支持UDP和TCP，此外，从AUTOSAR 4.3开始支持对大于1400字节的UDP数据进行分段传输，即SOME/IP-TP。DDS则使用前面提到的RTPS协议，至少支持UDP/IP，而很多DDS实现还支持其他传输协议，如TCP。 RTPS实现了与传输无关的可靠性和分段协议，理论上可在任何传输形式之上运行。 l 安全性 SOME/IP本身并不提供数据安全的控制，所以它的安全性依赖于传输协议，比如基于IPsec或TLS上运行。DDS当然也可以在IPsec或TLS上运行，但这并不是首选的方式。DDS提供多种插件，实现了对安全性的更细粒度的控制，比如数据的加密传输，读写权限控制，应用程序身份认证等，并且DDS安全机制与传输协议无关，因此使用任何传输协议都不影响安全机制的实现。 l QoS支持 DDS提供多种QoS策略，而SOME/IP本身不提供QoS的支持，因此只能在传输协议或者应用程序中实现。 l 资源需求 DDS在诸多方面提供了更丰富的特性，这自然就导致了在资源需求上，比如内存占用，比SOME/IP要大得多。 l AUTOSAR平台支持 AUTOSAR Adaptive平台从2018年起开始支持对DDS的绑定，Classic平台目前还并没有支持DDS绑定的规划。而SOME/IP是针对汽车应用定制的，可以无缝部署在AUTOSAR Adaptive和Classic平台中。 DDS测试 OMG组织并不提供DDS软件实现，各厂商可以根据该标准实现自己的DDS。我们可以在DDS官网（https://www.omg.org/dds-directory/）查询DDS的供应商列表，用户可以按照自己的具体需求进行选择。这种由第三方供应商提供的预构建软件，一般称为商业现货软件（COTS）。对于COTS软件，我们在测试策略的选择上与自行开发的软件是不同的。一般来说，COTS软件往往是经过市场和时间验证的产品，其核心部分是比较稳定的，并且已由供应商进行了单元和功能测试。因此我们可以减少对COTS软件本身功能的重新测试，应该更侧重在系统集成测试或性能测试等测试类型上。 下面为大家展示了一个简单的DDS硬件在环（HIL）测试环境。 Figure SEQ Figure \* ARABIC 3 DDS 测试环境示例 为了保证ECU的正常运行环境，并监测或触发ECU的某些行为，我们需要仿真ECU的外围IO信号或者总线信号，这时我们可以借助Vector提供的丰富的IO激励和测量板卡，如VT系统，以及总线接口卡，如VN系列硬件等工具。在测试环境中，我们还需要仿真DDS Writer或者Reader，来发布或订阅ECU的DDS数据，以此来验证被测节点的变量范围，非法值的错误处理机制等。由于CANoe暂不支持DDS节点的仿真功能，我们可以使用开源或者DDS厂商提供的库，如pydds，RTI Connector等，来快速搭建DDS应用程序，并在CANoe中编写接口来控制仿真节点。 测试用例方面，可使用vTESTstudio进行测试用例的设计和管理。vTESTstudio不但提供了图形化和图表化的测试用例设计方式，而且提供多种基于测试参数自动生成测试用例的功能，并支持模糊测试，能够极大的提高测试用例的开发效率和测试覆盖度。 总结 自从汽车在十九世纪末被发明以来，技术的创新就从未停止过。汽车作为一种消费产品，已经从最初的交通工具变成了一种生活方式，正如今天的智能手机不再仅仅是一个打电话的工具而已。通过持续的技术创新和融合，汽车变得更安全，更人性化，更智能，更互联。DDS的引入，无疑是在汽车和互联世界之间打开的另一扇大门。至于DDS能否在汽车行业内得到更广泛的应用，还需要更全面和更细致的评估，但我们期待DDS以其丰富的特性和功能，能够为汽车应用领域带来更多可能性，帮助应对汽车智能化和互联化道路上的更多挑战。 索引文档 Data Distribution Service (DDS) Version 1.4 DDS Security Version 1.1 The Real-time Publish-Subscribe Protocol DDS Interoperability Wire Protocol (DDSI-RTPSTM) Specification Version 2.3

协议与站队 协议 ,表面上是甲和乙之间约定的联络规则。但实际上，他是工业物联网各大巨头攻城略地地利器。 在 2C互联网的世界里，一根网络连着两端，一端是装在普通用户家里的电脑上，通过电脑屏幕给用户看的，另一段连着不同巨头的服务器，有电子商务，有交友。对于用户，你的电脑就是你的工具，是你消费喜好的体现，因此，你的电脑的网络就成了各大巨头争夺的前沿。 在 2B物联网体系内，通信协议的一端是服务器，是平台，是数据库，是各大巨头提供的。另一段是设备，代表的是企业的生产、财务、数据、流程，是企业精髓的前沿。不同于互联网的世界，普通用户是无法选择或定义他自己的上网协议的。而在物联网的世界内，任何一个组织，有可能定义自己的语言。在这个意义上，理解了这种语言，就具备了和企业的设备交流的可能，进而具备了为企业的信息化服务的可能。在这个意义上，通信协议之争，成为物联网体系入口之争的典范。 每一个提供物联网平台服务的信息化方案提供商 ，必然会制定本平台的私有协议，这是必然的结果，商业，本来就是排他性的。现在，我们可以看到巨头们纷纷招兵买马，推出各种优惠，在工业物联网领域开启了一轮跑马圈地的竞争。近二十年以来，互联网的发展始终伴随着这类似的场景。 此时，任何一个入网的企业，必然面临着平台的选择。请各位注意，此时，建议选择通用协议。其一，通用协议是经过时间和空间成熟验证的协议，已具备广泛的认可；其二，一旦使用了某平台的私有协议，相当于绑在了该平台的战车上，难以更换平台，这是平台服务商的目的所在，是他们持续盈利的基础。 企业选择工业物联网平台时，请把他们看作是信息化领域的供应商，和自己其他的供应商没有设么区别，货比三家。更重要的是，需要制定供货标准，包括通信协议，如果自己没有能力，可委托第三方咨询公司制定。标准化需求的制定，会使得企业站牢甲方位置，而不会被各种高大上的名词所迷惑。