Restarting method of operating system, vehicle control equipment, vehicle, medium and product

Abstract

The invention provides a restarting method of an operating system, vehicle control equipment, a vehicle, a medium and a product, and relates to the technical field of vehicles. The method is applied to the vehicle control equipment, the vehicle control equipment comprises a virtual machine monitor, a first operating system and a second operating system, the first operating system and the second operating system run on the virtual machine monitor, the first operating system adopts a micro-kernel architecture, and the second operating system adopts a macro-kernel architecture. The method comprises the following steps: acquiring first to-be-tested information and second to-be-tested information in a process of running a first operating system and a second operating system on a virtual machine monitor; in response to the condition that the first to-be-tested information meets the corresponding restart condition, restarting the first operating system according to a first restart process; and restarting the first operating system according to a second restarting process in response to the condition that the second to-be-tested information meets the corresponding restarting condition. According to the mode, the independent restart of the first operating system can be realized, the continuous execution of the control task by the second operating system is not influenced, and the running reliability of the vehicle control equipment is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to an operating system restart method, vehicle control equipment, vehicle, medium and product. Background Art

[0002] Self-driving cars and intelligent connected cars have developed into complex devices that integrate multiple systems and multiple software and hardware. In order to achieve autonomous driving, vehicle control devices with dual operating systems are generally installed. The dual operating systems have different tasks and therefore have different safety requirements.

[0003] In the prior art, when the dual operating systems are restarted, the two affect each other, and the operating system with higher security requirements is extremely susceptible to the impact of the restart in the absence of faults, resulting in forced interruption of its tasks.

[0004] Therefore, the prior art has the problem of low operational reliability of vehicle control equipment. Summary of the invention

[0005] The present application provides an operating system restart method, vehicle control equipment, vehicle, medium and product to solve the problem of low operating reliability of vehicle equipment.

[0006] According to a first aspect of the present application, a method for restarting a first operating system is provided, which is applied to a vehicle control device, wherein the vehicle control device includes a virtual machine monitor Hypervisor, and a first operating system and a second operating system running on the Hypervisor, wherein the first operating system adopts a macro kernel architecture, and the second operating system adopts a micro kernel architecture, and the method includes:

[0007] In the process of running the first operating system and the second operating system on the Hypervisor, obtaining first information to be tested and second information to be tested;

[0008] In response to the first information to be tested satisfying a corresponding restart condition, restarting the first operating system according to a first restart process;

[0009] In response to the second information to be tested satisfying the corresponding restart condition, the first operating system is restarted according to a second restart process.

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

[0011] Then, in response to the first information to be tested satisfying the corresponding restart condition, restarting the first operating system according to a first restart process includes:

[0012] In response to the command to be tested being a Reboot command, and / or the calling function to be tested being a function used to indicate that a panic occurs in the first operating system, the first operating system is restarted according to a first restart process.

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

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

[0015] The Hypervisor intercepts the restart command 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;

[0016] After receiving the inter-core interrupt, the master core executes data copy and performs first initialization; after receiving the inter-core interrupt, the slave core is in a state of waiting for wake-up;

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

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

[0019] Then, in response to the second information to be tested satisfying the corresponding restart condition, restarting the first operating system according to a second restart process includes:

[0020] In response to an abnormality in the running state of the first operating system, the first operating system is restarted according to a second restart process.

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

[0022] The second operating system calls a virtualization call instruction indicating 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 the first operating system according to a first restart process.

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

[0026] When it is determined that the first operating system is restarted successfully, the Hypervisor sets the flag of the virtualization call instruction to a success flag; or when the first operating system fails to restart, 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 process 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 calling instruction queried is the failure flag, the second operating system sends a second virtualization calling command for indicating a forced restart to the Hypervisor through the power management module;

[0030] After receiving the second virtualization call 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 executes data copy and performs first initialization; after receiving the inter-core interrupt, the slave core is in a state of waiting for wake-up;

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

[0033] Optionally, the executing data copy includes:

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

[0035] Accessing the data to be backed up based on the page table mapping, and copying the data to be backed up to a target area;

[0036] The page table mapping is deleted.

[0037] According to a second aspect of the present 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 information to be tested meeting the restart condition;

[0040] Or, the first lifecycle management module in the first operating system, the second lifecycle management module in the virtual machine monitor 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 the present application, a vehicle control device is provided, comprising a memory and a processor; wherein:

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

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

