Urban rail vehicle electronic history data processing method

Abstract

The present application provides a kind of urban rail vehicle electronic history data processing method, the method establishes vehicle operation configuration in combination with vehicle structure design, and vehicle configuration data structure is structured using database technology;Vehicle history data granularity refined to the smallest maintainable unit is used, the correctness and timeliness of data are guaranteed through data analysis and integration technology based on business process, the whole life cycle stage document of vehicle is stored using data storage technology, and preliminary vehicle knowledge framework is established in combination with full-text search technology, to provide basic data support for later subway vehicle procurement, technical reform, operation.In history data management, block chain technology is added to ensure the confidentiality and integrity of data flow, to prevent sensitive data from being leaked and tampered with during transmission, and to enhance the security and correctness of vehicle history data, to provide reliable data security guarantee for subsequent history sharing.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of urban rail transit information management, and particularly relates to a kind of electronic history data processing method of urban rail vehicle. BACKGROUND

[0002] Metro vehicle history contains a large amount of important basic information, records the important data and technical state of metro vehicle and important parts from procurement, assembly, use, repair to updating and reconstruction, and is an important basis for metro vehicle repair, use management and technical analysis. Compared with general information management system, metro vehicle history management system has the characteristics of wide information source, large data volume and high redundancy, which requires the system to record, save and use vehicle information more reasonably and avoid the problem of imperfect and incorrect information. However, due to the problems of immature computer technology, unclear operation specification and lack of attention from employees in the past history management work, vehicle history information cannot be properly managed, resulting in problems such as information heterogeneity, information cannot form a closed loop and low information utilization rate. With the rapid development of metro detection, management, maintenance and evaluation technologies and the continuous expansion of metro operation scale, these problems have become more prominent and have become an important factor restricting the development of metro industry.

[0003] Currently, metro vehicle history information is generally recorded manually in an electronic form, and the data is scattered, which has the following problems:

[0004] (1) Incomplete data and lack of standards: The initial planning and construction of metro is basically based on lines, and each line is a separate system. The construction manufacturers, equipment manufacturers and construction technologies at different stages are different. These two factors result in a large amount of heterogeneous history information between systems and lines, which leads to the problem of information islands and information heterogeneity between lines, which is not conducive to the storage and application of history information. The style and format of the content are inconsistent. Especially, the metadata items and categories are not unified, and the history information is not effectively sorted and organized according to the unified classification system standard and metadata standard.

[0005] (2) Large amount of data: A large amount of history information, related information and dynamic, historical records and other data resources are stored in the present unit, and with the continuous increase of data collection, the amount of data will also become larger and larger.

[0006] (3) Difficulty in data screening and updating: Since the history information is currently collected and managed in paper form, it causes great difficulty in information collection. In addition, data updating is also a problem. For example, personnel changes are not collected and updated in time, resulting in inaccurate information.

[0007] Blockchain technology can build a systematic security protection mechanism for the rail transit system edge computing network, ensuring network security and data security. In the existing technology, the application of blockchain technology in rail transit includes: 1) fusion of blockchain-based rail transit edge computing network security protection mechanism; 2) blockchain solution for interconnection of urban rail two-dimensional codes; 3) by establishing a unified blockchain cooperation agreement and authorizing accounts and business links on the chain, the decentralization of interconnection business and the simplification of passenger services can be realized. SUMMARY

[0008] In order to solve the above technical problems, the present application comprehensively utilizes blockchain, database and other technologies, studies and proposes a subway vehicle electronic history data processing method based on blockchain technology, which can solve the problems of fine, standardized and standardized vehicle history life cycle data, while realizing traceability, shareability, improving data utilization value and enhancing work rigor, so as to realize the overall goal of smart subway construction and enterprise digital transformation. The present application specifically adopts the following technical solutions:

[0009] A method for processing electronic history data of urban rail vehicles, the method comprising the following steps:

[0010] (1) Establishing an electronic history data resource library of urban rail vehicles

[0011] Establishing a basic database, and storing various information data in the basic database after collection, safety inspection and basic verification processing;

[0012] Establishing a shared library for storing various information with public permissions of various business systems, for users to utilize information across systems;

[0013] Establishing an exchange database for data exchange between the system and peripheral systems;

[0014] Establishing a system management library for the system management platform of the system;

[0015] Establishing a history resource directory library for storing business directory, management directory and agency directory information;

[0016] Establishing a metadata database for managing the correspondence between data and data, between data and business, and between systems and systems;

[0017] (2) History data processing

[0018] Based on the excel, word, pdf and other format files collected by the user, the information technology, full-text retrieval technology and structure analysis technology are used to realize the functions of target data recognition, serialization processing, association with non-structured data, storage and construction of query index, etc. On the basis of meeting the basic query and statistical analysis functions of users, a knowledge base is gradually formed;

[0019] (3)Chain storage of history data

[0020] Before the metro vehicle electronic history related business data is chained, the business data is hashed by a hash algorithm, then the hash value is digitally signed by an encryption algorithm, and a timestamp is added;

[0021] After the business data is processed before chaining, it is converted into a way that can be read by the blockchain. After the processed data is sent to the blockchain node, it forms a blockchain transaction and enters the chaining process. After receiving the transaction, each node forms a new block through a consensus algorithm.

[0022] After the data chaining process is completed, the history related business data is recorded on the chain, and the metro company, operation and distribution company and other nodes complete the access to the recorded data on the blockchain.

[0023] Preferably, the specific way to establish the history resource directory is as follows:

[0024] (i) Determine the type of history data

[0025] The metro vehicle history information includes basic data, design data, production data, assembly data, operation data, inspection and maintenance data, fault data, and organization users.

[0026] (ii) Construction of history resource directory

[0027] First, according to the vehicle BOM bill of materials delivered by the vehicle manufacturer, combined with maintenance capacity and management accuracy, identification and reconstruction are carried out, which is divided into two steps:

[0028] I. Preparation of basic components of metro vehicles

[0029] 1. The delivery BOM obtained from the vehicle manufacturer is initialized and constructed, and the template defined by the vehicle history is imported, or the vehicle basic node is defined and parameterized according to the system initialization;

[0030] 2. Node attribute definition: define node metadata according to different components, including basic information, static technical information and associated dynamic;

[0031] 3. Node traversal: after defining the current node attributes, start traversing and identifying layer by layer and level by level;

[0032] 4. Node judgment: judge whether to "split, not split and not manage" for the current node. When the unit structure is inconsistent with the corresponding structure in the delivery BOM, delete, modify and refine the structure through node management into the node;

[0033] (1) Split, continue to identify and define the lower level of the current node and improve the attributes, and enter the next cycle;

[0034] (2) not split, only keep the node in the subway vehicle structure and information;

[0035] (3) not managed, no record in the subway vehicle structure;

[0036] 5. Whether to complete the traversal, whether the components of the "basic component hierarchy" are identified, if completed, enter the minimum management component phase, otherwise loop to identify and define;

[0037] II. Preparation of the minimum management component of the subway vehicle

[0038] 1. Identify the component type, which is divided into replacement parts, split parts, checkpoints, and identify and attribute define the component according to the management dimension;

[0039] (1) replacement parts, same type but different products of components that can be replaced with each other;

[0040] (2) split parts, same components but different locations;

[0041] (3) checkpoints, components that need to be checked but do not belong to replacement or split parts;

[0042] 2. Whether to complete the traversal, whether the components of the minimum management component are identified, if completed, the subway vehicle component tree is completed, otherwise loop to identify and define.

[0043] Preferably, the step (3) of chaining the history data for storage also includes the following specific ways:

[0044] The chained data covers the whole life cycle of subway vehicle project, establishment, supervision, acceptance, operation and scrap, and is divided according to the type of chained data, including vehicle basic configuration data, vehicle state information, operation and maintenance data, and related file data. For the chained data, the product quality information is effectively traced, and the specific chained data is as follows:

[0045] Equipment factory acceptance class data: basic information, technical parameters, acceptance process, acceptance rules, quality inspection report, acceptance report;

[0046] Technical file class data: technical conditions, calculation report, test outline, test report, detection report;

[0047] Whole vehicle information class data: technical parameters, product configuration list, allocation dynamic, vehicle running kilometers, vehicle quality information, updating and modification record;

[0048] Main component information: basic information, main technical parameters, asset allocation dynamic, component dynamic;

[0049] Inspection information data: inspection dynamic, inspection record, test record, trial operation record, damage record, special record;

[0050] Maintenance data: maintenance dynamic, test operation record, technical improvement record, special record, updating and reconstruction record.

[0051] The present application has the following beneficial effects:

[0052] (1) According to the train maintenance and operation specification and the subway operation experience, the vehicle operation configuration is established in combination with the vehicle structure design, and the vehicle configuration data structure is structured by using the database technology; the vehicle history data granularity refined to the smallest maintainable unit is adopted, the correctness and timeliness of the data are ensured through the data analysis and integration technology based on the business process, and the utilization rate of the subway vehicle basic data is improved.

[0053] (2) The vehicle full life cycle stage document data is stored by using the data storage technology, and the preliminary vehicle knowledge framework is established in combination with the full-text retrieval technology, so as to provide basic data support for the later subway vehicle procurement, technical transformation and operation.

[0054] (3) The subway company data resources are fully utilized to construct the subway vehicle history visualization capability and create the subway vehicle knowledge system, so that the data visualization and vehicle (basic, running and decision-making) knowledge sharing (function) are truly realized.

[0055] (4) The blockchain technology is added in the history data management, the data transmitted on the network is encrypted and authenticated based on the SSL mechanism, the confidentiality and integrity of the data flow are ensured, the sensitive data is prevented from being leaked and tampered in the transmission process, and the vehicle history data security and correctness are strengthened from the aspects of software architecture and data management function realization, so as to provide reliable data security guarantee for the subsequent history sharing. BRIEF DESCRIPTION OF DRAWINGS

[0056] Figure 1 It is a data integration relationship schematic diagram.

[0057] Figure 2 It is a subway vehicle data type diagram.

[0058] Figure 3 It is a subway vehicle history data directory construction flowchart.

[0059] Figure 4 It is a subway vehicle electronic history data diagram.

[0060] Figure 5 It is a history data chain storage process diagram.

[0061] Figure 6 It is an electronic history data processing flowchart. DETAILED DESCRIPTION

[0062] 1 History Resource Library

[0063] The metro vehicle history data resource library is a unified planning and management of metro vehicle basic information and main associated key metro vehicle operation related data, and metro vehicle related resource data, which solves the problem of scattered and non-unified metro vehicle history data, and realizes effective sharing and utilization of data.

[0064] 1.1 Construction of data resource library

[0065] The resource library is based on business application, and through the construction of data platform, the needs of the system are met. However, the data of the data resource database is not simply superimposed and summarized on the basis of data, but these data are recombined according to the classification of each business and according to the business relationship, so that it is more suitable for deep utilization and query of data.

[0066] Business distribution processing and data centralized management are a mainstream mode of system construction today. This mode not only meets the requirements of the system for the principles of "data stability, security, integrity, consistency", but also meets the requirements of the application system for the principles of "flexibility, individualization, easy expandability".

[0067] The establishment of the data resource database will solve four "unification" problems, namely "unified data platform, unified data interface, unified data channel, unified data management". The unified data platform is to provide a data system standard for the access, exchange and use of various data; the unified data interface is that the data exchange and sharing between the system and other peripheral systems must comply with the data standard, and is carried out through the unified data interface system; the unified data channel is that the data platform communicates the relationship between various application systems and departments, and makes the batch system constitute a unified new system; the unified data management is to concentrate data resources and carry out unified data management. Through advanced text and data mining technology, a data center is constructed to realize the coordination of efficiency and benefit.

