Controller virtualization method and device, computer equipment and storage medium

Abstract

The embodiment of the invention provides a controller virtualization method and device, computer equipment and a storage medium. The method comprises the steps that a virtual execution unit corresponding to each embedded controller creates a virtual core thread for each processor core in the embedded controller; and each virtual core thread is triggered through a virtual tick event, operates a task thread corresponding to a task deployed on the processor core, reads target interrupt information written by a virtual peripheral thread based on a shared memory, and executes a virtual interrupt routine corresponding to the target interrupt information. The method can effectively reduce the cost of the virtualization process of the controller.

Description

Technical Field

[0001] This application relates to the field of virtualization technology, and in particular to a controller virtualization method, apparatus, computer device, and storage medium. Background Technology

[0002] Virtualization refers to computer virtualization technology, generally referring to the simulation of another computer's operating environment (which can be called a "client") on one computer (the "host") using software. In the field of virtualization, most current communication methods between client and host architectures are based on direct instruction set translation. That is, the client architecture's instruction set is converted into the host architecture's instruction set through software. This method allows for direct instruction set integration, enabling desktop operating systems and application software to run in the virtual environment without porting.

[0003] However, in the virtualization process of embedded controllers (i.e. controllers with integrated embedded software), the embedded controller may be a real-time core architecture or a performance core architecture. The corresponding instruction set translation is required for embedded controllers with different architectures, which leads to a high cost of virtualization. Summary of the Invention

[0004] This application provides a controller virtualization method, apparatus, computer device, and storage medium, aiming to improve the high cost of existing controller virtualization processes.

[0005] A controller virtualization method, comprising: Each embedded controller corresponds to a virtual execution unit, which creates a virtual core thread for each processor core in the embedded controller. Each virtual core thread is triggered by a virtual tick event to run the task fiber corresponding to the task deployed on the processor core, and to read the target interrupt information written by the virtual peripheral thread in the shared memory and execute the virtual interrupt routine corresponding to the target interrupt information.

[0006] This solution directly ports the embedded software built into the embedded controller to the host architecture. It utilizes the process / thread mechanisms of the desktop operating system (Windows / Linux) to perform functional-level simulation operations such as interrupt handling and task scheduling, enabling cross-platform virtualization operations. This simplifies the virtualization process, eliminating the need to consider the actual instruction values ​​of the embedded controller during processing, and achieving the goal of simulating and testing the embedded controller's built-in software at a lower cost.

[0007] In one embodiment, each virtual core thread accesses shared memory via a virtual tick event. When the shared memory contains target interrupt information written by a virtual peripheral thread, the virtual interrupt routine corresponding to the target interrupt information is executed. When the shared memory does not contain target interrupt information written by a virtual peripheral thread, the virtual interrupt routine is not executed. Activate and run the task fiber corresponding to the task that meets the activation conditions deployed on the processor core.

[0008] In this embodiment, the process / thread mechanism of the desktop operating system (Windows / Linux) is used to first execute the virtual kernel thread to simulate the interrupt operation of the peripheral hardware. Only after there is no interrupt operation will the normal task scheduling processing logic be implemented. This can realize cross-platform virtualization operation, simplify the virtualization process, and make its processing process not need to consider the real instruction value of the embedded controller, so as to achieve the purpose of simulating and testing the built-in software of the embedded controller at a lower cost.

[0009] In one embodiment, the virtual interrupt routine is a code snippet in which a virtual peripheral thread provides data services to a virtual kernel thread.

[0010] A virtual interrupt routine is a code snippet that provides data services from a virtual peripheral thread to a virtual core thread. This allows the virtual core thread to execute the virtual interrupt routine without participating in the processor core's task scheduling. It is mainly used to simulate the effect of a "virtual interrupt". This approach eliminates the need for instruction set translation and peripheral register simulation of the embedded controller and its processor core. Instead, it is ported to the desktop operating system for operation, which helps reduce the cost of the virtualization process.

[0011] In one embodiment, the method further includes: When the virtual core thread is not triggered by the virtual tick event, the task status of the task is determined to be suspended. When the task status of the task is suspended and the task meets the activation condition, the task status of the task is switched to the ready state and the task fiber corresponding to the task is run. After the task fiber completes its execution, the task status corresponding to the task is switched to suspended state.

[0012] In this embodiment, the process / thread mechanism of the desktop operating system is used to simulate the task scheduling operation at the functional level, and the task state switching process of the task deployed in the processor core is simulated. This process does not require instruction set translation and peripheral register simulation of the embedded controller and its processor core and other hardware, but is transformed into operation by porting to the desktop operating system, which helps to reduce the cost of the virtualization process.

