A method, system, medium and product for simulating training of a transmitter of a CS architecture

Abstract

A client-server (CS) architecture transmitter simulation training method, system, medium, and product are disclosed, relating to the field of simulation. The method includes: a server receiving operation event messages from a client and storing them in an event buffer queue; the messages containing the client's local timestamp; sorting the messages in multiple levels according to a preset simulation period, using the client's local timestamp as the primary sorting criterion, to generate an ordered event sequence; extracting operation instruction data and inputting it into the transmitter's global state model to obtain global state update information and an updated state version number, which are then sent to the client; receiving state confirmation frames from the client, and sending missing information for synchronization if the version number is outdated. This application solves the problem of instruction execution deviating from actual business logic due to reliance on network arrival order in related technologies by reconstructing the physical timing of operation instructions and establishing a version closed-loop feedback, thereby improving the accuracy and timing rigor of collaborative training state synchronization.

Description

Technical Field

[0001] This application relates to the field of simulation, and in particular to a CS architecture transmitter simulation training method, system, medium and product. Background Technology

[0002] High-power long-wave transmitters, as critical national basic communication infrastructure, are characterized by high transmission power, complex tuning networks, high operating voltage, and numerous collaborative operation positions. Given the high operating costs, significant risk of misoperation, and potential disruption to combat readiness and duty performance associated with conducting full-process training on actual equipment, utilizing computer simulation technology to construct virtual training environments has become the primary method for training operation and maintenance personnel. Such simulation training systems aim to provide trainees with an interactive operating platform covering equipment start-up and shutdown, parameter adjustment, and troubleshooting by simulating the transmitter's circuit principles and logic control through software.

[0003] To implement the aforementioned transmitter simulation training system, the relevant technologies typically employ a client-server architecture based on a local area network (LAN). In multi-user collaborative training scenarios, the system generally utilizes standard TCP / UDP network sockets for communication. The server processes and forwards the operation commands uploaded by each client according to the arrival time order of network data packets (i.e., first-come, first-served principle), thereby driving the status updates of each terminal interface.

[0004] However, the operation of long-wave transmitters involves strict timing coordination and logical interlocking among multiple roles. Related technologies rely on processing instructions based on the physical arrival order of data packets. During network fluctuations or high-concurrency operations by multiple users, differences in transmission delays can easily cause the instruction execution order to deviate from the actual business logic. Therefore, when facing time-sensitive and complex collaborative operations, these technical solutions may lead to system state evolution that does not conform to the expected logic, thereby reducing the accuracy and logical rigor of state synchronization in collaborative training scenarios. Summary of the Invention

[0005] This application provides a transmitter simulation training method, system, medium, and product based on a CS architecture, which can improve the accuracy of state synchronization in transmitter simulation training in collaborative training scenarios.

[0006] Firstly, this application provides a transmitter simulation training method based on a client-server architecture, applied to a server in a transmitter simulation training system. The transmitter simulation training system also includes multiple clients communicating with the server, each client corresponding to a different operational role in the transmitter collaborative training. The method includes: receiving operation event messages uploaded by each client during collaborative training and storing them in an event buffer queue. The operation event messages at least include operation instruction data, a client-local timestamp generated based on clock synchronization by each client, and a corresponding role identifier; according to a preset simulation period, performing multi-level sorting on the set of messages to be processed in the event buffer queue to generate an ordered event sequence; the multi-level sorting at least includes using the client-local timestamp as the first sorting criterion, when... When client local timestamps are the same, a preset secondary sorting criterion is used as the second sorting criterion; operation instruction data is extracted from the ordered event sequence and sequentially input into the preset transmitter global state model to obtain global state update information and the corresponding updated state version number; the global state update information and the updated state version number are sent to each client to drive each client to update its local simulation interface according to the global state update information; status confirmation frames are received from each client, which contain the state version number currently applied by the client; the state version number in the status confirmation frame is compared with the updated state version number, and when the state version number in the status confirmation frame lags behind, the missing global state update information is sent to the corresponding client to synchronize with the current updated state version number.

[0007] By adopting the above technical solution, the server first constructs a time adjustment window using an event buffer queue, instead of immediately processing received operation event messages, it waits for a preset simulation period. By using the client's local timestamp as the primary sorting criterion, the transmitter simulation training system can ignore differences in network transmission latency and accurately reconstruct the true sequence of operation commands occurring in the physical world on the server side, eliminating timing errors caused by out-of-order delivery. Subsequently, the generated ordered event sequence is input into the transmitter's global state model, ensuring that the evolution of the transmitter's state strictly follows objective temporal logic. Finally, by comparing the state confirmation frames fed back by the client with the updated state version number on the server side, a closed-loop synchronization feedback is formed, enabling timely detection and correction of client state lag caused by network packet loss. In summary, this solution can improve the accuracy and temporal rigor of transmitter simulation training state synchronization in collaborative training scenarios.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the operation instruction data includes an instruction type identifier and a controlled object identifier; before the step of performing multi-level sorting of the set of messages to be processed in the event buffer queue to generate an ordered event sequence according to a preset simulation cycle, the method further includes: according to the instruction type identifier, selecting multiple sets of homologous messages belonging to the continuous variable type from the set of messages to be processed, where homologous messages refer to operation event messages with the same role identifier and the same controlled object identifier; extracting the client local timestamp from each operation event message in each set of homologous messages, retaining the operation event message with the latest client local timestamp or retaining the operation event message with the keyframe according to a preset sampling rate, as the target operation event message; deleting other messages from each set of homologous messages except the target operation event message from the set of messages to be processed, to obtain the target set of messages to be processed.

[0009] By adopting the above technical solution, the server performs targeted traffic shaping for continuous variable operations commonly encountered in transmitter operations, such as knob adjustments and slider dragging. During the simulation period, by identifying and filtering messages from the same source ("same role, same object"), the server eliminates redundant data from a series of intermediate transition states (such as 1, 2...99 during the process of adjusting from 0 to 100), retaining only the target operation event message with the latest client timestamp indicating the final intent. Therefore, this solution reduces the computational load of the subsequent transmitter global state model and the amount of data broadcast to each client, avoiding message queue congestion caused by massive small changes in high-concurrency scenarios, thereby improving the processing efficiency and response speed of the transmitter simulation training system under multi-user high-concurrency operations.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the operation event message further includes a globally unique identifier; the target message set to be processed replaces the message set to be processed; according to a preset simulation cycle, the message set to be processed in the event buffer queue is sorted in multiple levels to generate an ordered event sequence, specifically including: extracting the server receiving timestamp corresponding to each operation event message in the target message set to be processed; sorting the target message set to be processed in multiple levels according to a preset sorting rule to generate an ordered event sequence, the preset sorting rule including: ascending order using the client's local timestamp as the first sorting key; when the client's local timestamps are the same, descending order using a preset secondary sorting criterion as the second sorting key, the secondary sorting criterion being role priority; when the role priorities are the same, ascending order using the server receiving timestamp as the third sorting key; when the server receiving timestamps are the same, sorting using the globally unique identifier as the fourth sorting key.

