Logic time management service method and system for joint test

Abstract

The invention discloses a logic time management service method and system for a joint test, and the method comprises the steps: enabling a participant to set a time control strategy and a time limitation strategy, initiating a logic time propulsion request and a request for processing callback to middleware according to a preset time step length, and registering a callback function; the time regulator calculates a timestamp lower limit to provide data guarantee for time marching; the middleware receives the logic time advancing request, checks whether the participant has the authority of the time control strategy, and updates the lower limit of the current timestamp; receiving and processing a callback request, checking an FIFO queue and processing a queue message, checking a participant time limited strategy, checking a TSO queue state and processing the queue message, checking a relation between participant request time and a timestamp lower limit, and calling a callback function allowing time advance to the participant; the invention provides an efficient and accurate logic time management mechanism, and solves the problem that the existing joint test platform middleware does not support logic time management.

Description

Technical Field

[0001] The present invention relates to the technical field of joint experiments, and more particularly to a logical time management service method and system for joint experiments. Background Art

[0002] The joint test platform middleware is responsible for all communications during the establishment and operation of the entire joint test system. It is a public facility of the joint test platform and can provide a high-performance, low-latency data environment between joint test system resources and application management and control functions for the integrated test system.

[0003] In joint experiments, real time and logical time are two different time mechanisms; the logical time mechanism is suitable for those that do not need to be synchronized with the real world time. The use of logical time enables these distributed systems to be simulated in a coordinated and unified manner without relying on a single physical clock. Logical time can ensure that events occur in each participating simulation model in the designed time order through synchronization mechanisms.

[0004] However, the existing joint test platform lacks support for logical time functions. When participants in the system need to use logical time advancement, the middleware does not support logical time management services, so there are limitations in application.

[0005] Therefore, how to provide an efficient and accurate logic time management mechanism so that the joint test platform middleware supports logic time management is an urgent problem that technical personnel in this field need to solve. Summary of the invention

[0006] In view of this, the present invention provides a logical time management service method and system for joint testing, which solves the problem that the existing joint testing platform middleware does not support logical time management by providing an efficient and accurate logical time management mechanism.

[0007] In order to achieve the above object, the present invention adopts the following technical solution:

[0008] A logical time management service method for joint experiments comprises the following steps:

[0009] S1. Set the time control strategy and time limit strategy. The participant initiates a logic time advancement request to the middleware according to the preset time step to advance the new logic time;

[0010] S2. The middleware checks whether the participant has the authority of the time control policy. If the participant is a time control policy, go to step S3. If the participant is not a time control policy, go to step S4.

[0011] S3. The middleware processes requests with time control permissions. The middleware updates the current lower limit of the timestamp and updates the time advancement type of the participant whose time has advanced to the Time Advancement Request Service TAR.

[0012] S4. The participant sends a request to the middleware to handle the callback and registers a callback function. The middleware checks the status of the message queue to determine if there are messages to be processed.

[0013] S5. Check if the FIFO queue is empty. If the FIFO queue is not empty, process the messages in the FIFO queue. The middleware retrieves the message from the head of the FIFO queue and sends a request to call the callback function according to the message type, then go to step S4.

[0014] If the FIFO queue is empty, check if the participant is part of the time - restricted policy. If not, go to step S8; if so, go to step 6.

[0015] S6. Process the messages in the TSO queue. The system processes all TSO messages whose timestamps are less than or equal to the minimum of the timestamp lower bound LBTS and the participant's request time, and sends a request to call the callback function to the participant according to the message type, then go to step S4.

[0016] S7. Check the relationship between the participant's request time and LBTS. If the request time is less than LBTS, go to step S8; if the request time is greater than or equal to LBTS, go to step S4, and loop to send requests until the request time is less than LBTS.

[0017] S8. The middleware calls the callback function that allows time advancement to the participant and changes the participant's time advancement type to not having advanced time, ending the processing.

[0018] Preferably, the time control policy is specifically:

[0019] If the original state is a non - time - restricted participant:

[0020] Let the current lowest achievable advancement time LBTS of the test system be LBTSG, and the participant's effective logical time ELT = LogicTime + Lookahead, where LogicTime represents the minimum logical time for the participant to apply to become a time - controlled participant, and Lookahead is the participant's expected minimum time step.

[0021] If ELT≥LBTSG, set the participant's logical time to LogicTime.

[0022] If ELT < LBTSG, directly advance the logical time of the participant to LBTSG when joining, which is consistent with the lowest time of the system;

[0023] If the original state is a time-constrained participant:

[0024] The start time LogicTime of time control is consistent with the current logical time of the participant;

[0025] If ELT ≤ LBTSG, when the participant becomes a time-controlled participant, advance the current logical time to LBTSG to ensure that the timestamp-ordered TSO messages sent after this logical time are valid;

[0026] If ELT > LBTSG, directly advance the logical time of the participant to LBTSG. At this time, ELT = LBTSG + Lookahead, and then become a valid time-controlled participant with LogicTime = LBTSG.

[0027] Preferably, the time-constrained strategy is specifically as follows:

[0028] If the original state is a non-time-controlled participant:

[0029] When LogicTime < LBTSG, directly adjust the logical time of the participant to the lowest advanceable time LBTSG and immediately make it a time-constrained participant;

[0030] When LogicTime > LBTSG, the system suspends the participant until the LBTS of the system advances beyond the logical time of the participant, that is, LogicTime ≤ LBTSG. Once the condition is met, the system middleware will call back the TimeConstrainedEnabled() service, making the participant a time-constrained participant and allowing it to receive timestamp-ordered TSO messages;

[0031] If the original state is a time-controlled participant:

[0032] When LogicTime ≤ LBTSG, the participant directly switches to the time-constrained state, the logical time remains unchanged, and immediately becomes a legal receiver of TSO messages;

[0033] When LogicTime > LBTSG, the participant calculates a new LBTS value based on the current situation. If LogicTime ≤ LBTSG is satisfied after the calculation, the participant switches to the time-constrained state; otherwise, the participant is suspended until the system's LBTS advances beyond the participant's logical time, i.e., LogicTime ≤ LBTSG is satisfied, and the system middleware activates the participant as the time-constrained state again by calling the TimeConstrainedEnabled() service.

[0034] Preferably, the logical process of messages in the middleware is as follows:

[0035] Participant 1 sends a message to Participant n through other functional modules of the middleware;

[0036] The time management module determines the sorting type of the message according to the message sorting mechanism and places the message in the message queue of Participant n, including the TSO message queue or the RO message queue. The RO queue is a first-in, first-out (FIFO) queue;

[0037] Participant n calls the time advancement request service TAR of the middleware;

[0038] The time management module calculates the lower bound of the timestamp LBTS of Participant n. If the message meets the sending conditions, the message is sent to Participant n;

[0039] After all eligible messages in the message queue have been sent and LBTS is greater than the time requested by Participant n to advance, the middleware calls the participant service TAG to allow Participant n to advance in time.

[0040] Preferably, the operations of the middleware under time management include: allowing time advancement, sending TSO messages, and pending;

[0041] In the state where time advancement is allowed, if the time requested by the participant is less than LBTS and the timestamp of the head message in the queue, the middleware allows the participant to advance its logical time; in the TSO data sending state, if the timestamp of the head message is less than t and LBTS and the message fully meets the sending conditions, the middleware will send the message; in the pending or suspended state, when the requested time and the timestamp of the head message are greater than or equal to LBTS, the middleware will prohibit the sending of TSO messages and the advancement of the participant's logical time.

[0042] Preferably, the lower bound of the timestamp LBTS of the participant represents the maximum safe time advancement value of the participant, and no TSO message with a timestamp value less than this value will be received in the future. The calculation method is as follows:

[0043]

[0044] The lower bound of the timestamp LBTS of the test system is the minimum value of the LBTS of all participants:

[0045] LBTS = Min(LBTS i ) for i = 1, 2, ..., n.