[0044] According to a fourth aspect of the present application, a vehicle is provided, comprising 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 the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the method described in any one of the first aspects.

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

[0047] A restart method for a first operating system provided in the present application is applied to a vehicle control device, wherein the vehicle control device includes a virtual machine monitor Hypervisor, and a first operating system and a second operating system running on the Hypervisor, wherein the first operating system adopts a microkernel architecture, and the second operating system adopts a macrokernel architecture, and the method includes: in the process of running the first operating system and the second operating system on the Hypervisor, obtaining first information to be tested and second information to be tested; in response to the first information to be tested satisfying a corresponding restart condition, restarting the first operating system according to a first restart process; in response to the second information to be tested satisfying a corresponding restart condition, restarting the first operating system according to a second restart process.

[0048] This application can quickly determine the corresponding restart scheme by judging whether the first information to be tested or the second information to be tested meets the corresponding restart condition, and restart the first operating system according to the first restart process or the second restart process. In addition, this application implements the independent restart of the first operating system, which can ensure that during the independent restart process of the first operating system, the second operating system is not affected by it and continues to execute the control task, thereby enhancing the availability of the vehicle control device and improving the reliability of the operation of the vehicle control device.

[0049] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0051] Figure 1 A flowchart of a method for restarting an operating system provided in an embodiment of the present application;

[0052] Figure 2 A schematic diagram of a vehicle control device involved in an embodiment of the present application;

[0053] Figure 3 A schematic diagram of memory distribution provided for an embodiment of the present application;

[0054] Figure 4 A flowchart of another operating system restart method provided in an embodiment of the present application;

[0055] Figure 5 A flowchart of another operating system restart method provided in an embodiment of the present application;

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

[0057] Figure 7 A schematic diagram of the structure of another vehicle control device provided in an embodiment of the present application.

[0058] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0059] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0060] In the prior art, when the dual operating systems are restarted, the two affect each other, and the operating system with higher security requirements is extremely susceptible to the impact of the restart in the absence of faults, resulting in forced interruption of its tasks.

[0061] Therefore, the prior art has the following disadvantages:

[0062] (1) Multiple virtual machines running on a hypervisor are restarted at the same time, resulting in low restart efficiency.

[0063] (2) The method of 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 operationally complex.

[0065] In order to solve the above technical problems, the overall inventive concept of the present application is to provide a method for improving the operational reliability of vehicle control equipment in the vehicle field.

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

[0067] Embodiment 1:

[0068] Figure 1 A flowchart of a method for restarting an operating system provided in an embodiment of the present application. The method for restarting an operating system is applied to Figure 2 The vehicle control device 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 may be a Linux operating system or other embedded operating systems, and the first operating system adopts a macro kernel architecture. The second operating system may be a real-time operating system (RTOS) or other operating systems adopting a micro kernel architecture.

[0070] It should be understood that Hypervisor is also called Virtual Machine Monitor (VMM). The first operating system and the second operating system are both hosted in a virtual machine (VM). For example, the second operating system is hosted in a master virtual machine, and the first operating system is hosted in a slave virtual machine.

[0071] When the vehicle is in intelligent driving, a typical scenario is that Linux and RTOS run on the Hypervisor, Linux is responsible for various autonomous driving algorithms, and RTOS performs vehicle control tasks. The vehicle control software running on the RTOS has the highest safety level and needs to meet the requirements of "ASIL-D", the highest level of automotive functional safety. The algorithm run by Linux has a lower safety level than the vehicle control software. Therefore, when the Linux operating system fails and needs to be restarted, this embodiment can ensure that the Linux system restarts alone and does not affect the RTOS that is performing vehicle control tasks.

[0072] Exemplarily, the restart method of the Linux operating system can be applied to the AliOS Drive intelligent driving operating system. Specifically, the vehicle control device can adopt the AliOS Drive intelligent driving operating system, which has core features such as dual-core drive, layered decoupling, and cross-domain sharing. Hypervisor runs on hardware, and Safety Linux and AliOSRTOS run on Hypervisor. For example, Safety Linux occupies 6 physical cores and AliOS RTOS occupies 2 physical cores.

