In-vehicle system and control method based on a multi-operating system

Abstract

The present application provides an in-vehicle system based on a multi-operating system and a control method thereof. The in-vehicle system based on the multi-operating system includes at least one application operating system and a safety monitoring operating system. The application operating system and the safety monitoring operating system use different cores of the same processor. The application operating system is used to execute non-secure applications, and the safety monitoring operating system is communicatively connected to the application operating system in order to execute a safety monitoring service for safely monitoring the application operating system.

Description

Technical Field

[0001] This application relates to the field of in-vehicle technologies, and particularly to an in-vehicle system based on a multi-operating system and a control method thereof.

Background Art

[0002] Currently, the center control system of automobiles, that is, the in-vehicle system, is becoming increasingly popular. The in-vehicle system includes not only functions such as Android (Registered trademark) entertainment functions, car navigation, and back view, but also functions such as safety monitoring for monitoring the safety of the system.

[0003] However, existing in-vehicle systems are usually based on the core of the Android operating system and implement applications for realizing the safety monitoring function. The Android operating system is a huge system with numerous applications, and many applications are running. There are many safety problems in such a complex and huge system. If one of the applications malfunctions, the entire system may crash. Therefore, its safety monitoring function is affected by the abnormal operation of other applications in the Android operating system and cannot provide effective safety monitoring, resulting in low system safety.

Summary of the Invention

Problems to be Solved by the Invention

[0004] This My wish is , in order to improve the effectiveness of safety monitoring and enhance the safety performance of the in-vehicle system, an in-vehicle system based on a multi-operating system and a control method thereof are provided The purpose is .

Means for Solving the Problems

[0005] To solve the above technical problems, this application provides an in-vehicle system based on a multi-operating system. This in-vehicle system based on a multi-operating system is Includes at least one application operating system and a security monitoring operating system, The application operating system and the security monitoring operating system use different cores of the same processor. Application operating systems are used to run insecure applications. The security monitoring operating system communicates with the application operating system to perform security monitoring services for the security monitoring of the application operating system.

[0006] To solve the above technical problems, this application provides a control method for an in-vehicle system based on a multi-operating system. This in-vehicle system includes at least one application operating system and a safety monitoring operating system, wherein the application operating system includes a second operating system that uses a different core of the same processor as the safety monitoring operating system, and the second operating system is used to run a quick-start application. The control method is, The second operating system and the security monitoring operating system will form the core, To obtain a power-on command, load the mirror file of the safety monitoring operating system into the running memory of the in-vehicle system, and complete the startup of the safety monitoring operating system and its safety monitoring services, the execution of the core corresponding to the safety monitoring operating system is initiated. This further includes loading the kernel of the second operating system into running memory, initiating the execution of the core corresponding to the second operating system, sequentially completing the loading of the drivers for the second operating system, starting the services on which the quickstart application depends, and starting the quickstart application.

[0007] Compared to prior art, the beneficial effects of the present invention are as follows. The multi-operating system-based in-vehicle system of the present invention includes at least one application operating system and a safety monitoring operating system, the application operating system and the safety monitoring operating system using different cores of the same processor, the application operating system being used to run non-secure applications, and the safety monitoring operating system being communicated with the application operating system to safely monitor the application operating system. The in-vehicle system of the present invention achieves safety monitoring of the application operating system using the safety monitoring operating system, and implements the safety monitoring operating system and the application operating system using different cores of the same processor, thereby achieving isolation between the two. This avoids the problem that the safety monitoring application cannot run normally due to the abnormal execution of an application in the application operating system, thereby improving the effectiveness of safety monitoring and enhancing the safety performance of the in-vehicle system. [Brief explanation of the drawing]

[0008] [Figure 1] This is a diagram illustrating one embodiment of an in-vehicle system based on the multi-operating system of the present invention. [Figure 2] This is a diagram showing the core division of the in-vehicle system of the present invention. [Figure 3] This is a startup flowchart for one of the in-vehicle systems of the present invention. [Figure 4] This is another configuration diagram of the core division of the in-vehicle system of the present invention. [Figure 5] This is another startup flowchart for the in-vehicle system of the present invention. [Figure 6] This is a communication flowchart between different cores of an in-vehicle system based on the multi-operating system of the present invention. [Figure 7] This is an operation flowchart of the safety monitoring operating system in an in-vehicle system based on the multi-operating system of the present invention. [Figure 8] This is a flowchart of one embodiment of the control method for an in-vehicle system based on the multi-operating system of the present invention. [Figure 9] This is a communication flowchart between different cores in the control method for an in-vehicle system based on the multi-operating system of the present invention. [Figure 10] This is an operation flowchart of the safety monitoring operating system in the control method for an in-vehicle system based on the multi-operating system of the present invention. [Modes for carrying out the invention]