[0046] A logical time management service system for joint tests, based on the described logical time management service method for joint tests, includes participants, middleware, a time regulator, and a message queue;

[0047] Participants are used to set time control policies and time - limited policies, and initiate a logical time advancement request to the middleware according to a preset time step to advance the new logical time; initiate a request for request - handling callback to the middleware and register a callback function;

[0048] The time regulator is used to calculate the lower bound of the timestamp LBTS for time management to provide data guarantee for time advancement;

[0049] The middleware is used to receive logical time advancement requests, check whether the participant has the permission of the time control policy, and update the current lower bound of the timestamp; receive the request for handling callback initiated by the participant, check the message queue status, check the FIFO queue, process the messages in the FIFO queue, check whether the participant is a time - limited policy, check the TSO queue status, process the messages in the TSO queue, check the relationship between the participant - requested time and LBTS, and call the callback function that allows time advancement to the participant.

[0050] Preferably, the middleware includes a time management module and a time sorting mechanism; the message queue includes a TSO message queue and an RO message queue, and the RO queue is a first - in - first - out (FIFO) queue.

[0051] Through the above - mentioned technical solutions, compared with the prior art, the present invention discloses a logical time management service method and system for joint tests. Through the logical time management service based on time steps, local participants can flexibly set and update time management policies, and can request time advancement according to the preset time step to coordinate the simulation activities of each member during the simulation process, ensuring the synchronization and consistency of the simulation process; it expands the logical time management service of the middleware of the joint test platform, provides an efficient and accurate logical time management mechanism, significantly improves the performance in logical time synchronization and management, and expands the application scope and scalability of the middleware. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0053] Figure 1 A time advancement flow chart based on step length provided by the present invention;

[0054] Figure 2 A request time step advancement sequence diagram provided by the present invention;

[0055] Figure 3 The request processing callback timing diagram provided by the present invention;

[0056] Figure 4 A flow chart for implementing the time control strategy provided by the present invention;

[0057] Figure 5 A flow chart for implementing the time-limited strategy provided by the present invention;

[0058] Figure 6 A logical flow chart of messages in the middleware provided by the present invention;

[0059] Figure 7 A schematic diagram of the data structure of a participant message queue provided by the present invention;

[0060] Figure 8 A schematic diagram of the execution operation of the middleware provided by the present invention;

[0061] Figure 9 This is a static structure design diagram of the middleware logic time management service provided by the present invention. DETAILED DESCRIPTION

[0062] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0063] The embodiment of the present invention discloses a logical time management service method for joint testing, such as Figures 1-3 , including the following steps:

[0064] S1. Set the time control strategy and time limit strategy. The participant initiates a logic time advancement request to the middleware according to the preset time step to advance the new logic time;

[0065] S2. The middleware checks whether the participant has the permission for the time control policy. If the participant is the time control policy, go to step S3; if the participant is not the time control policy, go to step S4;

[0066] S3. The middleware processes the request with time control permission. The middleware updates the lower limit of the current timestamp and updates the time advancement type of the participant whose time is advanced to the time advancement request service TAR;

[0067] S4. The participant sends a request to the middleware to handle the callback and registers a callback function. The middleware checks the status of the message queue to determine whether there are messages to be processed;

[0068] S5. Check whether the FIFO queue is empty. If the FIFO queue is not empty, process the messages in the FIFO queue. The middleware takes out the messages from the head of the FIFO queue and sends a request to call the callback function according to the message type, and go to step S4;

[0069] If the FIFO queue is empty, check whether the participant is part of the time-limited policy. If it does not belong to the time-limited policy, go to step S8; if it belongs to the time-limited policy, go to step 6;

[0070] S6. Process the messages in the TSO queue. The system processes all TSO messages whose timestamps are less than or equal to the minimum of the timestamp lower limit LBTS and the participant's request time, that is, Min(LBTS, participant's request time), and sends a request to call the callback function to the participant according to the message type, and go to step S4;