[0013] In one embodiment, the activation condition is that the timer count corresponding to the virtual tick event reaches the expiration point count of the preset period corresponding to the task fiber.

[0014] In this example, by comparing the current tick timer count with the expiration point count corresponding to the task's preset period, it is possible to quickly and effectively determine whether the task's activation conditions are met.

[0015] In one embodiment, after creating a virtual core thread for each processor core in the embedded controller, the method further includes: The virtual kernel thread creates virtual tick events based on the waitable timer object in the desktop operating system and the time interval corresponding to the system tick interrupt frequency in the embedded controller.

[0016] In this embodiment, in order to virtualize the system tick of the embedded controller, the time interval corresponding to the actual system tick interrupt frequency of the embedded controller can be determined. Based on this time interval and the waitable timer object provided by the desktop operating system, a virtual tick event is created so that the virtual core thread can be triggered based on the virtual tick event. This allows the virtual core thread to work without worrying about the deviation between the virtualization process and the real physical time, which helps to ensure the orderly progress of the controller virtualization process.

[0017] In one embodiment, the method further includes: The virtualization master program creates a corresponding virtual execution unit for each embedded controller. The virtual execution unit and its corresponding virtual core thread communicate with the virtual peripheral thread through the shared memory corresponding to the virtualization master program.

[0018] In this embodiment, the virtualization main program creates a corresponding virtual execution unit for each embedded controller, and the virtual execution unit creates a virtual core thread for each processor core in the embedded controller. This enables the virtual execution unit and its corresponding virtual core thread to interact with virtual peripheral threads and other virtual core threads through the shared memory of the virtualization main program. This allows the virtual execution unit to simulate the scenario where the processor core is interrupted, avoiding the additional latency introduced by message queues or other communication methods, thus ensuring the high efficiency of information interaction.

[0019] A controller virtualization device, comprising: The virtual core thread creation module creates a virtual core thread for each processor core in the embedded controller, corresponding to each virtual execution unit of the embedded controller. The virtual core thread execution module includes each virtual core thread, which is triggered by a virtual tick event, to run the task fiber corresponding to the task deployed on the processor core, and to read the target interrupt information written by the virtual peripheral thread in the shared memory and execute the virtual interrupt routine corresponding to the target interrupt information.

[0020] A computer device includes a processor and a memory, wherein, Memory, used to store computer programs; The processor is used to execute programs stored in memory to implement the above methods.

[0021] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned controller virtualization method. Attached Figure Description

[0022] Figure 1 This is a flowchart of a controller virtualization method provided in an embodiment of this application; Figure 2 This is an interaction diagram of a controller virtualization method provided in an embodiment of this application; Figure 3 This is a structural diagram of the controller virtualization device provided in the embodiments of this application; Figure 4 This is a structural diagram of the computer device provided in the embodiments of this application. Detailed Implementation

[0023] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] This application relates to the field of virtualization technology for embedded controllers, specifically a controller virtualization method applicable to the AUTOSAR CP software platform architecture, suitable for software simulation testing of embedded controllers deployed on the AUTOSAR CP software platform architecture. AUTOSAR CP (Classic Platform) is a software architecture standard designed by AUTOSAR (Automotive Open Systems Architecture) for traditional automotive electronic control units (ECUs), focusing on meeting the needs of embedded systems with high real-time performance, limited resources, and relatively fixed functions. The embedded controller here refers to the on-board controller installed in the vehicle, which can be, but is not limited to, ECUs (Electronic Control Units) and MCUs (Microcontroller Units).

[0025] The controller virtualization method provided in this application is a virtualization implementation method based on a desktop operating system (such as Windows / Linux) on a computer, or equivalent to virtualization from the user-space perspective of a desktop operating system (such as Windows / Linux). It can realize full-stack simulation of AUTOSAR BSW layer and full-stack simulation of ASW layer. The core of AUTOSAR full-stack simulation is to reproduce the complete software stack of ECU (from low-level hardware abstraction to high-level application logic) in a virtual environment. BSW layer is the basic software layer, which includes the server (excluding the OS, MCAL and hardware-coupled modules that need to be ported and virtualized), ECU abstraction layer, MCAL (microcontroller abstraction, etc.). ASW layer is the application layer, which means that the code on the actual ECU can be run directly on a personal desktop terminal without modification. It only needs to be built as an x86 / 64 architecture program to realize software function simulation testing.

