近年来，中间件技术和分布对象计算技术的结合在军事、航空、通讯、工业控制等领域得到了广泛的应用。中间件技术在分布式实时系统中的使用减少了硬件、操作系统、应用软件三者之间的相互依赖程度，提高了系统的互操作能力。目前主流的中间件产品有OMG CORBA、Sun J2EE、Microsoft DCOM等。OMG CORBA与J2EE、DCOM相比，不仅在事务处理、安全服务方面表现良好，而且它的跨语言能力和跨平台能力更是后者所不能比拟的。

目前，在实时中间件的研究上最为活跃的是华盛顿大学(Washington University)和加利福尼亚大学(University of California)Irvine分校，他们研发的TAO遵循CORBA^[1-2]标准，它是一个满足实时CORBA规范且支持对应用的静态QoS要求的高性能分布式中间件平台。其研究成果已成功地应用到了军事、航空、工业控制领域，取得了良好的军事和经济效果。

在国内，这方面的研究大致始于20世纪90年代，投入到中间件技术研究中的单位有国防科技大学、中科院软件所、东南大学等高校和科研院所，并取得了一定的成果。与此同时，分布式多媒体应用在网络带宽和CPU处理能力飞速提高的前提下，需要在网络上传输如多媒体音频、视频流等连续的、实时的数据。目前流行的多媒体实时传输系统包括Real Networks公司的RealVideo Player、 Microsoft公司的Vxtree。在开源软件领域更有Open Meetings，它是一个多语言可定制的视频会议和协作系统。它支持音频、视频，能查看每个与会者的桌面，还包含白板，通过白板可以导入各种格式的图片和涂鸦。Open H.323提供了全功能的、可交互的 ITU H.323的视频会议协议的开源C++实现。Ekiga是一个兼容SIP和H.323的视频会议程序，兼容VoIP，IP电话通过Ekiga，可以与使用任何SIP和H.323软硬件的远程用户进行视频和音频对话。

如果采用传统的分布式系统构建技术，需要针对不同的嵌入式系统和不同的网络环境编写特定的实现代码，使得编写的代码大量重复，开发成本过高，降低了系统的可靠性、可维护性和可扩展性，而且开发分布式系统面临跨平台、跨操作系统、跨语言、跨协议等许多问题。CORBA提供了一个公共的框架，它屏蔽了底层硬件平台、操作系统以及通信协议之间的异构性，在本地和远程对象之间使用统一的通信接口来为分布和异构计算机环境下开发应用程序服务。这样，分布式应用开发人员不需要关心和重复处理与平台相关的底层细节，可以将精力集中在具有实际功能的应用逻辑开发过程中，而且会大大降低系统的开发代价，缩短开发周期，使系统更易于维护和升级。

本文的主要目标是在分布式异构平台^[3-4]环境下，利用CORBA中间件^[5]技术实现一个多平台下的实时视屏数据传输系统。其中涉及视频传输技术、CORBA中间件技术在嵌入式和实时性操作系统方面的应用，对开源CORBA产品ACE+TAO的裁剪^[6]和移植等关键内容。同时，分析了实时视屏传输系统在多作战平台下实现视屏实时传输的主要功能需求，基于ACE/TAO设计，同时可实现一个分布式的视屏数据实时传输系统。

1 需求分析 1.1 功能需求分析

根据异构平台下嵌入式实时视屏数据传输系统的需求描述。该系统需要发布视屏、订阅视屏、查询视屏、开始接收视屏、暂停视屏、退订视屏、获取视屏、获取系统日志等基本功能，参与者是视屏采集端、视屏订阅端、系统管理员。该系统的用例图如图 1所示。系统有3个参与者，分别是视屏发送端、管理员、视屏接收端。发送端首先向系统注册，注册成功之后开始发布视屏，首先修改全局的视屏发布订阅数据中心，然后通过数据传输系统传输数据。视屏数据的采集设备可以是采集卡、usb 摄像图、桌面录制工具等。视屏接收端首先向系统进行注册，然后通过查询视屏列表订阅相应的视屏，订阅成功之后通过视屏传输模块接收相应的视屏数据，实时播放，在接收视屏之后可以进行暂停视屏和取消订阅操作。系统管理员可以查询系统状态，管理视屏发布端和接收端的注册任务，设置视屏接收端能接收到的视屏权限。

1.2 性能需求分析

本系统主要解决分布式视屏数据的实时传输，所以在性能方面主要考虑以下几个方面：

