A method and system for simulating hardware communication protocols in a virtual simulation environment

Abstract

This invention relates to the field of semiconductor manufacturing virtual simulation technology, and discloses a method and system for simulating hardware communication protocols. This scheme achieves asynchronous decoupled communication between AMHS services and machine services through message queues (such as MQ), replacing the traditional hardware parallel I / O interaction method. The core includes: defining a protocol format for packaging multi-bit signals (such as 16-bit binary numbers); encoding signals such as VALID and CS_0 into single sequence messages (such as hexadecimal "4030"); maintaining a predefined sequence list (indexing corresponding communication steps) and the latest sequence status; and verifying whether a new message matches the expected sequence. If it matches, the status is updated and the process is advanced; otherwise, it is rejected and reset. The system includes AMHS services, machine services, message queue components, a storage module, and a verification module. This invention solves the problems of service dependency, bandwidth waste, and complex sequence verification in virtual scenarios, significantly improving simulation efficiency and realism, and is suitable for the interactive simulation of AMHS and machine interactions in semiconductor FAB plants.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, and in particular relates to a method and system for simulating hardware communication protocols in a virtual simulation environment. Background Technology

[0002] In the semiconductor wafer manufacturing industry, Automated Material Handling Systems (AMHS) automate the transfer of wafer carriers between equipment using devices such as Overhead Rail Transport (OHT). To verify the interaction logic between AMHS and equipment (such as loading ports), hardware communication protocols (such as the E84 standard) need to be simulated in a virtual simulation environment. This protocol requires signals to switch according to strict timing (e.g., load transfer involves 16 steps) and simultaneously transmits multiple signals (such as VALID, CS_0, READY, etc.) through parallel I / O interfaces.

[0003] However, there is currently no mature technology for this. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a method and system for simulating hardware communication protocols in a virtual simulation environment, which addresses the shortcomings of the prior art. While achieving service decoupling, efficient transmission and dynamic sequence verification, it can accurately simulate the multi-bit parallel transmission characteristics of hardware communication protocols (such as the E84 standard), thereby improving the realism and robustness of virtual simulation.

[0005] The first aspect of this invention discloses a method for simulating hardware communication protocols in a virtual simulation environment, used to simulate data exchange between AMHS services and machine services, the method comprising:

[0006] Sequential messages are transmitted between the AMHS service and the machine service via a message queue, wherein the message queue is an asynchronous communication mechanism to achieve decoupling between services;

[0007] Define a protocol format that packages multiple signal bits into a single sequence message, each sequence message including a digital representation;

[0008] Maintain a state sequence, which includes a predefined sequence list and a latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message; the latest sequence state is a variable used to store the index of the current step and the latest sequence value;

[0009] When a new sequence message is received, it is verified whether the new sequence message matches the expected sequence based on the latest sequence state. If it matches, the latest sequence state is updated to proceed to the next communication step. If it does not match, the new sequence message is rejected and the latest sequence state is reset.

[0010] In the above method, the protocol format is a binary format with a bit length of N bits, where N is an integer and N≥8, and the numbers are represented as hexadecimal or binary strings.

[0011] In the above method, the signal bits include at least one of the following: VALID, CS_0, CS_1, TR_REQ, L_REQ, U_REQ, READY, BUSY, COMPT, CONT, HO_AVBL, ES, VA, AM_AVBL, VS_0, VS_1, and each signal bit corresponds to a specific position in the protocol format.

[0012] The above method, wherein the message queue includes at least one of the following: Kafka or RabbitMQ.

[0013] The above method, wherein maintaining the state sequence includes storing the sequence list as a constant list in memory and accessing the sequence messages by index.

[0014] The above method further includes an error handling step when the new sequence message does not match: recording an error log or triggering an alarm.

[0015] A second aspect of the present invention discloses a system for simulating hardware communication protocols, applied in a virtual simulation environment, the system comprising:

[0016] AMHS service, configured to generate sequence messages;

[0017] Machine service, configured to handle sequential messages;

[0018] A message queue component connects the AMHS service and the machine service, and is used for asynchronous transmission of sequential messages;

[0019] The storage module is configured to maintain state sequences, including a predefined sequence list and the latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message; the latest sequence state is a variable used to store the index of the current step and the latest sequence value;

