Train data storage method, train data retrieval method, train data storage device, and train

Abstract

The present disclosure provides a train data storage method, which can be applied to the fields of rail transit and big data technology. The train data storage method comprises: acquiring multi-source heterogeneous data of a train, the multi-source heterogeneous data representing running data generated in the running process of multiple functional systems of the train; dividing the running data into at least one data storage unit according to attribute information of the running data, each data storage unit corresponding to a functional semantic complete storage granularity; generating a corresponding metadata label for each data storage unit, the metadata label containing storage information and retrieval information of the data storage unit; storing the data storage unit to at least one sub-storage area; and constructing index information corresponding to multiple dimensions respectively according to multiple dimension information in the metadata label, the index information being used for positioning the data storage unit independently or in combination during retrieval. The present disclosure also provides a train data retrieval method, a train data storage device and a train.

Description

Technical Field

[0001] This disclosure relates to the fields of rail transit and big data, specifically to a train data storage method, a train data retrieval method, a train data storage device, and a train. Background Technology

[0002] Train subsystems typically employ independent deployment and distributed storage for data management, meaning each functional system has its own local storage unit and maintains its data independently. While this architecture can meet the data recording needs of a single system, it lacks a unified data organization and access mechanism between different subsystems. Data is usually stored in separate files or proprietary formats on their respective storage devices, leading to complex cross-system data acquisition and integration processes, widespread data redundancy, and difficulty in supporting applications such as train health management, fault tracing, and fusion analysis. Summary of the Invention

[0003] In view of the above problems, this disclosure provides a train data storage method, a train data retrieval method, a train data storage device, and a train.

[0004] According to the first aspect of this disclosure, a train data storage method is provided, comprising: acquiring multi-source heterogeneous data of a train, wherein the multi-source heterogeneous data represents operational data generated during the operation of multiple functional systems of the train; dividing the operational data into at least one data storage unit according to the attribute information of the operational data, wherein each data storage unit corresponds to a storage granularity with complete functional semantics; generating a corresponding metadata tag for each data storage unit, wherein the metadata tag contains storage information and retrieval information of the data storage unit; storing the data storage unit in at least one sub-storage area; and constructing index information corresponding to multiple dimensions according to multiple dimension information in the metadata tag, wherein the index information is used independently or in combination to locate the data storage unit during retrieval.

[0005] According to embodiments of this disclosure, index information corresponding to multiple dimensions is constructed based on multiple dimensions of information in metadata tags, including: extracting field values ​​of multiple dimensions from metadata tags, the multiple dimensions including at least: time dimension, device number dimension, and fault type dimension; constructing an index information based on each dimension, the index information of each dimension being orthogonal to each other, so as to support the combination operation of any multiple dimension index information to obtain the location result of the target data storage unit during retrieval.

[0006] According to embodiments of this disclosure, storing runtime data in at least one sub-storage area includes: segmenting the runtime data of the first functional system according to attribute information of the runtime data of the first functional system to obtain first segment data and second segment data, wherein the first segment data corresponds to the first sub-storage area and the second segment data corresponds to the second sub-storage area; writing the first segment data into the first sub-storage area and simultaneously writing the second segment data into the second sub-storage area.

[0007] According to embodiments of this disclosure, storing runtime data in at least one sub-storage area includes: in response to determining that the priority of runtime data of the second functional system is higher than a preset threshold, writing the runtime data of the second functional system in parallel into a third sub-storage area and a fourth sub-storage area that are mirror images of each other; in response to receiving a first signal and a second signal, determining that the runtime data of the second functional system in the third sub-storage area and the fourth sub-storage area are in a synchronized state, wherein the first signal indicates that the writing of the runtime data of the second functional system in the third sub-storage area is completed, and the second signal indicates that the writing of the runtime data of the second functional system in the fourth sub-storage area is completed.

[0008] According to embodiments of this disclosure, the method further includes: obtaining download constraint parameters corresponding to the running data, wherein the download constraint parameters indicate that the downloaded running data meets the user's expected standards; and binding the download constraint parameters to a data storage unit to obtain a data storage unit with download constraint parameters.

[0009] According to embodiments of this disclosure, the download constraint parameters are configured as parameterizable configuration items, and the method further includes: updating the configuration items of the download constraint parameters in response to changes in download requirements, so that the data storage unit can download data according to the updated download constraint parameters.

[0010] According to a second aspect of this disclosure, a train data retrieval method is provided, applied to data stored in the aforementioned train data storage method, comprising: obtaining a retrieval request regarding a target train service, the retrieval request including at least one retrieval condition, the retrieval condition corresponding to dimension information in the metadata tags of a data storage unit; determining, based on the retrieval condition, metadata tags of data storage units matching each retrieval condition from index information in multiple dimensions, obtaining multiple tag sets; performing set operations on the multiple tag sets to obtain target metadata tags of the target data storage unit corresponding to the retrieval request; and returning the target data stored in the corresponding target data storage unit based on the target metadata tags.

[0011] According to embodiments of this disclosure, data storage units are divided based on the semantic information of running data, and each data storage unit has a semantic information tag. The method further includes determining retrieval semantic information about the retrieval request based on retrieval conditions; calculating the similarity between the retrieval semantic information and the semantic information tags of each data storage unit, wherein the semantic information tags are components of the metadata tags; and returning the target data stored in the target data storage unit, wherein the similarity between the semantic information tags of the target data storage unit and the retrieval semantic information is greater than a target threshold.

[0012] According to embodiments of this disclosure, the method further includes: determining a target output format for the target data based on the target data, wherein the target output format includes at least one of the following: graphical format, tabular format, file format, and data stream format; and converting the target data according to the target output format to obtain a target output result.

[0013] A third aspect of this disclosure provides a train data storage device, comprising: a storage board module including multiple storage boards, each storage board having a sub-storage area; a main control module for executing the aforementioned train data storage method or train data retrieval method; and a communication bus module for enabling data interaction between the storage board module and the main control module.

[0014] According to embodiments of this disclosure, the main control module includes a first main control unit and a second main control unit. The first main control unit and the second main control unit are configured to be connected via a synchronization bus. The second main control unit is used to synchronize the operating status and data of the first main control unit in real time. In response to detecting a fault in the first main control unit, the second main control unit is switched to an active state, and the second main control unit takes over the data interaction with the storage board module from the first main control unit.

[0015] A fourth aspect of this disclosure provides a train, comprising: a body; and the aforementioned train data storage device. Attached Figure Description

[0016] The above and other objects, features and advantages of this disclosure will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 A flowchart illustrating a train data storage method according to an embodiment of the present disclosure is shown schematically.

[0018] Figure 2 A flowchart illustrating a train data retrieval method according to an embodiment of the present disclosure is shown schematically.

