汽车车辆维修定检设备管理系统的设计与实现

2022-11-27晋东海

设备管理与维修 2022年20期

晋东海

（大庆油田有限责任公司试油试采分公司，黑龙江大庆 163000）

0 引言

随着我国汽车市场的不断扩张，汽车车辆的故障维修定检工作面临巨大的信息管理问题。通过车辆维修定检设备管理系统解决信息混乱、丢失和不透明问题，是现阶段汽车市场竞争的重要手段。基于此，重点对汽车车辆维修定检设备管理系统的系统模块、信息管理模块、车辆维修项目管理模块和故障信息管理模块等进行研究，以期设计出具有高度自动化与科技化的管理系统。

1 系统技术架构设计

汽车维修定检管理系统设计目的在于解决海量汽车维修数据信息的存储、查询，实现车辆维修的高度简洁性。例如维修客户信息中涵盖的客户信息、车辆维修信息、阶段性信息处理和反馈信息等都需要进行记录与管理，若使用人工方式对上述信息进行管理，会造成极大的工作内耗，阻碍汽车维修定检行业的发展。围绕该问题设计车辆维修定检设备管理系统，主体架构建立在对实际行动分析的基础上，对比各技术应用与架构的优劣势，结合实际业务对系统功能的需求，最终明确系统设计的主体技术架构。针对车辆维修定检设备的管理系统设计，利用B/S 多层架构模式对系统架构的多重框架进行开发[1]。

由表1 功能层设计架构可知，架构的第一层为客户端层，第二层与第四层为服务器层，第三层为数据库层，以此3 层架构为出发点细化各层的其他功能模块。在系统框架中，表层属于面向客户与操作人员的用户界面层，该部分以Web 浏览器为主，重要技术为界面优化与数据调用，因此不对该层进行过多叙述。因数据层与基础信息层可以通过已有数据库的方式解决，所以也不对该部分进行过多叙述。

表1 系统的各层功能框架

系统模块属于整个车辆维修定检设备管理系统的骨架，所有子系统皆在该模块上实现。考虑到该系统的服务对象大部分为车主及客服人员，因此该设备管理系统的用户操作界面应当具有一定的交互性与简洁性，应贴近实际且符合人们对常见操作系统控制的习惯。该模块应当具有高度逻辑转换性，即能够实现将各模块下不同数据的逻辑模型转换成虚拟的物理模型，该部分需要通过B/S 实现数据模块的分级。

以服务层为例，该系统的设计需要将服务层拆分为基础信息管理模块、车辆维修模块和故障信息管理模块，在各子模块中需要明确该部分设计解决的问题，为解决该问题需要构建的主要功能，例如在信息管理模块中要解决的核心问题是如何实现长期用户与短期用户信息的分别与管理[2]。

2 系统服务层的模块细化设计

2.1 基础信息管理模块设计

该部分设计主要是实现汽车维修部门、维修人员、客户和维修基础配件等数据的管理。在服务层框架设计中该部分的设计主要解决信息收集问题，例如部门信息、人员信息、客户信息和车辆配件信息等，通过该模块的综合应用才可以促使整个系统设计的顺利进行。该系统基础信息的设计应当更多体现在页面布局与层次布局上，通常情况下，完善基础信息是为系统后续数据整理提供更高效的服务。

在汽车维修定检设备管理系统设计中，基础信息管理的需求设计应当满足以下原则：①实现用户登录管理，即客户可自主进行次要信息的记录登录和用户开户、注销等功能；②可实现用户行为的自管理，即系统需要对用户的每一步操作进行行为习惯记录，例如车主在系统中挑选维修部件时经常浏览的价位与材料等信息的记录[3]；③应具有日志数据管理能力，通过该功能帮助客服人员对用户车辆维修数据变化情况进行及时记录，实现数据的可追溯、可分析与可恢复等功能。