[0020] The verification module is configured to, when a new sequence message is received, verify whether it matches the expected sequence based on the latest sequence state. If it matches, the latest sequence state is updated; if it does not match, it is rejected and reset. The system adopts a protocol format that packages multiple signal bits into a single sequence message, and each sequence message includes a digital representation.

[0021] In the aforementioned system, the protocol format is a 16-bit binary format, and each sequence message includes a hexadecimal representation.

[0022] In the aforementioned system, the storage module is either an in-memory database or a distributed cache.

[0023] In the aforementioned system, the verification module is further configured to perform error handling when sequences do not match, including generating logs or alarms.

[0024] Compared with the prior art, the present invention has the following advantages:

[0025] 1. Asynchronous communication is achieved using message queues (such as MQ and Kafka). AMHS service and machine service transmit messages through a publish-subscribe pattern without directly depending on each other's IP address or interface. This directly eliminates the direct interface calls and IP dependencies required by using HTTP or WebSocket. Services only interact through MQ brokers, achieving decoupling and thus improving the system's scalability (such as adding new services without reconfiguring dependencies) and maintainability (such as service changes not affecting each other). This solves the problem of "strong coupling between services".

[0026] 2. By defining a protocol format, multiple signal bits (such as a 16-bit binary sequence) are packaged into a single sequence message (such as hexadecimal "4030"). Each message transmits multiple signals simultaneously (such as VALID, CS_0, etc.) without the need for additional identifier fields. This simulates the advantage of simultaneous multi-bit transmission in hardware parallel I / O, significantly reducing the number of messages (for example, where multiple single-bit messages were previously required, now a single sequence message can transmit all signals). Traditional single-bit messages waste bandwidth, while the packaging mechanism of this invention optimizes bandwidth utilization and reduces transmission latency. This directly solves the problem of "low bandwidth utilization" and achieves efficient transmission of information data.

[0027] 3. By maintaining a state sequence (e.g., a sequence list storing the expected sequence of each step, and a latest sequence state variable storing the current step), the system dynamically verifies whether a new message matches the expected sequence (e.g., querying the sequence list based on the latest state index). If a mismatch occurs, the message is rejected and the state is reset. This solves the problem of traditional technologies requiring the storage of historical message sequences for complex verification (e.g., tracing back multiple historical steps). The mechanism of this invention only requires a constant list and simple variables in memory, achieving real-time verification through dynamic matching (e.g., comparing the new message with the expected value of the corresponding step in the sequence list), eliminating the need to store historical messages. This simplifies the verification logic (e.g., it can be implemented using if-else statements) and improves robustness (e.g., automatic reset in case of errors). This solves the problem of "high complexity in sequential verification" and meets the requirement of "dynamic sequential verification."

[0028] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0029] Figure 1 This is a flowchart of the method in Example 1.

[0030] Figure 2 This is a system architecture diagram for Example 2.

[0031] Figure 3 This diagram illustrates how AMHS Service and EQP Service exchange Sequence content via MQ.

[0032] Figure 4 The data structure in memory for storing a list of sequences. Detailed Implementation

[0033] Example 1:

[0034] like Figure 1 As shown, a method for simulating hardware communication protocols in a virtual simulation environment is used to simulate data exchange between AMHS services and machine services. The method includes:

[0035] Sequential messages are transmitted between the AMHS service and the machine service via a message queue, wherein the message queue is an asynchronous communication mechanism to achieve decoupling between services;

[0036] Define a protocol format that packages multiple signal bits into a single sequence message, each sequence message including a digital representation;

[0037] Maintain a state sequence, which includes a predefined sequence list and the latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message;

[0038] When a new sequence message is received, it is verified whether the new sequence message matches the expected sequence based on the latest sequence state. If it matches, the latest sequence state is updated to proceed to the next communication step. If it does not match, the new sequence message is rejected and the latest sequence state is reset.

[0039] It should be noted that asynchronous transmission of sequenced messages between the AMHS service and the machine service via message queues achieves service decoupling; a defined protocol format packages multiple signal bits into a single sequenced message (e.g., numerical representation); a state sequence (including a predefined sequence list and the latest sequence state) is maintained to verify the order of new messages; and the state is updated or reset based on the verification results. This solves the problems of service coupling and bandwidth waste.

