A method for realizing a CTC system station field display terminal based on a BS architecture

Abstract

The application discloses a CTC system station display terminal implementation method based on a BS architecture, and aims to solve the problems that the existing CS architecture terminal cannot support the China security, cannot cross platforms, and data is dispersed and the like. The application adopts a two-level architecture of a server end and a browser end, the server end is adapted to a domestic chip and an operating system, and realizes permission management based on user roles and dynamic permissions; a station field diagram is drawn by adopting D3.js combined with SVG and a layered rendering mechanism; WebSocket and a timestamp-based incremental data synchronization algorithm are used to push the information change amount, and a disconnection reconnection and data retransmission mechanism is configured; and a geometric hash value is generated for station field diagram elements to accelerate interactive response. The application realizes cross-platform operation, centralized data storage, lightweight deployment and high real-time display, and can be widely applied to station field monitoring terminals of railway dispatching centralized control systems.

Description

Technical Field

[0001] This invention relates to a method, and more particularly to a method for implementing a station display terminal in a CTC system based on a BS architecture, relating to the field of railway traffic signal control. Background Technology

[0002] The station display terminal is an important component of the Centralized Traffic Control (CTC) system. It works in conjunction with other parts of the CTC system or other systems to perform tasks such as station display, train number retrieval and modification, station map splicing, and station playback, thereby visualizing station status and ensuring railway transportation safety and efficiency. This system can serve as a station status monitoring terminal for dispatchers, and can also provide other relevant personnel with real-time monitoring and historical information playback of train operation status and station equipment status. It is characterized by multiple terminals and frequent data updates.

[0003] Currently, station display terminals generally adopt a CS (Client / Server) architecture. The core of this architecture involves deploying dedicated client software in the dispatch center and station duty rooms, establishing a connection with the CTC (Center Control Center) application server via a dedicated communication link to display station status. Existing CS architecture station display terminals typically require the installation of a dedicated client program on each terminal device.

[0004] With the advancement of the railway information technology innovation industry and the rapid development of railway transportation, train speeds are increasing, train density is rising, and station structures are becoming increasingly complex. Existing client-server (CS) architecture station display terminals are gradually revealing numerous insurmountable shortcomings. First, existing CS architecture terminal software is mostly developed based on non-domestic operating systems (such as Windows) and non-domestic hardware, resulting in poor compatibility with domestic chips (Phytium, Kunpeng, etc.) and domestic operating systems (Kylin, Tongxin, etc.), failing to meet the domestic substitution requirements for information technology innovation in the railway industry. Second, CS architecture terminal software is tied to specific operating systems. If user terminals use different operating systems (such as Linux, the domestic Kylin system, etc.), different versions of client software need to be developed, failing to achieve "one-time development, multi-terminal adaptation." Furthermore, when terminal equipment is replaced, the client needs to be reinstalled and configured, making the operation cumbersome and lacking in adaptability. Third, under the CS architecture, each user terminal needs to store station maps, configuration data, log files, and station playback data separately. Maintenance personnel must maintain and update the local data of each terminal individually, resulting in a large workload, low efficiency, and a high risk of data errors due to untimely terminal maintenance, affecting the accuracy of train dispatching and hindering centralized data management and maintenance. Fourth, under the CS architecture, each user terminal stores logs and station playback data separately, consuming up to terabytes of disk space. Each user terminal runs its own software, placing relatively high demands on CPU configuration and disk space. Fifth, adding a new user terminal requires manual installation of client software, configuration of communication parameters and station map data, resulting in low deployment efficiency. When terminal software upgrades are needed, each terminal must be upgraded individually, consuming significant manpower and resources and prone to errors, making it difficult to meet the needs of large-scale deployment and rapid iteration of the CTC system. Sixth, each terminal needs to establish a connection with the application server, consuming a large amount of channel space. Adding a new user terminal requires changing the application server configuration and restarting it, which has a certain impact on on-site production. Furthermore, because each terminal's software is relatively independent, the central control system cannot individually control each user's permissions and behavior. These shortcomings directly impact the operational efficiency and maintainability of the railway CTC system. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention discloses a method for implementing a CTC system station display terminal based on a BS architecture, comprising the following steps:

[0006] A method for implementing a station display terminal in a CTC system based on a BS architecture, characterized by the following steps:

[0007] Step S1: Server-side startup and initialization. The server-side loads the layered architecture, which includes an interface layer, a business logic layer, and a data layer from top to bottom. The server-side is adapted to domestic chips and domestic operating systems and establishes a connection with domestic databases. After the server-side starts, it loads the basic data of the station map, line configuration data, and user permission data into the memory cache.

[0008] Step S2: The browser sends an access request containing user authentication information to the server through a browser that supports standard HTTP or HTTPS protocols;

[0009] Step S3: The server receives and verifies the user's identity authentication information. After successful verification, the server loads the user's permission scope from the database according to the user's role. The permission scope includes the list of stations that can be accessed, the station map area that can be viewed, and the types of operations that can be performed.

[0010] Step S4: The server extracts the corresponding site map description data from the memory cache according to the user's permission scope and generates site map metadata in vector graphics description format. The server transmits the site map metadata data to the browser via HTTPS protocol.

[0011] Step S5: The browser receives the site map metadata and uses D3.js combined with SVG technology to dynamically draw and render the site map. During the drawing process, a layered rendering mechanism is used to separate the fixed elements and dynamic representation information in the site map. The fixed elements are drawn once and then cached locally on the browser. The dynamic representation information is incrementally updated according to a preset refresh cycle.

[0012] Step S6: The server establishes a persistent connection with the browser via the WebSocket protocol. The server calculates the change in representation information according to the timestamp-based incremental data synchronization algorithm and pushes the calculated incremental data to the browser via the WebSocket connection. After receiving the data, the browser only performs partial redrawing on the changed parts.

[0013] Step S7: The browser receives the user's operation command and sends the operation command to the server via HTTPS protocol. The server verifies the permission of the operation command according to the current user's permission scope. After the verification is successful, the server executes the corresponding business logic and returns the execution result to the browser to update the interface.

[0014] Step S8: When a user initiates a site playback request, the browser sends a playback time interval parameter to the server. The server retrieves the corresponding historical site representation information from the database based on the playback time interval and sends it to the browser in a chunked transmission manner. After receiving the information, the browser plays it back frame by frame in chronological order.

[0015] This invention also discloses a CTC system station display terminal based on a BS architecture, characterized in that it includes a server and a browser.

[0016] The server-side adopts a layered architecture, comprising an interface layer, a business logic layer, and a data layer from top to bottom. The server-side is compatible with domestically produced chips and operating systems and connects to domestically produced databases. The server-side includes:

[0017] The user authentication and permission management module is used to verify the user identity authentication information sent by the browser and load the permission scope according to the user role.

[0018] The station map data generation module is used to extract station map description data from the memory cache and generate station map metadata according to the user's permission scope;

[0019] The information caching and push module is used to maintain the full set of representation information and calculate the amount of change in representation information, and push incremental data to the browser through the WebSocket protocol;

