An inter-nuclear communication system and power distribution terminal

Abstract

This invention relates to the field of heterogeneous multi-core power distribution terminal equipment technology, and discloses an inter-core communication system and power distribution terminal. The system includes a master core, slave cores, and physical memory. A shared memory region is set within the physical memory, configured not to participate in the dynamic memory management of the master and slave cores. The shared memory region is divided into a control instruction area, a telemetry data area, a bulk transfer area, and a management information area. The control instruction area adopts a ping-pong buffer structure, the telemetry data area adopts a lock-free ring buffer structure, the bulk transfer area adopts a mutex lock mechanism, and the management information area includes a buffer index pointer for indicating active buffers in the control instruction area, read and write pointers for the telemetry data area, and an atomic lock flag for indicating whether the lock in the bulk transfer area is held. This system can ensure low-latency execution of protection control commands of the power distribution terminal, while ensuring efficient transmission of telemetry data and files.

Description

Technical Field

[0001] This invention relates to the field of heterogeneous multi-core power distribution terminal equipment technology, specifically to an inter-core communication system and a power distribution terminal. Background Technology

[0002] With the deepening of the construction of new power systems, distribution networks are placing higher demands on the intelligence, interconnectivity, and autonomous controllability of terminal equipment. As the core sensing and control node of the distribution network, the distribution automation terminal undertakes key tasks such as telemetry, remote signaling, remote control, and fault protection. Its real-time performance and reliability directly affect the safe and stable operation of the distribution network. To meet the increasing demands for computing power and functional integration, modern distribution terminals generally adopt a heterogeneous multi-core processor architecture. A typical solution involves running a general-purpose operating system (such as Linux / Dianhong OS) on the application processor core (A core, such as the ARM Cortex-A series) to handle upper-layer applications such as communication protocol parsing, IoT platform integration, human-machine interaction, and intelligent analysis; and running a real-time operating system (RTOS) on the real-time processor core (R core, such as the RISC-V XuanTie E907) to handle highly latency-sensitive tasks such as protection control logic execution, analog / switching quantity acquisition, and rapid fault clearing.

[0003] In this heterogeneous multi-core architecture, efficient and reliable communication between the A core and the R core becomes a key technical issue for the normal operation of the system. Existing inter-core communication methods for heterogeneous multi-core devices include: (1) simple read / write method based on shared memory; (2) inter-core notification mechanism based on polling; (3) inter-core communication method based on simple interrupts; and (4) communication method based on message queues. However, among these four methods, shared memory suffers from competition between different business data, and the transmission latency of key instructions may not be guaranteed. Furthermore, the address mapping and cache attributes of heterogeneous processors lack a unified configuration mechanism, which poses a cache consistency risk. Polling has high latency and is prone to resource waste. Simple interrupts lack message semantic carrying capacity, cannot distinguish data priority and type, and are prone to interrupt storms that interfere with real-time tasks in high-frequency data scenarios. Message queue-based methods are difficult to overcome the limitations of different message queue implementation methods and API interfaces between different architectures, making direct interoperability difficult. They also lack a synchronization mechanism for heterogeneous cores and cannot be used across two independently running operating system kernels. Therefore, a new inter-core communication system suitable for power distribution terminals needs to be designed to overcome the above defects. Summary of the Invention

[0004] In order to overcome the shortcomings of the prior art, the purpose of this invention is to provide an inter-core communication system for power distribution terminals, which can avoid competition for the same channel for different types of data in power distribution terminals, and ensure the efficiency of telemetry data and file transmission while ensuring low latency of key instructions.

[0005] To solve the above problems, the technical solution adopted by the present invention is as follows: an inter-core communication system for a power distribution terminal, comprising a master core, a slave core, and physical memory, wherein the physical memory is electrically connected to both the master core and the slave core, and a shared memory region is provided within the physical memory. The shared memory region is configured not to participate in the dynamic memory management of the master core and the slave core, and the shared memory region is divided into a control instruction region, a telemetry data region, a bulk transmission region, and a management information region. The control instruction region is used for the transmission of high-priority short messages, the telemetry data region is used for the transmission of periodically collected data, the bulk transmission region is used for the transmission of low-real-time large data, and the management information region is used to store management metadata. The control instruction region adopts a ping-pong buffer structure, the telemetry data region adopts a lock-free ring buffer structure, the bulk transmission region adopts a mutex lock mechanism, and the management information region is provided with a buffer index pointer for marking the active buffer in the control instruction region, a read pointer and a write pointer for the telemetry data region, and an atomic lock flag for marking whether the lock in the bulk transmission region is held.

