A card system service front-end integration method supporting dual gateway access

Abstract

The application discloses a one-card-through system service front-end integration method supporting double gateway access, and belongs to the technical field of one-card-through systems. A dynamic configuration tree containing gateway mounting relations and card reader service mapping is maintained by a front-end integration server. After the card reader is powered on, the card reader announces its own device identifier and service type through multicasting. Connection priority scores of the card reader with the first and second gateways are calculated according to historical access records, and configuration parameters are returned. Registration is initiated to the two gateways respectively, a bidirectional communication link is established, and two gateway routing tables are maintained locally. When a client calls, a service gateway selects a current service gateway according to a session binding relation, converts a request into a gateway protocol message, and forwards the gateway protocol message to a target card reader. The application realizes dynamic access, intelligent routing and transparent switching of the card reader and the double gateways, improves system scalability through service encapsulation, and significantly enhances business continuity and operation and maintenance efficiency.

Description

Technical Field

[0001] This invention discloses a service-oriented front-end integration method for a smart card system that supports dual gateway access, belonging to the field of smart card system technology. Background Technology

[0002] Traditional all-in-one card systems typically consist of card readers, controllers, and a central server. Card readers communicate with the central server via fieldbus or a single gateway. This centralized architecture has significant limitations: the gateway acts as a single point of failure; network outages or equipment malfunctions can cause numerous card readers to go offline, affecting the continuity of access control, attendance, and other services. Furthermore, the relationship between card readers and gateways is often static, lacking dynamic service discovery and flexible access switching mechanisms. When system expansion or gateway replacement is needed, cumbersome on-site reconfiguration is required, increasing maintenance costs and system downtime. With the development of IoT technology, all-in-one card systems are evolving towards a service-oriented architecture, but existing integration methods still fail to effectively address issues such as heterogeneous access from multiple gateways, dynamic service encapsulation, and transparent client calls.

[0003] In recent years, some all-in-one card systems have introduced dual-link backup or multi-gateway redundancy designs, but these are usually limited to simple primary / backup switching, lacking intelligent load awareness and dynamic migration capabilities. Regarding service integration, existing solutions mostly use hard-coding to expose card reader functions as interfaces, making it difficult to adapt to rapid changes in business logic. Simultaneously, protocol adaptation between card readers and gateways remains primarily point-to-point customization, failing to achieve standardized service descriptions and automatic function stub generation, resulting in long new device integration cycles and high integration costs. Furthermore, when network interruptions occur, card readers lack local caching and breakpoint resumption mechanisms, causing data loss and affecting the integrity and reliability of transaction records. In terms of configuration management, static configuration files or manual intervention are often used, failing to achieve version control and automatic synchronization of configurations, easily leading to system failures due to configuration inconsistencies.

[0004] In response to the aforementioned technological status quo, a service-oriented front-end integration method for a smart card system that supports dual gateway access is needed. This method should enable dynamic registration, intelligent routing, and transparent switching between card readers and multiple gateways. By encapsulating services, card reader functions should be provided to the outside world through standardized interfaces. Furthermore, it should have offline caching, automatic configuration synchronization, and load-aware migration capabilities, thereby improving the availability, scalability, and maintenance efficiency of the smart card system and meeting the needs of large-scale deployment and complex business scenarios. Summary of the Invention

[0005] To achieve the above objectives, this application provides the following technical solution: According to a first aspect of the present invention, the present invention claims protection for a service-oriented front-end integration method for a smart card system supporting dual gateway access, applied to a computing environment including a card reader, a front-end integration server, and heterogeneous gateways, comprising the following steps: S1, the front-end integration server maintains the dynamic configuration tree of the all-in-one card device. The front-end integration server sends topology probe frames to the first gateway and the second gateway, and updates the online status and link quality of the corresponding gateway in the dynamic configuration tree according to the returned response data. S2. When the card reader is powered on and starts up, it announces its device identifier and supported service types on the local area network. After the front-end integration server listens to the announcement, it calculates the connection priority scores of the card reader with the first gateway and the second gateway according to the gateway mounting relationship recorded in the dynamic configuration tree. The front-end integration server returns the configuration response unicast to the card reader. S3. After receiving the configuration response, the card reader initiates registration requests to the first gateway and the second gateway respectively. After completing the authentication of the card reader, it returns a registration response and establishes a two-way communication link. The card reader maintains two gateway routing tables locally, recording the heartbeat sequence number and the message buffer queue. S4, the front-end integration server generates a corresponding RESTful application programming interface definition for each entity function supported by the card reader, publishes the interface definition to the service gateway, converts the interface definition into a call format that conforms to the gateway protocol specification, generates a gateway executable function stub and pushes it to the first gateway and the second gateway. S5, the client application sends a service call request to the service gateway. The service gateway parses the Uniform Resource Identifier in the request, determines the target service type and the target card reader identifier. Based on the session binding relationship maintained by the front-end integration server, the service gateway selects the first gateway or the second gateway as the current service gateway, encapsulates the service call request into a gateway protocol message and forwards it to the selected gateway and sends it to the target card reader through a bidirectional communication link. S6. After the card reader executes the instruction, it generates the execution result. The card reader determines the current reachability status of the first gateway and the second gateway based on the heartbeat sequence number recorded in the local gateway routing table, selects the gateway with the better reachability status as the return gateway, and encapsulates the execution result into a response message and sends it to the return gateway.

[0006] Furthermore, the update method of the dynamic configuration tree includes: The front-end integration server maintains the first transaction log corresponding to the first gateway and the second transaction log corresponding to the second gateway. The first transaction log records the response timestamp and response content summary of each topology probe of the first gateway, and the second transaction log records the response timestamp and response content summary of each topology probe of the second gateway. The front-end integration server inputs the first transaction log and the second transaction log into the change detector, and the change detector calculates the first gateway state change entropy value and the second gateway state change entropy value. When the entropy value of the first gateway's status change exceeds the first threshold, the front-end integration server marks the list of mounted card readers of the first gateway in the dynamic configuration tree as pending refresh. When the entropy value of the second gateway's status change exceeds the second threshold, the front-end integration server will mark the list of mounted card readers of the second gateway in the dynamic configuration tree as pending refresh. The front-end integration server recalculates the connection priority score between the card reader and the first and second gateways based on the marking results.

[0007] Furthermore, the specific implementation method for the card reader to announce its own device identifier and supported service types is as follows: The card reader's security coprocessor generates a pair of session keys, uses these session keys to calculate the message authentication code for the announcement message, and appends the message authentication code to the end of the announcement message; The card reader sends an announcement message to the User Datagram Protocol multicast group via the physical layer broadcast address; the front-end integration server joins the multicast group, receives the announcement message, and uses the pre-set root certificate to verify the validity of the card reader's digital certificate. After successful verification, it extracts the device identifier and service type from the announcement message. The front-end integration server queries the historical access records associated with the device identifier in the dynamic configuration tree. If the average response latency of the first gateway in the historical access records is less than the average response latency of the second gateway, then the first gateway is assigned a higher connection priority score. If the average response latency of the second gateway is less than that of the first gateway, then the second gateway is assigned a higher connection priority score. The front-end integration server will send a configuration response message containing the Internet Protocol address, port number, and connection timeout parameters of the first gateway and the Internet Protocol address, port number, and connection timeout parameters of the second gateway to the media access control address of the card reader via unicast.

[0008] Furthermore, the process by which the card reader maintains two gateway routing tables includes: The embedded processor of the card reader creates a first gateway routing table and a second gateway routing table. The first gateway routing table includes a first gateway identifier field, a first sending sequence number field, a first receiving sequence number field, a first retransmission timer field, and a first message buffer queue pointer. The second gateway routing table includes a second gateway identifier field, a second sending sequence number field, a second receiving sequence number field, a second retransmission timer field, and a second message buffer queue pointer. When sending a registration request to the first gateway, the first sending sequence number field is assigned the current system tick count value, and a copy of the registration request message is stored in the first message cache queue; After receiving the registration response from the first gateway, the confirmation sequence number in the response is extracted and compared with the first sent sequence number. If they match, the corresponding copy of the registration request message in the first message buffer queue is cleared. When sending a registration request to the second gateway, the second sending sequence number field is assigned the current system tick count value, and a copy of the registration request message is stored in the second message cache queue; After receiving the registration response from the second gateway, extract the confirmation sequence number from the response and compare it with the second sending sequence number. If they match, clear the corresponding registration request message copy in the second message buffer queue. Check the first retransmission timer and the second retransmission timer. If the first retransmission timer expires and the first message buffer queue is not empty, retransmit the messages in the first message buffer queue. If the second retransmission timer times out and the second message buffer queue is not empty, then the messages in the second message buffer queue will be retransmitted.

[0009] Furthermore, the methods for generating gateway executable function stubs include: The service gateway loads the card reader service description file, which is written in an interface definition language and describes the input parameter types, output parameter types, and calling constraints of each functional service supported by the card reader. The service gateway's interface compiler performs lexical analysis, syntax analysis, and semantic analysis on the service description file to generate an abstract syntax tree; The interface compiler traverses the abstract syntax tree, generating a first placeholder function conforming to the first gateway communication protocol for each functional service and a second placeholder function conforming to the second gateway communication protocol for each functional service; The first placeholder function contains serialization logic that converts a Hypertext Transfer Protocol (HTTP) request into a message format for the first gateway, and the second placeholder function contains serialization logic that converts an HTTP request into a message format for the second gateway. The service gateway compiles the first placeholder function and the second placeholder function into the first gateway executable code fragment and the second gateway executable code fragment, respectively. It then installs the first gateway executable code fragment into the plugin container of the first gateway and the second gateway executable code fragment into the plugin container of the second gateway through the gateway management interface.

