A low-delay interrupt processing method and system for a smart control center

Abstract

The application discloses a low-delay interrupt processing method and system of an intelligent control center, and belongs to the field of industrial control computer system architecture. The method comprises the following steps: analyzing an interrupt request to obtain an event type identifier; matching the event type identifier to a corresponding interrupt priority based on a predefined event priority mapping table; selecting a path from a set of pre-allocated and physically isolated hardware response paths according to the interrupt priority; distributing the interrupt request and context data to a pre-bound processing core through the selected path; and executing a preloaded simplified processing routine by the processing core to generate a driving instruction. The application combines event semantic mapping with physically isolated hardware paths to provide a deterministic low-delay response channel for core emergency interrupts, and improves system reliability through a load balancing mechanism based on cache consistency, effectively solving the problem of large interrupt processing delay jitter in high-concurrency industrial intelligent control centers, and significantly improving the real-time performance of the control system.

Description

Technical Field

[0001] This application relates to the field of industrial control computer system architecture technology, and in particular to a low-latency interrupt handling method and system for an intelligent control center. Background Technology

[0002] As the core hub of modern intelligent manufacturing, the industrial intelligent control center is responsible for centrally processing massive, high-concurrency interrupt requests from various equipment on the production line, such as equipment status updates, emergency alarms, and scheduling instructions. These interrupt events vary significantly in terms of urgency, real-time requirements, and impact on system control logic. However, traditional interrupt handling technologies largely rely on pure software-level priority scheduling and management, and their inherent limitations are becoming increasingly apparent.

[0003] First, the interrupt response path heavily relies on a shared software interrupt controller and system bus. Interrupt requests of various priorities face resource contention and blocking risks during transmission and response, resulting in significant jitter in the response latency of high-priority events, failing to meet the stringent requirements of deterministic latency in industrial control. Second, software-level priority scheduling and task allocation mechanisms introduce additional decision-making overhead and context switching time when handling high-concurrency interrupts, becoming a bottleneck for reducing system real-time performance. Third, traditional architectures lack mechanisms for differentiated hardware-level processing based on event business semantics, failing to provide an absolutely priority, physically isolated, rapid response channel for the most urgent safety-related events. While hardware interrupt controllers exist in existing technologies, their channel allocation is often static or lacks deep coupling with industrial event semantics, making it difficult to achieve efficient load balancing and system reliability while ensuring minimum latency. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the embodiments of this application provide a low-latency interruption handling method for intelligent control centers to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, this application provides a low-latency interrupt handling method for an intelligent control center, comprising:

[0006] Parse the interrupt request received by the industrial intelligent control center and obtain the event type identifier carried in the interrupt request;

[0007] Based on a predefined event priority mapping table, the event type identifier is matched with the corresponding interrupt priority, wherein the event priority mapping table is pre-set according to the urgency of events and associated control logic in the industrial control scenario;

[0008] Based on the interrupt priority, a hardware response path is selected from a pre-allocated set of response paths, wherein hardware response paths of different priorities are physically isolated.

[0009] The interrupt request and its associated context data are assigned to a pre-bound processing core via a selected hardware response path.

[0010] The processing core executes a preloaded simplified processing routine corresponding to the interrupt priority, generating drive instructions for controlling industrial actuators.

[0011] To address the aforementioned issues, this application also provides a low-latency interrupt handling system for an intelligent control center, the system comprising:

[0012] The interrupt parsing module is used to parse the interrupt request received by the industrial intelligent control center and obtain the event type identifier carried in the interrupt request;

[0013] The priority matching module is used to match the event type identifier with the corresponding interrupt priority based on a predefined event priority mapping table, wherein the event priority mapping table is pre-set according to the urgency of the event and the associated control logic in the industrial control scenario;

[0014] The path selection module is used to select a hardware response path from a pre-allocated set of response paths according to the interrupt priority, wherein hardware response paths of different priorities are physically isolated.

[0015] The data allocation module is used to allocate the interrupt request and its associated context data to the pre-bound processing core through the selected hardware response path.

[0016] The instruction generation module is used by the processing core to execute a preloaded simplified processing routine corresponding to the interrupt priority, and generate drive instructions for controlling industrial actuators.

[0017] Compared with the prior art, this application has the following beneficial effects:

[0018] This invention effectively improves the real-time performance and reliability of industrial intelligent control centers by constructing a collaborative interrupt handling mechanism based on event semantics and physically isolated hardware paths. The primary effect is the achievement of deterministic interrupt response and ultra-low latency. By mapping event type identifiers to preset interrupt priorities and triggering physically isolated dedicated hardware response paths accordingly, an unobstructed direct channel to the processing core is created for critical emergency events. This completely avoids latency jitter caused by software scheduling and resource contention, ensuring that the highest priority events, such as emergency safety stops, receive the fastest response under any system load.

[0019] Secondly, this invention significantly reduces the overhead of software decisions and context switching during interrupt handling by using a pre-allocated hardware path, pre-bound processing cores, and pre-loaded simplified processing routines. Simultaneously, the coprocessor core dynamic load balancing mechanism based on a shared high-speed cache seamlessly takes over interrupt handling tasks when the main core is detected to be overloaded. This not only avoids the performance penalty caused by cache invalidation in traditional task migration and maintains the low-latency characteristics of processing, but also effectively improves the overall throughput and reliability of the system under high loads. Attached Figure Description

[0020] Figure 1 A flowchart illustrating a low-latency interrupt handling method for an intelligent control center provided in an embodiment of this application;

