饶 冬，孙甲琦，贾林巧，董伟升

（北京遥测技术研究所 北京 100094）

引言

信息化在带来方便快捷的同时也带来了信息安全隐患。2013年美国“斯诺登事件”暴露了存在于全球的重大信息安全隐患，信息安全已经威胁到各国的国防安全。操作系统作为当前信息设备最基础最重要的一部分，是保障信息安全的重要一环。现在绝大多数航天测控设备使用Windows操作系统。Windows操作系统由外企研发，代码封闭，多次被曝光存在“后门”，设备信息易被窃取，这些都给使用Windows操作系统的航天设备带来重大安全隐患。

Linux操作系统是一款内核代码开源的操作系统，可以完全消除内核中植入“后门”的安全隐患。而且Linux内核由全球Linux爱好者维护，更新速度快，漏洞少，大大降低了不法分子非法窃取信息的几率。这款安全性高于Windows的操作系统正是当前航天系统所需要的。

当前航天事业发展速度越来越快，任务越来越繁重，航天测控系统向多设备、多型号、多频段发展，对测控软件的安全性、实时性、可靠性和重用性提出越来越高的要求。传统的面向过程的结构化软件设计思想难以满足航天测控系统软件的可重用、易扩展和易升级的要求，针对该问题，很多文献提出了相应的解决办法。徐冰霖等提出运用面向服务的思想来设计航天测控软件［1］，李晓伟等提出将设计模式思想应用到航天测控软件架构设计中［2］，郭力兵等、赵海原等和周锦标等提出将构件化和组件化思想应用到航天测控软件架构设计中［3～6］，徐广柱等提出结合Rational“4+1”视图法［7］和面向对象思想来设计航天测控软件架构［8］。以上这些方法都是面向对象思想的扩展，本文同样以面向对象为基础，结合构件思想和模式思想，从多个方面完成适合Linux系统的测控软件架构设计，加快航天测控设备从Windows操作系统向Linux操作系统的迁移。

1 设计地面测控软件架构的必要性

地面测控软件是航天地面站测控系统的重要组成部分，它承担着各类实时测量数据的收集和处理、各种航天器运行轨道和姿态的监控与确定、各个测控站之间的数据信息交换以及测控数据的事后分析与处理等一系列任务。再加上测控系统设备研制单位多、软硬件接口复杂、需求变动多等现况，传统的面向过程的软件设计思想已很难满足当前测控软件的需求。其原因是，面向过程的软件设计思想是一种自顶向下的设计思路，软件结构是一棵任务不断细分细化的枝节繁多的函数树，一切功能的实现都依赖底层函数，导致结构扩展性太差，一旦需求发生变化，底层函数发生变动，依赖于这些底层函数的功能都会受到影响，将造成大量繁琐的改动，严重降低了软件开发的效率和可维护性。

面向对象的设计思路与面向过程的相反，它是一种自下而上的设计思想，从设计单独的类开始，通过类的扩展来实现所有的功能。类的封装性强，类与类之间耦合度低，这极大程度地避免了面向过程“牵一发而动全身”的缺点。面向对象的集成与模板特性大大提高了软件的重用性，其多态性增强了软件开发的扩展性。

面向构件的设计思想是面向对象设计思想的扩展。构件是具有一定集成度并可以重复利用的软件组成单元，相比于对象，构件具有更大的粒度、更强的独立性和更好的重用性。

航天地面站测控软件经过几十年的发展，在各个方面都形成了比较成熟的产品，其中很多软件模块、函数库、文档等都已得到不同程度的重用，大大避免了重复开发，提高了软件开发效率，缩短了开发周期。但这还不够，测控软件作为一个专业性很强的应用方向，其功能是相对比较集中的。设计一款专门针对测控软件的架构，既能满足这种专业性的需求，又能达到架构层次和设计层次的重用，形成测控软件从架构重用到代码级重用的全阶段重用，促进测控软件开发效率的进一步提升。

地面测控系统设备多、功能多、接口多，其软件架构也必然是功能多样、接口统一又兼容硬件差异，同时具有通用性强、耦合度低和扩展性强等特点。测控软件架构设计的优劣，直接影响着测控应用软件的开发，如果一开始设计的架构出现问题，以后基于此架构开发的应用软件也必然受到影响，所以架构设计必须经过细致、周全的考虑。

2 地面测控软件架构设计

本文从三个方面来完成测控软件架构设计，分别是分层设计视图、功能交互视图以及数据流导向视图。

2.1 架构分层视图

分层设计是软件架构设计里最常用的方法，分层视图使得软件总体架构层次分明，结构清晰。清晰的层次架构为后续软件模块的划分、功能的实现和代码的编写提供了有力的依据。测控软件的分层设计视图示于图1。