[0026] This application provides a controller virtualization method. To form a complete virtualization / simulation development environment, an auxiliary kit is also required. This auxiliary kit can extract and convert the configuration information required for virtualization / simulation from the AUTOSAR software configuration of the real embedded controller; and then generate / output runtime link dynamic libraries for the real embedded controller and software for virtualization porting to desktop operating systems (such as Windows / Linux) based on the configuration information. The AUTOSAR software configuration information here includes, but is not limited to, the ECUConfiguration Parameter file in the AUTOSAR toolchain. The runtime link dynamic libraries here include, but are not limited to, Alarm, Counter, Task, Schedule Table, etc. in the OS, as well as MCAL and other code coupled with ECU hardware. The design of the auxiliary kit already exists in some existing patents related to virtualization devices, and therefore is not within the scope of this invention.

[0027] This application provides a controller virtualization method. To form a complete virtualization / simulation development environment, a simulation environment corresponding to the virtual peripheral threads of the entire embedded controller is also required. This simulation environment includes, but is not limited to, functional simulation environments of peripherals corresponding to the AUTOSAR standard MCAL driver, such as CAN bus, ETH network, and PWM. The controller virtualization method provided in this embodiment is applicable to controller virtualization systems, focusing on the virtualization process of desktop operating systems (such as Windows / Linux). The virtualization method of MCAL and the design of the peripheral environment are not within the scope of this invention. The following explains the meaning of some terms involved in the embodiments of this application.

[0028] The virtualization main program is a virtualization management program. Its core function is to uniformly manage, schedule, and control resources of multiple virtual execution units to ensure the stable operation of the virtualization environment.

[0029] A Virtual Execution Unit (VLU) is an execution unit created by a desktop operating system for each embedded controller to simulate related operations performed by the embedded controller. As an example, a VLU can be a Virtual Process or a Virtual Thread. A Virtual Core Thread is a thread created by the VLU for each processor core in the embedded controller, and can simulate the corresponding processor core through this virtual core thread.

[0030] Task fibers are used to virtualize tasks in embedded controller software. While tasks run business logic, the purpose of using fibers to virtualize tasks is to allow the actual business logic running in the controller to also run within the fiber. A fiber is a lightweight user-space thread, entirely controlled and scheduled by the user program (not the kernel), also known as a "user-level thread." Fibers use a cooperative scheduling approach, resulting in lower resource overhead, and multiple fibers share the resources of the same underlying thread (such as stack space and file descriptors). In this example, each virtual kernel thread includes at least one task fiber.

[0031] Virtual peripheral threads are threads built using virtualization technology to simulate peripheral hardware; these will not be discussed in detail here. For example, the CAN bus is also virtualized as a user-space virtual peripheral thread, which can simulate input CAN messages. The virtual execution unit managed by the virtualization master program and its corresponding virtual core thread communicate via shared memory. In this example, the virtual peripheral thread writes the simulated CAN message into shared memory, treating it directly as pure software data in shared memory, without needing to concern itself with or simulate its physical voltage levels or other characteristics. In this example, the virtual peripheral thread corresponding to the peripheral hardware simulates the peripheral hardware providing data and services, and communicates with the virtual core thread via shared memory, writing target interrupt information into the shared memory.

[0032] This application provides a controller virtualization method applicable to computer devices with a desktop operating system installed, such as... Figure 1 As shown, the controller virtualization method includes: S101: The virtual execution unit corresponding to each embedded controller creates a virtual core thread for each processor core in the embedded controller; S102: Each virtual core thread is triggered by a virtual tick event to run the task fiber corresponding to the task deployed on the processor core, and to read the target interrupt information written by the virtual peripheral thread in shared memory and execute the virtual interrupt routine corresponding to the target interrupt information.

[0033] The virtual tick event is essentially a time-based thread scheduling mechanism provided by Windows used in virtualization emulation programs (for example, using the waitable timer object API: CreateWaitableTimer to create timer objects in the virtual core thread, and using the API: WaitForSingleObject in the so-called virtual core thread to simulate the tick interrupt frequency of the MCU system).

[0034] A virtual interrupt routine is a pre-written code snippet with specific functions that can be called repeatedly. Its core function is to respond to the "virtual interrupt" event and complete the preset processing logic.

[0035] As an example, in step S101, the controller is virtualized into a virtual execution unit (such as a virtual execution process or virtual execution thread) in the user mode of a desktop operating system. After the virtual execution unit is started, a virtual core thread needs to be allocated to each processor core (i.e., CPU) in the embedded controller.

