Unified management system and method of virtual controller

Abstract

The invention discloses a unified management system and method for a virtual controller, and the system comprises a controller registration module which is used for initializing a controller registration array, checking whether the number of network IO registration reaches an upper limit or not, traversing the controller registration array, searching vacancies, and recording new instance information; the instance mapping module is used for mapping the successfully registered controller indexes into a controller information array and updating the registration number; the multi-thread security module is used for realizing concurrent security access in a registration process through a mutual exclusion lock; and the communication management module is used for creating a read management module, a write management module and an alarm management module, processing different types of data and carrying out heartbeat monitoring and data forwarding through a port. The technical problems that when a plurality of virtual controllers work cooperatively, control tasks of the virtual controllers are difficult to coordinate efficiently, so that the system performance is reduced, and even control conflicts or data loss may occur are solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of virtual controller management in industrial control systems and relates to a unified management system and method for virtual controllers. Background Art

[0002] With the rapid development of modern industrial automation, distributed control systems (DCS) have become an indispensable core technology in fields such as power, chemical engineering, and metallurgy. Traditional DCS systems, with their high reliability and stability, play a vital role in industrial production. However, as industrial applications continue to expand and deepen, the limitations of traditional DCS systems are becoming increasingly prominent.

[0003] Traditional DCS systems rely heavily on specific, independent hardware devices, lacking flexibility and scalability. This hardware-bound design makes it difficult to meet the requirements of low cost, minimal space, and easy maintenance for small projects or those requiring rapid deployment. Furthermore, the aging and upgrading of hardware devices also complicates ongoing maintenance and increases costs.

[0004] To overcome these limitations of traditional DCS systems, virtualization technology has been gradually introduced into control system design. Through virtualization, control functions can be separated from the controller hardware, enabling flexible management of control logic and computational tasks. This virtualization-based controller design not only improves system flexibility and scalability but also enhances fault tolerance, enabling rapid recovery from hardware failures and ensuring production continuity.

[0005] However, as production control scale becomes increasingly complex, virtualized controller management issues are becoming increasingly prominent. The current market lacks an effective method for unified management of virtual controllers. This makes it difficult to efficiently coordinate control tasks when multiple virtual controllers work together, resulting in reduced system performance and even potential control conflicts or data loss. Summary of the Invention

[0006] The purpose of the present invention is to solve the technical problem in the prior art that when multiple virtual controllers work together, it is difficult to efficiently coordinate their control tasks, resulting in system performance degradation and even possible control conflicts or data loss, and to provide a unified management system and method for virtual controllers.

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

[0008] The present invention discloses a unified management system for virtual controllers, comprising the following steps:

[0009] The controller registration module is used to initialize the controller registration array, check whether the number of network IO registrations has reached the upper limit, traverse the controller registration array to find empty slots and record new instance information;

[0010] The instance mapping module maps the successfully registered controller index to the controller information array and updates the registration quantity;

[0011] Multi-threaded security module, which implements concurrent security access during the registration process through mutex locks;

[0012] The communication management module creates read management, write management and alarm management modules, processes different types of data and performs heartbeat monitoring and data forwarding through ports.

[0013] Furthermore, the heartbeat monitoring includes:

[0014] The heartbeat sending thread sends heartbeat synchronization messages regularly to update the status of the receiving device;

[0015] The heartbeat receiving thread receives and parses the heartbeat message of the VDPU and updates the connection status;

[0016] The heartbeat synchronization message is encapsulated into a heartbeat forwarding message and forwarded to the target device.

[0017] Furthermore, the heartbeat sending thread sends heartbeat synchronization messages regularly, specifically:

[0018] Create a heartbeat packet heartBeatPacket, wherein the heartbeat packet heartBeatPacket is used to encapsulate a heartbeat synchronization message;

[0019] Use the remote address setting function remoteAddr.set() to set the destination address and port of the heartbeat synchronization message;

[0020] The network heartbeat socket sending function ml_NetHBSndSocket.send() function sends the heartbeat forwarding message to the destination address through the UDP socket;

[0021] If the sending fails, the error is recorded and the sleep function usleep() is called to enter the sleep state, and the next heartbeat forwarding message is sent after the preset time;

[0022] For errors such as network unreachable (ECONNREFUSED) or host unreachable (EHOSTUNREACH), the system records the error log instead of actively disconnecting.

[0023] Furthermore, the heartbeat receiving thread receives and parses the heartbeat message of the VDPU, specifically:

[0024] Monitor the socket's readable status through the select() function, and the timeout is set by ACE_Time_Value;

[0025] Call recv() to receive data and verify the source address identifier srcDpuNo, and discard illegal data packets;

[0026] Write the legal data packet into the receive buffer. If the write fails, sleep and try again.