[0021] Figure 2 A functional block diagram of a low-latency interrupt handling system for an intelligent control center provided in an embodiment of this application;

[0022] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0024] This application provides a low-latency interrupt handling method for an intelligent control center. The executing entity of this low-latency interrupt handling method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the low-latency interrupt handling method for the intelligent control center can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms.

[0025] Reference Figure 1 The diagram shown is a flowchart illustrating a low-latency interrupt handling method for an intelligent control center according to an embodiment of this application. In this embodiment, the low-latency interrupt handling method for the intelligent control center includes:

[0026] S1. Parse the interrupt request received by the industrial intelligent control center and obtain the event type identifier carried in the interrupt request.

[0027] In this embodiment of the application, the interruption request is a trigger signal sent by industrial field equipment to the industrial intelligent control center when a specific event occurs (such as equipment failure, status change, or data acquisition completion). The purpose is to request the intelligent control center to handle the event in a timely manner. The event type identifier is a set of preset coded information used to uniquely distinguish the source equipment of the interruption event and the specific nature of the event. Through this code, it can be quickly determined which industrial equipment has experienced what type of event.

[0028] In some embodiments, parsing the interrupt request received by the industrial intelligent control center and obtaining the event type identifier carried in the interrupt request includes:

[0029] The event type identifier is extracted from the specified header field of the interruption request. The event type identifier is used to uniquely characterize the industrial equipment from which the interruption event originates and the nature of the event.

[0030] In this embodiment, the industrial intelligent control center is used to receive signals from various equipment (such as sensors, machine tools, and robotic arms) in the industrial field and to perform real-time control on industrial actuators. It is the core hub of the factory control system.

[0031] In this embodiment of the application, the specified message header field is a specific area in the message header that is specially designated when defining the interrupt request message format and is used to store the event type identifier. The position and length of this area are predetermined in the industrial communication protocol.

[0032] First, the signal receiving module of the industrial intelligent control center continuously monitors the communication links from industrial field devices (such as PROFINET, Modbus bus). When an interrupt request signal is detected, the signal receiving module will first perform preliminary filtering of the signal, eliminating invalid signals caused by transmission interference (such as signals with abnormal signal amplitude or incorrect check codes), and retaining only valid interrupt requests that conform to the preset communication protocol specifications.

[0033] Next, the signal receiving module transmits the valid interrupt request to the interrupt parsing module inside the intelligent control center. This module is a dedicated parsing unit based on FPGA hardware circuit design, which has high-speed message processing capabilities. The parsing module first reads the header structure of the interrupt request message, and according to the pre-stored message format definition (such as a message header length of 16 bytes, where bytes 3-6 are specified message header fields), locates the specified field area storing the event type identifier.

[0034] Subsequently, the parsing module extracts the encoded information from the specified message header field through hardware logic circuits. For example, when a fault interruption request is received from the robotic arm numbered "M01", the encoded information in the specified message header field is "M01-FLT-001", where "M01" represents the device identifier, "FLT" represents the fault class event, and "001" represents the specific fault type (such as motor overload). The parsing module directly extracts this encoded information as the event type identifier.

[0035] Finally, the parsing module verifies the validity of the extracted event type identifier. Verification rules include whether the encoding length conforms to a preset value (e.g., fixed at 12 characters), whether the device identifier is in the list of devices registered in the intelligent control center, and whether the event type encoding belongs to a preset valid type (e.g., "FLT", "DAT", and "CFG" represent fault, data, and configuration events, respectively). If the verification passes, the parsing module sends the event type identifier to the subsequent priority matching module; if the verification fails, the parsing module sends an "invalid identifier" response signal to the device that sent the interrupt request and records the time and device information of the abnormal request for subsequent troubleshooting.

[0036] In this embodiment of the application, taking an automotive parts production line as an example, when the "T03" CNC machine tool in the production line experiences an overtravel event of its motion axis, the machine tool will send an interrupt request to the industrial intelligent control center. After filtering invalid signals, the signal receiving module of the intelligent control center transmits the request to the parsing module. The parsing module locates the specified field of the 3rd to 6th bytes of the message header, extracts the event type identifier "T03-OVER-002", verifies and confirms that "T03" is a registered device and "OVER" is a valid event type, and then sends the identifier to the priority matching module to complete the implementation of step S1.

[0037] In this embodiment of the application, this step avoids full parsing of the entire interrupt request message by using a hardware-based parsing module and a specified field extraction method, which greatly shortens the identifier acquisition time and solves the problem of high latency in processing massive high-concurrency events by traditional software parsing methods. This lays a low-latency foundation for subsequent priority matching and interrupt response, and ensures the real-time performance of the factory control system.

[0038] S2. Based on a predefined event priority mapping table, match the event type identifier to the corresponding interrupt priority, wherein the event priority mapping table is pre-set according to the urgency of events and associated control logic in the industrial control scenario.

[0039] In this embodiment of the application, the event priority mapping table is a "event type identifier - interrupt priority" correspondence table that is pre-established in the memory of the industrial intelligent control center system based on the degree of impact (i.e. urgency) of different events on production safety and efficiency in the industrial control scenario, and the control logic associated with event processing (such as whether it involves the core functions of the equipment).

[0040] In this embodiment, interrupt priority is a level identifier used to distinguish the order in which different interrupt events are processed. The industrial intelligent control center will allocate system resources to process interrupt events with higher priority.

[0041] In some embodiments, matching the event type identifier to the corresponding interrupt priority based on a predefined event priority mapping table includes:

[0042] Use the event type identifier as the query key to perform a matching query in the event priority mapping table and obtain the corresponding numeric priority number.

