A processing method and system for embedded operating system

Abstract

The application discloses a processing method and system for an embedded operating system, and relates to the technical field of embedding.Aiming at the problems of task isolated management, rigid strategy configuration, lack of dynamic optimization and the like in the prior art, the application realizes optimization through the following steps: collecting task core attributes, associating data flow correlation between tasks with control flow correlation, and constructing a business chain model; dynamically configuring a shared cycle, a sleep depth and a wake-up window based on the model, and generating a strategy mapping table; coordinating and scheduling tasks according to the strategy, accurately waking up necessary hardware, and differentiating and processing timeout scenarios, and immediately sleeping after the completion of task execution; collecting running index deviation, and dynamically adjusting strategy parameters according to the deviation type.The application realizes business chain level overall scheduling, and improves system running efficiency and stability.

Description

Technical Field

[0001] This invention relates to the field of embedded technology, specifically to a processing method and system for embedded operating systems. Background Technology

[0002] The embedded operating system EOS is widely used in industrial control, automotive electronics, smart wearables, and other scenarios. Its operation requires both real-time performance and low power consumption. However, existing processing methods for EOS have the following drawbacks: First, existing methods often manage individual tasks in isolation, failing to identify data flow and control flow dependencies between tasks and lacking overall planning at the business chain level, resulting in chaotic task scheduling logic and frequent problems such as repeated wake-ups and resource preemption. Secondly, most of them adopt fixed cycles and uniform sleep depths, without dynamically adapting to the real-time level and task characteristics of the business chain, and thus cannot balance the real-time and power consumption requirements of different business scenarios. Third, during task execution, multiple hardware modules are fully started upon wake-up, and the startup of redundant modules consumes a lot of time and power. At the same time, data transmission relies on Flash storage, which is inefficient. Therefore, there is an urgent need for a processing method and system for embedded operating systems. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a processing method and system for embedded operating systems, which solves the problem of insufficient real-time performance and low power consumption co-optimization in embedded operating systems.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a processing method for embedded operating systems, comprising: S1. Collect the core attributes of each task and identify the data flow and control flow dependencies between tasks to build a business chain model; S2. Based on the constructed business chain model, determine the shared cycle of each business chain based on the task cycle with the highest trigger frequency, match the dormancy depth with the overall real-time level of the business chain, calculate the wake-up window with the total execution time of the task, and generate a business chain-dormancy strategy mapping table. S3. When the first task in the business chain reaches the trigger time, all tasks in the chain are executed in sequence according to the dependency order of the business chain-sleep strategy mapping table. If a real-time task times out, the wake-up window is temporarily extended or high real-time level tasks are given priority. The task is put into sleep mode immediately after the entire chain of tasks is completed. S4. Collect real-time service wake-up latency, execution timeout count, and energy consumption to identify the deviation type. At the same time, determine the adjustment target based on the deviation type and dynamically adjust the strategy parameters.

[0005] As a further aspect of the present invention, the specific operations for constructing the business chain model are as follows: Enter the four core attribute tags for each task one by one. Each tag retains only fixed optional values: ① Business type tag, including data acquisition, data preprocessing, AI inference, control output, local storage, and communication transmission; ② Real-time level tag, including safety critical level, normal real-time level, and non-real-time level; ③ Trigger cycle tag, which needs to be preset according to the common cycle of the embedded operating system EOS; ④ Dependency hardware module tag, which needs to be preset according to the EOS hardware list. Dependencies between tasks are identified from two dimensions: data flow tracing and control flow tracing. Data flow tracing locates the source of input data for each task and records the memory buffer address for data transmission. Control flow tracing locates the source of trigger signals for each task, starts the current task, and records the identifier ID of the trigger signal. If two tasks simultaneously satisfy both data flow association and control flow association, then a dependency relationship is determined between them. Based on EOS's core business scenarios, all tasks are divided into three fixed business domains: acquisition domain, processing domain, and execution domain. Tasks with dependencies are aggregated in a hierarchical order of "acquisition domain → processing domain → execution domain" to form a complete business chain. At the same time, within the same business chain, tasks are sorted according to the order of trigger signal transmission. The acquisition domain includes data acquisition tasks, the processing domain includes data preprocessing, AI inference, and local storage tasks, and the execution domain includes control output and communication transmission tasks. EOS is started to run for 10 business cycles. Task execution snapshots of each business chain are collected and compared with the actual execution order of tasks in the snapshots. If the order is consistent with the order within the business chain, the verification passes. Otherwise, the dependency relationship is re-determined. The task execution snapshots only record the execution order and trigger time of the tasks. After verification, a business chain-task model table is generated, which contains three types of core information: business chain name, task sequence, and overall real-time level of the business chain. The model table is then stored in EOS's high-speed SRAM, and the overall real-time level of the business chain is the highest level of the real-time levels of all tasks within the chain.

[0006] As a further aspect of the present invention, the specific steps for determining the shared cycle of each business chain are as follows: Extract the trigger cycle tag of each task in the current business chain and generate a task-cycle list; Compare the cycle values ​​in the task-cycle list one by one, and select the cycle with the smallest value as the high-frequency task cycle. After filtering out the high-frequency task cycle, check the cycles of all other tasks in the business chain except for the high-frequency task, and determine whether they are integer multiples of the high-frequency task cycle: if there are tasks that are not integer multiples, adjust the cycle of the task to the nearest integer multiple of the high-frequency task cycle, and finally set the shared cycle to the high-frequency task cycle; if the cycles of all other tasks are integer multiples of the high-frequency task cycle, then the shared cycle is directly set to the high-frequency task cycle.