[0011] By adopting the above technical solution, when faced with millisecond-level concurrent operations resulting in identical local timestamps on clients, the server introduces role priority as a secondary sorting key. This ensures that operations by high-privilege roles (such as shift leaders) logically take precedence over operations by ordinary roles, aligning with the hierarchical relationships in the actual command and dispatch of the transmitter. Furthermore, by using the server's received timestamp and globally unique identifier as subsequent sorting keys, the uncertainty of sorting is eliminated. Therefore, this solution ensures that even under extreme concurrency conditions, the generation of an ordered event sequence is deterministic and unique, avoiding unreproducible race-state errors in the transmitter state caused by execution order fluctuations. This improves the determinism of the transmitter simulation training system's state evolution and the rationality of its business logic.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of extracting operation instruction data from an ordered event sequence and sequentially inputting it into a preset transmitter global state model, the method further includes: performing a validity check on the operation instruction data based on the current global state using preset logical constraint rules in the transmitter global state model, and obtaining a check result; if the check result is unsuccessful, the operation instruction data is determined to be invalid, and an operation error response message is generated, the operation error response message containing an error type identifier and description information corresponding to the check result; keeping the current global state and update state version number of the transmitter global state model unchanged, and not generating new global state update information; and sending the operation error response message separately to the client corresponding to the operation instruction data.

[0013] By adopting the above technical solution, the server performs a legality check on the operation command data through logical constraint rules before the command takes effect, which can intercept operations that violate the electrical principles or safety specifications of the transmitter at the source. When the check result is unsuccessful, the server generates an operation error response message containing error type identification and description information and sends it separately to the operator to provide immediate guidance. Simultaneously, it forcibly maintains the current global state and update state version number unchanged, without generating new global state update information. In summary, this solution prevents a single person's erroneous operation from polluting the entire collaborative training environment, ensures the stable display of other client interfaces, and thus improves the logical stability and teaching error correction capabilities of the transmitter simulation training system.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, after sending the global state update information and the update state version number to each client, the method further includes: if the current time meets the preset state archiving conditions, extracting the current full state data, the update state version number, and the current training task progress information from the transmitter's global state model, and encapsulating them into a breakpoint state record; performing integrity verification calculation on the breakpoint state record, generating an integrity verification code, and appending the integrity verification code to the breakpoint state record to obtain the final breakpoint state record; writing the final breakpoint state record into the server's storage space, and monitoring the execution feedback results of the writing process.

[0015] By adopting the above technical solution, when the preset state archiving conditions are met, the server aggregates the scattered current full state data, updated state version number, and training task progress information, and encapsulates them into an atomic breakpoint state record. Based on this, the server forcibly performs integrity verification calculations and appends the generated integrity check code to obtain the final breakpoint state record, making the archived data logically self-consistent and possessing self-checking capabilities. When the server needs to resume training, it can quickly identify data tampering or corruption caused by storage media failure or transmission errors by recalculating the check code and comparing it with the check code in the record. This avoids simulation logic collapse caused by loading incorrect states, thereby ensuring the security and recoverability of long-cycle training task data.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, monitoring the execution feedback result of the write process specifically includes: if the execution feedback result indicates that the data has been written completely, then executing a transaction commit instruction to mark the breakpoint status record as a valid file to complete persistent storage; if the execution feedback result indicates that the write is interrupted or abnormal, then executing a transaction rollback instruction to clear the written data and release the occupied storage resources.

[0017] By adopting the above technical solution, the server monitors the execution feedback of the writing process in real time when writing the final breakpoint state record to the storage space. If the writing is complete, a transaction commit instruction is executed to ensure the file is valid; if a power outage or abnormality causes the writing to be interrupted, a transaction rollback instruction is immediately executed to clear residual data and release resources. This solution ensures that only complete and usable archive files are always retained in the storage system, avoiding the destruction of existing training records due to unexpected failures, thereby improving the reliability of persistent data storage in the transmitter simulation training system.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after receiving the status confirmation frames from each client, the method further includes: if no status confirmation frame is received from the client within a preset time period, then retransmitting a data frame containing global status update information to the corresponding client; if the number of retransmissions of the data frame reaches a preset retransmission threshold and no status confirmation frame is still received from the client, then marking the corresponding client as out of sync.

[0019] By adopting the above technical solution, the server establishes reliable transmission assurance at the application layer in an unreliable network environment. This prevents the server from wasting resources by continuously sending data to invalid links. Simultaneously, as a clear trigger point for abnormal states, it facilitates the transmitter simulation training system in promptly notifying the administrator or initiating a forced repair process. This prevents communication failures of a single client from hindering the synchronization rhythm of the entire collaborative training group, thereby improving the network communication robustness and connection management capabilities of the transmitter simulation training system.

[0020] Secondly, this application provides a transmitter simulation training system, including a server and multiple clients communicatively connected to the server; the server specifically includes: one or more processors and a memory; the memory is coupled to one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and one or more processors call the computer instructions to cause the server to execute the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application provides a computer-readable storage medium including instructions that, when executed on a server, cause the server to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer program product that, when run on a server, causes the server to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the server provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. By adopting a technical solution that uses the client's local timestamp as the primary sorting criterion to perform multi-level sorting of the message set to be processed in the event buffer queue, and uses the update status version number and status confirmation frame for closed-loop comparison, the server can ignore the difference in network transmission latency, strictly process instructions according to the actual time sequence of the operation, and promptly complete the lagging status. This effectively solves the problem in related technologies where the order of instruction execution deviates from the actual business logic due to network fluctuations or delays, causing chaotic timing of collaborative operations. Thus, it achieves high accuracy of status synchronization and rigor of timing logic in the scenario of collaborative training of transmitters.

[0026] 2. By adopting a technical solution that filters continuous variable types of homogeneous messages based on instruction type identifiers and retains only the target operation event message with the latest local timestamp on the client, the system can automatically identify and eliminate intermediate redundant data in the continuous adjustment process, and only calculate and broadcast the final operation intention. This effectively solves the problem of excessive server computing load and network congestion caused by massive small changes in data when processing high-frequency continuous variable operations, thereby achieving a significant improvement in system processing efficiency and response speed in multi-user high-concurrency operation scenarios.

[0027] 3. By adopting a preset sorting rule that includes the client's local timestamp as the first sorting key, role priority as the second sorting key, server receiving timestamp as the third sorting key, and globally unique identifier as the fourth sorting key, the server can establish a unique execution order based on business hierarchy logic when faced with timestamp conflicts in concurrent operations. This ensures that operations of high-privilege roles are processed first, effectively solving the problem of unreproducible race conditions or business logic conflicts in the transmitter state caused by random fluctuations in the execution order when processing high-concurrency instructions in a very short time. This, in turn, achieves the determinism of the transmitter simulation training system's state evolution and the rationality of its business logic under extreme concurrency conditions. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a transmitter simulation training method based on a CS architecture, as described in an embodiment of this application.

