Restart method of operating system, vehicle control device, vehicle, medium and product

Abstract

The application provides a restart method of an operating system, a vehicle control device, a vehicle, a medium and a product, and relates to the technical field of vehicles. The method is applied to a vehicle control device, the vehicle control device comprises a virtual machine monitor, a first operating system and a second operating system running on the virtual machine monitor, the first operating system adopts a microkernel architecture, and the second operating system adopts a macrokernel architecture. The method comprises the following steps: in the process of running the first operating system and the second operating system on the virtual machine monitor, acquiring first to-be-tested information and second to-be-tested information; in response to the first to-be-tested information satisfying a corresponding restart condition, restarting the first operating system according to a first restart process; and in response to the second to-be-tested information satisfying a corresponding restart condition, restarting the first operating system according to a second restart process. The above-mentioned method can realize independent restart of the first operating system, does not affect the second operating system to continuously perform a control task, and improves the reliability of the operation of the vehicle control device.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method for restarting an operating system, vehicle control equipment, vehicles, media, and products. Background Technology

[0002] Autonomous vehicles and intelligent connected vehicles have evolved into complex devices that integrate multiple systems and software and hardware. In order to achieve autonomous driving, they are generally equipped with vehicle control devices that use dual operating systems. Since the dual operating systems have different tasks, their safety requirements are also different.

[0003] In existing technologies, when two operating systems are rebooted, they affect each other. Furthermore, the operating system with higher security requirements is extremely vulnerable to rebooting even when it is fault-free, which can force its tasks to be interrupted.

[0004] Therefore, existing technologies suffer from low reliability in vehicle control equipment operation. Summary of the Invention

[0005] This application provides a method for restarting an operating system, vehicle control equipment, a vehicle, media, and products to solve the problem of low reliability in vehicle equipment operation.

[0006] According to a first aspect of this application, a method for restarting a first operating system is provided, applied to a vehicle control device. The vehicle control device includes a virtual machine monitor (Hypervisor) and a first operating system and a second operating system running on the Hypervisor. The first operating system adopts a monolithic kernel architecture, and the second operating system adopts a microkernel architecture. The method includes:

[0007] During the process of running the first operating system and the second operating system on the Hypervisor, the first test information and the second test information are acquired.

[0008] In response to the first test information meeting the corresponding restart conditions, the first operating system is restarted according to the first restart procedure;

[0009] In response to the second test information meeting the corresponding restart conditions, the first operating system is restarted according to the second restart procedure.

[0010] Optionally, the first information to be tested includes the command to be tested and the function to be called;

[0011] The response that the first test information meets the corresponding restart condition, and the first operating system restarts according to the first restart process, includes:

[0012] In response to the command to be tested being a Reboot command, and / or the function to be called being a function indicating that a panic has occurred in the first operating system, the first operating system is restarted according to the first reboot process.

[0013] Optionally, restarting the first operating system according to the first restart procedure includes:

[0014] The first operating system invokes a restart command on the power management module of the vehicle control device;

[0015] The Hypervisor intercepts the reboot command and sends an inter-core interrupt to the physical cores of the first operating system; wherein, the physical cores include a master core and a slave core;

[0016] After receiving the inter-core interrupt, the master core performs data copying and first initialization; after receiving the inter-core interrupt, the slave core is in a waiting-to-wake-up state.

[0017] The master core wakes up the slave core after the first initialization is completed, and the slave core performs a second initialization after being woken up; wherein, the completion of the second initialization indicates that the first operating system has been successfully restarted.

[0018] Optionally, the second information to be tested includes the running status of the first operating system;

[0019] Then, in response to the second test information satisfying the corresponding restart condition, the first operating system is restarted according to the second restart process, including:

[0020] In response to an abnormality in the operating status of the first operating system, the first operating system is restarted according to the second restart procedure.

[0021] Optionally, restarting the first operating system according to the second restart procedure includes:

[0022] The second operating system invokes a virtualization call instruction indicating a restart, and sends the virtualization call instruction to the Hypervisor;

[0023] After receiving the virtualization call instruction, the Hypervisor triggers an SPI interrupt and sends the SPI interrupt to the first operating system.

[0024] After receiving the SPI interrupt, the first operating system restarts itself according to the first restart procedure.

[0025] Optionally, after restarting the first operating system according to the first restart procedure, restarting the first operating system according to the second restart procedure further includes:

[0026] When the first operating system restarts successfully, the Hypervisor sets the flag of the virtualization call instruction to a success flag; or, when the first operating system restarts unsuccessfully, the Hypervisor sets the flag of the virtualization call instruction to a failure flag.