[0007] As a further aspect of the present invention, the specific operation of matching the dormancy depth with the overall real-time level of the business chain is as follows: Based on the generated business chain-task model table, the overall real-time level of the current business chain is directly obtained, and the EOS built-in peripheral group hibernation list is called. The peripheral group hibernation list divides all EOS hardware modules into three groups, including core peripherals, key peripherals, and non-core peripherals. The core peripherals are essential and general-purpose hardware that supports the normal operation of the EOS kernel. The key peripherals are functional hardware that directly serves a specific business chain. The non-core peripherals are non-essential hardware that only provides extended auxiliary functions. Match hibernation actions according to the overall real-time level: If the overall real-time level is safety critical, then micro-sleep will be executed: core peripherals and critical peripherals will be kept running at low power while non-core peripherals will be turned off. If the overall real-time level is normal real-time level, then perform medium hibernation: switch core peripherals to low-frequency operation mode and shut down non-core peripherals and critical peripherals; If the overall real-time level is non-real-time, then deep hibernation is executed: core peripherals are put into hibernation mode, only the real-time clock is retained to trigger wake-up, and non-core peripherals and critical peripherals are turned off. At the same time, the startup configuration parameters of the key peripherals that the business chain depends on are written into the SRAM of the core peripherals in advance.

[0008] As a further aspect of the present invention, the specific steps for calculating the wake-up window are as follows: Launch the EOS task single execution time collection tool to allow all tasks in the business chain to be executed once in the task sequence determined by the business chain-task model table, record the time taken for each task from start to finish, i.e. the single execution time, and generate a task-single execution time list. Sum the time of all tasks in the task-single-time list to get the total execution time of the business chain. The redundancy ratio is determined based on the overall real-time level of the business chain: if the overall real-time level is safety critical, add 20% redundancy; if the overall real-time level is normal real-time, add 15% redundancy; if the overall real-time level is non-real-time, add 10% redundancy; calculate the final wake-up window duration = total task execution time × (1 + redundancy ratio).

[0009] As a further aspect of the present invention, the specific operation of sequentially executing all tasks within the chain is as follows: Each business chain is assigned a unique trigger identifier. The trigger signal of the first real-time task needs to carry this trigger identifier. When the EOS scheduler receives the trigger signal, it first extracts the trigger identifier from the signal and compares it with the trigger identifier of the business chain to be woken up. Only when the two are completely consistent will the wake-up process of the business chain be started, and trigger signals with other identifiers will be rejected. Extract the dependent hardware modules of all tasks in the current business chain to form a necessary hardware list. When waking up, only start the hardware modules in the list and directly shut down the wake-up links of all modules outside the list. The task sequence is extracted from the business chain-task model table. The scheduler starts the tasks one by one in the order of the task sequence and allocates an independent SRAM memory buffer for each business chain. The output data of the previous task is directly written to the buffer, and the input data of the next task is read from the buffer. No data is written to Flash throughout the process.

[0010] As a further aspect of the present invention, the specific operation of temporarily extending the wake-up window or prioritizing high real-time tasks is as follows: When each business chain is started, the scheduler assigns an independent task execution timer to each task in the chain. The timer starts counting when the task starts and automatically resets to zero when the task ends normally. If the countdown time reaches the preset maximum execution time of the task, the timer immediately sends a task timeout signal to the scheduler. The preset maximum execution time is 1.5 times the collected single execution time. After receiving a timeout signal, the scheduler synchronously reads two pieces of data: the execution time of the current timeout task and the total execution time of the business chain. If (total execution time of the business chain + remaining preset execution time of the task) ≤ wake-up window, it is determined that the single task has timed out; otherwise, it is determined that the entire chain is about to time out. If it is a single task timeout, the scheduler will temporarily extend the current wake-up window for twice the timeout duration of the timed-out task, and the total window duration after the extension will not exceed 1.5 times the wake-up window. After the extension, the task will continue to be executed until the task ends and then the subsequent task will be executed. If the entire chain is about to time out, the scheduler will immediately terminate all non-real-time tasks in the chain, and retain safety-critical and ordinary real-time tasks. If there is still a risk of timeout, ordinary real-time tasks will be terminated, and only safety-critical tasks will be retained to ensure that they are executed first.

[0011] As a further aspect of the present invention, the specific steps for addressing positioning deviation are as follows: For each business chain, the built-in hardware-level metric acquisition module of EOS is enabled to collect wake-up latency, execution timeout count, and energy consumption through hardware units: For wake-up latency, the time difference between the moment the trigger signal is received and the moment when all dependent hardware is started is recorded through the EOS system clock counter; For execution timeout count, the count is accumulated through the task execution timer, and the count is incremented by 1 each time a task sends a timeout signal. It is necessary to count the total number of records before the business chain goes to sleep; For energy consumption, the average current value of the business chain from wake-up to sleep is collected through the current sampling unit of the EOS power management module, and the energy consumption is calculated by combining the duration: average current × voltage × duration. After every 10 business chain sharing cycles are completed, the acquisition module automatically organizes the indicator data within the cycle into a "single cycle data + statistical data" format to generate a business chain indicator snapshot. The single cycle data records the specific values ​​of wake-up latency, execution timeout count, and energy consumption for each sharing cycle. The statistical data is the sum of the maximum wake-up latency, average energy consumption, and total number of timeouts within 10 cycles. The statistical data of the indicator snapshot is compared with the preset benchmark value of the indicator one by one: if the maximum wake-up delay is greater than the delay benchmark value, it is determined to be a wake-up delay deviation; if the average energy consumption is greater than the energy consumption benchmark value, it is determined to be an excessive energy consumption deviation; if the total number of timeouts is greater than the timeout benchmark value, it is determined to be an execution timeout deviation.

