基于抽象工厂模式的机载总线数据通用化处理方法研究
2022-10-19杨萍文信峰
杨萍，文信峰
（航空工业北京青云航空仪表有限公司飞控设计部，北京 100029）
0 引言
机载数据总线技术是飞机的电传操纵系统和航空电子系统综合化的关键技术之一，它的发展与航空电子技术的发展密切相关，先后经历了四个时代：第一代航空电子系统是分立式结构；第二代是联合式航空电子系统，采用的是数字式数据总线网络；第三代是综合式航空电子系统，采用了高速数据总线；第四代是先进综合式航空电子系统，采用统一航空电子互联网络。机载总线技术的发展，也是航空电子系统的发展，是为了满足航空电子系统数据量日趋庞大，数据交联关系多样化、复杂化的需求［1］。
在军用航空电子系统中，快速、准确地进行数据传输尤为重要，数据传输和处理对航空电子系统的性能影响很大，可以说是现代航空电子系统的支柱，因此可靠、高速的数据处理是航空电子系统设计的关键技术。为了满足这个需求，我国航空电子系统中使用了各种机载数据总线，以
RS232/422/485，MIL-STD-1553B，ARINC429，AFDX等类型为主。在进行总线数据处理时既要考虑总线的技术特点，又要兼顾协议标准。在日常开发中经常遇到总线类型多、信号量大的处理问题，当系统功能更新迭代时需要扩展总线或者增加信号时，就会导致之前的软件模块无法使用，需要重新开发，因此不仅导致工作量的增加，而且会导致不同版本之间维护困难，经常出现调用混乱的情况。而计算机设计模式中的抽象工厂模式正是采用一种通用化的处理方法，使总线处理标准化、通用化，大大简化了不同总线数据的处理过程，提高程序的模块化和可复用性，实现高效、准确的数据处理和传输，突破了以往对于数据处理的固有方案，提高了机载软件的可复用性和可靠性［2］。
1 抽象工厂模式
设计模式是将解决重复发生问题的方案核心总结成固定的模式，给出特定场景下问题的通用解决方案。一般用类关系和对象之间的通信方式描述软件方案。抽象工厂模式是设计模式中用得比较多的一种对象创建型模式，将对象实例化过程抽象到一组接口的创建中。目的在于不指定具体类类型的情况下创建一系列相关的类对象。可以将大量有共同接口的类实例化，并可动态决定将哪一个类实例化［3］。图1是抽象工厂模式的类关系图，对外提供抽象工厂的类定义，掩盖了具体使用类的类型，从而使客户仅需要与抽象类定义的接口交互，而不必使用特定的具体类的接口［4］。
图1 抽象工厂模式类关系图Fig.1 Class diagram of abstract factory pattern
抽象工厂模式不指定具体的类，仅仅提供创建若干有依赖的对象的接口，抽象工厂模式可以避免客户端和具体的产品耦合，方便以后对产品库的扩展。
2 在机载总线数据处理中的应用
2.1 机载总线数据的特点
随着航空电子系统向指挥、控制、通信和计算机智能化处理方向的发展，对数据总线构成了强大的需求牵引，机载数据总线正在朝着数据传输高速化、网络拓扑结构分布式、传输协议多样化、通信介质光纤化的方向发展，在此发展过程中，机载数据总线本身的传输多样性、协议标准内容多、交联关系复杂等特点更加突出。
原来对于总线数据的处理方案是基于具体信号实现的，因为信号数量有限、交联关系简单，所以每个总线信号都是按照协议标准和技术特点进行单独的数据处理。当测试需求发生改变时，基于整个测试系统相对简单，所以维护单个信号或者单独一类总线的工作相对也简单，而且不容易出错，此时对测试系统的通用性、可复用性的需求也并不明显。
但是随着20世纪八九十年代第三代综合式航空电子系统的出现，航空电子系统所接收和产生的信息种类和数量不断增长，机载数据总线上传输的信号量激增，交联关系复杂多样，而且测试系统的迭代更新加快，型号研制任务加重，在如此快速的变化中，原有的总线数据处理方案出现了很大的局限性，信号量不能实现快速扩充，交联关系转换复杂，测试系统迭代更新时工作量大，设计开发用时久等缺陷都急需一种新的数据处理方案来解决［5］。
2.2 抽象工厂模式在数据处理中的应用
经过第1节对计算机设计模式中抽象工厂模式的分析，我们提出可以将抽象工厂模式的优点用于机载总线数据的处理中。将机载数据总线的共同操作抽象为对外接口，所有的总线操作集合作为抽象工厂类，具体工厂类可以有两种划分方式：一种是以总线分类作为具体产品工厂，对应的产品是具体类型的总线；一种是将总线的操作集合作为具体工厂，对应的产品是某种具体类型总线的对应操作。不管使用哪种划分方式，抽象工厂模式在机载总线数据处理过程中都可以分为三层结构：具体产品、具体工厂和抽象工厂层，如图2所示。每一层之间相互协作，但是彼此在实例化的过程中又相互独立，对外只表现为一个接口［6-7］。
图2 抽象工厂的三层关系图Fig.2 Three layer relationship diagram of abstract factory
这种模式可以保证在外部需求不断变化的时候，比如增加了新类型的总线，只需要增加具体的总线处理，不需要修改对外的接口，从而使对外接口能够更加稳定。例如当增加一种新类型的总线数据时，只需要在具体产品层实现对应总线的各种操作，在调用层实现某种操作时，选择对应类型具体产品即可，从而达到接口不需要做任何改动，也不需要感知底层具体产品形态就可以完成新类型总线的扩展。
我们将抽象工厂模式应用于机载总线数据处理的时候，将机载总线按照总线类型进行分类。同一类型总线数据所遵循的技术特点和协议标准是一样的，具有共同的协议接口，可以按照抽象工厂模式将这些操作接口抽象作为对外的统一接口。
不同的总线类型，对应于不同的具体产品，有几种总线就创建几个实例工厂，每个实例工厂又抽象出来自己的抽象产品和实例产品。本文以ARINC429和MIL-STD1553B两种机载总线数据处理为例，介绍抽象工厂模式的实现方案。
2.3 应用方案的设计和实现
航空电子的地面测控系统由硬件平台和测控软件组成。硬件平台由各类机载总线板卡和数据采集卡构成，对航电系统中的各设备信号进行仿真；测控软件属于应用软件，对底层协议层的操作是驱动硬件平台进行数据收发和处理，对应用层的操作是完成人机交互，实时监控、显示硬件平台的数据和工作状态。由此可见，测控软件协议层负责机载总线数据的处理［8-10］。
采用面向对象的技术对机载总线数据进行通用化处理，是为了应对需求的改变，将总线的共性抽象出来便于以后开发复用，将测试流程通过抽象工厂模式设计使得用户可以方便地修改和扩充。在面向对象领域，有两种最基本的软件复用方式：类库和框架。类库以静态或动态的链接方式，为我们提供了一组可以调用的类。框架可以认为是类库的一种扩展形式，除了提供可以被应用程序调用的类，还可以驱动应用程序中的功能组件，完成特定的操作流程。
机载总线数据的通用处理即建立通用的可复用的类，并一个组件集成到类库中，再对类库进行扩展，既可以清晰地描述机载总线的工作流程，还可以作为一个样本被纳入以后的框架设计，用UML类图表示如图3所示。
图3 机载总线数据通用处理UML类图Fig.3 UML class diagram of data general processing of airborne bus
按照图3所示，框架分为三层结构进行设计。第一层是将机载总线数据独立于系统进行设计，即作为设计模式的第一层—抽象工厂。在该层设计中，按照总线类型创建抽象工厂，每种总线抽象为一个工厂，以面向对象的开发工具MFC开发为例，下面是在MFC中创建抽象工厂的方式［11］：
CDrv429Control m_pDrv429；//创建ARINC429总线对象
CDrv1553Control m_pDrv1553；//创 建1553B总线对象
如果创建的是ARINC429总线，则需要用抽象工厂的接口创建出ARINC429总线的产品：
CDrv429Control m_pDrv429=factory.CreateProduct429Control（）；
新建CDrv429Control类作为ARINC429总线的抽象工厂，m_pDrv429底层对应的是创建ARINC429总线相关的操作，包括数据封装、解析和数据收发等操作。
第二层结构是创建实例工厂。对第一层结构创建的抽象工厂进行实例化扩展，扩展依据是总线技术特点和协议标准，为了实现通用化的处理需求，可以将总线的技术特点和协议标准写成配置信息表，从而将扩展过程简化为对配置信息表的修改过程。下面是在MFC中MIL-STD-1553B总线配置信息表的部分内容：
＜ElementRoot＞
＜dev_nums＞1＜/dev_num＞//1553设备ID
＜MY_CARD_NUM1＞0＜/MY_CARD_NUM1＞//1553通道ID
＜api_bc1_mbuf＞
＜name＞PFAF0100＜/name＞//数据块名称
＜messno＞0＜/messno＞//消息number
＜control＞0x509＜/control＞//控制字
＜messno_next＞1＜/messno_next＞//下 一 个 消 息nmber
＜mess_command1＞
＜rtaddr＞14＜/rtaddr＞//RT地址
＜subaddr＞1＜/subaddr＞//RT子地址
＜tran_rec＞0＜/tran_rec＞//T/R标志
＜wcount＞12＜/wcount＞//数据量
＜/mess_command1＞
＜gap_time＞20＜/gap_time＞//间隔时间
＜/api_bc1_mbuf＞
在1553B总线协议芯片提供的驱动函数、或者1553B总线板卡提供的API函数中调用配置信息表，完成1553B总线测试系统的搭建。该系统运行以后，1553B总线开始启动测试，其对外接口即配置信息表［12-13］。
第三层结构是创建实例产品。该层结构是用户操作的主要对象，包括总线数据接口和总线数据操作，如果说前两层结构完成的是机载数据总线运行，那么第三层结构完成的就是总线上究竟有哪些数字信号、对应哪些物理信号以及数字信号的传输方式。在该层设计中，我们利用第二层对外接口中关于总线消息定义的模块来完成信号的定义和操作。下面是第二层结构中分别关于ARINC429总线和1553B总线消息定义的结构体：
typedef struct_DATA_STRUCTURE_429
｛
char name［100］；//信号名称
UINT type；//数据类型
FLOAT lsb；//数据精度
UINT startbit；//数据低位
UINT endbit；//数据高位
UINT signbit；//是否有符号
UINT channel；//传输通道
UINT lable；//lable
UINT rate；//传输速率
UINT id；//数据块中的id
UINT source；//源标识
｝DATA_STRUCTURE_429；
typedef struct_DATA_STRUCTURE_1553
｛
char name［50］；//信号名称
UINT type；//数据类型
FLOAT lsb；//数据精度
UINT startbit；//数据低位
UINT endbit；//数据高位
UINT signbit；//是否有符号
UINT Value；//数字信号值
UINT messno；//消息号
UINT index；//消息块中的索引位置
FLOAT initialD；//初始物理值
char comment［50］；//物理意义
｝DATA_STRUCTURE_1553；
用户可以将总线数据接口文件按照提供的结构体格式，形成第三层结构设计的配置信息表，总线数据操作是对该配置信息表的数据元素进行操作。至此，完成机载总线数据的通用化处理。由上述设计过程可见，每一层设计都是独立的，但是又与其他层互为对象，抽象工厂模式将处理单个总线数据的规则，通用化得应用到了整个这一类总线对象中，从而形成这一类总线的一个实例工厂，便于维护，也便于在需求发生改变或扩展时，提高可移植性和复用性。
本文提出的基于抽象工厂模式的机载总线数据通用处理方法，是根据所有机载总线的协议标准和总线数据的传输特点进行的共性分析处理，不受板卡工作方式、接口信号物理定义的限制，在方案设计中的第二层和第三层实例产品设计中包含了目前航电系统常用的所有种类的机载总线。
该方案的通用程度，在数据层、协议层、仪器层三个层面上不尽相同。首先在数据层和协议层两方面，该方案是完全通用的，这两个层面属于应用程序级，完全可以复用方案中所设计的结构体、配置信息表等实例产品。其次在仪器层方面通用化程度会受一定程度的限制。而第一层设计的目标是建立各总线的硬件操作对象，每个平台的配置不同、硬件不同，使得该层设计与测试平台的硬件密不可分。除此之外，在第二层和第三层是完全可以通用的，因为任何机载总线数据的协议传输特点和接口信号特点都被包含在这两层设计的实例产品中。综上分析，该方案的通用程度很高，能够实现的软件可复用率也很高。
该处理方案的有效性体现在软件模块实现了可复用。原来的数据处理方案是针对具体项目的每一个接口信号来处理的，而本文所提方案是针对这一类总线协议的数据的；软件在进行数据处理时的开发、运行和维护，原来是在每个信号的代码上进行的，而经过抽象工厂模式的共性特征提取后，软件的数据处理变成了只需要维护与总线协议相关的配置信息表以及接口信息表，而协议层和数据层的工作则是由可复用模块来完成［14］。设计模式对总线数据协议和数据处理部分进行了重构，使类模块之间更加解耦，模块内部更加内聚。不仅代码总量上有明显的减少，而且模块之间的层次更加分明。对于使用者来说不需要关心内部的处理方式，只需要根据需要做相应的配置变更，使用更加简单。该模块已通过测试和验证，可以被安全复用，提高了软件开发的效率，降低了维护成本，增强了安全性和可靠性［15］。
3 结论
应用抽象工厂模式对机载总线数据进行通用化处理，使设计更灵活、更模块化。当总线需求发生变化时，数据处理的最大障碍是对被实例化的类进行硬编码，而抽象工厂的设计模式提供了多个不同接口，从实例化它们的代码中除去对这些类的显式引用。航空电子系统复杂多样的交联关系通过抽象工厂模式的设计，可以实例成各类总线的接口，从而将原来按部件设计的接口关系图，重新按照总线类型设计，形成一个灵活易维护的接口控制文件（ICD），不仅可以完成机载总线数据处理这样的基础工作，还可以进行测控系统设计、半实物仿真平台搭建等更多、更具扩展性的系统设计开发。因此抽象工厂模式的思想不仅解决了机载总线数据通用化处理的问题，还给测控系统的设计提供了一种方法，使得测控系统能够与航空电子系统的快速发展相适应。