[0029] Figure 2 This is another flowchart illustrating a transmitter simulation training method based on a CS architecture in an embodiment of this application;

[0030] Figure 3 This is a schematic diagram of the physical device structure of a server in an embodiment of this application. Detailed Implementation

[0031] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions a, an, the foregoing, and this are intended to also include the plural expressions, unless the context clearly indicates otherwise. It should also be understood that the terms used in this application refer to any or all possible combinations that include one or more of the listed items.

[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0033] To facilitate understanding, the application scenarios of the embodiments of this application are described below.

[0034] In related technologies, a "first-come, first-served" (FFS) mechanism based on the physical arrival order of network data packets can be used to achieve command interaction and state forwarding between multiple clients. The following describes a scenario using a client-server (CS) architecture-based transmitter simulation training method: In a collaborative training exercise troubleshooting a high-power transmitter, the client acting as the "shift leader" pressed the "high-voltage emergency stop" button at 10:00:01:100, while the client acting as the "master controller" performed a "power boost" operation at 10:00:01:150. Theoretically, emergency stop should occur before power processing (or the power operation should be blocked due to emergency stop). However, due to network congestion on the "shift leader's" network link, their data packet arrived 50 milliseconds later than the "master controller's" packet. The server executed the "power boost" first, according to the arrival order, causing the transmitter to run at full power in a faulty state before finally executing the "emergency stop." This logical reversal not only violates the equipment's principles but also leads trainees to develop incorrect emergency response knowledge.

[0035] The multi-level sorting mechanism based on event buffer queues and client-side local timestamps in this embodiment of the application, by introducing simulation cycles on the server side and reconstructing the physical timing of operation instructions, achieves simulation control that strictly follows real business logic. This not only eliminates timing interference caused by network transmission latency differences but also ensures the rigor of the training process. The following describes a scenario using a transmitter simulation training method based on a CS architecture from this application: In the same training scenario described above, after the server receives operation event messages from two clients, it does not execute them immediately but first stores them in the event buffer queue. During the current simulation cycle settlement, the server parses the message content and finds that the "shift leader's" local timestamp (10:00:01.100) is earlier than the "master controller's" local timestamp (10:00:01.150). Although the "shift leader's" data packet arrives later, the system still prioritizes "high-voltage emergency stop" before "power increase" based on the timestamp. The global state model executes sequentially: first, the emergency stop logic is triggered to cut off the high voltage; then, when processing the power boost command, the operation is deemed invalid and an error message is returned because the logic constraint check of "high voltage has been cut off" is triggered.

[0036] As can be seen, by adopting the timing reconstruction and state closed-loop synchronization technology in the embodiments of this application, while realizing efficient collaborative training of multiple positions, it can also effectively solve the problem of deviation between the operation execution order and the actual business logic caused by network fluctuations or concurrent competition, thereby realizing transmitter simulation training with high accuracy, high consistency and conformity to the real equipment operation mechanism.

[0037] To facilitate understanding, the method provided in this implementation will be described in detail below, using the above scenario as an example. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating a transmitter simulation training method based on a CS architecture in an embodiment of this application.

[0038] S101. Receive operation event messages uploaded by each client during collaborative training and store them in the event buffer queue. The operation event message includes at least operation instruction data, client local timestamp generated by each client based on clock synchronization, and corresponding role identifier.

[0039] In this system, the client refers to the student's operating terminal in the transmitter simulation training system, used to simulate different operating positions of the transmitter, such as the main control terminal, exciter control terminal, and antenna tuning terminal; collaborative training refers to the simulated transmitter operation training process in which multiple clients participate simultaneously, requiring coordination according to a specific operation procedure and timing; operation event messages represent data packets converted from user interaction behavior captured by the client, used to convey the user's operation intentions; operation instruction data refers to the specific operation content, such as closing the high-voltage switch or adjusting the capacitor value to 50pF; the client's local timestamp represents the precise time point at which the operation event occurred on the client, generated by a high-precision timer and corrected by clock synchronization; the role identifier is used to indicate the role type played by the client that issued the operation instruction, such as 01-shift leader, 02-main controller, etc.; and the event buffer queue is a temporary storage structure maintained by the server side, used to cache operation event messages to be processed.

[0040] After the collaborative training of the transmitters begins, each client will capture the trainee's actions in real time and generate operation event messages. Specifically, when a trainee performs an operation on the client interface (such as clicking a button, adjusting a knob, or inputting parameters), the client software will immediately capture this action and generate an operation event message containing operation command data, a timestamp, and a role identifier. To ensure the accuracy of the timestamp, the system will perform a clock synchronization process before training begins, calculate the clock deviation between each client and the server, and automatically compensate for the deviation when generating the timestamp. The generated operation event messages are transmitted to the server via the network. After receiving the messages, the server will not process them immediately but will store them in an event buffer queue, waiting to be processed uniformly according to the simulation cycle, in order to solve the out-of-order problems that may be caused by network transmission.

[0041] S102. According to the preset simulation cycle, the set of messages to be processed in the event buffer queue is sorted in multiple levels to generate an ordered event sequence; the multi-level sorting includes at least the client local timestamp as the first sorting basis, and when the client local timestamps are the same, the preset secondary sorting basis is used as the second sorting basis.

[0042] The simulation cycle represents a fixed time interval for the server to process messages in the event buffer queue, used to balance real-time performance and computational resource consumption; the set of messages to be processed refers to all unprocessed operation event messages extracted from the event buffer queue within the current simulation cycle; multi-level sorting refers to the process of sorting messages according to priority using multiple sorting keys; and ordered event sequence refers to the sequence of operation event messages arranged in logical time order after multi-level sorting, used to ensure that operation instructions are executed in the actual order of occurrence rather than the order of network arrival.

[0043] At the start of each simulation cycle, the server needs to process the accumulated operation event messages. Specifically, the server first retrieves all messages that need to be processed within the current cycle from the event buffer queue, forming a set of messages to be processed. Then, the server performs a multi-level sorting algorithm on these messages: firstly, the client's local timestamp is used as the primary sorting criterion to ensure that operations are processed in the actual order of occurrence; when the client's local timestamps of two or more operation events are the same or differ by less than a preset time threshold (e.g., 1 millisecond), the server applies secondary sorting criteria for further sorting. Secondary sorting criteria are usually set based on business logic, such as the operation priority of the role (e.g., emergency operations take precedence over routine operations), the importance of the operation type (e.g., security-related operations take precedence over adjustment-related operations), or the server's receiving time.

[0044] Optionally, the server also includes a timestamp validity verification module. When the client's local timestamp of a received operation event message is significantly later than the server's current time, or significantly earlier than (exceeding a preset threshold) the server's current time, the client's clock is determined to be abnormal, a forced clock synchronization command is triggered, and the current message is rejected to prevent expired, lagging commands from interfering with the current state.

[0045] S103. Extract the operation instruction data from the ordered event sequence and input it into the preset transmitter global state model in sequence to obtain the global state update information and the corresponding update state version number.