[0010] Furthermore, the process by which the serving gateway encapsulates gateway protocol messages includes: The service gateway extracts the body content from the Hypertext Transfer Protocol request sent by the client application and parses the body content into a set of key-value pairs; The service gateway queries the session binding relationship table to obtain the card reader identifier currently bound to the client application and the current service gateway identifier; If the current service gateway identifier points to the first gateway, the service gateway calls the protocol adapter corresponding to the first gateway. The protocol adapter encodes the key-value pair set into a binary payload according to the protocol specification of the first gateway, and adds a reader identifier field and a call sequence number field to the header of the binary payload. If the current service gateway identifier points to the second gateway, the service gateway calls the protocol adapter corresponding to the second gateway. The protocol adapter encodes the key-value pair set into a binary payload according to the protocol specification of the second gateway, and adds a reader identifier field and a call sequence number field to the header of the binary payload. The service gateway sends the encapsulated binary payload to the first or second gateway via the Transmission Control Protocol (TCP). After receiving the binary payload, the first or second gateway looks up the locally maintained reader communication socket based on the reader identifier field, removes the header from the binary payload, and sends it to the target reader through the communication socket.

[0011] Furthermore, the specific logic for the card reader to select and return to the gateway is as follows: The embedded processor of the card reader reads the first receive sequence number field from the first gateway routing table and the second receive sequence number field from the second gateway routing table; The embedded processor compares the value of the first received sequence number field with the sequence number of the most recent message received from the first gateway, and calculates the absolute value of the first sequence number deviation; The embedded processor compares the value of the second received sequence number field with the sequence number of the most recent message received from the second gateway and calculates the absolute value of the second sequence number deviation. If the absolute value of the first sequence number deviation is less than the absolute value of the second sequence number deviation, the embedded processor determines that the first gateway is the gateway with a better reachable state. If the absolute value of the second sequence number deviation is less than the absolute value of the first sequence number deviation, the embedded processor determines that the second gateway is the gateway with a better reachable state. If the absolute value of the first serial number deviation is equal to the absolute value of the second serial number deviation, the embedded processor further compares the first signal strength indication value corresponding to the first gateway with the second signal strength indication value corresponding to the second gateway, and selects the gateway with the larger signal strength indication value as the return gateway. The card reader encapsulates the execution result into a response message and sends the response message to the selected return gateway.

[0012] Furthermore, the method also includes a service migration step: The front-end integration server monitors the load metrics of the first gateway and the second gateway, including CPU utilization, memory utilization, and number of connections. The front-end integration server presets a first load limit threshold and a second load limit threshold. When the CPU utilization of the first gateway exceeds the first load limit threshold or the number of connections exceeds the second load limit threshold, the front-end integration server triggers a service migration process. The front-end integration server queries the list of card readers mounted under the first gateway in the dynamic configuration tree, and calculates the migration benefit value for each card reader in the list. The migration benefit value is equal to the connection priority score between the card reader and the second gateway minus the connection priority score between the card reader and the first gateway. The front-end integration server selects the card reader with the highest migration benefit value as the card reader to be migrated. The front-end integration server sends a migration instruction to the card reader to be migrated. The migration instruction includes the updated connection parameters of the second gateway. After the card reader receives the migration instruction, it pauses sending new service call requests through the first gateway, resends the unacknowledged messages in the current first message buffer queue through the second gateway, initiates a second registration request to the second gateway, and resumes service calls after completing the registration. The front-end integration server updates the mounted gateway identifier of the card reader in the dynamic configuration tree to the second gateway identifier.

[0013] Furthermore, the method also includes an offline caching step: The reader's embedded processor allocates a circular buffer, which consists of multiple fixed-size storage units, each containing a valid flag bit and a timestamp field; When the card reader disconnects from both the first and second gateways simultaneously, the embedded processor writes the execution result and the corresponding timestamp into the current storage unit of the circular buffer, and sets the valid flag of that storage unit to the valid state. The embedded processor continuously monitors the connection status with the first and second gateways. When it detects that a connection has been re-established with either gateway, the embedded processor traverses the circular buffer and reads all memory cells where the valid flag bits are valid. The embedded processor encapsulates the execution results in the storage unit into retransmission messages in the order of the timestamp fields, and sends the retransmission messages to the gateway through the newly established connection. After receiving the retransmission message, the gateway converts the execution result into a Hypertext Transfer Protocol response and sends it back to the client application through the service gateway. After receiving the confirmation response from the gateway, the embedded processor sets the valid flag of the corresponding storage unit to an invalid state and releases the storage unit.

[0014] Furthermore, the method also includes a configuration synchronization step: The front-end integration server maintains a configuration version vector, which includes the configuration version number of the first gateway and the configuration version number of the second gateway. The front-end integration server pushes the first configuration subset related to the first gateway in the dynamic configuration tree to the first gateway, and at the same time increments the configuration version number of the first gateway by one; The front-end integration server pushes the second configuration subset related to the second gateway in the dynamic configuration tree to the second gateway, and increments the configuration version number of the second gateway by one. After receiving the first configuration subset, the first gateway compares the local configuration version number with the first gateway configuration version number. If the local configuration version number is smaller, the local configuration is updated with the first configuration subset, and the local configuration version number is updated to the first gateway configuration version number. After receiving the second configuration subset, the second gateway compares the local configuration version number with the second gateway configuration version number. If the local configuration version number is too low, the local configuration is updated with the second configuration subset, and the local configuration version number is updated to the second gateway configuration version number. The first and second gateways broadcast configuration change notifications to the connected card readers. After receiving the configuration change notification, the card reader requests incremental configuration data from the corresponding gateway and updates its local function service mapping table based on the incremental configuration data.

[0015] This invention discloses a service-oriented front-end integration method for a smart card system supporting dual gateway access, belonging to the technical field of smart card systems. The front-end integration server maintains a dynamic configuration tree containing gateway mounting relationships and card reader service mappings. After power-on, the card reader announces its device identifier and service type via multicast. Based on historical access records, it calculates its connection priority scores with the first and second gateways and returns configuration parameters. It then registers with both gateways, establishes bidirectional communication links, and maintains two gateway routing tables locally. When a client makes a call, the service gateway selects the current service gateway based on the session binding relationship and converts the request into a gateway protocol message for forwarding to the target card reader. This invention achieves dynamic access, intelligent routing, and transparent switching between card readers and dual gateways. Service-oriented encapsulation improves system scalability and significantly enhances business continuity and operational efficiency. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the process of a service-oriented front-end integration method for a smart card system supporting dual gateway access, as claimed in an embodiment of the present invention. Figure 2 This is a second workflow diagram of a service-oriented front-end integration method for a smart card system supporting dual gateway access, as claimed in an embodiment of the present invention. Figure 3The third flowchart is a service-oriented front-end integration method for a smart card system that supports dual gateway access, as claimed in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," and "third" in this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of those features. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. All directional indications in the embodiments of this application, such as up, down, left, right, front, back, etc., are only used to explain the relative positional relationships and movements between components in a specific orientation as shown in the accompanying drawings. If the specific orientation changes, the directional indications will change accordingly. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0019] References to embodiments herein mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] According to the first embodiment of the present invention, referring to Figure 1 This invention claims protection for a service-oriented front-end integration method for a smart card system supporting dual gateway access, applied to a computing environment including card readers, a front-end integration server, and heterogeneous gateways, comprising the following steps: S1, the front-end integration server maintains the dynamic configuration tree of the all-in-one card device. The front-end integration server sends topology probe frames to the first gateway and the second gateway, and updates the online status and link quality of the corresponding gateway in the dynamic configuration tree according to the returned response data. S2. When the card reader is powered on and starts up, it announces its device identifier and supported service types on the local area network. After the front-end integration server listens to the announcement, it calculates the connection priority scores of the card reader with the first gateway and the second gateway according to the gateway mounting relationship recorded in the dynamic configuration tree. The front-end integration server returns the configuration response unicast to the card reader. S3. After receiving the configuration response, the card reader initiates registration requests to the first gateway and the second gateway respectively. After completing the authentication of the card reader, it returns a registration response and establishes a two-way communication link. The card reader maintains two gateway routing tables locally, recording the heartbeat sequence number and the message buffer queue. S4, the front-end integration server generates a corresponding RESTful application programming interface definition for each entity function supported by the card reader, publishes the interface definition to the service gateway, converts the interface definition into a call format that conforms to the gateway protocol specification, generates a gateway executable function stub and pushes it to the first gateway and the second gateway. S5, the client application sends a service call request to the service gateway. The service gateway parses the Uniform Resource Identifier in the request, determines the target service type and the target card reader identifier. Based on the session binding relationship maintained by the front-end integration server, the service gateway selects the first gateway or the second gateway as the current service gateway, encapsulates the service call request into a gateway protocol message and forwards it to the selected gateway and sends it to the target card reader through a bidirectional communication link. S6. After the card reader executes the instruction, it generates the execution result. The card reader determines the current reachability status of the first gateway and the second gateway based on the heartbeat sequence number recorded in the local gateway routing table, selects the gateway with the better reachability status as the return gateway, and encapsulates the execution result into a response message and sends it to the return gateway.

