A multi-core scheduling method and system for a building intelligent control system task resource feature sample library

Abstract

The application discloses a kind of multi-core scheduling method and system of building intelligent control system task resource feature sample library, belong to the technical field of building resource scheduling.Method includes: each typical building control task is sequentially run on each processor core, task resource demand vector, core capability feature vector and historical performance data are bound as sample entry, the set of all sample entries is stored as offline sample set into sample library;With offline sample set as baseline, calculate the deviation of task actual execution performance and sample library expected value, adjust matching weight;Update task resource demand vector, inject runtime state marker into sample library entry, update sample library;Based on sample library, respond to three types of events, such as new task arrival, emergency interruption above preset priority threshold, task running exception, generate the latest core state;Based on the latest core state, evaluate each core load rate distribution, output global load balancing instruction.The application improves resource utilization and long-term load balancing.

Description

Technical Field

[0001] This invention relates to the technical field of building resource scheduling, and more specifically, to a multi-core scheduling method and system for a task resource feature sample library of a building intelligent control system. Background Technology

[0002] Building control systems need to integrate various heterogeneous subsystems such as HVAC, lighting, and security, which communicate with each other via protocols such as RS-485 and BACnet / IP. Different types of control tasks have significantly different requirements for system resources: HVAC PID control loops have extremely high real-time requirements; lighting switching, while involving a large number of messages, has a higher tolerance for latency; and energy consumption analysis focuses on calculations with less I / O interaction.

[0003] Current building control systems primarily employ homogeneous or heterogeneous multi-core SoC architectures, both of which face task scheduling challenges. In heterogeneous multi-core SoC scenarios, each physical core exhibits inherent hardware differences in interrupt response latency, I / O bus bandwidth, and cache capacity. Traditional schedulers cannot perceive these differences in hardware capabilities, making it difficult to achieve global optimization in power consumption, latency, and control precision. In homogeneous multi-core SoC scenarios, although each core has identical hardware parameters, runtime state factors such as uneven on-chip heat distribution leading to differences in available frequency, different physical locations of I / O peripherals causing access latency differences, and different interrupt routing affinity causing response latency differences mean that the effective carrying capacity of each core for the same task is not actually equal. Traditional schedulers treat each core as a completely interchangeable equivalent resource, neither perceiving these runtime state differences nor utilizing them to optimize task allocation.

[0004] On heterogeneous multi-core platforms, different physical cores have inherent hardware differences in terms of interrupt response latency, I / O bus bandwidth, power consumption characteristics, etc. On homogeneous multi-core platforms, although the hardware parameters of each core are the same, runtime state differences such as differences in available frequency due to uneven on-chip heat distribution, differences in access latency due to different physical locations of I / O peripherals, and differences in response latency due to different interrupt routing affinity affect task execution performance.

[0005] The resource consumption patterns of each building subsystem task during runtime, such as I / O operation frequency, interrupt trigger frequency, and real-time latency, are different. However, traditional schedulers only allocate CPU time slices and do not collect or utilize these multi-dimensional resource characteristic information, resulting in an information gap between the actual resource requirements of the task and the scheduling decision.

[0006] Building systems exhibit drastically different load structures under various operating modes (such as weekday morning peak hours versus night shifts), and their operating intensity also varies significantly across different seasons. Traditional static priority or fixed core binding strategies cannot adapt to these changing scenarios. On multi-core platforms, this problem further manifests as the runtime state of each core (temperature, cache content, bus contention level) continuously drifting with load changes. The scheduler needs to perceive these changes in real time and dynamically adjust the mapping relationship between tasks and processor cores. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a multi-core scheduling method and system for a building intelligent control system task resource feature sample library. This method solves the technical problem that existing schedulers lack the ability to perceive and quantify the hardware differences of multi-core platforms, the multi-dimensional resource requirements of tasks, and changes in runtime states. As a result, the mapping between tasks and cores cannot be dynamically adjusted according to system mode, load, and inter-core states, leading to scheduling decisions that are out of touch with the actual situation.

[0008] The present invention adopts the following technical solution.

[0009] The first aspect of this invention proposes a multi-core scheduling method for a task resource feature sample library of a building intelligent control system, comprising the following steps: Each typical building control task is run sequentially on each processor core. For each typical building control task type and processor core number, task resource requirement vector, core capability feature vector, and historical performance data are collected. A hash index is established using task type and core number as keys. An initial matching weight is set for each sample entry based on historical performance data. The task resource requirement vector, core capability feature vector, and historical performance data are bound to the sample entry. The set of all sample entries is stored in the sample library as an offline sample set. Using the offline sample set as a baseline, after each scheduling execution, the deviation between the actual execution performance of the task and the expected value in the sample library is calculated, and the matching weight is adjusted; the task resource requirement vector is updated through a moving average mechanism, runtime state markers are injected into the sample library entries, and the sample library is updated. Based on the sample library, the system responds to three types of events: new task arrival, emergency interruption above a preset priority threshold, and task operation abnormality, and generates the latest core status. Based on the latest core status, the system evaluates the load distribution of each core and outputs a global load balancing instruction to implement multi-core scheduling of the building intelligent control system's task resource feature sample library.

[0010] Preferably, the generation of the kernel capability feature vector includes: The runtime status of each processor core is periodically read at a preset dynamic correction cycle. The runtime status includes core temperature, thermal throttling margin, current available frequency, L1 / L2 cache hit rate, interrupt queue depth, I / O bus utilization, and ready queue length. Based on the acquired runtime state, a dimension-by-dimensional linear scaling correction is performed on each dimension of the static capability vector generated by the benchmark test program, and the correction results are truncated at the boundary to generate a real-time kernel capability feature vector.

[0011] Preferably, the generation of the static capability vector includes: After the system completes its power-on self-test, benchmark test programs are injected into each processor core sequentially to collect raw hardware performance data. The raw hardware performance data includes interrupt response latency, I / O bus bandwidth, peripheral access latency, fixed-point computing throughput, and floating-point computing throughput. The I / O bus bandwidth, fixed-point computing throughput, and floating-point computing throughput are normalized. The two types of latency indicators, interrupt response latency and peripheral access latency, are normalized after taking the complement values ​​and then assembled into a static capability vector according to the dimensions. The static capability vector consists of the following dimensions: the first dimension is interrupt response capability, filled with the normalized result of interrupt response delay compensation; the second dimension is I / O bandwidth capability, filled with the normalized result of I / O bus bandwidth; the third dimension is peripheral access capability, filled with the normalized result of peripheral access delay compensation; the fourth dimension is fixed-point throughput capability, filled with the normalized result of fixed-point computation throughput; and the fifth dimension is floating-point throughput capability, filled with the normalized result of floating-point computation throughput.

