标签: 协议栈

在上一篇文章中，我们对 DDS 协议测试的策略、方法和工具进行了详细的介绍。本文旨在进一步探讨如何利用这些方法和工具搭建实际的测试环境，并执行测试，进而揭示可能遇到的各类问题。 被测协议栈简介 在本次测试中，被测协议栈选择了一个在汽车行业内广泛使用的开源 DDS 产品。 近年来随着开源软件社区的不断发展和成熟，越来越多的整车厂在选择 DDS 协议栈实现时，开始青睐开源产品。相比商业化的 DDS 协议栈，开源产品具有显著的成本优势。此外，使用开源产品还可以让整车厂获得更大的自主可控性，以便根据自身需求对协议栈进行定制和优化。 然而天下没有免费的午餐，选择开源 DDS 协议栈也意味着使用者必须承担起产品质量的责任。与商业化产品不同，开源产品通常没有专门的团队负责质量保证。因此，开源 DDS 协议栈的使用者必须投入额外的精力和资源，甚至组建专门的软件团队，来全面评估、测试和维护所选择的开源产品，以确保其功能和性能满足汽车行业的严苛要求。 在本篇文章中我们试图准确地识别出可能存在的问题，希望为汽车行业用户在选择开源 DDS 协议栈时提供实用的参考。 测试环境搭建 被测的 DDS 协议栈部署在一台运行 Ubuntu 操作系统的 x 86 服务器上。这种部署方式能够为 DDS 协议栈提供一个简单、稳定，且一致的运行环境，避免资源或网络配置错误等原因导致的测试结果不可信。 同时，为了全面评估 DDS 协议栈的功能和性能，我们在 DDS 之上部署了两个专门设计的测试应用程序。这两个应用程序的主要目的是模拟真实场景下的应用程序对 DDS 接口的调用，以验证 DDS 能够正确地处理各种请求并返回预期的结果。通过这种方式, 可以全面检验 DDS 的接口是否符合 OMG DDS 标准，以及是否能够满足汽车行业的特定需求。 为了实现对测试过程的自动化控制和管理，我们在上位机中开发了一套专门的测试脚本。这些脚本负责向 DDS 测试应用程序发送各种测试指令，根据预定的逻辑对测试应用程序的行为进行编排和调度。测试过程全自动化，无需任何人工干预，能够确保测试过程的一致性和可重复性。 此外，为了方便工程师对测试用例进行管理和监控，上位机软件还提供了一个直观的图形化界面。通过这个界面，测试人员可以轻松地创建、编辑和组织测试用例，并实时监控测试的执行状态和结果。 图1: DDS测试环境搭建 需要强调的是，测试环境可以根据用户的具体需求进行灵活地配置。比如将 DDS 测试程序部署在一个或多个真实的 ECU 中，以帮助我们发现系统性的网络配置问题、兼容性问题或性能问题等，包括防火墙、IP 地址、端口号、TSN 约束、时间同步、网络拓扑结构问题，DDS 中间件与不同硬件和软件平台之间的兼容性问题，也包括吞吐量、延迟、资源占用等指标。从而全面评估 DDS 分布式系统在实际应用场景下的可靠性、兼容性和性能表现，为系统的开发和优化提供重要的依据。 测试用例介绍 测试用例覆盖了 OMG DDS 规范中定义的所有软件接口，共 406 条测试用例，内容如下： 接口行为测试，包括正常调用时的行为测试，以及错误调用的故障行为测试，共计 353 条用例 QoS 测试，即 OMG DDS 中定义的各项 QoS 的功能测试，共计 53 条用例 关于性能测试，由于 DDS 的性能很大程度上取决于硬件平台的性能和资源情况，以及操作系统的调度和管理机制，故在测试服务器中得到的性能测试结果与实际系统的性能表现可能相差很大，故本次测试不包含性能测试。 测试结果分析 概览 本次测试共计执行 406 个测试用例，通过194个，失败 212 个，通过率为 47.78%。如下为各模块的通过情况。 图2: 测试结果概览 问题示例 1. 功能缺失 如下表格列出了部分当前版本 DDS 缺失的接口。这些缺失的接口对于 DDS 分布式系统的功能和性能具有直接或间接的影响。重要的是，开发者文档可能并未明确指出这些接口功能的缺失，这种情况可能会对系统的稳定性和可靠性带来潜在风险。因此，用户在使用 DDS 时需要对这些潜在的缺陷保持警觉，并采取相应的预防措施。此外，用户应当积极参与开源社区讨论，关注产品的更新日志，以便及时了解和补充这些关键接口的功能，从而降低系统运行中的不确定性和风险。 表 1: 功能缺失问题示例 图3: 功能缺失问题的测试报告示例 2. 行为错误 当开发者根据官方文档调用特定 API 时，软件表现出的行为与文档描述不一致。这种不一致性可能表现为返回错误的结果、触发未预期的副作用或完全无响应。这种情况下，开发者不得不投入大量的时间去排查和定位问题。 表 2：API 行为错误示例 图4: 行为错误测试报告示例 3. 异常终止 此类问题指的是当应用程序在某些场景下调用特定接口时，DDS 中间件出现异常终止。这类问题的严重性在于其难以被发现、排查和修复。问题的隐蔽性在于异常通常只在特定的条件下触发，这些条件可能包括特定的数据模式、并发级别或资源使用情况，使得在常规测试中难以触发和识别。同时，即使问题被成功识别，修复工作也同样困难重重，这需要精确修改复杂的代码逻辑，还需要确保不会对 DDS 的其他功能造成负面影响。 由于 DDS 中间件作为系统的基础软件，其稳定性对整个系统的运行至关重要。同时，基础软件的不稳定性会对上层应用和最终用户产生连锁反应，极大地影响整个系统的质量和用户体验。因此，解决 DDS 中间件的异常终止问题，不仅是提升软件质量的技术挑战，也是确保系统整体稳定性和可靠性的重要一环。 表 3: DDS 软件异常终止问题示例 总结 经过本篇文章的介绍，相信读者已经对DDS的协议测试以及可能存在的问题有了大概的了解。 在敏捷开发模式下，软件需求不断增加，软件系统的规模和复杂度也在不断增长。然而，许多关键问题（尤其是性能问题）只有在软件达到一定规模和复杂度后才会暴露出来。一旦发现这些问题，修复的成本往往非常高昂，因为任何基础软件的改动可能会影响到整个系统，牵一发而动全身。 相比之下，如果在项目早期就能够模拟实际的应用场景，并对 DDS 进行全面的功能和性能测试，开发团队可以深入了解 DDS 的行为特点，甚至软件缺陷，识别性能瓶颈，从而及时调整设计，优化实现。这种“前置”的测试方法不仅能够显著降低后期的修复成本，能够提高整个系统的质量和可靠性，帮助系统应对未来的挑战。 本文介绍了南京臻融科技有限公司（以下简称“臻融科技”）开发的DDS协议测试工具。臻融科技在过去十年里，一直致力于DDS产品及其相关工具链的自主研发，并且在国内关键行业领域取得了最高的市场份额。这款DDS协议测试工具在DDS研发过程中已经历了近十年的不断迭代，证明了其产品的成熟性和可靠性。臻融科技与北汇信息的合作，旨在将这套工具引入汽车行业，以协助客户建立DDS测试能力，提供高品质的测试服务和相关培训，进而加快DDS在汽车行业的推广和应用。