[0021] This embodiment provides a specific implementation of a service-oriented front-end integration method for a smart card system that supports dual gateway access. In the smart greenhouse of an agricultural IoT demonstration base, a front-end integration server, two heterogeneous gateways (the first gateway using the Modbus TCP protocol and the second gateway using the MQTT protocol), and twenty patch-type card readers are deployed. These card readers are installed at the greenhouse entrance and exit, the equipment control cabinet, and the harvesting vehicle, respectively.

[0022] When the front-end integration server starts, it creates a dynamic configuration tree based on a red-black tree in memory. The root node of this tree has two gateway child nodes, corresponding to the first gateway and the second gateway, respectively. Each gateway child node has a leaf node for the card reader belonging to that gateway. Each card reader leaf node stores device identifiers such as MAC addresses, communication parameters such as IP addresses, port numbers, communication timeouts, the attached gateway identifier, and a function service mapping table, such as function code 0x01 for the door opening service and function code 0x02 for the card reading service. The front-end integration server uses two independent worker threads to send UDP topology probe frames every 30 seconds to port 5000 of the first gateway and port 1883 of the second gateway. The probe frames contain server timestamps and probe sequence numbers. After receiving the probe frames, the first and second gateways return response data containing their own CPU load and online duration. The front-end integration server updates the online status (online or offline) and link quality (response latency, packet loss rate) of the corresponding gateway in the dynamic configuration tree based on the response data.

[0023] When a new card reader is connected to the greenhouse LAN and powered on, its built-in ARM Cortex-M4 processor generates a pair of session keys. The card reader encapsulates the device identifier, supported service types such as ISO / IEC 14443 Type A card reading service, and a message authentication code calculated using the session key into a UDP packet and sends it to port 50000 of multicast address 239.255.100.100. The front-end integration server joins this multicast group, and upon receiving the announcement message, verifies the signature validity of the card reader's digital certificate using a pre-configured RSA root certificate. After successful verification, the front-end integration server resolves the device identifier as RD-2024-0032 and the supported service types as MIFARE card reading and CPU card reading. The front-end integration server queries the historical access records of this device in the dynamic configuration tree and finds that the historical records show that the average response latency of the first gateway is 15 milliseconds and the average response latency of the second gateway is 45 milliseconds. Therefore, the first gateway is assigned a connection priority score of 85 points and the second gateway is assigned a connection priority score of 60 points. The front-end integration server sends a configuration response message containing the IP address of the first gateway (192.168.1.100, port number 502, connection timeout parameter of 5 seconds) and the IP address of the second gateway (192.168.1.101, port number 1883, connection timeout parameter of 8 seconds) to the MAC address of the card reader via unicast.

[0024] After receiving the configuration response, the card reader's embedded processor initiates TCP connections to port 502 of the first gateway and port 1883 of the second gateway. Once the connection is established, the card reader sends a registration request frame to the first gateway. This frame contains the card reader's digital certificate in X.509 format and a list of service functions allocated in the dynamic configuration tree, including MIFARE card reading and CPU card reading. The security module of the first gateway verifies the validity of the digital certificate. After successful verification, it returns a registration response containing the session ID assigned to the card reader and a 30-second heartbeat interval. Simultaneously, the card reader sends a similar registration request frame to the second gateway. After the second gateway's authentication service verifies the digital certificate, it returns a registration response containing the Client ID and a 60-second heartbeat interval. The card reader creates a first gateway routing table and a second gateway routing table in its local SRAM. The first gateway routing table records the first gateway identifier GW-TCP-01, the initial value of the sending sequence number 1000, the initial value of the receiving sequence number 500, the initial value of the retransmission timer 3 seconds, and allocates a 256-byte packet buffer queue. The second gateway routing table records the second gateway identifier GW-MQTT-01, the initial value of the sending sequence number 2000, the initial value of the receiving sequence number 1500, the initial value of the retransmission timer 5 seconds, and allocates a 256-byte packet buffer queue.

[0025] The service gateway loads a card reader service description file written in Protocol Buffers. This file defines the input parameters for the ReadCard service as a timeout (integer), and the output parameters as a card number (string) and card type (integer). The service gateway's interface compiler parses this file and generates an abstract syntax tree (AST). The compiler traverses the AST and generates a first placeholder function conforming to the Modbus TCP protocol and a second placeholder function conforming to the MQTT protocol for the ReadCard service. The first placeholder function contains logic for converting the JSON payload of an HTTP POST request into Modbus protocol data units; the second placeholder function contains logic for converting the JSON payload of an HTTP POST request into an MQTT message payload. The service gateway compiles these two placeholder functions into machine code in the ARM Thumb instruction set and installs the first placeholder function into a dlopen-based dynamic library in the first gateway's plugin container and the second placeholder function into the second gateway's plugin container via the gateway management interface.

[0026] The greenhouse management system's client application sends a service call request to the service gateway's / card / read interface via HTTP POST. The request body contains the target card reader identifier RD-2024-0032. The service gateway parses the request, queries the session binding table, and finds that the card reader is currently bound to the first gateway. The service gateway calls the Modbus TCP protocol adapter, which encodes the timeout parameter in the request body into a two-byte binary value and adds the card reader identifier RD-2024-0032 and the call sequence number 12345 to its header. The service gateway sends the encapsulated binary payload to the first gateway's port 502 via a TCP connection. After receiving the payload, the first gateway looks up the locally maintained card reader communication socket handle 0x7F3A based on the card reader identifier, removes the header from the binary payload, and sends it to the target card reader through this socket.

[0027] After executing the card reading command, the card reader generates the execution result card number 3100765432 and card type 01. The embedded processor of the card reader reads the current value of the receive sequence number field in the first gateway routing table (501), and the most recently received message sequence number from the first gateway (502). The absolute value of the first sequence number deviation is calculated to be 1. The processor also reads the current value of the receive sequence number field in the second gateway routing table (1501), and the most recently received message sequence number from the second gateway (1502). The absolute value of the second sequence number deviation is calculated to be 1. Since they are equal, the processor further compares the Wi-Fi signal strength indicator value (-67dBm) corresponding to the first gateway with the Wi-Fi signal strength indicator value (-72dBm) corresponding to the second gateway, selecting the first gateway with the stronger signal as the return gateway. The card reader encapsulates the execution result into a response message and sends it to the first gateway through the TCP connection established with the first gateway. The first gateway converts the response message into an HTTP 200 OK acknowledgment and sends it back to the client application through the serving gateway.

[0028] Furthermore, the methods for updating the dynamic configuration tree include: The front-end integration server maintains the first transaction log corresponding to the first gateway and the second transaction log corresponding to the second gateway. The first transaction log records the response timestamp and response content summary of each topology probe of the first gateway, and the second transaction log records the response timestamp and response content summary of each topology probe of the second gateway. The front-end integration server inputs the first transaction log and the second transaction log into the change detector, and the change detector calculates the first gateway state change entropy value and the second gateway state change entropy value. When the entropy value of the first gateway's status change exceeds the first threshold, the front-end integration server marks the list of mounted card readers of the first gateway in the dynamic configuration tree as pending refresh. When the entropy value of the second gateway's status change exceeds the second threshold, the front-end integration server will mark the list of mounted card readers of the second gateway in the dynamic configuration tree as pending refresh. The front-end integration server recalculates the connection priority score between the card reader and the first and second gateways based on the marking results.

[0029] In this embodiment, the front-end integration server maintains two circular log files, named gw_tcp_trans.log and gw_mqtt_trans.log, respectively, to record the topology probe results of the first and second gateways. After each topology probe, the front-end integration server appends the current system timestamp, probe sequence number, gateway response timestamp, CPU load percentage returned by the gateway, and online duration in seconds to the corresponding log file in binary format. Each log file is limited to 10MB in size; records exceeding this limit are automatically overwritten by the oldest record.

[0030] A separate change detector thread runs on the front-end integration server. This thread is woken up every 5 minutes. Upon waking, the change detector thread first opens the `gw_tcp_trans.log` file, reads the 50 most recent probe records from the end of the file backwards, converts the response timestamps in these records into latency differences relative to the current time, and calculates the average of these 50 latency differences as `μ_tcp` and the standard deviation as `σ_tcp`. The change detector thread calculates the first gateway state change entropy value `H_tcp = -Σ(p_i * log2(p_i))`, where `p_i` is the proportion of records in each of the 50 latency differences divided into 10 equally spaced intervals. Simultaneously, the change detector thread performs the same operation on the `gw_mqtt_trans.log` file to calculate the second gateway state change entropy value `H_mqtt`.

