在飞机数字化装配^[1]场景下，围绕生产线和配套信息系统，存在着大量装配数据，或产生于装配过程中，或作为配置信息而存在. 飞机装配数据可以用于支持数字化装配系统基本功能的运转，进行现场的可视化^[2]、数据的可视化，还可以用于构建数据与装配质量^[3]、设备故障^[4]间的关联模型，从而开展实时分析. 飞机装配数据的充分利用有利于改善当前生产状态不透明和制造执行调整能力差的问题.

由于飞机装配数据的多源异构问题阻碍了数据的流通与共享，为数据的充分利用带来不便. “多源”体现在飞机装配数据分散存储于关系型数据库、非关系型数据库、半结构化文档、数据接口、分布式文件系统等不同类型的数据源之中；“异构”体现在数据存储结构、访问方式与访问信息、数据需求表达语言、数据响应结构、数据语义等方面的不统一. 由于多源异构问题的存在，在综合应用各类飞机装配数据时，须清楚知道每个数据项具体在哪个数据源、数据源内部的数据组织形式、数据源如何访问等信息，还须编写不同代码片段以访问不同类型数据源，并承受语义模糊、冲突的困扰.

为了解决飞机装配数据的多源异构问题，须进行数据集成研究，将数据以物理或逻辑的方式集成于统一的数据资源中心，从而对外提供优质的数据资源共享服务^[5]. 窦亚冬等^[6]设计了一种基于装配任务、装配对象、工装设备的多重结构数据关系模型，以此形成飞机数字化装配物理意义上的单一数据源. 为了实现飞机装配中的运动路径动态仿真和实时碰撞干涉预判，应征等^[7]设计了相关运动数据的实体关系模型，实现了物理意义上的飞机装配运动数据集成. Scott等^[8]以波音747机型装配工艺改进为目的，开发了集三维测量数据采集、存储与分析功能于一体的数据管理系统. 为了实现飞机装配质量数据集成，孟飙等^[9]设计了包含质量数据关系模型和质量数据仓库模型在内的质量数据模型体系. 但是，上述研究存在受集成数据源类型限制和无法兼容柔性化装配场景下的数据集成需求的问题.

为了增强装配系统中的数据共享，亢颖等^[10]围绕工艺过程，构建装配数据对象模型，在协同数据层提供一个逻辑上统一的单一产品数据源虚拟库，促进飞机装配中ERP、MES系统的数据共享和交换. 卞华星等^[11]针对飞机协同设计中不同专业软件间的数据交换问题，设计并实现了基于DDS的飞机协同设计数据服务中间件，以XML进行通用数据表示，在保持原有各专业软件自治性的基础上，实现了不同软件间的信息交互. Wang等^[12]利用本体技术，对来自设计所、制造商和最终用户的航空装备故障信息进行集成，以全局本体作为公共模型，对多源数据进行统一而具体的描述，解决其中的异构特性问题，但其数据集成覆盖范围小，通用性不足.

本研究针对飞机装配数据多源异构问题，分析了多源异构数据类型，提出了一种基于虚拟中心数据源的飞机装配数据集成方法，设计了用于重新组织数据的装配数据全局模型，定义了统一的数据索引规范和数据集成的接口规则. 基于所提出的数据集成方法，开发了飞机装配数据集成中间件，并以飞机外翼翼盒装配为背景，完成了中间件的应用验证与测试.

在装配业务层面上，飞机装配数据可以分为3大类：装配对象数据、装配系统数据、装配任务数据. 以某型飞机外翼翼盒装配为例，相关数据如图1所示.

1）装配对象数据. 装配对象是指翼盒装配中涉及的各类装配件，如前后缘、翼肋、壁板等，相关数据可以划分为基本信息、关键特性、工艺参数3个子集. 其中，装配对象的基本信息包括其编号、名称、数模以及所属机型；关键特性是指装配对象的主要几何特征，包括点、线、面，如交点孔、中心线、对接面等，在装配过程中通过控制、测量以及评价这些关键特性参数来实现与评价装配效果；工艺参数子集中包含装配对象相关各类具体装配任务的参数设置，分为吊装与吊离参数、加工与连接参数、位姿评价与调整参数.