[0040] The achievable effects include:

[0041] (1) Service decoupling: AMHS and machine services run independently without needing to know each other's IP or interface, improving system scalability and maintainability;

[0042] (2) High-efficiency transmission: Packing multiple signal bits reduces the number of messages and saves bandwidth;

[0043] (3) Reliable sequence verification: Dynamically match the expected sequence to ensure the strict order of communication protocols (such as E84) and avoid error propagation;

[0044] (4) Improve the overall simulation realism and get closer to real hardware interaction.

[0045] In implementation, those skilled in the art can design the following steps:

[0046] Define the protocol format: The protocol format is a fixed-length binary sequence (e.g., 16 bits), with each bit corresponding to a signal (e.g., bit 0 corresponds to the VALID signal). Sequence messages are represented numerically (e.g., hexadecimal "4030") for easy transmission and storage. For example, in signal transfer step ①, the AMHS service packages multiple signal bits (e.g., CS_0=1, VALID=0, etc.) to generate the sequence "4030". The message format is "EQP01-LP1-4030", where "EQP01" is the machine ID, "LP1" is the port number, and "4030" is the sequence value.

[0047] Using message queues for transmission: Choose an MQ implementation (such as RabbitMQ), with the AMHS service acting as a producer to publish sequential messages to an MQ topic (e.g., "amhs_to_eqp"), and the machine service acting as a consumer to subscribe to this topic and receive messages asynchronously. Similarly, the machine service publishes response messages to another topic (e.g., "eqp_to_amhs"). In this way, services do not directly call each other, but communicate only through the MQ broker.

[0048] Maintaining the state sequence: Create two data structures in the service memory: (1) Sequence list: An array or list constant, with indices representing communication step numbers (step 0 to 15) and values ​​representing expected sequence messages (e.g., step 1 corresponds to "4030", step 2 corresponds to "C030"); (2) Latest sequence state: A variable storing the current step number and the latest sequence (e.g., initially step 0). For example, in Java, a Map can be used.<Integer, String> Store a list of sequences, where the key is the step number and the value is the sequence string.

[0049] Verification and Status Update: When a new sequence message (e.g., "C030") is received, the current step (e.g., step 1) is retrieved from the latest sequence status, and the expected next sequence is obtained from the sequence list (step 2 should be "C030"). If a match is found, the latest sequence status is updated to step 2; otherwise, the message is rejected and the status is reset to the initial step 0 (e.g., "4030" is received but "C030" is expected). Resetting may include clearing memory variables and ensuring the system restarts from a safe state. For example, in a semiconductor fab virtual simulation, the AMHS service simulates crane movements, and the machine service simulates machine responses. For instance, during loading and transfer, AMHS sends a step 1 message "4030," the status is updated after the machine verification passes, and a step 2 response is sent. This can be implemented using common programming languages ​​(e.g., Python or Java) without complex algorithms.

[0050] It should be noted that this invention provides an implementation of E84 in a virtual scenario. MQ (Message Queue) is used to decouple communication between the AHMS service and the machine, eliminating the need for mutual dependence on specific services. The protocol content includes 16 bits, as shown in Table 1 for signal bit allocation. Table 1 is as follows:

[0051]

[0052] Using the bit allocation in Table 1, the signals are shown in Table 2, which corresponds to the sequence of steps. Table 2 is as follows:

[0053]

[0054] In this embodiment, the protocol format is binary, with a bit length of N bits, where N is an integer and N≥8, and the numbers are represented as hexadecimal or binary strings.

[0055] It should be noted that by limiting the protocol format to binary, with a minimum bit length of 8 bits (e.g., 16 bits), and using hexadecimal or binary strings for numerical representation, data representation can be optimized, enhancing readability and transmission efficiency. Hexadecimal strings (e.g., "4030") are more concise than binary strings, reducing parsing overhead; binary strings (e.g., "0100000000110000") facilitate bit manipulation, ensuring precise control of signal bits.

[0056] In implementation, the bit length N is set to a fixed value (e.g., 16 bits) to meet the signal requirements of the E84 protocol. For example:

[0057] Binary format design: Each sequence message is represented by N bits, with signal bits mapped to specific positions (e.g., bit 0 is VALID). Those skilled in the art can implement this using bitmasking technology: defining signal bit constants (e.g., VALID_MASK = 0x0001), and setting or reading signal values ​​through bitwise operations. For example, when generating a sequence, the AMHS service sets the corresponding bit based on the signal state (e.g., VALID=1), and then converts it to the hexadecimal string "4030" for transmission.

[0058] Digital representation processing: Upon receiving a message, the hexadecimal or binary string is parsed and restored to a binary sequence. For example, when the machine service receives "4030", it is first converted to an integer, and then bitwise operations are used to extract the signal bits. Those skilled in the art can implement the conversion using standard library functions (such as Python's int(hex_str, 16)) without needing to customize the code. For example, in a virtual machine service, after receiving the message "C030", it is converted to binary "1100000000110000", and then bit 1 (CS_0) is checked to verify the assigned port. This simplifies signal processing and makes implementation more intuitive.

[0059] In this embodiment, the signal bits include at least one of the following: VALID, CS_0, CS_1, TR_REQ, L_REQ, U_REQ, READY, BUSY, COMPT, CONT, HO_AVBL, ES, VA, AM_AVBL, VS_0, VS_1, and each signal bit corresponds to a specific position in the protocol format.

[0060] It should be noted that by listing specific signal bit types (such as VALID, CS_0, etc.), each bit occupies a fixed position in the protocol format, ensuring that the protocol is compatible with hardware standards (such as E84). Each signal bit has a clear definition, which improves the accuracy and versatility of the simulation.

[0061] In practice, the signal bits are arranged in a predefined order within the binary sequence. For example:

[0062] Signal bit mapping: Create a mapping table (used as a constant dictionary in the code), where the key is the signal name and the value is the bit index (e.g., VALID corresponds to bit 0, CS_0 corresponds to bit 1). During sequence generation, the corresponding bits are set according to the signal state (Boolean value). For example, the AMHS service sets CS_0=1, VALID=0, etc., in step ①, generating the sequence "4030".

[0063] Fixed position: The order of signal bits is immutable, ensuring consistency across services. Those skilled in the art can use arrays to store the bit values, with indices 0 to 15 corresponding to each signal. For example, during machine service verification, the value of bit 1 (CS_0) is extracted from the sequence to check if it is in the expected state. For example, in the unloading step, the U_REQ signal (bit 5) is set to 1, and other bits are adjusted according to the protocol. Implementation is simple; developers only need to maintain a single signal bit definition file.

[0064] In this embodiment, the message queue includes at least one of the following: Kafka or RabbitMQ.

[0065] By using a message queue, you can choose a specific implementation, such as RabbitMQ or Kafka, which provides flexibility to adapt to different deployment environments (such as local or cloud) and ensures the universality and scalability of the decoupling mechanism.

[0066] During implementation, choose any message queue (MQ) system and configure a publish-subscribe model. For example... Figure 3 As shown, for example:

[0067] Setting up a message queue: When using RabbitMQ, install the MQ server and create exchanges and queues. The AMHS service acts as a producer, using an MQ client library (such as pika for Python) to publish messages to the topic "amhs_signals"; machine services subscribe to this topic and listen for messages. Similarly, Kafka can be used; create a topic and configure consumer groups.

[0068] Cloud service integration: If based on the cloud (such as AWS SQS), use the SDK to send and receive messages. The message format remains a string (e.g., "EQP01-LP1-4030"). Those skilled in the art do not need to modify the core logic; only the MQ client initialization code needs to be adapted. For example, in a test environment, RabbitMQ simulates communication: after the AMHS service publishes a message, the MQ broker forwards it, and the machine service asynchronously receives and processes it. During implementation, developers can refer to the official MQ documentation for quick integration.

[0069] In this embodiment, maintaining the state sequence includes storing the sequence list in memory as a constant list, such as... Figure 4 As shown, the sequence message is accessed via an index.

[0070] By storing the list of state sequence sequences as a constant in memory and accessing them via an index (communication step number), sequence verification can be simplified, access speed can be improved (memory operations are faster than databases), storage overhead can be reduced, and real-time performance can be ensured.

[0071] During implementation, the sequence list is initialized as a read-only constant when the service starts:

[0072] Data structure design: Use arrays or lists to store sequence values, with indices starting from 0 to correspond to step numbers. For example, define a list seqList = ["4030", "C030", ...], where seqList[0] corresponds to the expected sequence of step 1. The latest sequence state is stored using variables such as currentStep (current step index) and lastSequence (latest sequence value).

[0073] Access Mechanism: When verifying a new message, the expected sequence is obtained by querying seqList using the currentStep index. For example, when currentStep=1, the expected sequence is seqList[1]="C030". If a match is found, currentStep++ is updated. This can be implemented using simple data structures, such as list and int variables in Python.

[0074] For example, in the AMHS service, seqList is initialized as ["4030", "C030", "C830",...]. When a message is received, the new message is compared with seqList[currentStep]. If a match is found, currentStep is incremented by 1. Upon reset, currentStep is set to 0. This implementation is easy to understand and avoids complex databases.

[0075] In this embodiment, when the new sequence message does not match, an error handling step is also included: recording an error log or triggering an alarm.

[0076] Adding error handling, such as logging or alerts, when mismatches occur can enhance system robustness, facilitate fault diagnosis and maintenance, and prevent the propagation of error states.

[0077] During implementation, execute the following after verification fails:

[0078] Error handling logic: If a mismatch occurs, the logging module is invoked to record the error (e.g., message content, expected sequence, and timestamp), or an alert is triggered (e.g., a notification is sent to the monitoring system). Logs can be written to a file or database; alerts can be sent via email or API calls.

[0079] Reset Integration: After resetting the latest sequence state (e.g., setting currentStep=0), error handling is performed. This can be implemented by those skilled in the art using standard logging libraries (such as log4j), requiring no additional hardware.

[0080] For example, when the machine service receives an invalid message "0000", it logs "Invalid sequence at step 1, expected C030", resets its status, and sends an alert to the administrator. Implementation is simple; developers only need to add a few lines of error handling code.

[0081] Example 2:

[0082] like Figure 2 As shown, a system for simulating hardware communication protocols is applied in a virtual simulation environment. The system includes:

[0083] AMHS service, configured to generate sequence messages;

[0084] Machine service, configured to handle sequential messages;

[0085] A message queue component connects the AMHS service and the machine service, and is used for asynchronous transmission of sequential messages;

[0086] The storage module is configured to maintain state sequences, including a predefined sequence list and the latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message;

[0087] The verification module is configured to, when a new sequence message is received, verify whether it matches the expected sequence based on the latest sequence state; if it matches, update the latest sequence state; if it does not match, reject and reset.

[0088] The system employs a protocol format that packages multiple signal bits into a single sequence message, with each sequence message including a digital representation.

[0089] It should be noted that the method of simulating hardware communication protocols in a virtual simulation environment described in Example 2 is essentially the same as that described in Example 1, but it is implemented in the form of a system, providing an integrated solution that can achieve efficient decoupling, sequence guarantee and simulation fidelity improvement, while being easy to deploy and maintain.

[0090] In implementation, those skilled in the art can deploy it as a distributed system, as follows:

[0091] Component connectivity: The AMHS service (running on the crane simulator) connects to the machine service (running on the machine simulator) via a message queue component (such as a RabbitMQ server). Storage modules (such as a Redis in-memory database) and verification modules are integrated into the service.

[0092] Module functions: The AMHS service generates sequence messages (such as packetized signal bits) and publishes them to the MQ; the machine service subscribes to the MQ to receive messages; the storage module maintains the sequence list and its latest state (in memory); the verification module implements verification logic within the machine service (comparing new messages with expectations). For example, the verification module uses if-else statements to determine the match and updates the storage module's state.

[0093] For example, in a virtual fab system, the AMHS service sends messages to the MQ, the machine service listens to the MQ, and upon receiving a message, the verification module accesses the sequence list in the storage module to determine whether to update the status. Developers can implement each module using a microservice architecture (such as Spring Boot).

[0094] In this embodiment, the protocol format is a 16-bit binary format, and each sequence message includes a hexadecimal representation.

[0095] During implementation, the fixed bit length is 16 bits:

[0096] The format processing is as follows: When the sequence message is generated, the AMHS service converts the 16-bit binary data into a 4-character hexadecimal string (e.g., binary "0100000000110000" converted to "4030"). Upon receipt, the machine service performs the reverse conversion. Those skilled in the art can implement this using built-in functions (such as Java's Integer.toHexString()), without requiring an algorithm. For example, the storage module stores the sequence list as ["4030", "C030"], and the verification module compares whether the strings are equal. Implementation is direct, avoiding the complexity of bit manipulation.

[0097] In this embodiment, the storage module is a memory database or a distributed cache.

[0098] Implementation: When using Redis, install a Redis server. In the code, use a client library to store the sequence list (as a hash) and the latest state (as a key-value pair). For example, the key "currentStep" stores the current step number. If the system is deployed on multiple nodes, use a distributed cache to synchronize the state. Those skilled in the art only need to initialize the storage client; no modification to the core logic is required. For example, in a cloud environment, use Redis to store the state; the validation module reads the sequence list from Redis for validation. Developers can quickly integrate the system by referring to the storage system documentation.

[0099] In this embodiment, the verification module is also configured to perform error handling when the sequences do not match, including generating logs or alarms.

[0100] During implementation, error handling logic is added to the verification module:

[0101] When a mismatch occurs, the validation module calls the logging interface to record error details or triggers an alert service (such as a Slack notification) via an API. For example, when validation fails, the validation module writes "Sequence mismatch error" to the log file and resets the storage module's state. Those skilled in the art can implement this using existing logging frameworks, such as Python's logging module.

[0102] The above description is merely a preferred embodiment of the present invention and does not constitute any limitation on the present invention. Any simple modifications, alterations, or equivalent structural changes made to the above embodiments based on the technical essence of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for simulating hardware communication protocols in a virtual simulation environment, characterized in that, The method for simulating data exchange between AMHS services and machine services includes: Sequential messages are transmitted between the AMHS service and the machine service via a message queue, wherein the message queue is an asynchronous communication mechanism to achieve decoupling between services; Define a protocol format that packages multiple signal bits into a single sequence message, each sequence message including a digital representation; Maintain a state sequence, which includes a predefined sequence list and a latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message; the latest sequence state is a variable used to store the index of the current step and the latest sequence value; When a new sequence message is received, it is verified whether the new sequence message matches the expected sequence based on the latest sequence state. If it matches, the latest sequence state is updated to proceed to the next communication step. If it does not match, the new sequence message is rejected and the latest sequence state is reset.

2. The method as described in claim 1, characterized in that, The protocol format is binary, with a bit length of N bits, where N is an integer and N≥8, and the numbers are represented as hexadecimal or binary strings.

3. The method as described in claim 1, characterized in that, The signal bits include at least one of the following: VALID, CS_0, CS_1, TR_REQ, L_REQ, U_REQ, READY, BUSY, COMPT, CONT, HO_AVBL, ES, VA, AM_AVBL, VS_0, VS_1, and each signal bit corresponds to a specific position in the protocol format.

4. The method as described in claim 1, characterized in that, The message queues mentioned therein include at least one of the following: Kafka or RabbitMQ.

5. The method as described in claim 1, characterized in that, Maintaining the state sequence includes storing the sequence list as a constant list in memory and accessing the sequence messages through an index.

6. The method as described in claim 1, characterized in that, When the new sequence message does not match, the error handling steps are also included: recording an error log or triggering an alarm.

7. A system for simulating hardware communication protocols, characterized in that, The system, applied in a virtual simulation environment, includes: AMHS service, configured to generate sequence messages; Machine service, configured to handle sequential messages; A message queue component connects the AMHS service and the machine service, and is used for asynchronous transmission of sequential messages; The storage module is configured to maintain state sequences, including a predefined sequence list and the latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message; the latest sequence state is a variable used to store the index of the current step and the latest sequence value; The verification module is configured to, when a new sequence message is received, verify whether it matches the expected sequence based on the latest sequence state; if it matches, update the latest sequence state; if it does not match, reject and reset. The system employs a protocol format that packages multiple signal bits into a single sequence message, with each sequence message including a digital representation.

8. The system as described in claim 7, characterized in that, The protocol format is a 16-bit binary format, and each sequence message includes a hexadecimal representation.

9. The system as described in claim 7, characterized in that, The storage module mentioned therein is an in-memory database or a distributed cache.

10. The system as described in claim 7, characterized in that, The verification module is also configured to perform error handling when sequences do not match, including generating logs or alerts.

Images