[0012] As a further aspect of the present invention, the adjustment target is determined according to the type of deviation, and the strategy parameters are dynamically adjusted, specifically including: If the issue is wake-up delay deviation, adjust the sleep depth; if the issue is excessive power consumption deviation, adjust the shared cycle; if the issue is execution timeout deviation, adjust the wake-up window. The adjustment of sleep depth means reducing the number of non-core peripherals that are turned off; the adjustment of the sharing cycle means extending the sharing cycle to the next integer multiple of the original high-frequency task cycle; and the adjustment of the wake-up window means extending the original wake-up window by 10%. After the adjustment is completed, continue to collect indicator data for the next 10 business chain sharing cycles, generate a new indicator snapshot, and compare the deviation changes before and after the adjustment: if the deviation indicator in the new snapshot returns to the range of the corresponding benchmark value, the adjustment is deemed effective and the new strategy parameters are solidified; if the deviation still exists, the sharing cycle, dormancy depth, and wake-up window are repeatedly adjusted until the deviation is eliminated.

[0013] A processing system for an embedded operating system includes: The business chain modeling module collects the core attributes of each task and identifies the data flow and control flow dependencies between tasks to build a business chain model. The strategy configuration module, based on the constructed business chain model, determines the shared period of each business chain based on the task cycle with the highest trigger frequency, matches the dormancy depth with the overall real-time level of the business chain, calculates the wake-up window with the total execution time of the task, and generates a business chain-dormancy strategy mapping table. The collaborative scheduling module executes all tasks in the chain sequentially according to the dependency order of the business chain-sleep strategy mapping table when the first task in the business chain reaches its trigger time. If a real-time task times out, the wake-up window is temporarily extended or high real-time priority tasks are given priority, and the task immediately goes into sleep mode after the entire chain of tasks has been completed. The feedback optimization module collects real-time service wake-up latency, execution timeout count, and energy consumption to identify the type of deviation. At the same time, it determines the adjustment target based on the deviation type and dynamically adjusts the strategy parameters.

[0014] This invention provides a processing method and system for embedded operating systems, which has the following advantages compared with the prior art: (1) By constructing a business chain model, this invention accurately identifies the data flow and control flow dependencies between tasks, breaks the traditional isolated task management mode, and realizes overall scheduling at the business chain level. (2) The present invention is based on a business chain model to dynamically configure the sleep-wake strategy, which matches the sleep depth according to the real-time level, determines the shared period according to the high-frequency task cycle, and calculates the wake-up window in combination with the task duration. This ensures that high real-time level tasks respond quickly and avoids energy waste of non-real-time tasks. (3) This invention improves task execution efficiency and stability by triggering precise wake-up, loading necessary hardware on demand, direct data memory transfer, and differentiated timeout processing. Attached Figure Description