2）装配系统数据. 装配系统相关数据可以划分为基本信息、公共观测点、坐标转换关系、设备数据、人员信息等5个子集. 其中，装配系统的基本信息包括装配系统编号、名称、类型、规格等；公共观测点是布置在装配现场的若干点位，利用其在测量坐标系下的实测坐标和在装配坐标系下的理论坐标计算2个坐标系间的转换关系；坐标转换关系子集中保存各激光跟踪仪、产品、设备相应坐标系与装配坐标系间的转换关系，记录坐标原点在装配坐标系下的位置和方位角；设备数据子集用于记录装配系统中各设备相关数据，包括基本信息、设备坐标系信息、设备运行状态等数据；另有人员信息子集，记录账号、密码、姓名、工作编号、所属部门、权限、登录记录等信息.

3）装配任务数据. 装配任务数据划分为任务配置和任务执行2个子集. 任务配置数据是装配工艺流程设计的具象化，通过父子任务的层层嵌套以及兄弟任务的有序排列，形成最终的外翼翼盒装配任务分解结构，相关数据包括任务编号、任务名称、任务类型、父任务编号、父任务对应子任务编号、任务执行位序等. 任务配置数据是在装配前就已经确定下来的，而任务执行数据是在装配过程中产生的，包括装配架次、环境数据、任务执行结论、任务执行数据、设备调用记录等.

多种不同类型数据源在外翼翼盒装配中得到应用：核心装配系统采用关系型数据库MySQL存储配置信息、点位、位姿、设备运行状态等数据，采用XML文档存储加工参数、刀具信息、紧固件信息等相关数据，采用HDFS分布式文件系统存储孔径视觉测量图像；外围配套软件采用非关系型数据库Redis存储账号登录信息，通过数据接口获取定位器实时承载力.

为了解决飞机装配数据的多源异构问题，本研究提出了一种基于虚拟中心数据源的飞机装配数据集成方法：在所有集成数据源之上构建一个不实际存储数据的虚拟中心数据源，采用二级索引的方式访问实际存储于集成数据源中的数据，借助装配数据全局模型实现数据索引规则的统一. 该方法支持以格式统一的基本数据单元封装数据查询方式，最终实现逻辑上对飞机装配数据进行集成，以单源代替多源，整合各类异构数据的访问并规范其语义.

飞机装配数据仍然存储于不同类型的多个被集成数据源中，虚拟中心数据源不实际存储数据，但又要求数据请求方可以通过虚拟中心数据源获得所需数据. 元数据^[13]是用于描述其他数据的数据，对某个数据的来源、存储信息、业务内涵等各个方面进行描述. 虚拟中心数据源中记录所有数据的元数据，在接收到数据请求时，首先找到所需数据的元数据，此为第1级索引；其次根据元数据中的存储信息从集成数据源中获取所需数据本身，此为第2级索引.

每个被集成数据源都有其私有的数据组织方式，各不相同，因此在整体层面上数据表现为缺乏规则. 为了方便数据访问，虚拟中心数据源同样也须以一定的方式对数据进行组织，在所有局部规则之上提供一种全局统一的索引规则，将原本无规则地、散乱地存储在多个异构数据源中的数据按指定的结构进行组织. 装配数据全局模型便是该全局统一索引规则的载体，其中以指定的结构保存着所有被集成数据的元数据，通过组织元数据的方式来重新组织数据. 同时，二级索引的实现依赖于装配数据全局模型中的元数据.

装配数据全局模型的构成自顶向下划分为汇聚层、应用逻辑层、局部模型层、数据对象层和元数据层，分层逻辑如图2所示.

1）汇聚层. 在装配数据全局模型中，由下层元素组合形成上层元素，层层嵌套，并最终在汇聚层形成装配数据全局模型 $ {M}_{\mathrm{g}\mathrm{l}\mathrm{o}} $.