(1) FPS(Frames PerSecond)帧速率：每秒钟传输画面帧的个数，如果每秒能传输的帧数太低，就会影响整个视屏传输的效果。同时FPS越高，视屏画面延迟越低。

(2) 压缩率：由于原始视屏数据量巨大^[7-9]，所以在视屏传输系统中传输的数据都是经过视屏压缩技术压缩过的。压缩率越高，占用的带宽就越低。

(3) 图像分辨率：视频都是由一张张的图像连续播放构成的，图像又是由一个个连续的像素点组合而成的。图像分辨率越高，占用的存储空间就越大。在固定的压缩率下，图像分辨率越大，占用的带宽就越高。

(4) 带宽：网络每秒能传输的数据量。由于物理带宽是固定的，不能改变。当系统的最低带宽需求高于物理带宽的时候，系统就不能在该网络情况下运行，导致看到的画面质量下降。

1.3 数据分析

根据嵌入式实时视屏数据传输系统的业务需求，该系统的数据流是从视屏采集端发送给传输系统的，传输系统根据视屏接收端的订阅情况，进行视屏数据流的分发、传递。数据流程图如图 2所示。视屏发送端、视屏接收端都可以通过用户ID进行系统的注册和注销。注册和注销功能通过修改系统数据记录进行注册注销。管理员可以通过查询命令查询系统运行状况，并且通过权限控制命令控制各个视屏订阅端和发布端的系统权限。视屏发布端通过输入发布命令发布视屏数据，视屏数据经过压缩、组包之后存储在视屏数据缓冲区，视屏分发器根据注册、视屏发布、视屏订阅、权限这些控制信息进行数据包的分发，接收端接收数据包，进行视屏解压，实时显示。同时接收端可以发送订阅命令，以便进行视屏订阅。

1.4 系统结构分析

集群作战平台上的各种系统几乎都连接在本地的网络中，这样系统之间可以进行交互协作，并且管理人员可以方便地通过网络向各个系统发送命令。同样，如果开发的实时视屏传输系统能够利用本地网络来实现数据传输功能，这样就能以统一的方式，实现对各种桌面系统和嵌入式系统上的多媒体信息进行传输和控制。

在实时视屏传输数据链路中，主要包括前端信息采集和后端接收显示。如果后端节点需要接收同一前端节点的视屏数据，并且后端节点能够实时控制视屏数据的传输方式和传输速率，那么，在前端节点就需要维护对多个节点的连接，并且需要将一份数据转发多次。由于分布在网络中的计算机硬件系统和软件平台种类繁多，前端和后端节点往往都需要保持瘦客户机^[10]模式。

基于以上原因，本文提出了一种发送、转发、接收的通信框架结构，如图 2所示。客户端主要负责对视频信息的采集和监控，服务器负责维护与多个客户端的连接，并完成对节点的管理和数据的存储转发。基于该框架耦合了视屏发送端和视屏接收端，发送端不需要知道接收端的存在，接收端也不需要知道发送端是谁，并且可以灵活地在各个数据传输通道上使用不同的传输协议，实现传输协议的可插拔。可以在视屏发送端和视屏接收端使用不同的网络模型和编程模型，并且在转发服务器端可以实现权限控制、流量控制、转发策略控制等控制功能。在视屏的发送端和接收端系统平台都不变的情况下，服务器端可以选择具有强实时性的VxWorks^[11-12]系统作为服务器端，使整个系统具有更高的横向扩展功能和实时性。

2 系统设计

首先给出系统的总体设计，根据系统要求进行分层设计，最后给出各层具体模块的详细设计。按照前面提出的功能需求和性能需求，实时数据传输系统应该能够不依赖于具体的操作系统和网络传输协议。根据视屏接收端的订阅情况实现视屏数据的实时采集、分发、显示等。在视屏接收端能够进行查询、订阅、播放、暂停视屏功能。系统管理员可以在线查阅系统运行情况和设置系统权限。基于以上需求，该系统设计如图 2所示。

系统采用分层设计，分为操作系统层、中间件层、基础设施层、表现层等。

(1) 操作系统层：整个系统运行在操作系统层之上；

(2) 中间件层：该层使用底层操作系统的具体实现，屏蔽底层多个操作系统的差异，选用开源CORBA 产品TAO 作为基础中间件，CORBA A/V 服务实现流式数据服务，CORBA Nameing Service 服务实现节点管理；

(3) 基础设施层：包括流管理、实时数据分发、实时数据处理模块、节点管理等；