[0046] The transmitter global state model represents a complete transmitter state simulation model maintained by the server, used to simulate the circuit logic, interlocking relationships, and state transition rules of a real transmitter; global state update information refers to the changes in the transmitter state after the execution of operation instructions, which can be a full state snapshot or incremental change data; the update state version number represents a unique identifier assigned by the server after each state update, used to track the historical records of state changes and ensure state synchronization among clients.

[0047] After completing the multi-level sorting into an ordered event sequence, the server needs to process these operation instructions sequentially and update the global state. Specifically, the server first extracts each operation event message from the ordered event sequence in sequence, parsing out the operation instruction data, including operation type, operation object, operation parameters, and other information. Then, the server sequentially inputs these operation instruction data into the preset transmitter global state model. The transmitter global state model is a complex finite state machine, containing the current state values ​​of each component of the transmitter (such as switches, relays, capacitors, inductors, etc.) and the logical relationships between them. The transmitter global state model calculates the new state according to the current state and the input operation instructions, following predefined state transition rules. After processing each operation instruction, the transmitter global state model generates corresponding state change information. When all operation instructions have been processed, the server generates an incrementing version number based on this state update and packages the global state update information (which can be the full state or incremental changes) with the version number, ready to send it to each client.

[0048] S104. Send the global state update information and update state version number to each client to drive each client to update the local simulation interface according to the global state update information.

[0049] The local simulation interface represents the virtual environment of the transmitter control panel presented to the trainees on the client side, including various instruments, indicator lights, switches, knobs and other interactive elements.

[0050] After processing the operation instructions and generating global state updates, the server needs to synchronize these updates to all participating clients. Specifically, the server packages the global state update information and the corresponding update version number into a standard-format data packet and sends it to all online clients via a network connection. To ensure the security and integrity of data transmission, the server encrypts the data packets (e.g., using the TLS protocol) and adds a checksum. The transmission process employs a reliable transmission scheme, such as the TCP protocol or a reliable transport layer based on UDP, to prevent data loss.

[0051] Optionally, in some embodiments, the server may employ an incremental update-based state synchronization mechanism to analyze the differences between the current state and the previous version, and only send the state information of the changed components. Each incremental packet contains an update state version number, a previous version number, a change timestamp, and a list of changes. The server sends these incremental packets to each client in sequence through a reliable TCP connection and retains these incremental packets in the sending buffer until an acknowledgment is received.

[0052] S105. Receive status confirmation frames from each client. The status confirmation frame contains the status version number currently applied by the client.

[0053] Among them, the status confirmation frame represents the confirmation message sent by the client to the server, which is used to inform the server that the client has successfully received and applied the specific version of the status update; the applied status version number refers to the version identifier corresponding to the status currently displayed on the client's interface, which is used by the server to determine the client's synchronization status.

[0054] After receiving and successfully applying a global state update, the client needs to send an acknowledgment to the server to maintain the reliability of state synchronization. Specifically, when the client receives the state update data packet from the server and successfully applies it to the local simulation interface, the client generates a state acknowledgment frame and sends it to the server. This acknowledgment frame contains at least the version number of the state that the client has successfully applied, and may also include auxiliary information such as the client ID, acknowledgment timestamp, and processing result code. The server receives these acknowledgment frames through the network interface and associates them with the corresponding client's session information. This acknowledgment mechanism is similar to the ACK (acknowledgment) mechanism in network protocols, but implemented at the application layer, with the aim of ensuring that the server can accurately grasp the actual state synchronization status of each client. For state updates that are not acknowledged within the expected time (e.g., 500 milliseconds), the server may mark them as pending acknowledgment.

[0055] Optionally, in some embodiments, the server may maintain a state tracking object for each client session. The object records the state version number and confirmation time of the last confirmation by the client. When the server receives a state confirmation frame sent by the client, it first verifies whether the format and signature of the confirmation frame are valid. Then, it extracts the state version number currently applied by the client from the confirmation frame, compares it with the record in the state tracking object and updates it. At the same time, it records the confirmation timestamp for subsequent network status analysis and latency statistics. The server will also periodically (e.g., every second) scan all client state tracking objects to identify clients that have not updated their confirmations for a long time, mark them as sessions that may enter a state of being out of sync, and initiate the corresponding out-of-sync processing procedure.

[0056] S106. Compare the status version number in the status confirmation frame with the updated status version number. When the status version number in the status confirmation frame is outdated, send the missing global status update information to the corresponding client to synchronize with the current updated status version number.

[0057] The missing global state update information represents all state change data between the current client version and the latest server version.

[0058] After receiving a status acknowledgment frame from a client, the server needs to ensure that all clients can synchronize to the latest state in a timely manner. Specifically, the server first compares the applied state version number reported by the client in the status acknowledgment frame with the latest updated state version number currently maintained by the server. If they are equal, it indicates that the client's state is already up-to-date, and no further action is required. If the client's state version number is less than the server's latest version number, it indicates that the client's state is lagging behind, possibly due to network packet loss, latency, or abnormal client processing. In this case, the server calculates the missing version range for the client (from the client's current version + 1 to the server's latest version) and retrieves the state update information for these versions from the state history. The server can choose to send all incremental updates during this period (if the version difference is small) or directly send the latest complete state snapshot (if the version difference is large or the incremental updates are incomplete). This missing state update information is packaged and sent to the corresponding client. After receiving it, the client applies these updates sequentially until it synchronizes to the current latest state version.

[0059] In this embodiment, by storing received operation event messages in an event buffer queue, performing multi-level sorting of the message set to be processed according to a preset simulation period and the client's local timestamp to generate an ordered event sequence, generating global state update information and update state version number using the transmitter's global state model, and synchronizing missing global state update information by comparing the version number with received state confirmation frames, the server can reconstruct the actual physical time sequence of each client operation on the server side, eliminate timing interference caused by network transmission delay differences, and promptly detect and repair client state lag through version verification. This effectively solves the problem in related technologies where the instruction execution order deviates from the actual business logic under network fluctuations or high concurrency scenarios due to the reliance on the arrival order of network data packets, thus causing asynchronous collaborative training states. This improves the accuracy of transmitter simulation training state synchronization and the rigor of timing logic in collaborative training scenarios.

[0060] Based on the above embodiments, the method provided in this embodiment will be described in further detail below. Please refer to... Figure 2 This is another flowchart illustrating a transmitter simulation training method based on a CS architecture in an embodiment of this application.

[0061] S201. Receive operation event messages uploaded by each client during collaborative training and store them in the event buffer queue. The operation event message includes at least operation instruction data, client local timestamps generated by each client based on clock synchronization, and corresponding role identifiers. The operation event message also includes a globally unique identifier. The operation instruction data includes an instruction type identifier and a controlled object identifier.

[0062] This step and Figure 1 The description of step S101 in the embodiment is similar and will not be repeated here.

[0063] S202. Based on the instruction type identifier, filter out multiple sets of same-source messages belonging to the continuous variable type from the message set to be processed. Same-source messages refer to operation event messages that have the same role identifier and the same controlled object identifier.