[0027] Furthermore, the data forwarding includes:

[0028] Receive data requests from the host computer and parse the source address identifier srcDpuNo to verify the legitimacy of the data;

[0029] Parse the legal data, extract the source IP and port, and store the parsed data in the receiving buffer;

[0030] Read the data packet from the receive buffer, copy the data packet from the receive buffer to the temporary buffer, and extract the IP address and port number of the target VDPU;

[0031] Send data packets to the target VDPU via UDP sockets. If the sending fails, an error is logged but the UDP connection is not closed.

[0032] Receive and parse VDPU response data, and transmit the processing results back to the host computer.

[0033] Furthermore, the data request from the host computer is received and the source address identifier srcDpuNo is parsed to verify the legitimacy of the data, specifically:

[0034] The host computer sends instructions through the network IO socket ml_NetIOSocket and stores the data in the send buffer;

[0035] Wait for the instruction sent by the host computer through the monitoring function select(), receive the instruction through the receiving function recv(), and store it in the packet field of the network receiving packet pRcvNetPack;

[0036] The source address identifier srcDpuNo of the packet header is used to determine whether the packet belongs to the current control domain.

[0037] Furthermore, the data packet is read from the receiving buffer, the data packet is copied from the receiving buffer to the temporary buffer, and the IP address and port number of the target VDPU are extracted, specifically:

[0038] Read the current data packet from the receive buffer mp_NetIOGetBuf and return a pointer to the readable data in the current buffer. At the same time, update the data packet size and read result status.

[0039] When the read is successful, the data is copied to a temporary buffer and the IP address and port number of the target VDPU are extracted from the data packet.

[0040] Furthermore, the data packet is sent to the target VDPU via the UDP socket, and an error is recorded but the UDP connection is not closed when the sending fails; specifically:

[0041] Set the target address to remoteAddr through the set() function of the ACE_INET_Addr class;

[0042] Use the send() function of the ACE_SOCK_Dgram class to send various types of data packets to the target VDPU via UDP;

[0043] If the sending fails, an error is logged without disconnecting the UDP connection.

[0044] Furthermore, the VDPU response data is received and analyzed, and the processing results are transmitted back to the host computer, specifically:

[0045] Use the select() function to monitor whether there is readable data in the IO receiving socket ml_NetIORcvSocket;

[0046] If there is data to read in the socket, the program executes recv() to read the data and store it in the receive buffer recvBuf. If there is no data to read, it enters the waiting state until the timeout or data arrives.

[0047] By encapsulating the received data packet and converting it into a message structure that only carries the necessary device status information, the source address identifier srcDpuNo is extracted to check whether the data packet comes from the local VDPU;

[0048] Write the local VDPU response data into the receiving buffer. If the write fails, wait for a preset time and try again.

[0049] Send the VDPU response data in the receiving buffer back to the host computer.

[0050] A second aspect of the present invention provides a unified management method for virtual controllers, comprising:

[0051] Initialize the controller registration array, check whether the number of network IO registrations has reached the upper limit, traverse the controller registration array to find an empty space and record the new instance information;

[0052] Map the successfully registered controller index to the controller information array and update the number of registrations; implement concurrent secure access during the registration process through a mutex lock;

[0053] Create read management, write management, and alarm management modules to process different types of data and perform heartbeat monitoring and data forwarding through ports.

[0054] Compared with the prior art, the present invention has the following beneficial effects:

[0055] The present invention discloses a unified controller management system, which implements dynamic array initialization and vacancy detection through the controller registration module, ensuring that the system issues a timely warning when the number of registrations reaches the upper limit, avoiding overflow risks. New instance information is automatically recorded and mapped to the controller information array, significantly improving registration efficiency and accuracy, and reducing manual intervention costs. The multi-threaded security module adopts a mutual exclusion lock mechanism to ensure concurrent access security during the registration process, avoid data competition and resource conflicts, and ensure the stability and reliability of the system in high-concurrency scenarios. At the same time, a dual-thread heartbeat mechanism is set up to generate heartbeat synchronization messages at regular intervals, accurately deliver them to the target device through the UDP socket, support error logging and automatic retry mechanisms, and ensure that connection stability is maintained in the event of network anomalies (such as ECONNREFUSED, EHOSTUNREACH). Based on the select() function, the socket status is efficiently monitored, the VDPU heartbeat message is parsed in real time and the connection status is updated. Illegal data packets are automatically discarded, and legal data packets are written to the buffer to ensure data integrity. The heartbeat synchronization message is encapsulated as a forwarding message and accurately delivered to the target device, forming a closed-loop state synchronization mechanism, effectively reducing the risk of device offline and improving the system's fault tolerance. The system also boasts efficient data forwarding capabilities. It verifies data legitimacy using the source address identifier (srcDpuNo), ensuring only instructions within the current control domain are processed. Valid data is extracted from the source IP address and port and stored in the receive buffer, enabling precise filtering and storage of data streams. Data is read from the receive buffer and copied to a temporary buffer, where the target VDPU address and port are extracted to mitigate data tampering risks. Error logs are logged when a transmission fails, but the connection remains open, ensuring continuous data transmission. The select() function monitors I / O sockets, parses VDPU responses, and converts them into standardized message structures, carrying only essential device status information, improving host computer processing efficiency. The communication management module decouples read, write, and alarm management functions, implementing heartbeat monitoring and data forwarding through independent ports for ease of expansion and maintenance. Error logging and automatic retry mechanisms are designed for network anomalies (such as ECONNREFUSED and EHOSTUNREACH) to ensure continuous system operation even in the face of non-fatal errors, reducing operational costs. Asynchronous processing of the heartbeat monitoring and data forwarding processes ensures real-time responsiveness to device status and data requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0057] Figure 1 This is a data interaction flow chart of the unified management system of the virtual controller of the present invention;