[0027] Optionally, restarting the first operating system according to the second restart procedure further includes:

[0028] The second operating system queries the flag of the virtualization call instruction after a preset time period;

[0029] If the flag of the virtualization call instruction found is the failure flag, the second operating system sends a second virtualization call command to the Hypervisor through the power management module to indicate a forced restart;

[0030] After receiving the second virtualization invocation command, the Hypervisor sends an inter-core interrupt to the physical core of the first operating system; wherein the physical core includes a master core and a slave core;

[0031] After receiving the inter-core interrupt, the master core performs data copying and first initialization; after receiving the inter-core interrupt, the slave core is in a waiting-to-wake-up state.

[0032] The master core wakes up the slave core after the first initialization is completed, and the slave core performs a second initialization after being woken up; wherein, the completion of the second initialization indicates that the first operating system has been successfully restarted.

[0033] Optionally, the execution data copy includes:

[0034] Establish a page table mapping between the data to be backed up and the backup area address;

[0035] Access the data to be backed up based on the page table mapping, and copy the data to be backed up to the target area;

[0036] Delete the page table mapping.

[0037] According to a second aspect of this application, a vehicle control device is provided.

[0038] The vehicle control device includes a virtual machine monitor (Hypervisor) and a first operating system and a second operating system running on the Hypervisor;

[0039] The first lifecycle management module in the first operating system and the second lifecycle management module in the virtual machine monitor (Hypervisor) are used to restart the first operating system in response to the test information meeting the restart conditions.

[0040] Alternatively, the first lifecycle management module in the first operating system, the second lifecycle management module in the Hypervisor, and the third lifecycle management module in the second operating system are used to restart the first operating system.

[0041] According to a third aspect of this application, a vehicle control device is provided, including a memory and a processor; wherein,

[0042] The memory is used to store computer programs;

[0043] The processor is configured to read a computer program stored in the memory and execute the method described in any of the first aspects above according to the computer program in the memory.

[0044] According to a fourth aspect of this application, a vehicle is provided, including the vehicle control device described in the second aspect or the vehicle control device described in the third aspect.

[0045] According to a fifth aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects.

[0046] According to a sixth aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the restart method described in any of the first aspects.

[0047] This application provides a method for restarting a first operating system, applied to a vehicle control device. The vehicle control device includes a virtual machine monitor (Hypervisor) and a first operating system and a second operating system running on the Hypervisor. The first operating system adopts a microkernel architecture, and the second operating system adopts a monolithic kernel architecture. The method includes: during the operation of the first operating system and the second operating system on the Hypervisor, acquiring first test information and second test information; in response to the first test information meeting the corresponding restart conditions, restarting the first operating system according to a first restart procedure; and in response to the second test information meeting the corresponding restart conditions, restarting the first operating system according to a second restart procedure.

[0048] This application, by determining whether the first or second information to be tested meets the corresponding restart conditions, can quickly determine the corresponding restart scheme and restart the first operating system according to the first or second restart procedure. Furthermore, this application implements an independent restart of the first operating system, ensuring that the second operating system is unaffected during the independent restart process and continues to execute control tasks, thereby enhancing the availability and reliability of the vehicle control equipment.

[0049] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0050] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0051] Figure 1 A flowchart illustrating an operating system restart method provided in this application embodiment;

[0052] Figure 2 This is a schematic diagram of the vehicle control device involved in the embodiments of this application;

[0053] Figure 3 This is a schematic diagram of memory distribution provided for an embodiment of this application;

[0054] Figure 4 A flowchart illustrating another operating system restart method provided in this application embodiment;

[0055] Figure 5 A flowchart illustrating another operating system restart method provided in this application embodiment;

[0056] Figure 6 This is a schematic diagram of the structure of a vehicle control device provided in an embodiment of this application;

[0057] Figure 7 This is a schematic diagram of another vehicle control device provided in an embodiment of this application.

[0058] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0059] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0060] In existing technologies, when two operating systems are rebooted, they affect each other. Furthermore, the operating system with higher security requirements is extremely vulnerable to rebooting even when it is fault-free, which can force its tasks to be interrupted.

[0061] Therefore, the existing technology has the following drawbacks:

[0062] (1) Multiple virtual machines running on a Hypervisor restart simultaneously, resulting in low restart efficiency.

[0063] (2) Restarting multiple virtual machines at the same time can easily lead to poor security of fault-free virtual machines.

[0064] (3) The method of restarting multiple virtual machines at the same time is complex.

[0065] To address the aforementioned technical problems, the overall inventive concept of this application is to provide a method for improving the operational reliability of vehicle control equipment, applicable to the field of vehicles.