(4) 表现层：实现视屏发布用户需要的发布视屏，视屏接收端需要的查询、订阅、开始、暂停视屏功能，管理员需要的查询系统运行状况、权限设置功能。

上述模块首先根据功能进行层次划分，利用ACE+TAO 作为底层的中间件层提供给上层的基础设施层基本的CORBA服务、ACE封装过的底层操作系统统一API、CORBA A/V 服务和CORBA Nameing Service 服务。在中间件层之上设计实时视屏数据传输系统的基础设施层，该层由于构建在中间件层之上，保证了该层的平台独立性。在基础设施之上实现业务层，该层主要解决需求分析中提到的各种业务功能。该分层设计方案提高了系统的可移植性，用中间件层保证系统能够在多个操作系统下运行。^[7]把系统的复杂性进行分层，使得复杂逻辑在基础设施层实现。业务层主要关注具体的业务流程，利于业务层面的需求变更。

3 系统实现 3.1 系统运行环境

实时视屏传输系统运行的目标系统包括Windows、Linux、VxWorks操作系统等。Windows操作系统作为当今使用最为广泛的操作系统，其强大友好的图形界面极大地方便了用户的操作。将Windows系统用作发送端进行数据采集，以减少对硬件采集设备的驱动开发。VxWorks系统对图形界面的支持虽然还不够友好、操作不够方便，但是其具有实时性、稳定性等特点，所以用在转发端作为核心服务器。接收端采用Windows和Linux操作系统。

根据以上运行环境分析，系统需要实现嵌入式系统与普通桌面系统之间的分布式协作，所以，需要选择合适的CORBA中间件产品。ACE+TAO是一个应用广泛的、开源的CORBA中间件，并且基本按照OMG提供的CORBA 2.6规范来实现。它提供了对多种平台的支持(包括Window、Linux和VxWorks操作系统)。由于ACE+TAO的源码开放，能减少其在嵌入式系统中内存的占用，使得用户可以根据系统需求来裁剪^[9]出和优化自己需要的CORBA产品。

3.1.1. ACE+TAO针对各个嵌入式平台的定制化裁剪

在嵌入式系统中，存储资源是非常有限的。要求基于嵌入式系统开发的程序尽量占用较小的内存和较小的程序本身的存储空间。较小的内存占用可以对程序进行优化，但是较小的程序存储空间占用，一直是个难点。基于以上原因，设计了一个针对ACE+TAO 动态库裁剪的程序，使用该程序可以对ACE+TAO进行裁剪，裁剪的粒度达到.cpp 级别，也就是说如果应用程序里面使用了.cpp文件里面的函数，就编译该.cpp文件对应的.o 文件到库文件里面。

这个工具的目的是优化基于ACE+TAO开发的多个应用程序的动态链接库的存储空间占用。现有的解决方案是，基于静态链接的程序，程序只连接需要的对象文件模块，但是多个程序的静态链接会造成对象文件的冗余。动态链接的程序，多个程序共享地使用一个完整的库文件，需要安装整个动态链接库。针对一个特殊的应用程序，该应用程序并不是把该动态库里面所有的对象文件都使用了。该程序只是需要一个对象文件的子集。具体裁剪原理如图 3所示。

3.1.2. TAO在多平台上编译安装

TAO支持多种平台，如Windows、Unix、Linux、VxWorks、LynxOS等。本文所述的系统需要运行在多个平台之上，包括Window、Linux、VxWorks操作系统。在这些操作系统上编译和安装ACE+TAO时，方法各不相同而且配置烦琐，因此，需根据具体的应用需要修改相应的宏和选项。

3.2 系统IDL接口定义

该系统使用CORBA A/V Stream 服务作为底层的数据传输和控制功能，但是A/V 服务提供的控制功能不能满足所有功能，一部分功能需要用标准的CORBA IDL 接口定义实现。IDL接口是客户通过其发送请求对象中所定义的一系列操作的描述。接口阐明了由支持接口的对象所提供的服务是如何通过这组操作被访问的语法描述。其中，A/V 服务接口存在A、B两种截然不同的端类型IDL接口。接口定义已在OMG A/V stream规范中表述，这里不需要再对此进行设计。只需要在应用层调用接口中定义一个MediaCtrl接口，调用流式服务来完成对流的控制。每个模块接口中定义的操作对应一个CORBA对象请求调用的操作。客户端和服务器端通过这些操作相互通信。

3.3 命名服务实现

服务器端需要解决客户端获得对象引用这个问题，而让客户端获取对象引用的过程包括3个步骤：

第一步，服务器端提供要公布的对象给对象目录，并以一些有意义的方式来提供要识别的对象属性；