[0012] Preferably, establishing the hash index includes: Using the tuple consisting of task type T and core number C as the key, the bucket number is calculated according to the hash function, expressed as follows: Hash(T 16 | C) mod M Where M is a prime number greater than the upper limit of the sample library capacity.

[0013] Preferably, the initial matching weight is set in the following way: For the same task type, the best historical performance of that task type on each processor core is taken as the benchmark. The matching weight of the best core is set to 1, and the matching weight of the other cores is set according to the ratio of the historical performance data of that core to the best historical performance data, and the ratio is less than 1.

[0014] Preferably, updating the task resource requirement vector using a moving average mechanism includes:

[0015] In the formula, This is the original task resource requirement vector obtained from statistics within the data collection window. This is the task resource requirement vector that has been fused in the previous cycle for this task in the sample library. This is the task resource requirement vector to be written back to the sample database after the current cycle update. This is a smoothing factor.

[0016] Preferably, based on the sample library, in response to three types of events—new task arrival, emergency interruption exceeding a preset priority threshold, and task execution abnormality—the latest kernel status is generated, including: When a new task arrives, the sample library is retrieved using the real-time core capability feature vector and the task resource requirement vector as the joint retrieval key. The fitness score is calculated according to the fitness score formula, and the core with the highest score is selected to perform the reading operation. For emergency interrupts above the preset priority threshold, skip the sample library search, directly query the interrupt response capability dimension in the core capability feature vector, hard bind the task to the processor core with the lowest interrupt latency and preempt it immediately; If a task malfunctions, the corresponding task and core combination will be downgraded and written to the sample database.

[0017] Preferred fit score It can be expressed by the following formula:

[0018] in, Let be the dimension of the task resource requirement vector. For the first Dimensional weights To match weights, Let be the core capability feature vector component of processor core c in the i-th dimension of the task resource requirement vector. Let be the task resource demand vector component of task T in the i-th dimension of the task resource demand vector.

[0019] Preferably, the assessment of the load distribution of each core includes: cache affinity retention assessment, inter-core temperature equalization assessment, and execution migration decision; Assess the load distribution across cores and output global load balancing commands, including: Perform a global scan at a set period to check the dwell time of each task on the current core. If the dwell time is less than the minimum dwell time threshold, remove the task and do not participate in this round of migration evaluation, and generate the first migration candidate set. Based on the first migration candidate set, the number of cache accesses and misses during the read cycle are used to calculate the cache hot page hit rate of each task on the core. Tasks with a hit rate higher than the hit threshold are preferentially retained on the current core, and tasks with a hit rate lower than the hit threshold are marked as having weak cache affinity. A second migration candidate set containing the weak affinity markers is then generated. Monitor the temperature difference between cores. When the temperature difference exceeds the preset temperature difference threshold, based on the second migration candidate set, select tasks with a cache hot page hit rate lower than the threshold and no persistent state from cores whose core temperature difference with the lowest core temperature exceeds the temperature difference threshold and whose load rate exceeds the preset load threshold as the tasks to be migrated. Record the core where the task is currently located as the source core, and determine the core whose core temperature difference with the lowest core temperature does not exceed the temperature difference threshold and whose load rate does not exceed the preset load threshold as the target core. Then migrate the tasks to be migrated from the source core to the target core. Based on the tasks to be migrated, source cores, and target cores determined in the second migration candidate set, a global load balancing migration instruction is generated.

[0020] The second aspect of this invention proposes a multi-core scheduling system for a building intelligent control system task resource feature sample library, which runs the multi-core scheduling method for the building intelligent control system task resource feature sample library described in the first aspect, including: Offline sample set generation is used to run each typical building control task sequentially on each processor core. For each typical building control task type and processor core number, task resource requirement vector, core capability feature vector, and historical performance data are collected. A hash index is established with the task type and core number as the key. An initial matching weight is set for each sample entry based on the historical performance data. The task resource requirement vector, core capability feature vector, and historical performance data are bound to the sample entry. The set of all sample entries is stored in the sample library as an offline sample set. The sample library update module is used to calculate the deviation between the actual execution performance of the task and the expected value of the sample library after each scheduling execution, based on the offline sample set as the baseline, and adjust the matching weight; update the task resource requirement vector through the moving average mechanism, inject runtime status markers into the sample library entries, and update the sample library. The latest kernel status generation module is used to generate the latest kernel status based on the sample library in response to three types of events: new task arrival, emergency interruption above a preset priority threshold, and task operation abnormality. The scheduling module is used to evaluate the load distribution of each core based on the latest core status and output global load balancing instructions to implement multi-core scheduling of the building intelligent control system task resource feature sample library.

[0021] The third aspect of this invention proposes an Internet of Things (IoT) gateway that uses the method described in the first aspect to perform multi-core scheduling of the task resource feature sample library of the building intelligent control system.

[0022] A fourth aspect of the present invention provides a terminal comprising a processor and a storage medium; the storage medium is used to store instructions; the processor is used to operate according to the instructions to perform the steps of the method according to the first aspect.

[0023] A fifth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0024] Compared with the prior art, the present invention has at least the following beneficial effects: First, the homogeneous-heterogeneous multi-core adaptive matching scheduling based on a unified feature vector reduces the response latency of critical control loops and improves resource utilization. Addressing the issue that the scheduler cannot perceive differences in core capacity and the multidimensional resource requirements of tasks, this invention measures hardware indicators on the core capability side using a standard micro-benchmark and integrates runtime dynamic states, normalizing them into a unified capability feature vector. On the task side, a hardware performance monitoring unit extracts resource consumption profiles such as I / O intensity, interrupt frequency, and cache sensitivity within the acquisition window. These two vectors together form the retrieval key in the sample library. The scheduler performs matching using a unified interface, eliminating the need to perceive underlying architecture differences, and simultaneously resolving the problems of core mismatch between heterogeneous platforms and tasks, as well as the uneven utilization of equivalent cores on homogeneous platforms. Therefore, interrupt-sensitive tasks are precisely assigned to processor cores with optimal interrupt response latency, avoiding response timeouts caused by improper core selection and ensuring the real-time performance of critical control loops. At the same time, I / O-intensive tasks are assigned to cores with low interrupt latency, and compute-intensive tasks are assigned to cores with high compute throughput. The temperature status, cache content, and bus contention level of each core are monitored in real time, guiding tasks to the core with the best current effective carrying capacity, thus avoiding the load imbalance phenomenon where multiple tasks are concentrated on the same core while other cores are idle.