2）应用逻辑层. 根据飞机装配数据应用围绕装配任务或设备的特点，在装配数据全局模型 $ {M}_{\mathrm{g}\mathrm{l}\mathrm{o}} $下划分装配任务视角 $ {P}_{\mathrm{t}\mathrm{k}} $和设备视角 $ {P}_{\mathrm{d}\mathrm{e}\mathrm{v}} $，分别围绕装配任务和设备组织数据.

3）局部模型层. 在装配任务视角 $ {P}_{\mathrm{t}\mathrm{k}} $下按照“生产线-站位-装配任务”的层次形成树状结构 $ {\mathrm{S}}^{\mathrm{t}\mathrm{m}} $，组织多个与装配任务相关的局部数据模型 $ {M}_{\mathrm{t}\mathrm{o}\mathrm{t}}^{\mathrm{t}} $；在设备视角 $ {P}_{\mathrm{d}\mathrm{e}\mathrm{v}} $下，按照“设备族-设备”的层次形成树状结构 $ {\mathrm{S}}^{\mathrm{dm}} $，组织多个与设备相关的局部数据模型 $ {M}_{\mathrm{l}\mathrm{o}\mathrm{c}}^{\mathrm{d}} $.

4）数据对象层. 本研究采用实体-关系（E-R）建模方法^[14]定义装配数据全局模型. 在装配任务相关的局部数据模型 $ {M}_{\mathrm{l}\mathrm{o}\mathrm{c}}^{\mathrm{t}} $中定义了装配对象实体集 $ {O}_{\mathrm{a}} $、装配系统实体集S_a、装配任务实体集 $ {T}_{\mathrm{a}} $，还有不同装配任务实体 $ {R}_{\mathrm{t}\mathrm{o}} $、装配系统实体 $ {R}_{\mathrm{t}\mathrm{s}} $、装配对象实体间的关系集 $ {R}_{\mathrm{o}\mathrm{s}} $；在设备相关的局部数据模型 $ {M}_{\mathrm{l}\mathrm{o}\mathrm{c}}^{\mathrm{d}} $中定义了基本信息实体集 $ {B}_{\mathrm{d}} $、运行状态实体集 $ {W}_{\mathrm{d}} $、坐标系实体集 $ {A}_{\mathrm{d}} $.

另外，在数据对象层中还定义了装配系统实体与设备实体间的关系集 $ {R}_{\mathrm{s}\mathrm{d}} $，这是为兼容柔性化装配场景下的数据集成需求而做的特殊设计.

装配数据全局模型的一般表达式如下：

(1) $ \left.\begin{array}{l}{M}_{\mathrm{g}\mathrm{l}\mathrm{o}}={\{P}_{\mathrm{t}\mathrm{k}},{P}_{\mathrm{d}\mathrm{e}\mathrm{v}}\} ,\\ {P}_{\mathrm{t}\mathrm{k}}=\left\{{M}_{\mathrm{l}\mathrm{o}\mathrm{c}}^{\mathrm{t}},{S}^{\mathrm{t}\mathrm{m}}\right\},\\ {P}_{\mathrm{d}\mathrm{e}\mathrm{v}}=\left\{{M}_{\mathrm{l}\mathrm{o}\mathrm{c}}^{\mathrm{d}},{S}^{\mathrm{d}\mathrm{m}}\right\},\\ {M}_{\mathrm{l}\mathrm{o}\mathrm{c}}^{\mathrm{t}}=\left\{{O}_{\mathrm{a}},{S}_{\mathrm{a}},{T}_{\mathrm{a}},{R}_{\mathrm{t}\mathrm{o}},{R}_{\mathrm{t}\mathrm{s}},{R}_{\mathrm{o}\mathrm{s}}\right\},\\ {M}_{{\rm{loc}}}^{{\rm{d}}}=\left\{{B}_{\mathrm{d}},{W}_{\mathrm{d}},{A}_{\mathrm{d}}\right\},\\ {M}_{\mathrm{l}\mathrm{o}\mathrm{c}}^{\mathrm{t}},{M}_{{\rm{loc}}}^{{\rm{d}}},\;{R}_{\mathrm{s}\mathrm{d}}=\left\{{E}_{{\rm{met}}}\right\}.\end{array}\right\} $

