基于B/S 的民用飞机结构修理方案平台的设计与实现

2021-12-23 11:31冯蕴雯严浩路成薛小锋徐志斌

航空工程进展 2021年6期

冯蕴雯，严浩，路成，薛小锋，徐志斌

（西北工业大学航空学院，西安710072）

0 引言

飞机的结构修理是民用飞机日常维护工作的重要组成部分。在实际修理中，有时会遇到超出手册范围的修理情况。随着航空营运人员机队规模扩大以及老龄飞机数量的增加，民用飞机结构超手册修理的情况也将不断增加。以深圳航空为例，2013 年的超手册修理为 20 项，2014 年为 38 项，2015 年达到了 52 项，到 2018 年平均每 2 天就要实施一项超手册修理。超手册修理通常包括两种情况：一种是手册上对某一种结构损伤的修理方法没有具体明确的说明；另一种是由于采用原生产工艺进行修理的成本较高，航空营运人在维修时不能按照原有工艺进行修理而需要采用替代方案。

航空营运人员发现结构损伤超出手册范围后，通常可以通过以下途径获得修理方案：（1）自行制定维修方案报原始设备制造厂获得批准；（2）将损伤详细信息报原始设备制造厂获得维修方案和批准。与自行制定维修方案相比，从设备制造厂获得维修方案再实施修理工作会使得修理周期更长。

对飞机的重量、平衡、结构强度、性能、动力装置工作、飞行特性没有显著影响的修理被认为是非重要修理。超手册修理中也存在一部分情况是非重要修理。对于此类修理，由维修工程部门自行制定修理方案，并实施修理工作，既可以有效降低维修成本，又有利于缩短维修周期，使飞机能够更快地恢复运营。但如果修理方案制定得不合理，将导致不当维修的情况发生。不当维修是导致飞行事故的主要或促成因素之一，而有合理计划的维修是成功维修的关键。因此，在制定修理方案时，参考类似的成功修理方案，有助于维修工程人员更快制定出合理的维修方案。

孙建厦结合一线工程维修情况，详细介绍了民用飞机结构超手册修理的流程，针对超手册修理存在时间跨度较长，容易受到人为因素干扰，信息重复填写等问题，提出了建立相应信息化系统的需求和相关设想；余宾针对一线维修工程部门的需求，开发了飞机维修与工时管理系统，实现了人力资源管理、工时管理、维修经历管理等功能；蔡鹏针对航空工业长飞公司维修工作的特点与现状设计了飞机维修管理系统，提高了资源分配效率、压缩了维修周期；闫伟在详细分析了飞机维修技术状态管理系统的业务和功能需求的基础上，开发了飞机维修技术状态管理系统；针对目前飞机维修管理的工作现状，刘树乾设计了基于B/S 的飞机维修管理系统，实现对飞机故障的记录、维修和相关文件的管理，使飞机维修工作的效率和成本得到了改善。为了实现全球机队有效管理和提供优质的后勤保障业务，波音公司开发了用以支持全球机队安全运营的综合管理平台，并集成在其门户网站上，该综合管理平台功能已趋于完善，主要包括：用以数据采集的模块、用以可靠性管理的模块、用以维修任务优化的模块等；空客公司为了加强民用飞机全寿命周期管理和完善民用飞机管理体系，建立了全寿命周期管理平台，将其嵌入空客公司门户网站上，为航空企业用户提供全方位的技术支持。

综上所述，国外波音和空客公司在使用平台技术支持民用飞机运营维护工作上，处于较为先进的地位。目前国内在使用信息化平台技术支持飞机维修工作方面取得了很好的发展，其主要工作集中于记录维修数据、分配维修任务、管理维修文件、简化线下的工作流程等方面，但不能针对损伤信息直接为用户提供修理方案，尤其是尚缺乏为超手册结构修理工作提供可供参考的修理方案的功能。

本文通过对民用飞机结构修理工作的需求分析，设计基于B/S 的民用飞机结构修理方案平台，通过实际演示操作，对平台的主要功能模块进行测试。

1 需求分析

1.1 业务流程分析

民用飞机的每一次修理工作，都必须满足局方对适航性的相关要求。对于超手册修理工作，如果不进行严格的管理和有效的控制，会降低航空器的可靠性，甚至影响飞行安全。因此，对于飞机结构的非重要修理，航空公司的维修工程部门在制定并实施修理方案的过程中，参考一些类似损伤的成功修理方案，将有利于保障修理方案满足适航性要求。