[0025] Second, the scheduling strategy based on runtime feedback loop continuously evolves adaptively, enabling the system to adapt to changes in building operating scenarios. Addressing the issue that fixed scheduling strategies cannot keep up with building scenario changes and long-term load drift, this method collects execution performance feedback from each task on each core during the offline phase to construct an initial sample library. After online execution, the scheduling results are written back to the sample library, negative feedback items are automatically downweighted, and task profiles are continuously integrated with the latest data through exponential moving averages. Simultaneously, hardware state change markers are injected into the sample library, allowing the upper-layer scheduler to automatically perceive and adapt to environmental changes, achieving closed-loop evolution without manual intervention. Thus, by automatically identifying scenarios and switching corresponding scheduling strategy templates, combined with an online sample library update mechanism, the system gradually adapts to the drift of the current operating load. Runtime state dimensions (core temperature distribution, cache heat distribution) are incorporated into scenario matching as part of the scenario snapshot, enabling the scheduler to capture differences in scheduling strategies under the same load mode, further improving the accuracy of scheduling decisions.

[0026] Third, the event-driven immediate and cache-sensitive periodic rebalancing dual-path linkage scheduling balances immediate response determinism with long-term load balancing. Addressing the issue that pure periodic scheduling cannot balance the determinism of emergency event response with long-term load balancing, this invention designs a dual-path linkage mechanism between the event-driven immediate path and the low-frequency periodic rebalancing path: Emergency tasks trigger the retrieval and allocation of the optimal core, emergency interrupts are hard-bound to the core with the lowest latency for direct preemption, and abnormal tasks are automatically downgraded; the periodic path evaluates the cache affinity retention value and senses the temperature balance between cores, prioritizing the migration of lightweight tasks, balancing immediate response determinism with long-term load balancing, and avoiding ineffective migration and localized overheating and frequency reduction. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating the overall process of the multi-core scheduling method for intelligent building control in this invention. Figure 2 This is a diagram illustrating the overall architecture of the multi-core scheduling method for intelligent building control in this invention. Figure 3 This is a flowchart of the feature vector modeling process of the present invention; Figure 4 This is a flowchart illustrating the construction and maintenance process of the sample library for this invention. Figure 5 This is a flowchart of the dual-path linkage scheduling execution process of event-driven and periodic rebalancing in this invention; Detailed Implementation To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this invention. The embodiments described in this application are merely some embodiments of this invention, and not all embodiments. Based on the spirit of this invention, other embodiments obtained by those skilled in the art without creative effort are all within the protection scope of this invention.

[0028] like Figure 1 As shown, Embodiment 1 of the present invention proposes a multi-core scheduling method for a task resource feature sample library of a building intelligent control system, including: Step 1: Run each typical building control task sequentially on each processor core. For each group of typical building control task types and processor core numbers, collect task resource requirement vectors, core capability feature vectors, and historical performance data. Build a hash index using task type and processor core number as keys. Set initial matching weights for each sample entry based on historical performance data. Bind the task resource requirement vector, core capability feature vector, and historical performance data into sample entries. Store the set of all sample entries as an offline sample set in the sample library.

[0029] In a preferred but non-limiting embodiment of the present invention, step 1 includes: Step 1.1: After the system is powered on, the benchmark test program is injected into each processor core to collect the raw hardware indicators of the benchmark test program. After normalization processing, a static capability vector is generated.

[0030] More preferably, step 1.1 includes: Step 1.1.1: After the system power-on self-test is completed, the benchmark test program is injected into each processor core in sequence to collect raw hardware indicator data. The raw hardware indicator data includes interrupt response latency, I / O bus bandwidth, peripheral access latency, fixed-point computing throughput and floating-point computing throughput.

[0031] During the static measurement phase, benchmark programs are sequentially injected into each processor core upon system startup. These benchmark programs include interrupt latency testing, DMA channel bandwidth testing, peripheral addressing latency testing, and fixed-point and floating-point throughput testing. Interrupt latency testing records the time difference between interrupt triggering and the execution of the first instruction in the handler function; DMA channel bandwidth testing measures the amount of data transferred per unit time; and peripheral addressing latency testing measures the read / write response time for various peripherals on buses such as RS-485 and BACnet / IP.

[0032] The raw hardware performance data collected by the benchmark program includes interrupt response latency, I / O bus bandwidth, peripheral access latency, and computational throughput. A processor core refers to the physical CPU core within a multi-core SoC chip that independently executes instruction pipelines.

[0033] Step 1.1.2: Normalize the I / O bus bandwidth, fixed-point computing throughput, and floating-point computing throughput. Normalize the two types of latency indicators, interrupt response latency and peripheral access latency, after taking the complement values ​​and generating standardized values. Assemble the standardized values ​​by dimension to generate a static capability vector. The static capability vector consists of the following dimensions: the first dimension is interrupt response capability, filled with the normalized result of interrupt response delay compensation; the second dimension is I / O bandwidth capability, filled with the normalized result of I / O bus bandwidth; the third dimension is peripheral access capability, filled with the normalized result of peripheral access delay compensation; the fourth dimension is fixed-point throughput capability, filled with the normalized result of fixed-point computation throughput; and the fifth dimension is floating-point throughput capability, filled with the normalized result of floating-point computation throughput.

[0034] The collected raw hardware index data is normalized to [0,1] by min-max to form a static capability vector, in which the delay index is complemented so that the larger the value of each dimension, the stronger the capability.

[0035] Step 1.2: In the later stages of system startup and before entering online mode, the static capability vector is corrected to a real-time core capability feature vector, and a task resource requirement vector is generated synchronously.

[0036] Further preferably, step 1.2 includes: Step 1.2.1: Periodically read the runtime status of each processor core with a preset dynamic correction period of 100ms~1s. The runtime status includes core temperature, thermal throttling margin, current available frequency, L1 / L2 cache hit rate, interrupt queue depth, I / O bus utilization, and ready queue length.

[0037] During the dynamic correction phase, the system periodically reads the temperature sensor values ​​of each processor core, as well as runtime status such as thermal limiting margin, cache hit rate, and current interrupt queue depth.

[0038] Step 1.2.2: Based on the runtime state obtained in Step 1.2.1, perform a dimension-by-dimensional linear scaling correction on each dimension of the static capability vector, truncate the correction results at the boundary, and generate the kernel capability feature vector.

[0039] Table 1 Runtime State Correction Static Capability Vector Table