[0009] The technical invention in the embodiments of this application will be described clearly and completely below with reference to the drawings of the embodiments of this application. Clearly, the embodiments described are only a selection of embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by a person skilled in the art, provided that no creative work is performed, fall within the scope of protection of this application.

[0010] First, as shown in Figure 1, the present invention provides an in-vehicle system based on a multi-operating system, which is a configuration diagram of one embodiment of the in-vehicle system based on a multi-operating system of the present invention. The in-vehicle system of this embodiment includes at least one application operating system and a safety monitoring operating system 12, the application operating system and the safety monitoring operating system 12 using different cores of the same processor, that is, they use core 1 and core 2 (and core 3), respectively, where the application operating system is used to run non-secure applications, and the safety monitoring operating system 12 is communicated with the application operating system to perform safety monitoring services for the safety monitoring of the application operating system.

[0011] In this embodiment, the in-vehicle system implements safety monitoring for the application operating system using a safety monitoring operating system 12, and implements the safety monitoring operating system 12 and the application operating system using different cores of the same processor, thereby achieving isolation between the two. This avoids the problem where the safety monitoring application cannot run properly due to abnormal execution of an application in the application operating system, thereby improving the effectiveness of safety monitoring and enhancing the safety performance of the in-vehicle system.

[0012] Here, the core 2 used to execute the security monitoring operating system 12, that is, the core 2 used by the security monitoring operating system 12, may be one or more (two or more) cores of the same processor. The security monitoring operating system 12 is primarily used to execute security monitoring applications, i.e., security monitoring services, for monitoring the execution status of application operating systems, etc.

[0013] Here, the core 1 (and core 3) used to execute the application operating system, that is, the core 1 (and core 3) used by the application operating system may be one or more (two or more) other cores of the same processor.

[0014] Here, the application operating system of this embodiment includes a first operating system 11 and a second operating system 13. Here, the first operating system 11 may be an Android operating system. The Android operating system mainly includes the following: (a) It includes a Kernel layer, and its driver module includes all device drivers other than the video ( VIDEO ) device driver in the system-on-a-chip (SOC), such as a graphics processing unit (GPU), a data processing unit (DPU), and other module drivers (including modules such as EMMC, I2C, WIFI, USB), (b) A Service layer, that is, a service layer, and its services include all running services, such as OpenGLES, CarmeraSource, Surfaceflinger, and other running services (such as Storage Service, WIFI Service, Audio Service), (c) An application layer, and its applications include VIDEO Player, Music Play, 3rd Party APP, etc.

[0015] For a specific introduction to the Android operating system, reference can be made to the prior art, and this text does not make specific limitations. In other embodiments, the application operating system may further be other non-secure multi-application systems, etc.

[0016] Note that the multiple (two or more) cores of the present application may be of the same type or different types, and are not particularly limited.

[0017] Optionally, the second operating system 13 of this embodiment may be Linux (Registered trademark) operating system, and different cores of the same processor as the first operating system and the security monitoring operating system 12 are used. The Linux operating system uses core 3, and the Android operating system uses core 1. That is, the Linux operating system, the Android operating system, and the security monitoring operating system 12 each use independent cores in the same process.

[0018] Here, the Linux operating system is used to execute the quick start application. Here, the Linux operating system simplifies the Linux operating system 13 and sets only the resource items on which the quick start application depends in order to shorten the startup time of the quick start application.

[0019] The security monitoring operating system 12 is communicatively connected to the Android operating system and the Linux operating system respectively, and is used for the security monitoring of the Android operating system and the Linux operating system respectively.

[0020] Here, the core for executing the Linux operating system may be one or more (two or more) other cores of the same processor.