[0015] Figure 1 This is a flowchart of the steps of the present invention; Figure 2 This is the system principle block diagram of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Example 1 like Figure 1 This invention provides a processing method for embedded operating systems, comprising: S1. Collect the core attributes of each task and identify the data flow and control flow dependencies between tasks to build a business chain model. The specific operations are as follows: Enter the four core attribute tags for each task one by one, with only fixed optional values ​​for each tag: ① Business type tag, including data acquisition, data preprocessing, AI inference, control output, local storage, and communication transmission; ② Real-time level tag, including safety critical level, normal real-time level, and non-real-time level; ③ Trigger cycle tag, which needs to be preset according to the common cycle of the embedded operating system EOS; ④ Dependent hardware module tag, which needs to be preset according to the EOS hardware list, including sensors, ADC modules, CPU cores, SRAM, Flash, communication modules, actuators, etc. The task attributes of the embedded operating system EOS have specialization and fixed characteristics. For example, the data acquisition task attributes in industrial scenarios will not change arbitrarily. If traditional scattered data entry is used, it is easy to cause ambiguity in expression, which will lead to the inability to accurately identify dependencies later. At the same time, tag-based data acquisition avoids ambiguity from the source through standardized options and does not require complex algorithm processing. Identify dependencies between tasks from two dimensions: data flow tracing and control flow tracing. Data flow tracing locates the source of input data for each task, i.e., which task's output is the current task's input, and records the memory buffer address for data transmission. Control flow tracing locates the source of the trigger signal for each task, i.e., which task will send a trigger signal after execution to start the current task, and records the identifier ID of the trigger signal; If two tasks simultaneously satisfy both data flow association and control flow association, then it is determined that there is a dependency relationship between them; Identifying dependencies through data flow can easily miss hidden dependencies that have no direct data flow but are related to control. For example, the "security verification task" sends a trigger signal after execution to allow the "control output task" to start. Although there is no data flow between the two, there is a critical dependency between them. Based on EOS's core business scenarios, all tasks are divided into three fixed business domains: acquisition domain, processing domain, and execution domain. Tasks with dependencies are aggregated in a hierarchical order of "acquisition domain → processing domain → execution domain" to form a complete business chain. This ensures that the business chain conforms to EOS's core business logic of data acquisition → processing → execution. The acquisition domain includes data acquisition tasks, the processing domain includes data preprocessing, AI inference, and local storage tasks, and the execution domain includes control output and communication transmission tasks. At the same time, within the same business chain, tasks are sorted according to the order of trigger signal transmission (i.e., the trigger direction of control flow tracing) to ensure that the task execution order is consistent with the dependency direction. The EOS system runs for 10 business cycles, and task execution snapshots are collected for each business chain. These task execution snapshots only record the execution order and trigger time of the tasks, and do not collect redundant data. Compare the actual execution order of the tasks in the snapshot. If it matches the order within the business chain, the verification passes; otherwise, the dependency relationship is re-evaluated. After the verification is passed, a business chain-task model table is generated. The table contains three types of core information: business chain name (named according to the core function, such as "motor control business chain"), task sequence (such as A→B→C→D), and the overall real-time level of the business chain (taking the highest level of real-time level of all tasks in the chain). The model table is then fixed in the high-speed memory SRAM of EOS for subsequent use by the strategy configuration module. Snapshot verification verifies the model's accuracy using a small amount of real-time running data to avoid static configuration bias, while hardening to SRAM can shorten subsequent call latency, meeting EOS's real-time requirements; For example, snapshot verification of the "motor control business chain" (A→B→C→D): snapshots of 10 operating cycles all show that the task execution order is A→B→C→D, with no deviation. Therefore, the output model table is fixed: the business chain name is "motor control business chain", the task sequence is "A (speed acquisition) → B (data preprocessing) → C (AI fault reasoning) → D (motor start-stop control)", and the real-time level of the business chain is "safety critical level" (because A is the safety critical level, which is the highest level of real-time level of all tasks in the chain).

[0018] S2. Based on the constructed business chain model, determine the shared cycle of each business chain using the task cycle with the highest trigger frequency as the benchmark. The specific steps are as follows: Extract the trigger cycle tag of each task in the current business chain (which has been fixed in step 1 above) and generate a task-cycle list; Compare the cycle values ​​in the task-cycle list one by one, and select the cycle with the smallest value as the high-frequency task cycle. This cycle is the interval at which tasks are triggered most frequently within the business chain, and it is also the benchmark for the shared cycle. High-frequency tasks (i.e., the shortest cycle tasks) are most likely to be missed due to mismatch in shared cycles. Using them as a benchmark can ensure that high-frequency tasks are not missed, thereby driving other low-frequency tasks to execute synchronously. After filtering out the high-frequency task cycle, check the cycles of all other tasks in the business chain except for the high-frequency task, and determine whether they are integer multiples of the high-frequency task cycle: if there are tasks that are not integer multiples, adjust the cycle of the task to the nearest integer multiple of the high-frequency task cycle, and finally set the shared cycle to the high-frequency task cycle; if the cycles of all other tasks are integer multiples of the high-frequency task cycle, then the shared cycle is directly set to the high-frequency task cycle. For example, an industrial business chain contains three tasks: A (acquisition, 200ms), B (preprocessing, 500ms), and C (inference, 1s). After extraction, a list is generated: A→200ms, B→500ms, C→1s. By comparing 200ms, 500ms, and 1s, the high-frequency task period is selected as 200ms. At the same time, the periods of all other tasks are integer multiples of the period of the high-frequency task. Therefore, it is directly used as the shared period. The dormancy depth is matched based on the overall real-time level of the business chain. The specific operation is as follows: By reading the business chain-task model table generated in step S1, the overall real-time level of the current business chain can be directly obtained. The real-time requirements of the business chain are determined by the most core task in the chain. The preset level in the model table can be directly extracted without re-analyzing the task level, which meets the real-time requirements of EOS. The built-in peripheral group hibernation list of EOS is invoked. The peripheral group hibernation list divides all hardware modules of EOS into three groups, including core peripherals, critical peripherals, and non-core peripherals. The core peripherals mentioned above are essential, general-purpose hardware that supports the normal operation of the EOS kernel and are prerequisites for the execution of all business chains, such as CPU cores, SRAM, and real-time clocks. The key peripherals are functional hardware that directly serve a specific business chain and are strongly bound to the core functions of the business chain. Without such peripherals, the corresponding business chain cannot complete its intended functions, but it will not affect the basic operation of the EOS system itself, such as sensors and actuators that the business chain depends on. The non-core peripherals are non-essential hardware that only provides extended auxiliary functions. They do not affect the basic operation of the EOS kernel, nor do they affect the completion of the core functions of the business chain, such as Bluetooth, WiFi, and log storage Flash. Match hibernation actions according to the overall real-time level: If the overall real-time level is safety critical, then micro-sleep will be executed: core peripherals and critical peripherals will maintain low power operation, while non-core peripherals will be turned off. If the overall real-time level is normal real-time level, then perform medium hibernation: core peripherals enter low-frequency operation mode, and non-core peripherals and critical peripherals are shut down (only core hardware that the business chain depends on is retained). If the overall real-time level is non-real-time, then deep hibernation is executed: core peripherals enter hibernation mode (only the real-time clock is retained to trigger wake-up), and non-core peripherals and critical peripherals are turned off; The startup configuration parameters of key peripherals that the business chain depends on, such as the initial value of the register and the data acquisition frequency, are written into the SRAM of the core peripherals in advance. The core time consumed by peripheral startup during wake-up is reading configuration parameters. Preloading the configuration can directly shorten the wake-up preparation time and avoid real-time task timeouts due to configuration reading delays. The wake-up window is calculated based on the total task execution time. The specific operation is as follows: Activate the EOS task single execution time collection tool to allow all tasks in the business chain to be executed once in the task sequence determined in step S1, record the time taken for each task from start to finish, i.e. the single execution time, and generate a task-single execution time list. If a large amount of historical execution data is collected, it will consume EOS storage and computing power. However, the execution time of EOS tasks is relatively fixed, and collecting the execution time of a single execution is sufficient to meet the accuracy requirements. The total execution time of the business chain is obtained by summing the time of all tasks in the task-single execution time list. This time is the minimum time for all tasks to be executed in sequence, and it is also the basic value for waking up the window. The redundancy ratio is determined based on the overall real-time level of the business chain: if the overall real-time level is safety-critical, add 20% redundancy (requiring higher execution stability); if the overall real-time level is normal real-time, add 15% redundancy; if the overall real-time level is non-real-time, add 10% redundancy; calculate the final wake-up window duration = total task execution time × (1 + redundancy ratio). The execution time of EOS tasks may vary slightly due to fluctuations in data volume. Adding redundancy can prevent task execution from being interrupted due to slight fluctuations. Differentiated redundancy based on the overall real-time level of the business chain can ensure the stability of security-critical tasks while avoiding power waste caused by excessive redundancy of non-real-time tasks. Generate a business chain-dormancy policy mapping table, store the shared period, dormancy depth, and wake-up window parameters for each business chain, and associate it with the EOS scheduler.