[0036] As an example, in step S102, the virtual core thread corresponding to each processor core is triggered by the system tick event. After the virtual core thread is triggered, the task fiber corresponding to the task deployed on the processor core can be simulated and executed. Also, the target interrupt information written by the virtual peripheral thread can be read from the shared memory and the virtual interrupt routine corresponding to the target interrupt information can be executed to simulate the process of the processor core executing tasks or being interrupted by peripheral hardware.

[0037] In this embodiment, a virtual execution unit is created in each embedded controller, and a virtual core thread is created for at least one processor core corresponding to the embedded controller. This virtual core thread is triggered by virtual tick events to achieve different task scheduling. It can run the task fibers corresponding to the tasks deployed on the processor core, and it can also read the target interrupt information written by the virtual peripheral thread from shared memory and execute the virtual interrupt routine corresponding to the target interrupt information. This realizes the porting of the embedded software in the embedded controller to the virtual runtime environment. It uses the process / thread mechanism of the desktop operating system (Windows / Linux) to perform functional-level simulation operations such as interrupt handling and task scheduling. It simulates the virtual execution unit and virtual core thread, but does not directly simulate their behavior (there is no need to simulate the kernel operations involved). In this way, there is no need to translate the instruction set and simulate peripheral registers of the embedded controller and its processor core hardware. Instead, it is transformed into porting to the desktop operating system for operation, which helps to reduce the cost of the virtualization process.

[0038] In the virtualization of automotive controllers based on the AUTOSAR CP software platform architecture, the controller may be a real-time core architecture (e.g., powertrain, chassis, or central domain controllers with high real-time requirements) or a performance core architecture (e.g., intelligent driving and infotainment domain controllers with lower real-time requirements). The main problem with traditional instruction set translation technology is that supporting virtualization of multiple different controller architectures requires separate instruction set translation for each embedded controller, leading to very high costs (technical difficulty and development time). Furthermore, for real-time core architecture automotive controllers, in addition to instruction set translation, it is also necessary to establish a relationship between the desktop operating system and the specific MCU hardware (e.g., peripheral register relationships). However, the automotive industry's ECU / MCU hardware platforms are diverse and iterate frequently; therefore, this virtualization method is not well-suited for automotive ECUs / MCUs in real-time systems based on the AUTOSAR CP software platform.

[0039] Compared to traditional instruction set translation methods, this solution directly ports the embedded software built into the embedded controller to the host architecture. It utilizes the process / thread mechanisms of desktop operating systems (Windows / Linux) to perform functional-level simulation operations such as interrupt handling and task scheduling, enabling cross-platform virtualization operations. This simplifies the virtualization process, eliminating the need to consider the actual instruction values ​​of the embedded controller during processing, and achieving the goal of simulating and testing the embedded controller's built-in software at a lower cost.

[0040] In one embodiment, each virtual core thread accesses shared memory via a virtual tick event. When the shared memory contains target interrupt information written by the virtual peripheral thread, the virtual interrupt routine corresponding to the target interrupt information is executed. When the shared memory does not contain target interrupt information written by the virtual peripheral thread, the virtual interrupt routine is not executed. The task fiber corresponding to the task that meets the activation conditions and is deployed on the processor core is activated and run.

[0041] When the controller virtualization method is applied to software simulation testing of vehicle controllers (ECUs / MCUs) deployed with the AUTOSAR CP software platform architecture, the virtual peripheral thread can be a virtual program corresponding to the CAN bus, which interacts with the virtual core thread through shared memory. During software simulation testing, when the virtual peripheral thread writes a new CAN message to the shared memory, it is considered to be writing target interrupt information to the shared memory. This target interrupt information includes data simulated by each virtual peripheral (such as data from messages or packets processed by CAN, LIN, and ETH bus drivers, digital signals acquired and converted by ADC, etc.) and data simulated by customized virtual complex devices, as well as virtual interrupt flags used to simulate peripheral interrupt requests reaching the processor.

[0042] As an example, each virtual core thread is triggered by a virtual tick event. It can access shared memory to determine whether the shared memory contains target interrupt information written by the virtual peripheral thread. When the shared memory contains target interrupt information written by the virtual peripheral thread, for example, when the shared memory contains CAN messages and virtual interrupt flags written by the virtual peripheral thread corresponding to the CAN bus, the virtual interrupt routine corresponding to the target interrupt information needs to be executed to simulate the effect of the processor core being interrupted by the CAN message. Conversely, when the shared memory does not contain target interrupt information written by the virtual peripheral thread, for example, when the shared memory does not contain CAN messages and virtual interrupt flags written by the virtual peripheral thread corresponding to the CAN bus, it is determined that there is no interruption, and in this case, there is no need to execute the virtual interrupt routine.