[0019] Figure 3 A schematic diagram illustrating the principle of a train data retrieval method according to an embodiment of the present disclosure is shown.

[0020] Figure 4A schematic diagram of the structure of a train data storage device according to an embodiment of the present disclosure is shown.

[0021] Figure 5 A schematic diagram of a train according to an embodiment of the present disclosure is shown. Detailed Implementation

[0022] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0025] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0026] In the technical solution of this application, the passenger information (including but not limited to passenger personal information, passenger image information, passenger equipment information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by passengers or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0027] Before introducing the technical solutions provided in the embodiments of this disclosure, the relevant technologies involved in this disclosure will be explained first.

[0028] Traditional train systems typically distribute data across various functional modules. For example, subsystems such as train control and monitoring systems, passenger information systems, video surveillance systems, pantograph-catenary monitoring systems, door systems, and running gear detection systems each maintain independent storage units. Each train subsystem usually employs an independent deployment and distributed storage approach for data management, meaning each functional system is configured with local storage units and maintains its data independently. While this architecture can meet the data recording needs of a single system, its limitations become increasingly apparent as the scale and complexity of train data continue to increase, primarily in the following aspects.

[0029] I. Vehicle data storage is scattered and lacks unified management.

[0030] First, data is scattered and difficult to share. There is a lack of a unified data organization and access mechanism between different subsystems. Data is usually stored in separate files or proprietary formats on their respective storage devices, leading to complex cross-system data acquisition and integration processes, widespread data redundancy, and difficulty in supporting application requirements such as train health management, fault tracing, and fusion analysis. Second, interface standards are inconsistent. Different subsystems use different communication protocols and data interface methods, such as FTP, CAN, and MVB, resulting in poor interface compatibility and hindering unified data access and centralized management. Upper-layer applications need to be adapted for different systems, increasing system development and subsequent maintenance costs. Third, reliability and redundancy mechanisms are insufficient. Most existing storage units operate in a single-point manner. When a local storage device fails, critical data is easily lost. The lack of effective data redundancy and recovery mechanisms impacts train operation safety and maintenance analysis. Fourth, expansion and maintenance are complex. When train formations, vehicle configurations, or business requirements change, multiple subsystems need to be adjusted and upgraded separately. This involves long implementation cycles and high maintenance costs, making it difficult to adapt to the flexible expansion needs of rail transit systems.

[0031] Second, the ability to quickly retrieve and accurately locate massive amounts of data is insufficient.

[0032] As train operation data continues to accumulate, the performance problems of the existing system in data retrieval, location, and download are becoming increasingly prominent.

[0033] First, traditional storage solutions mostly organize data based on ordinary file directories or simple time order, lacking multi-dimensional indexing mechanisms tailored to rail transit business scenarios. When maintenance personnel need to query data using combinations of conditions such as "train number + time period," "fault type + equipment number," or "line section + data category," the system typically needs to traverse and scan the entire dataset, resulting in low retrieval efficiency. Second, existing systems lack unified data download constraints and cannot automatically locate the storage location of target data based on task requirements. In practical applications, maintenance personnel often need to manually confirm the data source, storage path, and corresponding equipment, making data extraction complex and hindering rapid response. Furthermore, existing data filtering and trimming operations are usually performed in real-time during the download process, concentrating significant computational pressure on the download link and further reducing data acquisition efficiency. When dealing with long-running records or large-capacity video and log data, problems such as long download times and high system load easily arise, making it difficult to meet the needs of rapid fault analysis and emergency handling.

[0034] The following will be through Figure 1 The train data storage method of the disclosed embodiments will be described in detail.

[0035] Figure 1 A flowchart illustrating a train data storage method according to an embodiment of the present disclosure is shown schematically.

[0036] like Figure 1 As shown, the train data storage method of this embodiment includes operations S110 to S150.

[0037] In operation S110, multi-source heterogeneous data of the train is acquired. Multi-source heterogeneous data represents the operating data generated during the operation of multiple functional systems of the train.

[0038] In operation S120, the running data is divided into at least one data storage unit according to the attribute information of the running data, and each data storage unit corresponds to a storage granularity with complete functional semantics.

[0039] In operation S130, a corresponding metadata tag is generated for each data storage unit. The metadata tag contains the storage information and retrieval information of the data storage unit.

[0040] In operation S140, the data storage unit is stored in at least one sub-storage area.

[0041] In operation S150, based on the multiple dimensions of information in the metadata tags, index information corresponding to each of the multiple dimensions is constructed. The index information is used independently or in combination during retrieval to locate the data storage unit.

[0042] For example, multi-source heterogeneous data can be raw data from different functional systems, in different formats, or with different structures during train operation. Examples include status logs such as door opening and closing generated by the door control system during train operation; video stream files generated by onboard cameras; and message data generated by the Train Control and Management System (TCMS).

[0043] Attribute information may include data type, source system, timestamp, event identifier, and runtime stage.

[0044] A data storage unit can be a data unit with complete business semantics within the operational data. For example, data storage units can be divided based on data from a single train or a single-function system within a train carriage.

[0045] Metadata tags can be descriptive information about data storage units. Storage information can describe the physical or logical location, size, format, and integrity check value of the data storage unit within the storage medium, serving data write and read management. Retrieval information can describe the business semantic characteristics of the data storage unit, serving data querying and location. For example, metadata tags should include at least one of the following: data name, storage location, file size, storage type, check information, data priority, train number, and line segment.

[0046] Sub-storage areas can be different physical or logical partitions in a distributed storage system. Examples include different disks, storage nodes, database shards, or cloud storage buckets. A single data unit can be stored in one sub-storage area or multiple sub-storage areas. For instance, data storage units for braking events can be written to sub-storage area A, and data storage units for the air conditioning system can be written to sub-storage area B. Data storage units can also be fragmented and stored in multiple sub-storage areas, but the metadata will record the complete location mapping.

[0047] It's important to note that each storage board can function as a relatively independent sub-storage area. Under the unified scheduling of the main control module, it receives write tasks from data storage units. Each sub-storage area can independently host different types of data storage units, or they can be mirrored across multiple sub-storage areas via a synchronization bus. This ensures that the same data storage unit has copies on multiple physical boards, achieving redundancy protection. Simultaneously, the parallel write mechanism allows the main control module to synchronously distribute data storage units to multiple sub-storage areas, improving overall write throughput. When a sub-storage area fails, the main control module reallocates read and write tasks to the remaining healthy sub-storage areas and automatically triggers a data mirroring recovery process to rebuild the data in the failed area in other sub-storage areas, ensuring the integrity of the data storage units is not affected by a single point of failure.