[0071] S7. Check the relationship between the participant's request time and LBTS. If the request time is less than LBTS, go to step S8; if the request time is greater than or equal to LBTS, go to step S4, and loop to send requests until the request time is less than LBTS;

[0072] S8. The middleware calls the callback function that allows time advancement to the participant and changes the time advancement type of the participant to not having time advancement, and ends the processing process.

[0073] To further implement the above technical solution, as Figure 4 , the time control policy is specifically: in logical time management, all federation members have independent time control policies. When a new time control participant joins the system, the participant broadcasts an empty message with a timestamp to other nodes, and other participants include it in the time control policy list. Time-limited participants need to participate in the calculation of the lowest pushable time LBTS according to the updated list.

[0074] When a participant applies to become a time-controlled participant, its effective logical time ELT must not be less than the LBTS of the current system; otherwise, it may cause the system time to roll back, thus violating the rules of logical time advancement. Correspondingly, if this participant also belongs to a time-constrained participant, the range of its logical time advancement must not exceed the LBTS of the test system. Therefore, the logical time of this participant needs to be maintained within the range allowed by the system, that is, not less than LBTS and not exceeding LBTS.

[0075] The setting of time-controlled participants is achieved by calling the service enableTimeRegulation(LogicTime,Lookahead), where LogicTime represents the minimum logical time for a participant to apply to become a time-controlled participant, and Lookahead is the expected minimum time step of this participant. When calling the service, there are the following two cases:

[0076] If the original state is a non-time-constrained participant:

[0077] Let the current lowest advanceable time LBTS of the test system be LBTSG, the effective logical time ELT of the participant = LogicTime + Lookahead, where LogicTime represents the minimum logical time for the participant to apply to become a time-controlled participant, and Lookahead is the expected minimum time step of the participant;

[0078] If ELT ≥ LBTSG, set the logical time of the participant to LogicTime;

[0079] If ELT < LBTSG, directly advance the logical time of the participant to LBTSG when joining, to be consistent with the lowest time of the system;

[0080] If the original state is a time-constrained participant:

[0081] The starting time LogicTime of time control is consistent with the current logical time of the participant;

[0082] If ELT ≤ LBTSG, when the participant becomes a time-controlled participant, advance the current logical time to LBTSG to ensure that the timestamp order TSO messages sent after this logical time are valid;

[0083] If ELT > LBTSG, directly advance the logical time of the participant to LBTSG. At this time, ELT = LBTSG + Lookahead, and then become a valid time-controlled participant with LogicTime = LBTSG.

[0084] To further implement the above technical solution, such as Figure 5, the time-constrained policy is specifically as follows:

[0085] In logical time management, a participant can be set as a time-constrained participant by calling the enableTimeConstrained() service; all participants maintain a list of time-controlled participants. Therefore, when a participant is set to the time-constrained state, it can immediately calculate its lowest achievable time to progress (LBTS) based on the list and quickly complete the state transition. Let the current logical time of the participant be LogicTime and the LBTS of the test system be LBTSG, which specifically includes:

[0086] If the original state is a non-time-controlled participant:

[0087] When LogicTime < LBTSG, directly adjust the logical time of the participant to the lowest achievable time to progress LBTSG and immediately make it a time-constrained participant;

[0088] When LogicTime > LBTSG, the system suspends the participant until the LBTS of the system advances beyond the logical time of the participant, that is, LogicTime ≤ LBTSG. Once the condition is met, the system middleware will call back the TimeConstrainedEnabled() service to make the participant a time-constrained participant and allow it to receive timestamp order (TSO) messages;

[0089] If the original state is a time-controlled participant:

[0090] When LogicTime ≤ LBTSG, the participant directly switches to the time-constrained state, the logical time remains unchanged, and it immediately becomes a legal receiver of TSO messages;

[0091] When LogicTime > LBTSG, the participant calculates a new LBTS value based on the current situation. If it satisfies LogicTime ≤ LBTSG after calculation, it switches to the time-constrained state; otherwise, the participant is suspended until the LBTS of the system advances beyond the logical time of the participant, that is, LogicTime ≤ LBTSG, and the system middleware activates the participant as a time-constrained state again by calling back the TimeConstrainedEnabled() service.