[0019] S3. When the first task in the business chain reaches its trigger time, all tasks in the chain are executed sequentially according to the dependency order of the business chain-sleep strategy mapping table. The specific steps are as follows: Each business chain is assigned a unique trigger identifier. The trigger signal of the first real-time task needs to carry this trigger identifier. When the EOS scheduler receives the trigger signal, it first extracts the trigger identifier from the signal and compares it with the trigger identifier of the business chain to be woken up. Only when the two are completely consistent will the wake-up process of the business chain be started, and trigger signals with other identifiers will be rejected. In EOS, multiple business chains usually coexist. Traditional wake-up methods are prone to false wake-ups due to confusion of trigger signals, which wastes power and occupies computing power. Using a unique trigger identifier can avoid false wake-ups across business chains from the source. Extract the dependent hardware modules of all tasks in the current business chain to form a necessary hardware list. When waking up, only start the hardware modules in the list and directly shut down the wake-up links of all modules outside the list. The general wake-up method will start all EOS hardware modules in full. The startup process of redundant modules takes a certain amount of time and continuously consumes power. However, by loading the necessary hardware, the wake-up preparation time can be shortened to the greatest extent and energy consumption can be reduced. The task sequence is extracted from the business chain-task model table in step S1. The scheduler starts the tasks one by one in the order of the task sequence and allocates an independent SRAM memory buffer for each business chain. The output data of the previous task is directly written to the buffer, and the input data of the next task is read from the buffer. No data is written to Flash throughout the process. If a real-time task times out, the wake-up window will be temporarily extended or high-real-time-priority tasks will be prioritized. The specific steps are as follows: When each business chain is started, the scheduler assigns an independent task execution timer to each task in the chain. The timer starts counting when the task starts and automatically resets to zero when the task ends normally. If the counting time reaches the preset maximum execution time of the task, the timer immediately sends a task timeout signal to the scheduler. The preset maximum execution time is 1.5 times the single execution time collected in step S2. If only the execution time of the entire chain is monitored, it is easy to miss the timeout of a single task. For example, if the preprocessing task times out but the entire chain does not time out, the subsequent inference task will fail to execute due to missing data. After receiving the timeout signal, the scheduler synchronously reads two pieces of data: the execution time of the current timeout task and the total execution time of the business chain. If (total execution time of the business chain + preset execution time of the remaining task) ≤ the wake-up window calculated in step S2, it is determined to be a single task timeout; otherwise, it is determined to be an imminent timeout for the entire link. If it is a single task timeout, the scheduler temporarily extends the current wake-up window for twice the timeout duration of the timed-out task, and the total window duration after the extension does not exceed 1.5 times the wake-up window in step S2. After the extension, the task continues to be executed until the task ends and then the subsequent task is executed. If the entire chain is about to time out, the scheduler will immediately terminate all non-real-time tasks in the chain, and retain safety-critical and ordinary real-time tasks. If there is still a risk of timeout, ordinary real-time tasks will be terminated, and only safety-critical tasks will be retained to ensure that they are executed first. Single-task timeouts only require a slight extension of the window to avoid data loss due to task interruption, while full-chain timeouts must prioritize core tasks to avoid security incidents. Once the entire task is completed, the system immediately goes into sleep mode to avoid multiple wake-ups caused by individual tasks going into sleep mode independently, thus reducing the overall power consumption of the real-time service chain.