[0066] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0067] Example 1:

[0068] Figure 1 This is a flowchart illustrating an operating system restart method provided in an embodiment of this application. The operating system restart method is applied to... Figure 2 The vehicle control equipment includes a virtual machine monitor (Hypervisor) and a first operating system and a second operating system running on the Hypervisor.

[0069] The first operating system can be Linux or other embedded operating systems, and it adopts a monolithic kernel architecture. The second operating system can be a real-time operating system (RTOS) or other operating systems that adopt a microkernel architecture.

[0070] It should be understood that a hypervisor is also called a Virtual Machine Monitor (VMM). Both the first and second operating systems are hosted in virtual machines (VMs). For example, the second operating system is hosted in the primary virtual machine, and the first operating system is hosted in the secondary virtual machine.

[0071] In a typical scenario where a vehicle is operating under autonomous driving conditions, the hypervisor runs Linux and an RTOS. Linux is responsible for various autonomous driving algorithms, while the RTOS performs vehicle control tasks. The vehicle control software running on the RTOS has the highest safety level, requiring compliance with the highest automotive functional safety standard, ASIL-D. The algorithms running on Linux, however, have a lower safety level than the vehicle control software. Therefore, in the event of a Linux operating system failure requiring a reboot, this embodiment ensures that the Linux system reboots independently without affecting the RTOS performing vehicle control tasks.

[0072] For example, the rebooting method for the Linux operating system can be applied to the AliOS Drive intelligent driving operating system. Specifically, vehicle control devices can use the AliOS Drive intelligent driving operating system, which features core characteristics such as dual-core driving, layered decoupling, and cross-domain sharing. The hypervisor runs on top of the hardware, while Safety Linux and AliOSRTOS run on top of the hypervisor. For instance, Safety Linux occupies 6 physical cores, and AliOS RTOS occupies 2 physical cores.

[0073] AliOS Drive is driven by a dual-core architecture consisting of AliOS RTOS and AliOS Safety Linux, offering advantages in both safety and performance. Its basic system's safety domain is AliOS RTOS, which meets the highest level of automotive functional safety, "ASIL-D" requirements. The performance domain is AliOS Safety Linux, which provides real-time safety enhancements based on Linux and can support the high-performance computing needs of autonomous driving.

[0074] like Figure 1 As shown, the method in this embodiment includes the following steps:

[0075] S100. During the process of running the first operating system and the second operating system on the Hypervisor, the first test information and the second test information are obtained.

[0076] The first test information is for determining whether to restart the first operating system according to the first restart procedure. The second test information is for determining whether to restart the first operating system according to the second restart procedure.

[0077] The first information to be tested in this embodiment includes, but is not limited to, the command to be tested and the function to be called. The second information to be tested may be the running status of the first operating system or other information to be tested.

[0078] The method provided in this embodiment enables the independent restart of the first operating system when a problem occurs. This method of restarting the first operating system independently offers high efficiency and improves the security of the second operating system.

[0079] In general, taking Linux as the first operating system and RTOS as the second operating system as an example, the process of booting the first operating system after it is shut down is as follows:

[0080] S1. After the hardware is powered on, it jumps to Uboot.

[0081] S2. Uboot copies the kernel image (Kernel), configuration file (dtb), and file system (fs) from the external storage device to a specified address in memory (i.e., the backup area address in Example 2 below).

[0082] S3 and Uboot will redirect to the Hypervisor.

[0083] S4, Hypervisor completes CPU-related initialization.

[0084] S5, the Linux main kernel jumps to Linux to perform early initialization tasks of the Linux operating system, while the slave kernels sleep in the Hypervisor, waiting for the main kernel to wake them up.

[0085] S6. After the main kernel completes the initialization of the corresponding parts, it wakes up the slave kernel via the PSCI command, the slave kernel jumps to the first kernel, and then executes the subsequent initialization tasks of the Linux operating system.

[0086] To enable independent rebooting of the Linux operating system, this embodiment makes the following settings:

[0087] (1) Memory distribution as follows Figure 3 As shown, this embodiment allocates a region in memory as a backup area for backing up the kernel image (Kernel), configuration files (dtb), and file system (fs).

[0088] In this embodiment, a separate memory block is allocated to back up the kernel, file system (FS), and / or data branch (DTB). This block can only be accessed during data copying and is inaccessible under other circumstances due to the lack of mapping, thus improving data security.

[0089] (2) In this embodiment, a kernel module is added to the first operating system and an SPI interrupt is registered in the Hypervisor. After the SPI interrupt is triggered, the shutdown procedure of the first operating system is executed.

[0090] The kernel module added in this embodiment can handle interrupts, thereby enabling the active restart of the first operating system.

