一种城轨车辆电子履历数据处理方法与流程

1.本发明涉及城市轨道交通信息管理领域，尤其涉及一种城轨车辆电子履历数据处理方法。


背景技术：

2.地铁车辆履历包含了大量、重要的基础信息，记录了地铁车辆及重要零部件从采购、组装、运用、检修到更新改造全过程的重要数据及技术状态，是地铁车辆检修、运用管理和技术分析的重要基础和依据。相较于一般的信息管理系统，地铁车辆履历管理系统具有信息来源广、数据量大、冗余度高等特点，这就要求系统能够更规范合理地记录、保存、运用车辆信息，避免出现信息不完善、不正确的问题。但是，由于以往的履历管理工作中存在着计算机技术不成熟、操作规范不清晰、职工思想不重视等问题，车辆履历信息得不到妥善的管理，产生了信息异构、信息无法形成闭环、信息利用率不高等问题。随着地铁检测、管理、维修、评估等技术的迅猛发展和地铁运营规模的不断扩大，这些问题愈发凸显，成为制约地铁行业发展的重要因素。
3.目前，对地铁车辆履历信息一般都是采用电子表格，手工登记录入，且数据信息零散，具体存在以下问题：
4.(1)数据不完整，缺乏标准：地铁最初的规划建设基本以线路为单位，各线路自成体系，不同阶段的建设厂商、设备厂家、建设技术等都不同。这两方面因素使得系统之间、线路之间存在大量异构的履历信息，由此产生了线路间的信息孤岛与信息异构问题，不利于履历信息的存储及应用。内容的样式、格式是不一致的。尤其是元数据项和分类不统一，没有按照统一的分类体系标准和元数据标准对履历信息进行有效的梳理和组织。
5.(2)数据量大：在现单位存储了大量的履历信息、相关信息及动态、历史记录等数据资源，且随着数据采集量的不断攀升，数据量也会越来越大。
6.(3)数据筛选与更新难度很大：由于现在履历信息多以纸质方式采集、管理这就给信息的采集造成了很大的困难；另外，数据的更新也是一个的问题，如人事变动，没有及时采集、更新导致信息不准确的情况。
7.区块链技术可为轨道交通系统边缘计算网络构建系统性的安全防护机制，保障网络安全和数据安全。现有技术中，区块链技术在轨道交通方面的应用包括：1)融合区块链的轨道交通边缘计算网络安全防护机制；2)区块链在城轨二维码互通中的解决方案；3)通过建立统一的区块链合作协议，并将账户和业务环节授权上链，可以实现互联互通业务的去中心化和乘客服务的简便化等。


技术实现要素：

