十多年来，汽车电子电气架构架构在不断升级的应用需求的推动下快速演进。从智能网联、自动驾驶、智能座舱，到软件定义汽车、OTA升级等新兴应用层出不穷，上层应用的创新必将催生电子电气架构的相应变革，后者是前者实现的重要基础。
回溯十多年前，当时典型的架构就是中央网关加上若干CAN节点的拓扑结构。后来随着域控制器、主干网络、集中式架构等概念的引入，区域控制器和高性能计算单元开始崭露头角。
为解决这一困境，后来引入了域控制器概念，将分散的ECU功能进行整合，实现集中管理和高效升级。更进一步，功能继续上移集中至中央高性能计算平台，从根本上解决了分散布局导致的迭代低效问题，有力支持软件快速迭代升级的需求。
功能上移的本质，是应用软件向上移动，而底层基础软件和硬件平台则可标准化，实现长周期维护。简单来说，这可以称为“软硬分离”，或“应用软件与基础软件/硬件平台分离”。
在这种软件快速迭代升级的大趋势下，应用软件对基础软硬件平台提出了新的需求。
首先是动态性需求。为实现快速开发新车型，有必要赋予基础平台一定的动态灵活性，这也是过去十年SOA架构飞速发展的原因之一。动态化的平台，就像搭乐高积木一样，可让OEM厂商快速为系统增加新的功能。
其次，更为重要的是实时性需求。这是汽车与消费电子的根本差别所在。作为交通工具，汽车的首要任务是确保驾驶员、乘客和行人的安全。要实现这一点，基础软硬件必须具备足够的实时响应能力、可靠性和确定性，才能有力承载关键应用。
那么DDS如何满足上述各方面需求呢？
DDS的关键特性
首先从通信模式的角度来看。很多人习惯将DDS与SOME/IP进行对比，但实际上两者遵循的是完全不同的通信模式，有不同的应用场景。
DDS是典型的发布订阅（Pub-Sub）通信模型，更像一种面向信号的通信方式。大家熟知的CAN总线实际上也是发布订阅模型，只不过DDS版的发布订阅要更加灵活。
而客户端服务器模型（Client-Server），又称SOA模型，则是在发布订阅模型基础上的进一步抽象。
在发布订阅模型中，发布者和订阅者交互的是独立的消息（Message）。但在SOA模型里，客户端和服务端交互的数据则赋予了新的语义，如请求消息、响应消息、事件消息等。
表面上SOA模型看似更高级，但实际上两种模式并无优劣之分，只是各有适用的场景。
而客户端服务器模型的限制则更多。首先要求数据流向明确，需有一中央节点，其他节点（客户端）只与该节点通信，客户端节点之间无直接交互。其次，通信模式是请求-响应式的，如数据库查询、文件服务等。再者，数据和计算资源均集中在服务端。
因此，SOA通信模型的适用场景是比较有限的。如果数据流不符合该模型，使用SOA反而会增加设计和开发的负担。事实上，近年一些OEM在第一代车载以太网量产后便急于追求整车SOA化，但开发效率未能显著提升，反而增加了不少成本。
1.DDS的以数据为中心
DDS的一个重要特性是“以数据为中心”。
过去在介绍SOA时，人们常说其一大特点是解耦。但解耦并非SOA的专利，DDS同样能够实现解耦。
大家可能会问，DDS中是否也存在一个中央节点，和SOA架构类似从逻辑上讲，确实存在一个虚拟的“全局数据空间”。但这并非SOA中的“服务器”概念，两者指向不同层次。DDS中的“服务”，仅指数据分发服务，属底层功能，负责数据发现、存储、发布等，不涉及业务逻辑；而SOA中的“服务”则指应用层的业务服务，如空调、音乐等。这是须明确区分的两个概念。另外，尽管DDS逻辑上有“全局数据空间”，但在物理实现上它仍是分布式的，并不存在真实的服务器节点，因此不存在单点故障和性能瓶颈隐患。
上图可以很好地解释DDS发布订阅双方的解耦关系。一开始整个系统处于空闲状态，发布端第一个“唤醒”，开始发布数据。此时网络中尚无接收者，但没关系，发布端只管把数据“丢给”DDS即可，随后自己进入休眠。等到有订阅端上线需要数据时，直接从DDS“拿走”所需数据即可，根本无需在意数据源头。这种“充分解耦”模式靠DDS的内置QoS（服务质量）实现，这能够使DDS的耦合程度比SOA更低。因为在SOA的请求-响应通信中，客户端和服务端必须同时在线，而DDS并不一定要求如此。
2.DDS的平台无关
DDS的另一大特性是平台无关性。这里的“平台”泛指操作系统、传输协议等底层依赖。DDS实现平台无关的方式是，尽量不依赖于平台的独有复杂功能，而将这些功能需求自己实现，然后通过统一的标准化接口对外提供服务。
因此，DDS的可移植性非常良好，只要有基本的UDP通信支持，就可以运行DDS。事实上，DDS与UDP被认为是最佳拍档，因为UDP最为简单，几乎没有QoS保证。而DDS则希望底层协议尽可能简单，因为诸如QoS等复杂功能需求，DDS自身已实现并对应用开放。
不过，DDS这种“自力更生”的做法，也带来了一个印象——在很多人眼里，DDS显得过于“重”、过于复杂，资源开销较大。笔者认为这是一种取舍：DDS一边提供了丰富特性、标准统一接口和平台无关性，作为代价，另一边就是较高的资源开销和软件复杂度。这是一种权衡，没有绝对的对错。
3.基于DDS实现的SOA架构SOA在现代车载分布式系统中扮演着至关重要的角色。SOA提供了一种灵活、可扩展的方法来设计和实现复杂的分布式系统，使得不同的服务能够独立开发、部署和维护，同时又能无缝地协同工作。
通过在DDS之上实现SOA，我们似乎可以结合DDS的数据中心特性和SOA的服务中心特性，既能够利用DDS的适用于大量实时数据分发的特性，又具备了SOA的灵活、可扩展，便于管理的优势。
前文提到DDS并非SOA架构，与SOME/IP等技术有所不同。但通过一定手段，DDS确实可以支持类SOA的通信模式。
虽然DDS可以大致模拟SOA，但仍有些特性缺失，比如真正意义上的服务发现功能。DDS虽然也有发现机制（SPDP/SEDP），但仅提供通信端点层面的发现，无法发现应用层业务服务。不过，DDS本身提供了良好扩展性，DDS-RPC框架使用者可自行开发所需的服务发现功能。
另一个限制是，一旦将DDS用于请求-响应模式的RPC通信，很多QoS特性将不再适用。
综合考虑，将DDS用作SOA通信框架或SOME/IP的替代方案时，我们需要全面权衡其优势与挑战。DDS与SOA的结合无疑能带来诸多优点，如高性能的实时数据分发与灵活的服务架构的融合。然而，这种整合也伴随着显著的成本和潜在缺陷：
技术实现方面，我们可能需要自行解决一系列额外的技术问题。
功能应用方面，这种使用方式可能会限制DDS原有的一些独特优势。
资源消耗方面，DDS较高的系统资源占用可能成为一个不容忽视的负担。
因此，在做出技术路线的选择之前，我们必须审慎评估其带来的收益是否足以抵消相应的成本和潜在风险。
DDS与TSN的融合
1.实时性是系统性问题
首先需要明确，实时性是一个系统性挑战，原因在于汽车电子电气系统本身就是一个错综复杂的大系统。尤其是在车载以太网进入汽车领域后，Linux、Android、QNX等复杂操作系统也开始大量应用，这使得确保整体实时性变得更加困难。
其中的根源在于，从应用程序、中间件、操作系统到硬件、网络，每个环节都存在一定的不确定性因素，而这些不确定性会沿着系统层层累积，越靠近应用层级别，不确定性就越高；而越接近硬件层级，不确定性就越低，最终各环节不确定性的累积导致整个系统的不确定性和实时性下降。
因此，解决分布式系统实时性问题是一个复杂的系统工程，我们不能寄希望于某一单一技术的应用就能全面解决。单靠某种中间件、操作系统或网络技术是远远不够的，需要从系统层面综合施策，通过架构、平台、中间件、操作系统等多维协同，才能够满足严格的实时性需求。
除了网络层面，大部分不确定性实际上来自于终端节点内部，而这部分无法依赖TSN来解决。由于终端内部的复杂性，很难有一个标准化的简单方案来全面解决内部实时性问题。
那么针对DDS，我们可以采取以下措施来提高实时性和确定性:
内存申请固化：减少不可预测的动态内存申请
通信关系固化：降低正常使用场景下通信关系的动态变化，减少节点动态进出
交互过程固化：减少DDS协议维护数据可靠性而产生的额外数据交换
总之，我们可以在一定程度上限制DDS的动态性特征，以换取更好的可预期性和实时性。这是一种权衡，需要根据具体场景需求来平衡动态性和实时性。
前面我们从全局角度分析了实时性问题，下面针对一些具体点做进一步探讨。
DDS的工作依赖于两种时钟
1.内部时钟-用于中间件内部的各种定时操作，如周期性发送SPDP消息、Heartbeat消息、Deadline控制等。
因此，缺少时钟同步系统时，我们只能放宽Deadline容忍度，比如正负500ms视为正常。而通过时钟同步技术，我们可以实现更精准的Deadline控制，例如1ms或更低。
另一需注意的是时钟跳跃问题。当DDS时钟配置为同步时钟源时，启动或其他情况下时钟可能会发生较大跳跃。无论是内部时钟还是外部时钟的跳跃，都可能导致DDS工作异常。所以在正常运行期间，时钟跳跃是应当尽量避免的。
时钟同步对实现精确的实时性控制非常重要，但也需规避时钟跳跃风险。在部署时钟同步方案时，务必权衡两者，审慎评估并制定相应的容错措施。
3.通过TSN改善DDS的传输延迟和优先级
在DDS中，有对应的QoS策略:
2.TRANSPORT_PRIORITY-同理，应用层可以指定不同数据流的传输优先级，但无法直接对底层传输层进行优先级调度。
需要注意的是，这些延迟和优先级的设置，实际上更多是应用层对底层传输的一种“建议”或“要求”。如何基于这些要求来动态调度网络资源、规划路径、设置队列等，需要在底层传输层有相应的机制来支持，DDS本身无法约束。
一种可行方案是在DDS下层部署一个TSN中间件，专门负责动态处理这些延迟和优先级需求。但这种机制也存在新的不确定性风险。当资源有限时，必定会有部分延迟、优先级需求无法满足，这将导致无法接受的实时性下降。因此，在决定是否采用这种机制时，我们需要全面评估其在车载场景下的适用性和合理性，谨慎权衡收益和潜在风险。
4.OMGDDS-TSN
说到DDS与TSN的融合，就不得不提接OMG发布的DDS-TSN规范，该规范定义了DDS与TSN的集成插件。目前该规范已经发布了Beta版本，有需要的读者可以在OMG官网免费下载。
DDS-TSN规范的目的是建立一个统一标准，使不同供应商在实现DDS与TSN集成时能够遵循相同规范，从而实现整个行业内产品和工具链的互操作性，有利于提高开发效率，降低成本。
OMGDDS-TSN规范约束了两个主要方面的内容:
第一是标准化了DDS-TSN系统的部署和配置流程。
第二是提出了两种具体的技术实现方案:
1.将RTPS消息映射到UDP/IP上，再通过TSN传输UDP数据包。这是一种相对容易实现的方式，因为只需将原有传统以太网改为TSN以太网，对系统修改较小。但缺点是数据需经UDP/IP协议栈再到TSN网络，实时性会受操作系统内核调度影响。
2.将RTPS直接映射到TSN网络的以太网帧上，绕过UDP/IP协议栈的影响。这种方式可有效提高实时性，但需对DDS实现做大量修改，研发工作量较大。
两种方案各有利弊，应根据具体场景的实时性需求和开发投入进行权衡选择。
针对DDS-TSN的系统级测试
在中间件测试领域，一个核心问题是如何有效地对中间件产生激励或触发测试。这一挑战源于中间件接口的特殊性。
黑盒测试通常需要仿真被测对象的输入并测量其输出。然而，中间件的接口多以软件形式存在，这与传统的ECU硬件在环（HIL）测试有显著差异。中间件测试面临的主要困难在于缺乏可直接进行激励或测量的物理外部接口。
为应对这一挑战，业界普遍采用的方法是在ECU内部嵌入专门的测试应用程序。例如，TC8中的UpperTester或ETS就属于此类应用。这些程序的作用是将中间件的软件接口以标准化的服务接口形式通过网络暴露出来，使外部测试系统能够访问中间件接口。
在DDS-TSN系统测试中，北汇信息沿用了这一思路，在系统内置入测试应用程序。需要注意的是，车载分布式系统通常具有较高的复杂性，可能包含多种网络节点配置：
1.简单的独立网络节点
2.复杂节点，内部包含多个通过板载交换机通信的子系统
3.支持多进程的高级操作系统节点，进程间通信采用基于共享内存的DDS
在测试系统层面，北汇信息通过私有协议对这些DDS测试程序进行控制和编排，以实现各种测试用例。这种架构实现了真正的“应用到应用”测试，能够全面反映整个系统的行为表现。
北汇信息不仅提供标准测试用例集，还支持用户根据系统的特殊场景定制开发新的测试用例。例如，用户可以设计一对多通信、多对一通信等模拟真实应用场景的测试。
为了实时监控时钟同步系统的运行状态，北汇信息采用了TSNCoreSolution工具，能够对网络中每个节点的1PPS（每秒脉冲）信号进行实时监测。通过这种方式，我们可以准确判断时钟同步系统是否正常工作，以及其误差是否满足系统要求。
在硬件方面，使用的核心工具是TSNBox。这是一个专门设计用于TSN系统仿真和分析的硬件系统。TSNBox具备丰富的接口支持，尤其是能够采集1PPS信号，这使得它成为时钟同步监测的理想设备。
与TSNBox配套的是上位机软件TSNTools。这款软件提供了强大的数据分析和可视化功能。通过TSNTools，我们能够：
1.实时处理从TSNBox采集的数据
2.进行深入的时钟同步性能分析
3.提供直观的可视化界面，便于工程师快速识别和解决同步问题
这套工具组合（TSNBox硬件+TSNTools软件）为我们提供了一个全面的TSN系统分析平台。它不仅能够监测时钟同步，还能对整个TSN网络的性能进行全方位的评估和优化。
通过对这些统一基准的数据进行分析，我们可以轻松地识别并量化系统中每个环节的具体延迟。这种精细化的延迟分析对于优化系统性能、满足严格的实时要求至关重要。
总结
北汇信息在车载网络通信和中间件测试领域拥有多年经验，已为众多整车厂和供应商提供过DDS、TSN等技术的咨询和测试服务，拥有成熟的解决方案和专业的技术团队，能够满足客户在软件定义汽车网络通信架构集成和测试验证等方面的各种需求，期待各位读者与我们进一步交流。