[0058] Figure 2 This is a schematic diagram of the heartbeat packet reception of the unified management system of the virtual controller of the present invention;

[0059] Figure 3 This is a flow chart of the heartbeat packet receiving process of the unified management system of the virtual controller of the present invention;

[0060] Figure 4 A flow chart showing the heartbeat packet transmission of the unified management system of the virtual controller of the present invention;

[0061] Figure 5 This is a block diagram of the unified management system of the virtual controller of the present invention. DETAILED DESCRIPTION

[0062] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Generally, the components of the embodiments of the present invention described and marked in the drawings herein can be arranged and designed in various different configurations.

[0063] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention as claimed, but rather merely represents selected embodiments of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without creative effort are intended to fall within the scope of protection of the present invention.

[0064] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings.

[0065] The present invention is described in further detail below with reference to the accompanying drawings:

[0066] See also Figure 5One embodiment of the present invention discloses a unified management system VDPUManager for virtual controllers. The virtual controller management system VDPUManager is used to manage the virtual controller kernel program VDPU; it includes:

[0067] The controller registration module is used to initialize the controller registration array, check whether the number of network IO registrations has reached the upper limit, traverse the controller registration array to find an empty space and record the new instance information; the virtual controller management system will first initialize the controller registration array, check the number of network IO registrations g_NetIORegNum, and report an error when the number reaches the upper limit; traverse the array g_NetIORegArray that stores network IO registration information, find the first empty space with an occupied value of 0, and record the new instance information (controller number, program number, type and function block offset, etc.).

[0068] The instance mapping module maps the successfully registered controller index to the controller information array and updates the registration quantity. After successful registration, the controller index dpuIndex is mapped to a specific position in the g_NetDpuInfo array that records the controller information, and the registration quantity regNum is increased by one so that VDPUManager can track the specific registration status of each controller instance. At the same time, the mutex g_NetIOMutex is used to implement secure multi-threaded concurrent access to avoid data competition during the registration process.

[0069] Multi-threaded safety module, which implements concurrent safety access during the registration process through mutex locks.

[0070] The communication management module creates read management, write management, and alarm management modules to handle different types of data and perform heartbeat monitoring and data forwarding through ports. VDPUManager uses the component management function createMngComponent() to establish various management modules (such as read management VdpuReadMange, write management VdpuWriteMange, and alarm management VdpuAlarmMange). These management modules handle different types of data and implement heartbeat monitoring and data forwarding through fixed ports.

[0071] Users can create new VDPU instances through a graphical interface and configure communication ports, network IP, redundancy mechanisms, etc. as needed. All instances are automatically registered to VDPUManager for centralized management.

[0072] This embodiment discloses a unified management system for virtual controllers, wherein heartbeat monitoring includes the following steps:

[0073] The virtual controller management system monitors the heartbeat of the controller in real time; Figure 1 and Figure 2 As shown in the figure, the active and standby VDPUs periodically send heartbeat messages to each other, which are forwarded by the VDPUManager to monitor the status of each other in real time, ensuring that they can handle and report errors in a timely manner when heartbeat loss occurs.

[0074] Heartbeat information between VDPUs must be encapsulated as UDP packets, unpacked and re-encapsulated by the VDPUManager, and ultimately forwarded. This invention employs a dual-message design, separating heartbeat messages into a heartbeat synchronization message (sync_heartbeat_packet) and a heartbeat forwarding message (hb_inter_process_packet). The heartbeat synchronization message focuses on the internal state details of the primary and standby servers, while the heartbeat forwarding message is used to adapt to the global monitoring needs of the compute engine manager. The key fields of these two message types are shown in the following table.