柔性化装配是飞机装配的一种发展趋势，其特点之一是装配系统可重组，一组可移动的设备、工装充当“积木”，一套装配系统由一定类型、一定数量的“积木”组成且同类型“积木”可互换，一块“积木”可以在不同时段充当不同装配系统的组成成分.

在现有研究中，数据模型在数据集成系统运行过程中通常是固定不变的. 若采用常规方法，即按照“机型-生产线-站位-装配系统-子系统-设备”这样的飞机装配现场组织形式来组织数据，那么某台设备的数据将始终绑定在某套装配系统之下，设备与装配系统严格绑定，有悖于“柔性、可重组”的装配思想，数据模型将无法正确反映现实情况.

为了实现飞机柔性化装配场景下的数据集成，本研究引入“角色”这一思想，将原本的装配系统概念化. 在传统视角下，一套数字化装配系统由一系列固定的实际设备组成，装配系统是现实存在；在装配系统概念化的视角下，一套数字化装配系统是一系列角色的集合，装配系统是概念存在，装配系统中的一个角色在不同时间的扮演者可以不同，一个角色的扮演者可以是一族同类设备中的任意一台. 通过装配系统概念化的视角和角色思想的引入，在装配数据全局模型中，装配系统与角色绑定，而角色与设备间为时变映射关系，从而实现设备与特定装配系统的解绑，契合“柔性、可重组”的柔性化装配思想，使得装配数据全局模型能够兼容柔性化装配场景.

5）元数据层. E-R实体的一个属性与一个被集成数据项对应，在实体集 $ {O}_{\mathrm{a}} $、 $ {S}_{\mathrm{a}} $、 $ {T}_{\mathrm{a}} $、 $ {B}_{\mathrm{d}} $、 $ {W}_{\mathrm{d}} $、 $ {A}_{\mathrm{d}} $中的实体下，均定义有多个元数据元素 $ {E}_{{\rm{met}}} $，每个元素与E-R实体的一个属性对应，保存该属性的元数据信息，标识数据项的全局命名、业务内涵、存储信息.

基于以上设计，构建的装配数据全局模型如图3所示. 其中，装配任务相关的局部数据模型以外翼翼盒装配为代表，在装配系统子树下定义了定位器、跟踪仪角色实体，与定义在设备视角下的设备实体间为时变映射关系（后续将以接口的形式实现）. 为了使图片内容简洁明了，图中隐去了设备实体和角色实体的相关属性.

一个数据源接收的请求应该统一且规范，为了使数据集成系统表现得更像一个中心数据源，数据请求规范的定义十分重要，须保证数据请求能够无歧义地传递用户的真实数据需求，并须具备足够的通用性,这样才能兼容各类异构局部数据源.

须理清数据请求在本研究数据集成系统中所扮演的角色，才能够明确数据请求中到底须携带哪些信息. 本研究数据集成系统通过装配数据全局模型来按一定结构组织数据的元数据，从而达到逻辑上重新组织数据的实际意图. 数据集成系统在接收外部请求后，首先根据数据请求中所传递的数据需求，在装配数据全局模型中找到所需数据的元数据，从而确定数据实际存储位置，再根据一定的约束条件，筛选对应数据集中真正满足需求的数据，封装后返回给数据请求方.

在以上过程中，数据集成系统须在装配数据全局模型中定位所需数据的元数据，还须根据约束条件对通过元数据找到的数据集进行筛选，其中所需要的信息都通过数据请求携带. 因此，数据请求中须携带2部分信息：其一，定位元数据元素所需要的信息；其二，进一步筛选数据所需的约束条件.