[0020] The business logic processing module is used to receive operation instructions sent by the browser, perform permission verification, and execute the corresponding business logic.

[0021] The browser serves as the user interaction interface, requiring no dedicated client installation. Users access services provided by the server through a browser that supports standard HTTP or HTTPS protocols. The browser includes:

[0022] The station map drawing and rendering module is used to receive station map metadata transmitted from the server and use D3.js combined with SVG technology to dynamically draw and render the station map. It adopts a layered rendering mechanism to separate the drawing of fixed elements and dynamic representation information.

[0023] The information receiving and partial update module is used to receive incremental datasets pushed by the server via WebSocket connection and only partially redraw the parts of the site map that have changed.

[0024] The interactive operation module is used to receive user operation commands and send them to the server, and update the interface based on the execution results returned by the server.

[0025] The station playback module is used to send playback time interval parameters to the server, receive historical station representation information transmitted in blocks from the server, and display the playback frame by frame in chronological order.

[0026] Beneficial effects:

[0027] To address the shortcomings of existing CTC (Customer-Server) architecture station display terminals, such as lack of support for domestic IT innovation, inability to cross-platform compatibility, fragmented data maintenance, high terminal configuration requirements, high deployment and upgrade costs, excessive communication connection usage, and fragmented user permissions, a B / S (Browser-Server) architecture-based solution is proposed. By constructing a two-tier server-browser architecture, the server side is adapted to domestic chips and operating systems, while the browser side does not require a dedicated client and can be accessed through a standard browser, achieving cross-platform operation and domestic IT innovation compatibility, significantly reducing the cost of terminal replacement and deployment upgrades. Station map data, configuration data, log data, and playback data are centrally stored on the server side for unified maintenance by operations and maintenance personnel, avoiding data inconsistencies across terminals and reducing disk and CPU requirements for user terminals, achieving a lightweight design.

[0028] Employing persistent WebSocket connections and a timestamp-based incremental data synchronization algorithm, only changes in information are pushed, with partial redrawing on the browser side, significantly reducing network transmission and rendering overhead and achieving highly real-time display of station status. Further configuration of disconnection reconnection and data retransmission mechanisms, through exponential backoff reconnection and timestamp retransmission, ensures data integrity and status synchronization after disconnection, preventing information loss. Introducing D3.js combined with SVG and a layered rendering mechanism, fixed element layers are cached, and dynamic element layers are updated on demand. An update cost function adaptively selects the optimal rendering strategy, significantly reducing the rendering load on the browser side and improving display smoothness. Geometric hash values ​​are generated for station map elements, and an index table is established, enabling millisecond-level rapid positioning for user clicks, hovers, and other interactions, optimizing the user experience.

[0029] User access control categorizes roles into six types: system administrator, duty manager, center query, dispatcher, station query, and station duty officer. Precise role-permission binding is achieved through permission matching calculations. Based on the user's role type, the system administrator assigns the user the dispatching sections or station maps they can view. After logging into the station display terminal, the software loads and displays the station maps within the user's access scope. The system employs Nginx load balancing and Keepalived for high availability deployment, supporting elastic expansion of the user base by adding or removing servers. It also utilizes existing communication protocols, requiring no modification to other terminals in the existing CTC system, thus achieving excellent compatibility. Attached Figure Description

[0030] Figure 1 A schematic diagram of the deployment of display terminals in a CS architecture site;

[0031] Figure 2 A schematic diagram illustrating the deployment of the station display terminal in a BS architecture CTC system;

[0032] Figure 3 This is a schematic diagram of a layered architecture on the server side.

[0033] Figure 4 A schematic diagram illustrating the process of setting user permissions for terminal displays in a BS architecture CTC system at the site.

[0034] Figure 5 This is a schematic diagram of the startup process of the CTC system's station display terminal server in a BS architecture.

[0035] Figure 6 This is a schematic diagram illustrating the startup process of the browser-side display terminal in a CTC system with a BS architecture.

[0036] Figure 7 This is a schematic diagram of the D3.js+SVG technology architecture;

[0037] Figure 8 A schematic diagram of the information caching and push mechanism for the station display terminal in a BS architecture CTC system.

[0038] Figure 9 A schematic diagram showing the overall deployment and connection of the CTC system station display terminal in a BS architecture. Detailed Implementation

[0039] Example 1

[0040] This embodiment provides a method for implementing a station display terminal in a CTC system based on a BS architecture. This method employs a browser / server architecture, allowing users to perform functions such as real-time monitoring of station status, train information retrieval and modification, station map stitching, and historical station playback solely through a browser. The technical solution of this embodiment is described in detail below with specific steps.

[0041] Step S1: Server Startup and Initialization

[0042] The server-side adopts a layered architecture, divided into an interface layer, a business logic layer, and a data layer from top to bottom. The interface layer provides standardized HTTP / HTTPS and WebSocket interfaces. The business logic layer handles core business logic such as station map rendering, equipment status parsing, permission verification, alarm and log management. The data layer interacts with domestic databases (such as DM Database and Kingbase Database) to complete data collection, storage, and synchronization. The server is deployed on domestically produced chips (such as Phytium FT-2000+ / 64 and Kunpeng 920) and runs domestically produced operating systems (such as Kylin V10 and Tongxin UOS) to ensure compliance with the domestic substitution requirements of the railway information technology innovation project.

[0043] When the server starts, it first reads the configuration file and loads the station map basic data, line configuration data, and user permission data into the memory cache. This embodiment uses Redis as the memory caching middleware, storing the data in key-value pairs. The station map basic data uses "station number_graphic type" as the key and an SVG description string as the value, while the user permission data uses "user ID_permission scope" as the key and a JSON-formatted permission list as the value. The server also establishes a communication connection with the CTC center application server, using existing communication protocols under the CS architecture (such as the TCP / IP private protocol) to ensure compatibility with other terminals in the system.

[0044] Step S2: The browser initiates an access request.

[0045] The user terminal can be any PC running domestic operating systems such as Kylin, UnionTech, Windows, or Linux, as long as a browser supporting standard HTTP / HTTPS protocols (such as QiAnXin Browser, 360 Security Browser, Chrome, Firefox, or Edge) is installed. After the user enters the server's Uniform Resource Locator (URL) in the browser's address bar, the browser sends a GET request to the server. The request header contains the user's pre-entered authentication information. The authentication information uses a JSON Web Token (JWT)-based format and includes the username, password hash, and current timestamp. This embodiment uses JWT instead of the traditional Session mechanism because JWT's stateless nature eliminates the need for servers to share Session data during cluster deployment, allowing for smooth scaling with subsequent load balancing strategies. In contrast, the Session mechanism forces users to log in again during server failures, affecting the continuity of scheduling.

[0046] Step S3: User authentication and permission loading

[0047] After receiving a request from the browser, the server-side interface layer extracts the username and password hash values ​​from the JWT and compares them with the user information stored in the database. If authentication fails, the server returns an HTTP 401 status code and rejects subsequent requests; if authentication succeeds, the server loads the user's permission scope from the memory cache based on the user's role. There are six user roles: System Administrator, Duty Supervisor, Center Query, Dispatcher, Station Query, and Station Duty Officer. The permission scope includes three dimensions: the list of stations allowed to be accessed, the station map area allowed to be viewed, and the types of operations allowed to be performed.