[0075] Table 1 Heartbeat synchronization message

[0076]

[0077] Table 2 Heartbeat forwarding message

[0078]

[0079] Heartbeat synchronization messages contain key information such as master and standby machine failures, status, and resource usage, ensuring real-time synchronization between the master and standby machines and triggering failover in a timely manner when any anomaly is detected. Heartbeat forwarding messages use a lightweight design, containing only the target executor number and overall redundancy and communication status, reducing the burden of direct communication.

[0080] The VDPUManager maintains independent heartbeat monitoring with each VDPU, periodically (default 20ms) sending a heartbeat synchronization message (sync_heartbeat_packet) to the VDPUManager. The VDPUManager listens for these messages, encapsulates them into a heartbeat forwarding message (hb_inter_process_packet), and forwards them to the peer. The peer parses the forwarded message and updates its own status. If the peer heartbeat is lost, the platform will automatically generate an alarm and log the abnormal status.

[0081] VDPUManager's heartbeat forwarding is mainly implemented through the following three key modules:

[0082] Heartbeat sending thread (VdpuNetHBManage_Send): responsible for sending heartbeat synchronization messages regularly;

[0083] Heartbeat receiving thread (VdpuNetHBManage_Recv): responsible for receiving heartbeat synchronization messages and updating the connection status;

[0084] Network data packet (transfer_net_packet): responsible for encapsulating the heartbeat synchronization message and converting it into a heartbeat forwarding message that only carries the necessary device status information.

[0085] The specific process is as follows:

[0086] S101, initialize network connection:

[0087] First, use the initialization socket function initSocket() to establish a UDP network connection, and then configure the UDP network connection parameters, that is, set the socket options, such as non-blocking mode (ACE_NONBLOCK), receive and send buffer size (SO_RCVBUF, SO_SNDBUF), address reuse (SO_REUSEADDR), broadcast mode (SO_BROADCAST), etc., to prepare for the subsequent sending and receiving of UDP heartbeat packets.

[0088] S102, receiving heartbeat synchronization message:

[0089] See also Figure 3 , VDPUManager monitors the heartbeat messages from the remote device through the heartbeat receiving thread VdpuNetHBManage_Recv class and updates the connection status based on the received heartbeat data.

[0090] First, start an infinite loop of heartbeat receiving thread, and use the heartbeat monitoring function select() function to monitor in real time whether there is data to read in the heartbeat receiving socket ml_NetHBRevSocket, so as to judge whether a new heartbeat synchronization message sync_heartbeat_packet is received, and use ACE_Time_Value to configure the timeout time to limit the waiting time of the heartbeat monitoring function select() call to ensure that it will not be blocked for a long time; when the socket is readable, call the receiving function recv() function to receive data from the heartbeat receiving socket ml_NetHBRevSocket and store it in the packet field of the network receiving packet pRcvNetPack; if an error occurs when receiving data, the recv() function will return Returns a negative number, the receiving thread will record the error number errno and skip this loop, and enter the next receiving loop through continue; after successfully receiving the heartbeat synchronization message sync_heartbeat_packet, determine whether the data packet belongs to the local domain based on the source address identifier srcDpuNo in the message header, if not, ignore it; write the message type, length, IP address, port number and other information of the received heartbeat synchronization message into the network receiving package pRcvNetPack; write the received data into the receiving buffer through the data writing function writeData. If the write fails, wait for a short time through the sleep function usleep(VDPUMNG_WAITTIME_NODATA) to avoid repeated write operations and consume resources, and then try to write again.

[0091] S102, sending a heartbeat forwarding message:

[0092] See also Figure 4 ,VDPUManager regularly checks and sends heartbeat messages through the heartbeat sending thread VdpuNetHBManage_Send, to ensure that the system continuously updates the status of the other device.

[0093] First, create a heartbeat packet heartBeatPacket to encapsulate the heartbeat synchronization message from the executor, and set its type to the network heartbeat type NET_BUF_TYPE_NETHB to identify the message as a heartbeat forwarding message; then use the remote address setting function remoteAddr.set() to set the destination address and port of the message; the network heartbeat socket sending function ml_NetHBSndSocket.send() function sends the heartbeat forwarding message to the target device through the UDP socket; if the sending fails (such as network failure, device is offline), the error is recorded, and the sleep function usleep() is called to put the thread into sleep state, and the next heartbeat forwarding message is sent after waiting for a while. For errors such as network unreachable ECONNREFUSED or host unreachable EHOSTUNREACH, only the error log is recorded without actively disconnecting.

[0094] The VDPUManager not only manages VDPU instances but also serves as a data forwarding hub. The host computer communicates with the VDPU through the VDPUManager, passing commands, control tasks, and data to the VDPU and receiving status information from the VDPU.