第二步，客户端将需要的对象属性提交给对象目录，目录将匹配的对象返回给客户端；

第三步，客户端使用获得的对象引用，服务器端完成相应的操作。

在本系统中主要用CORBA命名服务实现对象的定位。服务器端将伺服对象注册到命名服务器上，客户程序可以通过命名服务器上提供的对象名称将其解析成对象引用，然后客户端发送请求到服务器，服务器处理请求并返回结果给客户端程序。命名服务实现原理如图 4所示。

在系统启动前，需要先开启命名服务。命名服务程序可以分布在局域网内的任何计算机，但是其IP地址和端口号需要对引用命名服务的程序公开。

启动命名服务的方式：打开一个控制台窗口，键入-m1。

参数说明：

-m1采用multicast(多播)方式，这样启动服务器程序的时候就不用再指定主机的IP地址了。

-ORBEndPoint iiop://192.168.0 .100 :8000:采用IIOP通信协议，并指定启动命名服务主机的IP地址和端口号。

3.4 服务器启动

服务器端需首先启动，这样才能将伺服对象绑定到命名服务上，客户端通过corbaloc获取服务对象引用。

根据节点管理模块的设计，每一个节点控制类对象中都包含了一个连接器对象CConnetor，而CConnector对象中包含了一个服务器对象的对象引用。因此，在注册节点之前，需初始化与服务器的CORBA连接，这包括ORB的初始化以及服务器对象引用的获取。初始化代码处于CConnector的Login接口中。

首先开启一个后台任务运行naming 程序，VxWorks 5.5下开启naming服务,该程序监听的网卡是VxWorks本机的网卡。然后分别开启任务server和client，并指定了命名服务开启的地址。

4 系统测试 4.1 测试环境

测试环境包括6台PC机、100 M网卡、1个摄像头、1个视频采集卡。其中，发送端上装有摄像头和视频采集卡，运行在Windows XP系统上。转发服务器端运行在VxWorks系统上。4台接收端计算机有2台运行在Windows XP上，2台运行在linux Red Hat 9.0上。客户端和服务器端通过一个局域的以太网相互连接起来，构成了一个网络环境。

4.2 功能测试

由于本系统涉及客户端和服务器端之间的通信，所以在测试过程中需要先启动服务器端上的程序，然后启动客户端上的程序，并对每一个系统功能通过客户端的相应调用操作进行测试，这样不但测试了客户端相应模块的准确性和对异常的处理，也测试了各个功能模块在服务器端的操作实现。在整个测试过程中，主要是采用黑盒测试方法，调用过程是否正确可根据调用返回值是否符合预期值、操作功能实现是否正确进行判断。分别对节点管理、流管理进行了测试，测试过程符合期望值。

4.3 性能分析

在系统通信链路上，分别接入1台接收端、2台接收端、3台接收端和4台接收端。这里只给出2台和4台接收端的情况测试,通过对以上传输速率方面的研究，选取分辨率为352 pixel×288 pixel进行比较，当一个数据包的大小是1 500字节时，传输速率大约在1 Mbps左右。当一个数据包的大小是3 050字节时，传输速率大约为1.5 Mbps。这是缓存的利用率提高所导致的。通过对实验数据分析可以看到，总的传输率随着连接的接收端数量增多而变大。这是由于当传输的总和不超过网络最大传输率时，网络带宽的利用率提高了。多个接收端之间的传输速率不同，与客户端操作系统有关。在实时性方面，在连接4台接收端服务器的时候，依然能保证100 ms左右的延迟，符合系统所提出的120 ms 延迟。关于图像质量方面，当前视频压缩标准选择MPEG-4压缩算法，视频帧由I帧、P帧和B帧组成。

5 结语

实时视屏传输系统是基于CORBA技术实现的，和传统方式开发的分布式系统相比，系统中各个应用对象之间的互操作更加透明，有效地实现了系统所需的各种传输和远程服务功能，方便系统的升级和维护，极大地提高了系统开发效率。同时，由于对开源的CORBA产品TAO进行了裁剪，保证了系统的嵌入式应用特性，数据分发服务器使用了实时操作系统VxWorks和实时CORBA的结合，使得系统的实时性得到很大的提高。当前实现的系统转发服务器端不能主动通知各个节点相应的系统管理信息。接收端只能通过每次调用查询节点信息来获取服务器所管理的节点信息。由于音视频的采集使用不同的设备，并且采集频率不相同，所以还需要解决音视频数据的同步问题。