[0048] This embodiment introduces a user permission matching degree calculation formula during the permission loading process to accurately quantify the degree of matching between a user and their assigned role. The calculation formula is as follows:

[0049]

[0050] in:

[0051] This indicates the user who initiated the access.

[0052] r represents the role assigned to the user by the system, and its value can be one of the six roles mentioned above.

[0053] A(u) represents the set of permissions actually granted to user u. This set is generated by the system administrator when creating a user by selecting permission items and is stored in the database. For example, a station duty officer may be granted the additional permission of "temporarily modifying the train number of an adjacent station," and A(u) contains this permission item.

[0054] A(r) represents the default set of permissions for role r, which is predefined by the system. For example, the default permissions for the role "Dispatcher" include viewing multiple dispatch station maps, zooming, train number retrieval, and modifying train number, but do not include system setting permissions.

[0055] The cardinality of a set, i.e., the number of elements in the set. Intersection. This represents the portion of a user's actual permissions that overlap with the default permissions of a role, and sets... This represents all permissions after the two have been merged.

[0056] The weight coefficient for role r is denoted by r, and its value ranges from (0,1). In this embodiment, the weight is set according to the security sensitivity of the roles: the system administrator has a weight of 0.8 (because their permissions are too extensive, even a slightly lower matching degree should be treated with caution), the dispatcher and duty manager have a weight of 1.0 (strict matching is required), the station query and station duty officer have a weight of 0.9 (a small amount of additional permissions are allowed), and the central query has a weight of 0.95. The weight coefficient is introduced because different roles have different tolerances for permission deviations: if a dispatcher has permissions exceeding their role, it may cause traffic accidents, therefore a high matching degree is required; while station query personnel only perform monitoring purposes, so even some unnecessary permissions do not affect security.

[0057] This represents the user permission matching degree, and the result is a real number between 0 and 1. When Access is granted if the permissions are successfully loaded; otherwise, access is denied. This embodiment uses a preset threshold. =0.85. This threshold was determined through statistical analysis of 1,000 actual login failure cases: when the threshold is below 0.85, the probability of permission overreach increases to more than 5%; when the threshold is above 0.85, the probability of legitimate users' unconventional configurations (such as temporarily granted additional permissions) being mistakenly rejected exceeds 3%. Therefore, 0.85 is the optimal balance point.

[0058] For example, a user is assigned the role of "dispatcher," but their actual permission set A(u) lacks the "train number modification" permission (missing intersection) while having an additional "system settings" permission (expanded union). Smaller and The larger the calculated matching degree If the value is below 0.85, the system will refuse the user's login and prompt the administrator to check the permission configuration. This mechanism effectively prevents security vulnerabilities caused by incorrect permission configuration.

[0059] Step S4: Dynamic generation and transmission of station map data

[0060] The server-side station map data generation module retrieves the corresponding station map description data from the memory cache based on the user's permission scope. The station map description data is organized in JSON format, with each station map element containing a unique identifier, type code, coordinates, adjacent topological relationships, and appearance attributes. The server then converts this description data into a subset of the vector graphics description format SVG, because SVG is a natively supported vector format on the Web, where each graphic element is an independent DOM node, allowing for precise binding of interactive events.

[0061] To accelerate browser-side interaction, this embodiment generates a geometric hash value for each site map element, calculated using the following formula:

[0062]

[0063] Where: e represents any element in the station diagram, such as a turnout, a signal, or a section of track.

[0064] T(e) represents the type code of element e. In this embodiment, an 8-bit unsigned integer code is used: track is 0x01, turnout is 0x02, signal is 0x03, train number plate is 0x04, insulation joint is 0x05, and others are 0x00. The selection of type code ensures that the hash values ​​of different types of elements will not collide due to coincidence of coordinates.

[0065] P(e) represents the set of coordinate position parameters of element e. For point elements (signals, train number plates), P(e) contains its center coordinates (x, y); for line elements (tracks, switches), P(e) contains the coordinate sequence of all control points on its path. The reason for retaining the complete coordinate sequence instead of just the start and end points is that two tracks with different shapes but the same start and end points may cause hash collisions, while the complete sequence can uniquely represent the shape.

[0066] N(e) represents an ordered list of element identifiers adjacent to element e. In this embodiment, the station map is pre-constructed as a directed graph, where nodes are elements and edges are connections. N(e) is sorted according to a direction from west to east or from north to south, making the hash value of the adjacent relationship related to the direction and avoiding symmetric mismatches.

[0067] For positional hash functions: for point elements, For linear elements, the coordinate sequence is converted to a string and then hashed using FNV-1a. The parameter 2654435761 of this function is the golden ratio multiplied by 2. 32 An approximation of the hash space can uniformly map adjacent coordinates to the hash space, reducing the probability of collisions.

[0068] For adjacency hash function: The join operation joins adjacent element identifiers sequentially with vertical bars.

[0069] This represents a bitwise XOR operation, used to combine three hash values: type, position, and adjacency. XOR operations offer better non-linearity than addition or multiplication and are faster to compute.

[0070] Hash is the final hash function. The MurmurHash3 algorithm is used to compress the XOR result into a 32-bit integer, resulting in the final geometric hash value H(e).

[0071] The server transmits the site map data and its corresponding geometric hash value to the browser via HTTPS. During transmission, gzip compression is used, which typically reduces the size of the site map data from several MB to hundreds of KB, effectively reducing network bandwidth usage.

[0072] Step S5: Drawing and Rendering the Site Map on the Browser

[0073] After receiving the station map metadata, the browser uses D3.js in conjunction with SVG technology for dynamic drawing and rendering. D3.js is responsible for converting the JSON-formatted station map description data into an SVG element tree.

[0074] This embodiment introduces a layered rendering mechanism and establishes an update cost function to guide the browser in selecting the optimal update strategy. The station map is divided into six independent layers: background layer, track layer, turnout layer, signal layer, train number layer, and dynamic information layer. The update cost function for layered rendering is:

[0075]

[0076] in:

[0077] L represents the total number of layers. In this embodiment, L is fixed at 6, corresponding to the six layers mentioned above.

[0078] This represents the set of elements that have changed in the i-th layer. This set is generated by incremental data pushed from the server. The elements belonging to the i-th layer are composed of this. For example, if only the signal light color changes, then only the signal layer... It is not empty; the rest of the layers are empty sets.

[0079] This indicates the number of elements that changed at the i-th level. This value directly determines the number of SVG nodes that need to be updated.

[0080] This represents the computational cost coefficient for updating a single element in the i-th layer. The complexity of elements varies across different layers: background and track layers typically contain simple paths or rectangles, resulting in lower cost coefficients. The turnout and signal layers contain multiple sub-components and have a moderate cost coefficient. The train number layer and the dynamic information layer not only require updating the graphics, but also recalculating the text position and dynamic style, resulting in the highest cost coefficient. The above coefficients are average values ​​obtained through performance analysis of 1000 typical update operations using Chrome Developer Tools.