修理方案平台的核心任务是：在日常的修理工作中，将一些典型的损伤信息和修理方案内容存入数据库，以便在需要形成新的修理方案时可以进行调用及数据交互；通过当前的损伤信息、电子化的修理方案等内容，给当前损伤推荐若干修理方案作为参考，且每一次的成功修理方案将为新的结构修理方案制定提供数据化支持。

结合平台的使用确定修理方案的流程，如图1所示。

图1 使用平台形成修理方案的流程图Fig.1 Flow chart of using the platform to form the repair plan

（1）损伤信息的输入：由用户根据实际损伤情况输入损伤信息，包含机型、结构部位、损伤尺寸、损伤类型等参数。

（2）审核损伤信息：由用户对输入的损伤信息内容进行审核，检查输入的损伤信息内容是否符合规范。满足要求的损伤信息标记为“审核通过”，进入下一步流程。

（3）系统推荐参考修理方案：对于通过审核的损伤信息，程序会根据预先编写的关联条件推荐相应的若干条历史修理方案。用户可以对这些修理方案进行查看和选择。

（4）形成初步修理方案：用户对系统自动推荐的修理方案进行查看和选择后，可选择推荐的修理方案内容作为参考，然后结合修理准则、修理经验和实际损伤情况形成初步修理方案。

（5）审核并确定修理方案：对形成的初步修理方案，再由用户判断其可行性。如果方案可行，则可以确定修理方案；如果不可行，则需要进一步考虑修理准则、修理经验、实际损伤来重新确定修理方案。

1.2 功能需求分析

根据修理方案形成的流程，对平台的具体功能进行分析。平台应具备下述七种功能。

（1）信息输入与管理

录入结构修理数据库中的信息包含损伤信息内容和修理方案内容。对输入的信息，能够对其进行删除和修改等操作。

（2）数据检索查看功能

在不同模块页面中能够支持用户输入不同的条件进行单条件独立查询或多条件的关联查询功能，并能根据查询条件显示查询的结果给用户进行查看。

（3）数据输出功能

可对查询到的数据信息按照给定的格式进行编排，并能进行下载、打印、储存等形式的输出。

（4）管理技术文件

支持用户上传、下载、更新修理适航要求文件及标准规范文件等技术文件。

（5）修理数据的统计与分析

提供直观的统计图表显示界面，对机型、部件等内容的维修数据进行统计。

（6）修理方案的推荐功能

结合损伤信息的内容，按照一定的关联条件推荐相近的修理案例。

（7）用户权限管理

平台划分出三种用户角色：普通用户、管理员、系统管理员。不同角色登录后对应不同的功能页面。

2 平台设计

2.1 平台的实现技术

选择Java 语言作为该平台后端程序的开发语言，以MySQL 数据库作为后台数据库，前端和后端的开发主要在使用框架技术的基础上进行。

后端的开发基于SpringBoot 框架。同时，整合Mybatis 框架作为数据的持久层。使用Spring-Security 作为安全框架，能有效防止“注入攻击”“饱和攻击”，保证系统具有较好的安全性，同时满足用户角色分配和权限划分的业务需求。

前端的开发以Vue 框架为基础，使用Vue 官方推荐的Axios 异步交互技术实现前后端数据交互，用来发送请求、接收数据。

2.2 平台架构设计

平台的开发总体上使用B/S 架构实现。这种模式能够实现客户端的统一，使得平台功能的实现集中到服务器中，实现平台开发、使用、维护的简化，具有分布性强、维护方便、可扩展性好、开发简单、共享性强的优势。用户在使用平台时，只需要通过客户端浏览器就可以访问服务器端，客户端基本不需要进行维护。

平台中采用的B/S 架构形式为客户端—服务器—数据库，如图2 所示。

图2 B/S 架构使用的形式Fig.2 The form of B/S architecture

平台设计思路有以下三点。

（1）可扩展性和独立性

为方便平台的开发以及后期可能的功能扩展，平台中各功能模块既保持一定的功能独立性，又具有一定的数据关联性。平台中各模块之间的功能是相对独立的，它们之间通过数据内容来实现逻辑上的联系，一个模块程序出现异常不会影响其他模块。

（2）安全性

系统需要具有较好的安全性，能够有效防止注入攻击、饱和攻击等。用户注册时设置的密码要经过加密，然后再存储到数据库中，即便是开发人员也不能直接获取用户的密码内容。

（3）部署和使用方便

平台开发完成后，通过Maven 工具打包，生成的.jar 文件可以快速部署到Windows 系统的服务器上，也可以部署到其他系统服务器，如Unix、Linux 系统的服务器，具有适用于多种服务器类型的特性。同时，用户通过客户端浏览器就可以直接使用平台。