8.为了解决上述技术问题，本发明综合利用区块链、数据库等技术，研究并提出基于区块链技术的地铁车辆电子履历数据处理方法，可以解决车辆履历全生命周期数据精细化、规范化、标准化问题,同时实现可追溯、可共享，提升数据利用价值，增强工作严谨性，以
实现智慧地铁建设和企业数字化转型的总体目标。本发明具体采用如下技术方案：
9.一种城轨车辆电子履历数据处理方法，该方法包括如下步骤：
10.(1)建立城轨车辆电子履历数据资源库
11.建立基础数据库，各类信息数据经过采集、安全检查、基本校验处理后存入基础数据库；
12.建立共享库，用于存放各业务系统公开权限的各类信息，供用户进行跨系统的信息利用；
13.建立交换数据库用于本系统与外围系统之间的数据交换；
14.建立系统管理库，用于运行本系统的系统管理平台；
15.建立履历资源目录库，用于存放业务目录、管理目录以及机构目录信息；
16.建立元数据库，用于管理数据与数据之间，数据与业务之间，系统与系统之间的对应；
17.(2)履历数据处理
18.基于用户收集到excel、word、pdf等格式文件，利用信息化技术、全文检索技术及结构解析技术，实现目标数据识别、序列化处理、与非结构数据关联、存储、构建查询索引等功能，在满足用户基本查询和统计分析功能的基础上，逐步形成知识库；
19.(3)履历数据上链存证
20.地铁车辆电子履历相关业务数据在上链前，通过哈希算法对业务数据进行哈希处理，然后采用加密算法对哈希值进行数字签名，并增加时间戳；
21.业务数据经过上链前处理之后，被转换成区块链可读的方式，处理完成的数据发送到区块链节点后，形成区块链交易并进入上链处理的阶段，各节点在收到交易后，通过共识算法，形成新的区块；
22.数据上链处理完成之后，履历相关业务数据记录在链上，地铁公司、运分公司等各个节点完成访问区块链上记录的数据。
23.优选的，建立所述履历资源目录库的具体方式如下：
24.(i)确定履历数据类型
25.地铁车辆履历信息包括基础数据、设计数据、生产数据、装配数据、运行数据、检维数据、故障数据、组织用户；
26.(ii)履历资源目录建设
27.首先依据车辆厂商交付的车辆bom物料清单，结合维修能力和管理精度进行识别和重构，具体分为两个步骤：
28.一、地铁车辆基本构件编制
29.1、从车辆厂商处获取的交付bom进行构建初始化，通过车辆履历定义的模板进行导入，或根据系统初始化车辆基础节点进行定义和参数设置；
30.2、节点属性定义：根据不同部件进行节点元数据定义，包括基本信息、静态技术信息和配属动态；
31.3、节点遍历：定义好当前节点属性后，开始逐层、逐级进行遍历识别；
32.4、节点判定：对当前节点进行是否“拆分、不拆分和不管理”判定，当单元结构与交付bom中的对应结构不一致时，通过节点管理进节点进行删除、修改和细化结构；
33.(1)拆分，继续对当前节点的下级进行识别定义和属性完善，进入下一个循环；
34.(2)不拆分，在地铁车辆结构中只保留本节点并信息；
35.(3)不管理，在地铁车辆结构不做记录；
36.5、是否遍历完成，对“基本构件层级”的构件是否识别完成，如果完成进入最小管理构件阶段，否则循环进行识别定义；
37.二、地铁车辆最小管理构件编制
38.1、识别构件类型，所述构件类型分为替换件、拆分件、检查点，根据管理维度进行对本节点构件进行识别和属性定义；
39.(1)替换件，能够进行相互替换的同类型不同产品的构件；
40.(2)拆分件，相同的构件但所处位置不同；
41.(3)检查点，需要进行检查，但不属于替换或拆分件的构件；
42.2、是否遍历完成，对所述最小管理构件的构件是否识别完成，如果完成则地铁车辆构件树完成编制，否则循环进行识别定义。
43.优选的，所述步骤(3)中履历数据上链存证还包括如下具体方式：
44.上链数据覆盖地铁车辆立项、设联、监造、验收、运营、报废的全生命周期，按照上链数据类型区分，包括车辆基本构型数据、车辆状态信息、运营维修数据、相关文件资料，针对所述上链数据上链存证，实现产品质量信息有效追溯，上链具体数据如下：
45.设备出厂验收类数据：基础信息、技术参数、验收过程、验收规则、质检报告、验收报告；
46.技术文件类数据：技术条件、计算报告、试验大纲、试验报告、检测报告；
47.整车信息类数据：技术参数、产品配置清单、配属动态、车辆走行公里、车辆质量信息、更新改造记录；
48.主要零部件信息：基本信息、主要技术参数、资产配置动态、零部件动态；
49.检测信息类数据：检测动态、检测记录、试验记录、试运记录、破损记录、特别记载；
50.维修类数据：维修动态、试运行记录、技术提升记录、特别记载、更新改造记录。
51.本发明具有如下有益效果：
52.(1)根据列车检修运营规范和地铁运营经验，结合车辆结构设计建立了车辆运营构型，并利用数据库技术进行车辆构型数据结构化；采用细化至最小可维护单位的车辆履历数据颗粒度，通过基于业务流程的数据分析和集成技术保障数据的正确性和及时性，提高地铁车辆基础数据的利用率。
53.(2)利用数据存储技术存储车辆全生命周期阶段文档资料，结合全文检索技术建立初步的车辆知识框架，为后期地铁车辆的采购、技术改造、运营提供基本数据支撑。
54.(3)充分利用地铁公司数据资源，建设地铁车辆履历可视化能力，创建地铁车辆知识体系，真正实现数据可视化、车辆(基本、运行、决策)知识共享(功能)。
55.(4)在履历数据管理中加入区块链技术，基于ssl机制对在网络上传输的数据进行加密、认证，确保数据流的机密性和完整性，以防敏感数据在传输过程中被泄漏及篡改，从软件架构和数据管理功能实现两方面，加强车辆履历数据安全性、正确性，为后续履历共享提供可靠的数据安全保障。
附图说明
56.图1是数据集成关系示意图。
57.图2是地铁车辆数据类型图。
58.图3是地铁车辆履历数据目录建设流程图。
59.图4是地铁车辆电子履历数据图。
60.图5是履历数据上链存证流程图。
61.图6是电子履历数据处理流程图。
具体实施方式
62.1履历资源库
63.地铁车辆履历数据资源库是将地铁车辆基础信息和主要关联的重点地铁车辆运营相关的专题数据，及对地铁车辆相关资源数据的进行统一规划、统一管理，解决地铁车辆履历数据分散和不统一的问题，实现数据的有效共享和利用。
64.1.1数据资源库建设
65.资源库以业务应用为基础，通过数据平台的建设，使系统的需求得到满足。但数据资源数据库的数据并不是将基础数据进行简单的叠加、汇总，而是将这些数据按照各业务分类、按照业务关系进行重新组合，使其更适合于对数据的深层次利用和查询。
66.业务分布处理、数据集中管理是当今系统建设的一种主流模式。这种模式既满足了系统对“数据的稳定性、安全性、完整性、一致性”等原则的要求，又满足对应用系统“灵活性、个性化、易扩充性”等原则的要求。
67.数据资源数据库的建立将解决四个“统一”的问题，即“统一的数据平台、统一的数据接口、统一的数据通道、统一的数据管理”。统一的数据平台就是为各种数据的访问、交换、使用提供一个数据体系标准；统一的数据接口就是系统与外围其他系统之间的数据交换、共享必须符合数据标准，通过统一的数据接口体系进行；统一的数据通道就是数据平台沟通了各应用系统、各部门之间的关系，使批系统构成了一个统一的新系统；统一的数据管理就是集中数据资源，并进行统一的数据管理。通过先进的文本、数据挖掘技术，构建数据中心，实现效率和效益的协调。
68.1.2数据资源库总体设计
69.车辆履历数据资源库的设计既要考虑现有数据资源的利用，又要能支持全域数据的总体规划，建立全域范围内的稳定的数据模型。总体数据规划要解决信息资源规划和协调，最大程度地提高数据的共享、降低数据的冗余、减少数据接口，提高数据环境集成，数据集成关系如图1所示。
70.1.2.1数据资源库的分类
71.本发明的数据支持环境的数据按使用的技术分为数据库数据、文件数据和数据标准。数据库数据指以数据库形式存储和管理的数据；文件数据是指以文件形式存储和管理的数据；数据标准指数据管理的标准化内容。
72.1)数据资源库数据
73.从数据库的组织形式看，数据库数据是对平台的日常操作、信息服务提供支持，实现应用的查询、数据管理、数据服务、统计分析等功能。
74.2)文件数据
75.文件数据是以各种文件形式存放的非结构化的数据资源。系统采用xml技术的文件型的数据同数据库数据一样有了一定的格式描述，并且是支持变长记录格式，从而增强和方便了对交换数据的处理。
76.3)数据标准的内容
77.信息系统集成的基础是数据集成，而数据标准化是数据集成的保证。数据标准内容包括数据元素标准、信息分类编码标准、数据库标准和交换数据标准等。
78.1.3资源库建设方案
79.构造最优的数据资源库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求，主要功能目标如下：
80.1)各种查询：包括各种数据资源与文件查询等；
81.2)数据管理：包括应用系统的数据管理(增删改)、数据标准、基础配置数据的管理等；
82.3)数据服务：主要是以数据接口体系的形式，在本系统内部以及与外围其他系统之间进行数据共享、交换，提供各种数据服务；
83.4)实现与基础配置数据的关联：包括与资源目录数据、元数据等基础配置数据进行关联，形成一体化的数据环境。
84.1.3.1履历资源库设计
85.建立一个完整的、系统的数据资源的管理体系，主要内容有：
86.1)统一存储：把目前分散的数据集中到一起，进行妥善保存和统一管理，提高数据的利用价值。
87.2)形成体系：把各类数据按照一定的逻辑关系组织起来，使之整体化、系统化，形成一个完整、有序、严谨的数据体系，并编制详尽的数据资源目录库。
88.3)标准规范：所有数据必须遵循一个统一、规范的标准体系，实施统一的业务指标、业务分类及其编码。
89.4)全程管理：对数据的采集、检验、整理、分类组织、交换、维护、存储、使用和发布等全部流程进行标准化设计和有效管理，确保各个环节的有序衔接，不留管理真空和制度空白。
90.1.3.2履历资源库描述
91.本发明资源库的构建以数据资源为基础，具有整体性、逻辑性，形成了一个有序、严谨的框架。
92.本发明主要建设的数据库如下：
93.1、基础数据库：数据库是系统的基础，是系统的核心。各类来源的信息数据的数据经过采集、安全检查、基本校验等处理后存入基础数据库。
94.2、共享库：为保证数据共享的效率，建立共享库。共享库主要存放各业务系统公开权限的各类信息，供用户进行跨系统的信息利用。
95.3、交换数据库：为实现更为灵活、安全的数据交换，建议设立交换数据库。交换数据库主要负责本系统与外围系统之间的数据交换，存储两类数据：
96.(1)需要提交给其他系统的数据；
97.(2)从其他系统得到的数据。
98.交换数据库可以是独立的数据库，也可以和其他数据库在同一个物理库中作为临时表存在。
99.4、系统管理库：运行本系统的系统管理平台，属于基本配置库。
100.5、履历资源目录库：为了提高对数据的利用和管理效率，设立信息资源目录库，该库将存放数据的业务目录、管理目录以及机构目录等信息。通过在信息目录的正确位置读取(或更新)数据，可以简化系统内部查询信息的步骤。
101.6、元数据库：元数据是关于数据的数据，具体可分为业务元数据(businessmetadata)、技术元数据(technicalmetadata)和操作元数据(operationalmetadata)。管理数据与数据之间，数据与业务之间，系统与系统之间的对应，便于技术人员和业务人员理解和使用数据库中的信息。
102.1.3.3履历数据类型
103.地铁车辆履历信息包括从设计到建造、再到运行、维修、更新、改造的全生命周期内的数据，总体来说，地铁车辆全生命周期数据可以大体分为八类(如图2所示)：(1)基础数据、(2)设计数据、(3)生产数据、(4)装配数据、(5)运行数据、(6)检维数据、(7)故障数据、(8)组织用户等
104.其中(1)、(2)、(3)属于静态数据，它们描述的是地铁车辆本身的固有性，处于相对稳定的状态，基本不会发生改变。(1)主要是为整个地铁车辆的设计提供数据支持；(2)主要描述了地铁车辆的物理信息，包括车辆的长宽高，最大客容量等；(3)主要提供地铁车辆在生产过程中需要的信息，包括所需员工人数，制造环境参数等。(4)、(5)、(6)、(7)属于地铁车辆在投入使用后的数据。包括地铁列车在运行过程中所属的状态，如列车时速、传感器参数等；还有在列车发生故障后进行维修的内容。(8)属于管理数据。
105.总之，地铁车辆履历信息的数据类别多样，并且横跨周期长。要掌握地铁车辆的完整的履历信息，需要从设计到运行再到维修进行一条线的数据跟踪和记录。
106.1.3.4履历资源建设方法
107.地铁车辆资源目录建设从轨道车辆运营维度入手，通过地铁车辆维修bom的组织模式分析，建设地铁车辆的构型bom资源目录。地铁车辆履历数据目录建设流程如图3所示。
108.首先依据车辆厂商交付的车辆bom物料清单，结合维修能力和管理精度进行识别和重构，具体分为两大步骤：
109.一、地铁车辆基本构件
110.基本结构为地铁车辆通用结构节点，如一级为整车；二级车体、车辆外设部件、车辆内部设备等；三级为二级的下级结构，如车辆内部设备包括车内布置、车窗等，根据实际情况对基础结构进行层级定义，初步定义为三级结构，流程如下：
111.1、从车辆厂商处获取的交付bom进行构建初始化，可以通过车辆履历定义的模板进行导入，也可以根据系统初始化车辆基础节点进行定义和参数设置。
112.2、节点属性(参数)定义：根据不同部件进行节点元数据定义，主要包括基本信息、静态技术信息和配属动态。
113.3、节点遍历：定义好当前节点属性后，开始逐层(同级节点)、逐级(下级节点)进行遍历识别；
114.4、节点判定：对当前节点进行是否“拆分、不拆分和不管理”判定。当单元结构与交付bom中的对应结构不一致时，可能通过节点管理进节点进行删除、修改和细化结构；
115.(1)拆分，继续对当前节点的下级进行识别定义和属性完善，进入下一个循环；
116.(2)不拆分，在地铁车辆结构中只保留本节点并信息；
117.(3)不管理，在地铁车辆结构不做记录。
118.5、是否遍历完成，对“基本构件层级”的构件是否识别完成，如果完成进入最小管理构件阶段，否则循环进行识别定义。
119.二、地铁车辆最小管理构件
120.最小管理构件单元根据实际工作要求，对车辆的当前部件进行精细化结构管理，流程如下：
121.1、识别构件类型，分为“替换件、拆分件或检查点”，根据管理维度进行对本节点构件进行识别和属性定义(名称、编号、备品备件编号、层次等显性或隐性基本属性)；
122.(1)替换件，能够进行相互替换的同类型不同产品的构件；
123.(2)拆分件，相同的构件但所处位置不同；
124.(3)检查点，需要进行检查，但不属于替换或拆分件的构件。
125.注：所关注的单元在使用全寿命周期里的扩展属性都在维修节点上进行定义；同时，部分循环复用件在使用全寿命过程存在多次修和和跨线路周转情况。实例化管理实现了对具体维修单元的使用全寿命周期管理；从地铁车辆资产来看，同一车型的车辆通常是批量采购并且共享备品备件库存。
126.2、是否遍历完成，对“最小管理构件”的构件是否识别完成，如果完成地铁车辆构件树编制完成，否则循环进行识别定义。
127.1.3.5逻辑结构设计
128.数据库逻辑结构设计由概念模型向具体的数据模型转化的过程，即按照概念结构建立，将其转换成管理系统所支持的逻辑模型。
129.首先进行地铁车辆履历管理系统概念模型的初步转换，将管理系统的整车、零部件采购和维修更换转换为一般的关系模型，并按图4所示的信息设计出整车信息和零部件的基础信息、状态信息、维修/维护信息和相关技术资料等数据结构，从而满足整车及零部件的采购、更换、维修等履历信息的管理应用需求。
130.其次，继续转换列车履历管理系统的关系模型，使其成为数据库(oracle、ms sql server、db2、mysql、达梦、人大金仓等各大主流及国产数据库)管理系统支持的数据模型。最后，优化地铁车辆履历管理系统的数据模型，使其能更为高效的存储管理车辆信息。
131.表1供应商信息数据表(示意)
132.[0133][0134]
表2故障字典数据表(示意)
[0135]
字段类型长度null备注故障代码varchar20否主键故障描述varchar50否 录入人varchar50否 录入时间datetime50否 更新人varchar100否 更新时间datetime20否 [0136]
表3零部件种类数据表(示意)
[0137]
[0138][0139]
表4车型信息数据表(示意)
[0140]
字段类型长度null备注列车型号varchar20否主键列车名称varchar50否 录入人varchar50否 录入时间datetime50否 更新人varchar100
ꢀꢀ
更新时间datetime20
ꢀꢀ
[0141]
表5车型结构信息数据表(示意)
[0142]
[0143][0144]
表6整车信息数据表(示意)
[0145]
字段类型长度null备注车辆编号varchar20否主键列车型号varchar50否 供应商名称varchar50否 采购日期varchar50否 采购金额varchar50否 货币类型varchar50否 合同编号varchar50否 采购人varchar50否 列车状态varchar50
ꢀꢀ
存储地址varchar100
ꢀꢀ
录入人varchar50否 录入时间datetime50否 更新人varchar100
ꢀꢀ
更新时间datetime20
ꢀꢀ
[0146]
表7零部件信息数据表(示意)
[0147]
[0148][0149]
表8零部件维护信息数据表(示意)
[0150]
[0151][0152]
表9零部件更换信息数据表(示意)
[0153]
字段类型长度null备注更换工单号varchar20否主键列车编号varchar50否 零部件类型varchar50否 原零部件varchar50否 更换零部件varchar50否 原零件状态varchar50否 安置地址varchar50否 更换人员varchar50否 更换日期datetime50
ꢀꢀ
录入人varchar50否 录入时间datetime50否 更新人varchar100
ꢀꢀ
更新时间datetime20
ꢀꢀ
[0154]
表10轮对信息数据表
[0155]
[0156][0157]
(2)履历数据处理流程，如图6所示
[0158]
基于用户收集到excel、word、pdf等格式文件，利用信息化技术、全文检索技术，通过结构解析技术，实现目标数据识别、序列化处理、与非结构数据关联、存储、构建查询索引等功能，在满足用户基本查询和统计分析功能的基础上，逐步形成知识库，以关联性知识的形式为用户提供维修指导和修程修制支持。
[0159]
(3)履历数据上链存证
[0160]
针对车辆基本信息、状态信息、检修维护信息等全生命周期数据上链存证，实现产品质量信息有效追溯。上链数据设计如下：
[0161]
设备出厂验收类数据：基础信息、技术参数、验收过程、验收规则、质检报告、验收报告；
[0162]
技术文件类数据：技术条件、计算报告、试验大纲、试验报告、检测报告；
[0163]
整车信息类数据：技术参数、产品配置清单、配属动态、车辆走行公里、车辆质量信息、更新改造记录；
[0164]
主要零部件信息：基本信息、主要技术参数、资产配置动态、零部件动态；
[0165]
检测信息类数据：检测动态、检测记录、试验记录、试运记录、破损记录、特别记载；
[0166]
维修类数据：维修动态、试运行记录、技术提升记录、特别记载、更新改造记录。
[0167]
本发明中上链数据覆盖地铁车辆立项、设联、监造、验收、运营、报废的全生命周期，按照上链数据类型区分，主要包括车辆基本构型数据、车辆状态信息、运营维修数据、相关文件资料等。详细上链数据如下表：
[0168]
[0169][0170]
履历数据上链存证流程具体如下(如图5所示)：
[0171]
第一步、上链前处理
[0172]
地铁车辆电子履历相关业务数据在上链前，需要通过哈希算法对业务数据进行哈希处理，哈希值是与业务数据绑定的一串值，篡改业务数据会导致哈希值发生变化，因此具有防篡改的特性。
[0173]
接下来采用加密算法对哈希值进行数字签名，并增加时间戳。数字签名可将发送
者的身份和信息绑定，同时也可防止其他人冒充发送者，这样处理可保证信息的防篡改的同时认证发送者的身份，防止抵赖。
[0174]
第二步、上链处理阶段
[0175]
业务数据经过上链前处理之后，被转换成区块链可读的方式。处理完成的数据发送到区块链节点后，就形成了一笔区块链交易并进入上链处理的阶段。各节点在收到交易后，通过共识算法，将会形成新的区块。
[0176]
第三步、智能合约阶段
[0177]
数据上链处理完成之后，履历相关业务数据已经记录在链上了，并且地铁公司、运分公司等各个节点可以访问区块链上记录的数据。对于单纯只需要存证的业务数据而言，数据上链已经完成了存证操作，后续验证只需要通过哈希查询即可。如果涉及到存证以外其他的业务逻辑，则需要根据具体的业务场景设计相应的智能合约。