[0043] The value of the priority number is positively correlated with the urgency of the interrupt priority.

[0044] In this embodiment of the application, the query key is a keyword used to locate the target data during the data search process. In this step, the event type identifier is used as the query key to quickly find the corresponding interrupt priority in the event priority mapping table.

[0045] In the embodiments of this application, the priority number in digital form is an interrupt priority identifier represented by Arabic numerals (such as 1, 2, 3). The value is positively correlated with the urgency of the interrupt event, that is, the smaller the value, the higher the priority (or the larger the value, the higher the priority, which is determined according to preset rules).

[0046] In some embodiments, the event priority mapping table is pre-set according to the urgency of events and associated control logic in the industrial control scenario, including:

[0047] Set the priority of safety events related to equipment emergency stop and motion axis overtravel to the highest level;

[0048] Set the priority of time-sensitive events related to periodic data acquisition and high-precision timed triggering to the second highest;

[0049] Set the priority of regular events related to parameter configuration updates and logging to the lowest level.

[0050] In this application embodiment, safety events are those in industrial production that directly threaten personnel safety and equipment integrity, such as emergency equipment stops and overtravel of moving axes. If these events are not handled in a timely manner, they can lead to serious safety accidents. Time-sensitive events are those in industrial production that have strict requirements for processing time, such as periodic data acquisition (e.g., collecting temperature data every 10ms) and high-precision timed triggering (e.g., process switching accurate to the microsecond level). Delays in processing these events can affect the accuracy of production parameter monitoring or the production rhythm. Routine events are those in industrial production that have less stringent requirements for processing time, such as parameter configuration updates (e.g., adjusting equipment operating parameters) and log recording (e.g., recording equipment operating status). Delays in processing these events will not have a direct impact on production safety and efficiency.

[0051] The first step is to classify and sort out typical events in industrial control scenarios, and determine the urgency of the events and the associated control logic based on the actual needs of different customers such as automotive parts production lines and new energy battery assembly lines.

[0052] For example, in an automotive parts production line, emergency equipment stoppages directly affect operator safety, and the associated control logic is to immediately cut off the equipment's power source, making it the most urgent event. Periodic spindle speed data acquisition events are related to production quality monitoring, with the next highest urgency. Equipment parameter configuration update events only occur during production breaks, with the lowest urgency. Based on this, technicians categorize events into three types: safety-related, time-sensitive, and routine. Each type of event is assigned a corresponding numerical priority number, such as number 1 (highest priority) for safety-related events, number 2 (second highest priority) for time-sensitive events, and number 3 (lowest priority) for routine events. Subsequently, the event type identifiers of each type of event are mapped one-to-one with their priority numbers and stored in the system's memory cache area (such as L2 cache), forming an event priority mapping table. For example, "T03-OVER-002" (axis overtravel, safety-related) corresponds to number 1, "S05-TEMP-001" (temperature data acquisition, time-sensitive) corresponds to number 2, and "M01-PARA-003" (parameter configuration, routine) corresponds to number 3.

[0053] In the second step, the priority matching module of the industrial intelligent control center obtains the event type identifier from the parsing module in step S1, and uses this identifier as a query key to call the hardware lookup interface of the mapping table. This lookup interface is designed based on a hash lookup algorithm. The priority matching module first performs a hash operation on the event type identifier to obtain a hash value, and then directly locates the corresponding storage address in the mapping table based on the hash value, without traversing the entire mapping table. For example, after obtaining the event type identifier "T03-OVER-002", the hash value "0x12A" is obtained through hash operation. Based on this hash value, the memory cell with address "0x12A" in the mapping table is directly located, and the numeric priority number "1" stored in that cell is read.

[0054] Third, after obtaining the priority number, the priority matching module will perform a validity check on the number to confirm whether it is within the preset valid range (e.g., 1-3). If the check passes, the priority number will be sent to the subsequent hardware response path selection module; if the check fails (e.g., the number "4" is read, which is outside the valid range of 1-3), the priority matching module will set the priority of the interrupt event to the lowest priority (number 3) by default, and at the same time send a "priority matching error" alarm signal to the system management module, recording the error identifier and matching time, so that technicians can maintain and update the mapping table later.

[0055] In this embodiment of the application, taking a new energy battery assembly line as an example, when the "B07" battery testing device in the assembly line sends an interrupt request of "B07-DAT-005" (battery voltage periodic acquisition, time sensitive type), step S1 parses to obtain the event type identifier, and the priority matching module in step S2 uses it as a query key, locates the corresponding storage unit in the mapping table through hash operation, reads the priority number "2", and after verification, sends it to the path selection module to complete the priority matching process.

[0056] In this embodiment of the application, this step avoids the high latency and subjectivity of traditional software table lookup by using a preset scenario-based event priority mapping table and a hardware-based hash lookup method. This ensures the speed and accuracy of priority matching under high concurrency events, solves the problem of emergency events being blocked by low-priority events in a large number of events, and further guarantees the reliability and real-time performance of the factory control system.

[0057] S3. Select a hardware response path from the pre-allocated set of response paths according to the interrupt priority, wherein hardware response paths of different priorities are physically isolated.

[0058] In this embodiment of the application, the response path set is a general term for multiple physical transmission paths that are pre-planned and deployed for different interrupt priorities during the hardware design phase of the industrial intelligent control center. Each path corresponds to interrupt data transmission of a specific priority. The hardware response path is a single physical transmission channel in the response path set, used to carry the transmission of interrupt requests and related data within the intelligent control center. Its hardware structure and transmission characteristics are matched with the real-time requirements of the corresponding interrupt priority.