[0048] Multiple dimensions can include time, system, and event type dimensions. Each dimension has its own independent set of index information. Each dimension's index can work independently, such as searching by time range; multiple dimension indexes can be used together, such as performing compound queries by time range and system type simultaneously. By using the intersection of indexes, the target data range can be quickly narrowed down, improving the efficiency of multi-condition retrieval.

[0049] This can be understood as follows: by dividing multi-source heterogeneous rail transit data into data storage units according to the complete granularity of functional semantics, generating metadata tags containing storage and retrieval information for each unit, and then constructing multi-dimensional index information based on the metadata tags, the storage organization of train operation data can be improved. The data organization and description problems are solved in advance at the storage layer, binding the index to the data content.

[0050] It should be noted that, in the embodiments of this disclosure, if the train function system includes a passenger information system, the passenger's consent or authorization can be obtained before operating S110 to obtain passenger information from the passenger information system. For example, a request to obtain passenger information can be sent to the passenger before operating S110. If the passenger consents or authorizes the acquisition of passenger information, operation S110 is performed.

[0051] As described above, in operation S150, index information corresponding to each of the multiple dimensions is constructed based on the multiple dimension information in the metadata tags. In one possible implementation, this operation may further include: extracting field values ​​of multiple dimensions from the metadata tags, where the multiple dimensions include at least: time dimension, device number dimension, and fault type dimension; constructing an index information based on each dimension, with the index information of each dimension being orthogonal to support the combination and operation of any multiple dimension index information during retrieval to obtain the location result of the target data storage unit.

[0052] For example, the field values ​​can be structured description fields written by each data storage unit when generating metadata tags. Among them, the field values ​​of the time dimension can be the start and end times of data collection or a precise timestamp, such as the collection window described by the start and end times "2024-05-10 08:32:15 ~ 08:32:45"; the field values ​​of the equipment number dimension can be the unique identifier of the functional system or specific equipment that generated the operational data, such as the combined code of the carriage number and equipment type "BCU-01"; the field values ​​of the fault type dimension can be the business event identifier or alarm type recorded in the metadata tag, such as "abnormal brake pressure" or "speed sensor signal loss".

[0053] The index information for each dimension can be an ordered mapping structure built based on the corresponding field values, such as a key-value index table or a tree index structure with field values ​​as keys and storage location identifiers of data storage units as values. For example, the time dimension index uses the time field value as the key and organizes the storage location identifiers of all data storage units into an ordered index in chronological order; the device number dimension index uses the device identifier as the key and aggregates and maps the location identifiers of all data storage units generated by the same device to the corresponding index entries. The index information for each dimension is built and maintained independently, and there is no cross-dimensional coupling relationship between index items, thus achieving orthogonality between the index information of each dimension.

[0054] It's important to note that the orthogonality between the index information of each dimension means that the creation and querying processes of each dimension's index are independent, and the content and structure of any one dimension's index do not depend on the field values ​​of other dimensions. During retrieval, the corresponding index information can be used independently for a single dimension; for example, using only the time dimension index to locate all data storage units within a specific time period. Alternatively, the index information of multiple dimensions can be combined and processed. This involves performing matching queries on each dimension's index separately to obtain a tag set for each, and then performing operations such as set intersection and union on these tag sets to gradually narrow down the location range, ultimately obtaining the location result of the target data storage unit that simultaneously satisfies the retrieval conditions of multiple dimensions.

[0055] In one example, the braking event data storage unit from the braking system has been written to sub-storage area A, and the operating status data storage unit from the air conditioning system has been written to sub-storage area B. Both have generated their own metadata tags. Three dimensions of field values ​​are extracted from the metadata tags of the two data storage units: the braking event data storage unit has a time field value of "2024-05-10 08:32:15 ~ 08:32:45", an equipment number field value of "BCU-01", and a fault type field value of "abnormal braking pressure"; the air conditioning system data storage unit has a time field value of "2024-05-10 08:30:00 ~ 09:00:00", an equipment number field value of "HVAC-CarA-01", and a fault type field value of "insufficient cooling capacity". Based on the above field values, three sets of index information are independently constructed: time dimension index, device number dimension index, and fault type dimension index. The time dimension index arranges the storage location identifiers of the above two data storage units into an ordered index table according to the time field value. The device number dimension index maps the braking event data storage unit to the index entry corresponding to "BCU-01" and the air conditioning system data storage unit to the index entry corresponding to "HVAC-CarA-01". The fault type dimension index uses "abnormal braking pressure" and "insufficient cooling capacity" as independent key values ​​to collect the location identifiers of the corresponding data storage units. The three sets of index information are independent of each other.

[0056] Understandably, by extracting field values ​​from multiple dimensions such as time dimension, device number dimension, and fault type dimension from metadata tags, and independently constructing mutually orthogonal index information for each dimension, the indexes of each dimension can participate in set operations in any combination during retrieval, enabling the system to quickly locate the target data storage unit that simultaneously meets multiple dimension retrieval conditions without having to traverse all data storage units.

[0057] As described above, in operation S140, the runtime data is stored in at least one sub-storage area. In one possible implementation, this operation may further include: fragmenting the runtime data of the first functional system according to the attribute information of the runtime data of the first functional system to obtain first fragment data and second fragment data, wherein the first fragment data corresponds to a first sub-storage area and the second fragment data corresponds to a second sub-storage area; writing the first fragment data to the first sub-storage area, and simultaneously writing the second fragment data to the second sub-storage area.

[0058] For example, the first functional system can be a functional subsystem for any operating data on the train, such as a train control and management system (TCMS), a video surveillance system, or a running gear detection system.

[0059] Key fields in the attribute information used to trigger sharding operations may include data volume, time span, write rate, and the type of the functional system to which it belongs. For example, when receiving running data from the first functional system, if the data volume in its attribute information exceeds the optimal write threshold for a single sub-storage area, or if its time span exceeds the system's preset maximum time window for a single storage unit, the main control module triggers a sharding operation, dividing the running data into a first shard and a second shard according to preset sharding rules.

[0060] Data shards can be logical data segments obtained by cutting the original running data according to a certain dimension. Each data shard carries the same source system identifier as the original running data, and the data continuity of each shard is guaranteed at the cutting boundary.

[0061] The first and second sub-storage areas can be logical partitions pre-allocated by the main control module and corresponding to different physical storage boards. For example, the first sub-storage area can be located on storage board SBM1, and the second sub-storage area can be located on storage board SBM2. Both are connected to the main control module through a synchronous communication bus and can independently receive write commands issued in parallel.

[0062] Simultaneous writing refers to the main control module issuing independent write commands to the first and second sub-storage areas simultaneously after completing the fragmentation. The writing process of the first fragment data and the writing process of the second fragment data are executed in parallel in time and do not block each other.