技术特征：
1.一种城轨车辆电子履历数据处理方法，其特征在于，该方法包括如下步骤：（1）建立城轨车辆电子履历数据资源库建立基础数据库，各类信息数据经过采集、安全检查、基本校验处理后存入基础数据库；建立共享库，用于存放各业务系统公开权限的各类信息，供用户进行跨系统的信息利用；建立交换数据库用于本系统与外围系统之间的数据交换；建立系统管理库，用于运行本系统的系统管理平台；建立履历资源目录库，用于存放业务目录、管理目录以及机构目录信息；建立元数据库，用于管理数据与数据之间，数据与业务之间，系统与系统之间的对应；履历数据处理基于用户收集到excel、word、pdf等格式文件，利用信息化技术、全文检索技术及结构解析技术，实现目标数据识别、序列化处理、与非结构数据关联、存储、构建查询索引等功能，在满足用户基本查询和统计分析功能的基础上，逐步形成知识库；履历数据上链存证地铁车辆电子履历相关业务数据在上链前，通过哈希算法对业务数据进行哈希处理，然后采用加密算法对哈希值进行数字签名，并增加时间戳；业务数据经过上链前处理之后，被转换成区块链可读的方式，处理完成的数据发送到区块链节点后，形成区块链交易并进入上链处理的阶段，各节点在收到交易后，通过共识算法，形成新的区块；数据上链处理完成之后，履历相关业务数据记录在链上，地铁公司、运分公司等各个节点完成访问区块链上记录的数据。2.如权利要求1所述的一种城轨车辆电子履历数据处理方法，其特征在于，建立所述履历资源目录库的具体方式如下：（i）确定履历数据类型地铁车辆履历信息包括基础数据、设计数据、生产数据、装配数据、运行数据、检维数据、故障数据、组织用户；（ii）履历资源目录建设首先依据车辆厂商交付的车辆bom物料清单，结合维修能力和管理精度进行识别和重构，具体分为两个步骤：一、地铁车辆基本构件编制1、从车辆厂商处获取的交付bom进行构建初始化，通过车辆履历定义的模板进行导入，或根据系统初始化车辆基础节点进行定义和参数设置；2、节点属性定义：根据不同部件进行节点元数据定义，包括基本信息、静态技术信息和配属动态；3、节点遍历：定义好当前节点属性后，开始逐层、逐级进行遍历识别；4、节点判定：对当前节点进行是否“拆分、不拆分和不管理”判定，当单元结构与交付bom中的对应结构不一致时，通过节点管理进节点进行删除、修改和细化结构；(1)拆分，继续对当前节点的下级进行识别定义和属性完善，进入下一个循环；
(2)不拆分，在地铁车辆结构中只保留本节点并信息；(3)不管理，在地铁车辆结构不做记录；5、是否遍历完成，对“基本构件层级”的构件是否识别完成，如果完成进入最小管理构件阶段，否则循环进行识别定义；二、地铁车辆最小管理构件编制1、识别构件类型，所述构件类型分为替换件、拆分件、检查点，根据管理维度进行对本节点构件进行识别和属性定义；(1)替换件，能够进行相互替换的同类型不同产品的构件;(2)拆分件，相同的构件但所处位置不同；(3)检查点，需要进行检查，但不属于替换或拆分件的构件；2、是否遍历完成，对所述最小管理构件的构件是否识别完成，如果完成则地铁车辆构件树完成编制，否则循环进行识别定义。3.如权利要求1所述的一种城轨车辆电子履历数据处理方法，其特征在于，所述步骤（3）中履历数据上链存证还包括如下具体方式：上链数据覆盖地铁车辆立项、设联、监造、验收、运营、报废的全生命周期，按照上链数据类型区分，包括车辆基本构型数据、车辆状态信息、运营维修数据、相关文件资料，针对所述上链数据上链存证，实现产品质量信息有效追溯，上链具体数据如下：设备出厂验收类数据：基础信息、技术参数、验收过程、验收规则、质检报告、验收报告；技术文件类数据：技术条件、计算报告、试验大纲、试验报告、检测报告；整车信息类数据：技术参数、产品配置清单、配属动态、车辆走行公里、车辆质量信息、更新改造记录；主要零部件信息：基本信息、主要技术参数、资产配置动态、零部件动态；检测信息类数据：检测动态、检测记录、试验记录、试运记录、破损记录、特别记载；维修类数据：维修动态、试运行记录、技术提升记录、特别记载、更新改造记录。

技术总结
本发明提供一种城轨车辆电子履历数据处理方法，该方法结合车辆结构设计建立了车辆运营构型，并利用数据库技术进行车辆构型数据结构化；采用细化至最小可维护单位的车辆履历数据颗粒度，通过基于业务流程的数据分析和集成技术保障数据的正确性和及时性，利用数据存储技术存储车辆全生命周期阶段文档资料，结合全文检索技术建立初步的车辆知识框架，为后期地铁车辆的采购、技术改造、运营提供基本数据支撑。在履历数据管理中加入区块链技术，确保数据流的机密性和完整性，以防敏感数据在传输过程中被泄漏及篡改，加强车辆履历数据安全性、正确性，为后续履历共享提供可靠的数据安全保障。障。障。


技术研发人员：李熙 张骄 姜杉 丁明辉 谢莎婷 刘畅 赵丽媛 崔霆锐 马国强
受保护的技术使用者：北京市地铁运营有限公司技术创新研究院分公司
技术研发日：2023.03.14
技术公布日：2023/7/21