[0059] In the embodiments of this application, physical isolation means that hardware response paths of different priorities use independent circuit wiring, components and transmission channels, and there is no signal sharing or electrical connection, so as to ensure that the transmission of high-priority interrupts is not interfered with by low-priority interrupts.

[0060] In some embodiments, the selection of a hardware response path from a pre-allocated set of response paths based on the interrupt priority includes:

[0061] If the matched interrupt priority is the first priority, then the first physical channel directly connected to the internal hardware interrupt controller of the central processing unit is enabled.

[0062] If the matched interrupt priority is the second priority, then the second physical channel forwarded through the input / output memory management unit is enabled;

[0063] The signal transmission delay of the first physical channel is lower than that of the second physical channel.

[0064] In this application embodiment, the first priority is the highest level in the event priority system, corresponding to safety events in industrial control scenarios (such as equipment safety emergency stop, motion axis overtravel). These events require microsecond-level response to avoid safety accidents.

[0065] In this embodiment, the central processing unit is the core computing unit of the industrial intelligent control center, responsible for executing interrupt handling logic. It integrates a hardware interrupt controller to manage the reception and distribution of interrupt requests. The hardware interrupt controller is a dedicated hardware module integrated inside the central processing unit, used to quickly receive and prioritize interrupt requests, and directly distribute high-priority interrupts to the processing core, reducing software scheduling latency.

[0066] In this embodiment, the first physical channel is a dedicated transmission channel designed for the first priority interrupt, which is directly connected to the internal hardware interrupt controller of the central processing unit and uses independent wiring inside the chip to achieve the lowest transmission latency.

[0067] In this embodiment, the second priority is the second highest level in the event priority system, corresponding to time-sensitive events in industrial control scenarios (such as periodic data acquisition and high-precision timed triggering). These events require millisecond-level response to ensure production rhythm. The input / output memory management unit is a hardware module in the industrial intelligent control center used to manage data transmission between input / output devices and memory, and is responsible for address translation, data caching, and transmission security control.

[0068] In this embodiment, the second physical channel is a transmission channel designed for second-priority interrupts. It needs to be forwarded through the input / output memory management unit, and its hardware structure is adapted to the transmission requirements of the second-highest priority events.

[0069] In some embodiments, the first physical channel and the second physical channel are physically isolated, including:

[0070] The first physical channel is a metal wiring inside the chip that is independent of the system bus;

[0071] The second physical channel is a physical line connected to the input / output memory management unit via pins on the chip package.

[0072] In this embodiment, the internal metal wiring of the chip is a wire formed by etching a high-conductivity metal (such as copper) inside the chip during the manufacturing process of the core chip of the industrial intelligent control center, used to connect different hardware modules inside the chip; the system bus is a common data transmission line inside the industrial intelligent control center used to connect hardware modules such as the central processing unit, memory, and input / output devices, used to carry general data interaction between multiple modules; the chip package pins are metal contacts on the package structure of the core chip of the industrial intelligent control center, used to realize the electrical connection between the internal circuit of the chip and external hardware modules (such as input / output memory management units); the physical line is a physical transmission path composed of insulated wires, connectors and other components, used to connect the chip package pins and the input / output memory management unit to realize the external transmission of interrupt data.

[0073] In this embodiment, based on the core technical problem of the industrial intelligent control center (high interrupt response latency and poor determinism under high concurrency events), the response path set is planned during the hardware design stage. Considering the response requirements of different events in scenarios such as automotive parts production lines and new energy battery assembly lines, the response path set is divided into a first physical channel, a second physical channel, and a low-priority channel (corresponding to regular events). The first physical channel is designed for first-priority (safety events), using internal metal wiring independent of the system bus, with the wiring length controlled to the shortest path within the chip (e.g., only connecting the hardware interrupt controller to the core 0 pin), avoiding transmission contention on the system bus. The second physical channel is designed for second-priority (time-sensitive events), connecting to the input / output memory management unit via dedicated pins on the chip package (e.g., pin numbers P10-P15), from which the information is forwarded to the central processing unit. The low-priority channel shares system bus resources, adapting to the low real-time requirements of regular events.

[0074] In this embodiment, after the path selection module of the industrial intelligent control center obtains the interrupt priority number (such as first priority, second priority) from the priority matching module in step S2, it calls the internal hardware judgment logic (based on gate circuit design) to identify the priority. If the judgment result is the first priority (such as priority number 1 corresponding to the security event "T03-OVER-002"), the path selection module sends a "channel enable signal 1" to the hardware interrupt controller inside the central processing unit. This signal triggers the closing of the switching circuit between the hardware interrupt controller and the first physical channel, enabling the first physical channel. At this time, the interrupt request and associated data are directly transmitted through the independent metal wiring inside the chip, without going through the system bus or other intermediate modules, and there is no data contention delay during the transmission process.

[0075] In this embodiment, if the judgment result is the second priority (such as priority number 2 corresponding to the time-sensitive event "S05-TEMP-001"), the path selection module sends a "channel enable signal 2" to the input / output memory management unit and simultaneously controls the dedicated pins (P10-P15) on the chip package to be turned on, enabling the second physical channel. The interrupt request and associated data are first transmitted to the input / output memory management unit through the chip package pins. This unit performs address translation (converting virtual addresses to physical addresses) and simple verification on the data before forwarding it to the central processing unit through internal circuitry. During this process, the forwarding logic of the input / output memory management unit adopts a hardware acceleration design to avoid address translation delays at the software level and ensure the transmission efficiency of the second priority event.