[0006] In the aforementioned inter-core communication system, a descriptor table with a preset format is set at the starting position of the shared memory region. The descriptor table stores the parameter information of each sub-region of the shared memory region and the checksum of the descriptor table in a structured manner.

[0007] In the aforementioned inter-core communication system, both the master core and the slave core are equipped with a message queue management module, an interrupt control module, and an interrupt response module. The management information area contains a message mailbox, which includes multiple message slots for storing pending message notifications. Each pending message notification includes a validity flag, message type encoding, priority identifier, target sub-region index, data offset, data length, sequence number, timestamp, and a verification field. After the sending core's message queue management module writes the data to be transmitted into the shared memory area, the sending core's... The interrupt control module writes the pending message notification corresponding to the data to be transmitted into the first free message slot in the message mailbox. After writing, it modifies the valid flag bit in the message slot to be valid and triggers the hardware interrupt of the receiver. After the hardware interrupt of the interrupt response module of the receiver is triggered, it scans the message mailbox in sequence and reads the pending message notification in the message slot where the valid flag bit is valid. It adds the metadata of the pending message notification to the local processing queue and clears and releases the valid flag bit of the read message slot.

[0008] In the aforementioned inter-core communication system, the interrupt control module of the master core includes a merge window timer or a merge window counter. The merge window timer is used to time the merge window, and the merge window counter is used to count the accumulated non-urgent transmission tasks. When the timer value of the merge window timer reaches a preset window threshold, or when the count value of the merge window counter reaches a preset cumulative threshold, the interrupt control module uniformly triggers a hardware interrupt to the slave core.

[0009] In the aforementioned inter-core communication system, the main core's message queue management module includes three priority message queues: an emergency queue, a normal queue, and a background queue. The priorities of the emergency queue, the normal queue, and the background queue decrease sequentially. The main core's message queue management module includes a message scheduler, which operates at a fixed scheduling cycle. The message scheduler checks the status of each queue in descending order of priority and retrieves the data at the head of the highest priority non-empty queue, writing it to the corresponding sub-area of ​​the shared memory region.

[0010] In the aforementioned inter-core communication system, the message queue management module further includes waiting counters corresponding to the ordinary queue and the background queue, respectively. If the ordinary queue or the background queue is not served in each scheduling cycle, the value of the corresponding waiting counter is incremented by 1. If the count value of the waiting counter reaches a preset starvation protection threshold, a data transmission of the ordinary queue or the background queue is forcibly inserted in the next scheduling cycle.

[0011] In the aforementioned inter-core communication system, the management information area is equipped with a master core hop counter and a slave core hop counter. The master core hop counter and the slave core hop counter are maintained by the master core and the slave core respectively with the same maintenance cycle. The master core and the slave core periodically read each other's heartbeat counters at a preset monitoring cycle. If the number of monitoring cycles in which the heartbeat value of the heartbeat counter has not changed is greater than a preset abnormal monitoring threshold, it is determined that the peer processor core has an abnormality, and an abnormality handling strategy is initiated.

[0012] In the aforementioned inter-core communication system, both the master core and the slave core include a data verification and recovery module. This module calculates the verification field for each frame of data written by the sender to the shared memory area and stores it at the end of each frame. The module also allows the receiver to recalculate the verification field of the data frame after reading it from the shared memory area, and compare the calculated verification field with the verification field at the end of each data frame. If the comparison matches, the subsequent processing continues; otherwise, the frame is discarded, and the sequence number of the discarded frame is sent back to the sender through the shared memory area, requesting the retransmission of the data frame with that sequence number.

[0013] In the aforementioned inter-core communication system, the management information area is equipped with a sending sequence number counter and a desired sequence number counter. The sending sequence number counter is maintained by the sender, and the desired sequence number counter is maintained by the receiver. The sender uses the value of the sending sequence number counter as the sequence number of the data frame. After sending each data frame, the sender increments the sending sequence number counter by 1. After receiving each data frame, the receiver's data verification and recovery module compares the sequence number carried in the data frame with the value of the desired sequence number counter. If they are equal, the data frame is processed normally, and the value of the desired sequence number counter is incremented by 1. If the sequence number is greater than the value of the desired sequence number counter, it is determined that a frame has been lost, and the sequence number of the discarded frame is sent back to the sender through the shared memory area, requesting the sender to retransmit the data frame with that sequence number. If the sequence number is less than the value of the desired sequence number counter, it is determined that a duplicate frame exists, and the frame is directly discarded.