[0043] In this example, when each virtual core thread is triggered, it needs to determine whether the tasks deployed on the processor core meet the activation conditions. If the activation conditions are met, the corresponding task fiber deployed on the processor core that meets the activation conditions is activated and executed. Each time a virtual core thread is activated by a system tick event, it needs to evaluate whether all tasks on the current processor core meet the corresponding activation conditions. If the activation conditions are met, the corresponding task fiber deployed on the processor core that meets the activation conditions needs to be executed. This process uses user-mode fibers, and the task scheduling and switching are initiated by the virtual core thread during processing, without the need for kernel intervention from the desktop operating system, which helps ensure processing efficiency.

[0044] In the real world, peripheral hardware interrupts of embedded controllers can be randomly triggered and interrupt currently running tasks. System tick interrupts are essentially interrupts, but task scheduling may occur within their interrupt context. In the controller virtualization method provided in this application, virtual tick events are used to simulate the actual system tick interrupts of embedded controllers, thereby simulating periodic task scheduling. The virtual core thread blocks and waits until the virtual tick event is triggered. The tasks actually running on each processor core are simulated as task fibers in the virtual core thread. Therefore, within a virtual core thread, the memory of all task fibers is shared, and scheduling is independent, which is consistent with the real world. For peripheral hardware-triggered interrupts, firstly, the peripheral hardware is virtualized into a virtual peripheral thread in the simulation program. The process of the peripheral hardware providing data services to the embedded processor is simulated as the process of communication between the virtual peripheral thread and the virtual core thread based on shared memory. When the virtual peripheral thread writes the virtual interrupt flag and the virtual peripheral simulated data into shared memory, it means that a peripheral hardware interrupt has been triggered. However, this will not interrupt the task fibers in the virtual core thread. Instead, each time the virtual core thread executes, it first checks the virtual interrupt flag in shared memory and then executes the virtual interrupt routine. After that, it activates and runs the task fibers corresponding to the tasks that meet the activation conditions deployed on the processor core.

[0045] In this embodiment, the process / thread mechanism of the desktop operating system (Windows / Linux) is used to first execute the virtual kernel thread to simulate the interrupt operation of the peripheral hardware. Only after there is no interrupt operation will the normal task scheduling processing logic be implemented. This can realize cross-platform virtualization operation, simplify the virtualization process, and make its processing process not need to consider the real instruction value of the embedded controller, so as to achieve the purpose of simulating and testing the built-in software of the embedded controller at a lower cost.

[0046] In one embodiment, the virtual interrupt routine is a code snippet in which a virtual peripheral thread provides data services to a virtual kernel thread.

[0047] As an example, the target interrupt information determined by the virtual core thread accessing shared memory includes not only virtual interrupt flags but also one or more virtual interrupt routines. These virtual interrupt routines are code snippets provided by the virtual peripheral thread to the virtual core thread. These code snippets simulate data provided by peripheral hardware to the processor core, such as message or packet data processed by CAN, LIN, or ETH bus drivers, or digital signals acquired and converted by an ADC. In this example, when the virtual core thread determines that the shared memory contains the target interrupt information written by the virtual peripheral thread, it needs to traverse and execute all virtual interrupt routines corresponding to the simulated data from the virtual peripherals. This simulates the process of multiple peripheral hardware interrupting the processor core's task execution. In this example, the virtual interrupt routine is a pre-written code snippet with specific functionality that can be repeatedly called. Specifically, it can be understood as a code snippet related to the simulated data from the virtual peripherals. It does not participate in the processor core's task scheduling and is mainly used to simulate the "virtual interrupt" effect. This approach eliminates the need for instruction set translation and peripheral register simulation of the embedded controller and its processor core; instead, it transforms the process into a desktop operating system, helping to reduce the cost of the virtualization process. In this example, when the virtual kernel thread checks the shared memory, it iterates through all virtual peripheral threads to check whether they have written the target interrupt information, and then executes the virtual interrupt routines provided by all virtual peripheral threads that have currently written the target interrupt information.

[0048] In one embodiment, the controller virtualization method further includes: When the virtual core thread is not triggered by the virtual tick event, the task's task state is determined to be suspended. When a task is in a suspended state and the task meets the activation conditions, the task state corresponding to the task is switched to the ready state, and the task fiber corresponding to the task is run. After the task fiber completes its execution, the corresponding task status is switched to suspended.

