实时系统设计师和嵌入式软件开发工程师对独立的或者与嵌入式系统关联不大的设计、开发和调试工具与技术都非常熟悉。他们通常在设计阶段使用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中间件甚至可以在合约不满足时即时产生告警。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。