Urban rail system database management method, system and equipment based on section cooperation

Abstract

The invention relates to an urban rail system database management method, system and equipment based on section collaboration, and the method comprises the steps: dividing a project into a plurality of sections, and defining global general data, section special data and section overlapping region data of a system database according to the relation between the data type and the sections; labeling and updating the state of each section; the system database realizes multi-section data parallel collaboration through section data sign-in and sign-out modes; and performing identification and incremental management on the version difference, and performing version archiving and publishing. Compared with the prior art, the method has the advantages of realizing segmented data management and multi-team cooperation, improving the management efficiency of the urban rail system database and the like.

Description

Technical Field

[0001] This invention relates to the field of urban rail transit and database management technology, and in particular to a database management method, system and device for urban rail transit systems based on multi-version collaboration of sections. Background Technology

[0002] The preparation of system data for urban rail signaling systems is characterized by a large workload, complex data sources, and high coupling between systems. The system database typically needs to integrate a large number of parameters, including track, train, trackside equipment, and interface information. System data creators compile the system database files based on construction drawings and other parameter documents.

[0003] In traditional system database creation workflows, a single person typically completes the data compilation for the current route. Entering thousands of data entries is time-consuming. Team collaboration often occurs at the project-wide or subsystem level, lacking fine-grained control and status management based on "segment" granularity. This leads to difficulties in effectively distinguishing the data status of different segments in multi-person collaboration scenarios, resulting in duplicate data modifications or conflicting data overwrites. Furthermore, during the route design phase, data parameters are prone to frequent changes, requiring rapid data iteration.

[0004] A search revealed Chinese invention patent application publication number CN115374101A, which discloses a rail transit station-level data management system. The system includes a sensing unit comprising a data acquisition module for collecting station-level data from the urban rail transit system; a carrying unit connected to the data acquisition module for expanding the central capacity of the station-level data, ensuring the availability of the station-level data, automatically deploying the collection tasks, tracking the collection tasks, and monitoring the collection progress in real time; a data unit connected to the carrying unit for sharing and aggregating station-level data from different station-level urban rail transit systems based on different target data buses, storing the station-level data collected by the sensing unit, and processing the stored station-level data; and an intelligent unit connected to the data unit for calibrating and performing feature engineering on the processed station-level data. This existing patent application has the problem of not implementing segment logical isolation and team collaboration management.

[0005] Therefore, there is an urgent need for a system database management method that supports segment-level data management and multi-team collaboration mechanisms to adapt to the increasing complexity of urban rail transit systems and the needs of data engineering teams with multiple collaboration modes. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the existing technology and provide a method, system and device for urban rail transit system database management based on multi-version collaboration of sections.

[0007] The objective of this invention can be achieved through the following technical solutions:

[0008] According to one aspect of the present invention, a method for managing a database of an urban rail transit system based on segment cooperation is provided, the method comprising:

[0009] The project is divided into several sections. Based on the relationship between data types and sections, the system database is defined with global general data, section-specific data, and overlapping section data.

[0010] Mark and update the status of each section;

[0011] The system database enables parallel collaboration of multiple data segments through segment data check-in and check-out methods;

[0012] Identify and incrementally manage version differences, and archive and release versions.

[0013] Preferably, based on the route and equipment distribution of the urban rail project, the project is divided into several sections, and the overlapping areas required for defining the overlapping area data of the sections are defined by combining the overlapping areas of adjacent sections.

[0014] Preferably, the globally universal data is universal across all sections, including a universal parameter table, project configuration information, and line information.

[0015] Preferably, the section-specific data is used only for one section, including the section's trackside equipment table, signal table, and track table.

[0016] Preferably, the segment overlap area data is used for the overlap area of ​​two adjacent segments, and for the logical configuration of shared stations in two adjacent segments.

[0017] Preferably, the segment status includes "to be selected", "selected", "check-in", "check-out", "to be calculated", "calculating", "calculation completed" and "published".

[0018] More preferably, the update of the segment status is automatically updated based on the user operation flow, including:

[0019] The current segment status is "pending selection". When the user performs the "selection" operation, it is first determined whether the segment is in the "check-in" status. If it is, selection is allowed and the status is set to "selected". Otherwise, selection is not allowed.

[0020] Before performing a "check-out" operation on a segment, determine whether the segment is in a check-in state. If it is, check-out is allowed. After check-out, the segment's status is marked as "check-out". Otherwise, it is not allowed to be checked out.