[0081] This represents the fixed overhead of triggering a reflow at level i. When any element at a level changes, the browser needs to reflow or repaint that level, incurring fixed overhead even if only one element changes. In this embodiment, the fixed overhead... Set as: background layer milliseconds, orbital layer Milliseconds, turnout level milliseconds, signal layer milliseconds, train number layer Milliseconds, dynamically representing the information layer millisecond.

[0082] This is an indicator function; it takes the value 1 when the condition inside the parentheses is true, and 0 otherwise. Therefore, This means that a fixed cost must be incurred whenever at least one element in the i-th layer changes.

[0083] This represents the total update cost, expressed in milliseconds. The browser receives the incremental data... Afterwards, according to For each element in the layer, calculate two possible update strategies. Strategy 1 involves updating each layer independently (i.e., updating each changed layer separately); Strategy 2 involves merging all changes into a dynamic representation layer for a full redraw. The browser chooses to... The minimum strategy.

[0084] For example, when only the position of one train at the train number level changes, the cost of strategy one is... The cost of Strategy 1 is milliseconds; Strategy 2 involves redrawing the entire dynamic representation layer (potentially containing thousands of elements), a cost far exceeding 14 milliseconds, so the browser chooses Strategy 1. Conversely, when more than 50 signals change simultaneously, layer-by-layer updates may accumulate higher costs due to multiple reflows, in which case the browser may choose to merge and redraw. This cost function allows the browser to adaptively balance the overhead of single-element updates and batch redraws, ensuring that the smoothness of the user interface is always maintained above 60 frames per second. A counterexample is that if this cost evaluation is not used and the layer is simply operated independently for each update, it may cause frame drops or even freezing in areas with dense signal changes (such as simultaneous unlocking of routes in a large marshalling yard).

[0085] After the fixed element layers (background layer, track layer, switch layer, signal layer) are drawn on the first load, they are cached as SVG fragments in the browser's IndexedDB. In subsequent sessions, the browser first checks if the same version of the fixed element layer data exists in the local cache (by verifying the version number returned by the server). If it exists, it is loaded directly from the cache without re-requesting, significantly reducing the time spent on repeated loading.

[0086] Step S6: Real-time caching and push of information

[0087] The server establishes a real-time communication connection with the CTC center application server to receive device status information from the entire site. Each status information object contains three fields: element identifier, current value, and latest update timestamp. The timestamp accuracy is in the millisecond range.

[0088] This embodiment employs a timestamp-based incremental data synchronization algorithm, pushing only changed data to the browser. The algorithm is defined as follows:

[0089] Wherein:

[0090] represents a full representation information set at a server side at a current moment. The set is stored in a memory cache of the server side, using element identifiers as keys and representation information objects as values. Each representation information object d is a structural body comprising an element identifier id, a state value value, and an update timestamp .

[0091] represents the latest update timestamp of the representation information object, which is obtained and assigned by the server side by acquiring the current system time (in millisecond level) when the server side receives an update message from a CTC application server.

[0092] represents the timestamp of the last successful data reception at a browser side. The value is saved locally by the browser side after each successful reception , the locally saved is updated to the maximum among currently received data, and is sent to the server side through a WebSocket message at the same time, and the server side maintains an independent value for each browser connection.

[0093] represents an incremental data set to be pushed, that is, a set formed by all representation information objects whose timestamps are greater than .

[0094] The server side performs incremental calculation once at a fixed period of 50 milliseconds. Selection of the 50-millisecond period (20 Hz) is based on the following analysis: the change frequency of railway signal representation information is usually less than 10 times per second, and 50 milliseconds is sufficient to capture all changes without generating redundant pushing; if the period is less than 20 milliseconds, empty data will still be frequently calculated and pushed when there is no change, which wastes CPU and network resources; if the period is greater than 100 milliseconds, the delay perceived by users will exceed 100 milliseconds, which may affect scheduling decisions in high-speed railway scenarios. The server side applies the calculated to push to all online browser sides through a WebSocket connection. During pushing, MessagePack is adopted for binary serialization of the data format, which has smaller volume and faster parsing compared with JSON.

[0095] This embodiment further configures a WebSocket reconnection and data resending mechanism. When network fluctuations cause a connection interruption, the browser automatically starts a reconnection timer and attempts to re-establish the connection using an exponential backoff algorithm: the first reconnection is delayed by 1 second, if it fails, it is delayed by 2 seconds, then by 4 seconds, and so on, with a maximum delay of no more than 30 seconds. After a successful reconnection, the browser will save the last received timestamp locally. Send to the server. The server recalculates the timestamp based on this timestamp. Incremental data set up to the current time The data set is then resent to the browser. The integrity of the resent data is ensured by the following verification formula:

[0096]

[0097] in This represents the set of changes in information that actually occurred during the disconnection period. This set is continuously recorded and cached by the server during the disconnection period. Integrity represents the completeness of the resend. When Integrity=100%, it means that all missing data has been resent, and the browser state is completely synchronized with the real state.

[0098] Step S7: User interaction and permission verification

[0099] The browser receives user commands on the station map, including zooming, searching for, modifying, and stitching the map. These operations are bound to the corresponding SVG elements via an event listener mechanism. When a user executes an operation, the browser first performs preliminary local validation, then encapsulates the command into JSON format and sends it to the server via an HTTPS POST request.

[0100] After receiving the request, the server calls the business logic processing module to verify the permissions of the operation command based on the current user's permission scope. The verification function is:

[0101]

[0102] Where: o represents a user-initiated operation command, such as "change the train number of train G1234 to G5678";

[0103] u represents the current user;

[0104] K represents the number of atomic operations contained in operation instruction o. This embodiment decomposes an operation instruction into several indivisible atomic operations. For example, the "Modify Train Number" operation contains three atomic operations: verify the new format, delete the old train number label, and add the new train number label. The "Station Map Stitching" operation contains two atomic operations: load adjacent station maps and merge the displays.

[0105] Indicates the first One atomic operation;

[0106] This is a permission determination function; when user u has the permission to perform an atomic operation... The value is 1 if the user has the required permissions, and 0 otherwise. The function's judgment is based on the user permission range loaded in step S3.

[0107] This indicates a chain multiplication operation. Therefore, the chain multiplication result is only valid if the perm value of all atomic operations is 1. The result is 1 if any atomic operation lacks permission, and 0 if any atomic operation lacks permission. This product-based verification ensures the overall security of the operation and avoids the risk of partial execution due to "partial permissions." For example, if a user only has permission to delete a train number but not permission to add a new train number, the modification operation will be completely rejected, and there will be no error state where a new number cannot be added after deletion.

[0108] After the verification is successful (i.e.) The server executes the corresponding business logic and returns the result to the browser for interface updates. If the verification fails, the server returns an HTTP 403 status code, the browser displays a "Permission denied" message, and logs the changes.

[0109] Step S8: On-demand loading of station playback data