[0014] A power distribution terminal, including the aforementioned inter-nuclear communication system.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) The shared memory area is divided into functional sub-areas such as control instruction area, telemetry data area, batch transmission area and management information area according to the real-time requirements of different data types of the power distribution terminal, and the corresponding independent data structure is configured according to the real-time requirements of the data in different areas, so as to ensure the low latency of emergency control instructions and the efficiency of telemetry data and file transmission.

[0016] (2) By defining the parameters of each sub-functional area in the shared memory region through a unified descriptor table, the dual cores can automatically identify and adapt the parameters of the communication region. In the future, the division of each functional sub-area can be quickly modified by modifying the descriptor table, and new functional sub-areas can be added, which improves the scalability and portability of the system.

[0017] (3) By setting up a message mailbox in the management information area, a message mailbox layer is added before the interruption is triggered, so that the receiver can obtain the message type, priority and target sub-area and other metadata in the interruption response without having to traverse the shared memory one by one to parse it, which greatly shortens the interruption service processing time.

[0018] (4) By adopting interrupt merging strategies for different priorities, we can ensure that emergency instructions are triggered with zero delay while avoiding interrupt storms.

[0019] (5) By using a three-level priority message queue, combined with a preemptive scheduling method that checks the data in the scheduling queue from high to low priority, it is further ensured that the protection action instructions will be transmitted first under any load conditions. By setting a waiting counter for the low priority queue, a starvation protection mechanism is implemented to ensure that low priority data can still get basic transmission opportunities in extreme scenarios and ensure data throughput in extreme environments.

[0020] (6) By setting a verification field for each frame through the data verification and recovery module, performing continuous serial number checks through the sending serial number counter and the expected serial number counter, and establishing a complete data verification system through the retransmission mechanism, and by ensuring the monitoring of single-side processor anomalies through the heartbeat counter maintained by the dual cores, the system's operational stability in electromagnetic interference environments such as high-voltage substations is greatly improved.

[0021] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the inter-core communication system according to an embodiment of the present invention. Detailed Implementation

[0023] The embodiments of the present invention are described in detail below, with reference to... Figure 1This invention provides an inter-core communication system for power distribution terminals, including a master core, slave cores, and physical memory. Both the master and slave cores are electrically connected to the physical memory and can access it via a data bus. There are also direct or indirect signal connections between the master and slave cores. The master core, acting as an application processor core (A core), runs a general-purpose operating system and is responsible for upper-layer applications such as communication protocol parsing, IoT platform integration, human-machine interaction, and intelligent analysis. The slave core, acting as a real-time processor core (R core), runs a real-time operating system (RTOS) and is responsible for highly latency-sensitive tasks such as protection control logic execution, analog / switching signal acquisition, and rapid fault clearing. A contiguous physical memory space in DDR physical memory is configured by the bootloader as a shared memory region for inter-core communication. This shared memory region is configured not to participate in the dynamic memory management of the master and slave cores. That is, all read and write operations on the shared memory region by both the master and slave cores are performed directly, without going through their respective caches. This eliminates the need for compatibility issues with different caching strategies of the two cores, avoids data staleness problems caused by cache inconsistencies, and eliminates the need for hardware-level cache coherence protocols, reducing the hardware implementation requirements of the inter-core communication system. In this embodiment, the master core is an ARM architecture, and the MMU maps the shared memory region to a non-cacheable virtual address space, thereby preventing data at this address from entering the master core's L1 / L2 cache. The slave core is a RISC-V architecture, and the MPU configures the shared memory region as a Device or Strongly-ordered region to ensure that the slave core's access to the shared memory region does not go through the slave core's cache.

[0024] The shared memory area is divided into a control command area, a telemetry data area, a batch transmission area, and a management information area. The control command area is used for the transmission of high-priority short messages such as protection action commands, remote closing / opening commands, and emergency stop commands; the telemetry data area is used for storing and transmitting periodically collected data such as voltage, current, and power; the batch transmission area is used for transmitting large, low-real-time data files such as fault waveform data, configuration files, and firmware upgrade package fragments; and the management information area is used to store management metadata such as dual-core status flags, heartbeat counters, versions, handshake state machine variables, message mailboxes, and synchronization lock flags for each sub-area.