[0063] In one example, the first functional system is the Train Control and Management System (TCMS). The TCMS continuously generates message data during train operation. The data collection time range is from 08:30 to 09:00. Attribute information shows that the TCMS message data volume reached 2GB during this time period, exceeding the optimal write threshold (1GB) for a single sub-storage area, triggering a fragmentation operation. The main control module uses the midpoint 08:45 as the dividing boundary to split the TCMS message data into a first fragment (time range 08:30 to 08:45, data volume approximately 1GB) and a second fragment (time range 08:45 to 09:00:00, data volume approximately 1GB). The first fragment corresponds to the first sub-storage area on storage board SBM1, and the second fragment corresponds to the second sub-storage area on storage board SBM2. The main control module synchronously issues independent write commands to SBM1 and SBM2 respectively. The process of writing the first fragment data to the first sub-storage area and the process of writing the second fragment data to the second sub-storage area are executed in parallel, and the total write time is basically equivalent to the write time of a single fragment data. After the write is completed, the main control module records the complete fragment location mapping in the metadata tag corresponding to the TCMS message data: the storage location of the first fragment data points to the physical address corresponding to the first sub-storage area in SBM1, and the storage location of the second fragment data points to the physical address corresponding to the second sub-storage area in SBM2. The time field value covers the complete collection interval from 08:30:00 to 09:00:00, forming a continuous time coverage range on the same time axis as the time dimension index constructed in the above embodiment. This allows maintenance personnel to simultaneously locate the TCMS message data scattered in the two sub-storage areas through the fragment location mapping in the metadata tag when initiating a multi-dimensional combined retrieval request spanning this time period, and to aggregate the two fragments into a complete 30-minute message dataset in chronological order during restoration.

[0064] It is understandable that by dividing the operating data of the first functional system into first and second shards of data corresponding to different sub-storage areas according to the attribute information and the preset rules, and writing the two shards of data into their respective sub-storage areas in parallel, the writing task of a large amount of data in a single transaction can be effectively distributed to the concurrent writing channels of multiple sub-storage areas, which can shorten the writing latency and improve the overall storage throughput.

[0065] As described above, in operation S140, the runtime data is stored in at least one sub-storage area. In one possible implementation, the operation may further include the following operations: in response to determining that the priority of the runtime data of the second functional system is higher than a preset threshold, writing the runtime data of the second functional system in parallel to a third sub-storage area and a fourth sub-storage area that are mirror images of each other; in response to receiving a first signal and a second signal, determining that the runtime data of the second functional system in the third sub-storage area and the fourth sub-storage area are in a synchronized state, wherein the first signal indicates that the writing of the runtime data of the second functional system in the third sub-storage area is complete, and the second signal indicates that the writing of the runtime data of the second functional system in the fourth sub-storage area is complete.

[0066] For example, the priority can be a numeric level field written when generating metadata tags for data storage units, and the value can be an integer from 1 to 10, with a larger value indicating a higher priority.

[0067] The preset threshold can be a priority judgment benchmark value uniformly configured by the main control module. For example, the preset threshold can be set to 7. When the priority field value of a certain data storage unit is higher than 7, the main control module triggers the parallel mirroring write process; when the priority field value is not higher than 7, the data storage unit is written to the sub-storage area in the normal way, and the mirroring mechanism is not triggered.

[0068] The third and fourth sub-storage areas, which are mirrored regions, can be a pair of physical sub-regions with the same capacity and storage format, pre-configured by the main control module. They are connected to the main control module via a synchronous communication bus. Mirroring means that the data content stored in the third and fourth sub-storage areas remains completely consistent after being written; either can serve as a complete copy of the other. If one sub-storage area fails, the other sub-storage area can provide a complete and usable copy, ensuring data availability is not affected by a single point of failure. For example, the third sub-storage area can be located on storage board SBM3, and the fourth sub-storage area can be located on storage board SBM4. The two storage boards are hardware-independent and do not share physical media or control circuitry.

[0069] In one example, the second functional system is the Automatic Train Protection (ATP) system. When generating its metadata tag, the priority field value is set to 9 based on the source system type, which is higher than the preset threshold of 7. In response to the determination that the priority field value 9 is higher than the preset threshold of 7, independent write commands with the same content are simultaneously issued to the third sub-storage area located on storage board SBM3 and the fourth sub-storage area located on storage board SBM4, writing the operational data collected by the ATP system between 08:31:00 and 08:34:00 on May 10, 2024, into SBM3 and SBM4 in parallel. After SBM3 completes the write operation, it sends a first signal to the main control module. This signal contains the device identifier "SBM3-Node01", the identifier of the ATP data storage unit being written, and the write completion status code "0x00". After SBM4 completes the write operation, it sends a second signal to the main control module. This signal contains the device identifier "SBM4-Node01", the same ATP data storage unit identifier, and the write completion status code "0x00". Upon receiving both signals simultaneously, the main control module verifies that the data storage unit identifiers carried in the two signals are consistent and that the write status code is "0x00". This confirms that the third and fourth sub-storage areas are synchronized regarding the ATP operating data, and the mirror write process ends normally. At this point, the ATP system's operating data has a complete copy on each of the two physical storage cards, SBM3 and SBM4.

[0070] It is understandable that by writing the operational data of the functional system in parallel to two sub-storage areas that are mirror images of each other when the priority of the operational data is higher than a preset threshold, and confirming the synchronization status only after receiving the write completion signals sent by each of the two areas at the same time, dual-copy redundancy protection can be established for safety-critical operational data during the writing process without increasing the overall write latency.

[0071] As described above, in some embodiments, the train data storage method of this embodiment may further include the following operations: obtaining download constraint parameters corresponding to the running data, wherein the download constraint parameters indicate that the downloaded running data meets the user's expected standards; and binding the download constraint parameters to the data storage unit to obtain a data storage unit with download constraint parameters.

[0072] For example, download constraint parameters can be a set of range constraints and filtering conditions pre-configured during the data ingestion phase that must be satisfied when performing download operations on data storage units. Download constraint parameters can include one or any combination of the following: time window constraints, data type whitelists, data volume thresholds, device number ranges, and fault type filtering identifiers. For instance, a time window constraint can specify that only data within a specific time range before and after an event is allowed to be downloaded; a data type whitelist can limit the download to only data files conforming to a specified format; and a data volume threshold can specify the maximum amount of data that can be downloaded in a single operation to avoid excessive consumption of communication bandwidth resources due to large-capacity data downloads.

[0073] It should be noted that the binding between download constraint parameters and data storage units is completed during the data ingestion stage, rather than being dynamically generated when a download request arrives. This design shifts the computational burden of data filtering and pruning from the download link to the storage link.

