在实时分布嵌入式应用平台上进行设计与调试

　　实时系统设计师和嵌入式软件开发工程师对独立的或者与嵌入式系统关联不大的设计、开发和调试工具与技术都非常熟悉。他们通常在设计阶段使用UML，在开发阶段使用IDE，在集成与调试阶段使用调试器和逻辑分析器(位于其它工具之中)。

　　过去相互连接的节点通常只有几个，且每个节点之间的功能划分非常明晰，但随着嵌入式系统之间互联的普遍化，如今常常是几十个甚至数百个节点都共同分担着一些逻辑应用功能。

　　事实上，随着实时系统与企业系统之间联系越来越紧密，这种分布式系统在操作系统和执行处理器方面的差异越来越显著。本文将讨论实时分布式系统开发方面的问题，并介绍开发平台和开发工具必须如何演进来应对上述新环境所带来的挑战。

　　开发平台的概念在嵌入式设计领域已经流行很久了，作为一个工具，它将应用开发环境与底层(通常是非常复杂的)实时硬件、协议栈以及设备驱动等分割开来。

　　就象操作系统(OS)提供独立系统开发平台的基础构建模块一样，实时中间件主要负责解决分布式系统开发中所面临的实时网络性能、可扩展性以及对不同处理器和操作系统提供支持等方面的挑战。

　　就象在标准实时操作系统的演变过程中发生的现象一样，为了支持目标环境(本文中为大型分布式系统中的实时程序)的开发、调试和维护，业界推出了许多新的工具。

　　分布式系统开发平台

　　从应用开发工程师的角度看，当逻辑应用跨越多个连网计算机时，应用开发平台必须能够提供如下三个基本功能：

　　1. 执行线程之间的通信

　　2. 事件同步

　　3. 受控延时和网络资源的高效使用

　　显然通讯和同步是分布式平台的服务要求，这与OS所提供的服务非常类似。但对于分布式应用来说，它们必须在不同操作系统和处理器构成的网络设施中透明运行，所有这些都暗示着要遵从一定的字节顺序和数据表示格式。

　　最好采用这样一种机制，它不要求开发人员清晰地了解消息或同步线程的接收对象所处的位置，以便从应用开发的角度将网络视作一个单一目标系统。

　　通常用户采用商用或自己开发的中间件来提供上述这些关键功能。有多种支持这种方法的中间件解决方案，例如Object Management Group (OMG)公司的JMS和DDS (数据分配业务)。

　　不过只有DDS(图1)这样的方案明确地解决了上述的第三点，即受控延时和 (目标)网络资源的高效使用，这在实时应用中是一个关键问题。DDS在提供消息和同步方面与JMS类似，但额外还采用了称为服务质量(QoS)的机制。

             图1：DDS框架可以提供受控延时和目标网络资源的高效使用。

　　QoS从应用层次上明确地定义了消息或同步请求的发送端和接收端之间所需的服务等级(优先级，性能，可靠性等)。

　　DDS在处理目标网络方面有点像状态机，它承认实时系统是数据驱动的，数据的到达、移动、转换和消耗将从根本上确定实时系统的操作。

　　某些数据是关键数据，需要在受控/固定的延迟时间内获取和处理，并且大多数要穿越网络。另外，有些数据需要持续一定的时间以便用于计算，而另一些数据需要可靠地提供，时间倒不是关键。QoS使得所有这些需求得以简化，并提供更多功能。

　　也许使用中间件的最大优点常常到应用开发过程的最后才看到，以丰富的中间件格式来定义接口将使得系统的集成、调试和维护变得非常容易。优异的中间件功能可以帮助你通过服务质量完整地定义数据交互，并形成应用“合约”。

　　例如，DDS不仅允许数据源规定数据类型，还允许规定数据以“一次性发送”还是以“重复发送直到”语义进行发送，迟到接收端的历史数据需要多大的存储空间，该数据源相对于其他数据源的优先级，数据的最低发送速率，以及更多的可能性。

　　通过明确地规定这些问题，延伸到集成阶段的许多问题都可以通过快速地实现承诺特性与要求特性之间的匹配来解决。DDS中间件甚至可以在合约不满足时即时产生告警。

　　分布式系统工具面临的挑战

　　直到拥有能够支持整个应用周期中应用环境的工具之前开发平台都不算完整。如果询问任何一个支持或维护工程师，他们都会说需要三样东西：好的文档，丰富的工具集以及尽可能容易地获取状态和事件参数的代码。