[0064] Among them, the instruction type identifier represents the field in the operation event message that indicates the nature of the operation, used to distinguish between discrete operations (such as switch switching, button clicks) and continuous variable operations (such as knob adjustment, slider dragging); continuous variable type refers to the operation type that continuously adjusts a certain parameter, such as capacitor value adjustment, power adjustment, etc., which may generate multiple intermediate state values ​​in a short period of time; same source message indicates multiple messages generated by a series of continuous operations performed by the same operator on the same controlled object, which are essentially multiple adjustments to the same parameter; controlled object identifier refers to the unique identifier of the specific equipment component being operated, such as capacitor C1, power regulator P3, etc.

[0065] After retrieving the set of messages to be processed from the event buffer queue, the server needs to preprocess these messages to optimize processing efficiency. Specifically, the server first checks the instruction type identifier field in each operation event message to identify operation instructions belonging to the continuous variable type. These operations are characterized by users potentially making multiple consecutive adjustments to the same component within a short period (e.g., within a few hundred milliseconds) (e.g., rotating a capacitor adjustment knob from 10pF to 50pF), each adjustment generating an operation event message. The server groups these messages based on role identifiers and controlled object identifiers, grouping continuous variable type messages from the same role and targeting the same controlled object into a group of homogeneous messages. For example, if the "master controller" continuously drags the "final stage plate flow adjustment knob" within 100 milliseconds, generating 15 messages, these 15 messages constitute a group of homogeneous messages. This grouping mechanism is designed to address data redundancy caused by high-frequency sampling, prevent the accumulation of small intermediate states from clogging the simulation calculation pipeline, and prepare for subsequent intelligent flow shaping.

[0066] S203. Extract the client local timestamp from each operation event message in each group of source messages, and retain the operation event message with the latest client local timestamp or retain the operation event message of the key frame according to the preset sampling rate as the target operation event message.

[0067] Among them, the target operation event message refers to the operation event message that is finally retained from the same group of source messages, representing the final result of the group of continuous adjustment operations; the preset sampling rate refers to the minimum retention frequency set for physical quantities with integral effects or inertial links (such as capacitor charging, motor speed increase), for example, retaining one frame every 50 milliseconds to ensure that the slope of physical change can be calculated; the key frame refers to the message frame selected at preset intervals on the time axis, used to depict the trajectory of change.

[0068] After identifying the same message group, the server needs to perform differentiated traffic shaping based on physical characteristics to prevent simulation distortion. Specifically, the server first queries the physical attribute configuration of the controlled object. If the controlled object is marked as having no integral effect (i.e., the response is instantaneous, such as the voltage setpoint of a purely resistive network), the final value retention strategy is directly executed: the latest message with the client's local timestamp in the group is extracted as the target operation event message, because it represents the user's final intent, and the intermediate process does not affect the final state. However, if the controlled object is marked as having an integral effect or being sensitive to the rate of change (such as the rotational speed determining the voltage rise slope, or capacitor regulation requiring the simulation of a charging process), a keyframe retention strategy is executed: the server does not directly discard all intermediate values, but instead, according to a preset sampling rate (e.g., every 50ms), uniformly extracts several keyframes from the same message sequence, along with the last message, as the target operation event message. This processing ensures that the transmitter's global state model can obtain sufficient time-domain sampling points to fit the changing slope and trajectory when calculating differential equations or integrals, avoiding the erroneous simulation of a slow physical rise process as an instantaneous step change, thus guaranteeing the realism of the simulated physical characteristics.

[0069] S204. Remove all messages except the target operation event message from the same source messages in each group of pending messages to obtain the target pending message set.

[0070] The target message set to be processed represents a simplified message set after optimization of the same-source messages, containing only the necessary operation event messages.

[0071] After identifying the target operation event messages for each group of same-source messages, the server needs to streamline the original set of messages to be processed. Specifically, the server iterates through each message in the set, checking if it belongs to an identified group of same-source messages. For messages belonging to the same-source message group, the server further determines if they are the target operation event message for that group. If they are target operation event messages, they are retained; otherwise (i.e., intermediate states), they are removed from the set. Messages that do not belong to any same-source message group (such as discrete operation messages) are directly retained. In this way, the server generates an optimized set of target messages to be processed, which contains only the operation event messages that actually need to be processed, including all discrete operations (such as switch toggles) and the final state of continuous variable adjustment operations, but excluding intermediate states during the continuous adjustment process.

[0072] S205. According to the preset simulation cycle, sort the set of messages to be processed in the event buffer queue in multiple levels to generate an ordered event sequence.

[0073] This step specifically includes:

[0074] Extract the server-received timestamps corresponding to each operation event message in the target set of pending messages;

[0075] The target message set to be processed is sorted in multiple levels according to preset sorting rules to generate an ordered event sequence. The preset sorting rules include:

[0076] Sort in ascending order using the client's local timestamp as the first sorting key;

[0077] When the local timestamps of the clients are the same, they are sorted in descending order using the preset secondary sorting criteria as the second sorting key, and the secondary sorting criteria is the role priority.

[0078] When roles have the same priority, they are sorted in ascending order using the server's received timestamp as the third sorting key.

[0079] When the timestamps received by the server are the same, they are sorted using the globally unique identifier as the fourth sorting key.

[0080] Among them, the server receiving timestamp refers to the system time when the operation event message arrives at the server; the preset sorting rules represent a set of ordered judgment criteria used by the server to perform multi-level sorting of operation event messages; the role priority refers to the importance level of different operation roles preset by the server, which is usually related to the responsibilities and permissions in the mail transmitter operation process, such as the shift leader having higher priority than ordinary operators; the globally unique identifier is a non-repeating identifier assigned by the system to each operation event message, which is usually generated by a combination of timestamp and random number, and is used to provide the final sorting basis in the extreme case where all other sorting keys are the same.

[0081] After filtering and optimizing messages from the same source, the server needs to perform strict multi-level sorting on the target message set to ensure that operations are executed in logical order. Specifically, the server first extracts the server's received timestamp from each operation event message in the target message set. Then, the server applies a preset multi-level sorting rule to sort the message set. The sorting process follows a strict priority order: first, the client's local timestamp is used as the primary sorting key for ascending order, ensuring that operations are processed in the actual order of occurrence; when the client's local timestamps of two or more messages are the same or differ by less than the time precision threshold defined by the server (usually 1-5 milliseconds), the server uses role priority as the second sorting key for descending order, allowing operations of higher-priority roles (such as shift leaders) to be processed first; if role priorities are also the same, the server's received timestamp is used as the third sorting key for ascending order, following the first-come, first-served principle; in rare cases, if the first three sorting keys are the same, the server uses a globally unique identifier as the final sorting criterion, ensuring the determinism and reproducibility of the sorting result.

[0082] Optionally, in some embodiments, during the execution of an ordered event sequence, if the operation instruction of a high-priority role changes the interlock state of the transmitter's global state model, causing the subsequent operation instructions of low-priority roles to no longer satisfy the logical constraint rules, the server directly marks the subsequent operation instructions of low-priority roles as invalid instructions and discards them.