[0040] In the table, , , , , These represent the 1st, 2nd, 3rd, 4th, and 5th dimensions of the static capability vector, respectively. , , , , These represent the 1st, 2nd, 3rd, 4th, and 5th dimensions of the static capability vector after correction.

[0041] For the first dimension (interruption response capability), multiply by a linear inverse proportional relationship. The maximum value among 0, hour, The deeper the interrupt queue, the lower the corrected interrupt response capability will be. When the queue is full ( When this occurs, the dimension is corrected to 0, indicating that the core is no longer capable of handling new interrupt-sensitive tasks and the newly arrived interrupt-sensitive tasks should be assigned to other cores; for the second dimension (I / O bandwidth capability), multiplied by The maximum value in the sum of zeros; multiply by the third dimension (peripheral access capability). The maximum value in 0; multiply by the fourth dimension (fixed-point throughput). , At that time For the 5th dimension (floating-point throughput), multiply by , At that time .

[0042] In the formula, Indicates the interrupt queue depth. Indicates the maximum queue capacity. Indicates I / O bus utilization. Indicates the currently available frequency. Indicates the rated frequency.

[0043] Step 1.2.3: Using hardware performance counters and kernel tracepoints, collect resource consumption frequency data for each typical task within the set collection window. Normalize the collected resource consumption frequency data and assemble it by dimension to generate a task resource requirement vector. The resource consumption frequency data includes the number of I / O operations, interrupt trigger frequency, and L1 / L2 cache miss rate for each task.

[0044] Step 1.3: The typical building control tasks such as HVAC PID adjustment, scene switching, and energy consumption acquisition are sequentially polled and run on each processor core to collect historical performance data (execution time, interrupt response latency, throughput, etc.) for each combination (task type T, core number C).

[0045] Step 1.4: Using the task type of a typical building control task and the core number of the processor core as keys, a hash index is established using a hash function, and an initial matching weight is set for each sample.

[0046] For the same task type T, the optimal historical performance of that task type on each processor core is taken as the benchmark. An initial matching weight is calculated for the combination of the task type and the core number of the processor core for each typical building control task. The matching weight of the optimal processor core is set to 1, and the matching weight of the other processor cores is set according to the ratio of the historical performance data of the core to the optimal historical performance data of all cores for the same task, with the ratio being less than 1.

[0047] The index data uses a hash table as the primary index, with the key being a tuple consisting of the task type and the core number. When calculating the fit score, for a given task type, all core entries corresponding to that task type are traversed and their scores are compared, and the core with the highest score is selected.

[0048] The system is configured with a non-volatile storage area to store sample database entries. Each sample record contains three items: the task resource requirement vector, the kernel capability feature vector, and the historical performance data of the corresponding task. After a raw sample record is collected, its task type T and kernel number C are extracted to form the index key K=(T,C). The bucket number is calculated using the hash function Hash(T<<16|C)modM (M is a prime number greater than the upper limit of the sample database capacity). The record is then attached to the tail of the linked list of the corresponding hash bucket, completing the index construction. This allows each sample entry to be located in O(1) complexity through this index.

[0049] During the online evolution phase, each writeback (weight reduction, vector fusion, state flag injection) updates the index structure in place after locating the entry by K, without needing to rebuild the index structure. During scheduling and retrieval, the bucket is located by K hash and the bucket list is traversed (the number of entries in the bucket is equal to the number of cores corresponding to the task type, typically 2-8, and the overhead is negligible). The core with the highest ScoreT and C is selected for allocation.

[0050] Step 1.5: Bind sample entries and write them into the sample library to form an offline sample set.

[0051] The task resource requirement vector, core capability feature vector, historical performance data, matching weight, and runtime status flag are bound together as a single sample entry and stored in the sample library to form an offline sample set. All entries are written to a non-volatile storage area (or a dedicated memory structure). The sample library capacity limit and eviction policy are configured: entries with the lowest weight are evicted first; if weights are equal, the earliest inserted entry is evicted first. When the sample library is full, a weight-based eviction policy is used to evict the entry with the lowest weight in the current sample library. If multiple entries have the lowest weight, the entry with the earliest insertion time is evicted first. This policy directly reuses the weight mechanism described below in this application; low-weight entries are those that have been proven to perform poorly or have not been validated for a long time.

[0052] After the offline sample set is built, the system switches to online mode, and the sample library enters a state of continuous evolution (online write-back, weight reduction, and vector fusion are all updated in place with the same hash key, and the index structure is not rebuilt).

[0053] Step 2: After the system switches to online operation mode, using the offline sample set generated in Step 1 as the baseline, after each scheduling execution, the deviation between the actual execution performance of the task and the expected value of the corresponding entry in the sample library is calculated, and the matching weight is adjusted. At the same time, the task resource demand vector is updated by integrating the data from the latest acquisition window through the moving average mechanism, and the runtime status markers such as I / O bus utilization and nuclear temperature change of the sample library entries are updated to generate a dynamically and continuously updated sample library.

[0054] In a preferred but non-limiting embodiment of the present invention, step 2 includes: Step 2.1, in the online evolution phase, after each scheduling execution, the deviation between the actual execution performance of the task and the expected value of the corresponding entry in the sample library is calculated. When the deviation exceeds the preset deviation threshold of 20%, the matching weight of the corresponding sample entry is multiplied by a preset decay coefficient of 0.1~0.3 to automatically reduce the matching weight. The lower limit of the weight is set to 0.1 to prevent the entry from becoming completely invalid. When the performance is good for 3~5 consecutive preset times, the weight is increased by a fixed step size, and the adjusted weight value is output so that the entry can re-participate in scheduling after the runtime state is restored.

[0055] Step 2.2 employs a moving average mechanism, fusing statistical data from the most recent data collection window with historical data to update the task resource requirement vector, enabling the vector to track the long-term behavioral drift of the task. Let... This is the original task resource requirement vector obtained from statistics within the data collection window. This is the task resource requirement vector that has been fused in the previous cycle for this task in the sample library. Let the task resource requirement vector be the one written back to the sample database after the current period update. Then the moving average update formula is:

[0056] In the formula, α is a smoothing factor used to balance the proportion of historical task resource demand vectors to the latest task resource demand vectors, so that the vectors gradually track the long-term behavioral drift of tasks. The present invention uses a value of 0.2, that is, new data accounts for 20, which is suitable for the steady-state operation of most building control tasks. It can track the gradual drift of the task without being excessively affected by the fluctuation of a single acquisition.

[0057] The task resource requirement vector continuously integrates data from the most recent acquisition window using a moving average mechanism, enabling the vector to gradually track the long-term behavioral drift of the task.

[0058] Step 2.3 involves real-time monitoring of runtime status, such as I / O bus utilization and core temperatures. When changes in runtime status exceed preset thresholds, the latest runtime status is injected into the runtime fields of relevant entries in the sample library. This enables subsequent searches and scenario matching to automatically acquire the latest status and adjust scheduling preferences, achieving closed-loop evolution without manual intervention. The real-time updates to the sample library provide a continuous and reliable decision-making basis for coordinated scheduling.

[0059] Step 2.4: When the sample library reaches its capacity limit, based on the weight values ​​output in Step 2.1, the entry with the lowest weight is eliminated (if the weights are the same, the earliest inserter is eliminated), and a new entry containing the updated weight, the updated task resource requirement vector, and the runtime state is written, thus producing a continuously evolving sample library.

[0060] Step 3: Based on the continuously updated sample library from Step 2, respond to three types of events: new task arrival, high-priority emergency interruption, and task execution abnormality, and generate the latest kernel status.

[0061] In a preferred but non-limiting embodiment of the present invention, step 3 includes: Step 3.1: When a new task arrives, retrieve the corresponding task type entry from the sample database. For each dimension i of the task resource requirement vector, calculate the degree to which the kernel capability feature vector satisfies that dimension. , Let be the core capability feature vector component of processor core c in the i-th dimension of the task resource requirement vector. Let be the task resource demand vector component of task T in the i-th dimension of the task resource demand vector.

[0062] After weighted summation, multiply by the matching weight of that item to obtain the fit score. .

[0063] Compatibility rating It can be expressed by the following formula:

[0064] in, Let be the dimension of the task resource requirement vector. For the first Dimensional weights To match weights, Let be the core capability feature vector component of processor core c in the i-th dimension of the task resource requirement vector. Let be the task resource demand vector component of task T in the i-th dimension of the task resource demand vector.

[0065] Select the kernel with the highest calculated score as the optimal kernel, perform the read operation, and then perform task allocation.

[0066] Step 3.2: When a high-priority emergency interrupt (such as a fire alarm or security intrusion detection) arrives, skip the sample library search process, directly query the interrupt response capability dimension in the core capability feature vector, hard bind the task to the processor with the lowest interrupt latency, and immediately preempt the low-priority task currently executing on the core.

[0067] Step 3.3: When a task runs abnormally (timeout or error code is returned), the corresponding task and core combination is downgraded and written to the sample library, automatically reducing the matching weight of the corresponding (task, core) combination entry in the sample library.

[0068] The execution results of steps 3.1 to 3.3 above (including the binding timestamp after the new task is assigned, the kernel status change after the emergency interruption, and the weight update after the abnormal weight reduction) together constitute the latest kernel status and are written into the shared sample library.

[0069] Step 4: Read the latest core status generated in Step 3 from the shared sample library, evaluate the load distribution of each core, and output the global load balancing command.

[0070] In a preferred but non-limiting embodiment of the present invention, step 4 includes: Step 4.1, performing minimum dwell time verification, includes: reading the latest kernel state generated in step 3 from the shared sample library, performing a global scan at a set period, and checking the dwell time of each task on the current kernel. If the dwell time is less than the minimum dwell time threshold, the task is removed and will not participate in this round of migration evaluation, generating a set of transferable candidates.

[0071] Step 4.2, Cache affinity retention assessment: The cache access count and miss count within the cycle are read using hardware performance counters. The cache hot page hit rate of each task on the current core is calculated (hit rate = 1 - number of misses / number of accesses). Tasks with a hit rate higher than the hit threshold are preferentially retained on the current core (to avoid cache cold start overhead). Tasks with a hit rate lower than the threshold are marked as having a cache hot page hit rate lower than the hit threshold and are included in the migration candidate set. This hit rate is only used as the migration judgment threshold for this step and does not participate in the fit score calculation. Tasks with a hit rate higher than this value are considered to have their working set already resident in the cache and have high migration overhead, and are preferentially retained on the current core.

[0072] During deployment and debugging, each task is run in a stable state on each core, and its steady-state cache hit rate is measured; the median of the hit rates of each task is taken as the hit threshold. Steady-state determination condition: within 5 consecutive acquisition windows (50ms per window, 250ms in total), the difference between the maximum and minimum hit rates is less than 5% of the average.

[0073] Step 4.3, Assessment of internuclear temperature isostatics: Monitor the current temperature of each processor core and calculate the temperature difference between cores. If the temperature difference exceeds a preset threshold (set to 1 / 3 to 1 / 2 of the difference between the full-load steady-state temperature and the idle temperature), tasks on the processor core that have been marked as having a cache hot page hit rate no greater than the threshold and no persistent state are identified as potential migration targets and prepared for migration. Temperature steady-state determination: Within three consecutive acquisition windows (500ms per window, 1.5s in total), the temperature change rate of each core is less than 0.5℃ / window.

[0074] Step 4.4 combines the evaluation results of Steps 4.2 and 4.3 and outputs a global load balancing migration instruction. This instruction migrates tasks with a cache hot page hit rate of no more than a threshold and no persistent state on the processor core to a core where the difference between the core temperature and the lowest core temperature does not exceed a temperature difference threshold and the load rate does not exceed a preset load threshold. At the same time, the scheduling results generated in this step (actual execution time, whether there are any abnormalities, and the performance after migration) are fed back to Step 2 to update the matching weights of the corresponding sample entries, thus completing the closed-loop control of scheduling-feedback-optimization.

[0075] The cache hit rate is only used as a threshold for migration judgment in this step and is not included in the adaptation score calculation in step 3.1.

[0076] During normal system operation, the coordinated scheduling execution module, based on established feature vectors and a continuously evolving sample library, employs a dual-path mechanism that combines event-driven immediate paths with low-frequency periodic rebalancing paths. Its execution flow is as follows: Figure 5 As shown. Here, there is a minimum task residency time. After each task is bound to a core, its most recent binding timestamp is recorded. The event-driven path updates the timestamp of a task immediately after scheduling a new task or migrating an abnormal task. During scanning, the low-frequency rebalancing path first checks the residency time of each candidate migration task on the current core. If the residency time is less than the minimum residency time threshold, the task does not participate in the migration evaluation of this rebalancing and skips this round of scanning. It is only included in the migration candidate after the residency time reaches the threshold in the next cycle.

[0077] The low-frequency periodic rebalancing path performs a global load balancing scan at set intervals: First, it assesses the current load distribution of each core and calculates the cache hot page hit rate of each task on the homogeneous platform. Tasks with a hit rate higher than a threshold are preferentially retained on the current core to avoid cache cold start overhead caused by migration. When the temperature difference between cores exceeds a threshold, tasks with weak cache affinity and no persistent state are selected from the higher-temperature core and migrated to the lower-temperature core for execution, thereby eliminating invalid migrations and avoiding frequency degradation caused by local overheating. Both paths share the same sample library, and the demotion records written by the event-driven path are immediately visible in the periodic rebalancing path, ensuring consistency in decisions between the two paths.

[0078] The threshold in this application is written once during deployment and remains unchanged during operation without online automatic fine-tuning. This is intentional; frequent threshold drift would trigger repeated triggering of the periodic rebalancing path and repeated task migration, which would reduce system stability. When building load characteristics change significantly, maintenance personnel should trigger a re-debugging process to remeasure and update the threshold using the method described above.

[0079] Consult the chip datasheet to obtain the thermal throttling trigger temperature, full-load steady-state temperature, and no-load temperature. Set the threshold to 1 / 3 to 1 / 2 of (full-load steady-state temperature - no-load temperature) so that the high-temperature core can cool down to a range far from the thermal throttling trigger temperature after migrating out of the task, which ensures heat dissipation benefits and avoids frequent migration. After the two thresholds are determined in the above way during the system deployment and debugging phase, they are written into the configuration and remain unchanged during operation. If the building load characteristics change significantly (such as the change of seasons causing changes in the load of the HVAC system), they can be readjusted by the operation and maintenance personnel.

[0080] After the static capability vectors and offline sample set are established, the system immediately switches to online operation mode. For example... Figure 2The top layer consists of building subsystems (HVAC, lighting, and security); the middle layer consists of communication protocols; the core layer consists of a dual-path scheduling mechanism, with the feature acquisition and vector module on the left, the sample library management module in the middle, and the linkage scheduling execution module on the right; and the bottom layer consists of multi-core controller hardware and performance monitoring interfaces.

[0081] like Figure 3 The left branch collects static hardware metrics (interrupt latency, DMA bandwidth, etc.) and dynamic states (temperature, cache hit rate, etc.); the right branch uses hardware performance counters and tracepoints to collect task behavior statistics (I / O, interrupts, cache misses). Finally, the two are merged to generate a kernel capability feature vector and a task resource requirement vector for joint decision-making. Regarding the calculation logic, the implementation method is given in the main body of this application: within a set collection window, the number of I / O operations, interrupt trigger frequency, and L1 / L2 cache miss rate for each task are collected using hardware performance counters and kernel tracepoints, and after normalization, a multi-dimensional task resource requirement vector is formed. Figure 3 The statistical and normalization processing nodes within the data acquisition window together constitute a complete transformation process, corresponding to the statistical analysis of the original text and the normalized processing steps, respectively.

[0082] Regarding dimension mapping: The number of I / O operations, interrupt trigger frequency, and L1 / L2 cache miss rate listed in the text correspond to each dimension of the multidimensional task resource requirement vector. Each collected result is normalized and used as a component of the vector.

[0083] like Figure 4 In the offline phase, an initial sample set is generated through a benchmark program; in the online phase, the matching weights are dynamically adjusted through deviation calculation (if the deviation is large, the weight is reduced), and the vector is updated by combining the moving average, ultimately forming a closed-loop evolution. The automatic weight reduction when the deviation exceeds the threshold is as described in the original text. After each scheduling execution, the sample library management module calculates the deviation between the actual execution performance and the expected value of the corresponding entry in the sample library. Entries with deviations exceeding the set threshold automatically have their matching weights reduced, i.e., this is done after each scheduling execution.

[0084] The moving average fusion vector, which is the task resource requirement vector in the original text, continuously merges the data from the most recent acquisition window using a moving average mechanism, allowing the vector to gradually track the long-term behavioral drift of the task. This is done continuously according to the acquisition window.

[0085] These two processes are neither sequential nor performed as a single atomic operation; rather, they are carried out separately: weight reduction occurs after the scheduling execution is completed, while vector fusion continues according to the acquisition window.

[0086] like Figure 5The top section represents the trigger sources (new tasks, emergency interruptions, exceptions, periodic events); the middle section is the decision engine (including retrieval, load balancing scanning, cache hot page evaluation, and temperature difference evaluation); and the bottom section represents the execution actions (core allocation, task migration, and rescheduling). Regardless of the core load rate, tasks with a hit rate higher than the threshold are preferentially retained within the current core rules to avoid cache cold start overhead caused by migration. Only tasks with weak cache affinity are selected for migration. The original text establishes the order of priority by retaining high affinity and only migrating weak affinity, thus avoiding direct conflict between the two conditions. Instead of using a comprehensive cost function to handle the relationship between the two, the order is established through the above rules. When there is a conflict between load rate and cache affinity, the cache affinity protection rules take precedence, and high affinity tasks are not migrated.

[0087] To illustrate the specific effects of the method proposed in this invention, the following specific embodiments are provided: Taking a building HVAC PID control loop as an example, the complete scheduling process is illustrated as follows: After an HVAC PID task arrives, the event-driven path immediately extracts the resource requirement vector of the task (high I / O density, high interrupt frequency, medium cache sensitivity), retrieves the current capability feature vectors of all cores in the sample library, and selects the core with the highest interrupt response latency score for allocation based on the sample library's suitability retrieval. During task execution, the feature acquisition module continuously counts the actual resource consumption within the acquisition window, and the online evolution module writes the feedback data back to the sample library using a moving average mechanism. After each unit cycle, the rebalancing path triggers a global scan. If the current load rate of the core is low and the cache hot page hit rate is good, its binding relationship remains unchanged; if the core's temperature is detected to be significantly higher than other cores and the PID task's cache affinity is within a transferable range, it is migrated to a core with a lower temperature, balancing real-time performance and thermal balance.

[0088] Embodiment 2 of this invention proposes a multi-core scheduling system for a building intelligent control system task resource feature sample database, which runs the multi-core scheduling method for a building intelligent control system task resource feature sample database described in Embodiment 1, including: Offline sample set generation is used to run each typical building control task sequentially on each processor core. For each typical building control task type and processor core number, task resource requirement vector, core capability feature vector, and historical performance data are collected. A hash index is established with the task type and core number as the key. An initial matching weight is set for each sample entry based on the historical performance data. The task resource requirement vector, core capability feature vector, and historical performance data are bound to the sample entry. The set of all sample entries is stored in the sample library as an offline sample set. The sample library update module is used to calculate the deviation between the actual execution performance of the task and the expected value of the sample library after each scheduling execution, based on the offline sample set as the baseline, and adjust the matching weight; update the task resource requirement vector through the moving average mechanism, inject runtime status markers into the sample library entries, and update the sample library. The latest kernel status generation module is used to generate the latest kernel status based on the sample library in response to three types of events: new task arrival, emergency interruption above a preset priority threshold, and task operation abnormality. The scheduling module is used to evaluate the load distribution of each core based on the latest core status and output global load balancing instructions to implement multi-core scheduling of the building intelligent control system task resource feature sample library.

[0089] Embodiment 3 of the present invention proposes an Internet of Things gateway, which uses the method described in Embodiment 1 to perform multi-core scheduling of the task resource feature sample library of the building intelligent control system.

[0090] Embodiment 4 of the present invention provides a terminal, including a processor and a storage medium; the storage medium is used to store instructions; the processor is used to perform operations according to the instructions to execute the steps of the method according to Embodiment 1.

[0091] Embodiment 5 of the present invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in Embodiment 1.

[0092] The beneficial effects of this invention are compared with those of the prior art: First, the homogeneous-heterogeneous multi-core adaptive matching scheduling based on a unified feature vector reduces the response latency of critical control loops and improves resource utilization. Addressing the issue that the scheduler cannot perceive differences in core capacity and the multidimensional resource requirements of tasks, this invention measures hardware indicators on the core capability side using a standard micro-benchmark and integrates runtime dynamic states, normalizing them into a unified capability feature vector. On the task side, a hardware performance monitoring unit extracts resource consumption profiles such as I / O intensity, interrupt frequency, and cache sensitivity within the acquisition window. These two vectors together form the retrieval key in the sample library. The scheduler performs matching using a unified interface, eliminating the need to perceive underlying architecture differences, and simultaneously resolving the problems of core mismatch between heterogeneous platforms and tasks, as well as the uneven utilization of equivalent cores on homogeneous platforms. Therefore, interrupt-sensitive tasks are precisely assigned to processor cores with optimal interrupt response latency, avoiding response timeouts caused by improper core selection and ensuring the real-time performance of critical control loops. At the same time, I / O-intensive tasks are assigned to cores with low interrupt latency, and compute-intensive tasks are assigned to cores with high compute throughput. The temperature status, cache content, and bus contention level of each core are monitored in real time, guiding tasks to the core with the best current effective carrying capacity, thus avoiding the load imbalance phenomenon where multiple tasks are concentrated on the same core while other cores are idle.

[0093] Second, the scheduling strategy based on runtime feedback loop continuously evolves adaptively, enabling the system to adapt to changes in building operating scenarios. Addressing the issue that fixed scheduling strategies cannot keep up with building scenario changes and long-term load drift, this method collects execution performance feedback from each task on each core during the offline phase to construct an initial sample library. After online execution, the scheduling results are written back to the sample library, negative feedback items are automatically downweighted, and task profiles are continuously integrated with the latest data through exponential moving averages. Simultaneously, hardware state change markers are injected into the sample library, allowing the upper-layer scheduler to automatically perceive and adapt to environmental changes, achieving closed-loop evolution without manual intervention. Thus, by automatically identifying scenarios and switching corresponding scheduling strategy templates, combined with an online sample library update mechanism, the system gradually adapts to the drift of the current operating load. Runtime state dimensions (core temperature distribution, cache heat distribution) are incorporated into scenario matching as part of the scenario snapshot, enabling the scheduler to capture differences in scheduling strategies under the same load mode, further improving the accuracy of scheduling decisions.

[0094] Third, the event-driven immediate and cache-sensitive periodic rebalancing dual-path linkage scheduling balances immediate response determinism with long-term load balancing. Addressing the issue that pure periodic scheduling cannot balance the determinism of emergency event response with long-term load balancing, this invention designs a dual-path linkage mechanism between the event-driven immediate path and the low-frequency periodic rebalancing path: Emergency tasks trigger the retrieval and allocation of the optimal core, emergency interrupts are hard-bound to the core with the lowest latency for direct preemption, and abnormal tasks are automatically downgraded; the periodic path evaluates the cache affinity retention value and senses the temperature balance between cores, prioritizing the migration of lightweight tasks, balancing immediate response determinism with long-term load balancing, and avoiding ineffective migration and localized overheating and frequency reduction.

[0095] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0096] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0097] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0098] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0099] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A multi-core scheduling method for a task resource feature sample library of a building intelligent control system, characterized in that, Includes the following steps: Each typical building control task is run sequentially on each processor core. For each typical building control task type and processor core number, task resource requirement vector, core capability feature vector, and historical performance data are collected. A hash index is established using task type and core number as keys. An initial matching weight is set for each sample entry based on historical performance data. The task resource requirement vector, core capability feature vector, and historical performance data are bound to the sample entry. The set of all sample entries is stored in the sample library as an offline sample set. Using the offline sample set as a baseline, after each scheduling execution, the deviation between the actual execution performance of the task and the expected value in the sample library is calculated, and the matching weight is adjusted accordingly. The task resource requirement vector is updated by using a moving average mechanism, and runtime state tags are injected into the sample library entries to update the sample library. Based on the sample library, the latest kernel status is generated in response to three types of events: new task arrival, emergency interruption above a preset priority threshold, and task operation abnormality. Based on the latest core status, assess the load distribution of each core and output a global load balancing command to implement multi-core scheduling of the building intelligent control system's task resource feature sample library.