[0092] In the test system, each participant corresponds to a change / interaction information flow of the attributes of the objects it orders; after the message arrives at the middleware, it is taken over by the time management module, the sorting type of the message is determined, and the message is placed in the message queue of the participant; the middleware does not immediately send these messages. Instead, after waiting for the participant to send a clear time advancement request to the middleware, it determines the sorting type of the message again, calculates the lower bound of the timestamp of the participant, and then unconditionally sends all RO messages and conditionally selects and sends TSO messages until all messages are sent. The middleware calls the user function TAG to allow the user to advance its logical time.

[0093] To further implement the above technical solution, as Figure 6 , the logical process of the messages in the middleware is specifically as follows:

[0094] Participant 1 sends a message to Participant n through other functional modules of the middleware;

[0095] The time management module determines the sorting type of the message according to the message sorting mechanism and places the message in the message queue of Participant n, including the TSO message queue or the RO message queue. The RO queue is a first-in-first-out (FIFO) queue, as Figure 7 ;

[0096] Participant n calls the time advancement request service TAR of the middleware;

[0097] The time management module calculates the lower bound of the timestamp LBTS of Participant n. If the message meets the sending conditions, it sends the message to Participant n;

[0098] After all the eligible messages in the message queue are sent and the LBTS is greater than the time requested by Participant n to advance, the middleware calls the participant service TAG to allow Participant n to advance in time.

[0099] In this embodiment, for the data structure of the message queue, as Figure 7 , the middleware creates two message queues for each federation member, one is the RO message queue and the other is the TSO message queue. Specifically: during initialization, the middleware creates a participant list to store the relevant information of the joined participants; each participant in the participant list contains a pointer to an instance of the participant queue class (Queues). The instance of the participant queue class contains an RO message queue and a TSO message queue. The RO queue is a first-in-first-out (FIFO) queue. Each queue has a head pointer and a tail pointer for dequeue and enqueue operations; the queue class also provides methods for queue operations, such as message addition, removal, query, and message type determination, etc.

[0100] To further implement the above technical solution, as Figure 8, under time management, the operations of the middleware include: allowing time advancement, sending TSO messages, and being pending;

[0101] In the state where advancement is allowed, when the time requested by the participant is less than the timestamps of the LBTS and the head message, the middleware allows the participant to advance its logical time; in the TSO data sending state, when the timestamp of the head message is less than t and the LBTS, and the message fully meets the sending conditions, the middleware will send the message; in the pending or suspended state, when the requested time and the timestamp of the head message are greater than or equal to the LBTS, the middleware will prohibit the sending of TSO messages and the advancement of the participant's logical time.

[0102] In this embodiment, as Figure 8 In the specific case of TSO message grouping, Head represents the timestamp of the head message, t is the time requested by the participant to advance, the arrow pointing to the left indicates less than, the arrow pointing to the right indicates greater than, the white dot indicates a strict less than relationship, the timestamp of the message at the TSO head represents the minimum timestamp of the messages in the TSO queue, LBTS represents the minimum timestamp of the messages that will be received, and the time requested by the participant to advance represents the maximum timestamp of the TSO message to be sent; the six cases in the figure cover all possible values of the timestamp of the head message Head, LBTS, and the time t requested by the participant to advance, and are considered in three cases: (1) Figure 8 In 1 and 2 of Figure 8 , Head ≤ LBTS; (2)

[0103] In 3 and 4 of

[0104]

[0105] , Head > LBTS; (3) For 5 and 6, in these groupings, t includes all time values on the time axis; (1) and (2) cover all cases of LBTS and Head; (3) indicates that the TSO queue is empty and there are no TSO messages.

[0106] i LBTS = Min(LBTS

[0107] ) i = 1, 2,..., n. A logical time management service system for joint experiments, such as Figure 9 , based on a logical time management service method for joint experiments, includes participants, middleware, a time regulator, and a message queue;