[0021] Quick start applications are applications that need to be launched quickly, such as Around View Monitor (AVM) applications, backdrop applications in smart cabins, in-vehicle instrumentation applications, and in-vehicle dealer management system (DMS) applications.

[0022] The following explanation uses the case of a Linux operating system running an AVM application as an example.

[0023] AVM applications use GPUs, DPUs, VIDEO In this case, it relies on three important hardware modules. Here, the GPU can accelerate image processing and is compatible with the Android Kernel's GPU driver and the Android Service's OpenGLES interface, while the DPU is the display module and is compatible with the Android Kernel's DPU driver and the Android Service's SurfaceFinger interface. VIDEO IN is a camera image acquisition module, and is part of the Android Kernel. VIDEO IN Driver and Android Service Camera a Supports the Source interface.

[0024] An AVM application is an APP application written in Java for the Android application layer, and it operates through the Camera Source interface. VIDEO The IN module acquires the collected camera image data, and after going through an algorithm, the GPU hardware module completes distortion correction and splicing of the image data, and finally, through Surfaceflinger Camera images Display it on the screen.

[0025] Conventional in-vehicle systems have the following problems with the AVM system described above.

[0026] (1) Camera S Components such as the source interface, Surfaceflinger service, and OpenGLES library must all be loaded into the Android master filesystem before they can operate. Furthermore, the AVM app can only start after the entire Android system has booted and entered the master interface. Therefore, traditional in-car systems have a very slow process, typically 20 seconds, during which the car cold-starts and obtains the AVM image. That's all. That is the case.

[0027] (2) The Android system is a system with a vast number of applications and many services running on it. A complex and massive system has many security issues. For example, if one of its services malfunctions, the entire system could collapse. The AVM application is also affected, so the AVM functionality is susceptible to the Android system and has low security.

[0028] On the other hand, the in-vehicle system of this embodiment achieves the benefits of quick start and execution safety of AVM by making the AVM function independent and running it independently on the Linux operating system.

[0029] Furthermore, the Linux operating system in this embodiment is a custom crop, and (a) the GPU, DPU, and other components that AVM primarily depends on. VIDEO It includes only the following: (b) a Linux Kernel layer containing device drivers, (c) a Linux Service layer containing OpenGLES, CarmeraSource, Surfaceflinger, and Safety Service, on which AVM primarily depends, and (d) a Linux Application layer running only one AVM application. A simplified Linux operating system can further speed up AVM startup.

[0030] The SOC integrates multiple cores, such as 4 cores or 8 cores. This embodiment fully utilizes the resource advantages of a multi-core system to run three operating systems on the SOC: the first operating system 11 runs on a portion of the cores, the security monitoring operating system 12 runs on a portion of the cores, and the second operating system 13 runs on the remaining cores.

[0031] Furthermore, both the first operating system 11 and the second operating system 13 in this embodiment require two resource modules, a GPU and a DPU, and these two resource modules can be accessed by both the first operating system 11 and the second operating system 13 using software virtualization (hypervisor) technology.

[0032] As can be seen from the above analysis, the in-vehicle system further includes an SOC, which is provided with multiple physical cores, each of which is assigned at least one physical core to a first operating system 11, a safety monitoring operating system 12, and a second operating system 13.

[0033] Specifically, as shown in Figure 2, when the SOC is running, physical cores are allocated to the first operating system 11, the safety monitoring operating system 12, and the second operating system 13. For example, the SOC has four physical cores Core[0]-Core[3], and the safety monitoring operating system 12 Assign Core[0] to the second operating system 13 Assign Core[1] to the first operating system 11, and assign Core[2] and Core[3] to the first operating system 11.

[0034] Optionally, as shown in Figure 3, the in-vehicle system is powered up, the bootloader is executed, the hardware devices are initialized, the SOC assigns different physical cores to the first operating system 11, the safety monitoring operating system 12, and the second operating system 13, respectively, the bootloader loads a mirror file of the safety monitoring operating system 12 into running memory, starts the execution of the core corresponding to the safety monitoring operating system 12, and completes the startup of the safety monitoring operating system 12 and its safety monitoring services.