[0083] S206. Extract the operation instruction data from the ordered event sequence and input it into the preset transmitter global state model in sequence. Based on the current global state, the operation instruction data is validated using the preset logical constraint rules in the transmitter global state model to obtain the validation result.

[0084] Among them, logical constraint rules refer to a series of conditional judgment statements predefined in the global state model of the transmitter, which are used to describe the interlocking relationships, operational prerequisites and safety restrictions between various components of the transmitter; legality verification refers to the process of checking whether the current operation instruction conforms to the logical constraint rules, which is used to prevent misoperation and violation of operation from causing damage to the simulation equipment or leading to unrealistic training results.

[0085] After the ordered event sequence is generated, the server proceeds with the state update process. Specifically, the server extracts operation instruction data one by one according to the order of the ordered event sequence, preparing to apply it to the transmitter's global state model. Before actually executing the state change, the server must first perform a strict legality check. The server inputs the extracted operation instruction data (including the operation object, operation action, target parameters, etc.) into the model, and the model triggers corresponding logical constraint rule checks based on the current global state (such as the positions of various switches, voltage and current readings, environmental parameters, etc.). For example, if the current instruction is to close the high-voltage power supply, the model will check whether the cooling system is running, whether the safety door is closed, and whether the grounding rod has been removed, etc., as preconditions. Logical constraint rules are implemented through a series of conditional judgment logic (such as IF-THEN statements or decision tables). The verification process comprehensively considers the physical feasibility of the operation, safety regulations, and business logic, and finally outputs the verification result. If all preconditions and constraint rules are met, the verification result is passed; otherwise, the verification result is failed, and may be accompanied by specific explanations of rule violations.

[0086] S207. If the verification result is unsuccessful, the operation instruction data is determined to be invalid, and an operation error response message is generated. The operation error response message contains the error type identifier and description information corresponding to the verification result.

[0087] Among them, the operation error response message is a feedback data packet generated by the server when the operation command fails the validity check, which is used to inform the client of the reason for the operation failure; the error type identifier is a code used to classify operation errors, such as E001 indicating interlock conflict, E002 indicating that the precondition is not met, E003 indicating that the parameter is out of bounds, etc.; the description information is a detailed textual explanation of the reason for the error, which is used to guide trainees to correct the operation.

[0088] When the validity check fails, the server needs to process the invalid operation and provide feedback to the student. Specifically, the server first determines that the currently processed operation instruction data is invalid, meaning that the instruction will not be executed, and the global state of the transmitter will not change as a result. Then, based on the error information captured during the verification process, the server generates an operation error response message. This message contains two core parts: first, an error type identifier, used by the client software to identify the error category and potentially trigger corresponding audible and visual alarms; second, detailed descriptive information, directly explaining the specific reason for the operation failure (e.g., "High-voltage closing failed: cooling fan not started").

[0089] S208. Keep the current global state and update state version number of the transmitter's global state model unchanged, and do not generate new global state update information; send the operation error response message separately to the client corresponding to the operation instruction data;

[0090] In this context, sending a message individually means that the server only sends the message to the specific client that initiated the invalid operation, without broadcasting it, because the operation did not change the global state and other clients do not need to know about it.

[0091] After generating the operation error response message, the server needs to properly handle system status and network communication. Specifically, since the operation command is determined to be invalid, the server must maintain all state values ​​in the transmitter's global state model unchanged, ensuring that the model still accurately reflects the system state after the last valid operation. Simultaneously, the update state version number is not incremented, remaining at its original value. This means the server will not generate new global state update information, nor will it trigger a state broadcast process to all clients, thus avoiding wasted network bandwidth and unnecessary refreshes of the client interface caused by the invalid operation. Finally, the server sends the generated operation error response message to the specific client that issued the operation command via the network connection. Upon receiving the message, the client will display an error message box or illuminate an alarm indicator on its interface, informing the user that the operation was rejected and the reason, while the interfaces of other users remain unchanged, unaffected by the invalid operation.

[0092] In some embodiments, feedback loop processing for invalid operations and state management in collaborative scenarios can be implemented in various ways:

[0093] Optionally, after sending the operation error response message to the client corresponding to the operation instruction data, the server maintains a listening state on the client's input channel, waiting to receive the new operation instruction data re-uploaded by the client after correction based on the error message. After receiving the corrected operation instruction data, the server identifies the correction identifier associated with the original erroneous operation contained therein, and immediately calls the transmitter's global state model and logical constraint rules again to perform a validity check on the corrected operation instruction data. If the check result is successful, the subsequent global state update and broadcast process is executed, thereby completing the closed-loop control from operation error to operation correction and ensuring that the training task can continue to advance.

[0094] Optionally, when the server determines that the operation instruction data is invalid and the sequential operation task node is currently in multi-person collaborative training mode, it sends an operation error response message to the client corresponding to the operation instruction data, and at the same time generates a collaborative waiting notification message and sends it to all other relevant clients. The collaborative waiting notification message includes a prompt that the current operation is blocked and a waiting countdown, which is used to instruct other clients to maintain the current waiting state and lock their operation interface to prevent other trainees from performing unexpected operations before the current error is resolved. The server will broadcast the latest global status update information to all clients and unlock the interface after receiving and verifying the valid operation instruction resubmitted by the client, thus restoring the normal collaborative training process.

[0095] It is understandable that other methods can be used to implement process control after error handling, such as the server starting an error correction timer after sending an error response. If the correct instruction is not received within the timeout period, the assessment score will be automatically deducted and the step will be skipped. This is not limited here.

[0096] S209. If the verification result is successful, obtain the global status update information and the corresponding update status version number;

[0097] S210. Send the global state update information and update state version number to each client to drive each client to update the local simulation interface according to the global state update information.

[0098] Steps S209 and S210 and Figure 1 Steps S103 and S104 in the embodiment are described similarly and will not be repeated here.

[0099] S211. If the preset state archiving conditions are met at the current moment, extract the current full state data, update state version number and current training task progress information from the transmitter global state model and encapsulate them as breakpoint state records.

[0100] Among them, the preset state archiving conditions refer to the judgment logic that triggers the system to perform data saving operations, which is used to balance data security and system performance, such as the set time interval or specific task nodes; training task progress information refers to the step position completed by the trainee in the current training subject, the score obtained, and the assessment status; breakpoint state record refers to the structured data object after integrating the above discrete data, which is used for subsequent persistent storage and power failure recovery.