[0025] Each sub-region employs a different buffer structure based on its real-time data transmission requirements, with the control instruction area using a ping-pong buffer structure. The control instruction area is divided into two equally sized buffers, A and B. A buffer index pointer is set within the management information area to indicate which of the two buffers, A and B, is the active buffer. In this embodiment, when the buffer index pointer value is 0, buffer A is the active buffer; when the buffer index pointer value is 1, buffer B is the active buffer. The master core, acting as the writer of control instructions, reads the value of the buffer index pointer using the LDREX instruction and, based on this value, consistently writes the control instruction data to be transmitted to the currently inactive buffer. After writing, it uses the STREX instruction to switch the buffer index pointer to the opposite value. The slave core, acting as the reader of control instructions, reads the value of the buffer index pointer using the Load instruction and, based on this value, consistently reads the control instruction data from the currently active buffer. After reading, it uses the AMOSWAP.W (Atomic Memory Operation - Swap Word) instruction of the RISC-V instruction set to switch the value of the buffer index pointer. By employing a ping-pong buffer structure for the control command area, write and read operations always operate on different physical buffers, naturally eliminating read / write contention. The kernel can safely read commands without acquiring any locks, achieving lock-free reading of control commands and greatly ensuring the real-time transmission of control commands.

[0026] In this embodiment, the telemetry data area adopts a lock-free ring buffer structure, referring to... Figure 1 This includes a preset number of equally sized slots, and the management information area is configured with telemetry read pointers and telemetry write pointers corresponding to the telemetry data area. The slave core, acting as the sole producer, maintains the telemetry write pointer, while the master core, acting as the sole consumer, maintains the telemetry read pointer. Each time the R core writes a frame of telemetry data to the slot pointed to by the telemetry write pointer, it uses a memory barrier instruction (FENCE) to ensure the data is completely written to the corresponding slot in the physical memory's data telemetry area, and then atomically increments the telemetry write pointer. The master core periodically compares the telemetry read pointer and the telemetry write pointer; if they are not equal, it indicates that new data is available for reading. After reading the data from the slot pointed to by the telemetry read pointer, it atomically increments the telemetry read pointer. Because the telemetry write pointer is modified only by the slave core, and the telemetry read pointer is modified only by the master core, and pointer updates are guaranteed to be visible through atomic operations and memory barriers, safe concurrent read and write operations are achieved under lock-free conditions.

[0027] For functional sub-areas requiring mutually exclusive access, such as bulk transfer areas, a mutex lock mechanism is used. In this embodiment, an atomic lock flag of 0x00000000 indicates an unlocked state, while 0x00000001 indicates a locked state. The master core performs atomic read-modify-write operations on the atomic lock flag using LDREX / STREX instructions: the master core first executes LDREX to read the current lock value; if it is 0, it attempts to write 1 using STREX; if STREX returns successfully, the lock is acquired; otherwise, it retryes. The slave core uses the AMOSWAP.W instruction to atomically swap 1 with the atomic lock flag; if the returned old value is 0, the lock is acquired; otherwise, the lock is already occupied. The lock is released by the holder by writing the flag back to 0 using a normal Store instruction (in conjunction with memory barrier instructions: the master core uses the DMB instruction, and the slave core uses the FENCE instruction). To prevent unacceptable blocking delays caused by waiting for locks in the slave core's real-time tasks, a spin wait counter is set on the slave core side. In each cycle, if the slave core fails to acquire the lock, the spin wait counter value is incremented by 1. If the spin wait counter value reaches a preset spin wait limit, the current read is abandoned and the previously valid cached data is returned. The spin wait limit value needs to be determined based on the maximum tolerable additional delay of the slave core's protection task and the slave core's frequency. For example, if the maximum tolerable additional delay of the slave core's protection task is 5 microseconds and the slave core's frequency is 400MHz, then the spin wait limit can be set to 100 cycles. This means that the time taken for 100 spins is approximately 0.25 to 1 microsecond, meeting the 5 microsecond requirement. In this embodiment, the batch transmission area uses a block transmission protocol, with each block accompanied by a sequence number and a checksum.