目的：简单、实用的自组网协议栈，面向位置相对固定的路由节点。终端节点可以入网也可以不入网发送接收消息，以方便终端节点移动。较完善的网络管理功能。   功能： 业务功能用例： UC1 : 网关节点启动后，判断可用信道状态，选择合适的信道创建无线网络，成功后向网络提供以下服务( UC1.1 )： 响应入网请求（直接、间接），响应离网请求（直接、间接）； 响应路由节点更换父节点请求，响应终端节点更换父节点请求； 转发无线网络节点的消息给网关应用，转发网关应用的消息给无线网络节点； 在无线网络节点之间转发消息； 向网关应用提供以下服务( UC1.2 )： 获取无线网络拓扑结构； 获取无线网络节点的工作状态和网络配置参数； 修改无线网络节点的网络配置参数； 获取无线网络路由节点的通信性能参数； 在无线网络节点与网关应用之间转发消息； 节点首次入网确认； 将无线网络节点之间转发的消息转发给网关应用作为日志记录； UC2 : 路由节点首次接入网络，须通过网关应用确认，获取网络名称和可能使用的信道。然后根据网络名称申请加入网络，保存网络地址和父节点地址，在后续重启时可优先使用原来的配置加入网络，如果连接不上则重新申请加入网络。 路由节点更换网络需重新通过网关应用确认。 路由节点加入网络后，可以为其它网络节点（非网关）提供以下服务( UC2.1 )： 首次入网申请； 加入网络，脱离网络； 在子节点与网关应用之间转发消息； 子节点通信状态更新； 子节点被呼通知； 本节点状态定期通知； 广播来自网关应用的消息； 路由节点可以合并发往网关的消息，可以分拆来自网关的消息。 UC3 : 终端节点首次接入网络，须通过网关应用确认，获取网络名称和可能使用的信道。 终端节点可以在不加入网络的情况下（游离节点）( UC3.1 )，发送消息给网关应用，以及接收周边相同网络的节点广播的消息。 终端节点可以申请加入网络，作为网络拓扑中的一员( UC3.2 )： 终端节点可以休眠，在醒来后使用保存下来的父节点地址等网络配置发送消息； 终端节点可以申请更换父节点，可以申请离网； 入网的终端节点须定期向父节点报告状态； 终端节点在休眠醒来后可以向父节点查询是否有被呼通知（消息缓存业务由网关应用提供）；   UC1.2.1: 网关应用从网关节点获取无线网络拓扑结构 ~.1: 网关应用运行在嵌入式系统或电脑上，与网关节点通过RS232接口连接。 ~.2: 网关节点和路由节点保存子节点列表及地址空间表，网关应用可通过接口获取指定节点的子节点列表和地址空间表。子节点列表的数据应满足网关应用从中还原当前的无线网络拓扑结构。 ~.3: 当有节点加入网络、离开网络、更换父节点时，网关节点须通知网关应用，通知接口的参数应满足网关应用在不需要进一步查询的情况下更新当前的无线网络拓扑结构。 UC1.2.2: 网关应用获取无线网络节点的工作状态和网络配置参数 ~.1: 网关应用可通过接口从指定节点获取其工作状态，包括： 电源电量； I/O端口配置，I/O端口当前值； ~.2: 网关应用可通过接口从指定节点（网关节点和路由节点）获取其子节点的工作状态，包括： 联网状态：在线－－配置的时间段内有与父节点发生通信；离线； ~.3: 网关应用可通过接口从指定节点（网关节点和路由节点）获取其网络配置参数，包括： 节点名称，节点类型； 节点网络地址； （供子节点使用的）网络地址空间；（包含已使用的和未使用的）；由若干地址段组成，每个地址段有特定的配置参数，指定该地址段中允许的路由子节点、终端子节点数目； 当前频道，可选用频道列表； 定时状态上报周期； 父节点网络地址，父节点配置形式：固定、半固定、动态； 网络名称（仅网关节点）； 通信性能统计周期； ~.4: 网关应用可通过接口从指定节点（终端节点）获取其网络配置参数，包括： 节点名称，节点类型； 节点网络地址； 当前频道，可选用频道列表； 定时状态上报周期； 父节点网络地址，父节点配置形式：固定、半固定、动态； 通信性能统计周期； UC1.2.3: 网关应用修改无线网络节点的网络配置参数 ~.1: 网关应用可通过接口令指定节点修改其网络配置参数，包括： 节点名称； 可选用频道列表； 定时状态上报周期； 父节点配置形式：固定、半固定、动态； 通信性能统计周期； UC1.2.4: 网关应用获取无线网络路由节点的通信性能参数 ~.1: 网关应用可通过接口从指定节点获取其通信性能参数，包括： 发送消息数目，射频发送失败数目，因缓冲区满丢弃数目； 接收消息数目，其中CRC错误消息数目，因缓冲区满丢弃数目； 重启总次数；    