[0068] 1.2 Overall design of data resource library

[0069] The design of vehicle history data resource library not only considers the utilization of existing data resources, but also can support the overall planning of global data, and establish a stable data model in the global range. The overall data planning solves the information resource planning and coordination, maximizes the sharing of data, reduces the redundancy of data, reduces the data interface, and improves the integration of data environment. The data integration relationship is as shown in Figure 1 .

[0070] 1.2.1 Classification of data resource library

[0071] The data of the data support environment of the present application is classified into database data, file data and data standard according to the technology used. The database data refers to data stored and managed in the form of database; the file data refers to data stored and managed in the form of file; and the data standard refers to the standardized content of data management.

[0072] 1) Database data of data resource

[0073] From the organization form of database, the database data supports the daily operation of the platform, the information service providing, and realizes the functions of query, data management, data service, statistical analysis and the like of application.

[0074] 2) File data

[0075] The file data is the unstructured data resource stored in various file forms. The file type data of the system using XML technology has a certain format description as the database data, and supports the variable length record format, thereby enhancing and facilitating the processing of exchanged data.

[0076] 3) Content of data standard

[0077] The basis of information system integration is data integration, and the data standardization is the guarantee of data integration. The content of data standard includes data element standard, information classification and coding standard, database standard and exchanged data standard and the like.

[0078] 1.3 Construction scheme of resource library

[0079] The optimal data resource library mode is constructed, and the database and the application system thereof are established, so that the data can be effectively stored, and the application requirements of various users can be met. The main functional targets are as follows:

[0080] 1) Various queries: including various data resource and file queries and the like;

[0081] 2) Data management: including the data management (addition, deletion and modification) of application system, data standard, management of basic configuration data and the like;

[0082] 3) Data service: mainly in the form of data interface system, the data sharing and exchange between the system and other systems in the periphery are carried out, and various data services are provided;

[0083] 4) Realization of association with basic configuration data: including the association with resource directory data, metadata and the like basic configuration data, and forming an integrated data environment.

[0084] 1.3.1 Design of history resource library

[0085] A complete and systematic data resource management system is established, and the main content is as follows:

[0086] 1) Unified storage: the currently scattered data is centralized together, properly stored and uniformly managed, and the utilization value of the data is improved.

[0087] 2) Form a system: organize various data according to certain logical relationship, make it integral and systematic, form a complete, orderly and rigorous data system, and compile detailed data resource catalog library.

[0088] 3) Standard specification: all data must follow a unified and standardized standard system, implement unified business indicators, business classification and coding.

[0089] 4) Whole process management: standardize design and effectively manage all processes such as data collection, inspection, arrangement, classification organization, exchange, maintenance, storage, use and release, etc., to ensure the orderly connection of each link and no management vacuum and system blank.

[0090] 1.3.2 Description of resume resource library

[0091] The construction of the resource library of the application is based on data resources, has integrity and logicality, and forms an orderly and rigorous framework.

[0092] The database mainly constructed by the application is as follows:

[0093] 1. Basic database: the database is the basis of the system and the core of the system. The information data of various sources is stored in the basic database after being collected, safety checked and basically verified.

[0094] 2. Shared library: to ensure the efficiency of data sharing, a shared library is established. The shared library mainly stores various types of information with public permission of various business systems for users to utilize information across systems.

[0095] 3. Exchange database: to realize more flexible and secure data exchange, it is suggested to set up an exchange database. The exchange database is mainly responsible for data exchange between the system and peripheral systems, and stores two types of data:

[0096] (1) data needed to be submitted to other systems;

[0097] (2) data obtained from other systems.

[0098] The exchange database can be an independent database, or can exist as a temporary table in the same physical library as other databases.