综上，本研究数据集成系统接收的统一数据请求如下：{modelLocation, entityPath, relationType, specificName, attribute, restriction}. 其中，modelLocation字段标识数据所属的局部数据模型在全局模型中的位置；entityPath字段定义一个初始实体，标识该实体在局部模型中的位置；relationType字段和specificName字段分别标识实体间关系类型和具体关系名；attribute字段标识所需数据项的全局命名；restriction字段标识约束条件.

基本数据单元是构成数据集成系统对外输出的基本组成成分，必须通过合理的基本数据单元设计，才能在保证输出信息完整且无歧义的同时实现数据集成系统外观的统一.

在进行基本数据单元设计的时候，须综合考虑飞机数字化装配业务背景和信息系统数据集成需要，针对常见数据类型设计格式统一、信息完整且无歧义的数据封装方式.

在飞机数字化装配中，由于数据的多源异构特性，单单数据本身不足以完整地传递信息，还须对数据进行补充描述. 因此，基本数据单元须由2部分组成：元数据和数据本身.

1）元数据部分. 如图4所示，元数据部分中dataType字段标识数据类型，区分字符串和文件；measUnit字段标识数据计量单位； dynamic字段区分数据是实时产生的动态数据或不随时间变化的静态数据；另外，使用modelLocation、entityPath、attribute这3个字段标识数据项在全局模型中的位置. 以上dataType、measUnit、suffix、dynamic、samplingFreq等字段信息直接取自装配数据全局模型中的元数据元素；modelLocation、entityPath、attribute等字段信息由请求内容结合程序逻辑计算而来.

2）数据部分. 针对不同数据类型，分别采用类型转换、序列化、Base64编码等手段，将数据统一转换为字符串后封装入data字段中，既保证了数据集成系统外观的统一，又有利于避免因二进制不兼容问题导致的传输失真.

1）多源. 本研究在所有被集成数据源之上构建一个虚拟中心数据源，通过装配数据全局模型重新组织数据，使得局部多源数据对外表现为全局单源，数据请求方只须访问虚拟中心数据源便可以获得各类装配数据，以此解决飞机装配数据的“多源”问题.

2）访问方式异构. 在进行数据集成之前，数据请求方须访问多个不同类型数据源才能获得所需的各类数据，不同数据源的访问方式以及所需要的访问信息各不相同. 当在数据应用中涉及到多个不同类型数据源时，程序编写者不仅须多番查阅数据源访问信息，还须编写不同的代码片段以访问不同数据源.

在本研究所设计的数据集成方法中，访问信息统一存储于配置文件中，数据请求方只须以统一的访问方法、访问路径对虚拟中心数据源发起访问，由虚拟中心数据源中的程序逻辑结合配置信息代为访问被集成数据源. 程序编写者仅须编写一段虚拟中心数据源访问代码，在有数据访问需求时复用即可.

3）存储方式异构. 不同类型数据源的数据存储结构不统一，这从根本上导致了不同数据源中数据组织方式的不统一：关系型数据库按“库-表-列”的层次组织数据;非关系型数据库（以Redis为例）分库不分表；XML数据源按树状结构自顶向下层层细化；分布式文件系统以文件夹嵌套文件夹的方式组织数据.

相应的，数据请求方表达数据需求的语言便不统一：面向关系型数据库，以SQL语句说明需要某库某表某列中的某行数据；面向非关系型数据库（以Redis为例），通过键名说明需要某键名对应的键值；面向XML文档数据源，借助节点名称或XPath表达式说明需要某节点数据；面向分布式文件系统，以一层层的文件夹名及具体文件名构成的文件路径说明所需的具体文件.

在本研究所设计的数据集成方法中，数据请求方无须关注被集成数据源的数据存储结构，也无须使用不同的数据需求表达语言，只须面向装配数据全局模型，以统一数据请求作为数据需求表达语言，说明需要某场景/某设备相关数据模型中的某实体的某属性并加以约束条件即可.