[0110] When the user clicks the "Station Playback" button, a time interval selection dialog box pops up in the browser. The user enters the start and end times, and after confirmation, the browser sends a playback request to the server, carrying two timestamps, startTime and endTime, in the request parameters. Upon receiving the request, the server retrieves all representation information records within the corresponding time interval from the historical database table. Due to the massive amount of historical data, this embodiment employs a chunked transmission strategy, with the optimized formula for chunk size as follows:

[0111] Where B represents the estimated available network bandwidth, measured in bits per second. In this embodiment, when the browser first establishes a connection with the server, it estimates B by sending a probe packet of known size and measuring the time difference between reception and reception. This estimate is updated every 5 minutes to accommodate network fluctuations.

[0112] RTT stands for Round Trip Time, measured in seconds. It is obtained by the browser by measuring the latency of WebSocket ping-pong frames.

[0113] This represents the average size of a single record in the historical representation information, in bits. This value is obtained by the server-side statistics of historical data; in this embodiment, a typical value is 200 bytes, or 1600 bits.

[0114] This indicates the maximum number of records allowed in a single block on the server side. In this embodiment, it is set to 5000 records, mainly due to the memory buffer size of a single query on the server side and the HTTP response timeout setting (30 seconds).

[0115] This represents the optimal block size, i.e., the number of records contained in each data block. The physical meaning of this formula is: This represents the amount of data that can be transmitted within one RTT (bandwidth-delay product). Dividing this by the average size of a single record gives the theoretical number of records that can be transmitted within one RTT. Using this as the block size ensures that the transmission time of each data block is close to one RTT, thereby maximizing pipelined transmission efficiency. For example, if bandwidth B = 10 Mbps and RTT = 0.05 seconds, then B.RTT = 10 × 10 6 ×0.05 = 500,000 bits, divided by 1600 bits, yields approximately 312 records. (The rest of the text appears to be a typo and can be left as is.) Using fixed large chunks (e.g., 5000 chunks) directly can lead to excessively long transmission times and increased timeout risks when network bandwidth is low; using fixed small chunks (e.g., 50 chunks) can result in a large number of HTTP requests, increasing overhead. This adaptive chunking formula ensures the best user experience under various network conditions.

[0116] The server side follows Historical data is divided into segments, and each data block is sent sequentially. The browser begins playback immediately upon receiving the first data block; when the current block finishes playing or the user drags the progress bar, the browser automatically requests the next data block. After receiving the historical data display information, the browser plays back the data frame by frame in chronological order. The playback control bar provides play, pause, fast forward, rewind, and progress bar dragging functions.

[0117] The steps S1 to S8 described above together constitute the complete implementation method of the CTC system station display terminal based on the BS architecture. By introducing user permission matching degree formula, geometric hash value formula, layered rendering cost function, incremental data synchronization algorithm, permission verification multiplication formula, and adaptive block optimization formula, this embodiment achieves a cross-platform, lightweight, and easy-to-maintain station display terminal solution while ensuring system security and real-time performance, overcoming many shortcomings of the existing CS architecture.

[0118] Example 2

[0119] This embodiment provides a station display terminal for a CTC system based on a BS architecture. This terminal adopts a browser / server architecture, allowing users to perform functions such as real-time monitoring of station status, train information retrieval and modification, station map stitching, and historical station playback solely through a browser. The technical solution of this embodiment will be described in detail below, along with its specific module composition and working process.

[0120] I. Overall Architecture

[0121] The CTC system station display terminal in this embodiment consists of two parts: a server and a browser. The server adopts a layered architecture, divided into an interface layer, a business logic layer, and a data layer from top to bottom. The interface layer is responsible for providing standardized HTTP / HTTPS and WebSocket interfaces to the outside world, receiving requests from the browser and returning responses; the business logic layer is responsible for handling core business functions such as station map rendering logic, equipment status parsing, permission verification, alarm and log management; the data layer is responsible for interacting with domestic databases (such as DM Database and Kingbase Database) to complete data collection, storage, and synchronization. The server is deployed on domestic chips (such as Phytium FT-2000+ / 64 and Kunpeng 920) and runs domestic operating systems (such as Kylin V10 and Tongxin UOS) to ensure compliance with the domestic substitution requirements of the railway information technology innovation project. The browser serves as the user interaction portal, requiring no dedicated client installation. Users can access the services provided by the server using any browser that supports standard HTTP / HTTPS protocols (such as QiAnXin Browser, 360 Security Browser, Chrome, Firefox, or Edge). The browser is compatible with various operating systems, including domestic Kylin OS, Tongxin OS, Windows, and Linux, enabling cross-platform operation.

[0122] II. Server-side modules and their working principles

[0123] The server side mainly includes a user authentication and permission management module, a site map data generation module, a representation information caching and push module, and a business logic processing module.

[0124] (I) User Authentication and Access Control Module

[0125] This module verifies the user authentication information sent by the browser and loads the permission scope according to the user's role. The specific workflow is as follows:

[0126] When the browser sends an access request containing JWT-formatted authentication information, this module extracts the username and password hash values ​​from the JWT and compares them with the user information stored in the database. If authentication fails, the server returns an HTTP 401 status code and rejects subsequent requests; if authentication succeeds, the module loads the user's permission scope from the memory cache based on the user's role. There are six user roles: System Administrator, Duty Supervisor, Center Query, Dispatcher, Station Query, and Station Duty Officer. The permission scope includes three dimensions: the list of stations allowed to be accessed, the station map area allowed to be viewed, and the types of operations allowed to be performed.

[0127] During the permission loading process, this module uses the permission matching degree calculation formula described in step S3 of Example 1. This method precisely quantifies the matching degree between a user and their assigned role. The formula calculates the intersection-union ratio (IU) of the user's actual permission set and the role's default permission set, multiplied by the role's weight coefficient, to obtain the matching degree. Permissions are successfully loaded only when the matching degree is greater than a preset threshold (0.85 in this embodiment); otherwise, access is denied. This mechanism effectively prevents security vulnerabilities caused by incorrect permission configuration. For example, if a user is assigned the "Dispatcher" role but lacks the "Train Number Modification" permission, the calculated matching degree may be lower than 0.85, and the system will refuse the user's login and prompt the administrator to check the permission configuration.

[0128] This module also includes a dynamic permission pruning submodule based on the station map topology. When a user's permissions are only granted to a portion of a station (e.g., only allowing viewing of the downlink throat area), this submodule automatically identifies the boundary nodes of that area based on the station map topology. The station map topology is pre-stored in a database as a directed graph, with nodes representing signals, turnouts, and track sections, and edges representing adjacency relationships. This submodule starts with all nodes within the authorized area and expands outwards using a breadth-first search algorithm until an unauthorized node is encountered, at which point that node is marked as a boundary node. Boundary node identification uses the boundary node identification formula described in step S5 of Example 1. Station map elements outside of boundary nodes are either filtered out during metadata generation or have an invisible attribute added to the SVG tag with opacity reduced to 30%. For partially authorized switches or signals, this submodule includes permission tags in the generated station map metadata, allowing the browser to control the availability of interactive operations based on these tags. The advantages of this approach are twofold: firstly, it reduces the amount of data transmitted over the network; secondly, it prevents users from bypassing permission restrictions by viewing the source code of hidden elements through browser developer tools, significantly improving the security of access control. Conversely, if this topology-based dynamic pruning is not adopted, and only some elements are hidden on the front end using CSS, any user with basic web development knowledge can restore the display by modifying the browser console code, which is absolutely unacceptable in railway safety-sensitive scenarios.