[0091] (3) In this embodiment, the backup area information (i.e., the Kernel, DTB and / or FS mentioned above) and the interrupt number of the SPI interrupt are configured through the Hypervisor's DTS. The relevant configuration information in the Hypervisor includes, but is not limited to: whether the reboot function is enabled, the SPI interrupt number used to notify reboot, the kernel image size, the configuration file size, the file system size, the starting address of the file system, the starting address of the backup area, and the size of the backup area.

[0092] It should be noted that the configuration information for the kernel image start address and file system start address already exists, so they will not be configured again here.

[0093] (4) This embodiment can also configure the system so that the Hypervisor can intercept power-related commands of the VM (including restart commands of the power management module below).

[0094] Step 202: In response to the first test information meeting the corresponding restart conditions, restart the first operating system according to the first restart process.

[0095] Step 203: In response to the second test information meeting the corresponding restart conditions, restart the first operating system according to the second restart process.

[0096] The first restart process involves a self-initiated restart by the first operating system. The second restart process is triggered by the second operating system, which notifies the first operating system to restart autonomously; a forced restart is performed if the Linux self-restart fails.

[0097] This embodiment restores the system by restarting the first operating system, without affecting the control tasks executed on the second operating system, thus ensuring system security.

[0098] Based on the above embodiments, the technical solution of this application will be described in more detail below with reference to several specific embodiments.

[0099] Example 2:

[0100] As shown above, the overall restart provided in this embodiment is divided into the following two cases:

[0101] A. The first restart process corresponds to the Linux autonomous restart, which is a restart initiated by Linux itself, and corresponds to the following first restart process.

[0102] B. The second reboot process corresponds to the reboot of Linux by the RTOS. This method is triggered by the RTOS, which notifies Linux to reboot autonomously. If Linux fails to reboot autonomously, a forced reboot is performed, which corresponds to the second reboot process below.

[0103] The restart steps for scenario A are described in detail below:

[0104] In this embodiment, if the first information to be tested includes a command to be tested and a function to be called, then step S100, responding to the first information to be tested satisfying the restart condition, restarts the first operating system according to the first restart process, including:

[0105] In response to the command under test being the Reboot command, and / or the function under test being a function indicating a panic in the first operating system, the first operating system restarts according to the first reboot procedure. This first reboot procedure can be understood as an autonomous reboot procedure.

[0106] For example, if the user enters the Reboot command in the command-line shell of the first operating system, or the first operating system restarts itself under other abnormal circumstances; or, after Panic, the first operating system initiates a restart operation on its own.

[0107] The autonomous restart process provided in this embodiment can restore the system by restarting the first operating system separately, without affecting the control tasks executed on the second operating system, thus ensuring the system's security.

[0108] This embodiment combines Figure 4 The following analysis is performed on the autonomous restart process:

[0109] Figure 4 This is a flowchart illustrating another method for restarting a first operating system provided in an embodiment of this application. Figure 1 Based on the illustrated embodiment, this embodiment focuses on Figure 1 The S100 in the text is further refined. For example... Figure 4 As shown, the method in this embodiment includes:

[0110] S41. The first operating system calls the restart command of the power management module in the vehicle control device.

[0111] It should be understood that the Power State Coordination Interface (PSCI) is a standard interface for power management in vehicle control equipment. This interface, also known as the power management module or restart-related interface, is used to send or receive shutdown commands and restart commands. The restart-related interface is the shutdown interface of the first operating system kernel; it can be obtained by directly referencing the header file and making function calls.

[0112] It should be noted that the restart command of the power management module in this embodiment is the PSCI command, which is used to indicate a command to restart the first operating system separately.

[0113] In other words, step S41 involves the first operating system calling the restart-related interface, and ultimately calling the PSCI restart command.

[0114] S42, the Hypervisor intercepts the reboot command and sends an inter-core interrupt to the physical cores of the first operating system; the physical cores include the master core and the slave cores.

[0115] After the first operating system invokes the PSCI reboot command, the hypervisor intercepts the corresponding PSCI command and sends an inter-core interrupt to all other physical cores of the first operating system. In this embodiment, the number of physical cores in a CPU is determined by hardware.

[0116] After step S42, the Hypervisor takes over the entire system. All cores run Hypervisor code and no longer run VM code, which can be understood as the VM shutting down.

[0117] S43. After receiving an inter-core interrupt, the master core performs data copying and initialization; after receiving an inter-core interrupt, the slave core is in a waiting-to-wake-up state.

[0118] Step S43 includes three steps: performing data copying, initial initialization, and state change from the kernel.