[0076] In this embodiment of the application, a dual isolation mechanism is adopted in the hardware design to ensure that the transmission of interrupts of different priorities does not interfere with each other.

[0077] For the first physical channel, its metal wiring is completely independent of the system bus inside the chip. The wiring layer and the system bus wiring layer are isolated by insulating material, and the two ends of the wiring are only connected to the hardware interrupt controller and the designated processing core, without other branch nodes, thus eliminating the interference of system bus data to the first physical channel from the physical structure.

[0078] For the second physical channel, its physical lines use independent PCB traces, maintaining a preset safe distance (e.g., more than 2mm) from other lines (such as system bus lines and power lines), and the outer layer of the lines is wrapped with a shielding layer to reduce electromagnetic interference. At the same time, it is connected to the input / output memory management unit through a dedicated port of the chip package pin to ensure that only the second priority data can be transmitted through this channel, thus achieving physical isolation from the first physical channel and other channels.

[0079] In this embodiment, taking an automotive welding production line as an example: when the robotic arm in the production line experiences a "collision warning" (a safety event, first priority), after the interrupt request is matched to the first priority in step S2, the path selection module activates the first physical channel, and the data is directly transmitted to the central processing unit through independent metal wiring inside the chip, avoiding the blockage of other data (such as parameter configuration data) in the system bus; when the temperature sensor in the production line sends "10ms cycle temperature data" (a time-sensitive event, second priority), after the interrupt request is matched to the second priority, the path selection module activates the second physical channel, and the data is transmitted to the input / output memory management unit through the chip package pins, and after address conversion, it is forwarded to the central processing unit, ensuring the timeliness and independence of data transmission.

[0080] In this embodiment of the application, this step solves the problem of high-priority interrupts being blocked by low-priority interrupts in traditional shared bus transmission by binding priority with hardware channels and physical isolation mechanism, ensuring that the transmission delay of interrupts of different priorities is stable and controllable, significantly reducing the delay jitter of interrupt response, and providing hardware-level real-time guarantee for industrial intelligent control centers to handle massive high-concurrency events.

[0081] S4. The interrupt request and its associated context data are assigned to the pre-bound processing core through the selected hardware response path.

[0082] In this embodiment, the pre-bound processing core is a dedicated computing core pre-assigned for different interrupt priorities during the initialization of the industrial intelligent control center system. Each priority interrupt is handled only by the corresponding bound core, avoiding task scheduling delays between cores.

[0083] In this embodiment, context data is auxiliary information related to the interrupt request, including the event timestamp, current operating parameters of the device (such as the position coordinates of the robotic arm and the sensor detection values), event triggering conditions, etc. This data is a necessary basis for the core execution of interrupt handling logic.

[0084] In some embodiments, allocating the interrupt request and its associated context data to a pre-bound processing core via a selected hardware response path includes:

[0085] The context data is moved from system memory to the local memory of the processing core through the memory access engine corresponding to the hardware response path.

[0086] In this embodiment, the memory access engine is a dedicated data transport hardware module that corresponds one-to-one with the hardware response path. It is integrated at the end of the hardware response path and is used to quickly read context data in the system memory and transfer it to the local memory of the processing core.

[0087] In this embodiment, the system memory is a large-capacity storage device in the industrial intelligent control center used to store global data and to temporarily store the context data of all interrupt requests. It is implemented using DRAM chips. The local memory is a high-speed memory (such as L1 cache or SRAM) integrated inside the processing core. It is used to store the context data that the processing core is currently processing. Its access speed is much higher than that of the system memory to reduce data read latency.

[0088] In this embodiment, based on the multi-core hardware architecture of the industrial intelligent control center (such as a 4-core central processing unit), the binding of "priority-processing core" is completed through configuration registers during the system initialization phase. For example, the first priority (security events) is bound to core 0, the second priority (time-sensitive events) is bound to core 1, and the low priority (normal events) is bound to cores 2-3. The binding relationship is stored in the system's core allocation table, and the path selection module can directly read the table to determine the target processing core.

[0089] In this embodiment, after the hardware response path is selected in step S3, the path selection module sends a "start signal" to the memory access engine corresponding to that path. If the first physical channel (corresponding to the first priority) is selected, the "high-speed memory access engine A" integrated with the first physical channel is started; if the second physical channel (corresponding to the second priority) is selected, the "standard memory access engine B" integrated with the second physical channel is started. The hardware parameters of different memory access engines are adapted to the transmission characteristics of the corresponding channels. For example, the high-speed memory access engine A has a higher transmission bandwidth (e.g., 10GB / s) and a larger data prefetch depth (e.g., 64 bytes) to adapt to the low latency requirements of the first priority event; the standard memory access engine B has a transmission bandwidth adapted to the second priority requirements (e.g., 5GB / s) and also supports the reuse of address translation results of the input / output memory management unit.

[0090] In this embodiment, after the memory access engine starts, it first reads the storage address of the context data from the system memory. This address is synchronously recorded by the parsing module in step S1 when extracting the event type identifier and stored in the additional information field of the interrupt request. For example, the context data of the first priority event "T03-OVER-002" (including collision position coordinates X=150mm, Y=200mm, trigger timestamp=1690000000ms) is stored in the 0x80001000-0x800010FF address segment of the system memory. After the high-speed memory access engine A reads this address information, it sends a "data read request" to the system memory through the first physical channel. After receiving the request, the system memory controller transmits the context data of the corresponding address segment to the high-speed memory access engine A through the first physical channel.