图1 地面测控软件架构分层视图Fig.1 The layered view of space station TT&C software architecture

图1是航天测控软件的服务框架和平台架构的分层视图，在该框架的基础上，测控应用软件可以方便地运用框架提供的接口和服务，框架除了为应用程序提供接口和服务外，还管理着应用程序的类、对象、参数等。尽管测控软件功能复杂繁多，方向丰富多变，接口更新频繁，很难形成长期统一可用的模块，但是经过多年的实践和经验积累，我们总结出了一些规律，即一些功能模块在测控软件中经常用到，而且功能相对单一，通用性和适应性很强。如通信管理模块，其主要功能包括通信链路的创建、数据的发送和接收以及通信链路的状态监控等，这些功能和其他模块之间都是高度松耦合的；再如日志管理模块，其主要功能是定义日志格式、记录日志和读写日志文件，这些功能同样常用且与其他模块耦合度低。如果将这些常用功能模块写成统一的软件构件，当某应用软件用到这些模块时可以直接调用构件接口来实现相应功能。如数据收发软件可以直接调用通信管理模块的通信通道创建接口和数据发送接口来实现数据发送功能，这样既方便使用又能保证扩展性，在提高开发效率的同时，保证了代码质量。图1的框架架构正是基于这一目的完成的。

层次架构分为上中下三层，分别是硬件层、功能处理层和界面层。硬件层主要是硬件板卡的驱动程序。这些驱动程序种类繁多，对外提供的接口也各不相同，于是本文设计出一个硬件访问接口——硬件访问管理模块，将底层的驱动程序API统一起来管理，并为上层提供统一的接口。有了硬件访问管理模块，当驱动发生变动或更新时，无需更改上层的调用程序，只要变动驱动程序与硬件访问管理之间的衔接即可。这无疑减小了修改代码的工作量和复杂度，这样的松耦合设计也正是分层结构的最大优势。

功能处理层是整个架构的核心，平台的几乎所有功能都将在这里进行处理。向下它通过硬件访问管理来调用驱动API为本层服务，向上它为界面程序提供服务。从图1可以看出，这些功能包含了测控软件最基本最常用的功能，如参数宏设置、公共信息管理、通信功能、配置管理等，而用户管理、日志管理和帮助功能更具一般性，这些功能模块都做成了构件，具有很强的通用性。

最上层是界面层，界面是人机交互最直接的部分，它的方便易用及简洁美观极大地提高了用户体验。界面的数据来源及控制都由下层的功能处理来完成。

2.2 架构功能交互视图

众所周知，软件管理的资源主要有硬件和数据两种，在本文的测控软件架构中，我们又将数据细分为参数数据和普通数据。图2是地面测控软件架构功能交互视图。中间部分为对象管理，管理着测控软件中的所有类，这些类可归纳为设备类、数据类和参数类三种。这三个资源类之间可以通过消息传递进行信息交互，当然它们与对象管理之间也存在着信息交互。这三个资源类同时对外提供丰富的接口（图2中的菱形），通过调用这些接口，来管理这些资源，实现丰富的功能。

图2 地面测控软件架构功能交互视图Fig.2 The function interaction view of space station TT&C software architecture

设备包括基带设备、终端单机设备、伺服设备等，设备类管理着这些硬件设备，提供相关驱动函数接口，具有设备间的切换功能和相关配置功能，同时还对外提供相关参数，供其他类来监控其状态。

数据包括遥测数据、命令数据等，对于这些专业性很强的数据，除了要提供一般数据所需的简单接口，如收发功能、存储功能和显示功能外，还要提供专业的处理功能，而这些专业处理功能大多比较复杂，如遥测数据的解调、解码、相关转换和计算等。

这里的参数主要以宏的形式体现，包括参数宏、任务宏、配置宏等，这类宏信息通过XML文件来管理。测控软件中参数众多，更改更新频繁，且参数过于复杂，而XML文件正好具有结构清晰、通用性强、易读写和易管理等特点，因此它广泛用于结构化数据的存储和管理。参数类提供宏编辑、宏调用等多种宏管理手段。

2.3 数据流导向视图

地面测控系统的数据流主要包括遥测数据和遥控指令。遥测数据从弹、箭、星流向基带设备再到测控中心，遥控指令则刚好相反，是从测控中心流向基带设备再到弹、箭、星及各种航天器。