2. The multi-core scheduling method for a task resource feature sample library of a building intelligent control system according to claim 1, characterized in that: The generation of the kernel capability feature vector includes: The runtime status of each processor core is periodically read at a preset dynamic correction cycle. The runtime status includes core temperature, thermal throttling margin, current available frequency, L1 / L2 cache hit rate, interrupt queue depth, I / O bus utilization, and ready queue length. Based on the acquired runtime state, a dimension-by-dimensional linear scaling correction is performed on each dimension of the static capability vector generated by the benchmark test program, and the correction results are truncated at the boundary to generate a real-time kernel capability feature vector.

3. The multi-core scheduling method for a task resource feature sample library of a building intelligent control system according to claim 2, characterized in that: The generation of the static capability vector includes: After the system completes its power-on self-test, benchmark test programs are injected into each processor core sequentially to collect raw hardware performance data. The raw hardware performance data includes interrupt response latency, I / O bus bandwidth, peripheral access latency, fixed-point computing throughput, and floating-point computing throughput. The I / O bus bandwidth, fixed-point computing throughput, and floating-point computing throughput are normalized. The two types of latency indicators, interrupt response latency and peripheral access latency, are normalized after taking the complement values ​​and then assembled into a static capability vector according to the dimensions. The static capability vector consists of the following dimensions: the first dimension is interrupt response capability, filled with the normalized result of interrupt response delay compensation; the second dimension is I / O bandwidth capability, filled with the normalized result of I / O bus bandwidth; the third dimension is peripheral access capability, filled with the normalized result of peripheral access delay compensation; the fourth dimension is fixed-point throughput capability, filled with the normalized result of fixed-point computation throughput; and the fifth dimension is floating-point throughput capability, filled with the normalized result of floating-point computation throughput.