[0028] It is understood that, in this embodiment, reference is made to... Figure 1 To facilitate modifications and adjustments to each functional sub-region, a pre-formatted descriptor table is set at the starting position of the shared memory region. This descriptor table records, in a structured manner, parameters for each functional sub-region, including sub-region number, sub-region type identifier (8 bits, e.g., 0x01 for control instruction area, 0x02 for telemetry data area, etc.), starting offset address (32 bits, relative to the shared memory base address), sub-region length (32 bits), data structure type identifier (8 bits, e.g., ping-pong buffer / ring buffer / linear buffer), read / write permission flag (8 bits, identifying which side is the producer and which side is the consumer), and checksum (16 bits, CRC16 checksum for this descriptor entry). During initialization, the master and slave cores read the descriptor table, automatically obtaining the location and parameter information of each sub-region, enabling automatic identification and self-adaptation of communication regions. When the system needs to add a new functional sub-region, only entries need to be appended to the descriptor table and space allocation adjusted; no modification to the communication code on both sides is required, improving system scalability and portability, and reducing system development costs. (Refer to...) Figure 1In this embodiment, a certain amount of physical address space is reserved within the shared memory area as a reserved extension area for future functional expansion, and is initialized to zero.

[0029] Reference Figure 1In this embodiment, the communication request mechanism between the master core and the slave core adopts an interrupt triggering mechanism combined with a message mailbox. Both the master core and the slave core are equipped with a message queue management module, an interrupt control module, and an interrupt response module. A message mailbox is set up in the management information area. Two interrupt lines, A2R (master core to slave core direction) and R2A (slave core to master core), are established through the above modules and the message mailbox. The message queue management module is used to write the data to be transmitted into the corresponding functional sub-area of ​​the shared memory region according to the data type, and maintains the corresponding pointers and counters according to the write and read status. The interrupt control module is used to initiate a hardware interrupt to the peer after completing the data writing, notifying the peer to read the data. The interrupt response module is used to respond to the hardware interrupt initiated by the peer and call the corresponding task to read the data in the shared memory region. The message mailbox includes multiple message slots for storing pending message notifications. These notifications include: a validity flag (8 bits, 0x00 for idle, 0xFF for valid); a message type code (8 bits, 0x01 = remote control command, 0x02 = telemetry data, 0x03 = file transfer, 0x04 = heartbeat / management, 0x05 = parameter configuration); a priority flag (8 bits, 0x01 = urgent, 0x02 = normal, 0x03 = background); a target sub-area index (8 bits, corresponding to the sub-area number in the descriptor table); a data offset (32 bits, the starting offset of the data within the target sub-area); a data length (32 bits); a sequence number (32 bits, monotonically increasing); a timestamp (32 bits, the system clock count at the time of transmission); and a checksum field (32 bits, a CRC32 checksum for the first 28 bytes of this slot). After the sender's message queue management module writes the data to be transmitted into the shared memory area, the sender's interrupt control module writes the pending message notification corresponding to the data to be transmitted into the first message slot in the message mailbox with a valid flag of 0x00. After writing, it modifies the valid flag of the message slot to 0xFF and initiates a hardware interrupt to the peer. Upon receiving the hardware interrupt, the receiver's interrupt response module scans the mailbox slots in sequence, reads the pending message notification from the message slot with a valid flag of 0xFF, adds the metadata of the pending message notification to its local processing queue, and clears the valid flag of the read message slot. This embodiment of the inter-core communication system, by employing a bidirectional interrupt line mechanism, reduces communication latency, avoids idle cycles when no data arrives from the core, and, in conjunction with the metadata stored in the message mailbox, allows the receiver to obtain metadata such as message type, priority, and target sub-region in the interrupt response without traversing the shared memory area, significantly shortening the interrupt service processing time and further improving the interrupt service processing efficiency.

[0030] Reference Figure 1In this embodiment, to ensure that protection action commands are transmitted preferentially under any load conditions and to safeguard device safety, the main core's message queue module includes three priority message queues: an emergency queue, a normal queue, and a background queue. The priorities of the three queues decrease sequentially. A first-in, first-out (FIFO) management strategy is adopted within each queue. The emergency queue is used to cache protection action commands, fault clearing commands, emergency remote control commands, etc., originating from IEC 61870-5-101 / 104 remote control messages parsed by the communication protocol stack. The normal queue is used to cache telemetry data upload requests, parameter configuration distribution requests, etc., originating from periodic data acquisition tasks and configuration commands issued by the IoT platform. The background queue is used to cache file transfer requests (fault waveform data, firmware upgrade packages), log reporting requests, etc. The main core's message queue management module also includes a message scheduler. The message scheduler runs at a fixed scheduling cycle, such as 200 microseconds. The message scheduler uses a priority preemptive scheduling algorithm, checking the status of each queue in descending order of priority. If the emergency queue is not empty, the message at the head of the emergency queue is retrieved and written to the control instruction area of ​​the shared memory region. A hardware interrupt is initiated to the slave core through the interrupt control module, and then the current scheduling cycle ends. If the emergency queue is empty and the normal queue is not empty, the message at the head of the normal queue is written to the corresponding sub-area. If both the emergency and normal queues are empty, the messages in the background queue are processed.