[0095] The specific process is as follows:

[0096] S201, receiving data request

[0097] The host computer sends instructions through the network IO socket ml_NetIOSocket and stores the data in the send buffer; the IO receiving thread VdpuNetIOManage_Recv is responsible for monitoring the instructions or task requests of the host computer, waiting for the instructions sent by the host computer through the monitoring function select(), receiving the instruction through the receiving function recv(), and storing it in the packet field of the network receiving packet pRcvNetPack; through the packet source address identifier srcDpuNo in the message header, it is determined whether the packet belongs to the current control domain, if not, the packet is discarded; once the data is confirmed to be legal, the source IP, port number and other information in the packet are parsed out and filled into the network receiving packet pRcvNetPack, where type is used to distinguish the data type, length is used to record the packet length, and clientAddr and clientPort are used to record the source IP and port number; after the parsing is completed, the data is written to the receive buffer for subsequent sending to the corresponding VDPU instance.

[0098] S202, data forwarded to VDPU

[0099] VDPUManager reads the current data packet from the receive buffer mp_NetIOGetBuf through the readable data address acquisition function getCurReadPos(), and returns a pointer to the readable data in the current buffer. At the same time, it updates size and result to obtain the data packet size and read result status. When result indicates that the data is valid NET_BUF_RESULT_OK, the memcpy() function is used to copy the data to the temporary buffer packbuff. The content in packbuff is the complete data packet sent to the VDPU, including the data content and the message header information required for transmission. Then, the target VDP is extracted from the data packet. The IP address clientAddr and port number clientPort of U are set, and the target address is set to remoteAddr through the set() function of the ACE_INET_Addr class to prepare for the subsequent UDP sending process; the send() function of the ACE_SOCK_Dgram class is used to send various types of data packets to the target VDPU through UDP. If the sending fails, the function returns -1, the system records the error code and handles related errors (such as network failure ECONNREFUSED or host unreachable EHOSTUNREACH), but does not close the UDP connection, ensuring that even if the sending fails, the system can still continue to process other data.

[0100] S203, receiving VDPU response

[0101] The run() function keeps looping, waiting for the reception of data packets, and monitors whether there is readable data in the IO receiving socket ml_NetIORcvSocket through the select() function. If there is readable data in the socket, the program executes recv() to read the data and store it in the receive buffer recvBuf. If there is no readable data, the program will enter a waiting state until it times out or data arrives. The received data packet is encapsulated and converted into a message structure that only carries the necessary device status information. The source address identifier srcDpuNo is extracted to check whether the data packet comes from the local VDPU. If the data is legal, the type, length, address and port information of the received data packet are filled into pRcvNetPack, and the data packet is written to the receive buffer mp_NetIOGetBuf. If the write fails, wait for a while and try again.

[0102] S204, transmit back to the host computer

[0103] Finally, VDPUManager will transmit the result of VDPU response back to the host computer through the receiving buffer so that the host computer can obtain the processing result in time and update the task status.

[0104] This embodiment ensures that data can be sent and received synchronously by writing data into and reading data from the buffer and combining multi-threading, thereby improving efficiency and avoiding data loss or conflict.

[0105] A custom buffer class, VdpuListBuf, is used to store and manage data packets, ensuring that each thread can safely and efficiently read and store data. When sending and receiving data, the data is first stored in the buffer and then read and processed from the buffer, providing temporary storage and synchronization.

[0106] The use of the buffer mainly involves the following key operations:

[0107] 1) Readability judgment function isReadable(): determines whether there is data to be read in the buffer, which is used to detect whether there are data packets to be sent in the send buffer and whether there is new data to be processed in the receive buffer.

[0108] 2) Readable data address acquisition function getCurReadPos(): Gets the current readable data position from the buffer for reading and sending data packets.

[0109] 3) Read completion function finishReadOut(): marks the read data packet as processed and releases the buffer space for subsequent data writing.

[0110] 4) Write data function writeData(): writes the received network data packet into the buffer to ensure subsequent orderly processing.

[0111] The sending buffer (such as the network heartbeat sending buffer mp_NetHBAckBuf, the network IO sending buffer mp_NetIOAckBuf, etc.) is used to manage the content of the sending queue. The sending thread VdpuNetHBManage_Send::run() reads data from the buffer each time and sends it out.

[0112] Specific data sending process:

[0113] 1) Scan the send buffer: Use isReadable() to check whether there is data to be sent. If there is data in the buffer, continue processing.

[0114] 2) Read data: Use getCurReadPos(&size,&result) to get the currently readable packet from the buffer and copy it to the temporary buffer packbuff for sending.

