Embedded operation method based on multi-core collaboration and related equipment
By using an embedded operating system based on multi-core collaboration, the problems of resource sharing and task scheduling in multi-core collaboration scenarios are solved, achieving efficient resource sharing and task scheduling, reducing the scheduling latency of critical power supply processes and meeting the needs of high real-time scenarios.
Patent Information
- Application Number
- CN202511108866.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-08
- Publication Date
- 2026-02-24
AI Technical Summary
Existing embedded operating systems struggle to effectively address performance fluctuations and resource contention issues related to resource sharing and task scheduling in multi-core collaborative scenarios. Furthermore, traditional context switching mechanisms suffer from long switching delays across heterogeneous architectures, impacting overall efficiency.
An embedded operating system based on multi-core collaboration is adopted, including multiple kernels, a multi-core collaboration module, a dynamic task scheduling module, a clock synchronization unit, a latency compensation unit, a context switching optimization module, and a security access control module. Through cross-core data transmission, dynamic task scheduling, clock synchronization, and access control, efficient resource sharing and task scheduling are achieved.
It effectively reduces the scheduling latency of critical power supply processes, meets the needs of high real-time scenarios, and improves resource utilization and system determinism among multi-core processors.
Smart Images

Figure CN121560503A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded processor technology, specifically to multi-core embedded system technology, and more specifically to an embedded operation method and related equipment based on multi-core collaboration. Background Technology
[0002] With the rapid development of fields such as the energy industrial internet, smart grid dispatching, and IoT terminals, embedded operating systems have become an indispensable core support for these technologies. When facing diverse hardware platforms such as resource-constrained microcontrollers, multi-core heterogeneous processors, and high-performance industrial controllers, embedded operating systems need to provide efficient support in resource management, task scheduling, and latency control. However, current technical solutions exhibit certain limitations when dealing with the real-time and deterministic requirements of complex scenarios. For example, in multi-core collaborative scenarios, resource sharing and task scheduling between different kernels often rely on specific hardware or complex software protocols, which may lead to performance fluctuations or resource contention issues. Furthermore, the context switching mechanism of traditional operating systems has a long switching latency when crossing heterogeneous architectures, affecting overall efficiency. Summary of the Invention
[0003] In view of at least one of the above-mentioned technical problems, the purpose of this invention is to provide an embedded operation method and related equipment based on multi-core collaboration.
[0004] On one hand, embodiments of the present invention include an embedded operating system based on multi-core collaboration, wherein the embedded operating system based on multi-core collaboration is applied to a power supply, and the embedded operating system based on multi-core collaboration includes: Multiple kernels, each of which processes the assigned power supply process task; A multi-core collaboration module is used to transfer cross-core data between different cores; The dynamic task scheduling module is used to obtain multiple power supply process tasks of the power supply and allocate each power supply process task to the corresponding kernel according to the task scheduling strategy and the priority of each power supply process task.
[0005] Furthermore, the multi-core collaboration module is also used to select whether to transmit or isolate cross-core data between different cores based on the resource isolation strategy.
[0006] Furthermore, the dynamic task scheduling module is also used to determine the task scheduling strategy based on the acquired task scenario information through the scenario difference scheduling model, and to allocate each power supply process task to the corresponding kernel according to the task scheduling strategy and the priority of each power supply process task.
[0007] Furthermore, the dynamic task scheduling module also includes a clock synchronization unit and a delay compensation unit; The clock synchronization unit is used to synchronize the initial response time of the corresponding power supply process task executed in each kernel to obtain the synchronized initial response time. The delay compensation unit is used to acquire network transmission information and compensate the initial response time after synchronization based on the network transmission information to obtain the target response time.
[0008] Furthermore, the embedded operating system based on multi-core collaboration also includes a context switching optimization module; The context switching optimization module is used to enable the first kernel to access kernel data in the second kernel through a virtual interface; the first kernel and the second kernel are both arbitrary kernels.
[0009] Furthermore, the embedded operating system based on multi-core collaboration also includes a security access control module; The security access control module is used to adjust the permission range of each kernel according to the task scenario information, obtain the permission range corresponding to each kernel, and determine whether the first kernel conforms to the permission range. The context switching optimization module is further configured to, if it is determined that the first kernel conforms to the permission scope, enable the first kernel to access kernel data in the second kernel through the virtual interface.
[0010] Furthermore, the embedded operating system based on multi-core collaboration also includes a firewall between the various kernels; The firewall is used to prevent the second kernel from accessing the kernel data corresponding to the first kernel if it is determined that the second kernel does not conform to the permission scope.
[0011] On the other hand, embodiments of the present invention include an embedded operation method based on multi-core collaboration, wherein the embedded operation method based on multi-core collaboration is applied to a power supply, and the embedded operation method based on multi-core collaboration includes: Multiple power supply process tasks are obtained from the power supply. Based on the task scheduling strategy and the priority of each power supply process task, the power supply process tasks are assigned to the corresponding kernels.
[0012] On the other hand, embodiments of this application disclose an electronic device, including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor enables the processor to implement any of the multi-core collaborative embedded operation methods disclosed in embodiments of this application.
[0013] On the other hand, embodiments of the present invention also include a storage medium storing a processor-executable program, which, when executed by a processor, is used to perform the multi-core collaborative embedded operation method in the embodiments.
[0014] Compared with related technologies, the embodiments of this application have the following beneficial effects: This application provides an embedded operating method and related device based on multi-core collaboration. The embedded operating system includes: multiple kernels, each processing its assigned power supply process tasks; a multi-core collaboration module for transmitting cross-core data between kernels; and a dynamic task scheduling module for acquiring multiple power supply process tasks and assigning them to corresponding kernels according to a task scheduling strategy and the priority of each power supply process task. Implementing this application embodiment, with the support of a multi-core collaboration framework and the transmission of cross-core data between kernels via the multi-core collaboration module, enables efficient resource sharing and task scheduling among multi-core processors, thus avoiding performance fluctuations and resource contention issues in traditional methods. Furthermore, the dynamic task scheduling module schedules multiple power supply process tasks and assigns them to corresponding kernels according to a task scheduling strategy and the priority of each power supply process task, allowing multiple kernels to collaboratively process multiple power supply process tasks. This effectively reduces the scheduling latency of critical power supply process tasks, meeting the requirements of high real-time scenarios. Attached Figure Description
[0015] Figure 1 This is a schematic diagram of the structure of an embedded operating system based on multi-core collaboration disclosed in an embodiment of this application; Figure 2 This is a flowchart illustrating an embedded operation method based on multi-core collaboration disclosed in an embodiment of this application; Figure 3 This is a flowchart illustrating an embedded operation based on microkernel and multi-core collaboration in one embodiment. Figure 4 This is a schematic diagram of the structure of an embedded operating device based on multi-core collaboration disclosed in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. Detailed Implementation
[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0017] It should be noted that the terms "comprising" and "having," and any variations thereof, in the embodiments and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.
[0018] It is understood that the terms "first," "second," etc., used in this application may be used herein to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of this application, a first kernel may be referred to as a second kernel, and similarly, a second kernel may be referred to as a first kernel. Both the first kernel and the second kernel are kernels, but they are not the same kernel.
[0019] This application discloses an embedded operation method and related devices based on multi-core collaboration, which can effectively reduce the scheduling latency of critical power supply processes to meet the needs of high real-time scenarios. Detailed descriptions follow.
[0020] Please see Figure 1 , Figure 1 This application discloses a schematic diagram of an embedded operating system based on multi-core collaboration. This embedded operating system can be applied to a power supply, which may be a generator set, a smart grid, or an energy storage device, etc., and is not limited thereto. Figure 1 As shown, the embedded operating system based on multi-core collaboration can include multiple kernels, a multi-core collaboration module, and a dynamic task scheduling module.
[0021] In some embodiments, each kernel can process assigned power supply process tasks, which may be process tasks generated by various processes after the power supply is started. The kernel can be one or more of a real-time kernel, microkernel, miniature kernel, and standard kernel. Each kernel is configured within a multi-core collaborative embedded operating system that can manage the power supply process tasks and schedule data resources stored within it. The RAM (Random Access Memory) required for operation by each kernel can be very small; for example, the RAM required for operation by each kernel can be less than or equal to 50KB.
[0022] Each kernel, as a core component of this multi-core collaborative embedded operating system, resides in the foundational layer of the entire architecture. It contains low-power design units and real-time response units. The low-power design units reduce power consumption by eliminating unnecessary system calls and interrupt handling logic. Optionally, these units reduce the number of calling interfaces in the multi-core collaborative embedded operating system to only those required for managing power supply processes and scheduling resources, thus keeping the required RAM to within 50KB. The real-time response unit employs hardware virtualization technology to achieve secure isolation between kernels and supports interrupt response latency not exceeding 200μs. The microkernel module establishes a connection with the multi-core collaborative framework through a unified communication interface. This interface completes data transmission based on shared memory and message passing mechanisms, while hardware virtualization technology allocates independent operating environments to avoid resource contention.
[0023] As an optional implementation, the multi-core collaboration module can be used to transmit cross-core data between kernels. This cross-core data can be data transmitted between any two kernels, generated when a kernel processes a power supply process task, or data pre-stored within that kernel. The multi-core collaboration module can identify cross-core data transmitted from any kernel and then transmit the data to the kernel that needs it. Furthermore, the multi-core collaboration module is also used to select whether to transmit or isolate cross-core data between kernels based on a resource isolation policy. The resource isolation policy describes the conditions for data transmission between kernels; for example, kernel A and kernel B can only transmit data of type A. The multi-core collaboration module is configured to support heterogeneous multi-core collaboration among real-time kernels, microkernels, small kernels, and standard kernels, and achieves cross-core task scheduling and resource sharing through a unified communication interface.
[0024] Furthermore, the multi-core collaboration module resides on multiple cores and works closely with the dynamic task scheduling module and the delay deterministic control module. Optionally, this multi-core collaboration module utilizes hardware timestamps to ensure that the clock synchronization error between multiple cores is controlled within 10ns, and allocates an independent running environment to each core through a resource isolation strategy. The multi-core collaboration module and the dynamic task scheduling module interact through a scenario-differentiated scheduling algorithm, which dynamically adjusts the resource allocation in each core according to the priority and expiration time of the power supply process task. For example, in the energy industrial internet scenario, power supply process tasks are divided into three categories: safety-critical, real-time control, and background computing, respectively employing a hybrid scheduling strategy of Highest Priority First (HPF) and Shortest Remaining Time First (SRTF) to meet different task requirements. The priority of the power supply process task describes the priority of processing for that task, while the expiration time dynamically describes the timeframe for processing that task.
[0025] The multi-core collaboration module is used to select whether to transmit or isolate cross-core data between kernels according to resource isolation policies. It can allocate an independent running environment for each kernel through resource isolation policies, thereby improving the efficiency of each kernel in handling power supply process tasks.
[0026] In some embodiments, the dynamic task scheduling module can be used to acquire multiple power supply process tasks from the power supply and allocate each power supply process task to a corresponding kernel according to the task scheduling policy and the priority of each power supply process task. The task scheduling policy can describe the scheduling situation of scheduling multiple power supply process tasks to corresponding kernels for processing. This multi-core collaborative embedded operating system can be directly set within the power supply, enabling it to directly acquire the multiple power supply process tasks generated by the power supply during operation.
[0027] Furthermore, the dynamic task scheduling module is also used to determine the task scheduling strategy based on the acquired task scenario information through a scenario-differential scheduling model, and to allocate each power supply process task to the corresponding kernel according to the task scheduling strategy and the priority of each power supply process task. This scenario-differential scheduling model can be pre-set in the dynamic task scheduling module. The task scenario information can be used to describe the current application scenario of the power supply. This task scenario information can be obtained through direct user input. For example, the user can select from multiple preset scenarios based on the multi-core collaborative embedded operating system, thereby enabling the multi-core collaborative embedded operating system to obtain the task scenario information and input it into the scenario-differential scheduling model. The scenario-differential scheduling model can determine the corresponding task scheduling strategy based on the task scenario information, and the correspondence between the task scenario information and the task scheduling strategy can be pre-stored in the scenario-differential scheduling model.
[0028] The dynamic task scheduling module determines the task scheduling strategy based on the acquired task scenario information through the scenario-differentiated scheduling model. Based on the task scheduling strategy and the priority of each power supply process task, it allocates each power supply process task to the corresponding kernel, which can maximize the utilization of multi-core parallel computing resources.
[0029] Furthermore, the dynamic task scheduling module also includes a clock synchronization unit and a delay compensation unit. The clock synchronization unit synchronizes the initial response time of the corresponding power supply process tasks executed in each kernel to obtain the synchronized initial response time. The delay compensation unit acquires network transmission information and compensates for the synchronized initial response time based on the network transmission information to obtain the target response time. Specifically, the clock synchronization unit achieves clock synchronization between multiple kernels based on hardware timestamps, with an error of less than or equal to 10ns; the delay compensation unit dynamically compensates for non-deterministic delays such as network transmission and interrupt responses, ensuring that the standard deviation of the end-to-end power supply process task execution delay is less than or equal to 5%.
[0030] The dynamic task scheduling module further refines the multi-core multiplexing mechanism, maximizing the utilization of multi-core parallel computing resources through a combination of temporal and spatial multiplexing. Specifically, temporal multiplexing achieves concurrent execution of multiple tasks by slicing task execution time, while spatial multiplexing analyzes power supply process tasks, calculates their density, and allocates them to different cores based on their density to improve overall computing efficiency. The dynamic task scheduling module also works closely with the clock synchronization unit and the latency compensation unit. The clock synchronization unit can achieve inter-core clock synchronization based on hardware timestamps, while the latency compensation unit dynamically compensates for non-deterministic latency such as network transmission and interrupt response, ensuring that the standard deviation of end-to-end task execution latency is controlled within 5%.
[0031] In some embodiments, the multi-core collaborative embedded operating system further includes a context switching optimization module. This module enables a first kernel to access kernel data in a second kernel via a virtual interface; both the first and second kernels are arbitrary kernels. The context switching optimization module includes a lightweight register saving mechanism and a heterogeneous architecture support unit. The lightweight register saving mechanism only saves the necessary register states, reducing data storage during switching by more than 50%. Data access between kernels is achieved through a virtual interface. For example, a virtualized ISA interface enables cross-architecture context switching between CPU and GPU, or CPU and FPGA.
[0032] The context switching optimization module resides at the top level of this multi-core collaborative embedded operating system, forming a closed loop with multiple kernels and multi-core collaborative modules. This module reduces data copying through full memory protection technology, while leveraging the virtualized ISA interface to support context switching latency control within 2μs across heterogeneous architectures. Specifically, the full memory protection technology achieves zero-copy data operation through hardware acceleration, while the virtualized ISA interface provides a unified context switching interface by abstracting the instruction set differences of different hardware architectures.
[0033] Furthermore, the multi-core collaborative embedded operating system also includes a security access control module. This module adjusts the permission range of each kernel based on task scenario information to obtain the permission range corresponding to each kernel, and determines whether the second kernel conforms to the specified permission range. The context switching optimization module, if determined that the second kernel conforms to the specified permission range, allows the first kernel to access kernel data in the second kernel through a virtual interface. The context switching optimization module also works in conjunction with the security access control module and a real-time monitoring agent. The context switching optimization module can restrict unauthorized kernels or tasks from accessing critical resources based on a fine-grained capability model and access control lists. The security access control module can dynamically detect task timeouts and resource shortages and trigger priority preemption or resource reallocation.
[0034] This multi-core collaborative embedded operating system also includes firewalls between the kernels. These firewalls can prevent a second kernel from accessing the kernel data corresponding to the first kernel if it is determined that the second kernel does not meet the permission requirements. In other words, the security access control module includes a dynamic permission inheritance mechanism and firewalls between kernels. The dynamic permission inheritance mechanism automatically adjusts the permission scope according to the task scenario, while the inter-kernel firewalls block illegal memory access across kernels through hardware isolation technology. For example, in energy storage facility management scenarios, the security access control module can dynamically adjust the permission scope according to the task type of the power supply process, ensuring that critical tasks receive priority resource allocation, while preventing security risks caused by illegal access through multiple inter-kernel firewalls. The real-time monitoring agent periodically scans the task queue and resource usage to promptly detect anomalies and take corresponding measures. For example, when a power supply process task times out, it can trigger priority preemption or reallocate resources to other power supply process tasks.
[0035] As an alternative implementation, the multi-core collaborative embedded operating system also supports lightweight deployment and scalable architecture. Lightweight deployment allows microkernel modules to run independently on microcontrollers with less than or equal to 50KB of RAM, while scalable architecture adapts to multi-level hardware platforms, from low-power IoT terminals to high-performance industrial controllers, by dynamically loading standard kernel modules. For example, in real-time monitoring scenarios of generator sets, the system can extend its functionality by dynamically loading standard kernel modules to support more complex task scheduling requirements, while maintaining lightweight deployment capabilities to adapt to resource-constrained environments.
[0036] Optionally, this multi-core collaborative embedded operating system can be applied to the energy industrial internet field to achieve deterministic latency control for real-time monitoring of generator sets, smart grid dispatching, or energy storage facility management. In specific implementation, this multi-core collaborative embedded operating system provides basic task management and resource scheduling functions through a microkernel module. The multi-core collaboration module enables efficient resource sharing and task scheduling among heterogeneous multi-core processors. The dynamic task scheduling module dynamically allocates multi-core resources according to different scenario requirements. The latency deterministic control module ensures deterministic latency for critical task scheduling. The context switching optimization module reduces data storage and switching latency during cross-heterogeneous architecture switching. The secure access control module and real-time monitoring agent enhance the system's security and reliability.
[0037] In this embodiment, the multi-core collaborative embedded operating system includes: multiple kernels, each kernel processing its assigned power supply process tasks; a multi-core collaboration module for transmitting cross-core data between kernels; and a dynamic task scheduling module for acquiring multiple power supply process tasks and allocating them to corresponding kernels according to task scheduling policies and priorities. With the support of a multi-core collaboration framework, the multi-core collaboration module transmits cross-core data between kernels, enabling efficient resource sharing and task scheduling among multi-core processors. This avoids performance fluctuations and resource contention issues in traditional methods. Furthermore, the dynamic task scheduling module schedules multiple power supply process tasks and allocates them to corresponding kernels according to task scheduling policies and priorities, allowing multiple kernels to collaboratively process multiple power supply process tasks. This effectively reduces the scheduling latency of critical power supply process tasks, meeting the requirements of high real-time scenarios.
[0038] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embedded operation method based on multi-core collaboration disclosed in an embodiment of this application. This embedded operation method based on multi-core collaboration can be applied to the aforementioned power supply and may include the following steps: S201, acquire multiple power supply process tasks of the power supply.
[0039] S202 allocates each power supply process task to the corresponding kernel according to the task scheduling policy and the priority of each power supply process task.
[0040] In one embodiment, the power supply can generate multiple power supply process tasks during operation. Therefore, the power supply can directly acquire these tasks and allocate them according to the task scheduling policy and the priority of each task. For example, if the priority of power supply process task A is higher than that of power supply process task B, then task A can be allocated first. Furthermore, based on the task scheduling policy, the computational workload of each power supply process task can be estimated, and the multiple tasks can be allocated according to the computational workload of each task and the computational efficiency of each kernel. For example, if the computational workload of power supply process task A is greater than that of power supply process task B, and kernel A has higher computational efficiency, then task A can be allocated to kernel A for processing.
[0041] In the context of the energy industrial internet, real-time monitoring of power supply is required, along with deterministic latency control for task scheduling. Firstly, multiple kernels can use low-power design units to eliminate unnecessary system calls and interrupt handling logic, retaining only the functional interfaces necessary for basic task management and resource scheduling, thereby keeping the required RAM within 50KB. Simultaneously, the real-time response unit utilizes hardware virtualization technology to support interrupt response latency of no more than 200μs, providing an efficient foundational environment for subsequent task execution. The microkernel module establishes a connection with the multi-core collaborative framework through a unified communication interface. This interface completes data transmission based on shared memory and message passing mechanisms, and allocates independent operating environments through hardware virtualization technology to avoid resource contention.
[0042] Figure 3 This is a flowchart illustrating an embedded operation based on microkernel and multi-core collaboration in one embodiment, such as... Figure 3 As shown, multiple kernels are configured to provide basic task management and resource scheduling functions, requiring no more than 50KB of RAM to run. The multi-core collaboration module is configured to support heterogeneous multi-core collaboration among real-time kernels, microkernels, small kernels, and standard kernels, and achieves cross-kernel task scheduling and resource sharing through a unified communication interface. The dynamic task scheduling module is configured with a scenario-differentiated real-time pre-emptive scheduling strategy, dynamically allocating multi-core resources according to task priority and expiration time. Furthermore, the latency deterministic control module is configured to pre-allocate CPU, memory, and storage resources using a high-precision clock, ensuring the deterministic nature of critical task scheduling latency. Finally, the context switching optimization module is configured to employ full memory protection technology to reduce data copying, achieving a context switching latency of no more than 2µs across heterogeneous architectures.
[0043] In this embodiment, the power supply can acquire multiple power supply process tasks and allocate each power supply process task to the corresponding kernel according to the task scheduling strategy and the priority of each power supply process task. This can effectively reduce the scheduling latency of critical power supply process tasks to meet the needs of high real-time scenarios.
[0044] Please see Figure 4 , Figure 4 This is a schematic diagram of an embedded operating device based on multi-core collaboration disclosed in an embodiment of this application. This device can be applied to a power supply. Figure 4 As shown, the embedded operating device 400 based on multi-core collaboration may include: a task acquisition module 401 and a task scheduling module 402.
[0045] The task acquisition module 401 is used to acquire multiple power supply process tasks of the power supply. The task scheduling module 402 allocates each power supply process task to the corresponding kernel according to the task scheduling policy and the priority of each power supply process task.
[0046] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. For example... Figure 5 As shown, the electronic device 500 may include: Memory 501 storing executable program code; Processor 502 coupled to memory 501; The processor 502 calls the executable program code stored in the memory 501 to execute any of the embedded operation methods based on multi-core collaboration disclosed in the embodiments of this application.
[0047] This application discloses a computer-readable storage medium storing a computer program, wherein when the computer program is executed by the processor, the processor implements any of the multi-core collaborative embedded operation methods disclosed in this application.
[0048] This application discloses a computer program product, including a computer program, which, when executed by a processor, implements the methods described in the above embodiments.
[0049] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Those skilled in the art should also recognize that the embodiments described in the specification are optional embodiments, and the actions and modules involved are not necessarily essential to this application.
[0050] In the various embodiments of this application, it should be understood that the sequence number of each process does not necessarily imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0051] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they can be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0052] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0053] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-accessible memory. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several requests to cause a computer device (which can be a personal computer, server, or network device, specifically a processor in the computer device) to execute some or all of the steps of the methods described in the various embodiments of this application.
[0054] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compactdisc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.
[0055] The foregoing has provided a detailed description of an embedded operation method and related devices based on multi-core collaboration disclosed in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. An embedded operating system based on multi-core collaboration, characterized in that, The multi-core collaborative embedded operating system is applied to the power supply, and the multi-core collaborative embedded operating system includes: Multiple kernels, each of which processes the assigned power supply process task; A multi-core collaboration module is used to transfer cross-core data between different cores; The dynamic task scheduling module is used to obtain multiple power supply process tasks of the power supply and allocate each power supply process task to the corresponding kernel according to the task scheduling strategy and the priority of each power supply process task.
2. The embedded operating system based on multi-core collaboration according to claim 1, characterized in that, The multi-core collaboration module is also used to select whether to transmit or isolate cross-core data between different cores based on resource isolation strategies.
3. The embedded operating system based on multi-core collaboration according to claim 1, characterized in that, The dynamic task scheduling module is further configured to determine a task scheduling strategy based on the acquired task scenario information through a scenario-differential scheduling model, and to allocate each power supply process task to the corresponding kernel according to the task scheduling strategy and the priority of each power supply process task.
4. The embedded operating system based on multi-core collaboration according to claim 3, characterized in that, The dynamic task scheduling module also includes a clock synchronization unit and a delay compensation unit; The clock synchronization unit is used to synchronize the initial response time of the corresponding power supply process task executed in each kernel to obtain the synchronized initial response time. The delay compensation unit is used to acquire network transmission information and compensate the initial response time after synchronization based on the network transmission information to obtain the target response time.
5. The embedded operating system based on multi-core collaboration according to claim 1, characterized in that, The embedded operating system based on multi-core collaboration also includes a context switching optimization module; The context switching optimization module is used to enable the first kernel to access kernel data in the second kernel through a virtual interface; the first kernel and the second kernel are both arbitrary kernels.
6. The embedded operating system based on multi-core collaboration according to claim 5, characterized in that, The embedded operating system based on multi-core collaboration also includes a security access control module; The security access control module is used to adjust the permission range of each kernel according to the task scenario information, obtain the permission range corresponding to each kernel, and determine whether the first kernel conforms to the permission range. The context switching optimization module is further configured to, if it is determined that the first kernel conforms to the permission scope, enable the first kernel to access kernel data in the second kernel through the virtual interface.
7. The embedded operating system based on multi-core collaboration according to claim 6, characterized in that, The embedded operating system based on multi-core collaboration also includes a firewall between the various kernels; The firewall is used to prevent the second kernel from accessing the kernel data corresponding to the first kernel if it is determined that the second kernel does not conform to the permission scope.
8. An embedded operation method based on multi-core collaboration, characterized in that, The embedded operation method based on multi-core collaboration is applied to a power supply, and the embedded operation method based on multi-core collaboration includes: Multiple power supply process tasks are obtained from the power supply. Based on the task scheduling strategy and the priority of each power supply process task, the power supply process tasks are assigned to the corresponding kernels.
9. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor enables the processor to implement the embedded operation method based on multi-core collaboration as described in claim 8.
10. A storage medium storing a processor-executable program, characterized in that, The processor-executable program, when executed by the processor, is used to perform the embedded operation method based on multi-core collaboration as described in claim 8.