[0020] S4. Collect real-time service wake-up latency, execution timeout count, energy consumption, and positioning deviation type, specifically including: Each business chain is equipped with EOS's built-in hardware-level metric collection module, which directly collects three core metrics—wake-up latency, execution timeout count, and energy consumption—through hardware units. The collection frequency is consistent with the business chain's shared cycle. For wake-up delay, the time difference between the moment the trigger signal is received and the moment when all dependent hardware has finished booting is recorded using the EOS system clock counter; For the number of execution timeouts, the count is accumulated by the task execution timer in step S3. Each time a task sends a timeout signal, the count is incremented by 1. It is necessary to count the total number of records before the business chain goes into sleep mode. Regarding energy consumption, the average current value of the entire process from wake-up to sleep is collected through the current sampling unit of the EOS power management module, and the energy consumption is calculated by combining the duration with the duration = average current × voltage × duration. After every 10 business chain sharing cycles are completed, the acquisition module automatically organizes the indicator data within the cycle into a "single cycle data + statistical data" format to generate a business chain indicator snapshot. The single cycle data records the specific values ​​of wake-up latency, execution timeout count, and energy consumption for each sharing cycle. The statistical data is the sum of the maximum wake-up latency, average energy consumption, and total number of timeouts within 10 cycles. The statistical data of the indicator snapshot is compared with the preset benchmark value of the indicator one by one: if the maximum wake-up delay is greater than the delay benchmark value, it is determined to be a wake-up delay deviation; if the average energy consumption is greater than the energy consumption benchmark value, it is determined to be an excessive energy consumption deviation; if the total number of timeouts is greater than the timeout benchmark value, it is determined to be an execution timeout deviation. The adjustment target is determined based on the type of deviation, and the strategy parameters are dynamically adjusted. The specific operation is as follows: If the deviation is due to wake-up delay, adjust the sleep depth. The root cause of the deviation is that excessively deep sleep leads to excessively long wake-up preparation time. If the deviation is due to excessively high energy consumption, adjust the sharing cycle. The root cause of the deviation is that the sharing cycle is too short, leading to frequent wake-ups and accumulated energy consumption. If the deviation is due to execution timeout, adjust the wake-up window. The root cause of the deviation is that the wake-up window is too narrow, resulting in insufficient task execution time. For the identified adjustment targets, adjustments are performed in small increments, with the adjustment magnitude positively correlated with the degree of deviation: Adjusting the sleep depth means reducing the number of non-core peripherals that are turned off, such as changing micro-sleep from "turning off all non-core peripherals" to "turning off only the Bluetooth module, keeping the WiFi module in low-power standby"; adjusting the sharing cycle means extending the sharing cycle to the next integer multiple of the original high-frequency task cycle; adjusting the wake-up window means extending the original wake-up window by 10%. After the adjustment is completed, continue to collect indicator data for the next 10 business chain shared cycles, generate a new indicator snapshot, and compare the deviation changes before and after the adjustment: if the deviation indicator in the new snapshot returns to the range of the corresponding benchmark value, the adjustment is deemed effective and the new strategy parameters are solidified; if the deviation still exists, repeat the adjustment of the shared cycle, sleep depth, and wake-up window in step S2 until the deviation is eliminated.

[0021] Example 2 like Figure 2 A processing system for an embedded operating system, comprising: The business chain modeling module collects the core attributes of each task and identifies the data flow and control flow dependencies between tasks to build a business chain model. The strategy configuration module, based on the constructed business chain model, determines the shared period of each business chain based on the task cycle with the highest trigger frequency, matches the dormancy depth with the overall real-time level of the business chain, calculates the wake-up window with the total execution time of the task, and generates a business chain-dormancy strategy mapping table. The collaborative scheduling module executes all tasks in the chain sequentially according to the dependency order of the business chain-sleep strategy mapping table when the first task in the business chain reaches its trigger time. If a real-time task times out, the wake-up window is temporarily extended or high real-time priority tasks are given priority, and the task immediately goes into sleep mode after the entire chain of tasks has been completed. The feedback optimization module collects real-time service wake-up latency, execution timeout count, and energy consumption to identify the type of deviation. At the same time, it determines the adjustment target based on the deviation type and dynamically adjusts the strategy parameters.

[0022] Some of the data in the above formulas are numerical calculations with dimensions removed, and the contents not described in detail in this specification are all prior art known to those skilled in the art.

[0023] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention 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 methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A processing method for embedded operating systems, characterized in that, include: S1. Collect the core attributes of each task and identify the data flow and control flow dependencies between tasks to build a business chain model; S2. Based on the constructed business chain model, determine the shared cycle of each business chain based on the task cycle with the highest trigger frequency, match the dormancy depth with the overall real-time level of the business chain, calculate the wake-up window with the total execution time of the task, and generate a business chain-dormancy strategy mapping table. S3. When the first task in the business chain reaches the trigger time, all tasks in the chain are executed in sequence according to the dependency order of the business chain-sleep strategy mapping table. If a real-time task times out, the wake-up window is temporarily extended or high real-time level tasks are given priority. The task is put into sleep mode immediately after the entire chain of tasks is completed. S4. Collect real-time service wake-up latency, execution timeout count, and energy consumption to identify the deviation type. At the same time, determine the adjustment target based on the deviation type and dynamically adjust the strategy parameters.