为此，基础信息模块下需设立3 个子系统模块，即部门管理模块、维修人员管理模块和车辆维修配件管理模块。在用户界面操作人员可通过点击的方式实现对上述信息的查询与管理，但为保障系统数据的安全性需要对操作ID 进行权限限制，避免非管理人随意篡改用户信息。

2.2 车辆维修管理模块设计

该模块主要为满足车辆维修定检管理系统下针对维修信息的存储与调用而设计。在该管理系统中因涉及维修车辆品牌与型号众多，若没有科学的用户信息管理路径设计，会造成整个系统数据调用的高度延时。该管理模块的设计应当满足对车辆维修项目、维修车辆型号和维修车辆故障信息等的划分功能，确保系统具有较高的数据存储与调用性能，在保障用户数据信息安全的前提下实现数据的高速调用。

从实际功能设计角度出发，车辆维修管理模块的设计理念需要围绕车辆维修的各项数据产生点进行管理，例如活动的名称、种类和单价等信息，帮助客户实现对不同维修项目各项参数的自主选择，减少实际维修环节针对如维修材料、配额、组合和人工等信息的询问时间，即在客户端界面上即可实现对车辆维修各项参数的登记，提交后只需在规定时间内将维修车辆送至维修工厂或通知工厂收取故障车辆[4]。该部分主要可分为2 个子系统：①用户维修车辆信息填写系统：主要包括维修车辆类型、故障原因、更换材料和价格等；②附加服务信息填写系统：主要包括是否需要道路救援、是否加急、是否进行车辆改装和会员服务等。当车辆已经开始进行维修时，系统对客户账号发送维修单，客户可通过维修单上的编号查询车辆的实际维修情况，该部分的主要流程如图1 所示。

图1 系统设计流程

2.3 故障信息管理模块设计

在该模块中，一旦车辆出现任何故障都可通过该模块功能实现相关信息的上传与查询。为实现该模块的相关功能，需要根据其他不同子系统的权限和数据设计不同接入端口，同样在用户操作界面需要保证操作界面的整洁，在保证较高的操作兼容性需求下实现最简洁的操作设计。

故障信息管理模块需要设计故障登记与查找两大子系统，主要涉及对维修车辆的故障编号登记、故障名称登记、助记码生成与分发和故障现象登记等。维修项目主要涉及故障登记单的相关信息填写，例如不同地区的故障维修项目、工单号、初次维修时间、检修具体故障、客户名称、车牌号和车型等信息记录[5]。整个模块的相关信息皆需要由维修定检单位的工作人员填写，客服与客户均可通过上述方式对车辆维修故障登记单与维修项目等信息进行查询。该模块还可成为维修部门与客户之间沟通的介质，维修部门通过将维修信息上传至平台中实现故障公开化，而客户可通过平台上的信息实现对维修各项要求的更改，例如更换更贵的替换件或其他需求等。

3 系统测试

在所有功能模块均已设计完毕且实现对接后，需要通过不断输入模拟信号的方式对功能模块的本体与系统整体进行检验，以验证从系统登录到车辆维修定检流程，即项目相关信息完成分类封存后系统功能的流畅性。在测试单个功能模块时需要对每条输入信息的记录模式与实际输出进行详细记录，在综合考察中对比系统输出结果，若单独测试与整体测试输出结果不同则需要重新调整系统参数；如果系统运行时遇到与预期设计功能不符合的模块，同样需要修改参数并不断进行调试，直至测试结果数据完全符合预期设计要求。

系统功能测试环节不但要输入大量合理数据以增强车辆维修定检设备管理系统的设计可行性，还需要输入少量不合理数据，即误差数据，以验证系统在处理大量数据信息时的纠错能力与故障后的应急反应能力。所有功能结构通过测试后皆需要进行一段时间的试运行，通过实践找出系统运行中存在的技术漏洞，从而完善整个车辆维修定检管理系统。功能测试范围如表2所示，性能测试范围如表3 所示。