[0031] Reference Figure 1 In this embodiment, to avoid interrupt storms in high-frequency scenarios that could interfere with the real-time tasks of the slave core due to frequent interrupt handling, the interrupt control module of the master core includes a merge window timer or a merge window counter. The merge window timer is used to time the merge window, and the merge window counter is used to count the accumulated transmission tasks in the non-urgent queue. For tasks in the normal queue and the background queue, the interrupt control module does not immediately send an interrupt response to the slave core. Instead, it initiates a hardware interrupt to the slave core when the merge window timer reaches a preset window threshold, such as 5 milliseconds, or when the merge window counter reaches an accumulated threshold, such as 4 messages, and then resets the merge window timer or merge window counter to zero.

[0032] Reference Figure 1In this embodiment, to ensure that low-priority data can still receive basic transmission guarantees under extremely high-frequency emergency message scenarios, and to avoid telemetry data backlog or file transfer timeouts due to long-term non-empty emergency queues, the message queue management module also includes wait counters corresponding to the ordinary queue and the background queue, respectively. If the ordinary queue and the background queue are not served by the message scheduler in each scheduling cycle, the value of the corresponding wait counter is incremented by 1; if the count value of the wait counter reaches the preset starvation protection threshold, data from the ordinary queue or the background queue is forcibly inserted for transmission in the next scheduling cycle of the message scheduler. After the slave core reads the metadata of all valid slots in the message mailbox, it sends the metadata to the event flag group of the corresponding priority according to the priority identifier in the metadata, which is then completed by tasks of different priorities.

[0033] Reference Figure 1 In this embodiment, both the master core and the slave core further include a data verification and recovery module. The data verification and recovery module calculates the verification field for each frame of data written by the sender to the shared memory area and stores the verification field at the end of each frame. After the receiver reads a data frame from the shared memory area, the data verification and recovery module also recalculates the verification field of the read data frame and compares the calculated verification field with the verification field at the end of the data frame. If they match, the subsequent processing continues; if they do not match, the frame is discarded, and a NACK (Negative Acknowledgment) message is returned to the sender via a message mailbox, carrying the sequence number of the discarded frame and requesting the sender to retransmit. Upon receiving the NACK, the sender retrieves the data frame corresponding to the sequence number from its local transmission buffer and retransmits it, retrying a maximum of three times. If verification still fails after three retransmissions, a communication anomaly alarm is reported.

[0034] Reference Figure 1In this embodiment, the management information area also includes a sending sequence number counter and a desired sequence number counter. The sending sequence number counter is maintained by the sender, and the desired sequence number counter is maintained by the receiver. Each data frame carries a 32-bit monotonically increasing sequence number, the value of which is the value of the sending sequence number counter. After sending each data frame, the sender increments the sending sequence number counter by 1. After receiving each data frame, the receiver's data verification and recovery module compares the sequence number carried in the data frame with the value of the desired sequence number counter. If they are the same, the data frame is processed normally, and the value of the desired sequence number counter is incremented by 1. If the sequence number is greater than the value of the desired sequence number counter, it is determined that a frame has been lost, a frame loss alarm log is recorded, a retransmission request is sent to the sender via the message mailbox, and the value of the desired sequence number counter is updated to the received frame sequence number + 1. If the sequence number is less than the value of the desired sequence number counter, it is determined that a duplicate frame exists, and the frame is discarded without further processing. This mechanism complements the CRC check field mechanism. The check field is used to verify the integrity of a single frame, while the sequence number is used to detect the integrity of inter-frame transmission, together ensuring the stability and reliability of inter-core communication.