[0119] Regarding data copying, this embodiment analyzes it as follows:

[0120] In general, in this embodiment, the first CPU in the system is set as the master core and the other CPUs are slave cores. After the master core receives an inter-core interrupt, it copies the kernel / fs / dtb data in the backup area back to the original area. The original area refers to a specified / fixed location in the VM memory.

[0121] For the first initialization, this embodiment analyzes it as follows:

[0122] In this embodiment, all CPU-related registers (e.g., interrupt status register, exception status register, etc.) are reset, the CPU state is reset, the relevant status bits are cleared, and then the first operating system is started.

[0123] Regarding state changes from the kernel, this embodiment analyzes the following:

[0124] After receiving an inter-core interrupt, the kernel waits for the main core to wake it up.

[0125] S44. After the primary core completes the first initialization, it wakes up the secondary core, which then performs the second initialization. The completion of the second initialization indicates that the first operating system has successfully restarted. In other words, after step S44 is executed, the first operating system boot process is complete.

[0126] In this step, after the main core completes initialization, it wakes up the slave core, resets the relevant registers, and jumps to the first operating system. During this step, the slave core can repeatedly check a variable; if the variable is 0, it continues to wait; if it is 1, it resets the registers and jumps to the first operating system. In other words, the main core sets this variable to 1 after initializing to a certain stage, which is the wake-up process.

[0127] It should be understood that in a multi-core system, each core has its own set of registers, and each core resets its own registers.

[0128] In this embodiment, the Hypervisor code was originally being executed. Now, the PC pointer is assigned the VM's startup address, and the VM's code can be started by using an instruction (e.g., eret in Ram64).

[0129] This embodiment intercepts the restart command of the power management module and jumps back to start the VM after data recovery. This enables the VM to be restarted independently without affecting the control tasks executed on the second operating system, thus ensuring system security.

[0130] In one possible implementation, in step S43, performing a data copy includes:

[0131] S431. Establish a page table mapping between the data to be backed up and the backup area address.

[0132] S432. Access the data to be backed up based on page table mapping and copy the data to be backed up to the target area.

[0133] S433, Delete page table mapping.

[0134] It should be understood that the data to be backed up refers to kernel / fs / dtb data, which represents the specific contents of the kernel image (Kernel), configuration files (dtb), and / or file system (fs).

[0135] This embodiment uses data backup, avoiding the need to add a disk driver in the Hypervisor, and is faster.

[0136] Alternatively, this embodiment can also replace the backup method by reading the image from the disk during restart, protecting the original data and ensuring data integrity and reproducibility.

[0137] Before copying the kernel / fs / dtb data, this embodiment establishes a page table mapping. After the copy is completed, the page table mapping is deleted. In other cases, neither the Hypervisor nor the VM can access the backup area. During the restart process, this embodiment does not restart the entire system. It intercepts the PSCI command and only restarts the CPU of this VM, without affecting the normal operation of other VMs, thus improving system security.

[0138] Example 3:

[0139] The overall restart provided in this embodiment is divided into the following two cases:

[0140] A. The first operating system restarts autonomously. This autonomous restart method is a restart initiated autonomously by the first operating system, corresponding to the following first restart process.

[0141] B. The second operating system restarts the first operating system. This method is triggered by the second operating system, which notifies the first operating system to restart automatically. If the first operating system fails to restart automatically, a forced restart is performed, corresponding to the second restart process below.

[0142] The restart steps for scenario B are described in detail below:

[0143] In this embodiment, if the second information to be tested includes the running status of the first operating system, then step S100, in response to the second information to be tested satisfying the corresponding restart condition, restarting the first operating system, includes:

[0144] In response to an anomaly in the operating status of the first operating system, the first operating system is restarted according to the second restart procedure.

[0145] In intelligent driving systems, a second operating system with a higher safety level monitors the operating status of the first operating system. If the first operating system is found to be in an abnormal operating status, the second operating system can initiate a restart.

[0146] This embodiment prioritizes the autonomous restart method of the first operating system. If the autonomous restart fails, a forced restart is then performed, ensuring the effectiveness of the restart and improving system security.

[0147] This embodiment combines Figure 5 The second restart process, consisting of a self-restart process and / or a forced restart process, is analyzed as follows:

[0148] Figure 5 This is a flowchart illustrating another operating system restart method provided in an embodiment of this application. Figure 1 Based on the illustrated embodiment, this embodiment focuses on Figure 1 The S100 in the text is further refined. For example... Figure 5 As shown, the method in this embodiment includes:

[0149] S51, the second operating system calls the virtualization call instruction indicating a restart and sends the virtualization call instruction to the Hypervisor.