[0035] The bootloader loads the Min Kernel into running memory and starts the execution of the core corresponding to the Linux operating system. K After the kernel has finished driving, AVM starts the CarmeraSource, surfaceflinger, and Opengles services it depends on, and finally starts the AVM application.

[0036] The bootloader loads the Android Kernel into running memory and starts the execution of the cores corresponding to the Android operating system. After the Android Kernel has finished loading, it starts all Android services, and finally launches Android applications after all Android services have finished starting.

[0037] Furthermore, to enable quick startup of AVM applications, more physical cores can be allocated to the second operating system 13 during the AVM application startup phase, and after the AVM application startup is complete, the physical cores can be released to the first operating system 11. This embodiment ensures quick startup of AVM applications by allocating more physical cores to the second operating system 13 during the AVM application startup phase, and after the AVM application startup is complete, the second operating system 13 can be released to ensure the execution speed and rational use of resources of other application operating systems. Divided into A portion of the allocated physical cores can be freed up to other application operating systems of the in-vehicle system, such as the first application operating system 11.

[0038] In other embodiments, cores can also be allocated to the first operating system 11, the safety monitoring operating system 12, and the second operating system 13 using software virtualization (Hypervisor) technology. The in-vehicle system of this embodiment further includes a core virtualization system 14 (as shown in Figure 4), the general-purpose implementation of which involves designing a single layer of software at the Exception Level (EL2) of the processor. The core virtualization system 14 virtualizes physical cores into multiple virtual cores using Hypervisor technology, and the SOC allocates at least one virtual core to the first operating system 11, the safety monitoring operating system 12, and the second operating system 13, respectively.

[0039] Specifically, as shown in Figure 4, the core virtualization system 14 uses hypervisor technology to virtualize the physical cores Core[0]-Core[3] into multiple virtual cores VCore[0]-VCore[5], assigns VCore[0] to the safety monitoring operating system 12, assigns VCore[0] and VCore[2] to the second operating system 13, and assigns VCore[3], VCore[4], and VCore[5] to the first operating system 11.

[0040] Optionally, as shown in Figure 5, the system is powered up, the bootloader is executed, the hardware devices are initialized, the bootloader loads a mirror file of the Hypervisor into running memory, and after successfully starting the Hypervisor, multiple virtual cores are virtualized. The Hypervisor then loads a mirror file of the security monitoring operating system 12 into running memory, starts execution of the core corresponding to the security monitoring operating system 12, and completes the startup of the security monitoring operating system 12 and its security monitoring services.

[0041] The hypervisor loads the Min Kernel into running memory and starts the execution of the core corresponding to the Linux operating system. K After the kernel has finished driving, AVM starts the CarmeraSource, surfaceflinger, and Opengles services it depends on, and finally starts the AVM application.

[0042] The hypervisor loads the Android Kernel into running memory and starts the execution of cores corresponding to the Android operating system. After the Android Kernel has finished loading, it starts all Android services, and finally launches Android applications after the Android services have finished starting.

[0043] In other embodiments, cores can also be allocated to the first operating system, the security monitoring operating system, and the second operating system by reference to the physical partitioning method of the embodiment in Figure 2 and the virtual partitioning method of the embodiment in Figure 4.

[0044] Specifically, the SOC has multiple physical cores, the core virtualization system virtualizes a portion of the physical cores into multiple virtual cores, the SOC assigns at least one virtual core to the first operating system and the second operating system, and at least one physical core to the security monitoring operating system.

[0045] In other embodiments, physical cores may be assigned to the first operating system and / or the second operating system, and virtual cores may be assigned to the security monitoring operating system.

[0046] The in-vehicle system in this embodiment also includes memory.

[0047] As an option, the in-vehicle system of this embodiment can also realize communication between different cores. Specifically, as shown in Figure 6, this embodiment realizes communication between different cores based on interrupts and shared memory. Assuming that the SOC has n cores, taking the example of sending a message from Core[0] to Core[n-1], Core[0] writes a message to the designated shared memory data_A[], Core[0] writes an interrupt, the controller triggers Core[n-1] to receive the interrupt, Core[n-1] receives the interrupt, enters the interrupt handler, and reads the message from the shared memory data_A[].