[0031] When the value of H_tcp exceeds the preset first threshold of 0.8, the change detector thread determines that the network status of the first gateway has fluctuated drastically. At this time, the change detector thread sends an event notification to the dynamic configuration tree management module. This notification contains the identifier of the first gateway, GW-TCP-01. After receiving the notification, the dynamic configuration tree management module traverses all the card reader leaf nodes with the gateway identifier GW-TCP-01 in the dynamic configuration tree and changes the status field of these nodes from stable to pending refresh. Similarly, when the value of H_mqtt exceeds the preset second threshold of 0.7, the dynamic configuration tree management module changes the status field of all card reader leaf nodes attached to the second gateway to pending refresh.

[0032] The dynamic configuration tree management module then triggers a priority recalculation process. For each reader leaf node in the "awaiting refresh" state, the module rereads the response latency data of the two gateways from the node's historical access records. It retrieves the average response latency of the last 10 service calls forwarded through the first gateway (e.g., 18 milliseconds) and the average response latency of the last 10 service calls forwarded through the second gateway (e.g., 42 milliseconds) from the circular buffer in memory. The priority recalculation algorithm is: First gateway priority score = 100 - First gateway average response latency; Second gateway priority score = 100 - Second gateway average response latency. In the example above, the first gateway score is 82 points, and the second gateway score is 58 points. The dynamic configuration tree management module updates these two scores to the corresponding fields of the reader leaf node and restores the node status field to stable. Simultaneously, it sends the updated priority scores to the corresponding reader via an asynchronous notification message. Upon receiving the notification, the reader updates its locally stored gateway priority table for use in subsequent dual registration or service migration.

[0033] Furthermore, referring to Figure 2 The specific implementation method for a card reader to announce its own device identifier and supported service types is as follows: The card reader's security coprocessor generates a pair of session keys, uses these session keys to calculate the message authentication code for the announcement message, and appends the message authentication code to the end of the announcement message; The card reader sends an announcement message to the User Datagram Protocol multicast group via the physical layer broadcast address; the front-end integration server joins the multicast group, receives the announcement message, and uses the pre-set root certificate to verify the validity of the card reader's digital certificate. After successful verification, it extracts the device identifier and service type from the announcement message. The front-end integration server queries the historical access records associated with the device identifier in the dynamic configuration tree. If the average response latency of the first gateway in the historical access records is less than the average response latency of the second gateway, then the first gateway is assigned a higher connection priority score. If the average response latency of the second gateway is less than that of the first gateway, then the second gateway is assigned a higher connection priority score. The front-end integration server will send a configuration response message containing the Internet Protocol address, port number, and connection timeout parameters of the first gateway and the Internet Protocol address, port number, and connection timeout parameters of the second gateway to the media access control address of the card reader via unicast.

[0034] In this embodiment, the card reader's hardware design includes a dedicated security coprocessor chip, model Infineon OPTIGA Trust M. This chip has a pre-installed unique device certificate issued by the system integrator's root CA and a pair of ECC-256 public and private keys. After the card reader powers on, the main control CPU sends a session key generation command to the security coprocessor via the I2C interface. The security coprocessor then generates a 256-bit random number as the session key and signs the session key using the card reader's private key to generate a signature value S.

[0035] The process of constructing the announcement message is as follows: The master CPU encodes the device identifier RD-2024-0032 into a 16-byte ASCII string, and encodes the supported service types MIFARE card read and CPU card read into a two-byte bitmap. Bit 0 represents MIFARE support and bit 1 represents CPU card support. The master CPU combines this information with the plaintext session key generated by the security coprocessor and the signature value S into an announcement message with a length of 128 bytes. Then, the master CPU uses the session key to calculate HMAC-SHA256 on the entire message part except for the signature value to obtain a 32-byte message authentication code, and appends the authentication code to the end of the message.

[0036] The card reader sends the complete announcement message via the Ethernet PHY chip to the multicast IP address 239.255.100.100 and UDP port 50000. The TTL of this multicast group is set to 2, limiting its propagation to the local subnet. The network interface card of the front-end integration server, which has IGMPv3 enabled, joins this multicast group. When the announcement message arrives at the front-end integration server, the network protocol stack delivers it to the user-space daemon listening on port 50000.

[0037] Upon receiving the message, the daemon first extracts the device certificate in X.509 format. It then verifies the device certificate's signature chain using the root CA certificate's PEM format pre-installed in the file system, ensuring the certificate has not been tampered with and is valid. After successful verification, the daemon extracts the reader's public key from the device certificate. Using this public key, it decrypts the signature value S to obtain the decrypted session key. The daemon then compares the decrypted session key byte-by-byte with the plaintext session key carried in the message. If they match completely, it proves that the sender of the message indeed possesses the private key corresponding to the certificate.

[0038] Subsequently, the daemon process uses the session key to recalculate the HMAC-SHA256 of the packet payload from the device identifier to the message authentication code, and compares the calculated result with the message authentication code carried at the end of the packet. If the comparison matches, it proves that the packet has not been tampered with during transmission. After successful verification, the daemon process parses the device identifier and service type bitmap. Next, the daemon process queries the historical access record table in the dynamic configuration tree; this table records the statistics of service calls made by each device identifier through the first gateway and the second gateway in the past 24 hours. The daemon process retrieves the historical records of device RD-2024-0032: 95 successful calls through the first gateway, with an average response latency of 12ms; and 5 successful calls through the second gateway, with an average response latency of 55ms. Based on these data, the daemon process calculates the connection priority score: first gateway score = 95 * 1.0 / (12 + 1) ≈ 7.3, second gateway score = 5 * 1.0 / (55 + 1) ≈ 0.09, therefore the first gateway obtains a significantly higher priority.

[0039] Finally, the daemon constructs a configuration response message; this message includes the IP address of the first gateway (192.168.1.100), TCP port (502), connection timeout parameters (maximum connection establishment time: 5 seconds, read timeout: 3 seconds, write timeout: 3 seconds), and the IP address of the second gateway (192.168.1.101), TCP port (1883), connection timeout parameters (maximum connection establishment time: 8 seconds, read timeout: 5 seconds, write timeout: 5 seconds). The daemon obtains the reader's MAC address through the ARP cache and sends the configuration response message to that MAC address via UDP unicast.

[0040] Furthermore, the process by which the card reader maintains the two gateway routing tables includes: The embedded processor of the card reader creates a first gateway routing table and a second gateway routing table. The first gateway routing table includes a first gateway identifier field, a first sending sequence number field, a first receiving sequence number field, a first retransmission timer field, and a first message buffer queue pointer. The second gateway routing table includes a second gateway identifier field, a second sending sequence number field, a second receiving sequence number field, a second retransmission timer field, and a second message buffer queue pointer. When sending a registration request to the first gateway, the first sending sequence number field is assigned the current system tick count value, and a copy of the registration request message is stored in the first message cache queue; After receiving the registration response from the first gateway, the confirmation sequence number in the response is extracted and compared with the first sent sequence number. If they match, the corresponding copy of the registration request message in the first message buffer queue is cleared. When sending a registration request to the second gateway, the second sending sequence number field is assigned the current system tick count value, and a copy of the registration request message is stored in the second message cache queue; After receiving the registration response from the second gateway, extract the confirmation sequence number from the response and compare it with the second sending sequence number. If they match, clear the corresponding registration request message copy in the second message buffer queue. Check the first retransmission timer and the second retransmission timer. If the first retransmission timer expires and the first message buffer queue is not empty, retransmit the messages in the first message buffer queue. If the second retransmission timer times out and the second message buffer queue is not empty, then the messages in the second message buffer queue will be retransmitted.

[0041] In this embodiment, after the embedded processor STM32H743 of the card reader completes hardware initialization upon power-on, it divides two structure instances in a specific area of ​​its internal SRAM, named gateway_route_tcp and gateway_route_mqtt respectively. The memory layout of these two structures is exactly the same, and each structure contains the following fields: gateway_id

[16] byte array, tx_seq_num 32-bit unsigned integer, rx_seq_num 32-bit unsigned integer, retransmit_timer 32-bit unsigned integer in milliseconds, retransmit_count 8-bit unsigned integer, cache_queue_head pointer pointing to a doubly linked list, and cache_queue_tail pointer.

[0042] The process of the card reader initiating a registration request to the first gateway is as follows: The embedded processor reads the tx_seq_num field from the gateway_route_tcp structure, currently valued at 1000; it constructs a registration request frame with the following format: frame header 0xA5A5 + device identifier 16 bytes + serial number 4 bytes (1000) + certificate length 2 bytes + variable digital certificate content + frame trailer 0x5A5A; after construction, the embedded processor copies a complete copy of the frame, including all fields, to the first cache node pointed to by cache_queue_head via DMA; this cache node is a pre-allocated 512-byte memory block containing a data area, length field, and timestamp field; after copying, the embedded processor sets the retransmit_timer field to 3000 milliseconds and enables the timer, then sends the frame to the first gateway via a TCP socket.

[0043] When the card reader receives a registration response frame from the first gateway, the embedded processor parses the acknowledgment sequence number field in the response frame. It compares this acknowledgment sequence number with the tx_seq_num field (1000) in the gateway_route_tcp structure. If they are equal, the embedded processor traverses from the head of the linked list pointed to by cache_queue_head, finds the cache node with sequence number 1000, removes the node from the linked list, marks the memory block as free, and increments the tx_seq_num field in the gateway_route_tcp structure to 1001. If the received acknowledgment sequence number is less than 1000, it indicates an old retransmission response, and the processor ignores the response.