[0115] 3) Send data: Call the heartbeat sending function ml_NetHBSndSocket.send() to send the data to the specified remoteAddr remote address through the UDP socket.

[0116] 4) Result processing: If the sending fails, process the error code (such as ECONNREFUSED or EHOSTUNREACH), but do not close the network connection. If successful, continue to send the next data packet.

[0117] 5) Mark completion: Call finishReadOut() to mark the data packet as successfully sent and release the buffer space for subsequent data use.

[0118] Through the above process, it is ensured that the data can be cached in the queue before being sent, and then sent one by one, ensuring the efficiency and stability of the sending thread.

[0119] The receiving buffer (such as the network heartbeat receiving buffer mp_NetHBGetBuf and the network IO receiving buffer mp_NetIOGetBuf) is used to manage the messages received from the network. The receiving thread VdpuNetHBManage_Recv::run() continuously monitors the network socket and continuously writes new data to the buffer.

[0120] Specific data receiving process:

[0121] 1) Waiting for data: Monitor the receiving socket through select() to see if there is data to read, avoiding busy waiting (continuously checking the socket status in a loop). When there is data to read, call the recv() function to receive the data packet.

[0122] 2) Data parsing: Parse the received data packet information (such as type, length, client IP, port number, etc.) and encapsulate it into a network data packet transfer_net_packet.

[0123] 3) Write to the buffer: Call the writeData() function to write the parsed data packet to the receive buffer for processing by the upper-layer application.

[0124] 4) Error handling: If the buffer write fails, the thread will call the usleep() function to wait briefly and then retry to ensure that the data can eventually be successfully stored in the buffer.

[0125] Buffer synchronization control

[0126] Two threads handle the sending and receiving operations, respectively, and a buffer is used for reading and writing data. This prevents data loss even if the processing speeds of the sender and receiver differ. However, to avoid data contention, data status information is managed when reading and writing the buffer.

[0127] 1) Read-write mutual exclusion: When reading and writing the buffer, use a status flag (such as NET_BUF_RESULT_LOCKED_STATE) to ensure that only one operation can be performed at a time, preventing multiple threads from reading and writing the buffer at the same time, which may cause data contention or data inconsistency.

[0128] 2) Status check: For example, use isReadable() to determine whether there is data to read in the buffer, use finishReadOut() to mark the completion of data reading, and use the return value (such as NET_BUF_RESULT_OK, NET_BUF_RESULT_UNUSABLE, etc.) to determine whether the current buffer is available, ensuring that there is enough space in the buffer before writing data.

[0129] 3) Retry mechanism: During the receiving process, if the writeData operation fails, the usleep() method will be used to wait for a while, and then the write operation will be tried again to ensure that the data can be successfully stored in the buffer.

[0130] In this embodiment, after the VDPUManager establishes a socket connection with each VDPU instance, it encapsulates different types of messages to ensure that the VDPU can correctly distinguish messages of different protocols based on the type field. These message types include:

[0131] NET_BUF_TYPE_SYNCSERVER: data synchronization message.

[0132] NET_BUF_TYPE_READ: Read operation message.

[0133] NET_BUF_TYPE_WRITE: write operation message.

[0134] NET_BUF_TYPE_HB: Heartbeat packet, used to detect connection status.

[0135] VDPU will call the corresponding processing logic according to different type fields (such as read service dealReadServerPacket, write service dealWriteServerPacket, etc.).

[0136] After VDPUManager encapsulates the data, it sends the message to the VDPU's receiving socket through the send() function. The message content includes the following fields:

[0137] ·protocol: The protocol type of the current message.

[0138] ●type: used to distinguish the specific purpose of data.

[0139] ●length: packet length.

[0140] apiAddr and apiPort: mark the address and port of the sender, used to confirm the data source on the VDPU side.

[0141] The VDPUManager periodically sends NET_BUF_TYPE_HB heartbeat packets to maintain and detect the connection with the VDPU. The VDPU can also use these packets to confirm its communication status with the VDPUManager. For protocols that require a response (such as NET_BUF_TYPE_READ and NET_BUF_TYPE_WRITE), the VDPUManager waits for an ACK from the VDPU after sending the packet and then updates the locally cached data or operation status based on the ACK.

[0142] An embodiment of the present invention provides a unified management method for virtual controllers, including:

[0143] Initialize the controller registration array, check whether the number of network IO registrations has reached the upper limit, traverse the controller registration array to find an empty space and record the new instance information;

[0144] Map the successfully registered controller index to the controller information array and update the number of registrations; implement concurrent secure access during the registration process through a mutex lock;

[0145] Create read management, write management, and alarm management modules to process different types of data and perform heartbeat monitoring and data forwarding through ports.