[0099] 4. System management library: the system management platform for running the system belongs to the basic configuration library.

[0100] 5. History resource directory: In order to improve the efficiency of data utilization and management, an information resource directory is established, which stores information such as business directory, management directory and organization directory of data. By reading (or updating) data at the correct position of the information directory, the steps of querying information within the system can be simplified.

[0101] 6. Meta database: Meta data is data about data, which can be specifically divided into business metadata, technical metadata and operational metadata. The correspondence between management data and data, data and business, and system and system facilitates the understanding and use of information in the database by technical personnel and business personnel.

[0102] 1.3.3 History data type

[0103] Metro vehicle history information includes data from design to construction, to operation, maintenance, update and transformation in the whole life cycle. In general, metro vehicle life cycle data can be divided into eight categories (as shown in Figure 2 Figure 1): (1) basic data, (2) design data, (3) production data, (4) assembly data, (5) operation data, (6) inspection and maintenance data, (7) fault data, and (8) organization user

[0104] Among them, (1), (2) and (3) are static data, which describe the inherent nature of the metro vehicle itself and are in a relatively stable state and basically do not change. (1) mainly provides data support for the design of the entire metro vehicle; (2) mainly describes the physical information of the metro vehicle, including the length, width and height of the vehicle, the maximum passenger capacity, etc.; (3) mainly provides information needed by the metro vehicle in the production process, including the number of employees required, manufacturing environment parameters, etc. (4), (5), (6) and (7) belong to data after the metro vehicle is put into use. They include the state of the metro train during operation, such as train speed, sensor parameters, etc.; and the content of maintenance after the train fails. (8) belongs to management data.

[0105] In summary, metro vehicle history information has various data categories and spans a long period. To master the complete history information of the metro vehicle, data tracking and recording are needed from design to operation and then to maintenance.

[0106] 1.3.4 History resource construction method

[0107] The construction of metro vehicle resource directory starts from the dimension of rail vehicle operation, and through the analysis of the organization mode of metro vehicle maintenance BOM, the configuration BOM resource directory of metro vehicle is constructed. The construction process of metro vehicle history data directory is as followsFigure 3 as shown.

[0108] First, according to the vehicle BOM bill of materials delivered by the vehicle manufacturer, combined with maintenance capability and management accuracy, identification and reconstruction are carried out, which is divided into two steps:

[0109] I. Basic components of metro vehicles

[0110] The basic structure is the general structure node of metro vehicles, such as the whole vehicle at the first level, the vehicle body, vehicle external components, and vehicle internal equipment at the second level, and the lower level structure of the second level at the third level, such as the interior layout and windows of the vehicle internal equipment. According to the actual situation, the basic structure is defined as a three-level structure, and the process is as follows:

[0111] 1. The delivery BOM obtained from the vehicle manufacturer is initialized for construction, which can be imported through the template defined by the vehicle history or defined and parameterized according to the system initialization vehicle basic node.

[0112] 2. Node attribute (parameter) definition: define node metadata according to different components, mainly including basic information, static technical information, and affiliated dynamic.

[0113] 3. Node traversal: after defining the current node attributes, start traversing and identifying layer by layer (same level nodes) and level by level (lower level nodes);

[0114] 4. Node judgment: whether to "split, not split and not manage" is judged for the current node. When the unit structure is inconsistent with the corresponding structure in the delivery BOM, it can be deleted, modified and refined through node management into nodes;

[0115] (1) Split, continue to identify and define the lower level of the current node and improve the attributes, and enter the next cycle;

[0116] (2) Do not split, only keep the current node and information in the metro vehicle structure;

[0117] (3) Do not manage, do not record in the metro vehicle structure.

[0118] 5. Whether to complete the traversal, whether to complete the identification of the "basic component level" component, if completed, enter the minimum management component stage, otherwise loop to identify and define.

[0119] II. Minimum management component of metro vehicle