[0108] A participant, which is used to set a time control policy and a time limit policy, and initiate a logical time advancement request to the middleware according to a preset time step to advance a new logical time; initiate a request for processing a callback to the middleware and register a callback function;

[0109] A time regulator, which is used to calculate the lower bound timestamp LBTS of time management to provide data guarantee for time advancement;

[0110] A middleware, which is used to receive a logical time advancement request, check whether the participant has the permission of the time control policy, and update the current lower bound timestamp; receive the request for processing a callback initiated by the participant, check the message queue status, check the FIFO queue, process the messages in the FIFO queue, check whether the participant is a time limit policy, check the TSO queue status, process the messages in the TSO queue, check the relationship between the participant's requested time and the LBTS, and call the callback function that allows time advancement to the participant.

[0111] To further implement the above technical solution, the middleware includes a time management module and a time sorting mechanism; the message queue includes a TSO message queue and an RO message queue, and the RO queue is a first-in-first-out FIFO queue.

[0112] In this specification, each embodiment is described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. The same or similar parts among the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

[0113] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but will be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A logical time management service method for joint experiments, characterized in that: It includes the following steps: S1. Set up a time control policy and a time limit policy. Participants initiate a logical time advancement request to the middleware according to a preset time step to advance the new logical time; S2. The middleware checks whether the participant has the permission of the time control policy. If the participant is the time control policy, go to step S3. If the participant is not the time control policy, go to step S4; S3. The middleware processes the request with time control permission. The middleware updates the lower limit of the current timestamp and updates the time advancement type of the participant who initiated the time advancement to the Time Advancement Request Service TAR; S4. The participant initiates a request to process the callback to the middleware and registers a callback function. The middleware checks the message queue status to determine whether there are messages to be processed; S5. Check whether the FIFO queue is empty. If the FIFO queue is not empty, process the messages in the FIFO queue. The middleware takes out the messages from the head of the FIFO queue and issues a request to call the callback function according to the message type, and go to step S4; If the FIFO queue is empty, check whether the participant is part of the time limit policy. If it does not belong to the time limit policy, go to step S8; if it belongs to the time limit policy, go to step 6; S6. Process the messages in the TSO queue. The system processes all TSO messages whose timestamps are less than or equal to the minimum of the timestamp lower limit LBTS and the participant's request time, and issues a request to call the callback function to the participant according to the message type, and go to step S4; S7. Check the relationship between the participant's request time and LBTS. If the request time is less than LBTS, go to step S8. If the request time is greater than or equal to LBTS, go to step S4, and loop to send requests until the request time is less than LBTS; S8. The middleware calls the callback function that allows time advancement to the participant and changes the time advancement type of the participant to not having time advancement, and ends the processing process.

2. A logical time management service method for joint experiment according to claim 1, characterized in that: The time control policy is specifically as follows: If the original state is a non-time-limited participant: Let the current lowest advanceable time LBTS of the test system be LBTSG, and the effective logical time ELT of the participant = LogicTime + Lookahead, where LogicTime represents the minimum logical time for the participant to apply to become a time control participant, and Lookahead is the expected minimum time step of the participant; If ELT≥LBTSG, set the logical time of the participant to LogicTime; If ELT<LBTSG, directly advance the logical time of the participant to LBTSG when joining, which is consistent with the lowest time of the system; If the original state is a time-limited participant: The start time LogicTime of time control is consistent with the current logical time of the participant; If ELT≤LBTSG, when the participant becomes a time control participant, advance the current logical time to LBTSG to ensure that the timestamp order TSO messages sent after this logical time are valid; If ELT > LBTSG, the logical time of the participant is directly advanced to LBTSG. At this time, ELT = LBTSG + Lookahead, and then it becomes a valid time-controlled participant with LogicTime = LBTSG.