4）数据响应结构不统一. 不同类型数据源所返回的数据响应的结构是不统一的，这意味着数据请求方须以不同的数据结构存储来自各类数据源的响应，后续须以不同的方式处理，才能得到实际需要的字面值.

在本研究所设计的数据集成方法中，基本类型、对象、图片、视频、文档等各类数据，将通过序列化、Base64编码手段统一转换为字符串，然后补充dataType、suffix元数据，在被封装为基本数据单元的数据结构后，最终返回给数据请求方，便于数据请求方接收与处理.

5）语义异构. 关于同名异义：各个被集成数据源中的字段语义常常是由数据集语境隐式赋予的，比如人员表中出现“ID”这一字段，该表的语境是人员信息，那么该表中的“ID”字段则大概率意指人员编号，但这种隐式赋予只是一种一般设计规律，并不严格. 当数据应用涉及到大量数据集，且其中多个数据集共有同名字段时，上述隐式赋予字段语义的作用将大打折扣，程序编写者或因同名的缘故误判字段语义，最终导致程序逻辑错误.

关于同义异名：给数据项取一个合适的字段名有利于表达语义，由于前期设计不规范或数据源设计者与访问者间的理解偏差，程序编写者可能难以单纯通过字段名辨别数据语义，须查阅相关设计说明、数据字典或操作手册等材料，多有不便.

在本研究所设计的数据集成方法中，利用装配数据全局模型重新组织数据，在所有被集成数据源的基础上建立一个全局统一的数据模型，利用装配数据全局模型中的层次结构和数据项全局命名显式赋予数据项语义. 同时，相应地建立起一套全局统一的数据索引规范，程序编写者在利用代码表达数据需求时，索引的不再是某库某表中的某一列、某个键值或者某个路径对应的文件，而是某场景/设备相关数据模型中的某实体具体属性. 利用装配数据全局模型以及面向装配数据全局模型的统一数据请求，本数据集成方法可以支持数据请求方无歧义地表达数据需求，避免数据请求过程中带来的“语义异构”问题. 另外，该方法通过基本数据单元中携带的元数据信息完善数据响应的语义描述，避免数据应用中的“语义异构”问题.

以上所述数据集成前后数据请求方式对比总结如图5所示.

在以上数据集成方法设计的基础上，加以软件实现，形成多源异构装配数据集成中间件. 数据集成中间件整体上分为2层：中介层和适配器层. 其中，中介层负责处理数据请求和响应，在收到请求和返回响应之间，中介层还负责将面向全局模型的全局请求转换为面向被集成数据源的局部请求，并将局部请求分配到对应的适配器进行执行；适配器层包括多个与被集成数据源类型相对应的适配器，负责执行中介层分配下来的局部请求. 多源异构装配数据集成中间件的整体架构如图6所示.

1）中介层由配置文件、WebService接口、角色-设备映射接口组、元数据查询器、局部数据源查询器、查询分配器等组成.

a）配置文件包括以XML格式实现的装配数据全局模型和局部数据源注册信息. 装配数据全局模型XML文档以globalModel为根节点，在根节点下划分taskPers和devicePers子节点，分别用于组织任务视角和设备视角下的数据；局部数据源注册信息XML文档以localDSrcReg为根节点，在根节点下划分dataBases、semiStructDocs、interfaces、fileSystems子节点，分别用于注册数据库、半结构化文档、外部数据接口、文件系统等不同类型局部数据源.

b）WebService接口的作用是将中间件的功能对外暴露，从而使得各类上层应用软件可以远程访问到中间件中定义的类和方法，达到中间件对外提供数据服务的效果.

c）角色-设备映射接口的作用是查询柔性化装配场景中角色与设备间的时变映射关系，找到指定时刻扮演某角色的具体设备或者某设备所扮演的具体角色. 接口访问信息配置在装配数据全局模型中的相应角色实体或设备实体下.