[0073] AliOS Drive is a dual-core drive composed of AliOS RTOS and AliOS Safety Linux, which combines the advantages of safety and performance. The safety domain of its basic system is AliOS RTOS, which can meet the highest level of automotive functional safety "ASIL-D" requirements; the performance domain is AliOS Safety Linux, which performs 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 of this embodiment includes the following steps:

[0075] S100: Acquire first information to be tested and second information to be tested during the process of running a first operating system and a second operating system on a Hypervisor.

[0076] The first information to be tested is information to be tested for determining whether to restart the first operating system according to the first restart process. The second information to be tested is information to be tested for determining whether to restart the first operating system according to the second restart process.

[0077] The first information to be tested in the embodiment of the present application includes but is not limited to: a command to be tested and a calling function to be tested. The second information to be tested may be the running state of the first operating system or other information to be tested.

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

[0079] Generally speaking, taking the first operating system as a Linux operating system and the second operating system as an RTOS as an example, the process of starting the first operating system after the first operating system is shut down is as follows:

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

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

[0082] S3, Uboot jumps to Hypervisor.

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

[0084] S5, the Linux master core jumps to Linux and executes the early initialization tasks of the Linux operating system. The slave core sleeps in the Hypervisor and waits for the master core to wake up.

[0085] S6. After the master core initializes the corresponding part, it wakes up the slave core through the PSCI command, and the slave core jumps to the first, and then executes the subsequent initialization tasks of the Linux operating system.

[0086] To achieve independent restart of the Linux operating system, this embodiment performs the following settings:

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

[0088] This embodiment allocates a separate piece of memory to back up kernel, fs and / or dtb, which can be accessed only when data is copied and cannot be accessed without mapping in other cases, thereby 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 program of the first operating system is executed.

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

[0091] (3) This embodiment configures the backup area information (i.e., the above-mentioned Kernel, dtb, and / or fs) and the interrupt number of the SPI interrupt through the dts of the Hypervisor. The relevant configuration information in the Hypervisor includes, but is not limited to: whether to enable the restart function, the SPI interrupt number used to notify the restart, 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, the size of the backup area, etc.

[0092] It should be noted that the configuration information of the kernel image start address and the file system start address already exists and is not repeated here.

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

[0094] Step 202: in response to the first information to be tested satisfying a corresponding restart condition, restart the first operating system according to a first restart process.

[0095] Step 203: In response to the second information to be tested satisfying the corresponding restart condition, restart the first operating system according to a second restart process.

[0096] The first restart process is an autonomous restart of the first operating system, which is a restart initiated autonomously by the first operating system. The second restart process is triggered by the second operating system, notifying the first operating system to restart autonomously; after the Linux autonomous restart fails, a forced restart is performed.

[0097] This embodiment realizes system recovery by restarting the first operating system without affecting the control tasks executed on the second operating system, thereby ensuring the security of the system.

[0098] Based on the above embodiments, the technical solution of the present application is described in more detail below in combination with several specific embodiments.

[0099] Embodiment 2:

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

[0101] A. The restart corresponding to the first restart process is Linux autonomous restart. This autonomous restart mode is a restart initiated by Linux autonomously, corresponding to the following first restart process.

[0102] B. The restart corresponding to the second restart process is that the RTOS restarts Linux. This method is triggered by the RTOS and notifies Linux to restart autonomously. After the Linux autonomous restart fails, a forced restart is performed, which corresponds to the following second restart process.

[0103] The following are detailed descriptions of the restart steps in case A:

[0104] In this embodiment, if the first information to be tested includes a command to be tested and a calling function to be tested, step S100, in response to the first information to be tested satisfying the restart condition, restarting the first operating system according to the first restart process, includes:

[0105] In response to the command to be tested being a Reboot command, and / or the calling function to be tested being a function used to indicate that a panic occurs in the first operating system, the first operating system is restarted according to a first restart process. The first restart process can be understood as an autonomous restart process.

[0106] For example, a user enters a Reboot command in the command line shell of the first operating system, or the first operating system restarts autonomously in other abnormal situations; for example, after a panic, the first operating system autonomously initiates a restart operation.

[0107] The autonomous restart process provided in this embodiment can realize system recovery by restarting the first operating system alone without affecting the control tasks executed on the second operating system, thereby ensuring the security of the system.

[0108] This embodiment combines Figure 4 The autonomous restart process is analyzed as follows:

[0109] Figure 4 A flowchart of another method for restarting a first operating system provided in an embodiment of the present application. Figure 1 Based on the embodiment shown, this embodiment focuses on Figure 1 The S100 in the Figure 4 As shown, the method of this embodiment includes:

[0110] S41. The first operating system calls a restart command of a 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 a set of vehicle control devices. This interface may be called a power management module, a restart-related interface, etc., and is used to send or receive shutdown commands, restart commands, etc. The restart-related interface is the first operating system kernel shutdown interface, which can be obtained by directly referencing the header file and making a function call.

[0112] It should be noted that the restart command of the power management module in the embodiment of the present application is a PSCI command, which is used to represent a command for restarting the first operating system alone.

[0113] That is to say, step S41 implements the first operating system calling the restart related interface and finally calling the restart command of the PSCI.

[0114] S42. The Hypervisor intercepts the restart command 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.

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

[0116] After step S42, the Hypervisor takes over the entire system, and all cores run the Hypervisor code instead of the VM code, which can be understood as the VM being shut down.

[0117] S43, after receiving the inter-core interrupt, the master core executes data copy and performs the first initialization; after receiving the inter-core interrupt, the slave core is in a state of waiting for wake-up.

[0118] Step S43 includes three steps: executing data copy, first initialization, and performing state change from the core.

[0119] Regarding data copying, this embodiment performs the following analysis:

[0120] Generally, in this embodiment, the first CPU in the system is assumed to be 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, which refers to a specified / fixed location in the VM memory.

[0121] For the first initialization, this embodiment performs the following analysis:

[0122] This embodiment resets (ie, resets) all registers related to the CPU (eg, interrupt status register, exception status register, etc.), resets the CPU status, clears related status bits, and then jumps to start the first operating system.

[0123] With respect to the state change of the slave core, this embodiment performs the following analysis:

[0124] After receiving the inter-core interrupt, the slave core waits for the master core to wake up.

[0125] S44, the master core wakes up the slave core after the first initialization is completed, and the slave core performs the second initialization after waking up; wherein the completion of the second initialization indicates that the first operating system is successfully restarted. That is, after step S44 is executed, the first operating system is started.

[0126] In this step, the master core wakes up the slave core after initialization is completed, resets the relevant registers, and jumps to the first operating system. In this step, the slave core can cyclically determine a variable. If the variable is 0, it continues to wait. If it is 1, it resets the register and jumps to the first operating system. In other words, the master core sets the variable to 1 after initialization to a certain stage, which is wake-up.

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

[0128] In this embodiment, the Hypervisor code is originally executed, and now the PC pointer is assigned to the startup address of the VM, and then the VM code can be started to be executed through an instruction (for example, eret in Ram64).

[0129] This embodiment intercepts the restart command of the power management module and restarts the VM again after restoring the data, so that the VM can be restarted separately without affecting the control tasks executed on the second operating system, thereby ensuring the security of the system.

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

[0131] S431, establishing 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 the page table mapping, and copy the data to be backed up to the target area.

[0133] S433, delete the 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 content in the kernel image (Kernel), the configuration file (dtb) and / or the file system (fs).

[0135] This embodiment adopts a data backup method, avoids adding a disk drive in the Hypervisor, and has a higher speed.

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

[0137] Before the above-mentioned kernel / fs / dtb data is copied, this embodiment establishes a page table mapping, and deletes the page table mapping after the copy is completed. 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, intercepts the PSCI command, and only restarts the CPU of this VM, which does not affect the normal operation of other VMs and improves system security.

[0138] Embodiment 3:

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

[0140] A. The first operating system autonomously restarts. The autonomous restart mode 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 autonomously. After the first operating system fails to restart autonomously, a forced restart is performed, corresponding to the following second restart process.

[0142] The following are detailed descriptions of the restart steps in case B:

[0143] In this embodiment, if the second information to be tested includes the running state of the first operating system, 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 abnormality in the running state of the first operating system, the first operating system is restarted according to a second restart process.

[0145] In the intelligent driving system, a second operating system with a higher security level monitors the running status of the first operating system. If the running status of the first operating system is found to be abnormal, the second operating system may also initiate a restart.

[0146] This embodiment preferentially adopts the autonomous restart mode of the first operating system, and if the autonomous restart fails, a forced restart is performed, thereby ensuring the effectiveness of the restart and improving the security of the system.

[0147] This embodiment combines Figure 5 The second restart process consisting of the autonomous restart process and / or the forced restart process is analyzed as follows:

[0148] Figure 5 A flowchart of another operating system restart method provided in an embodiment of the present application. Figure 1 Based on the embodiment shown, this embodiment focuses on Figure 1 The S100 in the Figure 5 As shown, the method of this embodiment includes:

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

[0150] It should be understood that the virtualization call instruction or HVC command is used to implement a system call from a VM to a Hypervisor.

[0151] S52: After receiving the virtualization call instruction, the 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 a first restart process.

[0153] During the process of restarting the first operating system according to the first restart process at step S53, this embodiment sends an inter-core interrupt to other cores except the first operating system itself.

[0154] This embodiment preferentially adopts the autonomous restart mode of the first operating system, thereby improving the restart efficiency.

[0155] In a possible implementation, after restarting the first operating system according to the first restart process, restarting the first operating system according to the second restart process further includes:

[0156] S54: When it is determined that the first operating system is restarted successfully, the Hypervisor sets the flag of the virtualization call instruction to a success flag; or, when the first operating system fails to restart, the Hypervisor sets the flag of the virtualization call instruction to a failure flag.

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

[0158] In one possible implementation, Figure 5 As shown, restarting the first operating system according to the second restart process also includes:

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

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

[0161] S57. After receiving the second virtualization call 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.

[0162] S58. After receiving the inter-core interrupt, the master core executes data copy and performs the first initialization; after receiving the inter-core interrupt, the slave core is in a state of waiting for wake-up.

[0163] The data copy process in step S58 is similar to steps S431 to S433 in the above-mentioned embodiment 2, and will not be described again here.

[0164] S59. The master core wakes up the slave core after the first initialization is completed, and the slave core performs a second initialization after waking up; wherein the completion of the second initialization indicates that the first operating system is restarted successfully.

[0165] This embodiment preferentially adopts the autonomous restart mode of the first operating system, and if the autonomous restart fails, a forced restart is performed, thereby ensuring the effectiveness of the restart and improving the security of the system.

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

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

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

[0169] SPI interrupt refers to a shared external interrupt, which is 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 restart. The steps of the autonomous restart are consistent with steps S41 to S44 in Example 2. The difference is that Example 2 is restarted by the user inputting reboot in the shell, while Example 3 is restarted by the kernel module calling the shell.

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

[0172] e. Since the second operating system is not sure whether the restart has been successful, after a preset period of time (configurable), the second operating system queries the first operating system through HVC whether the restart has been successful.

[0173] That is to say, the HVC of the first operating system is mainly used to set a success flag; the second operating system determines whether the startup is successful through the flag bit.

[0174] f. If unsuccessful, the second operating system initiates a forced restart and sends a forced restart command through HVC. The present application embodiment does not specifically limit the factors leading to failure, because hardware problems or software problems may lead to startup failure.

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

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

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

[0178] j. After receiving the command from the core, the first operating system waits for the main core to wake 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 preferentially adopts the autonomous restart mode of the first operating system, and if the autonomous restart fails, a forced restart is performed, thereby ensuring the effectiveness of the restart and improving the security of the system.

[0182] Optionally, this embodiment may directly perform a forced restart in the second restart process, and this method may improve the restart efficiency.

[0183] Embodiment 4:

[0184] Figure 6 A schematic diagram of the structure of a vehicle control device provided in an embodiment of the present application. The vehicle control device includes a virtual machine monitor Hypervisor, and 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 virtual machine monitor Hypervisor are used to restart the first operating system in response to the information to be tested meeting the restart condition.

[0186] Or, a first lifecycle management module in the first operating system, a second lifecycle management module in the virtual machine monitor Hypervisor, and a 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 include corresponding lifecycle management modules.

[0188] The first life cycle 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 a restart command for the first operating system and diagnose whether the first operating system is successfully restarted (corresponding to the description in the above steps S54 to S56).

[0190] The second life cycle management module in the Hypervisor includes, but is not limited to: PSCI command processing unit, HVC command processing unit, SPI interrupt trigger unit, inter-core interrupt trigger unit, data backup and recovery unit, etc. Among them, the HVC command processing unit is used to process HVC commands; the PSCI command processing unit is used to process power management related commands (i.e., PSCI commands); the SPI interrupt trigger unit is used to trigger SPI interrupts; the inter-core interrupt trigger unit is used to trigger inter-core interrupts; and the data backup and recovery unit is used to implement data backup and recovery.