[0146] The present invention proposes VdpuManager as a unified management framework, which can effectively and centrally manage the operating status of multiple VDPU instances, enable configuration, monitoring, and fault diagnosis of multiple VDPUs on a unified platform, and reduce the problem of increased management complexity caused by the increase in the number of controllers; through multiple management modules (such as VdpuReadManage, VdpuWriteManage, VdpuAlarmManage, etc.), independent management of different functions is achieved, ensuring the flexibility and scalability of virtual controller operation; in addition, the modular design is also conducive to subsequent expansion and maintenance. Different functions can be upgraded and modified independently without affecting the overall operation of the system.

[0147] In traditional one-way buffering mechanisms, data is sent immediately upon generation, with no backlog or buffer space. Network congestion can disrupt data flow, causing transmission delays or even interruptions. This can lead to unstable data transmission in high-concurrency scenarios. Due to limited buffering, packets can easily be lost in high-concurrency or network fluctuations, compromising data integrity and consistency. In cases of network congestion, unsent data is discarded, further increasing the risk of packet loss. This also makes the system difficult to scale, as each additional node increases data flow pressure and the risk of packet loss. In high-concurrency scenarios, the system cannot balance data flow across all transmission connections, leading to a sharp decline in performance. Its applicability is limited because data generation and transmission in a one-way queue are strictly sequential. If the data transmission rate cannot keep up with the data generation rate, the queue will quickly fill up, impacting the overall system transmission efficiency. Furthermore, due to the lack of a reverse feedback mechanism, the system cannot adjust the data transmission rate based on the receiving end's processing speed or network conditions to adapt to traffic changes. If the transmission rate exceeds the receiving end's processing capacity, the buffer can quickly fill up, resulting in packet loss or delays.

[0148] The VDPUManager of the present invention uses a two-way queue and buffer to manage data flow, which not only supports the orderly transmission of data, but also performs flow control during peak data transmission periods, effectively reducing the risk of packet loss and data congestion, and ensuring efficient and stable transmission performance under high concurrency conditions. Among them, the design of the two-way queue and buffer simultaneously supports the reception and caching of downlink data and uplink data (feedback data), which can achieve multi-level data synchronization, making the communication between VDPUs more anti-interference capable, and can still maintain the orderly transmission of data in poor network conditions, ensuring the stability of the system; supporting the system's two-way transmission and management data, it can adjust the transmission rate in real time and dynamically, reduce data pressure during peak periods, and balance concurrent data requests from multiple VDPU nodes. Therefore, VDPUManager is more suitable for application in large-scale expansion scenarios, and can support multiple VDPU nodes to process data requests simultaneously, with less impact on the system's concurrent performance.

[0149] In traditional single-protocol framework systems, all types of data packets are transmitted using a fixed protocol. The system protocol and architecture need to be redesigned to add new functions (such as adding new forwarding rules for specific types of data). It may also affect the overall communication logic of the system, which is not conducive to the subsequent functional expansion and maintenance testing of the system. In the single-protocol forwarding process, all data are treated as one category, and the system lacks the ability to distinguish priorities. When a large amount of status data, alarm information and heartbeat information are transmitted at the same time, high-priority data cannot be forwarded first, resulting in delays or loss of important information, which may cause system instability or even serious failures.

[0150] Multi-protocol forwarding uses different data protocols to distinguish and process various types of data packets (such as read and write instructions, heartbeat detection, synchronization data, alarm information, etc.). Each protocol has its own independent data structure and control flow. Therefore, VDPUManager only needs to add processing functions for the corresponding protocol to expand new functions. This modular design improves the maintainability of the system. Different types of data protocols can be flexibly added, deleted, and optimized in the future, reducing code coupling and development costs. At the same time, VDPUManager can process different data packets with corresponding priorities according to different protocol types (such as heartbeat, status synchronization, alarm, etc.). For example, heartbeat packets (NET_BUF_TYPE_HB) and alarm data can be set to the highest priority to ensure that they can still be transmitted first in network congestion or high-load environments, ensuring the real-time nature of important data and improving the stability and response efficiency of the system.

[0151] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A unified management system for virtual controllers, characterized in that: The following steps are involved: The controller registration module is used to initialize the controller registration array, check whether the number of network IO registrations has reached the upper limit, traverse the controller registration array to find empty slots and record new instance information; The instance mapping module maps the successfully registered controller index to the controller information array and updates the registration quantity; Multi-threaded security module, which implements concurrent security access during the registration process through mutex locks; The communication management module creates read management, write management and alarm management modules, processes different types of data and performs heartbeat monitoring and data forwarding through ports.