　　如果连网应用节点之间有清晰的接口定义语言可供使用，那么工作在一个单节点上的最新工具链在用尽内存、代码校正和性能时仍然是非常有用的，在某些情况下，还可以用于白盒子测试。

　　开发人员面临的新挑战是在集成阶段出现的各种问题的隔离、确认和更正，因为这时候单个分布式子部件是相互连接的，这些连网的子部件将首次作为大型集成应用而开始执行。

　　大多数工程师熟悉在单板环境里进行调试，都具备很强的“硬故障”解决能力，这些硬故障指的是引起进程停止或冲突的故障。

　　这类故障的调试相对比较容易，因为从冲突状态退出来基本可以正常工作，如果幸运的话，还可以在调试器中捕获故障，并且对这类故障的调试可以不受约束。

　　最难查找的硬故障通常是与多线程相关的故障，因此在采用更大更复杂的分布式系统时遇到越来越多这类故障也就不足为奇了；每个节点都有其自己的执行线程，这些线程可能对同一时刻来自分布式系统架构的相同数据进行操作。

　　分布式系统似乎也存在大量的软故障。在这些情况下，没有应用冲突，但告警指示灯却闪亮，且分布式应用执行不好或者根本不执行。

　　软故障的类型有许多，不过绝大多数都与多机器间数据产生和处理的同步有关。例如单个丢弃消息效应，如果该消息只是一个更新数据的样本，可能不会有什么大问题，但如果是一个转换事件或者命令，系统就会立刻进入无法预期的状态。

　　另外，这类故障可能出现很长时间后你才能检测到，这将导致可怕的调试恶梦。这只是软故障的一种，通常还会产生许多其它类型的软故障：比如：引起控制环路不稳定的长延迟(持续不变或周期性的)，自我增强(self-reinforcing)数据的丢失，不期望的中断应用，系统在实验室中工作良好但升级后出现故障，提供的和期望的数据不匹配等。

　　因此对于分布式系统来说，在不中断或者不显著减慢系统运行速度的条件下获得状态和事件信息非常重要。

　　分布式应用开发的新工具

　　让我们从基本的开始：首先需要的是能够产生可涵盖所有板子的公共数据类型以及使它们保持同步的进程的工具。如果使用中间件，你通常会使用元语言(IDL, XML, XDR)来书写你的数据类型，并自动生成处理数据类型的代码。

　　某些系统将允许你随时创建新的类型，不过你应该知道，这可能形成一个潜在的错误源，因为如果编程器不知道其中的细节，那么验证有关数据的使用合约是非常困难的。

　　另一个你所需要的工具应能帮助你设计应用程序，并规定数据和QoS要求。这类工具理想上应该用来设计尽可能多的应用程序，以便在设计阶段就能满足发送端和接收端之间的QoS合约(这比后面再进行调试和修复要容易得多)。

　　理想地，该工具应与你正常使用的设计方法相结合。例如，UML用户可能希望你考虑Sparx UML。该工具带有用于DDS这类中间件的接口描述组件，从而使得初次建立QoS变得更加容易。

　　一旦应用完成部署后，你需要确保通讯能如期进行，QoS参数设置正常，系统能够立即运行！在集成时你首先需要回答的问题之一是：“这些分布式应用功能间的通话是否正常？”

　　利用合适的中间件询问工具，比如RTI分析器，你就能确定中间件是否将两个应用程序联系到一起，也能确保这两个应用功能是否满足实际规范要求。

　　这样的工具还需要告诉你哪些对象正在交换数据，或许更重要的是，哪些不在交换数据，如果不在交换数据的话，分析不在交换数据的原因。当你有3个不同分包商(或者仅是自由开发商)，且每个分包商只负责分布式应用中的一部分，而你需要将它们集成到一起时，你将会真切地感谢这类工具。利用这些工具可以迅速精确并且没有异义地发现绝大部分配置问题的根本原因。

　　三种调试用例

　　尽管你的前端设计不错，也具备良好的通用接口，但仍然可能不工作。这时分布式系统的状态和事件分析就变得极其关键。通常调试过程中有三种用例：

　　用例1：监视整个分布式系统的健康状态。这种情况下，你可能想观察系统中大部分应用程序的高层行为。像SL Corporation公司的RTView这样的工具可以通过侦听中间件及具体应用程序释放出的数据，帮助用户构建一个或多个控制平面GUI或者数据报告视图。