[0074] In one example, the operational data of carriage number three of a certain high-speed train is divided into a data storage unit A. Download constraint parameters corresponding to the fault data in data storage unit A are obtained: For the fault data in data storage unit A, the download constraint parameters include a time window constraint (five minutes before and after the event occurrence), a data type whitelist (log format file), and a data volume threshold (not exceeding 50 megabytes). These download constraint parameters are appended as fields to the metadata tags of data storage unit A, completing the binding and obtaining data storage units with their own download constraint parameters. Subsequently, when maintenance personnel initiate a download request for the outstanding data of carriage number three, the system automatically locates and trims the target data range based on the download constraint parameters already bound to the fault data in the metadata tags of data storage unit A, outputting data content that meets the requirements of the data analysis task, without requiring maintenance personnel to configure filtering rules separately during download.

[0075] It is understandable that by binding the download constraint parameters to the corresponding data storage unit in advance during the data entry stage, each data storage unit is equipped with the ability to be pruned as needed when it is formed, thus shifting the data filtering computation pressure from the download link to the storage link.

[0076] As described above, the download constraint parameters are configured as parameterizable configuration items. The train data storage method of this embodiment may further include the operation of updating the configuration items of the download constraint parameters in response to changes in download demand, so that the data storage unit can download data according to the updated download constraint parameters.

[0077] For example, download constraint parameters are configured as parameterizable configuration items. This means that download constraint parameters are stored as independent fields in the metadata tags of the data storage unit. Each constraint condition exists in the form of a read-write parameter value, supporting modification, overwriting, or appending operations on any constraint field without changing the storage content, storage location, or index structure of the data storage unit, and the update takes effect immediately after completion. For example, configuration items can be independent parameter units used to store download constraint parameters, each supporting individual adjustment. For example, time window constraints can be configured as numeric parameters in minutes; data volume thresholds can be configured as numeric upper limits in megabytes; and data type whitelists can be configured as an enumerated list of allowed file formats for download.

[0078] Changes in download requirements can be triggered by scenarios such as adjustments to the scope of operations and maintenance tasks, expansion of fault analysis depth, changes in emergency response levels, or updates to compliance requirements, leading to a redefinition of the target data scope or quality standards. For example, when operations and maintenance personnel determine, after initial analysis, that the impact of a fault exceeds the initial assessment and require data over a wider timeframe, this can trigger a change in download requirements.

[0079] In one example, the handling scenario of the abnormal door closing event at end D of carriage 3 in the previous embodiment is continued. After the maintenance personnel completed the first round of data download and preliminary analysis based on the initial constraint parameters, they found that there was a temporal correlation between this abnormal door closing event and the braking system response in an earlier period within the same operating range of the carriage. It was determined that the root cause might be due to the braking control logic misjudging the door locking status. It is necessary to extend the analysis scope forward to obtain more complete historical data of the braking system and supplement the braking control system special diagnostic message type to support in-depth fault tracing. Accordingly, the download requirement changed, and the system responded to this change by updating the download constraint parameter configuration items of the relevant data storage units: the time window constraint configuration item of data storage unit A was updated from five minutes before and after to fifteen minutes before and after, and the data volume threshold configuration item was updated from 50 megabytes to 150 megabytes; the time window constraint configuration item of data storage unit B was updated from ten minutes before and after to twenty minutes before and after, the data type whitelist configuration item added the braking control system special diagnostic message type to the original braking message entries, and the data volume threshold configuration item was updated from 200 megabytes to 500 megabytes. After the update is completed, the maintenance personnel initiate another data download request for the abnormal shutdown event. The system directly locates and outputs the target data within the extended time window based on the updated constraint parameters. The returned TCMS braking message data covers a longer historical period and includes brake control system-specific diagnostic messages. Together with the initial download results, they constitute the complete dataset required to support in-depth fault tracing and root cause analysis.

[0080] Understandably, by configuring the download constraint parameters as parameterizable configuration items, the train data management system's adaptability and response efficiency to complex and ever-changing operation and maintenance analysis needs are improved.

[0081] The following will be through Figures 2-3 The train data retrieval method of the disclosed embodiments will be described in detail.

[0082] Figure 2 A flowchart illustrating a train data retrieval method according to an embodiment of the present disclosure is shown schematically. Figure 3 A schematic diagram illustrating the principle of a train data retrieval method according to an embodiment of the present disclosure is shown.

[0083] like Figure 2 As shown, the train data retrieval method in this embodiment includes operations S210 to S240.

[0084] In operation S210, a search request for train target services is obtained. The search request contains at least one search condition, which corresponds to the dimension information in the metadata tag of the data storage unit.

[0085] In operation S220, based on the search criteria, the metadata tags of the data storage units that match each search criterion are determined from the index information of multiple dimensions, resulting in multiple tag sets.

[0086] In operation S230, a set operation is performed on multiple tag sets to obtain the target metadata tag of the target data storage unit corresponding to the retrieval request.

[0087] In operation S240, the target data stored in the corresponding target data storage unit is returned based on the target metadata tag.

[0088] For example, the target business can be a business requirement in a train operation and maintenance scenario to query and retrieve specific data. For instance, the target business could be to perform fault tracing analysis on braking anomalies that occur on a specific train within a specified time period.

[0089] A search request can be a query command initiated by operations and maintenance personnel or an upper-level operations and maintenance platform, containing at least one search condition. Search conditions can be parameters that constrain the target data range, corresponding to the dimensional information in the metadata tags of the data storage unit, thus directly mapping to the index information of the corresponding dimension for precise location. For example, search conditions may include one or more combinations of time window conditions, data source system conditions, event type conditions, train number conditions, etc.

[0090] Set operations can involve performing operations such as intersection, union, or difference on multiple tag sets to obtain a target metadata tag set that satisfies all or some of the search criteria. For example, when a search request contains multiple search criteria, after querying the corresponding tag sets in the index information of each dimension, taking the intersection of the tag sets can narrow the target scope to a data storage unit that simultaneously satisfies all search criteria.

[0091] The target metadata tags can be a final set of tags determined through set operations, where each tag records the physical or logical location information of the corresponding data storage unit in the storage medium. Based on the storage location indicated by the target metadata tags, the content of the target data storage unit can be directly read from the corresponding sub-storage area, and the target data can be returned to the party that initiated the retrieval request.