[0091] In this embodiment, after receiving context data, the memory access engine does not require software scheduling by the central processing unit. Instead, it directly writes the data to the local memory of the pre-bound processing core based on the core's information. For example, high-speed memory access engine A writes the context data of "T03-OVER-002" to the L1 cache of core 0 (addresses 0x20000000-0x200000FF), and standard memory access engine B writes the context data of the second priority event "S05-TEMP-001" (temperature value = 35℃, acquisition timestamp = 1690000010ms) to the L1 cache of core 1 (addresses 0x20010000-0x200100FF). The local memory write process uses "Direct Memory Access (DMA)," eliminating the need for the processing core to participate in data transfer. The core only needs to read the local memory after the data is written, significantly reducing the time the core spends waiting for data.

[0092] In this embodiment of the application, taking a new energy battery testing production line as an example: when the testing equipment sends an interrupt request for "battery voltage over-limit" (safety event, first priority), step S3 selects the first physical channel. In step S4, the high-speed memory access engine A reads context data (voltage value = 4.5V, over-limit threshold = 4.2V) from the system memory (address 0x80002000) and moves the data to the L1 cache of core 0 through the first physical channel. Core 0 does not need to wait for system memory access and can directly read the local cache to execute subsequent interrupt processing, avoiding the core idle delay in the traditional data moving method.

[0093] In this embodiment of the application, this step solves the high latency problem of core waiting for main memory in traditional software-level data transfer through hardware-based data transfer design, ensuring that interrupt requests and context data quickly reach the processing core, laying a low-latency foundation for the subsequent simplified execution of processing routines, and further improving the real-time interrupt response of the industrial intelligent control center.

[0094] S5. The processing core executes a preloaded simplified processing routine corresponding to the interrupt priority to generate drive instructions for controlling industrial actuators.

[0095] In this embodiment, the simplified processing routine is a streamlined program code that is pre-written and loaded into the corresponding processing core according to the processing requirements of different interrupt priorities of the industrial intelligent control center. It only contains the logic necessary to process the interrupt event of that priority and removes redundant functional modules to shorten the execution time. The industrial execution component is a device that performs specific operations in the industrial production process, such as a robotic arm, conveyor belt, servo motor, valve, etc. Its operating status needs to be controlled by the drive instructions generated by the industrial intelligent control center.

[0096] In the embodiments of this application, the driving instruction is a signal instruction generated by the processing core or coprocessor core after executing a simplified processing routine, used to control industrial actuators to perform specific actions (such as starting, stopping, or adjusting operating parameters).

[0097] In some embodiments, the processing core executes a preloaded simplified processing routine corresponding to the interrupt priority to generate drive instructions for controlling industrial actuators, including:

[0098] Generate digital output commands or analog control commands, and send them to the industrial actuator via the industrial bus interface;

[0099] The driving instructions are obtained by the simplified processing routine by accessing the context data and performing preset logical operations or state judgments.

[0100] In the embodiments of this application, digital output instructions are drive instructions represented by discrete binary signals (such as high level and low level), which are suitable for controlling the switching state of industrial actuators, such as controlling the emergency stop of a robotic arm and the opening and closing of a valve; analog control instructions are drive instructions represented by continuously changing physical quantities (such as current and voltage), which are suitable for controlling the continuous operating parameters of industrial actuators, such as adjusting the speed of a servo motor and regulating the opening of a temperature control valve.

[0101] In this embodiment, the industrial bus interface is a hardware interface module used by the industrial intelligent control center to communicate with industrial actuators. It supports mainstream industrial communication protocols such as PROFINET and Modbus to ensure stable transmission of drive commands.

[0102] In some embodiments, before the processing core executes a preloaded simplified processing routine corresponding to its interrupt priority, the method further includes:

[0103] Monitor the current load status of the processing core;

[0104] When the current load state exceeds the dynamic load threshold preset for the processing core, the interrupt request and the context data are copied to the coprocessor core that shares a cache with the processing core.

[0105] The preloaded simplified processing routines are executed by the coprocessor core.

[0106] In this embodiment, the current load status refers to the busyness of the processing core at a certain moment, which is comprehensively characterized by indicators such as the number of tasks being executed by the processing core, CPU utilization, and task queue waiting length. The dynamic load threshold is a preset, dynamically adjustable load limit value for each processing core based on the computing power of the processing core, the priority requirements of interrupt events, and the real-time requirements of industrial scenarios. When the current load status of the processing core exceeds the threshold, a load balancing mechanism needs to be activated.

[0107] In this embodiment, the shared cache is a high-speed memory shared by the main processing core and the coprocessor core, used to store data that both need to access (such as interrupt requests and context data), thereby achieving data sharing and avoiding frequent data transfer between the main memory and the core; the coprocessor core is an auxiliary computing unit that is set up in conjunction with the main processing core, preloaded with the same simplified processing routines as the main processing core, and takes over the interrupt handling task when the main processing core is overloaded, ensuring that the interrupt response is not delayed.

[0108] The first step, during the initialization phase of the industrial intelligent control center system, involves loading simplified processing routines corresponding to the priority level into the local memory (e.g., L1 cache) of the processing cores based on the "interrupt priority-processing core" binding relationship. For example, a "safety event processing routine" is preloaded for core 0, which is bound to the first priority level (safety events). This routine only contains core logic such as emergency stop judgment and fault location, and its code length is kept within a small range (e.g., less than 4KB). A "time-sensitive event processing routine" is preloaded for core 1, which is bound to the second priority level (time-sensitive events), and contains necessary logic such as data verification and parameter calculation. Simultaneously, each coprocessor core (e.g., coprocessor cores 0-1 paired with core 0) is loaded with the same simplified processing routine as the corresponding main processing core to ensure seamless execution after task migration.