图3是地面测控软件架构的数据流导向视图。现在基带设备的功能越来越强大，足以处理所有经过终端单机设备的遥测遥控数据。对于遥测数据，基带设备采集到数据后，进入数据缓冲区域，如果对数据没有实时性要求，则由数据存储程序将遥测数据存入磁盘等介质，以便对数据进行事后处理；如果对数据的实时性要求高，需要实时处理，则将遥测数据交由实时数据处理程序处理，并实时显示；如果要求实时转发数据，则将遥测数据直接实时转发至网络，最后发送到测控中心。对于遥控指令，测控中心形成的指令通过网络发给基带设备，基带设备接收到指令数据后，交由处理程序加工，然后由基带设备发送到各航天器。

图3 地面测控软件架构数据流导向视图Fig.3 The data stream guiding view of space station TT&C software architecture

数据流视图从另一个截面反映了架构的复杂性及可能出现的诸多问题，如多个基带设备采集多个航天器的多个数据，并且向多个测控中心转发，如何保证软件的通用性和数据流的准确性；对于需要实时处理的数据，如何保证边处理边实时转发的要求；对于实时数据和非实时数据，如何合理分配资源，在保证质量的同时避免资源浪费。如此诸多细节问题都是架构设计过程中需要考虑并解决掉的。

3 架构设计中的关键技术

3.1 跨平台技术

随着Linux操作系统在测控设备中的推广应用，今后设备的开发及应用环境将是Windows与Linux的交互使用，而测控系统软件的跨平台应用将显得尤为重要。尽管Linux和Windows在设计上存在巨大的差异，但在一些通用协议上它们是一致的，如网络协议。本文架构的实现采用功能强大的C++编程语言，Linux和Windows两个系统的编译工具对C++语言的支持程度很高，可用的函数库也很丰富，但这些函数库和编译工具不具备跨越操作系统的特性。最终，我们采用Qt函数库，它可以在不同操作系统上将C++语言编译成适合该系统的二进制代码，从而实现流畅的跨平台功能，解决了操作系统间的异构问题，大大提高了开发效率。

3.2 系统功能的集成和交互

软件架构的设计关注软件系统的组成及组成元素之间的交互，系统功能的集成和交互是架构的基本功能。在Linux系统上，我们把地面站测控系统软件模块编译成动态共享库，采用这种动态执行方式可使软件达到文件级的动态无缝集成。各个模块构件之间形成了粗粒度的松耦合交互，构件内部的实现对外是不可见的，仅需要提供对外接口就能实现相应功能。同时，软件构件的开发是独立的，保证了软件团队协作开发的效率，具有重要的现实意义。对于系统功能之间的交互，我们采用在对象之间进行消息传递的方式实现。

3.3 消息传递

功能对象之间通过消息进行交互，一种方式是通过函数（或接口）的调用向被调用者传递消息，但是当增加一个需要接收这个消息的对象时，调用者并不知道新增加的对象需要接收消息，因而未能传递消息。此时可以采用广播机制，即一旦有消息要发送，则调用所有功能模块发送消息。这就带来了性能问题，有的模块没有判断是否是自己的消息也进行了处理，导致不可预料的错误或异常。最合理的处理方法是，一方面发送者和接收者都不需要知道对方，另一方面接收者收到的正好是自己要收到的信息。本文采用“注册-接收”的方式，消息接收者向发送者注册，说明自己想要接收的消息类型，这样在每个发送者那里就会形成一个接收者列表；当发送者向外发送消息时，先在接收者列表里找到需要接收该消息的接收者，然后直接将消息发给该接收者。这种方式避免了广播机制带来的性能问题，是目前最适合本架构的消息传递机制。

3.4 数据共享

在测控系统中，数据的接收解调是一项重要功能，解调后的数据将用于实时显示、存储、测试、对外传输等处理，这就要求数据能够共享。数据共享既需要有足够的缓存以保证处理功能能够完成对数据的处理，又要具有较高的实时性。与消息传递类似，数据共享可以分为被动提供和主动传递两种方式，被动提供采用“生产者-消费者”模式，生产者负责将数据放入缓冲区，消费者从数据缓冲区读取数据，而主动传递方式则是由数据的产生者直接将数据发送给接收者处理，以满足实时性要求。

4 软件架构的实现

本文设计的软件架构在CentOS操作系统（一种Linux发行版操作系统）上实现，集成开发环境是Qt Creator，图形开发库是Qt，实现过程如图4所示。

图4 软件架构实现Fig.4 Software architecture implementation view

首先根据设计文档实现架构的模板，模板主要包含了定义各个模块接口类虚函数的头文件。以通信管理模块的接口类虚函数为例，模板头文件里函数定义如下（只列出两个）:

//名称:取通道对象

定义:int GetChannel（uchar szChannelID［］，ICommunication-Channel*pChannel）

//名称:发送数据