[0150] It should be understood that virtualization call instructions, or HVC commands, are used to implement system calls from the VM to the Hypervisor.

[0151] After receiving the virtualization call instruction, the S52 Hypervisor triggers an SPI interrupt and sends the SPI interrupt to the first operating system.

[0152] S53. After receiving the SPI interrupt, the first operating system restarts the first operating system according to the first restart procedure.

[0153] During step S53, when the first operating system is restarted according to the first restart process, this embodiment sends an inter-core interrupt to other cores besides the first operating system itself.

[0154] This embodiment prioritizes the autonomous restart method of the first operating system, which improves restart efficiency.

[0155] One possible implementation, after restarting the first operating system according to the first restart procedure, further includes restarting the first operating system according to the second restart procedure, and includes:

[0156] S54. When the first operating system restarts successfully, the Hypervisor sets the flag of the virtualization call instruction to the success flag; or, when the first operating system restarts unsuccessfully, the Hypervisor sets the flag of the virtualization call instruction to the failure flag.

[0157] This embodiment ensures the effectiveness of the restart by setting a flag, thereby improving system security.

[0158] One possible implementation is, such as Figure 5 As shown, restarting the first operating system according to the second restart procedure also includes:

[0159] S55. The second operating system queries the flag of the virtualization call instruction after a preset time.

[0160] S56. If the flag of the queried virtualization call command is a failure flag, the second operating system sends a second virtualization call command to the Hypervisor through the power management module to indicate a forced restart.

[0161] After receiving the second virtualization call command, the Hypervisor sends an inter-core interrupt to the physical cores of the first operating system; the physical cores include the master core and the slave cores.

[0162] S58. After receiving an inter-core interrupt, the master core performs data copying and initialization; after receiving an inter-core interrupt, the slave core is in a waiting-to-wake-up state.

[0163] The data copying process in step S58 is described in steps S431 to S433 of the above embodiment 2, and will not be repeated here.

[0164] S59. After the primary core completes the first initialization, it wakes up the secondary core. After being woken up, the secondary core performs the second initialization. The completion of the second initialization indicates that the primary operating system has successfully restarted.

[0165] This embodiment prioritizes the autonomous restart method of the first operating system. If the autonomous restart fails, a forced restart is then performed, ensuring the effectiveness of the restart and improving system security.

[0166] For ease of understanding, steps S51 to S59 above can be rephrased as the following process:

[0167] a. The second operating system calls the HVC command to restart.

[0168] b. After receiving the HVC command, the Hypervisor triggers the previously configured SPI restart interrupt.

[0169] SPI interrupt refers to shared external interrupt, used for peripheral notification; inter-core interrupt is used for interrupts between two CPU cores.

[0170] c. After receiving the SPI interrupt, the first operating system performs an autonomous reboot. The autonomous reboot steps are the same as steps S41 to S44 in Example 2. The difference is that Example 2 reboots by having the user enter "reboot" in the shell, while in Example 3, the kernel module calls the shell to reboot the first operating system.

[0171] d. If the first operating system starts successfully, this embodiment sets a success flag in the Hypervisor via HVC.

[0172] e. Since the second operating system is unsure whether it has succeeded, after a preset period of time (configurable), the second operating system queries the first operating system via HVC to see if it has successfully restarted.

[0173] In other words, the HVC of the first operating system is mainly used to set the success flag; the second operating system uses the flag bit to determine whether the boot was successful.

[0174] f. If unsuccessful, the second operating system initiates a forced restart by sending a forced restart command via HVC. This embodiment does not specifically limit the factors that may lead to failure, as both hardware and software problems can cause boot failure.

[0175] g. After receiving the forced reboot command, the Hypervisor sends an inter-core interrupt to all cores of the first operating system.

[0176] h. After receiving an inter-core interrupt, the primary kernel of the first operating system copies the kernel / fs / dtb data from the backup area back to the original area.

[0177] i. Reset the relevant registers and then jump to the first operating system to start.

[0178] j. After receiving the command from the kernel, the first operating system waits for the main kernel to wake it up.

[0179] k. The master core wakes up the slave core, resets the relevant registers, and jumps to the first operating system.

[0180] 1. Complete the startup of the first operating system.

[0181] This embodiment prioritizes the autonomous restart method of the first operating system. If the autonomous restart fails, a forced restart is then performed, ensuring the effectiveness of the restart and improving system security.

[0182] Optionally, in this embodiment, a forced restart can be performed directly in the second restart process, which can improve restart efficiency.

[0183] Example 4:

[0184] Figure 6 This is a schematic diagram of a vehicle control device provided in an embodiment of this application. The vehicle control device includes a virtual machine monitor (Hypervisor), a first operating system, and a real-time operating system (Second Operating System) running on the Hypervisor.

[0185] The first lifecycle management module in the first operating system and the second lifecycle management module in the Hypervisor are used to restart the first operating system in response to the test information meeting the restart conditions.

[0186] Alternatively, the first lifecycle management module in the first operating system, the second lifecycle management module in the Hypervisor, and the third lifecycle management module in the second operating system are used to restart the first operating system.

[0187] pass Figure 6 It can be seen that the first operating system, the second operating system, and the Hypervisor all contain corresponding lifecycle management modules.

[0188] The first lifecycle management module in the first operating system is mainly used for active restart, and for active restart when receiving an SPI interrupt triggered by the second operating system.

[0189] The third lifecycle management module in the second operating system is mainly used to initiate the restart command of the first operating system and diagnose whether the first operating system has been successfully restarted (corresponding to the description in steps S54 to S56 above).

[0190] The second lifecycle management module in the hypervisor includes, but is not limited to: a PSCI command processing unit, an HVC command processing unit, an SPI interrupt triggering unit, an inter-core interrupt triggering unit, and a data backup and recovery unit. Specifically, the HVC command processing unit processes HVC commands; the PSCI command processing unit processes power management-related commands (i.e., PSCI commands); the SPI interrupt triggering unit triggers SPI interrupts; the inter-core interrupt triggering unit triggers inter-core interrupts; and the data backup and recovery unit performs data backup and recovery.

[0191] All process architectures in this application embodiment can be implemented using the C language to achieve the best results.

[0192] The vehicle control device provided in this embodiment can be used to execute the restart method of the first operating system provided in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0193] It should be noted that the user information and data involved in this application (including but not limited to data used for analysis, stored data, and displayed data) are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0194] In other words, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0195] According to embodiments of this application, this application also provides another vehicle control device, a vehicle, a readable storage medium, and a computer program product.

[0196] Figure 7 This is a schematic diagram of another vehicle control device provided in an embodiment of this application. The vehicle control device includes a receiver 70, a transmitter 71, at least one processor 72, and a memory 73. The vehicle control device composed of the above components can be used to implement the above-mentioned specific embodiments of this application, which will not be described in detail here.

[0197] This application also provides a vehicle that includes any of the above-described vehicle control devices.

[0198] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the methods described above.

[0199] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the various steps in the methods provided in the above embodiments.

[0200] Various embodiments of the systems and technologies described above in this application can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0201] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or electronic device.

[0202] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be a machine-readable signal medium or a machine-readable storage medium. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of computer-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0203] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0204] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as data electronic devices), or computing systems that include middleware components (e.g., application electronic devices), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0205] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0206] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this application should be included within the scope of protection of this application.

Claims

1. A method for restarting an operating system, characterized in that, The method is applied to vehicle control equipment, which includes a virtual machine monitor (Hypervisor) and a first operating system and a second operating system running on the Hypervisor. The first operating system adopts a monolithic kernel architecture, and the second operating system adopts a microkernel architecture. During the process of running the first operating system and the second operating system on the Hypervisor, first test information and second test information are obtained, wherein the first test information includes the test command and the test call function, and the second test information includes the running status of the first operating system; In response to the first test information meeting the corresponding restart conditions, the first operating system is restarted according to the first restart process; wherein, in the first restart process, the Hypervisor intercepts the restart command of the first operating system calling the power management module in the vehicle control device to control the restart of the first operating system; In response to the second test information meeting the corresponding restart conditions, the first operating system is restarted according to the second restart process; wherein, in the second restart process, the Hypervisor receives a virtualization call instruction indicating a restart from the second operating system to control the restart of the first operating system.

2. The method according to claim 1, characterized in that, The first information to be tested includes the command to be tested and the function to be called; The response that the first test information meets the corresponding restart condition, and the first operating system restarts according to the first restart process, includes: In response to the command to be tested being a Reboot command, and / or the function to be called being a function indicating that a panic has occurred in the first operating system, the first operating system is restarted according to the first reboot process.

3. The method according to claim 2, characterized in that, The step of restarting the first operating system according to the first restart procedure includes: The first operating system invokes a restart command on the power management module of the vehicle control device; The Hypervisor intercepts the reboot command and sends an inter-core interrupt to the physical cores of the first operating system; wherein, the physical cores include a master core and a slave core; After receiving the inter-core interrupt, the master core performs data copying and first initialization; after receiving the inter-core interrupt, the slave core is in a waiting-to-wake-up state. The master core wakes up the slave core after the first initialization is completed, and the slave core performs a second initialization after being woken up; wherein, the completion of the second initialization indicates that the first operating system has been successfully restarted.