[0092] In one example, refer to Figure 3 Using the data stored in operations S110 to S150 as the retrieval object, assuming that after a train completes a run, maintenance personnel need to retrieve braking anomaly-related message data generated by the Train Control and Management System (TCMS) during this run from the stored multi-source heterogeneous data to perform fault tracing analysis on braking events that occurred during this run. Maintenance personnel initiate a retrieval request through the maintenance platform. The retrieval request includes three retrieval conditions: the time window condition corresponds to the start and end time interval of this run, the data source system condition specifies the Train Control and Management System (TCMS), and the event type condition specifies braking anomaly. After receiving the above retrieval request, the system matches the time window condition in the time dimension index to obtain the metadata tags of all data storage units within the time interval of this run, forming the first tag set; matches the data source system condition in the system dimension index to obtain the metadata tags of all data storage units originating from the TCMS, forming the second tag set; and matches the event type condition in the event type dimension index to obtain the metadata tags of all data storage units labeled with braking anomaly event tags, forming the third tag set. The system performs an intersection operation on the first, second, and third tag sets to obtain a target metadata tag set. Based on the storage location information recorded by each target metadata tag, the system directly reads the contents of the relevant braking event data storage unit from the corresponding sub-storage area and returns the target data to the operation and maintenance platform for subsequent waveform display and fault analysis by operation and maintenance personnel.

[0093] Understandably, in application scenarios where train operation data continues to accumulate and storage scale continues to expand, the above-mentioned retrieval mechanism relies on the multi-dimensional orthogonal index structure pre-built in the storage stage to achieve efficient mapping from retrieval conditions to the location of target data storage units, thereby improving the efficiency of multi-condition combined retrieval and the response speed of operation and maintenance data retrieval.

[0094] As described above, the data storage unit is divided according to the semantic information of the running data. The data storage unit has semantic information tags. In some embodiments, the train data storage method of this embodiment may further include the following operations: determining the retrieval semantic information about the retrieval request according to the retrieval conditions; calculating the similarity between the retrieval semantic information and the semantic information tags of each data storage unit, wherein the semantic information tags are part of the metadata tags; and returning the target data stored in the target data storage unit, wherein the similarity between the semantic information tags of the target data storage unit and the retrieval semantic information is greater than a target threshold.

[0095] For example, semantic information segmentation can be based on the business semantic content carried by the operational data to divide the operational data, so that each data storage unit corresponds to a complete and independent business event or functional process at the semantic level. It should be noted that semantic information segmentation is consistent with the principle of segmenting operational data at the functional semantic completeness granularity in operation S120. For instance, the message sequence generated by the Train Control and Management System (TCMS) in a complete braking control event within a certain operating section can be considered a semantically complete data storage unit; the wheel-rail vibration acceleration records collected by the running gear detection system within the same operating section can be considered another semantically independent data storage unit.

[0096] Semantic information tags can be descriptive markers of the business semantic content carried by a data storage unit. As a component of metadata tags, they together with stored information and retrieval information form a complete metadata tagging system. Semantic information tags can contain the core business semantic features involved in the data storage unit, such as fault type, occurrence scenario, related systems or components, etc. For example, the semantic information tag of a data storage unit can contain train number A, carriage B, and braking data.

[0097] Retrieval semantic information can be a set of semantic features obtained by the system after semantic extraction processing based on the retrieval intent expressed by the retrieval conditions. For example, when maintenance personnel use "Train A's doors closed at 12:00" as the retrieval condition, they can extract semantic features such as "Train A," "12:00," and "doors closed" to constitute the retrieval semantic information for this retrieval request.

[0098] Similarity calculation measures the degree of similarity between the retrieved semantic information and the semantic information tags of each data storage unit at the semantic feature level. The level of similarity reflects the degree of alignment between the semantic content carried by the data storage unit and the retrieval intent. The target threshold can be a system-preset or user-configured lower limit for similarity, used to control the balance between the semantic relevance and coverage of the retrieval results. When the similarity between the semantic information tags of a data storage unit and the retrieved semantic information is greater than the target threshold, that data storage unit will be included in the retrieval results and returned; when the similarity is lower than the target threshold, the corresponding data storage unit will not be returned.

[0099] It should be noted that the target threshold can be adjusted according to the actual needs of the retrieval task, and this disclosure does not limit it.

[0100] In one example, based on the scenario of retrieving TCMS braking anomaly message data, the maintenance personnel described the fault as follows: Train A experienced slight abnormal vibration during the deceleration phase upon entering the station, and the brake handle response felt slightly delayed after operation, accompanied by continuous abnormal noise. Since the above description does not contain precise fault type tags or system numbers, it cannot be directly mapped to a predefined index dimension for precise retrieval. Semantic parsing was performed on the above fault description to extract semantic features such as "Train A," "deceleration phase upon entering the station," "abnormal vibration," "delayed braking response," and "abnormal noise," constituting the retrieval semantic information for this search request. This retrieval semantic information was then compared with the semantic information tags of each data storage unit in the storage system. The wheel-rail vibration acceleration data storage unit collected by the running gear detection system within the same operating range had semantic information tags including semantic features such as "deceleration range upon entering the station," "wheel-rail vibration acceleration exceeding limits," and "abnormal vibration records." Since the similarity between this and the retrieval semantic information was higher than the target threshold, it was included in the search results. Therefore, this running gear vibration data storage unit was returned to the maintenance platform as the semantic search result.

[0101] Understandably, semantic retrieval mechanisms can effectively recall data storage units that are highly semantically related to the retrieval intent in scenarios where retrieval conditions are given in the form of natural language or fuzzy descriptions and cannot be directly mapped to the structured index dimension, thus meeting different retrieval needs.

[0102] As described above, in some embodiments, the train data storage method of this embodiment may further include the following operations: determining the target output format of the target data based on the target data, wherein the target output format includes at least one of the following: graphical format, tabular format, file format, and data stream format; and converting the target data according to the target output format to obtain the target output result.

[0103] For example, the target output format can be the data organization and presentation method used when displaying or transmitting target data. Different target output formats are suitable for different downstream application scenarios and usage requirements. The determination of the target output format can be based on a comprehensive judgment of the data type, data structure characteristics, and actual purpose of the retrieval business.

[0104] Graphical formats can be output methods that transform target data into visual graphics for presentation. For example, graphical formats can be time-series waveforms, frequency domain spectrograms, trend graphs, or event timelines.

[0105] A tabular format is an output method that organizes target data into a structured table for presentation. For example, a tabular format can use event timestamps, systems, event types, key parameter values, etc., as column fields, and the event records corresponding to each data storage unit as rows.

[0106] File format can be a way to package target data into a file that can be persistently stored or transmitted externally. For example, file format can be a structured data file, a compressed archive, or a data analysis report file.

[0107] A data stream format can be a data transmission method that continuously pushes target data to a downstream receiving end. For example, a data stream can be a video file, etc.