[0120] The minimum management component unit refines the structure management of the current components of the vehicle according to the actual work requirements, and the process is as follows:

[0121] 1. Identify the component type, divided into "replacement, split or check point", according to the management dimension to identify and attribute definition (name, number, spare parts number, level, etc. Explicit or implicit basic attributes) of the node component;

[0122] (1) Replacement, same type of different products of components that can be replaced with each other;

[0123] (2) Split parts, the same component but in different positions;

[0124] (3) Check point, the component needs to be checked, but not belonging to the replacement or split component.

[0125] Note: The extension attributes of the unit of interest in the whole life cycle are defined on the maintenance node; at the same time, part of the cyclically used components exist multiple times of repair and cross-line turnover in the whole life cycle. The instantiation management realizes the whole life cycle management of the specific maintenance unit; from the perspective of metro vehicle assets, vehicles of the same type are usually purchased in batches and share spare parts inventory.

[0126] 2. Whether to complete the traversal, whether the component of "minimum management component" is identified, if the metro vehicle component tree is compiled, otherwise the identification and definition are cycled.

[0127] 1.3.5 Logical structure design

[0128] The logical structure design of the database is the process of converting the conceptual model into a specific data model, that is, according to the conceptual structure, it is converted into the logical model supported by the management system.

[0129] First, the preliminary conversion of the metro vehicle history management system conceptual model is carried out, and the whole vehicle, spare parts procurement and maintenance replacement of the management system are converted into a general relational model, and the whole vehicle information and spare parts basic information, state information, maintenance information and related technical data are designed according to the information shown in the data structure, so as to meet the application requirements of the whole vehicle and spare parts procurement, replacement, maintenance and other history information management. Figure 4

[0130] Secondly, continue to convert the relational model of the train history management system, so that it becomes a data model supported by the database (Oracle, MS SQLServer, DB2, MySQL, Dream, RenDa JinCang, etc. Mainstream and domestic databases) management system. Finally, the data model of the metro vehicle history management system is optimized, so that it can more efficiently store and manage vehicle information.

[0131] Table 1 Supplier information data table (schematic)

[0132] ​

[0133]

[0134] Table 2 Fault Dictionary Data Table (schematic)

[0135] Field Type Length NULL Remark Fault code varchar 20 No Primary key Fault description varchar 50 No Entry person varchar 50 No Entry time Datetime 50 No Update person varchar 100 No Update time Datetime 20 No

[0136] Table 3 Parts Kind Data Table (schematic)

[0137]

[0138]

[0139] Table 4 Vehicle Type Information Data Table (schematic)

[0140] Field Type Length NULL Remark Train model varchar 20 No Primary key Train name varchar 50 No Entry person varchar 50 No Entry time Datetime 50 No Update person varchar 100 Update time Datetime 20

[0141] Table 5 Vehicle Type Structure Information Data Table (schematic)

[0142]

[0143]

[0144] Table 6 Whole Vehicle Information Data Table (schematic)

[0145] Field Type Length NULL Remark Vehicle number varchar 20 No Primary key Train model varchar 50 No Supplier name varchar 50 No Purchase date varchar 50 No Purchase amount varchar 50 No Currency type varchar 50 No Contract number varchar 50 No Purchasing person varchar 50 No Train status varchar 50 Storage address varchar 100 Entry person varchar 50 No Entry time Datetime 50 No Update person varchar 100 Update time Datetime 20

[0146] Table 7 Parts Information Data Table (schematic)

[0147]

[0148]

[0149] Table 8 Parts Maintenance Information Data Table (schematic)

[0150]

[0151]

[0152] Table 9 Parts Replacement Information Data Table (schematic)

[0153] Field Type Length NULL Remark Replacement work order number varchar 20 No Primary key Train number varchar 50 No Part type varchar 50 No Original part varchar 50 No Replacement part varchar 50 No Original part status varchar 50 No Installation address varchar 50 No Replacement person varchar 50 No Replacement date Datetime 50 Entry person varchar 50 No Entry time Datetime 50 No Update person varchar 100 Update time Datetime 20