[0044] The process of the card reader initiating a registration request to the second gateway is exactly the same, but it operates on the gateway_route_mqtt structure. It puts the current tx_seq_num of 2000 into the variable header of the MQTT CONNECT message as the message ID, caches the complete message in the second message cache queue, sets retransmit_timer to 5000 milliseconds, and after receiving the CONNACK message from the second gateway, it parses out the acknowledgment sequence number, releases the cache after a successful comparison, and updates tx_seq_num to 2001.

[0045] An embedded processor runs a timer interrupt service routine that triggers periodically every 1 millisecond. Each time this routine executes, it iterates through the `gateway_route_tcp` and `gateway_route_mqtt` structures. For each structure, it checks the value of the `retransmit_timer` field. If the value is greater than 0, it decrements it by 1. When the value reaches 0, the interrupt service routine triggers a retransmission event. It checks the `cache_queue_head` pointer; if the pointer is not empty, it indicates there are unacknowledged packets in the queue. It then reads a copy of the packet from the cache node at the head of the queue and retransmits it through the corresponding gateway connection. After retransmission, the `retransmit_timer` field is reset to the original timeout value (3000 for TCP, 5000 for MQTT), and the `retransmit_count` field is incremented by 1. If the `retransmit_count` value exceeds 3 times, the embedded processor determines that the gateway connection is unavailable, reports a gateway failure to the upper-layer application, and suspends transmission attempts to that gateway.

[0046] Furthermore, referring to Figure 3 The methods for generating gateway executable function stubs include: The service gateway loads the card reader service description file, which is written in an interface definition language and describes the input parameter types, output parameter types, and calling constraints of each functional service supported by the card reader. The service gateway's interface compiler performs lexical analysis, syntax analysis, and semantic analysis on the service description file to generate an abstract syntax tree; The interface compiler traverses the abstract syntax tree, generating a first placeholder function conforming to the first gateway communication protocol for each functional service and a second placeholder function conforming to the second gateway communication protocol for each functional service; The first placeholder function contains serialization logic that converts a Hypertext Transfer Protocol (HTTP) request into a message format for the first gateway, and the second placeholder function contains serialization logic that converts an HTTP request into a message format for the second gateway. The service gateway compiles the first placeholder function and the second placeholder function into the first gateway executable code fragment and the second gateway executable code fragment, respectively. It then installs the first gateway executable code fragment into the plugin container of the first gateway and the second gateway executable code fragment into the plugin container of the second gateway through the gateway management interface.

[0047] In this embodiment, the service gateway is deployed on an x86-based industrial control computer running a Linux operating system. The card reader supplier provides a Protocol Buffers v3 description file named card_service.proto, which defines the service interface. The service gateway calls the protoc compiler and specifies custom plugin parameters to generate gateway-specific code.

[0048] The protoc compiler first performs lexical analysis on card_service.proto, breaking down the input character stream into token sequences such as identifiers, keywords, and numbers. Then, it performs syntax analysis, combining the token sequences into an abstract syntax tree according to the syntax rules of Proto v3. The root node of this abstract syntax tree represents the file, and its child nodes represent package names, import declarations, and service definitions. The service definition node contains multiple method nodes, and each method node contains a method name, input message type, output message type, and optional options.

[0049] The protoc compiler traverses this abstract syntax tree. When it encounters a method node, such as a method named ReadCard, it checks if the method is marked with a custom option, such as gateway_plugin = "modbus_tcp". Based on this option, the compiler enters the code generation stage. For the Modbus TCP protocol, the compiler generates a C language function with the prototype int modbus_read_card_stub(unsigned char *req, int req_len, unsigned char *rsp, int *rsp_len). The function body implements the following logic: it parses the JSON string of the HTTP request from the input req buffer and uses the cJSON library to extract the integer value of the timeout field. This integer value is converted into the Modbus protocol data unit format, i.e., a Modbus PDU is constructed, with its function code set to 0x46 (customizable) and the data field containing a two-byte timeout value. Then, this PDU is copied to the beginning of the output buffer rsp, and *rsp_len is set to the length of the PDU.

[0050] For the MQTT protocol, the compiler generates another C function, `int mqtt_read_card_stub(unsigned char *req, int req_len, unsigned char *rsp, int *rsp_len)`. This function implements the following logic: it parses the JSON, extracts the timeout, and then constructs an MQTT application message with a fixed subject of ` / devices / + / command / readcard` and a binary payload. The first two bytes are the timeout, followed by a terminator. The entire MQTT message, including the fixed header, variable header, subject, and payload, is serialized into the output buffer `rsp`.

[0051] After generating these two C functions, the service gateway calls the cross-compiler toolchain to compile these two C files into shared object files that match the target gateway architecture. The first gateway runs on an ARMv7 architecture, so the compiler uses arm-linux-gnueabihf-gcc with the compilation parameters -shared -fPIC, generating the libmodbus_stub.so file. The second gateway runs on a MIPS architecture, and the compiler uses mips-linux-gnu-gcc, generating the libmqtt_stub.so file. The service gateway uses the scp command to copy these two .so files to the / usr / lib / plugins / directories of the first and second gateways respectively. Then, the service gateway communicates via HTTP REST... The API sends a POST request to the plugin management interface of the first gateway. The request body contains the plugin name and path. The plugin manager of the first gateway uses the dlopen() function to load the .so file and uses the dlsym() function to obtain the address of the modbus_read_card_stub function, registering it as a callback function to handle specific Modbus function codes. Similarly, a POST request is sent to the second gateway. The plugin manager of the second gateway loads the MQTT stub function and subscribes it to the corresponding MQTT topic.

[0052] Furthermore, the process by which the serving gateway encapsulates gateway protocol messages includes: The service gateway extracts the body content from the Hypertext Transfer Protocol request sent by the client application and parses the body content into a set of key-value pairs; The service gateway queries the session binding relationship table to obtain the card reader identifier currently bound to the client application and the current service gateway identifier; If the current service gateway identifier points to the first gateway, the service gateway calls the protocol adapter corresponding to the first gateway. The protocol adapter encodes the key-value pair set into a binary payload according to the protocol specification of the first gateway, and adds a reader identifier field and a call sequence number field to the header of the binary payload. If the current service gateway identifier points to the second gateway, the service gateway calls the protocol adapter corresponding to the second gateway. The protocol adapter encodes the key-value pair set into a binary payload according to the protocol specification of the second gateway, and adds a reader identifier field and a call sequence number field to the header of the binary payload. The service gateway sends the encapsulated binary payload to the first or second gateway via the Transmission Control Protocol (TCP). After receiving the binary payload, the first or second gateway looks up the locally maintained reader communication socket based on the reader identifier field, removes the header from the binary payload, and sends it to the target reader through the communication socket.

[0053] In this embodiment, the service gateway maintains a hash table in memory to store session binding relationships. The key of this hash table is a 32-byte random string representing the client application's session ID, and the value is a structure containing the target card reader identifier RD-2024-0032 and the current service gateway identifier GW-TCP-01. When the client application sends an HTTP POST request to http: / / gateway.local / api / v1 / card / read, the HTTP header of this request includes a Cookie field with the session ID as its value. The service gateway's web server module parses this header using libmicrohttpd, extracts the session ID, and uses it to look up the corresponding binding relationship in the hash table.

[0054] After finding the binding relationship, the web server module extracts the body of the HTTP request—a JSON string, such as {"timeout": 500}—as a continuous byte stream; it then checks the value of the current service gateway identifier. Since this value is GW-TCP-01, the web server module calls the pre-registered Modbus TCP protocol adapter function. This adapter function first creates a new buffer of 256 bytes. It copies the target reader identifier RD-2024-0032 to the beginning of the buffer, occupying 16 bytes, padding any remaining space with zeros. Next, it retrieves the next available call sequence number from a global atomic variable, such as 67890, and copies this 32-bit integer in little-endian order to the four bytes immediately following the identifier.

[0055] The adapter function then parses the JSON string in the HTTP request body. It iterates through each key-value pair of the JSON object, and when it encounters the key "timeout," it extracts the corresponding value 500. According to the Modbus protocol specification, the adapter function encodes this timeout parameter into a two-byte Modbus data unit: the high byte is 0x01, and the low byte is 0xF4 (because 500 = 0x01F4). It also implicitly determines the function code by the target service type; for example, card reader service corresponds to Modbus function code 0x46. The adapter function fills the buffer with function code 0x46, data length 0x02, and the two data bytes 0x01 and 0xF4, immediately following the sequence number.

[0056] After filling, the adapter function calculates the length of the entire buffer as 16 + 4 + 1 + 1 + 2 = 24 bytes. It sends this 24 bytes of binary data via a pre-established TCP long connection socket file descriptor (7) to the first gateway using the `send()` system call. The send operation is set to blocking mode with a timeout of 5 seconds. The event-driven server running on the first gateway, based on libevent, receives this 24 bytes of data. It first reads the first 16 bytes, parsing out the target reader identifier as RD-2024-0032. Then, it looks up the reader hash table it maintains, finding the corresponding TCP socket file descriptor (21). Next, the first gateway skips the first 16 bytes from the received buffer, starting from byte 17 (function code 0x46), and sends the remaining 8 bytes (function code + length + data) to the target reader via socket 21.