[0035] Reference Figure 1 In this embodiment, to further improve the reliability of inter-core communication, a master core heartbeat counter and a slave core heartbeat counter are also set in the management information area. The master core heartbeat counter is maintained by the master core, and the slave core heartbeat counter is maintained by the slave core. Both the master core and the slave core maintain their corresponding heartbeat counters with the same monitoring period, such as 100 milliseconds. The master core increments the value of its heartbeat counter by 1 every 100 milliseconds, and the slave core increments the value of its heartbeat counter by 1 every 100 milliseconds. The master core periodically reads the value of the slave core heartbeat counter, and the slave core periodically reads the value of the master core heartbeat counter. The read heartbeat counter value is compared with the previously read value. If the number of monitoring periods in which the heartbeat counter value has not changed is greater than a preset abnormal monitoring threshold, such as 5 monitoring periods, it is determined that the peer processing core has an abnormality, and the abnormality handling strategy is activated.

[0036] Specifically, in this embodiment, the local processor core enters a security degradation mode. The specific strategy is as follows: If the slave core detects an anomaly in the master core: the slave core stops receiving new control commands, maintains the last valid configuration, and continues to execute the protection control logic (i.e., the slave core has independent operating capabilities and can complete basic protection functions without relying on the master core), while simultaneously notifying on-site maintenance personnel via local indicator lights or alarm output. If the master core detects an anomaly in the slave core: the master core suspends writing new control commands to shared memory, reports a slave core anomaly alarm to the superior scheduling master station, and simultaneously attempts to trigger a slave core restart via a hardware watchdog or reset pin. After the peer recovers, the resynchronization process of the three-state machine is executed through the handshake flag bit in the management information area: First state READY—the recovering side sets its own handshake flag to READY, indicating that initialization is complete and communication is ready; Second state SYNC—after the peer detects the READY flag of the recovering side, it sets its own flag to SYNC, and both sides exchange their respective software version numbers, descriptor table checksums, and last valid serial numbers, etc.; Third state RUNNING—after both sides confirm that the parameters are consistent, they simultaneously set the flag bit to RUNNING, restoring normal communication. If the parameters are inconsistent (e.g., the version number changes after one side is upgraded), a parameter negotiation process is initiated. The main core reinitializes the descriptor table according to the latest configuration and then attempts to handshake again. This tri-state machine ensures that the dual cores can safely and orderly rebuild the communication link under any abnormal scenario.

[0037] Based on the same inventive concept, embodiments of the present invention also propose a power distribution terminal, including the aforementioned inter-core communication system, which can ensure the reliability and efficiency of communication between the master core and slave core, while avoiding data competition between different service types, and can ensure timely response to protection and control commands, ensuring the safety of the power distribution system, while ensuring the real-time acquisition of telemetry data and the real-time monitoring of the power distribution system.

[0038] It should be noted that in the description of this invention, any descriptions of orientation, such as up, down, front, back, left, right, etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings. They are only for the purpose of facilitating the description of this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed or operated in a specific orientation, and should not be construed as a limitation of this invention.

[0039] In the description of this invention, "several" means one or more, "more than" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the stated number, while "above," "below," "within," etc. are understood to include the stated number. If "first" or "second" is mentioned, it is only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0040] In the description of this invention, unless otherwise explicitly defined, terms such as "setting," "installing," and "connecting" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0041] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A core-to-core communication system for a power distribution terminal, characterized in that, The system includes a master core, slave cores, and physical memory. The physical memory is electrically connected to both the master and slave cores. A shared memory region is configured not to participate in the dynamic memory management of the master and slave cores. This shared memory region is divided into a control instruction area, a telemetry data area, a batch transmission area, and a management information area. The control instruction area is used for transmitting high-priority short messages; the telemetry data area is used for transmitting periodically collected data; the batch transmission area is used for transmitting large amounts of data with low real-time requirements; and the management information area stores management metadata. The control instruction area uses a ping-pong buffer structure. The control information area adopts a lock-free ring buffer structure. The batch transmission area uses a mutex lock mechanism. The management information area is equipped with a buffer index pointer to mark the active buffer in the control command area, read and write pointers for the telemetry data area, and an atomic lock flag to mark whether the lock in the batch transmission area is held. Both the master core and the slave core are equipped with a message queue management module, an interrupt control module, and an interrupt response module. The management information area is equipped with a message mailbox, which includes multiple message slots for storing pending message notifications. The pending message notification includes a validity flag, message type encoding, priority identifier, target sub-area index, and data offset. The sender's message queue management module writes the data to be transmitted into the shared memory area, including the data size, data length, sequence number, timestamp, and verification fields of the pending message notification. Then, the sender's interrupt control module writes the pending message notification corresponding to the data to be transmitted into the first free message slot in the message mailbox. After writing, the valid flag bit in the message slot is modified to be valid, triggering a hardware interrupt on the receiver. Upon triggering the hardware interrupt on the receiver's interrupt response module, it sequentially scans the message mailbox and reads the pending message notification from the message slot where the valid flag bit is valid. The system knows that the metadata of the message notification to be processed is added to the local processing queue, and the valid flag bit of the read message slot is cleared and released. The main core message queue management module includes three priority message queues: an emergency queue, a normal queue, and a background queue. The priority of the emergency queue, the normal queue, and the background queue decreases in sequence. The main core message queue management module includes a message scheduler. The message scheduler runs at a fixed scheduling cycle. The message scheduler checks the status of each queue in descending order of priority and takes the data at the head of the highest priority non-empty queue and writes it to the corresponding sub-area of ​​the shared memory region.