[0049] The suspended state refers to the state in which the task is paused, i.e., blocked and waiting. The ready state refers to the state in which the task has all the resources required for running (such as code, data, stack space, etc.) and is not blocked, waiting for the operating system to schedule and allocate CPU time slices to enter the running state.

[0050] As an example, when the virtual core thread is not triggered by a virtual tick event, the task state corresponding to the task deployed on its processor core is determined to be suspended (i.e., blocked and waiting). When the task state is suspended, it is necessary to monitor whether the task deployed on the processor core meets the activation conditions. If the activation conditions are met, the task state is switched to the ready state, which can be understood as its task fiber being ready to run. At this time, the task fiber corresponding to the task that meets the activation conditions can be run. After the task fiber finishes running, the task state is switched back to the suspended state to continue waiting for the system tick event to be triggered. In this example, the virtual core thread is set on the PC, and the task is a simulation of the task deployed on the processor core on the PC; the virtual core thread is blocked while waiting for the virtual tick event, and runs after it is triggered; the virtual core thread will determine whether the task deployed on the processor core meets the activation conditions. If the activation conditions are met, it will schedule the task fiber corresponding to that task to run until the task fiber finishes running. This process requires updating and switching the task state.

[0051] In this embodiment, the process / thread mechanism of the desktop operating system is used to simulate the task scheduling operation at the functional level, and the task state switching process of the task deployed in the processor core is simulated. This process does not require instruction set translation and peripheral register simulation of the embedded controller and its processor core and other hardware, but is transformed into operation by porting to the desktop operating system, which helps to reduce the cost of the virtualization process.

[0052] In one embodiment, the activation condition is that the timer count corresponding to the virtual tick event reaches the expiration point count of the preset period corresponding to the task fiber.

[0053] In this embodiment, the virtual core thread continuously acquires the timer count corresponding to the virtual tick event. When the timer count reaches the expiration point count of a preset period corresponding to any task fiber, it is determined that the activation condition for that task is met, and the task fiber corresponding to that task needs to be activated. This process is initiated by the virtual core thread to schedule and switch tasks, without the need for kernel intervention from the desktop operating system or to simulate the switching behavior between physical processor cores, thus helping to ensure processing efficiency. In this example, by comparing the current tick's timer count with the expiration point count corresponding to the task's preset period, it is possible to quickly and effectively determine whether the task's activation condition is met.

[0054] In one embodiment, after creating a virtual core thread for each processor core in the embedded controller, the controller virtualization method further includes: The virtual kernel thread creates virtual tick events based on the waitable timer object in the desktop operating system and the time interval corresponding to the system tick interrupt frequency in the embedded controller.

[0055] In the desktop operating system (AUTOSAR CP OS), task scheduling is mainly based on statically defined task cycles and priorities, supporting preemptive or non-preemptive methods. One of the core dependencies of its task scheduling is the system tick (here referred to as tick), which controls the activation and suspension of tasks.

[0056] The virtual kernel thread uses Windows' time-based thread scheduling mechanism (e.g., using the `CreateWaitableTimer` API to create timer objects within the virtual kernel thread, and the `WaitForSingleObject` API to simulate the MCU system tick interrupt frequency) to create virtual tick events, making them equivalent to the behavior of a system tick interrupt. The time interval (tick time) corresponding to the system tick depends on the embedded controller's OS configuration (`OsSecondsPertick`). This time interval is generally the greatest common divisor of the task cycles occurring on the embedded controller, ensuring that all task fibers can execute within one tick. A common value is 1ms. After creating a virtual tick event, the virtual kernel thread updates the timer count corresponding to the real-time virtual tick event in real time. When this timer count reaches a preset count, the virtual kernel thread is triggered to execute the virtual interrupt routine corresponding to the target interrupt information, or to simulate and execute the task fiber corresponding to the task deployed on the processor core that meets the activation conditions.

[0057] In this embodiment, in order to virtualize the system tick of the embedded controller, the time interval corresponding to the actual system tick interrupt frequency of the embedded controller can be determined. Based on this time interval and the waitable timer object provided by the desktop operating system, a virtual tick event is created so that the virtual core thread can be triggered based on the virtual tick event. This allows the virtual core thread to work without worrying about the deviation between the virtualization process and the real physical time, which helps to ensure the orderly progress of the controller virtualization process.