[0057] Furthermore, the specific logic for the card reader to select and return to the gateway is as follows: The embedded processor of the card reader reads the first receive sequence number field from the first gateway routing table and the second receive sequence number field from the second gateway routing table; The embedded processor compares the value of the first received sequence number field with the sequence number of the most recent message received from the first gateway, and calculates the absolute value of the first sequence number deviation; The embedded processor compares the value of the second received sequence number field with the sequence number of the most recent message received from the second gateway and calculates the absolute value of the second sequence number deviation. If the absolute value of the first sequence number deviation is less than the absolute value of the second sequence number deviation, the embedded processor determines that the first gateway is the gateway with a better reachable state. If the absolute value of the second sequence number deviation is less than the absolute value of the first sequence number deviation, the embedded processor determines that the second gateway is the gateway with a better reachable state. If the absolute value of the first serial number deviation is equal to the absolute value of the second serial number deviation, the embedded processor further compares the first signal strength indication value corresponding to the first gateway with the second signal strength indication value corresponding to the second gateway, and selects the gateway with the larger signal strength indication value as the return gateway. The card reader encapsulates the execution result into a response message and sends the response message to the selected return gateway.

[0058] In this embodiment, after the card reader executes the card reading instruction, its embedded processor immediately enters the response routing selection subroutine after the interrupt returns. This subroutine first accesses the peripheral register and reads the memory base address storing the first gateway routing table and the second gateway routing table.

[0059] The processor reads the current value (501) from the rx_seq_num field at offset 8 bytes in the first gateway routing table structure. Then, it parses the header of the most recently successfully received and processed application layer packet from the receive buffer allocated to the first gateway by the network protocol stack, extracts the sequence number field, and obtains 502. The processor executes a subtraction instruction to calculate the absolute value |502 - 501| = 1. This value is temporarily stored in register R0.

[0060] Next, the processor reads the current value (1501) from the second gateway routing table structure at an offset of 8 bytes. It then parses the most recently successfully received MQTT message from the second gateway's receive buffer, extracts the message ID field from the variable header, and obtains 1502. The absolute value |1502 - 1501| = 1 is calculated. This value is temporarily stored in register R1.

[0061] The processor executes a comparison instruction, comparing the values ​​of R0 and R1. Since both are 1, the equality flag in the comparison result status register is set. After detecting that the equality flag is 1, the processor jumps to the signal strength comparison branch. In this branch, the processor first reads the register of the Wi-Fi module (model ESP8266) associated with the first gateway. This module periodically reports the current connection signal strength via AT commands; the most recently reported value is stored in a specific memory variable. The processor reads this variable and obtains -67dBm. Then, the processor reads the signal strength register of the Wi-Fi module associated with the second gateway in the same manner, obtaining -72dBm.

[0062] The processor executes the comparison instruction again, comparing -67 and -72. Since -67 is greater than -72, the processor determines that the signal quality of the first gateway is better; therefore, it sets the gateway selection flag to 0, representing the first gateway. If the signal strengths are also equal, the processor will further compare the retransmit_count fields in the routing tables of the two gateways and select the gateway with fewer retransmissions.

[0063] After determining that the return gateway is the first gateway, the processor constructs a response message. It encodes the execution result card number 3100765432 and card type 01 according to the first gateway's protocol specifications. After encoding, the processor places the message into the first gateway's corresponding send buffer and triggers the network controller to send a DMA request, transmitting the data to the first gateway via the established TCP connection. Simultaneously, the processor updates the `rx_seq_num` field in the first gateway's routing table, setting its value to the received message sequence number 502 for future reference.

[0064] Furthermore, the method also includes a service migration step: The front-end integration server monitors the load metrics of the first gateway and the second gateway. The load metrics include CPU utilization, memory utilization, and number of connections. The front-end integration server presets a first load limit threshold and a second load limit threshold. When the CPU utilization of the first gateway exceeds the first load limit threshold or the number of connections exceeds the second load limit threshold, the front-end integration server triggers a service migration process. The front-end integration server queries the list of card readers mounted under the first gateway in the dynamic configuration tree, and calculates the migration benefit value for each card reader in the list. The migration benefit value is equal to the connection priority score between the card reader and the second gateway minus the connection priority score between the card reader and the first gateway. The front-end integration server selects the card reader with the highest migration benefit value as the card reader to be migrated. The front-end integration server sends a migration instruction to the card reader to be migrated. The migration instruction includes the updated connection parameters of the second gateway. After the card reader receives the migration instruction, it pauses sending new service call requests through the first gateway, resends the unacknowledged messages in the current first message buffer queue through the second gateway, initiates a second registration request to the second gateway, and resumes service calls after completing the registration. The front-end integration server updates the mounted gateway identifier of the card reader in the dynamic configuration tree to the second gateway identifier.

[0065] In this embodiment, the monitoring module of the front-end integration server sends GET requests to the / status interface of the first gateway and the / status interface of the second gateway every 10 seconds through two independent HTTP connections to obtain load metrics. An example of the JSON response returned by the first gateway is {"cpu": 85.5, "mem": 40.2, "conn": 28}, and an example of the JSON response returned by the second gateway is {"cpu": 30.1, "mem": 25.8, "conn": 12}.

[0066] The monitoring module has two preset thresholds: a maximum CPU utilization threshold of 80% and a maximum connection limit of 25. The monitoring module compares the CPU utilization of 85.5% returned by the first gateway with 80%, and finds that 85.5% > 80%, triggering the service migration process. The monitoring module sends an event to the dynamic configuration tree management module, with the event type being GATEWAY_OVERLOAD and carrying the gateway ID GW-TCP-01.

[0067] Upon receiving the event, the dynamic configuration tree management module locks the gateway child node GW-TCP-01 in the dynamic configuration tree. It then traverses all 28 reader leaf nodes under this node. For each reader leaf node, the management module reads the first gateway priority score and the second gateway priority score stored in that node. Taking one reader as an example, its first gateway score is 82 and its second gateway score is 58. The management module calculates the migration benefit value: Second gateway score - First gateway score = 58 - 82 = -24. Since the benefit value is negative, it means that migrating to the second gateway will degrade performance, therefore this reader is not suitable for migration. The management module continues to traverse until it finds a reader with a positive benefit value, i.e., a second gateway score higher than the first gateway score; for example, another reader has a first gateway score of 60 and a second gateway score of 75, then the migration benefit value = 75 - 60 = 15. The management module selects the reader with the largest benefit value among all readers with positive benefits as the reader to be migrated.

[0068] After identifying the reader to be migrated, the management module sends a TCP migration command to the reader. This command is a custom protocol message whose payload includes updated connection parameters for the second gateway: IP address 192.168.1.101, port 1883, and a new heartbeat interval of 60 seconds. Upon receiving the command, the reader's embedded processor first stops sending any new service call requests through the first gateway. For messages already sent but not yet acknowledged, stored in the first message buffer queue, the reader retrieves these messages one by one, re-encapsulates them according to the second gateway's protocol format, and retransmits them through the established connection to the second gateway. After retransmission, the reader sends an MQTTCONNECT message to the second gateway, carrying the same Client ID, initiating a secondary registration request. Upon receiving this message, the second gateway finds that the Client ID already exists and, according to the MQTT protocol specification, disconnects the old connection, accepts the new connection, and returns CONNACK. After successful registration, the card reader resumes normal service calls. All new call requests are forwarded through the second gateway. Finally, the card reader sends a migration completion confirmation message to the front-end integration server. Upon receiving the confirmation, the front-end integration server updates the mounted gateway identifier field of the card reader's leaf node in the dynamic configuration tree, changing it from GW-TCP-01 to GW-MQTT-01.

[0069] Furthermore, the method also includes an offline caching step: The reader's embedded processor allocates a circular buffer, which consists of multiple fixed-size storage units, each containing a valid flag bit and a timestamp field; When the card reader disconnects from both the first and second gateways simultaneously, the embedded processor writes the execution result and the corresponding timestamp into the current storage unit of the circular buffer, and sets the valid flag of that storage unit to the valid state. The embedded processor continuously monitors the connection status with the first and second gateways. When it detects that a connection has been re-established with either gateway, the embedded processor traverses the circular buffer and reads all memory cells where the valid flag bits are valid. The embedded processor encapsulates the execution results in the storage unit into retransmission messages in the order of the timestamp fields, and sends the retransmission messages to the gateway through the newly established connection. After receiving the retransmission message, the gateway converts the execution result into a Hypertext Transfer Protocol response and sends it back to the client application through the service gateway. After receiving the confirmation response from the gateway, the embedded processor sets the valid flag of the corresponding storage unit to an invalid state and releases the storage unit.

[0070] In this embodiment, during initialization, the embedded processor allocates a region on the external SPI Flash chip as a circular buffer. This circular buffer is formatted into 100 fixed-size storage units, each unit being 512 bytes. The first 8 bytes of each storage unit are metadata, including a 1-byte validity flag (0xAA for valid, 0x00 for invalid) and a 7-byte Unix timestamp representing the number of milliseconds since January 1, 1970. Following the metadata is a 504-byte data payload area.