2. The inter-nuclear communication system according to claim 1, characterized in that, The shared memory region is configured with a descriptor table of a preset format at its starting position. The descriptor table stores the parameter information of each sub-region of the shared memory region and the checksum of the descriptor table in a structured manner.

3. The inter-nuclear communication system according to claim 1, characterized in that, The interrupt control module of the main core includes a merge window timer or a merge window counter. The merge window timer is used to time the merge window, and the merge window counter is used to count the accumulated non-urgent transmission tasks. When the timer value of the merge window timer reaches a preset window threshold, or when the count value of the merge window counter reaches a preset accumulation threshold, the interrupt control module triggers a hardware interrupt to the slave core.

4. The inter-nuclear communication system according to claim 1, characterized in that, The message queue management module also includes waiting counters corresponding to the ordinary queue and the background queue respectively. If the ordinary queue or the background queue is not served in each scheduling cycle, the value of the corresponding waiting counter is incremented by 1. If the count value of the waiting counter reaches the preset starvation protection threshold, the data transmission of the ordinary queue or the background queue is forcibly inserted once in the next scheduling cycle.

5. The inter-nuclear communication system according to claim 1, characterized in that, The management information area is equipped with a master core hop counter and a slave core hop counter. The master core hop counter and the slave core hop counter are maintained by the master core and the slave core respectively with the same maintenance cycle. The master core and the slave core periodically read each other's heartbeat counters at a preset monitoring cycle. If the number of monitoring cycles in which the heartbeat value of the heartbeat counter has not changed is greater than the preset abnormal monitoring threshold, it is determined that the peer processor core is abnormal and an abnormality handling strategy is initiated.

6. The inter-nuclear communication system according to claim 1, characterized in that, Both the master core and the slave core include a data verification and recovery module. The data verification and recovery module is used to calculate the verification field of each frame of data written by the sender to the shared memory area, and store the verification field in the end of each frame of data. The data verification and recovery module is also used by the receiver to recalculate the verification field of the data frame after reading the data frame from the shared memory area, and compare the calculated verification field with the verification field at the end of each data frame. If the comparison matches, the subsequent processing continues; if the comparison does not match, the frame is discarded, and the sequence number of the discarded frame is sent back to the sender through the shared memory area to request the sender to retransmit the data frame with the sequence number.

7. The inter-nuclear communication system according to claim 6, characterized in that, The management information area is equipped with a sending sequence number counter and a desired sequence number counter. The sending sequence number counter is maintained by the sender, and the desired sequence number counter is maintained by the receiver. The sender uses the value of the sending sequence number counter as the sequence number of the data frame. After sending each data frame, the sender increments the sending sequence number counter by 1. After receiving each data frame, the receiver's data verification and recovery module compares the sequence number carried in the data frame with the value of the desired sequence number counter. If they are equal, the data frame is processed normally, and the value of the desired sequence number counter is incremented by 1. If the sequence number is greater than the value of the desired sequence number counter, it is determined that a frame has been lost. The sequence number of the lost frame is sent back to the sender through the shared memory area, requesting the sender to retransmit the data frame with that sequence number. If the sequence number is less than the value of the expected sequence number counter, it is determined that there is a duplicate frame, and the frame is discarded directly.

8. A power distribution terminal, characterized in that, Includes the inter-nuclear communication system according to any one of claims 1 to 7.

Images