[0154] Table 10 Wheel Set Information Data Table

[0155]

[0156]

[0157] (2) History Data Processing Flow, as shown in Figure 6 ​

[0158] Based on the user collects excel, word, pdf and other format files, using information technology, full-text retrieval technology, through the structure analysis technology, realizes target data recognition, serialization processing, and non-structural data association, storage, construction query index and other functions, on the basis of meeting the user's basic query and statistical analysis function, gradually forms a knowledge base, and provides maintenance guidance and repair schedule support in the form of associated knowledge for the user.

[0159] (3) History data chain storage

[0160] The vehicle basic information, state information, maintenance information and other full life cycle data are chained and stored, and the product quality information is effectively traced. The chained data is designed as follows:

[0161] Equipment factory acceptance data: basic information, technical parameters, acceptance process, acceptance rules, quality inspection report, acceptance report;

[0162] Technical file data: technical conditions, calculation report, test outline, test report, detection report;

[0163] Whole vehicle information data: technical parameters, product configuration list, allocation dynamic, vehicle running kilometers, vehicle quality information, updating and modification record;

[0164] Main component information: basic information, main technical parameters, asset allocation dynamic, component dynamic;

[0165] Detection information data: detection dynamic, detection record, test record, trial operation record, damage record, special record;

[0166] Maintenance data: maintenance dynamic, trial operation record, technical improvement record, special record, updating and modification record.

[0167] The chained data in the application covers the whole life cycle of the subway vehicle from project establishment, setting, supervision, acceptance, operation to scrap, and is mainly divided into vehicle basic configuration data, vehicle state information, operation and maintenance data, and related file data according to the type of chained data. The detailed chained data is shown in the following table:

[0168]

[0169]