[0058] In one embodiment, the controller virtualization method further includes: The virtualization master program creates a corresponding virtual execution unit for each embedded controller. The virtual execution unit and its corresponding virtual core thread communicate with the virtual peripheral thread through the shared memory of the virtualization master program.

[0059] As an example, the virtualization master program creates a corresponding virtual execution unit for each embedded controller, and the virtual execution unit creates a virtual core thread for each processor core in the embedded controller. This allows the virtual execution unit and its corresponding virtual core thread to interact with virtual peripheral threads and other virtual core threads through the shared memory of the virtualization master program. This enables the virtual execution unit to simulate the scenario where the processor core is interrupted, avoiding the additional latency introduced by message queues or other communication methods, thus ensuring the efficiency of information interaction.

[0060] This example provides a controller virtualization method, such as Figure 2 As shown, the specific steps include the following: In the desktop operating system (AUTOSARCPOS), each controller is virtualized as a virtual execution unit in the user space of the desktop operating system. After the virtual execution unit starts, a virtual core thread is created for each processor core. Task scheduling is mainly based on statically defined task cycles and priorities, supporting preemptive or non-preemptive methods. Furthermore, the virtual core thread creates virtual tick events based on the time intervals corresponding to the waitable timer objects in the desktop operating system and the system tick interrupt frequency in the embedded controller, in order to control the activation and suspension of tasks in the virtual core thread. In this example, the time interval corresponding to each timer event is a tick, which is generally the greatest common divisor of the task cycles occurring in the embedded controller, to ensure that all task fibers can execute within one tick.

[0061] Each virtual core thread has a busy-wait loop, where the busy-wait refers to waiting for the arrival of the virtual execution unit's synchronization tick information. After receiving the tick information, each virtual core thread checks the virtual interrupts in a fixed relative order and whether the activation conditions corresponding to the task are met.

[0062] (3) When the activation condition corresponding to any task is met, for example, when the updated timer count (i.e., the cumulative number of tick arrival messages) reaches the expiration point count of the preset period corresponding to the task fiber (i.e., the expiration point count of the preset period corresponding to the task fiber whose Alarm is set), the activation condition is deemed met, and the task fiber corresponding to the task that meets the activation condition deployed on the processor core needs to be activated and run. In this example, when the virtual core thread is not triggered by the virtual tick event, the task state is determined to be suspended; when the task state is suspended and the activation condition of the task is met, the task state corresponding to the task is switched to ready. At this time, the task fiber corresponding to the task that meets the activation condition deployed on the processor core is run; the virtual core thread will not be interrupted before the task fiber is completed. After all task fibers in the tick arrival message round have run, their task state is switched to suspended, and the loop returns to waiting for the next tick arrival message.

[0063] This method already provides support for the virtualized runtime environment of AUTOSARCPOS. On this basis, combined with peripheral virtual programs, a complete virtual runtime environment for embedded controller software can be built, on which simulation tests can be run.