[0071] During normal operation, the card reader periodically sends heartbeat messages to the first and second gateways. When the card reader fails to receive a heartbeat response from any gateway three times consecutively, its embedded processor determines that it is disconnected from all gateways. At this time, the processor sets the network protocol stack to offline. When a new service call request arrives, such as a card reading command, the card reader executes the command and obtains the execution result card number 3100765432. The processor reads the current system real-time clock and obtains the timestamp 16800000000000 milliseconds. It uses a write pointer to find the address of the next available storage unit in the circular buffer. The processor first writes the metadata part: setting the valid flag to 0xAA, writing the timestamp to the next 7 bytes, and then encoding the execution result string card number 3100765432 and related service type information into a byte stream and writing it to the data payload area of ​​the storage unit. After writing is complete, the write pointer moves to the next storage unit.

[0072] The card reader's main loop includes a dedicated connection monitoring task. This task attempts to send a probe message to both the first and second gateways every second. When it detects a successful TCP connection establishment with the second gateway and a completed MQTT handshake, the task triggers a re-entry event. The event handler first suspends all new service call processing and enters buffer replay mode. It uses a read pointer to locate the earliest valid storage unit in the circular buffer by scanning the unit with a valid flag of 0xAA. It reads the timestamp and data payload of this unit. The handler encapsulates the data payload into a standard service response message according to the timestamp order and sends it through the newly restored second gateway connection. During transmission, this message uses a special offline retransmission identifier so that the gateway can distinguish it from a normal response.

[0073] After sending a message, the processor waits for an acknowledgment from the second gateway. This acknowledgment can be a TCP-layer ACK or an application-layer acknowledgment such as MQTT PUBACK. Once received, the processor returns to the storage unit, changes the valid flag in its metadata from 0xAA to 0x00, and releases the unit. Then, the read pointer moves to the next storage unit, continuing reading and sending until a unit with a valid flag of 0x00 is encountered, indicating no more historical data is cached. After cache replay is complete, the card reader resumes normal online service mode, and new service call requests are forwarded directly in real time without being written to the circular buffer.

[0074] Furthermore, the method also includes a configuration synchronization step: The front-end integration server maintains a configuration version vector, which includes the configuration version number of the first gateway and the configuration version number of the second gateway. The front-end integration server pushes the first configuration subset related to the first gateway in the dynamic configuration tree to the first gateway, and at the same time increments the configuration version number of the first gateway by one; The front-end integration server pushes the second configuration subset related to the second gateway in the dynamic configuration tree to the second gateway, and increments the configuration version number of the second gateway by one. After receiving the first configuration subset, the first gateway compares the local configuration version number with the first gateway configuration version number. If the local configuration version number is smaller, the local configuration is updated with the first configuration subset, and the local configuration version number is updated to the first gateway configuration version number. After receiving the second configuration subset, the second gateway compares the local configuration version number with the second gateway configuration version number. If the local configuration version number is too low, the local configuration is updated with the second configuration subset, and the local configuration version number is updated to the second gateway configuration version number. The first and second gateways broadcast configuration change notifications to the connected card readers. After receiving the configuration change notification, the card reader requests incremental configuration data from the corresponding gateway and updates its local function service mapping table based on the incremental configuration data.

[0075] In this embodiment, when the front-end integration server starts, it initializes a configuration version vector structure in memory. This structure contains two member variables: tcp_cfg_version, which is initialized to 0, and mqtt_cfg_version, which is initialized to 0. Whenever the configuration related to the first gateway in the dynamic configuration tree changes, such as adding a new card reader or modifying the service mapping table of a card reader, the front-end integration server increments the value of tcp_cfg_version by 1. Similarly, when the configuration related to the second gateway changes, the value of mqtt_cfg_version is incremented by 1.

[0076] After the configuration changes, the synchronization thread of the front-end integration server is awakened. This thread first checks whether `tcp_cfg_version` is greater than the version number last synchronized to the first gateway. If so, it extracts the configuration information of all card readers mounted under the first gateway from the dynamic configuration tree, including the device identifier, function service mapping table, communication timeout parameters, etc. of each card reader, and serializes this information into JSON format. Then, it sends the JSON data containing the complete configuration subset to the ` / configure` interface of the first gateway via an HTTP PUT request, adding a custom field `X-Config-Version` to the HTTP header with the value of the latest `tcp_cfg_version`. After successful transmission, the synchronization thread updates the version number last synchronized to the first gateway to the current `tcp_cfg_version`. For the second gateway, the synchronization thread performs the exact same operation, sending the second configuration subset and `mqtt_cfg_version`.

[0077] Upon receiving an HTTP PUT request, the configuration management daemon of the first gateway first parses the X-Config-Version field in the header to obtain the version number, for example, 35. It then reads the version number field from the locally stored configuration file ` / etc / gateway.conf`, for example, 34. By comparison, it finds that 35 > 34, thus determining that this is a configuration update. The daemon completely replaces the relevant parts of the local configuration file with the received JSON data and updates the version number field in the configuration file to 35. After the update is complete, the daemon broadcasts a UDP configuration change notification message to all currently online card readers mounted under this gateway. This message contains a simple flag byte 0x01 indicating that the configuration has changed.

[0078] Upon receiving this UDP broadcast, the card reader mounted under the first gateway triggers a configuration synchronization process through its embedded processor. The card reader immediately sends an HTTP GET request to the first gateway's ` / configure / pull` interface, attaching the hash value of its current local service mapping table (calculated using CRC32) to the request header. Upon receiving the request, the first gateway's configuration management daemon searches for the latest configuration based on the card reader's identifier, calculates the hash value of the latest configuration, and compares it with the hash value sent by the card reader. If they do not match, the daemon encapsulates the complete incremental configuration data specific to that card reader (e.g., only including changed service mapping table entries) into JSON format and returns it to the card reader as the body of the HTTP response. The card reader receives the incremental configuration data, parses the JSON, and updates the service mapping table stored in its local Flash memory. After the update is complete, the card reader sends an acknowledgment to the gateway. The entire configuration synchronization process is completed within seconds, requiring no manual intervention.

[0079] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0080] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0081] The specific embodiments of the invention have been described in detail above, but they are only examples, and this application is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications or substitutions to the invention are also within the scope of this application. Therefore, all equivalent changes, modifications, and improvements made without departing from the spirit and principles of this application should be covered within the scope of this application.

Claims

1. A service-oriented front-end integration method for a smart card system supporting dual gateway access, applied to a computing environment including card readers, front-end integration servers, and heterogeneous gateways, characterized in that, Includes the following steps: S1, the front-end integration server maintains the dynamic configuration tree of the all-in-one card device. The front-end integration server sends topology probe frames to the first gateway and the second gateway, and updates the online status and link quality of the corresponding gateway in the dynamic configuration tree according to the returned response data. S2. When the card reader is powered on and starts up, it announces its device identifier and supported service types on the local area network. After the front-end integration server listens to the announcement, it calculates the connection priority scores of the card reader with the first gateway and the second gateway according to the gateway mounting relationship recorded in the dynamic configuration tree. The front-end integration server returns the configuration response unicast to the card reader. S3. After receiving the configuration response, the card reader initiates registration requests to the first gateway and the second gateway respectively. After completing the authentication of the card reader, it returns a registration response and establishes a two-way communication link. The card reader maintains two gateway routing tables locally, recording the heartbeat sequence number and the message buffer queue. S4, the front-end integration server generates a corresponding RESTful application programming interface definition for each entity function supported by the card reader, publishes the interface definition to the service gateway, converts the interface definition into a call format that conforms to the gateway protocol specification, generates a gateway executable function stub and pushes it to the first gateway and the second gateway. S5, the client application sends a service call request to the service gateway. The service gateway parses the Uniform Resource Identifier in the request, determines the target service type and the target card reader identifier. Based on the session binding relationship maintained by the front-end integration server, the service gateway selects the first gateway or the second gateway as the current service gateway, encapsulates the service call request into a gateway protocol message and forwards it to the selected gateway and sends it to the target card reader through a bidirectional communication link. S6. After the card reader executes the instruction, it generates the execution result. The card reader determines the current reachability status of the first gateway and the second gateway based on the heartbeat sequence number recorded in the local gateway routing table, selects the gateway with the better reachability status as the return gateway, and encapsulates the execution result into a response message and sends it to the return gateway.

2. The method according to claim 1, characterized in that, The dynamic configuration tree is updated in the following ways: The front-end integration server maintains the first transaction log corresponding to the first gateway and the second transaction log corresponding to the second gateway. The first transaction log records the response timestamp and response content summary of each topology probe of the first gateway, and the second transaction log records the response timestamp and response content summary of each topology probe of the second gateway. The front-end integration server inputs the first transaction log and the second transaction log into the change detector, and the change detector calculates the first gateway state change entropy value and the second gateway state change entropy value. When the entropy value of the first gateway's status change exceeds the first threshold, the front-end integration server marks the list of mounted card readers of the first gateway in the dynamic configuration tree as pending refresh. When the entropy value of the second gateway's status change exceeds the second threshold, the front-end integration server will mark the list of mounted card readers of the second gateway in the dynamic configuration tree as pending refresh. The front-end integration server recalculates the connection priority score between the card reader and the first and second gateways based on the marking results.