d）元数据查询器的作用是根据统一数据请求中的信息找到全局模型中对应数据的元数据元素；局部数据源查询器的作用是根据元数据元素中的信息找到数据所在局部数据源的注册信息. 两者的功能类似，都是根据输入信息找到XML文档中的指定元素. 因此，两者的实现技术选型一致，利用XPath路径表达式定位所需节点，采用dom4j框架解析对应的XML文档并访问XPath所指向的节点.

e）查询分配器的作用是遍历元数据查询器所获得的元数据元素列表，形成局部请求并将其分配到对应的适配器进行执行，最终获得基本数据单元列表.

2）适配器层包含多个与局部数据源类型对应的适配器，负责接受中介层调用并执行对局部数据源的查询.

在某型飞机外翼翼盒数字化装配中，存在系统信息数据库、设备信息数据库、任务信息数据库，共3个MySQL数据库，存储绝大部分装配数据；采用非关系型数据库Redis存储配套信息系统的登录校验信息；采用半结构化文档以树状结构存储加工参数、刀具配置及预紧固件配置；通过数据接口对外提供数控定位器承载力的访问；采用分布式文件系统HDFS存储孔径视觉测量图像、装配件数模、工艺文档等文件. 通过配置装配数据全局模型和数据源注册信息，利用数据集成中间件实现外翼翼盒装配相关多源异构数据的集成.

飞机装配数据应用平台是基于B/S架构，在Java、CSS、HTML5等技术支持下开发的一个Web端装配数据可视化软件，能够实时获取设备运行状态信息，有利于提高生产状态透明度，加速装配过程中问题的发现、处理与调整. 该软件通过数据集成中间件访问多源异构飞机装配数据，是本研究成果的应用实例，数据访问架构如图7所示.

数据应用平台通过数据集成中间件获取实际存储于不同数据库、数据表中的各类设备运行状态数据，如图8所示为前端设备总览界面展示，以便实时监测现场整体情况.

点击设备总览界面中的具体设备名，即可进入如图9所示的该设备的详情查看界面，数据应用平台通过数据集成中间件访问取自数据接口的数控定位器承载力，并由前端界面以图表形式展示.

与直接访问集成数据源相比，应用软件通过数据集成中间件访问飞机装配数据，因配置信息解析与查询、程序逻辑处理、网络访问等额外处理，将引入额外的数据访问耗时. 该额外耗时为负面影响，应尽可能地短，才能够满足更多的数据应用场景需求.

测试环境是在Win10系统下，假定2台主机分别为服务器和设备端，基于TCP/IP协议和Socket编程技术，实现在数据在2个终端之间的传输. 利用接口测试软件Postman和编写的控制台应用程序分析数据集成后各个事件在每一次数据访问中引入的时间成本. 在Postman中定义了Socket Initialization、DNS Lookup、TCP Handshake、Transfer Start、Download等事件，可以在一次接口测试后查看该次接口访问过程中相应事件耗时. Postman软件所定义的事件对应时间内涵如表1所示.

测试程序的时间灵敏度为1 ms，对于耗时小于1 ms的事件，获得多次重复总时长再进行平均. 具体测试过程在本研究中不再赘述. 对数据访问过程中的各事件耗时进行测试，结果如图10所示. 图中，从左到右为时间顺序.

时间块①表示项目启动时配置文件加载耗时，共323.9 ms，一次加载多次使用，在后续访问中不包含此耗时.

时间块②表示中间件引入的额外数据访问时间成本，此部分耗时存在于中间件持续调用过程中的每一次调用之中，当所需数据为字符串类型时，共11.46 ms；当所需数据为文件类型时，此部分耗时由2部分组成，一部分为固定时间9.79 ms，另一部分随文件大小发生变化，以1000 kb大小的文件为例，该随变时间为442.33 ms，此时时间块②的总耗时为452.12 ms.

时间块③也是中间件引入的额外数据访问时间成本，它意味着在通过中间件访问柔性化装配场景下数据时，须在时间块②的基础上另外再引入12.15 ms的额外耗时.