[0108] The target output format can be a combination of multiple formats. When the search results contain multiple types of target data, a suitable output format can be determined for each type of target data, and the conversion results of multiple formats can be output uniformly. This allows operations and maintenance personnel to obtain multi-type formatted results adapted to different analysis needs in the same search response. In addition, the determination of the target output format can also be adapted in conjunction with the receiving capabilities or format preferences of the platform where the search request was initiated, so that the format conversion results can be directly interfaced with downstream consumption systems, reducing the secondary processing cost of operations and maintenance data at the format level.

[0109] In one example, based on the semantic similarity retrieval results described above, the operation and maintenance platform has obtained two types of target data: one is the braking control command sequence and pressure change message stored in the TCMS braking anomaly data storage unit, and the other is the wheel-rail vibration acceleration data storage unit collected by the running gear detection system in the same operating range. The system determines the target output format based on the data characteristics of the two types of target data: For TCMS braking control command sequences and pressure change messages, whose data structure is a continuous time-series message, the system determines it to be in a graphical format, converting the braking pressure value sequence into a time-series waveform graph with time as the horizontal axis and pressure value as the vertical axis, intuitively presenting the dynamic change trend of braking pressure throughout the braking event; For key parameter records of braking events, including the event occurrence time, braking command type, pressure peak value, response delay duration, etc., the system determines it to be in a tabular format, presenting the specific values ​​of each key parameter in a structured data table, facilitating item-by-item verification and horizontal comparison by maintenance personnel; For wheel-rail vibration acceleration data collected by the running gear detection system, the system determines it to be in a graphical format, converting the vibration acceleration time series into a frequency domain spectrum graph, presenting the distribution characteristics of vibration energy on each frequency component, and assisting in judging the frequency characteristics of abnormal vibrations in the running gear.

[0110] It is understandable that by determining the target output format based on the data type and business purpose of the target data, and converting the target data according to the target output format to obtain the target output result, the retrieved multi-type operation and maintenance data can be presented in a form that adapts to its data characteristics and downstream application scenarios.

[0111] Based on the above-described train data storage and retrieval methods, this disclosure also provides a train data storage method. The following will combine... Figure 4 The device is described in detail.

[0112] Figure 4 A schematic diagram of the structure of a train data storage device according to an embodiment of the present disclosure is shown.

[0113] like Figure 4 As shown, the train data storage device 300 in this embodiment includes a storage board module 310, a main control module 320, and a communication bus module 330.

[0114] The storage board module 310 includes multiple storage boards, each with sub-storage areas. The main control module 320 is used to execute the aforementioned train data storage method and / or train data retrieval method. The communication bus module 330 is used to realize data interaction between the storage board module 310 and the main control module 320.

[0115] For example, the train data storage device 300 may include: a vehicle interface unit (VIU), a main control module (MCU), a storage board module (SBM), a communication bus module 330, and a power management module (PEM).

[0116] The main control module 320 is the core control unit of the storage device. It establishes a high-speed communication connection with the storage board module 310 through the communication bus module 330. It is responsible for the unified reception, fragmentation, distribution, synchronization and recovery of data, and provides a unified standardized software access interface to the upper-layer system, shielding the differences in the underlying hardware.

[0117] The storage board module 310 comprises multiple independent storage board modules 310 (SBM1, SBM2, SBM3, etc.), each operating independently while being uniformly scheduled by the main control module 320. Data consistency is synchronized between the storage board modules 310 via a synchronization bus, enabling mirror backup and parallel writing. If any storage board module 310 fails, the main control module 320 reassigns read / write tasks to other functioning boards and automatically initiates a data mirror recovery process to ensure data integrity is unaffected.

[0118] The communication bus module 330 employs a highly reliable communication bus to achieve real-time data interaction between the main control module 320 and each storage board module 310, supporting a time synchronization mechanism to ensure data consistency during parallel writing across multiple boards. The bus features bandwidth arbitration and error detection functions and supports link redundancy configuration. The bus architecture can be expanded into star, ring, or hybrid topologies according to deployment requirements to support multi-carriage, cross-section communication scenarios.

[0119] The power management module is responsible for providing stable power and temperature management for the entire system, and features overvoltage protection, temperature detection, and fan speed control. When abnormal temperatures or voltage fluctuations occur, the microcontroller can automatically adjust the power distribution strategy to ensure the system's continuous and stable operation in the complex operating environment of trains.

[0120] Each functional system of the train sends data requests to the centralized storage device through the vehicle interface unit via standardized communication interfaces (Ethernet, CAN, MVB, PCIe, etc.). After receiving the request, the main control module 320 distributes the write task to multiple storage boards in segments according to the data type, priority, and capacity allocation strategy. Each storage board writes data in parallel, and data consistency is ensured through a bus synchronization mechanism. After the write is completed, the main control module 320 is responsible for data consistency verification and mirror synchronization, and outputs a unified status and health report. The upper-level system accesses the stored data through a unified standardized software interface without needing to be aware of the underlying physical distribution.

[0121] In some embodiments, the main control module 320 includes a first main control unit and a second main control unit. The first main control unit and the second main control unit are configured to be connected via a synchronization bus. The second main control unit is used to synchronize the operating status and data of the first main control unit in real time. In response to detecting a fault in the first main control unit, the second main control unit is switched to an active state, and the second main control unit takes over the data interaction with the storage board module from the first main control unit.

[0122] For example, the main control module supports primary and backup redundancy configuration, and the two sets of control units achieve seamless switching through a dual-machine hot standby mechanism; when the main control module fails or communication is interrupted, any storage board module can also automatically take over the scheduling and management functions through an internal arbitration mechanism.

[0123] The first master control unit can be the active primary control unit in the master control module, undertaking core functions such as unified scheduling of various storage board modules, data reception and distribution, consistency management, and external interface response. The second master control unit can be a standby control unit in the master control module, in hot standby mode. During normal operation, it does not participate in active scheduling tasks, but continuously receives and maintains real-time status mirror data from the first master control unit via the synchronization bus. For example, the first and second master control units can be two independently deployed control processing boards, maintaining consistency in processor model, firmware version, and system configuration parameters to ensure that after a switchover, the second master control unit can seamlessly and completely take over all scheduling and management functions of the first master control unit.

[0124] The first and second master control units communicate via a heartbeat detection mechanism to detect faults and trigger switchover. During normal operation, the first master control unit sends a heartbeat signal to the second master control unit at fixed intervals. The second master control unit continuously listens to this heartbeat signal and performs time-based verification of the reception status. In response to detecting a fault in the first master control unit, including but not limited to not receiving a valid heartbeat signal for several consecutive heartbeat cycles, receiving an abnormal status flag actively reported by the first master control unit, or detecting a link abnormality on the communication bus, the second master control unit determines that the first master control unit is unavailable and immediately activates the master-slave switchover process. During the switchover, the second master control unit transitions from a hot standby state to an active state and takes over the data interaction functions of all storage board modules based on the synchronized task context data. This includes continuing to execute data writing tasks that the original first master control unit has not yet completed, responding to new data access requests from the vehicle interface unit, and continuously maintaining the data consistency synchronization mechanism between the various storage board modules. Since the second master control unit has a complete copy of the first master control unit's operating status before the switch occurs, the entire switch process remains transparent to the upper-layer access system, does not cause data writing interruption, and does not result in the loss of data storage units or damage to metadata tags.