[0021] If the segment status is "selected", the "calculation" operation is allowed. During the calculation, the segment status is set to "calculating" and after the calculation is completed, it is set to "calculation completed".

[0022] Only when the SectorA status is "Computation Complete" is it permissible to publish the data for the current segment and set the current segment status to "Published".

[0023] Preferably, the segment is checked out from the system database of the project and the segment database is exported, wherein the segment database includes global general data, segment-specific data and overlapping area data of the segment.

[0024] More preferably, the globally general data in the segment database can only be referenced; the segment-specific data can be edited and modified, and the overlapping area data of the segment can only be edited and modified after obtaining authorization for overlapping area data management.

[0025] Preferably, after the data processing in the segment database is completed, the operation of checking in the system database is performed. This includes checking the consistency between the globally common data and the overlapping area data of the segment in the segment database and the corresponding data in the system database. If they are consistent, the data in the segment database is merged into the system database; otherwise, the user is prompted to modify the conflicting data before the merging can be completed.

[0026] Preferably, the identification and incremental management of version differences includes: when project data changes, the system database performs a data upgrade operation; and a structured comparison of the database versions before and after the upgrade is performed to identify the changed sections.

[0027] More preferably, for the changed section, the system forces a re-execution of the calculation and verification process.

[0028] More preferably, the method further includes independently publishing data for at least one segment, and uniformly publishing complete project data, wherein the complete project data includes the system master file, subsystem data, and subsystem interface data.

[0029] According to another aspect of the present invention, a database management system for urban rail transit systems based on segment cooperation is provided, the system comprising:

[0030] The project management module divides the project into multiple sections and overlapping sections based on the project route and equipment distribution. It defines the project's global general data, section-specific data, and overlapping section data according to the division, ultimately forming a complete system database.

[0031] The segment management module is used to manage the segment status, which includes "pending selection", "selected", "check-in", "check-out", "pending calculation", "calculating", "calculation completed" and "published".

[0032] The version management module archives the system's main file for each check-in or data upgrade operation; it supports independent publishing of one or more data segments, as well as unified publishing of the entire project data.

[0033] The user permission management module is used to manage the editing permissions of data, including: globally common data can be referenced by any section, but editing permissions are only granted to the "administrator" or "global maintenance" roles; section-specific data can only be edited when checked out of the section, and cannot be changed across sections before check-in; data in overlapping areas can only be changed after authorization by the user management module, and the person responsible for the modification is recorded.

[0034] According to a third aspect of the present invention, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described thereon.

[0035] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described thereon.

[0036] Compared with the prior art, the present invention has the following beneficial effects:

[0037] 1) This invention divides the project into several regions. By defining the global general data, section-specific data and section overlapping area data of the system database, the system database is managed and logically isolated by section, thereby improving the accuracy of data processing. The parallel collaboration of multiple sections is achieved through section data check-in and check-out methods, thereby improving the efficiency of database management.

[0038] 2) Data in different sections of the system database is logically isolated and can be operated in parallel by their respective teams. Overlapping sections can only be edited and modified after obtaining authorization to manage the overlapping data. The designed section status update process improves management efficiency while ensuring the consistency of data between the section database and the system database when multiple sections collaborate, and solves the problems of repeated data modification and conflict overwriting.

[0039] 3) This invention’s version difference analysis and incremental management enables version difference identification and independent release of section data, which can improve version response capabilities and is suitable for urban rail line data preparation scenarios where data changes frequently and rapid iteration is required. Attached Figure Description

[0040] Figure 1 This is a flowchart illustrating the database management method of the present invention;

[0041] Figure 2 This is a flowchart of the segment-based database management process in this invention;

[0042] Figure 3 This is a schematic diagram of the database management system in this invention. Detailed Implementation

[0043] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0044] Example 1

[0045] This embodiment relates to a database management method for urban rail transit systems based on segment cooperation, such as... Figure 1 The method includes the following steps:

[0046] S1: The project is divided into sections through a section binding mechanism, and the project data is bound to the sections to achieve data isolation management;

[0047] S2: Mark the status of the section;

[0048] S3: Enables parallel collaboration of multiple segments through segment data check-in and check-out methods;

[0049] S4: The version management module identifies and incrementally manages version differences, and archives versions.

[0050] S5: Segment data release and project data release.

[0051] In S1, data isolation management is achieved through a segment binding mechanism, which includes the following steps:

[0052] S11: The project divides the system database into sections based on the current project situation and the relationship between data types and sections. These sections are categorized into globally common data, section-specific data, and overlapping section data. Globally common data is project data, applicable to all sections, and cannot be modified at the section level. Section-specific data refers to data related to a specific section; this data belongs to one and only one section. If two sections have overlapping areas (such as functionally intersecting parts), these must be defined as overlapping area data.

[0053] S12: Before performing data creation, editing, or import operations, the user is forced to select a target segment, and the system automatically associates and binds the operation data with that segment.

[0054] S13: Each data record of the segment-specific data is bound to a unique segment identifier to ensure that the data is managed in a logical and physical isolation manner.

[0055] S14: Any segment of the global general data can be modified. This data entry has no segment identifier.

[0056] S15: The overlapping data of the segments is bound to the identifiers of the two segments. When one of the two segments is selected, the current data can be modified.

[0057] In S2, the segment management module marks the segment status, specifically including the following steps:

[0058] S21: The system labels the status of each segment, including: "Pending selection", "Selected", "Check-in", "Check-out", "Pending calculation", "Calculating", "Calculation completed", "Published", etc.

[0059] S22: The segment status is updated automatically based on the user operation process, and is used for data flow control and parallel collaborative scheduling.

[0060] In S3, parallel collaboration of multiple data segments is achieved through segment data check-in and check-out, specifically including the following steps:

[0061] S31: Check out the section from the project's system database and export the section database. The section database contains globally common data, data specific to this section, and data on overlapping areas of this section.

[0062] S32: Different teams perform data entry, calculation, and verification work for different section databases. Globally applicable data in a section database can only be referenced and cannot be edited or modified. Data specific to that section can be edited and modified. Data in overlapping areas of that section requires authorization from the overlapping area data management department before it can be edited or modified.

[0063] S33: Once the data processing for a specific database segment is complete, the check-in operation can be performed to merge the data into the system database. The check-in module is responsible for checking the consistency between the globally common data in the segment database, the overlapping areas of the segment, and the system database. If conflicts are found, an alarm prompt will pop up, listing information such as the comparison of conflicting data, the data modification date, and the person responsible for the data modification, and prompting the user to modify the conflicting data before the merge can be completed. If there are no conflicts, the data will be merged into the system database.

[0064] In S4, the version management module identifies version differences and manages incremental changes, specifically including the following steps:

[0065] S41: When project data changes, the system database performs a data upgrade operation.

[0066] S42: Before the upgrade operation, the system automatically archives the current version of the system database to facilitate subsequent version rollback.

[0067] S43: The system can perform a structured comparison of any two versions of the database, identify which data segments have changed, and generate a report.

[0068] S44: For changed sections, the system forces a re-execution of calculation and verification to ensure the correctness of the data.

[0069] In S5, the release of segment data and project data includes the following steps:

[0070] S51: Provides the ability to publish a single segment or several segments independently.

[0071] S52: Provides the publishing of data information such as system master files, subsystem data, and subsystem interface data for the overall database.

[0072] S53: The release catalog is automatically archived according to the project structure, supports automatic delivery, and automatically generates a release content report after release. Version archiving and rollback of the system database improves the maintainability of the system database.

[0073] Example 2

[0074] This embodiment also relates to a database management method for urban rail transit systems based on segment collaboration. The signaling system project for Metro Line 3 in a certain city has a total length of approximately 30 kilometers, including multiple stations, sections, and interlocking areas. The entire signaling system has a long design cycle, involves many participating units, and has complex data relationships. The project team adopted the system database management method based on segment collaboration proposed in this invention to achieve structured management of system data and cross-team collaboration.

[0075] The system database is stored in the form of XML files on an enterprise-level private cloud platform. Designers use graphical system data preparation software to complete processes such as data creation, calculation, verification, check-in, check-out, and publishing.

[0076] The specific implementation process, including the steps, is described below:

[0077] Step S1: Implement data isolation management through a segment binding mechanism.

[0078] S11: Segmentation and Data Classification Logic

[0079] In this embodiment, based on the route and equipment distribution, the project is divided into three main sections: A, B, and C. Considering overlapping areas such as line junctions and communication relay areas, the following data range is defined:

[0080] Global general data: such as general parameter tables (<Generation_Parameters> Project configuration information () <projects>Information such as route details is applicable across all sections;

[0081] Section-specific data: such as the trackside equipment list within the section ( <zcs>), signal meter ( <signals>), track table ( <tracks>(etc.) belong to only one section;

[0082] Overlapping segment data: such as the logical configuration of shared stations in segments A and B, which have an intersection relationship between the two segments.

[0083] The project management module generates the complete system database for the project, including its section tables. <sector>This contains information for three sections: SectorA (Section_ID=1, Name=SectorA, State=CheckedIn), SectorB (Section_ID=1, Name=SectorB, State=CheckedIn), and SectorC (Section_ID=1, Name=SectorC, State=CheckedIn). Each section includes a section identifier (Section_ID), a section name (Name), and a status identifier (State).

[0084] S12–S13: Data Creation and Binding Process

[0085] Before each data creation, import, editing, or deletion operation, the section management module forces the user to select the target section. Through front-end logic validation and back-end binding mechanism, the newly added data is automatically marked with a "section identifier", such as Section_ID="1".

[0086] Data bound to multiple sections (overlapping areas) is recorded using multiple section identifier fields, such as Section_ID_List = {"1", "2"};

[0087] All data segments are physically stored in the same system database, but are logically isolated.

[0088] S14–S15: Editing permission control mechanism

[0089] Globally applicable data can be referenced by any section team, but editing permissions are only granted to the "Administrator" or "Global Maintenance" roles;

[0090] Section-specific data can only be edited when checking out of the same section; it cannot be changed across sections before checking in.

[0091] Data in overlapping areas can only be modified after authorization from the user management module, and the person responsible for the modification must be recorded.

[0092] S2: Section Management Module, which marks the section setting status, such as... Figure 2 As shown.

[0093] S21: Segment status (including "CheckedIn", "Selected", "CheckedOut", "Pending Calculation", "Calculating", "Calculation Completed", "Published") is stored in the system database. <sectors>The form corresponds to the Sector's attributes. After opening the current project's system database, the system data preparation software's segment management module loads the information and status of all segments and stores them in memory.

[0094] S22: When the user performs the operation "Select" SectorA, it is determined whether SectorA is in the "Check-in" state. If SectorA is in the "Check-out" state, selection is not allowed; if SectorA is in the "Check-in" state, selection is allowed, and the state is set to "Selected". At the same time, the system database interface editing module grants editing permissions for the relevant data of SectorA.

[0095] S23: Before a user performs a "check-out" operation on SectorA, it is determined whether SectorA is in a check-in state. If SectorA is not in a check-in state, it is not allowed to be checked out; if SectorA is in a check-in state, it is allowed to be checked out, and the status of SectorA is marked as "check-out".

[0096] S24: If the SectorA status is "Selected", then the "Calculation" operation is allowed. While the calculation is in progress, in order to prevent data from being tampered with, the SectorA status is set to "Calculation in progress" and after the calculation is completed, it is set to "Calculation completed".

[0097] S25: The function of publishing the current segment is allowed only when the SectorA status is "Completed" and the current Sector status is set to "Published".

[0098] Step S3: Achieve parallel collaboration through check-in and check-out methods.

[0099] S31: When a user checks out data, the system extracts relevant content from the main XML file based on the selected segment to generate a segment XML file:

[0100]

[0101] This section's XML file is a locally editable file.

[0102] S32: Each team performs data entry, simulation calculations, and verification based on independent XML files. Among them:

[0103] <globaldata>Read-only access to globally common data;

[0104] <section>The data for specific sections can be freely edited;

[0105] <overlap>Editing overlapping data requires authorization.

[0106] S33: During check-in, the system compares the structural differences between the local XML and the system's main XML:

[0107] contrast <globaldata>Has it been illegally altered?

[0108] contrast <section>Data structure differences (through node hashes, timestamps, or content comparison);

[0109] merge <section>The content is entered into the system's main XML and in <changelog>Changes are recorded in the middle. If detected... <overlap>If a conflict occurs, a merge strategy will be suggested (keep version, replace, manual confirmation, etc.).

[0110] Step S4: The version management module implements difference identification and incremental management.

[0111] S41: For each check-in or data upgrade operation, the system archives the version of the system master XML (e.g., SystemDB_v001.xml, SystemDB_v002.xml).

[0112] S42: The archiving method supports full snapshots or structural difference archives (Update files based on incremental changes).

[0113] S43: The system can perform a structured comparison on any two XML files, identifying additions, deletions, and modifications. <section> 、 <signal> 、 <overlap>Node; Generate a difference report (in XML diff table format).

[0114] S44: If a segment is identified as having been modified, the system automatically resets its status to "pending calculation" and prompts the user to re-execute the logical calculation or verification.

[0115] Step S5: Segment Data Release and Project Data Release

[0116] S51: Users can select one or more section XML files for independent publication. The published files are named according to the set rules, such as by section ID, like Section_A1_Publish.xml.

[0117] S52: The system supports unified deployment of complete projects, including:

[0118] The system's main XML file (i.e., the system's main file);

[0119] The split subsystem XML files (i.e., subsystem data) (categorized by subsystem type such as ATS, ATC, CBI);

[0120] Subsystem interface files (i.e., subsystem interface data) (such as ATS-ATC interface, ATC-CBI interface, etc.).

[0121] S53: All published content is archived to an automated directory structure, such as:

[0122]

[0123] The system automatically generates a release log, recording information such as the changed section, the operator, and the timestamp.

[0124] Example 3

[0125] This embodiment also relates to a database management system for urban rail transit systems based on segment cooperation, such as... Figure 3 The system includes:

[0126] Project Management Module 1: Based on the project route and equipment distribution, the project is divided into multiple sections, and overlapping areas between sections are identified by combining line intersections and communication relay areas. Based on the division, global general data, section-specific data, and section overlap data for the project are defined, ultimately forming a complete system database where all section data are physically stored in the same system database but logically isolated.

[0127] Segment Management Module 2: This module manages the segment status, which includes "CheckedIn", "Selected", "CheckedOut", "Pending Calculation", "Calculating", "Calculation Completed", and "Published". The segment status is stored in the system database. <sectors>The form corresponds to the Sector's attributes. After opening the current project's system database, all segment information and statuses are loaded and stored in memory. Segment statuses are updated accordingly based on user actions, including: when a segment's status is "Check-in," selection is allowed; after selection, the status is set to "Selected," and editing permissions for the segment's related data are granted. When a segment's status is "Check-out," selection is not allowed. Check-out is only allowed when the segment's status is "Check-in," and after check-out, the segment's status is marked as "Check-out."

[0128] When the segment status is "Selected", the "Calculation" operation is allowed. During the calculation, in order to prevent data from being tampered with, the segment status is set to "Calculation in progress" and after the calculation is completed, it is set to "Calculation completed".

[0129] The function to publish the current segment is allowed only when the segment status is "calculation complete", and the current segment status is set to "published".

[0130] Version Management Module 3: Each check-in or data upgrade operation archives the system's main XML file, supporting either a complete snapshot or structural difference archiving. This module supports independent publishing of one or more section XML files (section data), as well as unified publishing of the entire project. During publishing, the system automatically generates a publishing log and archives all published content to an automated directory structure.

[0131] User Permission Management Module 4: This module manages data editing permissions, including: Global general data can be referenced by any section team, but editing permissions are only granted to the "Administrator" or "Global Maintenance" roles; Section-specific data can only be edited when checking out of the current section and cannot be changed across sections before checking in; Overlapping area data can only be modified after authorization by the user management module, and the person responsible for the modification is recorded.

[0132] Interface Editing Module 5: This module manages the interface editing permissions for section data. It extracts system database parameters to generate a more intuitive human-computer interaction interface and provides editing functionality for the system database. When a user selects a data item for editing, the permission management function in the section management module is invoked to determine and grant editing permissions.

[0133] Example 4

[0134] The electronic device of this invention includes a central processing unit (CPU), which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) or loaded from a storage unit into random access memory (RAM). The RAM may also store various programs and data required for device operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0135] Multiple components in the device are connected to the I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0136] The processing unit performs the various methods and processes described above. For example, in some embodiments, the methods may be implemented as computer software programs tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute the methods by any other suitable means (e.g., by means of firmware).