[0048] As an option, as shown in Figure 7, this embodiment uses the following method to apply to the first operating system 11 and the second operating system 13 executionStatus monitoring is achieved, and the Safety Service running on the second operating system 13 and the first operating system 11 sends messages at regular frequency intervals via inter-process communication, i.e., the IPC method, to notify the Safety Monitor service running on the safety monitoring operating system 12. The message type can be defined independently, and two messages, "alive" and "fatal," can be defined.

[0049] If Safety Monitor receives "alive", it determines that the operating system that sent the message is running normally and will continue monitoring the message without processing it. If Safety Monitor receives "fatal", it determines that a fatal error has occurred in the operation of the operating system that sent the message and that the operating system needs to be restarted to resume normal operation. If Safety Monitor does not receive a message sent from an operating system within a specified time, it determines that a fatal error has occurred in the operation of the operating system that did not send the message and that the operating system needs to be restarted to resume normal operation.

[0050] Furthermore, Safety Monitor can also monitor its own execution status via a watchdog, for example, by sending notification signals to the Watchdog's Register at regular frequency intervals. If Safety Monitor is running abnormally and notification is not made in a timely manner, the safety monitoring operating system 12 will restart to resume normal operation.

[0051] The present invention further provides a control method for an in-vehicle system based on a multi-operating system, as shown in Figure 8, which is a flowchart of one embodiment of the control method for an in-vehicle system based on a multi-operating system of the present invention. The control method of this embodiment can be used in the in-vehicle system based on the multi-operating system described above, and the control method of this embodiment specifically includes the following steps.

[0052] Step S81, configure the core for the second operating system and the security monitoring operating system.

[0053] The in-vehicle system further includes at least one application operating system and a safety monitoring operating system, the application operating system includes a second operating system, and the SOC constitutes the core for the second operating system and the safety monitoring operating system. The SOC constitutes the core for the second operating system, the second operating system and the safety monitoring operating system are located on different cores of the processor, the second operating system is used to run the quickstart application, where the second operating system simplifies the Linux operating system and configures only the resource items that the quickstart application depends on in order to reduce the startup time of the quickstart application.

[0054] Quick start applications are applications that need to be launched quickly, such as AVM applications, backdrop applications in smart cabins, in-vehicle instrumentation applications, and in-vehicle DMS applications.

[0055] Furthermore, the application operating system may also include the first operating system. The SOC comprises the first operating system, the second operating system, and the security monitoring operating system, respectively.

[0056] When the SOC is running, it allocates at least one physical core to the first operating system, the security monitoring operating system, and the second operating system, or when the SOC is running, it virtualizes the physical cores of the SOC into multiple virtual cores using hypervisor technology via a core virtualization system, and the SOC allocates at least one virtual core to the first operating system, the security monitoring operating system, and the second operating system, or it virtualizes a portion of the physical cores of the SOC into multiple virtual cores using hypervisor technology via a core virtualization system, and the SOC allocates at least one virtual core to the first operating system and the second operating system, and allocates at least one non-virtualized physical core to the security monitoring operating system.

[0057] In other embodiments, the SOC may also allocate physical cores to a first operating system and / or a second operating system, and virtual cores to a security monitoring operating system.

[0058] Here, the second operating system in this embodiment may be a Linux operating system, the first operating system may be an Android operating system, and in other embodiments, the first operating system may be another non-secure multi-application system, etc.

[0059] Step S82, obtain power-on command and mirror the operating system file for safety monitoring. In-vehicleThe system loads the system into its running memory and starts the execution of the core corresponding to the security monitoring operating system in order to complete the startup of the security monitoring operating system and its security monitoring services.

[0060] In step S83, the kernel of the second operating system is loaded into running memory, the execution of the core corresponding to the second operating system is started, the drivers of the second operating system are loaded, the services on which the quickstart application depends are started, and the quickstart application is started in sequence.

[0061] Furthermore, the control method of this embodiment further includes step S84.

[0062] In step S84, the kernel of the first operating system is loaded into running memory, the execution of the core corresponding to the first operating system is started, and the driver loading, service startup, and application startup of the first operating system are completed sequentially.

[0063] The in-vehicle system of this embodiment implements safety monitoring for the application operating system using a safety monitoring operating system, and implements the safety monitoring operating system and the application operating system using different cores of the same processor, thereby achieving isolation between the two. This avoids the problem of the safety monitoring application not being able to run properly due to the abnormal execution of an application in the application operating system, thereby improving the effectiveness of safety monitoring and enhancing the safety performance of the in-vehicle system.