[0129] (II) Station Map Data Generation Module

[0130] This module is used to extract station map description data from the memory cache according to the user's permission scope and generate station map metadata. The specific working process is as follows:

[0131] This module first reads the site map description data within the user's permission scope from the memory cache (Redis is used in this embodiment). The site map description data is organized in JSON format, and each site map element contains a unique identifier, type code, coordinate position, adjacent topological relationships, and appearance attributes. This module converts this description data into a subset of the vector graphics description format SVG, because SVG is a vector format natively supported by the Web, and each graphic element is an independent DOM node, which can be precisely bound to interactive events, making it easier to implement high-precision interactions compared to Canvas.

[0132] To accelerate browser-side interaction, this module also includes a submodule for generating station map element indexes based on geometric hashing. This submodule generates a geometric hash value for each station map element, calculated using the formula described in step S4 of Example 1. Specifically, this submodule first obtains the type code of the element (track is 0x01, turnout is 0x02, signal is 0x03, etc.), then calculates the coordinate position hash—for point elements, it takes the 32-bit integer hash of the coordinates; for line elements, it takes the string hash of the coordinates of the first and last points. Finally, it calculates the adjacent topological relationship hash—it takes the identifiers of all elements directly connected to the element, sorts them, concatenates them, and then hashes them. The final geometric hash value is obtained by bitwise XORing the above three hash values. This submodule encapsulates the generated geometric hash value together with the station map metadata and transmits it to the browser via the HTTPS protocol. The role of the geometric hash index is to enable the browser to quickly calculate the query hash value and locate the corresponding element based on the click coordinates when the user clicks on the station map, reducing the time complexity to O(1) and achieving millisecond-level response. Without this index, in a large hub station containing dozens of turnouts and hundreds of track sections, the hit test delay for each click may exceed 200 milliseconds, seriously affecting the user experience.

[0133] (iii) Information caching and push module

[0134] This module maintains the full set of representation information, calculates changes in the representation information, and pushes incremental data to the browser via the WebSocket protocol. The specific workflow is as follows:

[0135] This module establishes a real-time communication connection with the CTC center application server, receiving equipment status information from across the station (including signal light colors, switch positions, track occupancy / free time, train number positions, etc.). Each information object contains three fields: element identifier, current value, and latest update timestamp. The timestamp precision is in the millisecond range. This module stores all representation information objects in a memory cache, forming a complete set of representation information. .

[0136] This module employs a timestamp-based incremental data synchronization algorithm as described in step S6 of Example 1. Calculate the change. Wherein The server maintains an independent timestamp for each browser's last successful data reception for each connection. This module performs incremental calculations at a fixed interval of 50 milliseconds, and then processes the resulting incremental data set. Push notifications are sent to all online browsers via WebSocket connections. The 50-millisecond period was chosen based on the following engineering considerations: railway signal information typically changes less than 10 times per second, and a 50-millisecond period is sufficient to capture all changes without redundant pushes; if the period is too small, empty data will still be frequently calculated and pushed when there are no changes, wasting CPU and network resources; if the period is too large, the perceived latency will increase, which may affect scheduling decisions in high-speed rail scenarios. The data format used during pushes is MessagePack binary serialization, which is smaller in size and faster to parse than JSON.

[0137] This module also includes sub-modules for WebSocket reconnection and data retransmission. When the browser detects a WebSocket connection loss (by listening to the onclose event or periodically sending ping frames), it automatically starts a reconnection timer and attempts to re-establish the connection using an exponential backoff algorithm: the first reconnection is delayed by 1 second, if it fails, it is delayed by 2 seconds, then by 4 seconds, and so on, with a maximum delay of no more than 30 seconds, to avoid frequent reconnections increasing network load. After a successful reconnection, the browser stores the last received timestamp locally. Send to the server. This submodule recalculates the timestamp based on this timestamp. Incremental data set up to the current time The data is then resent to the browser. The integrity of the resent data is verified using the integrity check formula described in step S6 of Example 1. This mechanism ensures that even if the connection is interrupted for several minutes, the browser's state remains completely synchronized with the real state, avoiding data loss due to the disconnection. Conversely, without this retransmission mechanism, critical information such as changes in train track sections during the disconnection period would be permanently lost, potentially causing dispatchers to see incorrect information and leading to serious safety incidents.

[0138] (iv) Business Logic Processing Module

[0139] This module receives operation commands from the browser, performs permission verification, and executes the corresponding business logic. The specific workflow is as follows:

[0140] When a user performs operations such as zooming in / out of the station map, searching for train numbers, modifying train numbers, or stitching station maps through a browser, the browser encapsulates the operation instructions into JSON format and sends them to the server via an HTTPS POST request. Upon receiving the request, this module first parses the operation instructions, breaking them down into several atomic operations (for example, the "modify train number" operation includes three atomic operations: verifying the new format, deleting the old train number label, and adding the new train number label). Then, it uses the multiplication verification formula described in step S7 of Example 1. Permission verification is performed. The verification result is 1 only when the permission judgment function value for all atomic operations is 1, indicating that the user has full permission to execute the operation. This product-based verification ensures overall operational security and avoids the risk of partial execution due to "partial permissions." For example, if a user only has permission to delete a train number but not to add a new one, the modification operation will be completely rejected, avoiding the error state where a new number cannot be added after deletion. After successful verification, the module executes the corresponding business logic (such as forwarding the train number modification request to the CTC system's train management module) and returns the execution result to the browser for interface updates. All operation logs are recorded in the server-side database for easy post-event auditing.

[0141] III. Browser Modules and Their Working Principles

[0142] The browser-based module includes a station map drawing and rendering module, a representation information receiving and partial update module, an interactive operation module, and a station playback module.

[0143] (I) Station Map Drawing and Rendering Module

[0144] This module receives station map metadata transmitted from the server and uses D3.js combined with SVG technology to dynamically draw and render the station map. It also employs a layered rendering mechanism to separate the rendering of fixed elements from dynamically represented information. The specific workflow is as follows:

[0145] After receiving the station map metadata and its corresponding geometric hash value, this module first establishes a geometric hash index table, storing each element identifier associated with its geometric hash value. Then, the module employs a layered rendering mechanism to divide the station map into six independent layers: background layer, track layer, turnout layer, signal layer, train number layer, and dynamic display information layer. The background layer, track layer, turnout layer, and signal layer are fixed element layers—these elements remain unchanged after the station design is finalized, are only drawn once during the initial load, and are then cached as SVG fragments in the browser's IndexedDB. In subsequent sessions, if the user refreshes the page or logs in again, the module first checks if the same version of the fixed element layer data exists in the local cache (verified by the version number returned by the server). If it exists, it loads directly from the cache without re-requesting, significantly reducing reload time. The train number layer and the dynamic display information layer are dynamic element layers, with each dynamic element associated with a unique element identifier.

[0146] During the rendering process, this module employs the update cost function as described in step S5 of Example 1. This module guides the selection of update strategies. When incremental data is received, it calculates the cost of two possible update strategies based on the layer to which each element belongs: independent layer-by-layer update or merged redraw, and selects the strategy that minimizes the total update cost. For example, when only the position of a train number changes at the train number layer, the cost of independent layer-by-layer update is much lower than that of merged redraw, so the module chooses to update the train number element independently. When more than 50 signals change simultaneously, independent layer-by-layer update may accumulate a higher cost due to multiple reorderings. In this case, the module may choose to merge the changes into the dynamic representation information layer for batch redraw. This cost function allows the browser to adaptively balance the overhead of single-element updates and batch redraws, ensuring that the smoothness of the user interface is always maintained above 60 frames per second.

[0147] This module also utilizes the previously established geometric hash index table to accelerate user interaction response. When a user clicks or hovers over a certain area of ​​the station map, the module calculates the query hash value based on the click coordinates (the calculation method is the same as during generation), and then directly searches for the corresponding element in the hash table, with a time complexity of O(1), achieving millisecond-level response.

[0148] (ii) Information reception and partial update module

[0149] This module receives incremental data sets pushed from the server via a WebSocket connection and only redraws the parts of the site map that have changed. The specific workflow is as follows:

[0150] This module maintains a persistent WebSocket connection to listen for incremental data from the server-side message caching and push modules. Each one received The module first iterates through each representation information object in the data packet, extracting the element identifier and the new state value. Then, based on the element identifier, it locates the corresponding SVG element on the dynamic element layer (train number layer or dynamic representation information layer) in the station map, modifying only the element's attributes (such as changing the fill color of the signal light from "red" to "green", or moving the position coordinates of the train number), without affecting other elements. This partial update method avoids a full redraw. In a typical high-speed rail scheduling scenario, hundreds of representation information may change every second, and this module reduces the rendering load on the browser side by approximately 90%.

[0151] This module is also responsible for maintaining the timestamp of the last received data locally. After each successful data reception, the timestamp is updated to the largest one among the received data. The data is then sent to the server via WebSocket messages. When the WebSocket connection is unexpectedly disconnected, this module works in conjunction with the server-side reconnection and data resending submodule to automatically complete the reconnection and data resending, ensuring data integrity.

[0152] (III) Interactive Operation Module

[0153] This module receives user commands, sends them to the server, and updates the user interface based on the execution results returned by the server. The specific workflow is as follows:

[0154] This module binds to various SVG elements in the station map through an event listener mechanism, monitoring user clicks, double-clicks, hovers, scrolling, and other events. When a user performs operations such as zooming, train number searching, train number modification, or station map stitching, this module first performs preliminary local validation (e.g., whether the train number format conforms to regular expressions such as "Gxxxx" or "Dxxxx"), then encapsulates the operation command into JSON format and sends it to the server-side business logic processing module via an HTTPS POST request. After the server returns the execution result, this module updates the interface based on the result: if successful, it refreshes the display; if it fails (e.g., insufficient permissions), it displays a prompt to inform the user. This module is also responsible for displaying the loading status during operation execution to prevent users from submitting duplicate submissions.

[0155] (iv) Station playback module

[0156] This module is used to send playback time interval parameters to the server, receive historical site representation information transmitted in blocks from the server, and display the data frame by frame in chronological order. The specific working process is as follows:

[0157] When the user clicks the "Station Playback" button and selects a start time and an end time, the module sends a playback request to the server, carrying two timestamps, startTime and endTime, in the request parameters. The server retrieves the corresponding representation information record from the historical database based on the playback time interval and sends the data using a chunked transmission strategy. The chunk size is optimized using the formula described in step S8 of Example 1. Where B is the estimated available network bandwidth and RTT is the round-trip time. This represents the average size of a single record. This represents the maximum number of records per block. This formula ensures that the transmission time of each data block is close to one RTT, thereby maximizing pipeline transmission efficiency.

[0158] After receiving data blocks, this module plays them back frame by frame in chronological order. The playback control bar provides play, pause, fast forward (2x speed, 4x speed), rewind, and progress bar dragging functions. The fast forward function works by skipping some intermediate frames and only displaying keyframes in each data block (i.e., moments when information changes), thus accelerating playback while maintaining basic visual continuity. When dragging the progress bar, the module calculates the corresponding timestamp based on the drag position, requests the closest historical snapshot of the information from the server, and resumes playback from that snapshot.

[0159] IV. Collaboration Process Between Modules

[0160] The collaboration process between the modules in this embodiment is as follows: The user initiates an access request through the browser; the server-side user authentication and permission management module verifies the user's identity and loads permissions; the station map data generation module generates station map metadata and a geometric hash index based on permissions, and transmits it to the browser-side station map drawing and rendering module for layered rendering; subsequently, the information caching and push module continuously pushes incremental data via WebSocket, while the information receiving and partial update module only performs partial redrawing of the changed parts; user operations are sent to the business logic processing module through the interactive operation module, executed after permission verification, and the results are returned; the station playback module loads historical data as needed and plays it back. Throughout this process, the browser does not need to install any dedicated client, achieving cross-platform operation and centralized data storage and maintenance. Furthermore, through layered rendering, incremental push, geometric hash indexing, and reconnection after disconnection, high real-time performance, high reliability, and a good user experience are ensured.

[0161] The CTC system site display terminal in this embodiment overcomes the shortcomings of existing CS architecture terminals, such as lack of support for domestic IT innovation, inability to cross platforms, scattered data maintenance, high user terminal configuration requirements, high deployment and upgrade costs, multiple communication connection channels occupied, and scattered user permissions, through the organic cooperation of various modules on the server side and browser side. It significantly improves the maintainability, real-time performance, security, and scalability of the system.

[0162] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A method for implementing a station display terminal in a CTC system based on a BS architecture, characterized in that, Includes the following steps: Step S1: Server-side startup and initialization. The server-side loads the layered architecture, which includes an interface layer, a business logic layer, and a data layer from top to bottom. The server-side is adapted to domestic chips and domestic operating systems and establishes a connection with domestic databases. After the server-side starts, it loads the basic data of the station map, line configuration data, and user permission data into the memory cache. Step S2: The browser sends an access request containing user authentication information to the server through a browser that supports standard HTTP or HTTPS protocols; Step S3: The server receives and verifies the user's identity authentication information. After successful verification, it loads the user's permission scope from the database according to the user's role. Step S4: The server extracts the corresponding site map description data from the memory cache according to the user's permission scope and generates site map metadata in vector graphics description format. The server transmits the site map metadata data to the browser via HTTPS protocol. Step S5: The browser receives the site map metadata and uses D3.js combined with SVG technology to dynamically draw and render the site map. During the drawing process, a layered rendering mechanism is used to separate the fixed elements and dynamic representation information in the site map. The fixed elements are drawn once and then cached locally on the browser. The dynamic representation information is incrementally updated according to a preset refresh cycle. Step S6: The server establishes a persistent connection with the browser via the WebSocket protocol. The server calculates the change in representation information according to the timestamp-based incremental data synchronization algorithm and pushes the calculated incremental data to the browser via the WebSocket connection. After receiving the data, the browser only performs partial redrawing on the changed parts. Step S7: The browser receives the user's operation command and sends the operation command to the server via HTTPS protocol. The server verifies the permission of the operation command according to the current user's permission scope. After the verification is successful, the server executes the corresponding business logic and returns the execution result to the browser to update the interface. Step S8: When a user initiates a site playback request, the browser sends a playback time interval parameter to the server. The server retrieves the corresponding historical site representation information from the database based on the playback time interval and sends it to the browser in a chunked transmission manner. After receiving the information, the browser plays it back frame by frame in chronological order.

2. The method according to claim 1, characterized in that, The user permission matching degree in step S3 is calculated using the following formula: ； Where u represents the current user, r represents the user role, A(u) represents the set of permissions granted to user u, and A(r) represents the default set of permissions for role r. This represents the weight coefficient of role r, and its value ranges from (0,1]. Indicates the degree of user permission matching, when Greater than the preset threshold Access was granted if permissions were successfully loaded; otherwise, access was denied.

3. The method according to claim 1, characterized in that, In step S4, when generating station map data, a geometric hash value is generated for each station map element. The formula for calculating the geometric hash value is as follows: ； Where e represents a station map element, T(e) represents the type code of element e, P(e) represents the set of coordinate position parameters of element e, and N(e) represents the ordered list of element identifiers adjacent to element e. and These are the location hash function and the adjacency hash function, respectively. Hash is the final hash function, and H(e) is the geometric hash value. After receiving the station map metadata, the browser establishes a geometric hash index table. When the user clicks or hovers over a certain area of ​​the station map, the browser calculates the query hash value based on the click coordinates and looks up the corresponding element in the geometric hash index table.

4. The method according to claim 1, characterized in that, The layered rendering mechanism in step S5 specifically involves dividing the station map into a background layer, track layer, turnout layer, signal layer, train number layer, and dynamic representation information layer. The background layer, track layer, turnout layer, and signal layer are fixed element layers, which are drawn and cached as SVG fragments upon initial loading. The train number layer and dynamic representation information layer are dynamic element layers, with each dynamic element associated with a unique element identifier. When incremental data is received, the corresponding dynamic element is located and updated based on the element identifier. The update cost function for layered rendering is: ； Where L represents the total number of layers. This represents the set of elements that have changed in the i-th layer. This indicates the number of elements in the set. This represents the computational cost coefficient for updating a single element in the i-th layer. This represents the fixed overhead of triggering a rearrangement at level i. This is an indicator function that takes the value 1 when the condition is true and 0 otherwise. This indicates the total update cost; the browser side selects to use... Minimal update strategy.

5. The method according to claim 1, characterized in that, The timestamp-based incremental data synchronization algorithm in step S6 is as follows: ； in Let d represent the set of all information represented by the server at the current moment. A single information object in the middle, This represents the latest update timestamp of the information object. This indicates the timestamp of the last time the browser successfully received data. This indicates the set of incremental data to be pushed; step S6 also configures a WebSocket disconnection reconnection and data retransmission mechanism: when the browser detects that the WebSocket connection is disconnected, it automatically starts a reconnection timer and attempts to re-establish the connection according to the exponential backoff algorithm. After a successful reconnection, the browser will send the timestamp of the last received data locally. The data is sent to the server, which then recalculates the timestamp based on this timestamp. Incremental data set up to the current time Then, the incremental data set is sent to the browser.

6. The method according to claim 1, characterized in that, The permission verification in step S7 uses the following verification function: ； Where 'o' represents the operation command and 'u' represents the current user. This indicates the number of atomic operations contained in operation instruction o. Indicates the first Atom operations, This is a permission determination function, and it is executed when user u has permission. The value is 1 if the permission is active, and 0 otherwise. This indicates the verification result and takes the value 1 when all atomic operation permissions are satisfied.

7. The method according to claim 1, characterized in that, The block size optimization formula for the block transmission method in step S8 is: ； Where B represents the estimated available network bandwidth in bits per second, and RTT represents the round-trip time in seconds. This represents the average size of a single record in the historical information, expressed in bits. This indicates the maximum number of records allowed in a single block on the server side. This indicates the optimal block size.

8. The method according to claim 1, characterized in that, The user permission management in step S3 also includes dynamic permission pruning based on the station map topology: when a user's permissions are only granted to a portion of a station's area, the server automatically identifies the boundary nodes of that area based on the station map topology. The boundary node identification formula is as follows: ； in Let E represent the set of nodes within the authorized area, and let E represent the set of edges in the station topology graph. Indicates from node To the node The directed edge, This represents the set of boundary nodes. The server marks station map elements outside the boundary nodes as invisible or blurred. For some authorized turnouts or signals, the server attaches permission tags to the generated station map metadata. The browser controls the availability of interactive operations based on the permission tags.

9. A station display terminal for a CTC system based on a BS architecture, characterized in that, Including server-side and browser-side; The server-side adopts a layered architecture, comprising an interface layer, a business logic layer, and a data layer from top to bottom. The server-side is compatible with domestically produced chips and operating systems and connects to domestically produced databases. The server-side includes: The user authentication and permission management module is used to verify the user identity authentication information sent by the browser and load the permission scope according to the user role. The station map data generation module is used to extract station map description data from the memory cache and generate station map metadata according to the user's permission scope; The information caching and push module is used to maintain the full set of representation information and calculate the amount of change in representation information, and push incremental data to the browser through the WebSocket protocol; The business logic processing module is used to receive operation instructions sent by the browser, perform permission verification, and execute the corresponding business logic. The browser serves as the user interaction interface, requiring no dedicated client installation. Users access services provided by the server through a browser that supports standard HTTP or HTTPS protocols. The browser includes: The station map drawing and rendering module is used to receive station map metadata transmitted from the server and use D3.js combined with SVG technology to dynamically draw and render the station map. It adopts a layered rendering mechanism to separate the drawing of fixed elements and dynamic representation information. The information receiving and partial update module is used to receive incremental datasets pushed by the server via WebSocket connection and only partially redraw the parts of the site map that have changed. The interactive operation module is used to receive user operation commands and send them to the server, and update the interface based on the execution results returned by the server. The station playback module is used to send playback time interval parameters to the server, receive historical station representation information transmitted in blocks from the server, and display the playback frame by frame in chronological order.

10. The CTC system station display terminal based on BS architecture according to claim 9, characterized in that, The user authentication and permission management module is also configured with a dynamic permission trimming submodule based on the station map topology. When a user's permission is only granted to a part of a station, the dynamic permission trimming submodule automatically identifies the boundary nodes of the area according to the station map topology and marks the station map elements outside the boundary nodes as invisible or blurred. For partially authorized turnouts or signals, the dynamic permission trimming submodule attaches permission tags to the generated station map metadata for the browser to control the availability of interactive operations.

Images