[0170] The history data chain storage process is as follows (as shown in Figure 5

[0171] First step, pre-processing before chaining

[0172] ​The subway vehicle electronic record related business data needs to be hashed by a hash algorithm before being chained. The hash value is a string of values bound to the business data. Tampering with the business data will change the hash value, thus having the feature of tamper resistance.

[0173] Next, the hash value is digitally signed using an encryption algorithm and a timestamp is added. Digital signature can bind the sender's identity and information, and also prevent others from impersonating the sender. This processing can guarantee the anti-tampering of information and authenticate the identity of the sender, preventing repudiation.

[0174] Second step, chain processing stage

[0175] After the business data is processed before being chained, it is converted into a form readable by the blockchain. After the processed data is sent to the blockchain node, a blockchain transaction is formed and enters the chain processing stage. After receiving the transaction, each node will form a new block through a consensus algorithm.

[0176] Third step, smart contract stage

[0177] After the data chain processing is completed, the record related business data has been recorded on the chain, and the subway company, operation and distribution company and other nodes can access the data recorded on the blockchain. For business data that only needs to be notarized, data chaining has completed the notarization operation, and subsequent verification only needs to be queried by hash. If it involves other business logic besides notarization, the corresponding smart contract needs to be designed according to the specific business scenario.

Claims

1. A method for processing electronic history data of urban rail vehicles, characterized in that the method comprises the following steps: (1) establishing an electronic history data resource library of urban rail vehicles establishing a basic database, wherein various information data are stored in the basic database after being collected, checked for safety, and processed for basic verification; establishing a shared library for storing various information with public rights of various business systems, so as to allow users to utilize information across systems; establishing an exchange database for data exchange between the system and peripheral systems; establishing a system management library for a system management platform for running the system; establishing a history resource directory library for storing business directory, management directory, and agency directory information; establishing a meta-database for managing correspondence between data and data, between data and business, and between systems and systems; The specific method for establishing the history resource directory library is as follows: (i) history resource directory construction First, the BOM bill of materials of vehicles delivered by vehicle manufacturers is identified and reconstructed according to maintenance capacity and management accuracy, and the reconstruction is specifically divided into two steps: I. Preparation of basic components of metro vehicles 1. The delivery BOM obtained from the vehicle manufacturer is initialized for construction, imported through the template defined by the vehicle history, or defined and parameterized according to the system initialization vehicle base node; 2. Node attribute definition: define node metadata according to different components, including basic information, static technical information and associated dynamic; 3. Node traversal: after defining the current node attributes, start traversing and identifying layer by layer and level by level; 4. Node judgment: whether to "split, not split and not manage" the current node, when the unit structure is inconsistent with the corresponding structure in the delivery BOM, delete, modify and refine the structure through node management progress node; 5. Whether the traversal is completed, whether the component of the "basic component level" is identified, if completed, enter the minimum management component phase, otherwise loop to identify and define; II. Preparation of the minimum management component of the metro vehicle 1. Identify the component type, which is divided into replacement parts, split parts and checkpoints, and identify and attribute define the components of the current node according to the management dimension; 2. Whether the traversal is completed, whether the component of the minimum management component is identified, if completed, the metro vehicle component tree is completed, otherwise loop to identify and define; (2) History data processing Based on the excel, word and pdf format files collected by the user, information technology, full-text retrieval technology and structure analysis technology are used to realize the functions of target data identification, serialization processing, association with non-structured data, storage and query index construction. On the basis of meeting the user's basic query and statistical analysis functions, a knowledge base is gradually formed; (3) History data on-chain storage Before the metro vehicle electronic history related business data is on-chain, the business data is hashed by using the hash algorithm, and then the hash value is digitally signed by using the encryption algorithm, and the time stamp is added; After the business data is processed before on-chain, it is converted into a form readable by the blockchain. After the processed data is sent to the blockchain node, a blockchain transaction is formed and enters the on-chain processing stage. After receiving the transaction, each node forms a new block through the consensus algorithm; After the data on-chain processing is completed, the history related business data is recorded on the chain, and the metro company and operation division nodes complete the access to the data recorded on the blockchain.

2. The metro vehicle electronic history data processing method of claim 1, wherein the specific way of establishing the history resource directory library further comprises: (ii) determining the history data type Metro vehicle history information includes basic data, design data, production data, assembly data, operation data, inspection and maintenance data, fault data and organization users; The node judgment includes: (1) Split, continue to identify and define the attributes of the current node and enter the next cycle; (2) Do not split, only keep the current node in the metro vehicle structure and information; (3) Do not manage, do not record in the metro vehicle structure; The identification and attribute definition of the components of the current node according to the management dimension includes: (1) Replacement parts: components of the same type but different products that can be replaced with each other; ​ (2) Split parts, same components but in different positions; (3) Checkpoints, need to be checked, but not components of replacement or split parts.

3. The electronic record data processing method of the urban rail vehicle according to claim 1, characterized in that, the record data chaining storage in step (3) further includes the following specific ways: The chaining data covers the whole life cycle of the subway vehicle from project establishment, connection, supervision, acceptance, operation to scrap. According to the chaining data type, it includes vehicle basic configuration data, vehicle state information, operation and maintenance data, and related file data. For the chaining storage of the chaining data, the product quality information is effectively traced, and the specific chaining data is as follows: Device factory acceptance data: basic information, technical parameters, acceptance process, acceptance rules, quality inspection report, acceptance report; Technical file data: technical conditions, calculation report, test outline, test report, detection report; Whole vehicle information data: technical parameters, product configuration list, allocation dynamics, vehicle running kilometers, vehicle quality information, updating and modification record; Main component information: basic information, main technical parameters, asset allocation dynamics, component dynamics; Detection information data: detection dynamics, detection record, test record, test operation record, damage record, special record; Maintenance data: maintenance dynamics, test operation record, technical improvement record, special record, updating and modification record.

Images