[0064] In this embodiment, the quick-start and execution-safe effects of the quick-start application can be achieved by making the quick-start application independent and running it alone on the Linux operating system.

[0065] In other embodiments, the execution order of steps S82 to S84 is not limited.

[0066] In one application scenario, after the SOC allocates physical cores to the Android operating system, the safety monitoring operating system, and the Linux operating system, the in-vehicle system is powered up, the bootloader is executed, the hardware devices are initialized, the SOC allocates different physical cores to the Android operating system, the safety monitoring operating system, and the Linux operating system respectively, the bootloader loads a mirror file of the safety monitoring operating system into running memory, starts the execution of the core corresponding to the safety monitoring operating system, and completes the startup of the safety monitoring operating system and its safety monitoring services.

[0067] The bootloader loads the Min Kernel into running memory and starts the execution of the core corresponding to the Linux operating system. K After the kernel has finished driving, AVM starts the CarmeraSource, surfaceflinger, and Opengles services it depends on, and finally starts the AVM application.

[0068] The bootloader loads the Android Kernel into running memory and starts the execution of the cores corresponding to the Android operating system. After the Android Kernel has finished loading, it starts all Android services, and finally launches Android applications after all Android services have finished starting.

[0069] In other application scenarios, after the SOC allocates virtual cores to the Android operating system, security monitoring operating system, and Linux operating system, the system powers up, runs the bootloader, initializes the hardware devices, the bootloader loads the Hypervisor mirror file into running memory, and after successfully starting the Hypervisor, virtualizes multiple virtual cores, the Hypervisor loads the security monitoring operating system mirror file into running memory, starts execution of the core corresponding to the security monitoring operating system, and completes the startup of the security monitoring operating system and its security monitoring services.

[0070] The hypervisor loads the Min Kernel into running memory and starts the execution of the core corresponding to the Linux operating system. K After the kernel has finished driving, AVM starts the CarmeraSource, surfaceflinger, and Opengles services it depends on, and finally starts the AVM application.

[0071] The hypervisor loads the Android Kernel into running memory and starts the execution of cores corresponding to the Android operating system. After the Android Kernel has finished loading, it starts all Android services, and finally launches Android applications after the Android services have finished starting.

[0072] Furthermore, for the quick start of the quick start application, the SOC allocates a preset number of cores to the second operating system, and after the second operating system has finished booting, it releases some of the cores to the first operating system. Here, this preset number is greater than the number of cores required for the second operating system to run the quick start application. In this embodiment, more physical cores can be configured for the second operating system during the AVM application boot phase, ensuring a quick start of the AVM application, and after the AVM application has finished booting, the second operating system is released to ensure the execution speed and rational use of resources for other application operating systems. Divided into A portion of the allocated physical cores can be freed up to other application operating systems in the in-vehicle system, such as a first application operating system.

[0073] As an option, the control method of the present invention can also enable communication between different cores. The processor (SOC) is provided with a first core and a second core, which are the application operating system and security monitoring, respectively. operating The system is compatible, and the control method in this embodiment enables communication between different cores based on interrupts and shared memory. Specifically, this communication method includes steps S91 to S93 shown in Figure 9.

[0074] Step S91, the application operating system writes a message to shared memory.

[0075] The first core writes a message to shared memory.

[0076] Step S92, the application operating system writes an interrupt to perform safety monitoring. operating The system is triggered to receive the interrupt.

[0077] The first core triggers the second core to receive the interrupt by writing an interrupt.

[0078] In step S93, the safety monitoring operating system enters the interrupt handler after receiving an interrupt and reads a message from shared memory.

[0079] The second core, after receiving an interrupt, enters the interrupt handler and reads the message from shared memory.

[0080] Assuming the SOC has n cores, let's take the example of sending a message from Core[0] to Core[n-1]. Core[0] writes a message to the designated shared memory data_A[], Core[0] writes an interrupt, the controller triggers Core[n-1] to receive the interrupt, Core[n-1] receives the interrupt, enters the interrupt handler, and reads the message from the shared memory data_A[].