[0064] In this example, since the desktop operating system is not a real-time operating system, the process scheduling is different from that of the real-time system, and the actual time interval cannot be strictly guaranteed. As mentioned above, in a virtual kernel thread, it will not return to the busy waiting state until the next tick is reached until the virtual interrupt and task fiber are completed. This process may be inaccurate due to the long execution time of the task between two adjacent ticks. However, since the accuracy of the tick time does not affect the functionality or logic of the code, it can be directly considered accurate as a (time interval). (For example, suppose the tick time in a real embedded controller is 1ms, i.e., OsSecondsPertick is 0.001s, and suppose there is a Task with a 5ms cycle containing a 1+1 binary operation. If the Task fibers and ISRs within this tick cycle are all executed within 1ms, the virtual core thread's task state is blocked until the next tick arrives. If the Task fibers and ISRs within this tick cycle are not executed within 1ms, resulting in a timeout, the Task fiber execution will not be interrupted, but the tick time will still be considered 1ms. Therefore, regardless of how much real-world physical time has passed, each tick time is considered 1ms, and the preset execution cycle of the 5ms Task is considered 5ms. In this scenario, testing the 1+1 binary operation, regardless of how long the operation takes or how inaccurate the virtual tick time is, obviously does not affect the result of the 1+1 operation.)

[0065] In this embodiment, the software porting of the OS of the AUTOSARCP platform for the vehicle controller is applicable. This involves porting the OS code to the x86 architecture of a PC, utilizing the process / thread mechanisms of desktop operating systems (Windows / Linux) to simulate task scheduling, interrupt handling, and related APIs at the functional level (corresponding to the process / thread object model mentioned above), without directly simulating its behavior (no need to simulate the kernel operations involved). This eliminates the need for instruction set translation and peripheral register simulation for various CPU architectures and MCU hardware, instead transforming the process into a single x86 architecture for operation.

[0066] This invention aims to transfer software development and testing from prototype vehicles, test benches, and hardware-in-the-loop (HIL) simulation to the computers of functional developers. In the context of increasingly complex electronic and electrical architectures and the hardware and software architectures of vehicle controllers, with ever-increasing iteration frequencies and different hardware platforms for various domain control projects, this invention achieves software and hardware decoupling, as well as decoupling BSW and ASW development, to enable parallel development and functional-level testing and verification (mainly for algorithms, logic, etc.), thereby improving development efficiency.

[0067] This application also provides a controller virtualization device 300, such as... Figure 3 As shown, it includes: The virtual core thread creation module 301 creates a virtual core thread for each processor core in the embedded controller, corresponding to each virtual execution unit of the embedded controller. The virtual core thread execution module 302 is triggered by a virtual tick event to run the task fiber corresponding to the task deployed on the processor core, and to read the target interrupt information written by the virtual peripheral thread in the shared memory and execute the virtual interrupt routine corresponding to the target interrupt information.

[0068] This application embodiment also provides a computer device 400, such as... Figure 4 As shown, it includes a memory 401 and a processor 402, wherein the memory 401 is used to store computer programs; the processor 402 is used to execute the programs stored in the memory 401 to implement the controller virtualization method described in any embodiment of this application.

[0069] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the controller virtualization method described in any embodiment of this application.

[0070] In this application, "multiple" refers to two or more.

[0071] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0072] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if present) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0073] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0074] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if the method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if the method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0075] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A controller virtualization method, characterized in that, include: Each embedded controller corresponds to a virtual execution unit, which creates a virtual core thread for each processor core in the embedded controller. Each virtual core thread is triggered by a virtual tick event to run the task fiber corresponding to the task deployed on the processor core, and to read the target interrupt information written by the virtual peripheral thread in the shared memory and execute the virtual interrupt routine corresponding to the target interrupt information.

2. The method according to claim 1, characterized in that, Each virtual core thread accesses shared memory via a virtual tick event. When the shared memory contains target interrupt information written by the virtual peripheral thread, the virtual interrupt routine corresponding to the target interrupt information is executed. When the shared memory does not contain target interrupt information written by the virtual peripheral thread, the virtual interrupt routine is not executed. Activate and run the task fiber corresponding to the task that meets the activation conditions deployed on the processor core.

3. The method according to claim 1, characterized in that, The virtual interrupt routine is a code snippet in which the virtual peripheral thread provides data services to the virtual core thread.

4. The method according to claim 2, characterized in that, The method further includes: When the virtual core thread is not triggered by the virtual tick event, the task status of the task is determined to be suspended. When the task status of the task is suspended and the task meets the activation condition, the task status of the task is switched to the ready state and the task fiber corresponding to the task is run. After the task fiber completes its execution, the task status corresponding to the task is switched to suspended state.

5. The method according to claim 2, characterized in that, The activation condition is that the timer count corresponding to the virtual tick event reaches the expiration point count of the preset period corresponding to the task fiber.

6. The method according to any one of claims 1-5, characterized in that, After creating a virtual core thread for each processor core in the embedded controller, the method further includes: The virtual kernel thread creates virtual tick events based on the waitable timer object in the desktop operating system and the time interval corresponding to the system tick interrupt frequency in the embedded controller.

7. The method according to any one of claims 1-5, characterized in that, The method further includes: The virtualization master program creates a corresponding virtual execution unit for each embedded controller. The virtual execution unit and its corresponding virtual core thread communicate with the virtual peripheral thread through the shared memory corresponding to the virtualization master program.

8. A controller virtualization device, characterized in that, include: The virtual core thread creation module creates a virtual core thread for each processor core in the embedded controller, corresponding to each virtual execution unit of the embedded controller. The virtual core thread execution module includes each virtual core thread, which is triggered by a virtual tick event, to run the task fiber corresponding to the task deployed on the processor core, and to read the target interrupt information written by the virtual peripheral thread in the shared memory and execute the virtual interrupt routine corresponding to the target interrupt information.

9. A computer device, characterized in that, Including processor and memory, among which, Memory, used to store computer programs; A processor for executing a program stored in memory to implement the controller virtualization method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the controller virtualization method according to any one of claims 1-7.

Images