4. The multi-core scheduling method for a task resource feature sample library of a building intelligent control system according to claim 1, characterized in that: The establishment of the hash index includes: Using the tuple consisting of task type T and core number C as the key, the bucket number is calculated using a hash function, expressed as follows: Hash(T 16∣C) mod M Where M is a prime number greater than the upper limit of the sample library capacity.

5. The multi-core scheduling method for a task resource feature sample library of a building intelligent control system according to claim 1, characterized in that: The initial matching weights are set as follows: For the same task type, the best historical performance of that task type on each processor core is taken as the benchmark. The matching weight of the best core is set to 1, and the matching weight of the other cores is set according to the ratio of the historical performance data of that core to the best historical performance data, and the ratio is less than 1.

6. The multi-core scheduling method for a task resource feature sample library of a building intelligent control system according to claim 1, characterized in that: The step of updating the task resource requirement vector using the moving average mechanism includes: In the formula, For the first Each data collection window number This is the original task resource requirement vector obtained from statistics within the data collection window. This is the task resource requirement vector that has been fused in the previous cycle for this task in the sample library. This is the task resource requirement vector to be written back to the sample database after the current cycle update. As a smoothing factor, .

7. The multi-core scheduling method for a task resource feature sample library of a building intelligent control system according to claim 2, characterized in that: Based on the aforementioned sample library, in response to three types of events—new task arrival, emergency interruption exceeding a preset priority threshold, and task execution abnormality—the latest kernel status is generated, including: When a new task arrives, the sample library is retrieved using the real-time core capability feature vector and the task resource requirement vector as the joint retrieval key. The fit score is calculated according to the fit score formula, and the core with the highest score is selected as the optimal core. The new task is then assigned to the optimal core for execution. For emergency interrupts above the preset priority threshold, skip the sample library search, directly query the interrupt response capability dimension in the core capability feature vector, hard bind the task to the processor core with the lowest interrupt latency and preempt it immediately; If a task malfunctions, the corresponding task and core combination will be downgraded and written to the sample database.