[0081] Furthermore, communication between cores corresponding to the different operating systems mentioned above is possible as described above.

[0082] As an option, the control method of the present invention can also implement security monitoring of the application operating system. Specifically, this can be achieved by the method shown in Figure 10, and the method of this embodiment includes steps S101 to S103.

[0083] In step S101, the application operating system sends a message to the security monitoring operating system.

[0084] The Safety Service, running on the application operating system, sends messages at regular frequency intervals via inter-process communication, i.e., the IPC method, to the Safety Monitor service running on the safety monitoring operating system. Message types can be defined independently, and two messages, "alive" and "fatal," can be defined.

[0085] Step S102, Safety Monitoring Operating system This determines the execution state of the application operating system based on the message or the waiting time for receiving the message.

[0086] If Safety Monitor receives "alive," it determines that the application operating system that sent the message is running normally and will continue monitoring the message without processing it. If Safety Monitor receives "fatal," it determines that a fatal error has occurred in the application operating system that sent the message and that the application operating system needs to be restarted to resume normal operation. If Safety Monitor does not receive a message sent from an application operating system within a specified time, it determines that a fatal error has occurred in the application operating system that did not send the message and that the application operating system needs to be restarted to resume normal operation.

[0087] In step S103, if the execution state is abnormal, the safety monitoring operating system restarts the application operating system.

[0088] If the application operating system runs abnormally, the security monitoring operating system will restart the application operating system.

[0089] The security monitoring operating systems are connected to the Android operating system and the Linux operating system respectively, and security monitoring of the Android operating system and the Linux operating system can be achieved using the method described above.

[0090] Furthermore, Safety Monitor can also monitor its own operational status via a watchdog. For example, it can send notification signals to the Watchdog's Register at regular frequency intervals. If Safety Monitor is running abnormally and notifications are not made in a timely manner, the safety monitoring operating system will restart to resume normal operation.

[0091] For a description of each of the above operating systems, please refer to the examples above, and we will omit the explanation here.

[0092] Unlike conventional technologies, the multi-operating system-based in-vehicle system of the present invention includes at least one application operating system and a safety monitoring operating system. The application operating system and the safety monitoring operating system use different cores of the same processor. The application operating system is used to run non-secure applications, and the safety monitoring operating system communicates with the application operating system to safely monitor it. The in-vehicle system of the present invention achieves safety monitoring of the application operating system using the safety monitoring operating system, and implements the safety monitoring operating system and the application operating system using different cores of the same processor, thereby achieving isolation between the two. This avoids the problem of the safety monitoring application not being able to run normally due to the abnormal execution of an application in the application operating system, thereby improving the effectiveness of safety monitoring and enhancing the safety performance of the in-vehicle system.

[0093] This invention provides a system for independently running an AVM application on a single system, allocating a multi-core SOC to cores required for a safety monitoring operating system, cores required for a second operating system, and cores required for a first operating system, running the AVM application on the second operating system, running an Android application on the first operating system, running Safety Monitor on the safety monitoring operating system, monitoring the execution status of the second and first operating systems, handling abnormal recovery, and achieving quick start (AVM startup display can be completed in about 3 seconds) and execution safety effects.

[0094] This invention deploys an AVM application to a second operating system. Since the second operating system only needs to support the AVM application, it can be cropped very simply, thereby achieving the goal of a quick start. Furthermore, compared to the complex and voluminous first operating system, the simpler second operating system is more stable and secure because it runs fewer services and has a single application. Also, because the first and second operating systems are isolated, an error in the first operating system will not affect the second operating system.

[0095] The system architecture and method provided in this application can be applied not only to AVM quick-start and execution safety scenes, but also to other module scenes such as quick-start of backdrops in smart cabins, quick-start of in-vehicle instruments, and quick-start of in-vehicle DMS systems.

[0096] The above describes only embodiments of the present application and does not limit the scope of the patent. Any equivalent structure or equivalent flow transformation performed using the contents of the present specification and drawings, or any application directly or indirectly to other related technical fields, is included within the scope of the patent protection of the present application.

[0097] This application claims priority to the Chinese patent application filed with the China National Patent Office on July 11, 2022, with application number 2022108132200 and application title "In-vehicle system and control method thereof based on a multi-operating system," the entire contents of which are incorporated herein by reference.