2. The processing method for an embedded operating system according to claim 1, characterized in that, The specific steps for building a business chain model are as follows: Enter the four core attribute tags for each task one by one. Each tag retains only fixed optional values: ① Business type tag, including data acquisition, data preprocessing, AI inference, control output, local storage, and communication transmission; ② Real-time level tag, including safety critical level, normal real-time level, and non-real-time level; ③ Trigger cycle tag, which needs to be preset according to the common cycle of the embedded operating system EOS. ④ Depends on hardware module tags and needs to be preset according to the EOS hardware manifest; Dependencies between tasks are identified from two dimensions: data flow tracing and control flow tracing. Data flow tracing locates the source of input data for each task and records the memory buffer address for data transmission. Control flow tracing locates the source of trigger signals for each task, starts the current task, and records the identifier ID of the trigger signal. If two tasks simultaneously satisfy both data flow association and control flow association, then a dependency relationship is determined between them. Based on EOS's core business scenarios, all tasks are divided into three fixed business domains: acquisition domain, processing domain, and execution domain. Tasks with dependencies are aggregated in a hierarchical order of "acquisition domain → processing domain → execution domain" to form a complete business chain. At the same time, within the same business chain, tasks are sorted according to the order of trigger signal transmission. The acquisition domain includes data acquisition tasks, the processing domain includes data preprocessing, AI inference, and local storage tasks, and the execution domain includes control output and communication transmission tasks. EOS is started to run for 10 business cycles. Task execution snapshots of each business chain are collected and compared with the actual execution order of tasks in the snapshots. If the order is consistent with the order within the business chain, the verification passes. Otherwise, the dependency relationship is re-determined. The task execution snapshots only record the execution order and trigger time of the tasks. After verification, a business chain-task model table is generated, which contains three types of core information: business chain name, task sequence, and overall real-time level of the business chain. The model table is then stored in EOS's high-speed SRAM, and the overall real-time level of the business chain is the highest level of the real-time levels of all tasks within the chain.

3. The processing method for an embedded operating system according to claim 1, characterized in that, The specific steps for determining the shared cycle for each business chain are as follows: Extract the trigger cycle tag of each task in the current business chain and generate a task-cycle list; Compare the cycle values ​​in the task-cycle list one by one, and select the cycle with the smallest value as the high-frequency task cycle. After filtering out the high-frequency task cycle, check the cycles of all other tasks in the business chain except for the high-frequency task, and determine whether they are integer multiples of the high-frequency task cycle: if there are tasks that are not integer multiples, adjust the cycle of the task to the nearest integer multiple of the high-frequency task cycle, and finally set the shared cycle to the high-frequency task cycle; if the cycles of all other tasks are integer multiples of the high-frequency task cycle, then the shared cycle is directly set to the high-frequency task cycle.

4. The processing method for an embedded operating system according to claim 1, characterized in that, The specific operation of matching the dormancy depth with the overall real-time level of the business chain is as follows: Based on the generated business chain-task model table, the overall real-time level of the current business chain is directly obtained, and the EOS built-in peripheral group hibernation list is called. The peripheral group hibernation list divides all EOS hardware modules into three groups, including core peripherals, key peripherals, and non-core peripherals. The core peripherals are essential and general-purpose hardware that supports the normal operation of the EOS kernel. The key peripherals are functional hardware that directly serves a specific business chain. The non-core peripherals are non-essential hardware that only provides extended auxiliary functions. Match hibernation actions according to the overall real-time level: If the overall real-time level is safety critical, then micro-sleep will be executed: core peripherals and critical peripherals will be kept running at low power while non-core peripherals will be turned off. If the overall real-time level is normal real-time level, then perform medium hibernation: switch core peripherals to low-frequency operation mode and shut down non-core peripherals and critical peripherals; If the overall real-time level is non-real-time, then deep hibernation is executed: core peripherals are put into hibernation mode, only the real-time clock is retained to trigger wake-up, and non-core peripherals and critical peripherals are turned off. At the same time, the startup configuration parameters of the key peripherals that the business chain depends on are written into the SRAM of the core peripherals in advance.

5. The processing method for an embedded operating system according to claim 1, characterized in that, The specific steps for calculating the wake-up window are as follows: Launch the EOS task single execution time collection tool to allow all tasks in the business chain to be executed once in the task sequence determined by the business chain-task model table, record the time taken for each task from start to finish, i.e. the single execution time, and generate a task-single execution time list. Sum the time of all tasks in the task-single-time list to get the total execution time of the business chain. The redundancy ratio is determined based on the overall real-time level of the business chain: if the overall real-time level is safety critical, add 20% redundancy; if the overall real-time level is normal real-time, add 15% redundancy; if the overall real-time level is non-real-time, add 10% redundancy; calculate the final wake-up window duration = total task execution time × (1 + redundancy ratio).

6. The processing method for an embedded operating system according to claim 1, characterized in that, The specific steps for executing all tasks within the chain sequentially are as follows: Each business chain is assigned a unique trigger identifier. The trigger signal of the first real-time task needs to carry this trigger identifier. When the EOS scheduler receives the trigger signal, it first extracts the trigger identifier from the signal and compares it with the trigger identifier of the business chain to be woken up. Only when the two are completely consistent will the wake-up process of the business chain be started, and trigger signals with other identifiers will be rejected. Extract the dependent hardware modules of all tasks in the current business chain to form a necessary hardware list. When waking up, only start the hardware modules in the list and directly shut down the wake-up links of all modules outside the list. The task sequence is extracted from the business chain-task model table. The scheduler starts the tasks one by one in the order of the task sequence and allocates an independent SRAM memory buffer for each business chain. The output data of the previous task is directly written to the buffer, and the input data of the next task is read from the buffer. No data is written to Flash throughout the process.