3. The method according to claim 1, characterized in that, The specific implementation method for the card reader to announce its own device identifier and supported service types is as follows: The card reader's security coprocessor generates a pair of session keys, uses these session keys to calculate the message authentication code for the announcement message, and appends the message authentication code to the end of the announcement message; The card reader sends an announcement message to the User Datagram Protocol multicast group via the physical layer broadcast address; the front-end integration server joins the multicast group, receives the announcement message, and uses the pre-set root certificate to verify the validity of the card reader's digital certificate. After successful verification, it extracts the device identifier and service type from the announcement message. The front-end integration server queries the historical access records associated with the device identifier in the dynamic configuration tree. If the average response latency of the first gateway in the historical access records is less than the average response latency of the second gateway, then the first gateway is assigned a higher connection priority score. If the average response latency of the second gateway is less than that of the first gateway, then the second gateway is assigned a higher connection priority score. The front-end integration server will send a configuration response message containing the Internet Protocol address, port number, and connection timeout parameters of the first gateway and the Internet Protocol address, port number, and connection timeout parameters of the second gateway to the media access control address of the card reader via unicast.

4. The method according to claim 1, characterized in that, The process by which the card reader maintains the two gateway routing tables includes: The embedded processor of the card reader creates a first gateway routing table and a second gateway routing table. The first gateway routing table includes a first gateway identifier field, a first sending sequence number field, a first receiving sequence number field, a first retransmission timer field, and a first message buffer queue pointer. The second gateway routing table includes a second gateway identifier field, a second sending sequence number field, a second receiving sequence number field, a second retransmission timer field, and a second message buffer queue pointer. When sending a registration request to the first gateway, the first sending sequence number field is assigned the current system tick count value, and a copy of the registration request message is stored in the first message cache queue; After receiving the registration response from the first gateway, the confirmation sequence number in the response is extracted and compared with the first sent sequence number. If they match, the corresponding copy of the registration request message in the first message buffer queue is cleared. When sending a registration request to the second gateway, the second sending sequence number field is assigned the current system tick count value, and a copy of the registration request message is stored in the second message cache queue; After receiving the registration response from the second gateway, extract the confirmation sequence number from the response and compare it with the second sending sequence number. If they match, clear the corresponding registration request message copy in the second message buffer queue. Check the first retransmission timer and the second retransmission timer. If the first retransmission timer expires and the first message buffer queue is not empty, retransmit the messages in the first message buffer queue. If the second retransmission timer times out and the second message buffer queue is not empty, then the messages in the second message buffer queue will be retransmitted.

5. The method according to claim 1, characterized in that, The methods for generating gateway executable function stubs include: The service gateway loads the card reader service description file, which is written in an interface definition language and describes the input parameter types, output parameter types, and calling constraints of each functional service supported by the card reader. The service gateway's interface compiler performs lexical analysis, syntax analysis, and semantic analysis on the service description file to generate an abstract syntax tree; The interface compiler traverses the abstract syntax tree, generating a first placeholder function conforming to the first gateway communication protocol for each functional service and a second placeholder function conforming to the second gateway communication protocol for each functional service; The first placeholder function contains serialization logic that converts a Hypertext Transfer Protocol (HTTP) request into a message format for the first gateway, and the second placeholder function contains serialization logic that converts an HTTP request into a message format for the second gateway. The service gateway compiles the first placeholder function and the second placeholder function into the first gateway executable code fragment and the second gateway executable code fragment, respectively. It then installs the first gateway executable code fragment into the plugin container of the first gateway and the second gateway executable code fragment into the plugin container of the second gateway through the gateway management interface.

6. The method according to claim 1, characterized in that, The process of a service gateway encapsulating gateway protocol messages includes: The service gateway extracts the body content from the Hypertext Transfer Protocol request sent by the client application and parses the body content into a set of key-value pairs; The service gateway queries the session binding relationship table to obtain the card reader identifier currently bound to the client application and the current service gateway identifier; If the current service gateway identifier points to the first gateway, the service gateway calls the protocol adapter corresponding to the first gateway. The protocol adapter encodes the key-value pair set into a binary payload according to the protocol specification of the first gateway, and adds a reader identifier field and a call sequence number field to the header of the binary payload. If the current service gateway identifier points to the second gateway, the service gateway calls the protocol adapter corresponding to the second gateway. The protocol adapter encodes the key-value pair set into a binary payload according to the protocol specification of the second gateway, and adds a reader identifier field and a call sequence number field to the header of the binary payload. The service gateway sends the encapsulated binary payload to the first or second gateway via the Transmission Control Protocol (TCP). After receiving the binary payload, the first or second gateway looks up the locally maintained reader communication socket based on the reader identifier field, removes the header from the binary payload, and sends it to the target reader through the communication socket.

7. The method according to claim 1, characterized in that, The specific logic for the card reader to select and return to the gateway is as follows: The embedded processor of the card reader reads the first receive sequence number field from the first gateway routing table and the second receive sequence number field from the second gateway routing table; The embedded processor compares the value of the first received sequence number field with the sequence number of the most recent message received from the first gateway, and calculates the absolute value of the first sequence number deviation; The embedded processor compares the value of the second received sequence number field with the sequence number of the most recent message received from the second gateway and calculates the absolute value of the second sequence number deviation. If the absolute value of the first sequence number deviation is less than the absolute value of the second sequence number deviation, the embedded processor determines that the first gateway is the gateway with a better reachable state. If the absolute value of the second sequence number deviation is less than the absolute value of the first sequence number deviation, the embedded processor determines that the second gateway is the gateway with a better reachable state. If the absolute value of the first serial number deviation is equal to the absolute value of the second serial number deviation, the embedded processor further compares the first signal strength indication value corresponding to the first gateway with the second signal strength indication value corresponding to the second gateway, and selects the gateway with the larger signal strength indication value as the return gateway. The card reader encapsulates the execution result into a response message and sends the response message to the selected return gateway.

8. The method according to claim 1, characterized in that, It also includes service migration steps: The front-end integration server monitors the load metrics of the first gateway and the second gateway, including CPU utilization, memory utilization, and number of connections. The front-end integration server presets a first load limit threshold and a second load limit threshold. When the CPU utilization of the first gateway exceeds the first load limit threshold or the number of connections exceeds the second load limit threshold, the front-end integration server triggers a service migration process. The front-end integration server queries the list of card readers mounted under the first gateway in the dynamic configuration tree, and calculates the migration benefit value for each card reader in the list. The migration benefit value is equal to the connection priority score between the card reader and the second gateway minus the connection priority score between the card reader and the first gateway. The front-end integration server selects the card reader with the highest migration benefit value as the card reader to be migrated. The front-end integration server sends a migration instruction to the card reader to be migrated. The migration instruction includes the updated connection parameters of the second gateway. After the card reader receives the migration instruction, it pauses sending new service call requests through the first gateway, resends the unacknowledged messages in the current first message buffer queue through the second gateway, initiates a second registration request to the second gateway, and resumes service calls after completing the registration. The front-end integration server updates the mounted gateway identifier of the card reader in the dynamic configuration tree to the second gateway identifier.

9. The method according to claim 1, characterized in that, It also includes offline caching steps: The reader's embedded processor allocates a circular buffer, which consists of multiple fixed-size storage units, each containing a valid flag bit and a timestamp field; When the card reader disconnects from both the first and second gateways simultaneously, the embedded processor writes the execution result and the corresponding timestamp into the current storage unit of the circular buffer, and sets the valid flag of that storage unit to the valid state. The embedded processor continuously monitors the connection status with the first and second gateways. When it detects that a connection has been re-established with either gateway, the embedded processor traverses the circular buffer and reads all memory cells where the valid flag bits are valid. The embedded processor encapsulates the execution results in the storage unit into retransmission messages in the order of the timestamp fields, and sends the retransmission messages to the gateway through the newly established connection. After receiving the retransmission message, the gateway converts the execution result into a Hypertext Transfer Protocol response and sends it back to the client application through the service gateway. After receiving the confirmation response from the gateway, the embedded processor sets the valid flag of the corresponding storage unit to an invalid state and releases the storage unit.

10. The method according to claim 1, characterized in that, It also includes the configuration synchronization step: The front-end integration server maintains a configuration version vector, which includes the configuration version number of the first gateway and the configuration version number of the second gateway. The front-end integration server pushes the first configuration subset related to the first gateway in the dynamic configuration tree to the first gateway, and at the same time increments the configuration version number of the first gateway by one; The front-end integration server pushes the second configuration subset related to the second gateway in the dynamic configuration tree to the second gateway, and increments the configuration version number of the second gateway by one. After receiving the first configuration subset, the first gateway compares the local configuration version number with the first gateway configuration version number. If the local configuration version number is smaller, the local configuration is updated with the first configuration subset, and the local configuration version number is updated to the first gateway configuration version number. After receiving the second configuration subset, the second gateway compares the local configuration version number with the second gateway configuration version number. If the local configuration version number is too low, the local configuration is updated with the second configuration subset, and the local configuration version number is updated to the second gateway configuration version number. The first and second gateways broadcast configuration change notifications to the connected card readers. After receiving the configuration change notification, the card reader requests incremental configuration data from the corresponding gateway and updates its local function service mapping table based on the incremental configuration data.

Images