3. A logical time management service method for joint experiment according to claim 1, characterized in that: The time-limited policy is specifically as follows: If the original state is a non-time-controlled participant: When LogicTime < LBTSG, directly adjust the logical time of the participant to the lowest advanceable time LBTSG, and immediately make it a time-limited participant; When LogicTime > LBTSG, the system suspends the participant until the LBTS of the system advances beyond the logical time of the participant, that is, LogicTime ≤ LBTSG. Once the condition is met, the system middleware will call back the TimeConstrainedEnabled() service, making the participant a time-limited participant and allowing it to receive timestamp-ordered TSO messages; If the original state is a time-controlled participant: When LogicTime ≤ LBTSG, the participant directly switches to the time-limited state, the logical time remains unchanged, and it immediately becomes a legal TSO message receiver; When LogicTime > LBTSG, the participant calculates a new LBTS value according to the current situation. If it satisfies LogicTime ≤ LBTSG after calculation, it switches to the time-limited state; otherwise, the participant is suspended until the LBTS of the system advances beyond the logical time of the participant, that is, LogicTime ≤ LBTSG, and the system middleware activates the participant to the time-limited state again by calling back the TimeConstrainedEnabled() service.

4. A logical time management service method for joint experiment according to claim 1, characterized in that: The logical process of messages in the middleware is specifically as follows: Participant 1 sends a message to Participant n through other functional modules of the middleware; The time management module determines the sorting type of the message according to the message sorting mechanism and puts the message into the message queue of Participant n, including the TSO message queue or the RO message queue. The RO queue is a first-in-first-out FIFO queue; Participant n calls the time advance request service TAR of the middleware; The time management module calculates the lower timestamp limit LBTS of Participant n. If the message meets the sending conditions, it sends the message to Participant n; After all eligible messages in the message queue are sent and LBTS is greater than the time requested by Participant n to advance, the middleware calls back the participant service TAG to allow Participant n to advance in time.

5. The logical time management service method for joint experiment according to claim 1, characterized in that: The operations of the middleware under time management include: allowing time advancement, sending TSO messages, and pending; In the state where time advancement is allowed, when the time requested by the participant is less than LBTS and the timestamp of the head message, the middleware allows the participant to advance its logical time; in the TSO data sending state, when the timestamp of the head message is less than t and LBTS, and the message fully meets the sending conditions, the middleware will send the message; in the pending or suspended state, when the requested time and the timestamp of the head message are greater than or equal to LBTS, the middleware will prohibit the sending of TSO messages and the advancement of the participant's logical time.

6. A logical time management service method for joint experiment according to claim 1, characterized in that: The participant's timestamp lower limit LBTS represents the participant's maximum safe time advancement value. In the future, no TSO message with a timestamp value less than this value will be received. The calculation method is: The lower limit of the timestamp LBTS of the experimental system is the minimum value of the LBTS of all participants: LBTS=Min(LBTS i ) i=1,2,...,n。 7. A logical time management service system for joint experiments, characterized in that: A logical time management service method for joint experiment based on any one of claims 1 to 6, comprising a participant, a middleware, a time regulator and a message queue; Participants are used to set time control strategies and time-limited strategies, and initiate logical time advancement requests to the middleware according to the preset time step to advance the new logical time; initiate requests to the middleware to process callbacks, and register callback functions; The time regulator is used to calculate the lower limit of the timestamp LBTS for time management and provide data guarantee for time advancement; The middleware is used to receive the request for logical time advancement, check whether the participant has the authority of the time control policy, and update the lower limit of the current timestamp; receive the request for processing callback initiated by the participant, check the message queue status, check the FIFO queue, process the messages in the FIFO queue, check whether the participant is a time-restricted policy, check the TSO queue status, process the messages in the TSO queue, check the relationship between the participant's request time and LBTS, and call the callback function that allows time advancement to the participant.

8. A logical time management service system for joint experiments according to claim 7, characterized in that: The middleware includes a time management module and a time sorting mechanism; the message queue includes a TSO message queue and a RO message queue, and the RO queue is a first-in-first-out FIFO queue.

Images