4. The method according to claim 2, characterized in that, The second information to be tested includes the running status of the first operating system; Then, in response to the second test information satisfying the corresponding restart condition, the first operating system is restarted according to the second restart process, including: In response to an abnormality in the operating status of the first operating system, the first operating system is restarted according to the second restart procedure.

5. The method according to claim 4, characterized in that, The process of restarting the first operating system according to the second restart procedure includes: The second operating system invokes a virtualization call instruction indicating a restart, and sends the virtualization call instruction to the Hypervisor; After receiving the virtualization call instruction, the Hypervisor triggers an SPI interrupt and sends the SPI interrupt to the first operating system. After receiving the SPI interrupt, the first operating system restarts itself according to the first restart procedure.

6. The method according to claim 5, characterized in that, After restarting the first operating system according to the first restart procedure, restarting the first operating system according to the second restart procedure further includes: When the first operating system restarts successfully, the Hypervisor sets the flag of the virtualization call instruction to a success flag; or, when the first operating system restarts unsuccessfully, the Hypervisor sets the flag of the virtualization call instruction to a failure flag.

7. The method according to claim 6, characterized in that, The process of restarting the first operating system according to the second restart procedure also includes: The second operating system queries the flag of the virtualization call instruction after a preset time period; If the flag of the virtualization call instruction found is the failure flag, the second operating system sends a second virtualization call command to the Hypervisor through the power management module to indicate a forced restart; After receiving the second virtualization invocation command, the Hypervisor sends an inter-core interrupt to the physical core of the first operating system; wherein the physical core includes a master core and a slave core; After receiving the inter-core interrupt, the master core performs data copying and first initialization; after receiving the inter-core interrupt, the slave core is in a waiting-to-wake-up state. The master core wakes up the slave core after the first initialization is completed, and the slave core performs a second initialization after being woken up; wherein, the completion of the second initialization indicates that the first operating system has been successfully restarted.

8. The method according to claim 3 or 7, characterized in that, The execution data copy includes: Establish a page table mapping between the data to be backed up and the backup area address; Access the data to be backed up based on the page table mapping, and copy the data to be backed up to the target area; Delete the page table mapping.

9. A vehicle control device, characterized in that, The vehicle control device includes a virtual machine monitor (Hypervisor) and a first operating system and a second operating system running on the Hypervisor; The first lifecycle management module in the first operating system and the second lifecycle management module in the hypervisor are used to restart the first operating system according to the first restart process in response to the first test information meeting the corresponding restart conditions; wherein... The first information to be tested includes a command to be tested and a function to be called; in response to the command to be tested being a Reboot command, and / or the function to be called being a function used to indicate that a panic has occurred in the first operating system, the first operating system is restarted according to the first reboot process; The step of restarting the first operating system according to the first restart procedure includes: The first operating system invokes a restart command on the power management module of the vehicle control device; The Hypervisor intercepts the restart command from the first operating system calling the power management module in the vehicle control device and sends an inter-core interrupt to the physical core of the first operating system; wherein, the physical core includes a master core and a slave core; After receiving the inter-core interrupt, the master core performs data copying and first initialization; after receiving the inter-core interrupt, the slave core is in a waiting-to-wake-up state. The master core wakes up the slave core after the first initialization is completed, and the slave core performs a second initialization after being woken up; wherein, the completion of the second initialization indicates that the first operating system has successfully restarted; or, The first lifecycle management module in the first operating system, the second lifecycle management module in the hypervisor, and the third lifecycle management module in the second operating system are used to restart the first operating system according to the second process in response to the second test information meeting the corresponding restart conditions; wherein... The second information to be tested includes the running status of the first operating system; in response to an abnormality in the running status of the first operating system, the first operating system is restarted according to the second restart procedure; The process of restarting the first operating system according to the second restart procedure includes: The second operating system invokes a virtualization call instruction indicating a restart, and sends the virtualization call instruction to the Hypervisor; After receiving the virtualization call instruction, the Hypervisor triggers an SPI interrupt and sends the SPI interrupt to the first operating system; After receiving the SPI interrupt, the first operating system restarts itself according to the first restart procedure.

10. A vehicle control device, characterized in that, Includes memory and processor; among which, The memory is used to store computer programs; The processor is configured to read a computer program stored in the memory and execute the method described in any one of claims 1 to 8 according to the computer program in the memory.

11. A vehicle, characterized in that, This includes the vehicle control device as described in claim 9 or the vehicle control device as described in claim 10.

12. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the method described in any one of claims 1 to 8.

Images