[0137] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0138] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0139] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0140] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / sectors> < / overlap> < / signal> < / section> < / overlap> < / changelog> < / section> < / section> < / globaldata> < / overlap> < / section> < / globaldata> < / sectors> < / sector> < / tracks> < / signals> < / zcs> < / projects>

Claims

1. A database management method for urban rail transit systems based on segment cooperation, characterized in that, The method includes: The project is divided into several sections. Based on the relationship between data types and sections, the system database is defined with global general data, section-specific data, and overlapping section data. Mark and update the status of each section; The system database enables parallel collaboration of multiple data segments through segment data check-in and check-out methods; Identify and incrementally manage version differences, and archive and release versions.

2. The urban rail transit system database management method based on segment cooperation according to claim 1, characterized in that, Based on the route and equipment distribution of the urban rail project, the project is divided into several sections, and the overlapping areas required for defining the overlapping area data of the sections are defined by combining the overlapping areas of adjacent sections.

3. The urban rail transit system database management method based on segment cooperation according to claim 1, characterized in that, The aforementioned global general data is applicable to all sections, including general parameter tables, project configuration information, and line information.

4. The urban rail transit system database management method based on segment cooperation according to claim 1, characterized in that, The section-specific data mentioned above is only used for one section and includes the section's trackside equipment table, signal table, and track table.