时间块④也是中间件引入的额外数据访问时间成本，它意味着在通过中间件获取文件时，须在时间块②的基础上另外再引入Base64编码/解码的额外耗时，该耗时随文件大小发生变化，以1000 kb大小的文件为例，一次编码耗时1.49 ms，一次解码耗时1.46 ms，共计2.95 ms.

时间块⑤表示必要的数据访问时间成本，即使不通过数据集成中间件而是直接访问局部数据源，此耗时也不可避免，因此不属于数据集成中间件所引入的额外时间成本. 而且时间块⑤耗时与被集成数据源的设计、存储量以及具体查询的内容、结果大小直接相关，小至数毫秒，大至获取大文件时的数分钟甚至数小时，不可一概而论.

一次数据访问中的额外耗时总结如表2所示. 表中， $ {{t}}_{1} $为访问数据为字符串类型时耗时， $ {{t}}_{2} $为访问数据为文件类型（以1000 kb大小文件为例）时耗时.

借助数据集成中间件，数据请求方可以在统一的索引规则下表达数据需求，并通过统一的访问方法、访问路径发起数据请求. 在接收到数据请求后，数据集成中间件能够正确地按照预定逻辑进行处理，无论是字符数据还是不同格式的文件，均能够被准确且完整地封装为语义完善的基本数据单元集并返回给数据请求方，不存在数据异常、错误以及缺失的情况.

数据集成的代价主要体现在数据访问时间成本上：1）在通过数据集成中间件获取字符串类型数据时，将引入11.46 ms 额外耗时，在柔性化装配场景下，由于角色-设备映像接口访问的需要，这一数值将变为23.61 ms. 2）在通过数据集成中间件获取文件时，所引入的额外耗时随文件大小发生变化，以1000 kb 大小的文件为例，将引入455.07 ms额外耗时，在柔性化装配场景下，由于角色-设备映像接口访问的需要，这一数值将达到467.22 ms. 通过数据集成中间件获取字符串类型数据的额外耗时极低，即使在实时性要求高的特殊飞机装配数据应用场景中也能够满足使用要求. 通过数据集成中间件获取文件的额外耗时随文件大小发生变化，可以利用该中间件以较低的额外耗时获取小文件，但不推荐将该中间件用于大文件的获取.

为了解决数据的多源异构问题并改善数据的可访问性，提出一种基于虚拟中心数据源的飞机装配数据集成方法，通过在飞机装配场景下所有局部数据源之上构建一个虚拟中心数据源，实现逻辑上对飞机装配数据进行集成的效果，最终形成了基于中介层和适配器层2层架构的多源异构装配数据集成中间件. 应用验证及测试结果表明本研究提出的数据集成方法及其软件实现能够以毫秒级的额外数据访问时间为代价，改善数据的可访问性，达到屏蔽装配数据多源异构特性并提供统一、透明数据访问服务的效果，解决飞机装配数据的多源异构问题，有利于数据的流通与共享.

多源异构装配数据集成中间件虽然实现了预期功能，但也引入了额外的处理时间和传输时间，还存在较大改进空间.

1）在未来研究中可以利用缓存技术减少不必要的数据处理，利用消息队列削峰填谷提高吞吐量，利用集群部署和负载均衡满足更多的数据请求，从而改善多源异构装配数据集成中间件的性能.

2）装配数据全局模型和局部数据源注册信息以XML 文档的形式保存，数据源的扩展须以手动方式修改XML 文档. 下一步研究可以考虑借助编程来实现半自动化扩展.

3）装配数据全局模型为数据访问提供了全局统一的索引规则，数据集成中间件所接收的数据请求是面向全局模型的. 目前还缺乏配套的可视化工具来辅助数据集成中间件的使用者，使之可以实现所需数据在全局模型中的定位，从而更快、更准确地构造统一数据请求. 下一步可以结合前端技术与XML技术，基于装配数据全局模型XML 文档来实现全局模型的可视化，优化数据集成中间件的使用体验.