[0109] The second step involves the load monitoring module of the industrial intelligent control center collecting real-time data on the current load status of the processing cores before the cores execute simplified processing routines. This module uses hardware counters to track the CPU utilization of the processing cores (e.g., the percentage of instruction execution time per unit of time) and the number of interrupt tasks waiting in the task queue, combining this data with a preset algorithm to calculate the overall load value. For example, if the load monitoring module detects 85% CPU utilization and 3 waiting tasks for core 0, the overall load value for core 0 is calculated as 85% × 0.7 + (3 / 5) × 0.3 = 77.5% using the algorithm "Overall load value = CPU utilization × 0.7 + (number of waiting tasks / maximum number of tasks) × 0.3". Subsequently, the load monitoring module compares the overall load value with the dynamic load threshold of core 0 (e.g., preset to 80%) to determine whether load balancing needs to be initiated.

[0110] Thirdly, if the current load of the processing core does not exceed the dynamic load threshold (e.g., the overall load value of core 0 is 77.5% < 80% threshold), load balancing does not need to be initiated, and the processing core directly executes the pre-loaded simplified processing routine. If the current load exceeds the dynamic load threshold (e.g., the overall load value of core 0 is 85% > 80% threshold), the dynamic load balancing mechanism is triggered. At this time, the load scheduling module first identifies the coprocessor core that shares a high-speed cache with the processing core (e.g., core 0 corresponds to coprocessor core 0-1), and then copies the interrupt request and context data from the local storage area of ​​the main processing core to the storage area of ​​the coprocessor core through the internal data copying logic of the shared high-speed cache. Since the data is stored in the shared high-speed cache, the copying process does not need to access the system main memory, but only needs to be completed through the internal bus of the cache, which is extremely fast and ensures data consistency. For example, the interrupt request and context data (collision position, speed) of "robotic arm collision warning" in the shared cache of core 0 are copied to the shared cache partition of coprocessor core 0-1. After the copying is completed, the load scheduling module sends a "task start signal" to the coprocessor core.

[0111] Fourth, if load balancing is not required, the main processing core (such as core 0) directly reads the pre-loaded simplified processing routines from local memory, while simultaneously accessing the context data moved to local memory in step S4. For example, when core 0 executes the "safety event handling routine," it first reads the "robotic arm collision force value" and "safety threshold" from the context data, performs preset logical operations (whether the collision force value is greater than the safety threshold) and status judgments (whether it is a fatal collision). If the judgment result is "yes," it generates a digital output instruction (such as a "robotic arm emergency stop instruction"). If load balancing has been enabled, the coprocessor core (such as coprocessor core 0-1) reads the interrupt request, context data, and pre-loaded simplified processing routines from the shared cache, performs the same logical operations and status judgments as the main processing core, and generates the same drive instructions. For example, coprocessor core 0-1 executes the "safety event handling routine," generates a "robotic arm emergency stop instruction" based on the same context data, ensuring consistent interrupt handling results.

[0112] The fifth step involves the processing core (or coprocessor core) generating the drive instructions and then transmitting them to the industrial bus interface module. This module first encapsulates the drive instructions using a protocol (e.g., adding address and check fields according to the PROFINET protocol), and then sends the encapsulated instructions to the target industrial actuator via the industrial bus (e.g., the PROFINET bus). For example, a "robotic arm emergency stop command" is encapsulated as a PROFINET message and sent to the corresponding robotic arm controller via the industrial bus interface, ensuring the command arrives accurately and is executed.

[0113] In this embodiment, taking an automotive parts welding production line as an example: when the welding robot arm sends an interrupt request for "welding current over-limit" (safety event, first priority), the core 0 bound to the first priority first receives load monitoring. If the current load value of core 0 is 70% (below the 80% threshold), the "safety event handling routine" is executed directly. The "current current value 120A" and "safety threshold 100A" in the context data are read. After logical operation (120A>100A) and status judgment (belonging to fatal over-limit), a "welding robot arm emergency stop" digital command is generated and sent to the robot arm controller through the industrial bus interface. If the current load value of core 0 is 85% (exceeding the 80% threshold), load balancing is started. The interrupt request and context data are copied to the co-core 0-1, which executes the same routine and generates the same emergency stop command to ensure that the welding robot arm stops in time and avoids equipment damage or safety accidents.

[0114] In this embodiment, the step reduces routine loading delay by "preloading simplified processing routines" and avoids response delay caused by processing core overload by dynamic load balancing. This solves the problems of slow routine execution and core overload stagnation in traditional interrupt handling, ensures that drive instructions are generated and transmitted quickly, guarantees timely response of industrial execution components, further reduces the total interrupt response delay, and improves the real-time performance and reliability of the factory control system.

[0115] like Figure 2 The diagram shown is a functional block diagram of a low-latency interrupt handling system for an intelligent control center provided in an embodiment of this application.

[0116] The low-latency interrupt handling system 100 of the intelligent control center described in this application can be installed in an electronic device. Depending on the functions implemented, the low-latency interrupt handling system 100 of the intelligent control center may include an interrupt parsing module 101, a priority matching module 102, a path selection module 103, a data allocation module 104, and an instruction generation module 105. The module described in this application can also be referred to as a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and which are stored in the memory of the electronic device.

[0117] In this embodiment, the functions of each module / unit are as follows:

[0118] Interrupt parsing module 101 is used to parse the interrupt request received by the industrial intelligent control center and obtain the event type identifier carried in the interrupt request;