2011-12-27 记录 曾经有个同学在MSN上问我，为什么协议栈软件总是跑在ARM上，为什么物理层软件跑在DSP上呢？ 呵呵，好像从咱们开始做终端软件那天起，就是这样子设计的。为什么呢？ 我简单的回答了一下：因为软件的结构不同。 协议栈软件基本上都是基于状态机的，有很多层次结构，需要很多个不同优先级的task来运行。他的总体结构是需要一个RTOS来做调度的多个task可以通信，互相抢占式的。 物理层软件基本上是算法流程的，没有那么多的层次结构。重在算法本身的并行处理上面。DSP内核也是基于这些算法的特征来设计的。于是对于中断的响应上面往往比较差，甚至现在的vector engine的DSP就不响应中断。 于是，不同的芯片内核应不同的应用场景而生。而不同的软件结构就运行在了不同的芯片内核上而已。如此配合才可以做到系统的最优。 这位执着的同学继续问：那么协议栈能否直接跑在DSP上，这样不是节省一颗ARM吗？ 这个问题问得蛮好的。 那么咱们得看这整个系统的需求了。不同的系统需求是完全不一样的。协议栈有多少层次，有多少模块，多少状态要处理，整个软件结构会怎么划分，会有多大的代码量，需要多少运算量，会有怎样的抢占关系，实时性的要求是怎样的。 这是一个系统设计的问题，不能单纯的用一种通用的想法来约束系统设计。如果只是一个简单的协议。例如就是基于物理层做了一层协议，那么直接就做在一起，用一颗DSP就处理了有何尝不可。记得十年前刚刚工作的时候，我就设计了一个协议，用于SCDMA的基站与基站之间的一种透明的点到点的通信的协议，也就是直接跟声码器等软件跑在一颗DSP上。 而如果要谈到复杂的协议栈，如GSM/GPRS这样的，你一定要弄到一颗DSP上去做，那就是自讨苦吃了。当然如果是如C64X这么强悍的DSP，另当别论了。GSM、GPRS这样的协议栈，主要是逻辑关系太过于复杂，模块多，层次多。这样的软件跟物理层软件混在一起，会严重影响其实时性。而且代码量大，要放在带cache的系统上运行才是合适的。cache适合这种数据间有一定相关性，又不是剧烈相关的应用场景。如果剧烈相关，那么用sratch的memory可能更合适一点。 而如LTE这样的协议栈又是另外的话题了。首先数据面和控制面的需求就完全不同，最好时分在不同的core上。 细说起来，花很长。总之是需要根据具体的系统需求来做方案的，要考虑到关键点的细节，就好选择了。