8. The multi-core scheduling method for a task resource feature sample library of a building intelligent control system according to claim 7, characterized in that: Compatibility rating It can be expressed by the following formula: in, Let be the dimension of the task resource requirement vector. For the first Dimensional weights To match weights, Let be the core capability feature vector component of processor core c in the i-th dimension of the task resource requirement vector. This indicates the result obtained through dynamic correction based on the operating status. Let be the task resource requirement vector component of task T in the i-th dimension of the task resource requirement vector. When task T has no resource requirement in the i-th dimension of the task resource requirement vector, the degree of satisfaction in that dimension is... The value is 1.

9. The multi-core scheduling method for a task resource feature sample library of a building intelligent control system according to claim 1, characterized in that: The assessment of core load distribution includes: cache affinity retention assessment, inter-core temperature equalization assessment, and execution migration decision. Assess the load distribution across cores and output global load balancing commands, including: Perform a global scan at a set period to check the dwell time of each task on the current core. If the dwell time is less than the minimum dwell time threshold, remove the task and do not participate in this round of migration evaluation, and generate the first migration candidate set. Based on the first migration candidate set, the number of cache accesses and misses during the read cycle are used to calculate the cache hot page hit rate of each task on the core. Tasks with a hit rate higher than the hit threshold are preferentially retained on the current core, and tasks with a hit rate lower than the hit threshold are marked as having weak cache affinity. A second migration candidate set containing the weak affinity markers is then generated. Monitor the temperature difference between cores. When the temperature difference exceeds the preset temperature difference threshold, based on the second migration candidate set, select tasks with a cache hot page hit rate lower than the threshold and no persistent state from cores whose core temperature difference with the lowest core temperature exceeds the temperature difference threshold and whose load rate exceeds the preset load threshold as the tasks to be migrated. Record the core where the task is currently located as the source core, and determine the core whose core temperature difference with the lowest core temperature does not exceed the temperature difference threshold and whose load rate does not exceed the preset load threshold as the target core. Then migrate the tasks to be migrated from the source core to the target core. Based on the tasks to be migrated, source cores, and target cores determined in the second migration candidate set, a global load balancing migration instruction is generated.