5. A database management method for urban rail transit systems based on segment cooperation according to claim 1, characterized in that, The aforementioned segment overlap area data is used for the overlap area of ​​two adjacent segments and for the logical configuration of shared stations between two adjacent segments.

6. The urban rail transit system database management method based on segment cooperation according to claim 1, characterized in that, The segment status includes "pending selection", "selected", "check-in", "check-out", "pending calculation", "calculating", "calculation completed" and "published".

7. A method for managing a database of an urban rail transit system based on segment cooperation according to claim 6, characterized in that, The update of the segment status is based on automatic updates according to the user operation flow, including: The current segment status is "pending selection". When the user performs the "selection" operation, it is first determined whether the segment is in the "check-in" status. If it is, selection is allowed and the status is set to "selected". Otherwise, selection is not allowed. Before performing a "checkout" operation on a segment, determine whether the segment is in a check-in state. If it is, checkout is allowed. After checkout is completed, the segment's status is marked as "checkout". Otherwise, checkout is not allowed. If the segment status is "selected", the "calculation" operation is allowed. During the calculation, the segment status is set to "calculating" and after the calculation is completed, it is set to "calculation completed". Only when the SectorA status is "Computation Complete" is it permissible to publish the data for the current segment and set the current segment status to "Published".

8. A method for managing a database of an urban rail transit system based on segment cooperation according to claim 1, characterized in that, Check out the segment from the project's system database and export the segment database, which includes global general data, segment-specific data, and overlapping area data of the segment.

9. A method for managing a database of an urban rail transit system based on segment cooperation according to claim 8, characterized in that, The global general data in the segment database can only be referenced; the segment-specific data can be edited and modified, and the overlapping area data in the segment can only be edited and modified after obtaining authorization for overlapping area data management.

10. A method for managing a database of an urban rail transit system based on segment cooperation according to claim 1, characterized in that, Once the data in the segment database is processed, the process of checking it into the system database is executed. This includes checking the consistency between the globally common data and the overlapping data in the segment database and the corresponding data in the system database. If they are consistent, the data in the segment database is merged into the system database; otherwise, the user is prompted to modify the conflicting data before the merging is completed.

11. A method for managing a database of an urban rail transit system based on segment cooperation according to claim 1, characterized in that, Version difference identification and incremental management include: when project data changes, the system database performs a data upgrade operation; and a structured comparison of the database versions before and after the upgrade is performed to identify the changed sections.

12. A method for managing a database of an urban rail transit system based on segment cooperation as described in claim 11, characterized in that, For changed sections, the system forces a re-execution of the calculation and verification process.

13. A method for managing a database of an urban rail transit system based on segment cooperation as described in claim 11, characterized in that, The method also includes independently publishing data for at least one segment, as well as uniformly publishing complete project data, which includes system master files, subsystem data, and subsystem interface data.

14. A system utilizing the urban rail transit system database management method based on segment cooperation as described in any one of claims 1 to 13, the system comprising: The project management module divides the project into multiple sections and overlapping sections based on the project route and equipment distribution. It defines the project's global general data, section-specific data, and overlapping section data according to the division, ultimately forming a complete system database. The segment management module is used to manage the segment status, which includes "pending selection", "selected", "check-in", "check-out", "pending calculation", "calculating", "calculation completed" and "published". The version management module archives the system's main file for each check-in or data upgrade operation; it supports independent publishing of one or more data segments, as well as unified publishing of the entire project data. The user permission management module is used to manage the editing permissions of data, including: global general data can be referenced by any section, but editing permissions are only granted to the "administrator" or "global maintenance" roles; Section-specific data can only be edited when checking out of the same section; it cannot be changed across sections before checking in. Data in overlapping areas can only be changed after authorization from the user management module, and the person responsible for the modification must be recorded.

15. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 13.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 13.

Images