　　选择性地构建应用中的关键变量，这可能是隔离系统问题并确保系统正常工作的最重要的第一步。当利用像DDS这类数据中心中间件实现时，诸如RTView等工具就可以在没有相关资源详细信息的情况下生成显示内容。

　　仅需要知道其存在和适用的格式(与数据元语言中定义的一样)，以及如何才能使数据可用(QoS)，就可以快速消化这种有用系统浏览显示器所需的信息。

　　通常使用这类工具的应用程序有许多不同的数据源，且大都具有较低的时间分辨率，因此需要将其组合起来显示，方可形成有意义的系统健康远景。

　　这类工具经常作为分布式系统中维护环境的一部分，并且同样包含易用的GUI构建器，因此可以产生面向最终用户的系统数据和健康显示。

　　用例2：深入了解故障应用程序。一旦利用系统健康分析工具确定出是哪一个节点存在问题，就需要从所选的一些应用程序以及网络上这些应用的交互情况中获得更详细的信息和更高的时间分辨率数据。像RTI Scope这样的工具就可以提供这类功能，它允许用户在没有预配置的情况下，以图形的方式实时地查看流入或流出应用程序的不同数据流。

　　用户可以将RTI Scope看作一台用来观测网络中任何一个应用程序的输出数据的示波器，它能利用负时间沿触发，具有多种绘图类型(与时间的关系，x与y的关系)，获取信号并能够存储以用于后续处理。RTI Scope仍然工作在规定的数据级别，不过其设计意图是以最少的介入方式捕获较少的数据源。

　　对于获取超出范围的数据或者说提供超出所需吞吐率或性能要求的数据来说，它是非常理想的。其底层中间件实现的丰富知识意味着它能够‘发现’数据的发送方和接收方，并通过网络与它们连接，从而通过中间件提取数据用于本地分析和可视化。

　　应例3：网络分析。有时候，中间件试图执行一些应用请求的服务，但底层网络实现自身的表现却不如预期。这个问题也许是路由器掉包，或无线中继所提供的带宽低于要求，或者某个节点周期性地断网一两秒钟，或者任何一个其他的问题所致。

　　更深入的分析

　　这时候你已没有选择，只有进行更深入的分析，才能了解到底发生了什么。协议分析器虽然可以提供你所需的所有UDP或其他包信息，但这没有任何意义，除非你能够将它们重新与应用程序关联到一起。

　　一个构建良好的分布式中间件应包含一个标准的有线协议，比如DDS就采用了开放标准的RTPS(实时数据的发布与订阅)协议。正如你所期望的那样，这样的平台能够监控有线流量并抽取相关的中间件数据包，并将数据包分拆用来与应用层相关。这里RTI也是有用的，它和专用协议分析器一起能够实时显示所有“线上活动”。

　　如上所述，在大型和复杂的网络上工作的实时应用开发需要一个创新性方案，该方案应能提供一个高效的工具策略来应对这类分布式环境所带来的多种挑战。如果没有这种连贯和综合的策略，无论是系统性能还是项目开发时间都将大打折扣。

　　对高效工具的基本需求主要表现在两个方面：一方面是能够定义和支持可覆盖不同操作系统、处理器和网络拓扑结构的一致性和可预测的实时环境；再就是能够为包含开发应用的分布式系统架构提供各种不同层次(设计，代码，集成，调试和维护)调试信息的全集成工具链。

　　Bob博士是Real-Time Innovations公司工程服务副总裁。他在2000年加入RTI公司，在控制系统和分布式网络技术方法拥有非常丰富的经验。他是复杂分布式应用的设计与调试专家，有两年时间在专门研究嵌入式和网络系统调试。他过去还做过客户培训、系统设计和集成调试等咨询工作。

        图2：利用IDL文件定义 “rtiddsgen”等数据类型工具可以生成能处理被定义数据类型的代码。扩展的“rtiddsgen”可以用来产生与CORBA兼容的数据类型。

        图3：RTI分析器是一个系统级调试工具，可以发现运行系统中的RTI数据分布服务对象，对其进行重组，并显示它们的通信参数。将该信息与你的系统设计相关联能够迅速找出性能和可靠性问题。

        图4：RTI分析器能显示DataReader与DataWriter 之间的“所有权”中的QoS失配。

        图5：RTView提供的虚拟仪器可以帮助用户查看关键的分布式数据。

        图6：RTI Scope能够利用一个类似示波器一样的显示器来图形化显示DDS Topic Data与时间的关系。

        图7：RTI协议分析器允许观测在线流量。