[0101] During system operation, to prevent the loss of training progress due to unexpected power outages or program crashes, the server needs to periodically save the current state. Specifically, the server runs a background monitoring thread or timer to detect in real time whether preset state archiving conditions are met. These conditions typically include: every fixed time window (e.g., every 30 seconds), when the trainee completes a key training step (e.g., the transmitter's high-voltage switch is successfully closed), or when a save command is received manually by the administrator. Once the conditions are met, the server immediately locks the transmitter's global state model to prevent data races, and then extracts the current full state data from the model using serialization technology. Simultaneously, the system obtains the current update state version number and reads the current training task progress information from the task management module. The server packages and encapsulates these three parts of data into a unified breakpoint state record object, which is typically in JSON, XML, or binary format, ensuring that it contains all the context information needed to recover the training scenario.

[0102] S212. Perform integrity verification calculation on the breakpoint status record, generate integrity verification code, and append the integrity verification code to the breakpoint status record to obtain the final breakpoint status record.

[0103] Integrity verification calculation refers to the process of applying a specific hash algorithm or verification algorithm to the data content to detect whether the data has been damaged during storage or transmission; integrity verification code represents a fixed-length string or numerical value output by the verification calculation, such as MD5 value or CRC32 value, which is the digital fingerprint of the data.

[0104] After generating the breakpoint state record, the server needs to verify the record to ensure data validity during subsequent readings. Specifically, the server takes the breakpoint state record generated in step S211 (usually a serialized byte stream or string) as input and feeds it into a preset integrity verification algorithm engine. Common algorithms include CRC (Cyclic Redundancy Check) or SHA / MD5, which generate a unique integrity checksum. The server appends this checksum to the header or footer of the breakpoint state record, or merges it as a separate field into the record structure, resulting in the final breakpoint state record. When the system reads this record during recovery, it recalculates the checksum of the content and compares it with the appended checksum. If they do not match, the record is corrupted and cannot be used for recovery, thus preventing system anomalies caused by loading incorrect states.

[0105] S213. Write the final breakpoint state record to the server's storage space and monitor the execution feedback results of the writing process. This step specifically includes:

[0106] If the execution feedback indicates that the data has been written completely, then execute the transaction commit instruction and mark the breakpoint status record as a valid file to complete the persistent storage;

[0107] If the execution feedback indicates that the write was interrupted or an exception occurred, a transaction rollback instruction is executed to clear the written data and release the occupied storage resources.

[0108] Among them, the execution feedback result indicates the return status of the write operation, such as the number of bytes successfully written, error code, or Boolean success flag; the transaction commit instruction is a command that confirms the validity of the operation and makes it permanent; persistent storage means that the data is safely written to non-volatile media and will not disappear after power failure; the transaction rollback instruction is a command that undoes an incomplete operation and is used to restore the state before the operation to ensure data consistency.

[0109] After preparing the final breakpoint state record, the server performs a write operation, which must be atomic—either succeeds completely or fails completely, leaving no corrupted files. Specifically, the server first creates a temporary file in storage or starts a database transaction, writing the final breakpoint state record to this temporary location. During the write process, the server continuously monitors the operating system's I / O feedback. After the write is complete, the server checks the execution feedback: if the result shows that all data has been written correctly and no errors have occurred, the server executes the transaction commit command. In the file system, this typically means renaming the temporary file to the official archive filename (an atomic operation), overwriting the old archive and marking it as a valid file for persistent storage. Conversely, if a power outage, insufficient disk space, or I / O error occurs during the write process, causing the feedback result to indicate anomalies, the server immediately executes a transaction rollback command. This typically means deleting the written portion of the temporary file or rolling back the database transaction, clearing the written data, ensuring that the originally valid old archive file is not corrupted, thus guaranteeing that the system can at least recover to the last successful state upon the next startup.

[0110] S214. Receive status confirmation frames from each client. The status confirmation frame contains the status version number currently applied by the client.

[0111] This step and Figure 1 The description of step S105 in the embodiment is similar and will not be repeated here.

[0112] S215. If no status confirmation frame is received from the client within the preset time period, a data frame containing global status update information is retransmitted to the corresponding client.

[0113] The preset duration represents the time window limit for the server to wait for confirmation feedback after sending data. It is used to determine whether network communication is congested or packet loss occurs. This parameter setting scheme is usually dynamically adjusted based on the real-time statistical value of network round-trip time (RTT) (e.g., set to 1.5 times RTT) or set to a fixed empirical value (e.g., 200 milliseconds).

[0114] After the server broadcasts global state update information to the client, it enters a waiting-for-acknowledgment phase to ensure the reliability of communication based on UDP or a custom protocol. Specifically, when sending a data frame, the server starts a timeout timer for that data packet and keeps a copy of the data frame in a retransmission queue. If the server's network receiving thread does not receive a state acknowledgment frame matching the version number from the corresponding client before the timer expires, it is determined that the data frame may have been lost in transit or the client's processing timed out. At this time, the timeout event triggers the retransmission logic. The server retrieves the original data frame from the retransmission queue, does not recalculate or repackage it, and directly resends the same data packet to the client through the network interface, resetting the timer to start a new round of waiting, thus attempting to overcome momentary network fluctuations through multiple transmissions.

[0115] It should be noted that the application-layer retransmission mechanism in this application is independent of the underlying network protocol. Even when using the TCP protocol, if the application-layer logic determines that the state version is inconsistent (e.g., due to a client logic error rather than network packet loss), a full or incremental state retransmission mechanism at the application layer is still required to force synchronization.

[0116] S216. If the client's status confirmation frame is not received after the number of retransmissions of the data frame reaches the preset retransmission threshold, the corresponding client is marked as out of sync.

[0117] The preset retransmission threshold represents the maximum number of retries allowed by the system, used to prevent infinite looping and resource exhaustion caused by link failure. This parameter is usually set according to the stability requirements of the network environment, such as 3 or 5 times in a local area network environment. The out-of-synchronization state refers to an abnormal logical state in which the client's connection is marked as unreliable or the data is severely lagging, indicating that the client can no longer maintain synchronization with the server through regular incremental updates.

[0118] When a server's retransmission operation for a particular client fails consecutively, and the cumulative number of failures exceeds the system's tolerance limit, it indicates a persistent network link failure or a malfunction in the client program. Specifically, before each retransmission operation, the server checks the retransmission counter associated with the data frame. If the accumulated counter value equals or exceeds a preset retransmission threshold, the server stops retransmission attempts and considers the current connection unavailable. At this point, the server accesses the client's session manager, locates the corresponding session object for that client, and updates its internal status flag from "Online / Synchronizing" to "Out of Sync / Offline." This flagging action triggers a series of subsequent protective measures, such as suspending the transmission of subsequent status update data to the client, displaying the student's icon as a red offline alert on the coach monitoring interface, and potentially initiating link diagnostics in the background or preparing a recovery process to force the client to re-synchronize its status.

[0119] S217. Compare the status version number in the status confirmation frame with the updated status version number. When the status version number in the status confirmation frame is outdated, send the missing global status update information to the corresponding client to synchronize with the current updated status version number.

[0120] This step and Figure 1 The description of step S106 in the embodiment is similar and will not be repeated here.

[0121] In this embodiment, by employing methods such as filtering source messages based on instruction type identifiers and retaining target operation event messages to optimize traffic, utilizing role priority and globally unique identifiers to improve multi-level sorting rules to arbitrate concurrent conflicts, using logical constraint rules to verify the legality of instructions and providing feedback on operation error response messages to isolate invalid operations, and using breakpoint status records with integrity check codes for transactional persistent storage and marking out-of-step states based on retransmission counts, it can significantly reduce system computation and network load while establishing a unique execution order under extreme concurrency. It intercepts illegal operations from the source and protects the global state from contamination, while ensuring the atomicity and self-consistency of system archived data. This effectively solves the problems of resource congestion, timing race conditions, risk of misoperation propagation, and data corruption or loss during system failures that exist in related technologies in high-concurrency collaborative training scenarios, thereby improving the efficiency, logical accuracy, data security, and communication robustness of the transmitter simulation training system.

[0122] The server in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference]. Figure 3 This is a schematic diagram of the physical device structure of a server in an embodiment of this application.