2. The unified management system of virtual controllers according to claim 1, characterized in that: The heartbeat monitoring includes: The heartbeat sending thread sends heartbeat synchronization messages regularly to update the status of the receiving device; The heartbeat receiving thread receives and parses the heartbeat message of the VDPU and updates the connection status; The heartbeat synchronization message is encapsulated into a heartbeat forwarding message and forwarded to the target device.

3. The unified management system of virtual controllers according to claim 2, characterized in that: The heartbeat sending thread sends heartbeat synchronization messages regularly, specifically: Create a heartbeat packet heartBeatPacket, wherein the heartbeat packet heartBeatPacket is used to encapsulate a heartbeat synchronization message; Use the remote address setting function remoteAddr.set() to set the destination address and port of the heartbeat synchronization message; The network heartbeat socket sending function ml_NetHBSndSocket.send() function sends the heartbeat forwarding message to the destination address through the UDP socket; If the sending fails, the error is recorded and the sleep function usleep() is called to enter the sleep state, and the next heartbeat forwarding message is sent after the preset time; For errors such as network unreachable (ECONNREFUSED) or host unreachable (EHOSTUNREACH), the system records the error log instead of actively disconnecting.

4. The unified management system of virtual controllers according to claim 2, characterized in that: The heartbeat receiving thread receives and parses the heartbeat message of the VDPU, specifically: Monitor the socket's readable status through the select() function, and the timeout is set by ACE_Time_Value; Call recv() to receive data and verify the source address identifier srcDpuNo, and discard illegal data packets; Write the legal data packet into the receive buffer. If the write fails, sleep and try again.

5. The unified management system of virtual controllers according to claim 1, characterized in that: The data forwarding includes: Receive data requests from the host computer and parse the source address identifier srcDpuNo to verify the legitimacy of the data; Parse the legal data, extract the source IP and port, and store the parsed data in the receiving buffer; Read the data packet from the receive buffer, copy the data packet from the receive buffer to the temporary buffer, and extract the IP address and port number of the target VDPU; Send data packets to the target VDPU via UDP sockets. If the sending fails, an error is logged but the UDP connection is not closed. Receive and parse VDPU response data, and transmit the processing results back to the host computer.

6. The unified management system of virtual controllers according to claim 5, characterized in that: The receiving computer receives the data request and parses the source address identifier srcDpuNo to verify the legitimacy of the data, specifically: The host computer sends instructions through the network IO socket ml_NetIOSocket and stores the data in the send buffer; Wait for the instruction sent by the host computer through the monitoring function select(), receive the instruction through the receiving function recv(), and store it in the packet field of the network receiving packet pRcvNetPack; The source address identifier srcDpuNo of the packet header is used to determine whether the packet belongs to the current control domain.

7. The unified management system of virtual controllers according to claim 5, characterized in that: The data packet is read from the receiving buffer, copied to a temporary buffer, and the IP address and port number of the target VDPU are extracted, specifically: Read the current data packet from the receive buffer mp_NetIOGetBuf and return a pointer to the readable data in the current buffer. At the same time, update the data packet size and read result status. When the read is successful, the data is copied to a temporary buffer and the IP address and port number of the target VDPU are extracted from the data packet.

8. The unified management system of virtual controllers according to claim 5, characterized in that: The data packet is sent to the target VDPU via a UDP socket. If the sending fails, an error is recorded but the UDP connection is not closed. Specifically: Set the target address to remoteAddr through the set() function of the ACE_INET_Addr class; Use the send() function of the ACE_SOCK_Dgram class to send various types of data packets to the target VDPU via UDP; If the sending fails, an error is logged without disconnecting the UDP connection.

9. The unified management system of virtual controllers according to claim 5, characterized in that: The receiving VDPU response data and parsing, and transmitting the processing results back to the host computer, specifically: Use the select() function to monitor whether there is readable data in the IO receiving socket ml_NetIORcvSocket; If there is data to read in the socket, the program executes recv() to read the data and store it in the receive buffer recvBuf. If there is no data to read, it enters the waiting state until the timeout or data arrives. By encapsulating the received data packet and converting it into a message structure that only carries the necessary device status information, the source address identifier srcDpuNo is extracted to check whether the data packet comes from the local VDPU; Write the local VDPU response data into the receiving buffer. If the write fails, wait for a preset time and try again. Send the VDPU response data in the receiving buffer back to the host computer.

10. A unified management method for virtual controllers, based on the unified management system for virtual controllers according to any one of claims 1 to 9, characterized in that: include: Initialize the controller registration array, check whether the number of network IO registrations has reached the upper limit, traverse the controller registration array to find an empty space and record the new instance information; Map the successfully registered controller index to the controller information array and update the registration quantity; Concurrent and secure access during registration is achieved through mutex locks; Create read management, write management, and alarm management modules to process different types of data and perform heartbeat monitoring and data forwarding through ports.

Images