[0119] The priority matching module 102 is used to match the event type identifier to the corresponding interrupt priority based on a predefined event priority mapping table, wherein the event priority mapping table is pre-set according to the urgency of events and associated control logic in the industrial control scenario;

[0120] The path selection module 103 is used to select a hardware response path from a pre-allocated set of response paths according to the interrupt priority, wherein hardware response paths of different priorities are physically isolated.

[0121] The data allocation module 104 is used to allocate the interrupt request and its associated context data to the pre-bound processing core through the selected hardware response path.

[0122] Instruction generation module 105 is used by the processing core to execute a preloaded simplified processing routine corresponding to the interrupt priority, and generate drive instructions for controlling industrial actuators.

[0123] In the several embodiments provided in this application, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0124] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0126] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application.

[0127] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. A low-latency interrupt handling method for an intelligent control center, characterized in that, The method includes: Parse the interrupt request received by the industrial intelligent control center and obtain the event type identifier carried in the interrupt request; Based on a predefined event priority mapping table, the event type identifier is matched to the corresponding interrupt priority. The event priority mapping table is pre-set according to the urgency of events and associated control logic in the industrial control scenario, and includes: Set the priority of safety events related to equipment emergency stop and motion axis overtravel to the highest level; Set the priority of time-sensitive events related to periodic data acquisition and high-precision timed triggering to the second highest; Set the priority of regular events related to parameter configuration updates and logging to the lowest level; Based on the interrupt priority, a hardware response path is selected from a pre-allocated set of response paths, wherein hardware response paths of different priorities are physically isolated, including: If the matched interrupt priority is the highest priority, the first physical channel directly connected to the hardware interrupt controller inside the central processing unit is activated. The first physical channel is a metal wiring inside the chip that is independent of the system bus. If the matched interrupt priority is the second highest priority, then the second physical channel forwarded through the input / output memory management unit is enabled. The second physical channel is a physical line connected to the input / output memory management unit through pins on the chip package, and the signal transmission delay of the first physical channel is lower than that of the second physical channel. Assigning the interrupt request and its associated context data to a pre-bound processing core via a selected hardware response path includes: moving the context data from system memory to the local memory of the processing core via the memory access engine corresponding to the hardware response path; The processing core executes a preloaded simplified processing routine corresponding to the interrupt priority, generating drive instructions for controlling industrial actuators.

2. The low-latency interruption handling method for the intelligent control center as described in claim 1, characterized in that, The process of parsing the interrupt request received by the industrial intelligent control center and obtaining the event type identifier carried in the interrupt request includes: The event type identifier is extracted from the specified header field of the interruption request. The event type identifier is used to uniquely characterize the industrial equipment from which the interruption event originates and the nature of the event.

3. The low-latency interruption handling method for the intelligent control center as described in claim 1, characterized in that, The predefined event priority mapping table matches the event type identifier with the corresponding interrupt priority, including: Use the event type identifier as the query key to perform a matching query in the event priority mapping table and obtain the corresponding numeric priority number. The value of the priority number is positively correlated with the urgency of the interrupt priority.

4. The low-latency interruption handling method for the intelligent control center as described in claim 1, characterized in that, The processing core executes a preloaded simplified processing routine corresponding to the interrupt priority, generating drive instructions for controlling industrial actuators, including: Generate digital output commands or analog control commands, and send them to the industrial actuator via the industrial bus interface; The driving instructions are obtained by the simplified processing routine by accessing the context data and performing preset logical operations or state judgments.

5. The low-latency interruption handling method for the intelligent control center as described in claim 4, characterized in that, Before the processing core executes the preloaded simplified processing routine corresponding to its interrupt priority, the following is also included: Monitor the current load status of the processing core; When the current load state exceeds the dynamic load threshold preset for the processing core, the interrupt request and the context data are copied to the coprocessor core that shares a cache with the processing core. The preloaded simplified processing routines are executed by the coprocessor core.

6. A low-latency interrupt handling system for an intelligent control center, characterized in that, The system includes: The interrupt parsing module is used to parse the interrupt request received by the industrial intelligent control center and obtain the event type identifier carried in the interrupt request; A priority matching module is used to match the event type identifier to the corresponding interrupt priority based on a predefined event priority mapping table. The event priority mapping table is pre-set according to the urgency of events and associated control logic in the industrial control scenario, and includes: Set the priority of safety events related to equipment emergency stop and motion axis overtravel to the highest level; Set the priority of time-sensitive events related to periodic data acquisition and high-precision timed triggering to the second highest; Set the priority of regular events related to parameter configuration updates and logging to the lowest level; A path selection module is used to select a hardware response path from a pre-allocated set of response paths based on the interrupt priority, wherein hardware response paths of different priorities are physically isolated, including: If the matched interrupt priority is the highest priority, the first physical channel directly connected to the hardware interrupt controller inside the central processing unit is activated. The first physical channel is a metal wiring inside the chip that is independent of the system bus. If the matched interrupt priority is the second highest priority, then the second physical channel forwarded through the input / output memory management unit is enabled. The second physical channel is a physical line connected to the input / output memory management unit through pins on the chip package, and the signal transmission delay of the first physical channel is lower than that of the second physical channel. The data allocation module is used to allocate the interrupt request and its associated context data to a pre-bound processing core through a selected hardware response path, including: moving the context data from system memory to the local memory of the processing core through the memory access engine corresponding to the hardware response path; The instruction generation module is used by the processing core to execute a preloaded simplified processing routine corresponding to the interrupt priority, and generate drive instructions for controlling industrial actuators.

Images