大型跨超声速风洞维修维护自动化平台的设计与应用
2019-08-29
(1.中国空气动力研究与发展中心高速所，四川 绵阳 621000; 2.北京航天测控技术有限公司，北京 100041)
0 引言
大型跨超声速风洞是航空航天飞行器在定型和发展阶段进行气动试验的重要设备。随着空气动力学技术的不断发展和飞行器研制水平的提升，大型跨超声速风洞试验模拟能力日益精细，试验设备向着更复杂、更智能、更集成的方向发展，相应的维护保养要求不断提高，维修专业化程度不断加深，原有维修维护管理水平急需提高[1-3]。同时，随着国家对航空航天领域的大力投入，风洞试验种类、试验频次均有大幅度提升，如某型跨超声速风洞全年试验车次就超过设计车次的3倍。大型跨超声速风洞长周期满负荷高强度运行成为常态，对设备安全稳定持续运行的要求越来越迫切，维修维护工作量急剧增加，维修维护的技术水平要求越来越高，维修响应时间要求越来越短，同时，维修人员还在不断缩减。传统依靠人工发现，人工申请和审批的维护维修管理模式和方式难以适应现实需要[4-6]。
为了提高大型跨超声速风洞维修维护的自动化水平，减少人力资源投入，精准开展维修维护工作，加强管理效果，开发了一种基于B/S构架的维修维护平台。该平台立足高速所已有的办公综合管理系统，以现有人员和组织机构为基础，利用设备台账数据库，将参与风洞试验保障的设备进行统一管理，梳理维修维护过流程，优化管理流程，利用自动化平台的特点和优势，更好地为风洞试验提供有效保障。
1 平台技术架构设计
根据项目情况，平台设计采用通用的分层架构，具体技术架构如图1。
图1 平台基本架构
1.1 表示层
UI是客户端的用户界面，负责从用户方接收命令、请求和数据，将其传递给业务层进行处理，然后将结果以直观的形式呈现给用户。表示层中为了使用修改和保证页面的一致性，结合MasterPage和WebUserControl使用。MasterPage的使用原则为：一般情况下，所有页面继承于主要的MasterPage，各个模块中，如变化较大则使用子模块的MasterPage，如只为局部变化，如子模块菜单变化则使用WebUserControl来实现。
WebUserControl使用原则为：在两个以上的地方使用的部分，采用WebUserControl。如子模块菜单、常用查看视图等。
1.2 业务层
业务层封装了实际业务逻辑，包含数据验证、事物处理、权限处理等具体业务实现的相关操作，是整个应用系统的核心。在业务层中，不能直接访问数据库，而必须通过数据访问层。对数据访问业务的调用，通过接口模块IDAL来完成，与具体的数据访问逻辑无关，层与层之间的关系就是松散耦合。如果需要修改数据访问层的具体实现，只要不涉及到IDAL的接口定义，那么业务层就不会受到任何影响。业务层模块结构如图2所示。
图2 业务层模块结构图
1.3 数据访问层
数据访问层是一个针对具体应用系统的专属层，它为业务层提供与数据源交互的最小操作方式，仅仅是业务层需要的数据访问接口，业务层完全依赖数据访问层所提供的服务。这些服务负责从业务层接收数据或返回业务实体，它屏蔽了实际业务数据与机器存储方式的差别。
图3 数据访问层模块结构图
在数据访问层(DAL)中，采用DAL 拉口抽象出数据访问逻辑，并以DAL 工厂作为数据访问层对象的工厂模块，而Model模块则包含了数据实体对象。数据访问层的模块结构如图3所示。
IBaseDAL是定义的数据访问基类接口，包含各种常用的操作定义；因此BaseDAL就是要对各种操作的进行实现，实现接口越多，将来继承类的重用程度就越高。通过泛型
1.4 数据实体对象
Model是将数据库中的表直接映射成为业务数据对象，出于复用性，扩展性，性能等方面考虑，选用Model建模。实体层定义一个空的基类，其他实体类继承之，主要是为了利用泛型操作。
1.5 数据层
数据层就是为数据源提供一个可供外界访问的接口，我们选用一种能够提供数据源无关的抽象数据访问接口，并通过在其下挂接各种不同的数据接口来访问数据源的数据层组件，以便移植到不同的数据源上。
1.6 公共部件
公共部件包括图片上传控件、消息对话框、分页显示控件、信息检测等公共模块。同时每个层根据需要建立工具类Common，用来处理整个系统公共部分。
2 系统主要功能设计
2.1 维护规范
维护规范是各类装备的维护规则数据表，由装备使用单位根据装备特点、出厂说明书、使用经验等制定。维护规范包含了装备名称、维护周期、维护器材、维护方法等全部内容，主要分为日常保养、一级保养、二级保养三类[7]。
日常保养由操作者进行的日常维护保养工作，包括擦拭设备、注油保养、润滑清洁、紧固松动部位、消除细小故障等。一般周期为每天或每班次进行。
一级保养以操作工人为主进行，维修人员负责指导，按计划对设备进行定期或定频的维护。内容包括局部拆卸、检查、清洁、调整配合间隙、紧固部位等。一般周期为3～6个月。
二级保养以维修工人为主、操作工人参加的定期或定频维修，内容包括对设备进行局部解体检查更换修复少量磨损零件、局部精度恢复，对润滑系统清洗、换油等。一般周期为6～12个月。
三类保养的活动将记录到检查记录中，该记录以设备的标识为索引，可在台帐管理模块对某些设备的保养信息查询。具体保养周期可以根据设备情况进行修订，修订后在维护规范中进行更新。
2.2 维护计划
维护计划是根据维护规范自动生成的，可显示当天、当月、当季、当年各装备的各级维护保养计划，同时可以自动导出不同周期要求的计划表格。各单位可以实时查看维护计划的执行和完成情况，上级部门可实时统计整个部门的维护情况。
2.3 维护预警
维护预警是对即将或者已经到期的维护计划进行提醒和消息推送，例如当二级保养时间还剩15天，二级维护使用频次低于5%时，由系统将该部分作为预警信息推送到相应负责人或操作者的账户中，提醒相关人员及时维护。如果已经过期的维护计划超过一定比例，还可以设置推送到其主管上级部门。
2.4 故障记录
故障记录来源主要有3个方面，一是各装备自身故障诊断系统判断出的故障，通过统一的接口连接到平台上；二是装备在使用过程中，由于性能、运行、测试等低于预期值，由平台判断为最终系统故障的；三是由操作人员发现，通过平台的手动标记的故障。
2.5 维修申请审批
维修申请审批模块主要是完成大、中、小、临时性维修的申请，流程审批等。装备出现故障时，由对应人员填写设备维修申请单。维修申请表根据用户权限和角色自动提供其所在单位内设备清单，当用户选择设备后，自动从台账导入其他信息。申请人、审批人等能够实时查看审批流程和走向。申请、审批人权限根据具体规则制定，任何一级审批人未审核通过此次申请流程结束，超级管理员能够管理人员权限和流程。维修申请时，调入台帐中的设备维修历史信息、存在资源等，供决策参考。
2.6 验收结算
验收结算主要实现维修维护的验收，耗费材料和经费的统计，以及对维修维护效果的评价。
3 接口设计
3.1 软件内部接口
维修维护自动化平台以设备基本信息为基础，主要分为维护保养和维修两大部分。其中维修模块主要立足设备的名称、功能、所属单位、历史维修信息、价值、厂家等常规信息，调取设备基本信息库的内容。维护保养立足维护规范模块构建的基本规则进行数据读取和生成，同时维护规则也是设备基本信息库中包含的一个部分。因此与设备相关的所有数据均保存在数据库中，通过索引方式可查找所有相关信息。
自动化平台中的各种审批及入库流程由流程引擎接口实现，该接口能够满足新增、删除及上报审批等过程。
3.2 软件外部接口
自动化平台的外部接口包括：风洞试验运行接口、设备故障自诊断接口、设备状态接口、办公综合管理系统接口[8-10]。
风洞试验运行接口包括试验设备的状态，包括：中压气源实时信息、高压气源实时信息、试验时间、试验次数、试验持续时间等。其中获取的风洞运行次数可以驱动维护保养流程。
设备故障自诊断接口包括：智能设备的故障诊断信息，安全系统预定的逻辑推理故障，风洞建立的健康管理系统得到的故障状态、预测曲线、维修决策建议等。
设备状态接口是为了对维修维护的过程信息进行自动识别，避免手动操作而设置的一类硬件信息读取记录，既可以是设备本身自带的，也可以是RFID监控信息等。如将部分电器设备的通电运行与日常维护相结合，将部分机械的运转信息与一级保养相结合，将关键部件的拆卸或口盖开启信息与二级保养相结合，当对应的事件发生或信号传递时，平台自动记录相关的操作，并视为相应的维护已经发生，实现智能化。
办公综合管理系统提供了人员和组织机构的基础信息，供自动化平台直接使用，包括部门信息、用户信息、角色权限、日志等。实现单点登录信息接口，辅助完成登录用户的认证。
外部接口根据实际需要和系统成熟度开放不同权限，如对用户和部门信息提供只读权限，平台不能修改；对设备的故障诊断信息和健康管理系统开放故障报警、维修建议、故障消除等的读写权限，可根据当前维修流程执行结果自动更新系统状态。
4 运行界面
软件界面设计总体要求是友好、简洁、方便。使用人员不需要操作培训和用户手册就能快速上手使用。软件页面布置和主要控件外观形式与原有管理系统和日常办公软件风格保持一致。软件界面具有操作自动提示功能，对重要内容或参数在输入错误时，进行简洁的提示，方便操作人员及时改正。平台运行主界面和操作界面分别如图4和图5所示。
图4 平台运行主界面
图5 平台操作界面
在自动生成的维护计划和故障列表中，具有权限的操作人员可以进行添加、删除、修改等。在显示详细内容时，以列表的形式进行，列表字段可以由系统管理员进行配置。系统管理员可以按照固定格式批量导入或导出数据。所有需要用户修改定制的内容均提供界面或接口，不允许用户直接修改或查询数据库，容错机制设置合理，即使由于用户误操作也不会造成数据丢失和系统崩溃。
5 平台开发
维修维护自动化平台使用SQL Server 2008数据库，开发环境采用Visual Studio2012，开发语言采用C#。数据库与系统部署于统一的服务器上，采用B/S架构，各个用户均可使用浏览器通过内部网络进行访问和操作[11-12]。其业务申请流程设计如图6所示，数据库设计如图7所示。
图6 业务申请流程图
图7 数据库设计图
6 结果与分析
平台建成后，在部分用户中进行了前期测试和试运行，测试涵盖了全部用户角色，模拟了所有工作流程，并进行了20名用户的并发处理。经过试运行后，结合反馈意见，对相关流程进行了优化，修改程序Bug共150处。正式上线运行后，具体性能指标见表1，2018年维护计划及完成情况见表2，设备具体维修记录见图8。
通过自动化平台，建立了346套分系统的三级维护规范，每年生成维护计划超过6000余次，推送维护预警信息545次，确保了维护的及时性，避免工作疏忽和遗漏。其中，通过设备状态接口自动识别的维护工作占40%，平台的自动化功能完善，符合要求，但由于系统设备自身硬件限制，自动化程度还有很大的提升空间。
表1 系统性能指标情况
表2 2018年维护计划及完成情况
图8 设备维修记录
平台运行以来，处理维修申请381条，通过外修并完成验收185条，自修并记录116条。设备故障自诊断接口传送的装备故障信息[13]，将风洞维修由人工事后填报转变为自动提前发现，大大提升了智能化水平。同时，维修自动化平台将设备故障自诊断接口传输的故障自动生成维修申请，主动发起维修审批流程，实现故障诊断、故障记录、维修审批的一体化，提高了大型跨超声速风洞维修维护的自动化水平。
7 结束语
大型跨超声速风洞维修维护自动化平台立足现有的管理流程和使用模式，借助信息化工具，通过对信息采集、传输、交换和分析，以系统消息和可视化界面，实现了维修维护的自动登记、记录、提醒和统计。利用信息化的手段，使维修维护的检测手段更加先进，在大型风洞中，实现了根据使用时间和使用频次相结合进行维护保养的新模式。但是，在维修维护的自动化过程中，部分操作依赖外部接口传输的数据，特别是在维修维护过程和维修维护记录中，部分老旧设备不能提供准确有用的信息，通过配置单独的信号检测设备将增加系统成本，而通过人工进行登记又会降低自动化水平，在下一步工作，将探索两者之间的平衡关系。同时，随着健康管理、智能故障诊断的系统的不断发展，如何将平台信息与这些系统进行有效连接，互为补充、互相促进，也是下一步研究重点。