[0123] It should be noted that, Figure 3 The server structure shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0124] like Figure 3 As shown, the server includes a CPU 301, which can perform various appropriate actions and processes based on a program stored in the read-only memory ROM 302 or a program loaded from the storage section 308 into the random access memory RAM 303, such as performing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An I / O interface 305 is also connected to the bus 304.

[0125] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0126] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by CPU 301, it performs the various functions defined in the present invention.

[0127] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium that contains or stores a program, which can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0128] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0129] Specifically, the server in this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements a CS architecture transmitter simulation training method provided in the above embodiment.

[0130] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the server described in the above embodiments; or it may exist independently and not assembled into the server. The storage medium carries one or more computer programs that, when executed by a server's processor, cause the server to implement a client-server architecture transmitter simulation training method provided in the above embodiments.

[0131] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0132] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning if... or after... or in response to determining... or in response to detecting... Similarly, depending on the context, the phrase "when determining... or if (the stated condition or event) is interpreted as meaning if determining... or in response to determining... or in response to detecting (the stated condition or event)" or in response to detecting (the stated condition or event).

[0133] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory RAM, magnetic disks or optical disks.

Claims

1. A client-server architecture transmitter simulation training method, applied to a server of a transmitter simulation training system, wherein the transmitter simulation training system further includes multiple clients communicating with the server, each client corresponding to a different operational role in transmitter collaborative training, characterized in that, The method includes: The system receives operation event messages uploaded by each client during collaborative training and stores them in an event buffer queue. The operation event messages include at least operation instruction data, client-local timestamps generated by each client based on clock synchronization, and corresponding role identifiers. According to the preset simulation cycle, the set of messages to be processed in the event buffer queue is sorted in multiple levels to generate an ordered event sequence; the multi-level sorting includes at least using the client's local timestamp as the first sorting criterion, and when the client's local timestamps are the same, using the preset secondary sorting criterion as the second sorting criterion. Extract the operation instruction data from the ordered event sequence and input it sequentially into the preset transmitter global state model to obtain global state update information and the corresponding update state version number; The global state update information and the update state version number are sent to each of the clients to drive each of the clients to update the local simulation interface according to the global state update information; Receive status confirmation frames from each of the clients, wherein the status confirmation frame contains the current status version number applied by the client; The status version number in the status confirmation frame is compared with the updated status version number. If the status version number in the status confirmation frame is lagging behind, the missing global status update information is sent to the corresponding client to synchronize with the current updated status version number.

2. The method according to claim 1, characterized in that, The operation instruction data includes an instruction type identifier and a controlled object identifier; Before the step of performing multi-level sorting of the set of messages to be processed in the event buffer queue to generate an ordered event sequence according to a preset simulation period, the method further includes: Based on the instruction type identifier, multiple sets of homogeneous messages belonging to the continuous variable type are selected from the message set to be processed. The homogeneous messages refer to operation event messages that have the same role identifier and the same controlled object identifier. Extract the client-local timestamp from each operation event message in each group of the same source messages, and retain the operation event message with the latest client-local timestamp or the operation event message of the key frame according to the preset sampling rate as the target operation event message; Remove all messages other than the target operation event message from each group of messages of the same origin from the set of messages to be processed, and obtain the target set of messages to be processed.

3. The method according to claim 2, characterized in that, The operation event message also includes a globally unique identifier; The target set of messages to be processed replaces the set of messages to be processed; The step of sorting the set of messages to be processed in the event buffer queue in a multi-level manner to generate an ordered event sequence according to a preset simulation period specifically includes: Extract the server-received timestamps corresponding to each operation event message in the target set of messages to be processed; The target message set to be processed is sorted in multiple levels according to a preset sorting rule to generate the ordered event sequence. The preset sorting rule includes: Sort in ascending order using the client's local timestamp as the first sorting key; When the local timestamps of the clients are the same, they are sorted in descending order using a preset secondary sorting criterion as the second sorting key. The secondary sorting criterion is role priority. When the roles have the same priority, they are sorted in ascending order using the server's received timestamp as the third sorting key. When the timestamps received by the server are the same, they are sorted using the globally unique identifier as the fourth sorting key.

4. The method according to any one of claims 1 to 3, characterized in that, Before obtaining the global state update information and the corresponding update state version number, the method further includes: The operation instruction data is validated based on the current global state by using the preset logical constraint rules in the transmitter global state model to obtain the validation result. If the verification result is unsuccessful, the operation instruction data is determined to be invalid, and an operation error response message is generated. The operation error response message contains an error type identifier and description information corresponding to the verification result. The current global state of the transmitter's global state model and the updated state version number remain unchanged, and no new global state update information is generated. The operation error response message is sent separately to the client corresponding to the operation instruction data.

5. The method according to any one of claims 1 to 3, characterized in that, After the step of sending the global state update information and the update state version number to each of the clients, the method further includes: If the preset state archiving conditions are met at the current moment, the current full state data, the updated state version number, and the current training task progress information in the transmitter global state model are extracted and encapsulated as a breakpoint state record. The integrity check calculation is performed on the breakpoint state record to generate an integrity check code, and the integrity check code is appended to the breakpoint state record to obtain the final breakpoint state record. The final breakpoint state record is written to the server's storage space, and the execution feedback results of the writing process are monitored.

6. The method according to claim 5, characterized in that, The execution feedback results of the monitoring and writing process specifically include: If the execution feedback result indicates that the data has been written completely, then execute the transaction commit instruction and mark the breakpoint status record as a valid file to complete the persistent storage; If the execution feedback indicates a write interruption or exception, a transaction rollback instruction is executed to clear the written data and release the occupied storage resources.

7. The method according to claim 1, characterized in that, After receiving the status confirmation frames from each of the clients, the method further includes: If the status confirmation frame from the client is not received within a preset time period, a data frame containing the global status update information is retransmitted to the corresponding client. If the client still does not receive a status confirmation frame after the number of retransmissions of the data frame reaches a preset retransmission threshold, the corresponding client will be marked as out of sync.

8. A transmitter simulation training system, characterized in that, Includes a server and multiple clients that communicate with the server; The server specifically includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the server to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the server, the server causes the server to perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the server, the server performs the method as described in any one of claims 1-7.

Images