7. The processing method for an embedded operating system according to claim 1, characterized in that, The specific steps for temporarily extending the wake-up window or prioritizing high real-time tasks are as follows: When each business chain is started, the scheduler assigns an independent task execution timer to each task in the chain. The timer starts counting when the task starts and automatically resets to zero when the task ends normally. If the countdown time reaches the preset maximum execution time of the task, the timer immediately sends a task timeout signal to the scheduler. The preset maximum execution time is 1.5 times the collected single execution time. After receiving a timeout signal, the scheduler synchronously reads two pieces of data: the execution time of the current timeout task and the total execution time of the business chain. If (total execution time of the business chain + remaining preset execution time of the task) ≤ wake-up window, it is determined that the single task has timed out; otherwise, it is determined that the entire chain is about to time out. If it is a single task timeout, the scheduler will temporarily extend the current wake-up window for twice the timeout duration of the timed-out task, and the total window duration after the extension will not exceed 1.5 times the wake-up window. After the extension, the task will continue to be executed until the task ends and then the subsequent task will be executed. If the entire chain is about to time out, the scheduler will immediately terminate all non-real-time tasks in the chain, and retain safety-critical and ordinary real-time tasks. If there is still a risk of timeout, ordinary real-time tasks will be terminated, and only safety-critical tasks will be retained to ensure that they are executed first.

8. The processing method for an embedded operating system according to claim 1, characterized in that, The specific steps for handling positioning deviation types are as follows: For each business chain, the built-in hardware-level metric acquisition module of EOS is enabled to collect wake-up latency, execution timeout count, and energy consumption through hardware units: For wake-up latency, the time difference between the moment the trigger signal is received and the moment when all dependent hardware is started is recorded through the EOS system clock counter; For execution timeout count, the count is accumulated through the task execution timer, and the count is incremented by 1 each time a task sends a timeout signal. It is necessary to count the total number of records before the business chain goes to sleep; For energy consumption, the average current value of the business chain from wake-up to sleep is collected through the current sampling unit of the EOS power management module, and the energy consumption is calculated by combining the duration: average current × voltage × duration. After every 10 business chain sharing cycles are completed, the acquisition module automatically organizes the indicator data within that cycle into a "single cycle data + statistical data" format to generate a business chain indicator snapshot. The single cycle data records the specific values ​​of wake-up latency, execution timeout count, and energy consumption for each sharing cycle. The statistical data is the sum of the maximum wake-up latency, average energy consumption, and total number of timeouts within 10 cycles. The statistical data of the indicator snapshot is compared with the preset benchmark value of the indicator one by one: if the maximum wake-up delay is greater than the delay benchmark value, it is determined to be a wake-up delay deviation; if the average energy consumption is greater than the energy consumption benchmark value, it is determined to be an excessive energy consumption deviation; if the total number of timeouts is greater than the timeout benchmark value, it is determined to be an execution timeout deviation.

9. A processing method for an embedded operating system according to claim 1, characterized in that, The adjustment targets are determined based on the type of deviation, and the strategy parameters are dynamically adjusted, specifically including: If the issue is wake-up delay deviation, adjust the sleep depth; if the issue is excessive power consumption deviation, adjust the shared cycle; if the issue is execution timeout deviation, adjust the wake-up window. The adjustment of sleep depth means reducing the number of non-core peripherals that are turned off; the adjustment of the sharing cycle means extending the sharing cycle to the next integer multiple of the original high-frequency task cycle; and the adjustment of the wake-up window means extending the original wake-up window by 10%. After the adjustment is completed, continue to collect indicator data for the next 10 business chain sharing cycles, generate a new indicator snapshot, and compare the deviation changes before and after the adjustment: if the deviation indicator in the new snapshot returns to the range of the corresponding benchmark value, the adjustment is deemed effective and the new strategy parameters are solidified; if the deviation still exists, the sharing cycle, dormancy depth, and wake-up window are repeatedly adjusted until the deviation is eliminated.

10. A processing system for an embedded operating system, used to execute the processing method for an embedded operating system according to any one of claims 1-9, characterized in that, include: The business chain modeling module collects the core attributes of each task and identifies the data flow and control flow dependencies between tasks to build a business chain model. The strategy configuration module, based on the constructed business chain model, determines the shared period of each business chain based on the task cycle with the highest trigger frequency, matches the dormancy depth with the overall real-time level of the business chain, calculates the wake-up window with the total execution time of the task, and generates a business chain-dormancy strategy mapping table. The collaborative scheduling module executes all tasks in the chain sequentially according to the dependency order of the business chain-sleep strategy mapping table when the first task in the business chain reaches its trigger time. If a real-time task times out, the wake-up window is temporarily extended or high real-time priority tasks are given priority, and the task immediately goes into sleep mode after the entire chain of tasks has been completed. The feedback optimization module collects real-time service wake-up latency, execution timeout count, and energy consumption to identify the type of deviation. At the same time, it determines the adjustment target based on the deviation type and dynamically adjusts the strategy parameters.

Images