[0125] Understandably, by unifying and scheduling data from multiple subsystems through the main control module, centralized storage and management of data within the train scope is achieved, solving the problems of scattered storage and data silos in traditional train systems. A parallel working structure of multiple independent storage boards, combined with a high-bandwidth communication bus, enables multi-channel parallel writing and reading, significantly improving data throughput and real-time performance, meeting the needs of high-speed data recording and retrieval during train operation. A health monitoring and redundancy management mechanism is implemented, which can detect the status of storage boards in real time and automatically perform data mirroring and synchronous recovery in the event of a failure, effectively preventing data loss and improving system reliability and security. A unified software access interface is provided, shielding upper-level systems from underlying hardware differences. Different subsystems such as the train control and monitoring system, passenger information system, video surveillance system, pantograph-catenary monitoring system, door system, and running gear detection system can access storage resources using a unified standard, greatly improving system compatibility and scalability. Because all storage devices are centrally managed, unified monitoring, log collection, and capacity allocation can be achieved through remote or automated tools, reducing on-site maintenance workload and spare parts management complexity, and lowering the total lifecycle cost of the train. Modular design allows storage capacity and bandwidth to be flexibly expanded according to the number of train formations and functional systems, adapting to different train models and application scenarios without changing the system structure.

[0126] Figure 5 A schematic diagram of a train according to an embodiment of the present disclosure is shown.

[0127] like Figure 5 As shown, the train 400 in this embodiment includes a main body 410 and a train data storage device 300.

[0128] The train data storage device 300 is used to execute the above-mentioned train data storage method or train data retrieval method.

[0129] The above description can be used as a reference for the train data storage device 300, and will not be repeated here.

[0130] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0131] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A method for storing train data, comprising: Acquire multi-source heterogeneous data of the train, wherein the multi-source heterogeneous data represents the operational data generated during the operation of multiple functional systems of the train; Based on the attribute information of the running data, the running data is divided into at least one data storage unit, and each data storage unit corresponds to a storage granularity with complete functional semantics; A corresponding metadata tag is generated for each data storage unit, and the metadata tag contains the storage information and retrieval information of the data storage unit; The data storage unit is stored in at least one sub-storage area; Based on the multiple dimensions of information in the metadata tags, index information corresponding to each of the multiple dimensions is constructed. The index information is used independently or in combination during retrieval to locate the data storage unit.

2. The method according to claim 1, wherein index information corresponding to each of the multiple dimensions is constructed based on the multiple dimensions of the metadata tag, comprising: Extract field values ​​from multiple dimensions from the metadata tags, including at least: time dimension, device number dimension, and fault type dimension; An index is constructed for each dimension, and the index information of each dimension is orthogonal to support the combination and operation of any number of dimension index information during retrieval to obtain the location result of the target data storage unit.

3. The method according to claim 1, wherein storing the runtime data in the at least one sub-storage area comprises: Based on the attribute information of the operating data of the first functional system, the operating data of the first functional system is divided into segments to obtain first segment data and second segment data. The first segment data corresponds to the first sub-storage area, and the second segment data corresponds to the second sub-storage area. Write the first fragment data to the first sub-storage area, and simultaneously write the second fragment data to the second sub-storage area.

4. The method according to claim 1, wherein storing the runtime data in the at least one sub-storage area comprises: In response to determining that the priority of the running data of the second functional system is higher than a preset threshold, the running data of the second functional system is written in parallel to the third and fourth sub-storage areas, which are mirror areas of each other. In response to receiving a first signal and a second signal, it is determined that the third sub-storage area and the fourth sub-storage area are in a synchronized state regarding the operating data of the second functional system. The first signal indicates that the operation data of the third sub-storage area regarding the second functional system has been written, and the second signal indicates that the operation data of the fourth sub-storage area regarding the second functional system has been written.

5. The method according to claim 1, further comprising: Obtain the download constraint parameters corresponding to the running data, wherein the download constraint parameters indicate that the downloaded running data meets the user's expected standards; The download constraint parameters are bound to the data storage unit to obtain a data storage unit with download constraint parameters.

6. The method according to claim 5, wherein the download constraint parameter is configured as a parameterizable configuration item, and the method further comprises: In response to changes in download requirements, the configuration items of the download constraint parameters are updated so that the data storage unit can download data according to the updated download constraint parameters.

7. A train data retrieval method, applied to data stored in the train data storage method according to any one of claims 1 to 6, comprising: Obtain a search request for train target services, the search request containing at least one search condition, the search condition corresponding to the dimension information in the metadata tags of the data storage unit; Based on the search criteria, metadata tags of data storage units that match each search criterion are determined from index information of multiple dimensions, resulting in multiple tag sets; Perform set operations on the multiple tag sets to obtain the target metadata tags of the target data storage unit corresponding to the retrieval request; Based on the target metadata tag, return the target data stored in the corresponding target data storage unit.

8. The method according to claim 7, wherein the data storage unit is divided according to the semantic information of the running data, and the data storage unit has semantic information tags. The method further includes: Based on the search criteria, determine the retrieval semantic information regarding the search request; The similarity between the retrieved semantic information and the semantic information tags of each data storage unit is calculated, where the semantic information tags are components of the metadata tags; Return the target data stored in the target data storage unit, wherein the similarity between the semantic information tag of the target data storage unit and the retrieved semantic information is greater than the target threshold.

9. The method according to claim 7 or 8, further comprising: Based on the target data, determine the target output format of the target data, wherein the target output format includes at least one of the following: graphical format, tabular format, file format, and data stream format; The target data is converted according to the target output format to obtain the target output result.

10. A train data storage device, comprising: A storage board module includes multiple storage boards, each storage board having a sub-storage area; The main control module is used to execute the method according to any one of claims 1 to 6 or 7 to 9; The communication bus module is used to realize data interaction between the storage board module and the main control module.

11. The train data storage device according to claim 10, wherein the main control module includes a first main control unit and a second main control unit, the first main control unit and the second main control unit are configured to be connected via a synchronization bus, and the second main control unit is used to synchronize the operating status and data of the first main control unit in real time. In response to the detection of a fault in the first main control unit, the second main control unit is switched to the active state, and the second main control unit takes over the data interaction with the storage board module from the first main control unit.

12. A train, comprising: ontology; The train data storage device according to claim 10 or 11.

Images