定义:int SendDataToChannel（uchar szChannelID［］，uchar aData［］，int iDataLen）

整个头文件包含了十多个接口类，上百个接口类虚函数，这些虚函数都将在各模块实现类里实现。

接着是架构主程序和各模块的实现，它们都以架构模板为基础，各模块主要实现模板中接口类的虚函数，完成特定的功能。主程序同样以模板为基础，首先是初始化工作，然后加载各个模块的信息，建立相关模块接口类对象，调用模块接口类函数，以完成主程序的服务功能。如建立参数宏模块的接口类对象，调用该接口类的参数读取函数，即可从XML配置文件中读取相关配置信息，接着再建立界面管理模块的接口类对象，调用其界面显示函数来显示这些配置信息。主程序运行流程如图5所示。

图5 主程序运行Fig.5 Main software running view

最后，航天地面站测控软件应用程序的实现同样是基于架构模板的，同时调用主程序提供的服务和模块提供的接口函数。应用程序开发人员只要熟悉了各模块的接口函数，即可简单方便地调用相应函数，快速完成开发任务，这将极大地提高软件开发效率。

5 结束语

本文以面向对象思想为基础，从三个方面对航天地面站测控软件架构进行分析，阐述了架构设计过程中的关键技术。该架构的服务框架和平台已经在Linux操作系统上得以实现，部分应用程序也在该架构的基础上实现。实践证明，该架构确实有利于提高软件的开发效率，对于全面提高整个测控软件的可重用性、安全性、可靠性和可维护性具有极大的促进作用。后续还将完成架构的具体性能测试及进一步的改进工作，如有可能，还将尝试移植架构到嵌入式平台，这些工作都具有重要的现实意义。

［1］徐冰霖，李战怀.面向服务的航天测控软件架构设计［J］.飞行器测控学报，2012，31（6）:47～51.Xu Binglin，Li Zhanhuai.SOA-Based Design of the Architecture of Space TT&C Software［J］.Journal of Spacecraft TT&C Technology，2012，31（6）:47～51.

［2］李晓伟，徐冰霖，郭 巍，王建伟.设计模式探析及其在测控软件中的应用［J］.飞行器测控学报，2012，31（3）:21～26.Li Xiaowei，Xu Binglin，Guo Wei，Wang Jianwei.Discussions on Design Patterns and Their Application in TT&C Software［J］.Journal of Spacecraft TT&C Technology，2012，31（3）:21 ～26.

［3］郭力兵，吴学军，李永刚，刘晓阳.基于COM组件的航天测控软件设计［J］.飞行器测控学报，2009，28（5）:60～64.Guo Libing，Wu Xuejun，Li Yonggang，Liu Xiaoyang.Design of Spaceflight TT&C Soft ware Based on COM Components［J］.Journal of Spacecraft TT&C Technology，2009，28（5）:60 ～64.

［4］赵海原，王丽芳，蒋泽军.基于组件化思想的测控软件开发平台设计与实现［J］，电子设计工程，2013，21（8）:80～83.Zhao Haiyuan，Wang Lifang，Jiang Zejun.Design and Implementation of General Development Platform for Measurement and Control Software Based on Componentization of Ideas［J］.Electronic Design Engineering，2013，21（8）:80～83.

［5］周锦标，李永刚，鲍俊雷.面向构件的海上测控软件系统架构的设计［J］.装备指挥技术学院学报，2008，19（6）:104～107.Zhou Jinbiao，Li Yonggang，Bao Junlei.The Components Oriented Design of Seaborne Track and Control Software System［J］.Journal of the Academy of Equipment Command&Technology，2008，19（6）:104 ～107.

［6］郭力兵，李永刚，王 恒，白小舒，刘海兵.航天测控软件共用原型系统设计与实现［J］.遥测遥控，2013，34（1）:61～66.Guo Libing，Li Yonggang，Wang Heng，Bai Xiaoshu，Liu Haibing.Design and Realization of Spacecraft TT&C Software Sharing Prototype System［J］.Journal of Telemetry，Tracking and Command，2013，34（1）:61 ～66.

［7］温 昱.软件体系结构设计［M］.北京:清华大学出版社，2009:261～267.Wen Yu.Software Architecture Design［M］.Beijing:Tsinghua University Press，2009:261 ～267.

［8］徐广柱，吴锦凤.大型火箭发动机地面试验系统测控软件架构设计［J］.火箭推进，2012，38（2）:68～74.Xu Guangzhu，Wu Jinfeng.Software Architecture Design of Measurement and Control System in Ground Testing System for Large-scale Rocket Engine［J］.Journal of Rocket Propulsion，2012，38（2）:68 ～74.