通过上述分析，对平台系统架构进行整理，平台系统架构如图3 所示。基于业务逻辑，平台架构主要分为三层：表现层、逻辑层、数据层。表现层是客户端展现给用户的界面，主要完成用户和后端程序的数据交互；逻辑层主要是处理前端发送的请求，然后按照业务逻辑对数据进行处理；数据层则负责操作数据库，写入和传出数据。三层架构体现了“高内聚，低耦合”的开发设计思想。

图3 平台系统架构Fig.3 Platform system architecture

2.3 数据库设计

2.3.1 权限划分的库表设计

数据模型是对系统实体类关系的映射。平台中与权限划分相关的实体有：用户、用户的角色、不同角色各自可以访问的菜单页面。需要通过五张表完整描述这三个实体之间的关系：用户信息表、角色表、用户角色关联表、菜单表、菜单角色关联表。表的关系模型如图4 所示。五张表分别存储用户信息、角色信息、不同用户和角色之间相关联的外键信息、菜单信息以及不同菜单和角色之间相关联的外键信息。

图4 数据库权限框架相关表的关系模型图Fig.4 Relational model diagram of related tables in database authority framework

用户通过前端页面进行登录时，向后端发送携带用户名和密码的请求，后端安全框架Spring-Security 根据前端传入的数据查询到用户信息，并通过外键关系继续得到用户角色信息，以及角色对应的菜单信息。SpringSecurity 框架会对该用户可以使用的后端接口进行授权，这就为不同的角色分配了不同的接口。同时，后端将用户信息及其对应的菜单页面信息返回前端，前端程序根据接收到的返回内容加载相应的Vue 组件即可实现不同菜单和页面内容的展示。

2.3.2 修理方案推荐功能的库表设计

不同材料结构的失效模式常常是不同的。例如飞机复合材料层合板和蜂窝加芯结构产生的损伤最主要是冲击损伤，碳纤维蜂窝夹层结构损伤多表现为碳纤维织物与蜂窝芯的脱胶离层。不同的材料和结构损伤通常有其相对应的典型修理方案，材料与修理方案的设计和工艺是紧密联系的。

因此，根据损伤信息和修理方案的内容，分别建立与之对应的数据库表。损伤信息内容主要包括：飞机型号、飞机注册号、飞机序号、ATA 章节号、飞行循环/小时、修理日期、损伤部件、结构分类、损伤成因、损伤类型、材料牌号、损伤尺寸、损伤发现方法、损伤等级以及结构描述、损伤描述、允许损伤尺寸的图文信息。修理方案内容主要包括：修理方法、修理类型、损伤去除方法、损伤去除部分的尺寸、补片尺寸、紧固件参数、胶层参数、特殊工艺、表面防护以及完成修理后的检查要求、修理图纸等。针对损伤信息和修理方案的内容特点，考虑将损伤信息中的材料信息与修理方案中修理方法相联系，建立损伤信息和修理方案关联表，对应关系由实际工程案例得到，如表1 所示。

表1 损伤信息和修理方案关联表Table 1 Damage information and repair plan association table

修理方案表、损伤信息表以及它们之间的关联表的ER 关系图如图5 所示。材料牌号与损伤信息表中内容相联系，修理方法和修理方案表中内容相联系，就可以建立数据库中损伤信息与修理方案之间的联系。用户选中一条损伤时，通过编写三个表关联的查询语句，将材料信息作为条件传入，查询得到相应的修理方案，将其返回到前端页面，就实现了根据损伤信息自动推荐修理方案的功能。在查询语句中使用条件模糊匹配，可以扩大修理方案推荐的范围。

图5 修理方案和损伤信息ER 关系图Fig.5 ER diagram of repair plan and damage information

2.4 功能模块设计

根据业务流程和功能需求的分析，将平台划分为五个模块：用户管理模块、修理数据建模模块、修理知识文件管理模块、修理数据管理模块、修理数据统计分析模块。平台功能模块结构如图6 所示。

图6 功能模块结构图Fig.6 Functional module structure diagram

系统管理员仅使用用户管理模块对管理员用户和普通用户进行管理；管理员用户可使用所有模块，并在用户管理模块中对普通用户进行管理；普通用户没有用户管理的权限，可使用其他功能模块。

2.4.1 用户管理模块

用户管理模块包含三个子模块，用户信息、用户管理、个人中心，用于实现用户注册登录、用户角色识别、用户账户管理功能。个人中心模块提供给用户对个人信息进行编辑和修改。管理员用户具有用户信息模块的使用权限，可以在该模块中对普通用户账户进行管理，包括编辑普通用户电话信息、删除普通用户账户、关闭用户登录权限等操作。系统管理员用户具有用户管理模块的使用权限，可以在该模块中对普通用户和管理员用户账户进行管理。系统管理员账户在开发过程中直接存入数据库，无法在平台页面中删除其账户，因此可有效对其他用户的账户进行管理。