Claims

1. An in-vehicle system based on a multi-operating system, It includes at least one application operating system and a security monitoring operating system, The aforementioned application operating system and the aforementioned safety monitoring operating system use different cores of the same processor. The aforementioned application operating system is used to run non-secure applications. The aforementioned security monitoring operating system is connected to the application operating system in order to perform security monitoring services for the application operating system, The application operating system includes a second operating system that uses a different core of the processor than the security monitoring operating system, the second operating system is used to run the quickstart application, and the second operating system is configured to load only the resource items on which the quickstart application depends. The aforementioned safety monitoring operating system is connected in communication with the second operating system in order to safely monitor the second operating system. An in-vehicle system based on a multi-operating system, characterized by the following features.

2. The application operating system further includes a first operating system that communicates with the security monitoring operating system, and the security monitoring operating system is further used to security monitor the first operating system. The in-vehicle system according to claim 1, characterized by the features described above.

3. The in-vehicle system further includes an on-chip system, the on-chip system is provided with a plurality of physical cores, and at least one of the physical cores is assigned to the first operating system, the safety monitoring operating system, and the second operating system, respectively. The in-vehicle system according to claim 2, characterized in that it is as described above.

4. The in-vehicle system further includes an on-chip system and a core virtualization system, wherein the on-chip system is provided with physical cores, the core virtualization system virtualizes at least a portion of the physical cores into a plurality of virtual cores, and the on-chip system assigns at least one of the virtual cores and / or at least one of the physical cores to the first operating system, the safety monitoring operating system, and the second operating system, respectively. The in-vehicle system according to claim 2, characterized in that it is as described above.

5. A control method for an in-vehicle system based on a multi-operating system, The in-vehicle system includes at least one application operating system and a safety monitoring operating system, wherein the application operating system includes a second operating system using a different core of the same processor as the safety monitoring operating system, the second operating system is used to run a quick start application, the second operating system is configured to load only the resource items on which the quick start application depends, and the safety monitoring operating system is connected to the second operating system for safety monitoring of the second operating system. The control method described above is The second operating system and the safety monitoring operating system constitute a core, To obtain a power-on command, load the mirror file of the safety monitoring operating system into the running memory of the in-vehicle system, and start the execution of the core corresponding to the safety monitoring operating system in order to complete the startup of the safety monitoring operating system and its safety monitoring services, This includes loading the kernel of the second operating system into the running memory, starting the execution of the core corresponding to the second operating system, sequentially completing the loading of the drivers for the second operating system, starting the services on which the quickstart application depends, and starting the quickstart application, A control method for an in-vehicle system based on a multi-operating system, characterized by the following features.

6. The application operating system further includes the security monitoring operating system and the second operating system and a first operating system that uses different cores of the processor, The control method further includes, The first operating system to constitute a core, This includes loading the kernel of the first operating system into the running memory, starting the execution of the core corresponding to the first operating system, and sequentially completing the driver loading, service startup, and application startup of the first operating system. The control method according to feature 5.

7. The first operating system, the second operating system, and the safety monitoring operating system constitute a core, Each of the following is to assign at least one physical core to the safety monitoring operating system, the second operating system, and the first operating system, or Virtualizing at least a portion of the physical cores into multiple virtual cores, Each of the following is to assign at least one virtual core and / or at least one physical core to the safety monitoring operating system, the second operating system, and the first operating system, including, The control method according to feature 6.

8. Configuring the core of the second operating system is This includes allocating a preset number of cores to the second operating system, The control method further includes, This includes releasing a portion of the core to the first operating system after the second operating system has finished booting, The control method according to feature 6.

9. The control method further includes, The aforementioned application operating system writes a message to shared memory, The application operating system triggers the safety monitoring operating system to receive the interrupt by writing an interrupt, The safety monitoring operating system includes, after receiving the interrupt, entering the interrupt handler and reading the message from the shared memory, The control method according to feature 5.

10. The aforementioned application operating system sends a message to the aforementioned security monitoring operating system, The security monitoring operating system determines the execution state of the application operating system based on the message or the waiting time for receiving the message, If the execution state is abnormal, the safety monitoring operating system further includes restarting the application operating system. The control method according to feature 5.

Images