[0191] All process architectures of the embodiments of the present application can achieve the best implementation effect by using C language.

[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 effects 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, displayed data, etc.) are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0194] That is to say, in the technical solution of this application, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved are in compliance with the relevant laws and regulations and do not violate public order and good morals.

[0195] According to an embodiment of the present application, the present application also provides another vehicle control device, a vehicle-readable storage medium, and a computer program product.

[0196] Figure 7 A schematic diagram of the structure of another vehicle control device provided in an embodiment of the present 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 several specific embodiments of the present application, which will not be described in detail here.

[0197] An embodiment of the present application also provides a vehicle, comprising any of the above-mentioned vehicle control devices.

[0198] The embodiment of the present application further provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, each step of the method in the above embodiment is implemented.

[0199] An embodiment of the present application also provides a computer program product, including a computer program, which implements each step of the method provided in the above embodiment when executed by a processor.

[0200] Various embodiments of the systems and techniques described above in the present 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 chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include: being implemented in one or more computer programs, which may be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general programmable processor, which may receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0201] The program code for implementing the method of the present application can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code can be executed entirely on the machine, partially on the machine, partially on the machine as a stand-alone software package and partially on a remote machine, or entirely on a remote machine or electronic device.

[0202] In the context of the present application, a computer-readable storage medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A computer-readable storage medium may be a machine-readable signal medium or a machine-readable storage medium. A computer-readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any suitable combination of the foregoing. A more specific example of a computer-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, 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 (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the 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 acoustic input, voice input, or tactile input).

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

[0205] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps disclosed in this application can be performed in parallel, sequentially or in different orders, as long as the desired results of the technical solution disclosed in this application can be achieved, and this document does not limit this.

[0206] The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the principles of this application should be included in the protection scope of this application.

Claims

1. A method for restarting an operating system, characterized in that: 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 macro kernel architecture, and the second operating system adopts a micro kernel architecture, and the method includes: In the process of running the first operating system and the second operating system on the Hypervisor, obtaining first information to be tested and second information to be tested; In response to the first information to be tested satisfying a corresponding restart condition, restarting the first operating system according to a first restart process; In response to the second information to be tested satisfying the corresponding restart condition, the first operating system is restarted according to a second restart process.

2. The method according to claim 1, characterized in that The first information to be tested includes a command to be tested and a calling function to be tested; Then, in response to the first information to be tested satisfying the corresponding restart condition, restarting the first operating system according to a first restart process includes: In response to the command to be tested being a Reboot command, and / or the calling function to be tested being a function used to indicate that a panic occurs in the first operating system, the first operating system is restarted according to a first restart process.

3. The method according to claim 2, characterized in that The restarting the first operating system according to the first restart process includes: The first operating system calls a restart command of the power management module in the vehicle control device; The Hypervisor intercepts the restart command 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 executes data copy and performs first initialization; after receiving the inter-core interrupt, the slave core is in a state of waiting for wake-up; The master core wakes up the slave core after the first initialization is completed, and the slave core performs a second initialization after waking up; wherein the completion of the second initialization indicates that the first operating system is restarted successfully.

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

5. The method according to claim 4, characterized in that The restarting the first operating system according to the second restart process includes: The second operating system calls a virtualization call instruction indicating 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 the first operating system according to a first restart process.

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

7. The method according to claim 6, characterized in that Restarting the first operating system according to the second restart process 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 calling instruction queried is the failure flag, the second operating system sends a second virtualization calling command for indicating a forced restart to the Hypervisor through the power management module; After receiving the second virtualization call 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 executes data copy and performs first initialization; after receiving the inter-core interrupt, the slave core is in a state of waiting for wake-up; The master core wakes up the slave core after the first initialization is completed, and the slave core performs a second initialization after waking up; wherein the completion of the second initialization indicates that the first operating system is restarted successfully.

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

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 virtual machine monitor Hypervisor are used to restart the first operating system in response to the information to be tested meeting the restart condition; Or, the first lifecycle management module in the first operating system, the second lifecycle management module in the virtual machine monitor Hypervisor, and the third lifecycle management module in the second operating system are used to restart the first operating system.

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

11. A vehicle, characterized in that: Including the vehicle control device as claimed in claim 9 or the vehicle control device as claimed in claim 10.

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

Images