2.4.2 修理数据建模模块

修理数据建模模块包含三个子模块，数据库信息模块、损伤信息模块、输入审核模块，数据库信息模块的功能是展示存入数据库中飞机结构修理相关的通用修理原则和方法。用户可以输入数据库序号、修理方法的内容查询得到所需内容，也可根据需要新增相关内容。损伤信息模块的功能为录入损伤信息，需要录入的信息与损伤信息数据库表的内容相对应。在损伤信息录入过程中，由于程序中设置了定时操作函数，页面会自动定时提交和保存已填写的损伤信息，以实现损伤信息数据的自动备份。损伤信息填写完成后，在输入审核模块的页面中会同步已填写的损伤信息，需要管理员用户进入输入审核模块对损伤信息进行审核。管理员可以先查询得到所需的损伤信息，然后再进行审核。审核后的损伤信息会被标记为“审核通过”或“审核不通过”。

2.4.3 修理知识文件管理模块

修理知识文件管理模块包含一个子模块：修理文件查看。该模块用于用户上传、更新、下载和删除修理相关技术文件。

2.4.4 修理数据管理模块

修理数据管理模块包含两个子模块：选择修理方案、查看修理方案。在选择修理方案模块中，用户可以查看系统根据损伤信息自动推荐的修理方案内容。同时，还可在查看方案的同时对每个方案进行评分，评分项包括修理效果、可操作性和经济性三方面，具体有耐久性、气动外形、功能性要求、修理成本、人员需求、修理时间、可检性、可操作性、修理效果等内容。完成打分后可以根据分数为修理方案排序，方便用户进行选择，然后由用户自行选择修理方案，用户也可以在该页面中新增修理方案。完成修理方案的选择后，进入查看修理方案模块，用户可以同时对损伤信息和对应选择的修理方案内容进行查看，并将页面中的损伤信息和修理方案信息以PDF 格式打印输出，方便使用。

2.4.5 修理数据统计分析模块

修理数据统计分析模块包含一个子模块：维修数据统计。该模块用于对不同机型和损伤部件的修理次数进行统计，并将结果以柱状图和饼状图的形式进行展示。用户可以对统计图表进行操作，例如进行图片的保存、数据导出、数据查看等。

3 测试

3.1 测试过程

登录系统后，首先进入修理数据建模模块，然后选择数据库信息子模块，在查询功能区输入相关查询条件，即可查询得到数据库中相关的通用修理方法内容，如图7 所示。

图7 数据库信息模块查询功能图Fig.7 Diagram of query function of database information module

如需新增修理方法，点击页面左下方“新增录入”按钮，在弹出窗口中填写新增的修理方法内容，填写完成后点击提交即可，如图8 所示。

图8 数据库信息模块新增录入功能图Fig. 8 Diagram of new input function of database information module

切换菜单页面，进入损伤信息填写页面，如图9 所示。用户在页面上方填写基本损伤信息，包括：方案名称、编号、飞行型号、飞机注册号等相关内容。点击右上方“基本信息录入”按钮，随后页面会显示该条基本损伤信息。选中页面列表中该条损伤信息，点击右侧操作栏中“填写损伤信息”按钮，页面打开完整损伤信息填写页面，如图10 所示。填写损伤信息描述、可允许损伤尺寸等内容，并上传损伤相关图片后，完成损伤信息的填写。

图9 损伤信息模块页面图Fig.9 Diagram of damage information module

图10 损伤信息录入功能图Fig.10 Diagram of damage information entry function

切换菜单栏，进入输入审核页面，用户可在该页面中对上一步填写的损伤信息进行查看和审核。审核结论通过后，方可进入下一步选择和查看推荐修理方案的操作。在该页面中，用户也可在查询功能区中输入相关条件对损伤信息进行筛选，如图11 所示。

图11 输入审核页面查询功能图Fig.11 Diagram of Input review page query function

切换菜单栏，选择修理数据管理模块，进入选择修理方案页面，该页面列表中会显示通过审核的损伤信息。用户选中一条损伤信息后，点击右侧操作栏中的“选择修理方案”按钮，页面会弹出根据损伤信息推荐的相关修理方案，如图12 所示。点击修理方案信息右侧“查看”按钮，用户可对修理方案详细内容进行查看，并根据修理效果、可操作性、经济性等内容对该条修理方案进行打分，如图13 所示。用户可以根据打分结果选择一条修理方案。