10. A multi-core scheduling system for a building intelligent control system task resource feature sample database, comprising running the multi-core scheduling method for a building intelligent control system task resource feature sample database as described in any one of claims 1-9, characterized in that, include: The offline sample set generation module is used to run each typical building control task sequentially on each processor core. For each typical building control task type and processor core number, it collects task resource requirement vectors, core capability feature vectors, and historical performance data. It establishes a hash index with task type and core number as keys, sets an initial matching weight for each sample entry based on historical performance data, binds the task resource requirement vector, core capability feature vector, and historical performance data into sample entries, and stores the set of all sample entries as an offline sample set in the sample library. The sample library update module is used to calculate the deviation between the actual execution performance of the task and the expected value of the sample library after each scheduling execution, based on the offline sample set as a baseline, and adjust the matching weight accordingly. The task resource requirement vector is updated by using a moving average mechanism, and runtime state tags are injected into the sample library entries to update the sample library. The latest kernel status generation module is used to generate the latest kernel status based on the sample library in response to three types of events: new task arrival, emergency interruption above a preset priority threshold, and task operation abnormality. The scheduling module is used to evaluate the load distribution of each core based on the latest core status and output global load balancing instructions to implement multi-core scheduling of the building intelligent control system task resource feature sample library.

11. An Internet of Things (IoT) gateway, characterized in that, The method described in any one of claims 1-9 is used for multi-core scheduling of the task resource feature sample library of the building intelligent control system.

12. A terminal, comprising a processor and a storage medium; characterized in that: The storage medium is used to store instructions; The processor is configured to operate according to the instructions to perform the steps of the method according to any one of claims 1-9.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method according to any one of claims 1-9.

Images