WO2024012603A1 - 基于多操作系统的车载系统及其控制方法 - Google Patents

基于多操作系统的车载系统及其控制方法 Download PDF

Info

Publication number
WO2024012603A1
WO2024012603A1 PCT/CN2023/114652 CN2023114652W WO2024012603A1 WO 2024012603 A1 WO2024012603 A1 WO 2024012603A1 CN 2023114652 W CN2023114652 W CN 2023114652W WO 2024012603 A1 WO2024012603 A1 WO 2024012603A1
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
application
security monitoring
kernel
vehicle
Prior art date
Application number
PCT/CN2023/114652
Other languages
English (en)
French (fr)
Inventor
刘丹丹
孙超杰
Original Assignee
合肥杰发科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 合肥杰发科技有限公司 filed Critical 合肥杰发科技有限公司
Publication of WO2024012603A1 publication Critical patent/WO2024012603A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G06F9/441—Multiboot arrangements, i.e. selecting an operating system to be loaded

Definitions

  • the present application relates to the field of vehicle technology, and in particular to a vehicle system based on a multi-operating system and a control method thereof.
  • In-vehicle systems not only include Android entertainment functions, car navigation, reversing rear view and other functions, but also include safety monitoring and other functions to monitor system safety.
  • the main technical problem solved by this application is to provide a multi-operating system-based vehicle system and its control method to improve the effectiveness of safety monitoring and improve the safety performance of the vehicle system.
  • the vehicle-mounted system based on multiple operating systems 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; among them, the application operating system is used to run non-safety applications; security
  • the monitoring operating system communicates with the application operating system and is used to run security monitoring services to perform security monitoring on the application operating system.
  • this application provides a control method for a vehicle-mounted system based on a multi-operating system.
  • the vehicle-mounted system includes at least one application operating system and a safety monitoring operating system.
  • the application operating system includes a second operating system, which uses different cores of the same processor as the safety monitoring operating system.
  • the second operating system is used to run quick-start applications.
  • Control method It further includes: configuring the kernel for the second operating system and the safety monitoring operating system; obtaining the power-on startup command, loading the image file of the safety monitoring operating system into the running memory of the vehicle system, and starting the kernel operation corresponding to the safety monitoring operating system.
  • the vehicle-mounted system based on multiple operating systems of this application 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 processors of the same processor. Kernel; among them, the application operating system is used to run non-security applications; the security monitoring operating system communicates with the application operating system to conduct security monitoring of the application operating system.
  • the vehicle-mounted system of this application uses a security monitoring operating system to implement security monitoring of the application operating system, and uses different cores of the same processor to implement the security monitoring operating system and the application operating system respectively to achieve isolation between the two and avoid application operations. Abnormal application operation in the system causes the security monitoring application to fail to operate normally. Therefore, it can improve the effectiveness of security monitoring and improve the safety performance of the vehicle system.
  • Figure 1 is a schematic structural diagram of an embodiment of a vehicle-mounted system based on multiple operating systems of the present application
  • FIG. 2 is a schematic structural diagram of the core division of the vehicle system of this application.
  • FIG. 3 is a schematic diagram of a startup process of the vehicle-mounted system of this application.
  • FIG. 4 is another structural schematic diagram of the core division of the vehicle system of this application.
  • FIG. 5 is a schematic diagram of another startup process of the vehicle-mounted system of the present application.
  • Figure 6 is a schematic diagram of the communication flow between different cores of the vehicle-mounted system based on multiple operating systems of this application;
  • Figure 7 is a schematic diagram of the work flow of the safety monitoring operating system in the vehicle-mounted system based on multiple operating systems of this application;
  • Figure 8 is a schematic flowchart of an embodiment of a control method for a vehicle-mounted system based on multiple operating systems of the present application
  • Figure 9 is a schematic diagram of the communication flow between different cores in the control method of the vehicle-mounted system based on multiple operating systems of this application;
  • Figure 10 is a schematic diagram of the work flow of the safety monitoring operating system in the control method of the vehicle-mounted system based on multiple operating systems of the present application.
  • FIG. 1 is a schematic structural diagram of an embodiment of the vehicle-mounted system based on multiple operating systems of the application.
  • the vehicle-mounted system of this embodiment includes: at least one application operating system and a security monitoring operating system 12.
  • the application operating system and the security monitoring operating system 12 adopt different cores of the same processor, that is, they respectively adopt core 1 and core 2 (and core 3); Among them, the application operating system is used to run non-security applications; the security monitoring operating system 12 is communicated with the application operating system and is used to run security monitoring services to perform security monitoring of the application operating system.
  • the vehicle-mounted system of this embodiment uses the security monitoring operating system 12 to implement security monitoring of the application operating system, and uses different cores of the same processor to implement the security monitoring operating system 12 and the application operating system respectively to achieve isolation between the two. It can avoid the problem of abnormal application operation in the application operating system that causes the security monitoring application to fail to run normally. Therefore, it can improve the effectiveness of security monitoring and improve the safety performance of the vehicle-mounted system.
  • the core 2 used to run the security monitoring operating system 12, that is, the core 2 adopted 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 mainly used to run a security monitoring application, that is, a security monitoring service, to monitor the running status of the application operating system, etc.
  • the core 1 (and core 3) used to run the application operating system that is, the core 1 (and core 3) used by the application operating system can be one or more (two or more) others of the same processor. Kernel.
  • the application operating system of this embodiment includes a first operating system 11 and a second operating system 13.
  • the first operating system 11 may be an Android operating system.
  • the Android operating system mainly includes: (a) Kernel layer, Its driver module includes all device drivers on the system-on-a-chip (SOC) except the video (VEDIO) device driver, such as graphics processor (graphics processing unit, GPU), data processor (Data Processing Unit) , DPU), other module drivers (including EMMC, I2C, WIFI, USB and other modules); (b) Service layer, that is, the service layer, whose services include all running services, such as OpenGLES, CarmeraSource, Surfaceflinger, other running services (such as Storage Service, WIFI Service, Audio Service); (c) Application layer, its applications include VEDIO Player, Music Play, 3rd Patry APP, etc.
  • the application operating system may also be other non-secure multi-application systems.
  • multiple (two or more) cores in this application can be homogeneous or heterogeneous, and there is no specific limitation.
  • the second operating system 13 of this embodiment can be a Linux operating system, which uses different kernels of the same processor as the first operating system and the security monitoring operating system 12.
  • the Linux operating system uses kernel 3, and the Android operating system uses kernel 3. 1. That is, the Linux operating system, the Android operating system and the security monitoring operating system 12 respectively use independent kernels in the same process.
  • the Linux operating system is used to run the quick-start application; among them, the Linux operating system only sets resource items that the quick-start application depends on to simplify the Linux operating system 13 and shorten the startup time of the quick-start application.
  • the security monitoring operating system 12 is communicated and connected with the Android operating system and the Linux operating system respectively, and is used for security monitoring of the Android operating system and the Linux operating system respectively.
  • the kernel used to run the Linux operating system may be one or more (two or more) other kernels of the same processor.
  • Quick start applications are applications that need to be started quickly, such as around view monitor (AVM) applications, reversing applications in smart cockpits, vehicle instrument applications, and vehicle dealer management system (Dealer Management System, DMS) applications. wait.
  • AVM view monitor
  • DMS vehicle dealer management system
  • GPU can accelerate image processing, corresponding to the GPU driver of Android Kernel and the OpenGLES interface of Android Service
  • DPU is a display module, corresponding to the DPU driver of Android Kernel and the Surfacefingler interface of Android Service
  • VEDIO IN is a camera image acquisition module, corresponding to Android Kernel The VEDIOIN driver and the CamerSource interface of Android Service.
  • the AVM application is an APP application written in Java in the Android application layer. It obtains the camera image data collected by the VEDIO IN module through the CameraSource interface, uses the GPU hardware module to complete image data distortion correction and splicing through algorithms, and finally displays it on the screen through Surfaceflinger.
  • the Android system is a system with huge applications.
  • the system runs many services. There are many security issues in complex and huge systems. For example, if one of the services runs abnormally, it may cause the entire system to crash.
  • the AVM application will also be affected, so AVM functions are affected by the Android system and are less secure.
  • the vehicle-mounted system of this embodiment separates the AVM function and runs it separately in a Linux operating system, which can achieve the effect of quick startup of the AVM and safe operation.
  • the Linux operating system in this embodiment is customized and only includes: (a) Linux Kernel layer, which mainly includes GPU, DPU, and VEDIO device drivers that AVM depends on; (b) Linux Service layer, which mainly includes OpenGLES, which AVM depends on. CarmeraSource, Surfaceflinger and Safety Service; (c) The Linux application layer only runs one AVM application.
  • the simplified Linux operating system can further speed up AVM startup.
  • SOC integrates multiple cores, such as 4 cores or 8 cores.
  • This embodiment makes full use of the resource advantages of the multi-core system to run three operating systems on the SOC.
  • the first operating system 11 runs on some cores
  • the security monitoring operating system 12 runs on some cores
  • the second operating system 13 runs on the remaining cores. superior.
  • both the first operating system 11 and the second operating system 13 of this embodiment require two resource modules: GPU and DPU.
  • Software virtualization technology (Hypervisor) can be used to achieve the first operating system 11 and the second operating system 13 Access these 2 resource modules together.
  • the vehicle system further includes a SOC.
  • the SOC is provided with multiple physical cores, and at least one physical core is allocated to the first operating system 11, the safety monitoring operating system 12, and the second operating system 13 respectively.
  • the SOC runtime allocates physical cores to the first operating system 11, the security monitoring operating system 12 and the second operating system 13.
  • the SOC is equipped with 4 physical cores Core[0]-Core[3 ], allocate Core[0] to the security monitoring operating system 13; allocate Core[1] to the second operating system; allocate Core[2] and Core[3] to the first operating system 11.
  • the vehicle system is powered on, runs the bootloader, and initializes the hardware devices.
  • the SOCs are allocated differently to the first operating system 11, the security monitoring operating system 12, and the second operating system 13.
  • the bootloader loads the Min Kernel into the running memory and starts the kernel corresponding to the Linux operating system. Nuclear operation. After the Linux kernel completes driver loading, it starts the CarmeraSource, surfaceflinger and Opengles services that AVM depends on, and finally starts the AVM application.
  • the bootloader loads the Android Kernel into the running memory and starts the kernel operation corresponding to the Android operating system. After the Android Kernel completes driver loading, it starts all Android Services. After the Android Service is started, it finally starts the Android application.
  • more physical cores can be allocated to the second operating system 13 during the startup phase of the AVM application, and then the physical cores can be released to the first operating system 11 after the AVM application is started.
  • This embodiment configures more physical cores for the second operating system 13 during the AVM application startup phase, which can ensure that the AVM application starts quickly, and after the AVM application startup is completed, some physical cores are allocated to some physical cores of the second operating system 13
  • the kernel is released to other application operating systems of the vehicle system, such as the first operating system 11, to ensure the running speed of other application operating systems and the reasonable utilization of resources.
  • software virtualization (Hypervisor) technology can also be used to allocate kernels to the first operating system 11, the security monitoring operating system 12 and the second operating system 13.
  • the vehicle-mounted system of this embodiment further includes a kernel virtualization system 14 (as shown in Figure 4), which is a general implementation of a layer of software designed at the EL2 (Exception Level) of the processor.
  • the kernel virtualization system 14 uses Hypervisor technology to virtualize the physical kernel into multiple virtual kernels, and the SOC allocates at least one virtual kernel to the first operating system 11, the security monitoring operating system 12, and the second operating system 13 respectively.
  • the kernel virtualization system 14 uses Hypervisor technology to virtualize the physical cores Core[0]-Core[3] into multiple virtual cores VCore[0]-VCore[5], and allocate VCore[0] To the security monitoring operating system 12; allocate VCore[0] and VCore[2] to the second operating system 13; allocate VCore[3], VCore[4] and VCore[5] to the first operating system 11.
  • the system is powered on, runs the bootloader, and initializes the hardware devices.
  • the bootloader loads the Hypervisor image file into the running memory.
  • multiple virtual kernels are virtualized; the Hypervisor loads security monitoring
  • the image file of the operating system 12 is stored in the running memory, and the corresponding kernel operation of the security monitoring operating system 12 is started to complete the startup of the security monitoring operating system 12 and its security monitoring service.
  • Hypervisor loads the Min Kernel into the running memory and starts the kernel operation corresponding to the Linux operating system. After the Linux kernel completes driver loading, it starts the CarmeraSource, surfaceflinger and Opengles services that AVM depends on, and finally starts the AVM application.
  • Hypervisor loads the Android Kernel into the running memory and starts the corresponding program of the Android operating system.
  • the kernel is running. After the Android Kernel completes driver loading, it starts all Android Services. After the Android Service is started, it finally starts the Android application.
  • the physical division method of the embodiment in Figure 2 and the virtual division method of the embodiment of Figure 4 can also be combined to allocate kernels to the first operating system, the security monitoring operating system and the second operating system.
  • the SOC is equipped with multiple physical cores, and the kernel virtualization system virtualizes some physical cores into multiple virtual cores.
  • the SOC allocates at least one virtual core to the first operating system and the second operating system respectively, and performs security monitoring operations.
  • the system is allocated at least one physical core.
  • physical cores may also be allocated to the first operating system and/or the second operating system, and virtual cores may be allocated to the security monitoring operating system.
  • the vehicle-mounted system of this embodiment is also provided with a memory.
  • the vehicle-mounted system of this embodiment can also realize communication between different cores.
  • this embodiment realizes communication between different cores based on interrupts and shared memory.
  • n cores there are n cores in the SOC. Take Core[0] sending a message to Core[n-1] as an example:
  • Core[0] writes a message to the scheduled shared memory data_A[]; Core[0] writes an interrupt, and the controller triggers Core[n-1] to receive the interrupt; Core[n-1] receives the interrupt and enters the interrupt handler , and read the message from the shared memory data_A[].
  • this embodiment adopts the following method to implement the security monitoring operating system 12 to monitor the motion status of the first operating system 11 and the second operating system 13: running on the second operating system 13 and the first operating system 13.
  • the Safety Service on the operating system 11 will send messages at fixed frequency intervals through inter-process communication, that is, IPC, to inform the safety monitoring service Safety Monitor running on the operating system 12.
  • the message type can be defined by yourself, and two messages can be defined: "alive" and "fatal”.
  • Safety Monitor When Safety Monitor receives "alive”, it determines that the operating system that sent the message is running normally, and continues to monitor the message without processing it; when Safety Monitor receives "fatal”, it determines that the operating system that sent the message encountered a fatal error and needs to be restarted to run the message. The operating system to resume normal operation; Safety Monitor does not receive a message from the operating system within the specified time, and determines that the operating system that has not sent the message has encountered a fatal error and needs to restart the operating system to resume normal operation.
  • Safety Monitor can also monitor its own operating status through the watchdog Watchdog, such as sending a dog feeding signal to Watchdog's Register at fixed frequency intervals. If Safety Monitor runs abnormally and does not feed the dog in time, the operating system can be safely monitored. 12 will reboot to resume normal operation.
  • FIG. 8 8 is a schematic flowchart of an embodiment of a control method for a vehicle-mounted system based on multiple operating systems of the present application.
  • the control method of this embodiment can be used in the above-mentioned vehicle-mounted system based on multiple operating systems.
  • the control method of this embodiment specifically includes the following steps:
  • Step S81 Configure the kernel for the second operating system and the security monitoring operating system.
  • the vehicle system also 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 configures the kernel for the second operating system and the safety monitoring operating system.
  • the SOC configures the kernel for the second operating system, and the second operating system and the security monitoring operating system are located in different cores of the processor.
  • the second operating system is used to run quick-start applications; among them, the second operating system only sets the parameters that the quick-start application depends on. Resource items to simplify the Linux operating system and shorten the startup time of quick-start applications.
  • Quick start applications are applications that need to be started quickly, such as AVM applications, reversing applications in smart cockpits, vehicle instrument applications, vehicle DMS applications, etc.
  • the application operating system may also include a first operating system.
  • the SOC configures kernels for the first operating system, the second operating system and the security monitoring operating system respectively.
  • the SOC When the SOC is running, at least one physical core is allocated to the first operating system, the security monitoring operating system, and the second operating system; or when the SOC is running, the physical core of the SOC is virtualized into multiple virtual cores by using the hypervisor technology through the kernel virtualization system. , the SOC allocates at least one virtual core to the first operating system, the security monitoring operating system and the second operating system respectively; or the kernel virtualization system uses Hypervisor technology to virtualize some of the physical cores of the SOC into multiple virtual cores, and the SOC respectively At least one virtual core is allocated to the first operating system and the second operating system, and at least one non-virtualized physical core is allocated to the security monitoring operating system.
  • the SOC may also allocate physical cores to the first operating system and/or the second operating system, and allocate virtual cores to the security monitoring operating system.
  • the second operating system in this embodiment may be a Linux operating system, and the first operating system may be an Android operating system; in other embodiments, the first operating system may also be other non-secure multi-application systems.
  • Step S82 Obtain the power-on startup command, load the image file of the security monitoring operating system into the running memory of the control system, and start the kernel operation corresponding to the security monitoring operating system to complete the security monitoring operating system and its security monitoring services. start up.
  • Step S83 Load the Kernel of the second operating system into the running memory, start the kernel operation corresponding to the second operating system, and sequentially complete the driver loading of the second operating system, the startup of the services that the quick-start application depends on, and the quick-start application. start up.
  • control method of this embodiment also includes step S84.
  • Step S84 Load the Kernel of the first operating system into the running memory, start the kernel operation corresponding to the first operating system, and sequentially complete the driver loading, service startup, and application startup of the first operating system.
  • the vehicle-mounted system of this embodiment uses a security monitoring operating system to implement security monitoring of the application operating system, and uses different cores of the same processor to implement the security monitoring operating system and the application operating system respectively to achieve isolation between the two and avoid Applying the problem of abnormal application operation in the operating system that causes the security monitoring application to fail to run normally, it can improve the effectiveness of security monitoring and improve the safety performance of the vehicle-mounted system.
  • the quick-start application is separated and run independently in a Linux operating system, so that the quick-start application can be started quickly and run safely.
  • steps S82 to S84 is not limited.
  • the vehicle system is powered on, runs the bootloader, and initializes the hardware devices.
  • the SOC is the Android operating system.
  • the security monitoring operating system and the Linux operating system allocate different physical cores; the bootloader loads the image file of the security monitoring operating system into the running memory, starts the corresponding kernel operation of the security monitoring operating system, and completes the security monitoring operating system and its security monitoring services. start up.
  • the bootloader loads the Min Kernel into the running memory and starts the kernel operation corresponding to the Linux operating system. After the Linux kernel completes driver loading, it starts the CarmeraSource, surfaceflinger and Opengles services that AVM depends on, and finally starts the AVM application.
  • the bootloader loads the Android Kernel into the running memory and starts the kernel operation corresponding to the Android operating system. After the Android Kernel completes driver loading, it starts all Android Services. After the Android Service is started, it finally starts the Android application.
  • the system is powered on, runs the bootloader, and initializes the hardware devices.
  • the bootloader loads the Hypervisor image file into the running memory.
  • multiple virtual kernels are virtualized; the hypervisor loads the image file of the security monitoring operating system into the running memory, starts the kernel operation corresponding to the security monitoring operating system, and completes the startup of the security monitoring operating system and its security monitoring service.
  • Hypervisor loads the Min Kernel into the running memory and starts the kernel corresponding to the Linux operating system. Nuclear operation. After the Linux kernel completes driver loading, it starts the CarmeraSource, surfaceflinger and Opengles services that AVM depends on, and finally starts the AVM application.
  • Hypervisor loads the Android Kernel into the running memory and starts the kernel operation corresponding to the Android operating system. After the Android Kernel completes driver loading, it starts all Android Services. After the Android Service is started, it finally starts the Android application.
  • the SOC allocates a preset number of cores to the second operating system, and releases some of the cores to the first operating system after the second operating system is started.
  • the preset number is greater than the number of cores required by the second operating system to run the quick-start application.
  • This embodiment configures more physical cores for the second operating system during the AVM application startup phase, which can ensure that the AVM application starts quickly, and after the AVM application startup is completed, some physical cores allocated to the second operating system are released.
  • control method of this application can also implement communication between different cores.
  • the processor (SOC) is provided with a first core and a second core, respectively corresponding to the application operating system and the security monitoring system.
  • the control method of this embodiment implements communication between different cores based on interrupts and shared memory.
  • the communication method specifically includes steps S91 to S93 as shown in Figure 9 .
  • Step S91 The application operating system writes a message to the shared memory.
  • the first core writes a message to shared memory.
  • Step S92 Apply the operating system write interrupt to trigger the security monitoring system to receive the interrupt.
  • the first core writes an interrupt to trigger the second core to receive the interrupt.
  • Step S93 After receiving the interrupt, the security monitoring operating system enters the interrupt handler and reads the message from the shared memory.
  • the second core After the second core receives the interrupt, it enters the interrupt handler and reads the message from the shared memory.
  • Core[0] writes a message to the scheduled shared memory data_A[]; Core[0] writes an interrupt, and the controller triggers Core[n-1] to receive the interrupt; Core[n-1] receives the interrupt and enters the interrupt handler in and read the message from the shared memory data_A[].
  • control method of this application can also realize security monitoring of the application operating system by the security monitoring operating system. Specifically, it can be implemented by the method shown in Figure 10.
  • the method in this embodiment includes Step S101 to step S103.
  • Step S101 The application operating system sends a message to the security monitoring operating system.
  • the Safety Service running on the application operating system will send messages at fixed frequency intervals through inter-process communication, that is, IPC, to inform the safety monitoring service Safety Monitor running on the safety monitoring operating system.
  • IPC inter-process communication
  • the message type can be defined by yourself, and two messages can be defined: “alive” and “fatal”.
  • Step S102 The security monitoring operation determines the running status of the application operating system based on the message or the waiting time for receiving the message.
  • Safety Monitor When Safety Monitor receives "alive”, it determines that the application operating system that sent the message is running normally, and continues to monitor the message without processing it; when Safety Monitor receives "fatal”, it determines that the application operating system that sent the message encountered a fatal error and needs to be restarted. Run the application operating system to resume normal operation; Safety Monitor does not receive a message from the application operating system within the specified time, and determines that the application operating system that has not sent the message has encountered a fatal error while running and needs to restart the application operating system. , to resume normal operation.
  • Step S103 If the running state is an abnormal state, the security monitoring operating system restarts the application operating system.
  • the security monitoring operating system communicates with the Android operating system and the Linux operating system respectively, and the above method can be used to implement security monitoring of the Android operating system and the Linux operating system.
  • Safety Monitor can also monitor its own operating status through the watchdog Watchdog, such as sending a dog feeding signal to the Register of Watchdog at fixed frequency intervals. If Safety Monitor runs abnormally and does not feed the dog in time, restart the safety monitoring operation. system to restore normal operation.
  • the vehicle-mounted system based on multiple operating systems of this application 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; wherein, the application operating system uses For running non-security applications; the security monitoring operating system communicates with the application operating system for security monitoring of the application operating system.
  • the vehicle-mounted system of this application uses a security monitoring operating system to implement security monitoring of the application operating system, and uses different cores of the same processor to implement the security monitoring operating system and the application operating system respectively to achieve isolation between the two and avoid application operations.
  • Abnormal application operation in the system causes the security monitoring application to fail to operate normally. Therefore, it can improve the effectiveness of security monitoring and improve the safety performance of the vehicle system.
  • This application proposes to run AVM applications independently in a system and allocate multi-core SOC as security
  • the kernel required for the monitoring operating system, the kernel required for the second operating system and the kernel required for the first operating system, the second operating system runs AVM applications, the first operating system runs Android applications, and the security monitoring operating system runs Safety Monitor is used to monitor the running status of the second operating system and the first operating system, and handle abnormal recovery to achieve fast startup (the AVM startup display can be completed in about 3S) and safe operation.
  • This application places the AVM application in the second operating system, because the second operating system only needs to support the AVM application and can be cut very streamlined to achieve the purpose of quick startup; and compared with the complex and bulky first operating system, the streamlined second operating system
  • the operating system runs fewer services and has a single application, so it is more stable and secure.
  • the first operating system and the second operating system are isolated, so an abnormal operation of the first operating system will not affect the second operating system.
  • the system architecture and method proposed in this application are not only suitable for AVM quick start and safe operation scenarios, but also can be applied to other module scenarios, such as quick start of reversing in the smart cockpit, quick start of vehicle instrumentation, quick start of vehicle DMS system, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

本申请提供一种基于多操作系统的车载系统及其控制方法。该基于多操作系统的车载系统包括：至少一个应用操作系统及安全监控操作系统，应用操作系统及安全监控操作系统采用同一处理器的不同内核；其中，应用操作系统用于运行非安全应用；安全监控操作系统与应用操作系统通信连接，用于运行安全监控服务，以对应用操作系统进行安全监控。

Description

基于多操作系统的车载系统及其控制方法
本申请要求于2022年07月11日提交的申请号为2022108132200，发明名称为“基于多操作系统的车载系统及其控制方法”的中国专利申请的优先权，其通过引用方式全部并入本申请。
【技术领域】
本申请涉及车载技术领域，特别是涉及一种基于多操作系统的车载系统及其控制方法。
【背景技术】
目前，汽车中控系统，即车载系统已经越来越普及，车载系统不仅包括安卓(Android)娱乐功能、汽车导航、倒车后视等功能，还包括监测系统安全的安全监控等功能。
但现有的车载系统通常是基于安卓操作系统的内核，实现一个应用程序来实现其安全监控功能的。而安卓操作系统是一个应用庞大的系统，运行了很多应用，复杂庞大的系统存在不少安全性问题，其中一个应用运行异常，可能就会导致整个系统崩溃。因此，其安全监控功能会受到安卓操作系统的其它应用运行异常的影响，不能提供有效的安全监控，系统安全性较低。
【发明内容】
本申请主要解决的技术问题是提供一种基于多操作系统的车载系统及其控制方法，以提高安全监控的有效性，提高车载系统的安全性能。
为解决上述技术问题，本申请提供一种基于多操作系统的车载系统。该基于多操作系统的车载系统包括：至少一个应用操作系统及安全监控操作系统，应用操作系统及安全监控操作系统采用同一处理器的不同内核；其中，应用操作系统用于运行非安全应用；安全监控操作系统与应用操作系统通信连接，用于运行安全监控服务，以对应用操作系统进行安全监控。
为解决上述技术问题，本申请提供一种基于多操作系统的车载系统的控制方法。该车载系统包括至少一个应用操作系统及安全监控操作系统，应用操作系统包括第二操作系统，与安全监控操作系统采用同一处理器的不同内核，第二操作系统用于运行快启应用，控制方法进一步包括：为第二操作系统及安全监控操作系统配置内核；获取到上电启动指令，将安全监控操作系统的镜像文件加载到车载系统的运行内存中，并启动安全监控操作系统对应的内核运行， 以完成安全监控操作系统及其安全监控服务的启动；将第二操作系统的Kernel加载到运行内存中，并启动第二操作系统对应的内核运行，依次完成第二操作系统的驱动加载、快启应用依赖的服务的启动、快启应用的启动。
与现有技术相比，本申请的有益效果是：本申请基于多操作系统的车载系统包括：至少一个应用操作系统及安全监控操作系统，应用操作系统及安全监控操作系统采用同一处理器的不同内核；其中，应用操作系统用于运行非安全应用；安全监控操作系统与应用操作系统通信连接，用于对应用操作系统进行安全监控。本申请车载系统利用安全监控操作系统实现对应用操作系统的安全监控，且采用同一处理器的不同内核分别实现安全监控操作系统及应用操作系统，以实现二者之间的隔离，能够避免应用操作系统中应用运行异常而导致安全监控应用无法正常运行的问题，因此能够提高安全监控的有效性，提高车载系统的安全性能。
【附图说明】
图1是本申请基于多操作系统的车载系统一实施例的结构示意图；
图2是本申请车载系统内核划分的一结构示意图；
图3是本申请车载系统的一启动流程示意图；
图4是本申请车载系统内核划分的另一结构示意图；
图5是本申请车载系统的另一启动流程示意图；
图6是本申请基于多操作系统的车载系统不同内核之间的通信流程示意图；
图7是本申请基于多操作系统的车载系统中安全监控操作系统的工作流程示意图；
图8是本申请基于多操作系统的车载系统的控制方法一实施例的流程示意图；
图9是本申请基于多操作系统的车载系统的控制方法中不同内核之间的通信流程示意图；
图10是本申请基于多操作系统的车载系统的控制方法中安全监控操作系统的工作流程示意图。
【具体实施方式】
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请的一部分实施例，而不是 全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请首先提出一种基于多操作系统的车载系统，如图1所示，图1是本申请基于多操作系统的车载系统一实施例的结构示意图。本实施例的车载系统包括：至少一个应用操作系统及安全监控操作系统12，应用操作系统及安全监控操作系统12采用同一处理器的不同内核，即二者分别采用内核1及内核2(和内核3)；其中，应用操作系统用于运行非安全应用；安全监控操作系统12与应用操作系统通信连接，用于运行安全监控服务，以对应用操作系统进行安全监控。
本实施例的车载系统利用安全监控操作系统12实现对应用操作系统的安全监控，且采用同一处理器的不同内核分别实现安全监控操作系统12及应用操作系统，以实现二者之间的隔离，能够避免应用操作系统中应用运行异常而导致安全监控应用无法正常运行的问题，因此能够提高安全监控的有效性，提高车载系统的安全性能。
其中，用于运行安全监控操作系统12的内核2，即安全监控操作系统12采用的内核2可以是同一处理器的一个或者多个(两个或者两个以上)内核。安全监控操作系统12主要用于运行一个安全监控应用，即安全监控服务，以监控应用操作系统的运行状态等。
其中，用于运行应用操作系统的内核1(和内核3)，即应用操作系统采用的内核1(和内核3)可以是同一处理器的一个或者多个(两个或者两个以上)其它的内核。
其中，本实施例的应用操作系统包括第一操作系统11及第二操作系统13，其中，第一操作系统11可以是安卓操作系统，安卓(Android)操作系统主要包括：(a)Kernel层，其驱动模块包括片上系统(System-on-a-chip，SOC)上除视频(VEDIO)设备驱动外的所有设备驱动，例如图形处理器(graphics processing unit，GPU)、数据处理器(Data Processing Unit，DPU)、其他模块驱动(包括EMMC、I2C、WIFI、USB等模块)；(b)Service层，即服务层，其服务包括所有运行服务，例如OpenGLES、CarmeraSource、Surfaceflinger、其他运行服务(如Storage Service、WIFI Service、Audio Service)；(c)应用层，其应用包括VEDIO Player、Music Play、3rd Patry APP等。
关于安卓操作系统的具体介绍可以参阅现有技术，本文不做具体限定。在 其它实施例中，应用操作系统还可以是其它非安全的多应用系统等。
需要注意的是本申请的多个(两个或者两个以上)内核可以是同构的或者异构的，具体不做限定。
可选地，本实施例的第二操作系统13可以是Linux操作系统，与第一操作系统及安全监控操作系统12采用同一处理器的不同内核，Linux操作系统采用内核3，安卓操作系统采用内核1，即Linux操作系统、安卓操作系统及安全监控操作系统12分别采用同一处理中独立的内核。
其中，Linux操作系统用于运行快启应用；其中，Linux操作系统仅设置快启应用依赖的资源项，以简化Linux操作系统13，缩短快启应用的启动时间。
安全监控操作系统12分别与安卓操作系统及Linux操作系统通信连接，用于分别安卓操作系统及对Linux操作系统进行安全监控。
其中，用于运行Linux操作系统的内核可以是同一处理器的一个或者多个(两个或者两个以上)其它的内核。
快启应用，即需快速启动的应用，如全景式监控影像系统(Around View Monitor，AVM)应用、智能座舱中倒车应用、车载仪表应用、车载汽车经销商管理系统(Dealer Management System，DMS)应用等。
下面以Linux操作系统运行AVM应用为例，进行描述。
AVM应用依赖3个重要的硬件模块：GPU、DPU、VEDIO IN。其中，GPU可以加速图像处理，对应Android Kernel的GPU驱动和Android Service的OpenGLES接口；DPU为显示模块，对应Android Kernel的DPU驱动和Android Service的Surfacefingler接口；VEDIO IN为摄像头图像采集模块，对应Android Kernel的VEDIOIN驱动和Android Service的CamerSource接口。
AVM应用是Android应用层一个java写的APP应用程序，它通过CameraSource接口获取VEDIO IN模块采集的摄像头图像数据，经过算法使用GPU硬件模块完成图像数据畸变矫正以及拼接，最后通过Surfaceflinger显示到屏幕上。
现有的车载系统中，如上的AVM系统存在如下问题：
(1)Camerasource接口、Surfaceflinger服务、OpenGLES库等这些组件都必须在Android主文件系统加载起来后才能工作，AVM APP更是要整个Android系统启动完成，进入主界面后才能启动。所以传统的车载系统，汽车冷启动，获得AVM图像的过程非常慢，一般在20s以上。
(2)Android系统是一个应用庞大系统，系统运行了很多服务，复杂庞大的系统存在不少安全性问题，例如其中一个服务运行异常，可能导致整个系统崩溃，这个AVM应用也会受到影响，所以AVM功能受Android系统的影响，安全性较低。
而本实施例的车载系统，将AVM功能独立出来，单独运行在一Linux操作系统中，可以达到AVM快速启动，且运行安全的效果。
且本实施例的Linux操作系统是定制裁剪的，仅包括：(a)Linux Kernel层，主要包括AVM依赖的GPU、DPU、VEDIO设备驱动；(b)Linux Service层，主要包括AVM依赖的OpenGLES、CarmeraSource、Surfaceflinger和Safety Service；(c)Linux应用层只运行一个AVM应用。简化的Linux操作系统能够进一步加快AVM的启动。
SOC集成多个内核，例如4个内核或者8个内核。本实施例充分利用多核系统的资源优势，在SOC上运行3个操作系统，第一操作系统11运行在部分内核，安全监控操作系统12运行在部分内核，第二操作系统13运行在剩下内核上。
进一步地，本实施例的第一操作系统11及第二操作系统13都需要GPU及DPU这2个资源模块，可以使用软件虚拟化技术(Hypervisor)达到第一操作系统11及第二操作系统13共同访问这2个资源模块。
由上述分析可知，车载系统进一步包括SOC，在SOC设有多个物理内核，并分别为第一操作系统11、安全监控操作系统12及第二操作系统13分配至少一个物理内核。
具体地，如图2所示，SOC运行时为第一操作系统11、安全监控操作系统12及第二操作系统13分配物理内核，例如SOC设有4个物理内核Core[0]-Core[3]，分配Core[0]给安全监控操作系统13；分配Core[1]给第二操作系统；分配Core[2]及Core[3]给第一操作系统11。
可选地，如图3所示，车载系统上电启动，运行引导加载程序，即bootloader，初始化硬件设备，SOC分别为第一操作系统11、安全监控操作系统12及第二操作系统13分配不同的物理内核；bootloader加载安全监控操作系统12的镜像文件到运行内存中，启动安全监控操作系统12对应的内核运行，完成安全监控操作系统12及其安全监控服务的启动。
bootloader加载Min Kernel到运行内存中，启动Linux操作系统对应的内 核运行。Linux kernel完成驱动加载后，启动AVM依赖的CarmeraSource、surfaceflinger及Opengles服务，最后启动AVM应用。
bootloader加载Android Kernel到运行内存中，启动安卓操作系统对应的内核运行。Android Kernel完成驱动加载后，启动Android所有Service，在Android Service启动完成后，最后启动Android应用。
进一步地，为快速启动AVM应用，可以在AVM应用启动阶段分配较多的物理内核给第二操作系统13，等AVM应用启动完成后，再释放物理内核给第一操作系统11。本实施例在AVM应用启动阶段为第二操作系统13配置较多的物理内核，能够保证AVM应用快速启动，且在AVM应用启动完成后，再将部分物理分配给第二操作系统13的部分物理内核释放给车载系统的其它应用操作系统，如第一操作系统11，以保证其它应用操作系统的运行速率及资源的合理利用。
在另一实施例中，还可以通过软件虚拟化(Hypervisor)技术为第一操作系统11、安全监控操作系统12及第二操作系统13分配内核。本实施例的车载系统进一步包括内核虚拟化系统14(如图4所示)，其是通用实现是在处理器的EL2(Exception Level)设计一层软件。内核虚拟化系统14利用Hypervisor技术将物理内核虚拟化为多个虚拟内核，SOC分别为第一操作系统11、安全监控操作系统12及第二操作系统13分配至少一个虚拟内核。
具体地，如图4所示，内核虚拟化系统14使用Hypervisor技术将物理内核Core[0]-Core[3]虚拟化多个虚拟内核VCore[0]-VCore[5]，分配VCore[0]给安全监控操作系统12；分配VCore[0]、VCore[2]给第二操作系统13；分配VCore[3]、VCore[4]、VCore[5]给第一操作系统11。
可选地，如图5所示，系统上电启动，运行bootloader，初始化硬件设备，bootloader加载Hypervisor的镜像文件到运行内存中，启动Hypervisor启动成功后，虚拟化多个虚拟内核；Hypervisor加载安全监控操作系统12的镜像文件到运行内存中，启动安全监控操作系统12对应的内核运行，完成安全监控操作系统12及其安全监控服务的启动。
Hypervisor加载Min Kernel到运行内存中，启动Linux操作系统对应的内核运行。Linux kernel完成驱动加载后，启动AVM依赖的CarmeraSource、surfaceflinger及Opengles服务，最后启动AVM应用。
Hypervisor加载Android Kernel到运行内存中，启动安卓操作系统对应的 内核运行。Android Kernel完成驱动加载后，启动Android所有Service，在Android Service启动完成后，最后启动Android应用。
在另一实施例中，还可以结合图2实施例的物理划分方式及图4实施例的虚拟划分方式为第一操作系统、安全监控操作系统及第二操作系统分配内核。
具体地，SOC设有多个物理内核，内核虚拟化系统将部分物理内核虚拟化为多个虚拟内核，SOC分别为第一操作系统及第二操作系统分配至少一个虚拟内核，并为安全监控操作系统分配至少一个物理内核。
在其它实施例中，还可以为第一操作系统和/或第二操作系统分配物理内核，为安全监控操作系统分配虚拟内核。
本实施例的车载系统还设置有内存。
可选地，本实施例的车载系统还能够实现不同内核之间通信，具体地，如图6所示，本实施例是基于中断和共享内存的方式实现不同内核之间通信。假定SOC中有n个内核，以Core[0]向Core[n-1]发送消息为例：
Core[0]向预定的共享内存data_A[]写入消息；Core[0]写中断，控制器触发Core[n-1]收到中断；Core[n-1]收到中断，进入中断处理程序中，并从共享内存data_A[]读取该消息。
可选地，如图7所示，本实施例采用如下方式实现安全监控操作系统12对第一操作系统11及第二操作系统13进行运动状态的监控：运行在第二操作系统13及第一操作系统11上的Safety Service会以固定频率的间隔，通过进程间通信，即IPC方式发送消息告知安全监控操作系统12运行的安全监控服务Safety Monitor。消息类型可自行定义，可以定义两中消息：“alive”和“fatal”。
Safety Monitor接收到“alive”，认定发送消息的操作系统运行正常，不做处理，继续监听消息；Safety Monitor接收到“fatal”，认定发送消息的操作系统运行遇到致命错误，需要重新启动运行该操作系统，以恢复正常运行；Safety Monitor在规定的时间内，没有收到操作系统发送的消息，认定未发送消息的操作系统运行遇到致命错误，需要重新启动该操作系统，以恢复正常运行。
进一步地，Safety Monitor还可以通过看门狗Watchdog来监控自身的运行状态，如以固定频率的间隔，向Watchdog的Register发送喂狗信号，如果Safety Monitor运行异常，没有及时喂狗，安全监控操作系统12会重启，以恢复正常运行。
本申请进一步提出一种基于多操作系统的车载系统的控制方法，如图8所 示，图8是本申请基于多操作系统的车载系统的控制方法一实施例的流程示意图。本实施例的控制方法可以用于上述基于多操作系统的车载系统，本实施例的控制方法具体包括以下步骤：
步骤S81：为第二操作系统及安全监控操作系统配置内核。
车载系统还包括至少一个应用操作系统及安全监控操作系统，应用操作系统包括第二操作系统，SOC为第二操作系统及安全监控操作系统配置内核。SOC为第二操作系统配置内核，且第二操作系统与安全监控操作系统位于处理器的不同内核，第二操作系统用于运行快启应用；其中，第二操作系统仅设置快启应用依赖的资源项，以简化Linux操作系统，缩短快启应用的启动时间。
快启应用，即需快速启动的应用，如AVM应用、智能座舱中倒车应用、车载仪表应用、车载DMS应用等。
进一步地，应用操作系统还可以包括第一操作系统。SOC分别为第一操作系统、第二操作系统及安全监控操作系统配置内核。
SOC运行时分别为第一操作系统、安全监控操作系统及第二操作系统分配至少一个物理内核；或者SOC运行时，通过内核虚拟化系统采用Hypervisor技术将SOC的物理内核虚拟化为多个虚拟内核，SOC分别为第一操作系统、安全监控操作系统及第二操作系统分配至少一个虚拟内核；又或者通过内核虚拟化系统采用Hypervisor技术将SOC的部分物理内核虚拟化为多个虚拟内核，SOC分别为第一操作系统及第二操作系统分配至少一个虚拟内核，并为安全监控操作系统分配至少一个未虚拟化的物理内核。
在其它实施例中，SOC还可以为第一操作系统和/或第二操作系统分配物理内核，为安全监控操作系统分配虚拟内核。
其中，本实施例的第二操作系统可以是Linux操作系统，第一操作系统可以是安卓操作系统；在其它实施例中，第一操作系统还可以是其它非安全的多应用系统等。
步骤S82：获取到上电启动指令，将安全监控操作系统的镜像文件加载到控制系统的运行内存中，并启动安全监控操作系统对应的内核运行，以完成安全监控操作系统及其安全监控服务的启动。
步骤S83：将第二操作系统的Kernel加载到运行内存中，并启动第二操作系统对应的内核运行，依次完成第二操作系统的驱动加载、快启应用依赖的服务的启动、快启应用的启动。
进一步的，本实施例的控制方法还包括步骤S84。
步骤S84：将第一操作系统的Kernel加载到运行内存中，并启动第一操作系统对应的内核运行，依次完成第一操作系统的驱动加载、服务启动、应用启动。
本实施例的车载系统利用安全监控操作系统实现对应用操作系统的安全监控，且采用同一处理器的不同内核分别实现安全监控操作系统及应用操作系统，以实现二者之间的隔离，能够避免应用操作系统中应用运行异常而导致安全监控应用无法正常运行的问题，因此能够提高安全监控的有效性，提高车载系统的安全性能。
本实施例将快启应用独立出来，单独运行在一Linux操作系统中，可以达到快启应用快速启动，且运行安全的效果。
在其它实施例中，不限定步骤S82至步骤S84的执行顺序。
在一应用场景中，在SOC为安卓操作系统、安全监控操作系统及Linux操作系统分配物理内核后，车载系统上电启动，运行引导加载程序，即bootloader，初始化硬件设备，SOC分别为安卓操作系统、安全监控操作系统及Linux操作系统分配不同的物理内核；bootloader加载安全监控操作系统的镜像文件到运行内存中，启动安全监控操作系统对应的内核运行，完成安全监控操作系统及其安全监控服务的启动。
bootloader加载Min Kernel到运行内存中，启动Linux操作系统对应的内核运行。Linux kernel完成驱动加载后，启动AVM依赖的CarmeraSource、surfaceflinger及Opengles服务，最后启动AVM应用。
bootloader加载Android Kernel到运行内存中，启动安卓操作系统对应的内核运行。Android Kernel完成驱动加载后，启动Android所有Service，在Android Service启动完成后，最后启动Android应用。
在另一应用场景中，在SOC为安卓操作系统、安全监控操作系统及Linux操作系统分配虚拟内核后，系统上电启动，运行bootloader，初始化硬件设备，bootloader加载Hypervisor的镜像文件到运行内存中，启动Hypervisor启动成功后，虚拟化多个虚拟内核；Hypervisor加载安全监控操作系统的镜像文件到运行内存中，启动安全监控操作系统对应的内核运行，完成安全监控操作系统及其安全监控服务的启动。
Hypervisor加载Min Kernel到运行内存中，启动Linux操作系统对应的内 核运行。Linux kernel完成驱动加载后，启动AVM依赖的CarmeraSource、surfaceflinger及Opengles服务，最后启动AVM应用。
Hypervisor加载Android Kernel到运行内存中，启动安卓操作系统对应的内核运行。Android Kernel完成驱动加载后，启动Android所有Service，在Android Service启动完成后，最后启动Android应用。
进一步地，为快速启动快启应用，SOC为第二操作系统分配预设数量的内核，并在第二操作系统启动完成后，释放部分内核给第一操作系统。其中，该预设数量大于第二操作系统运行快启应用所需的内核的数量。本实施例在AVM应用启动阶段为第二操作系统配置较多的物理内核，能够保证AVM应用快速启动，且在AVM应用启动完成后，再将部分物理分配给第二操作系统的部分物理内核释放给车载系统的其它应用操作系统，如第一操作系统，以保证其它应用操作系统的运行速率及资源的合理利用。
可选地，本申请的控制方法还可以实现不同内核之间的通信。处理器(的SOC)设有第一内核及第二内核，分别对应应用操作系统及安全监控系统，本实施例的控制方法基于中断和共享内存实现不同内核之间通信。其中，该通信方法具体包括如图9所示的步骤S91至步骤S93。
步骤S91：应用操作系统向共享内存写入消息。
第一内核向共享内存写入消息。
步骤S92：应用操作系统写中断，以触发安全监控系统接收所述中断。
第一内核写中断，以触发第二内核接收所述中断。
步骤S93：安全监控操作系统接收到中断后，进入中断处理程序，并从共享内存中读取消息。
第二内核接收到中断后，进入中断处理程序，并从共享内存中读取消息。
假定SOC中有n个内核，以Core[0]向Core[n-1]发送消息为例：
Core[0]向预定的共享内存data_A[]写入消息；Core[0]写中断，控制器触发Core[n-1]收到中断；Core[n-1]收到中断，进入中断处理程序中，并从共享内存data_A[]读取该消息。
需要注意的是，上述不同操作系统对应的内核之间均可以采用上述方式进行通信。
可选地，本申请的控制方法还可以实现安全监控操作系统对应用操作系统的安全监控。具体地，可以通过如图10所示的方法实现，本实施例的方法包括 步骤S101至步骤S103。
步骤S101：应用操作系统向安全监控操作系统发送消息。
运行在应用操作系统上的Safety Service会以固定频率的间隔，通过进程间通信，即IPC方式发送消息告知安全监控操作系统运行的安全监控服务Safety Monitor。消息类型可自行定义，可以定义两中消息：“alive”和“fatal”。
步骤S102：安全监控操作基于消息或者接收消息的等待时长确定应用操作系统的运行状态。
Safety Monitor接收到“alive”，认定发送消息的应用操作系统运行正常，不做处理，继续监听消息；Safety Monitor接收到“fatal”，认定发送消息的应用操作系统运行遇到致命错误，需要重新启动运行该应用操作系统，以恢复正常运行；Safety Monitor在规定的时间内，没有收到应用操作系统发送的消息，认定未发送消息的应用操作系统运行遇到致命错误，需要重新启动该应用操作系统，以恢复正常运行。
步骤S103：若运行状态为异常状态，则安全监控操作系统重启应用操作系统。
若应用操作系统运行异常，安全监控操作系统重启应用操作系统。
安全监控操作系统分别与对安卓操作系统及Linux操作系统通信连接，可以采用上述方法实现对安卓操作系统及Linux操作系统的安全监控。
进一步地，Safety Monitor还可以通过看门狗Watchdog来监控自身的运行状态，如以固定频率的间隔，向Watchdog的Register发送喂狗信号，如果Safety Monitor运行异常，没有及时喂狗，重启安全监控操作系统，以恢复正常运行。
上述各操作系统的介绍可以参阅上述实施例，这里不赘述。
区别于现有技术，本申请基于多操作系统的车载系统包括：至少一个应用操作系统及安全监控操作系统，应用操作系统及安全监控操作系统采用同一处理器的不同内核；其中，应用操作系统用于运行非安全应用；安全监控操作系统与应用操作系统通信连接，用于对应用操作系统进行安全监控。本申请车载系统利用安全监控操作系统实现对应用操作系统的安全监控，且采用同一处理器的不同内核分别实现安全监控操作系统及应用操作系统，以实现二者之间的隔离，能够避免应用操作系统中应用运行异常而导致安全监控应用无法正常运行的问题，因此能够提高安全监控的有效性，提高车载系统的安全性能。
本申请提出将AVM应用独立运行在一个系统中，将多核SOC分配为安全 监控操作系统所需的内核、第二操作系统所需的内核和第一操作系统所需的内核，第二操作系统上运行AVM应用，第一操作系统运行Android应用，安全监控操作系统上运行Safety Monitor，用来监控第二操作系统和第一操作系统的运行状态，并处理异常恢复，达到快速启动(可以在3S左右完成AVM启动显示)和运行安全的效果。
本申请将AVM应用放在第二操作系统中，因为第二操作系统只需要支持AVM应用，可以裁剪非常精简，从而达到快速启动目的；且相比复杂庞大的第一操作系统，精简的第二操作系统，运行的服务少，应用单一，所以更加稳定安全，而且第一操作系统和第二操作系统是隔离的，所以第一操作系统运行出现异常也不会影响第二操作系统。
本申请提出的系统架构及方法不仅适用于AVM快速启动和运行安全的场景，也可以适用其他模块场景，例如智能座舱中倒车快速启动、车载仪表快速启动、车载DMS系统快速启动等。
以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (11)

  1. 一种基于多操作系统的车载系统，其特征在于，包括：至少一个应用操作系统及安全监控操作系统，所述应用操作系统及所述安全监控操作系统采用同一处理器的不同内核；
    其中，所述应用操作系统用于运行非安全应用；
    所述安全监控操作系统与所述应用操作系统通信连接，用于运行安全监控服务，以对所述应用操作系统进行安全监控。
  2. 根据权利要求1所述的车载系统，其特征在于，所述应用操作系统包括第二操作系统，与所述安全监控操作系统采用所述处理器的不同内核，其中，所述第二操作系统用于运行快启应用；其中，所述第二操作系统仅配置加载所述快启应用依赖的资源项；
    所述安全监控操作系统与所述第二操作系统通信连接，用于对所述第二操作系统进行安全监控。
  3. 根据权利要求2所述的车载系统，其特征在于，所述应用操作系统还包括第一操作系统，与所述安全监控操作系统通信连接，所述安全监控操作系统还用于对所述第一操作系统进行安全监控。
  4. 根据权利要求3所述的车载系统，其特征在于，所述车载系统进一步包括片上系统，所述片上系统设有多个物理内核，并分别为所述第一操作系统、所述安全监控操作系统及所述第二操作系统分配至少一个所述物理内核。
  5. 根据权利要求3所述的车载系统，其特征在于，所述车载系统进一步包括片上系统及与内核虚拟化系统，所述片上系统设有物理内核，所述内核虚拟化系统将至少部分所述物理内核虚拟化为多个虚拟内核，所述片上系统分别为所述第一操作系统、所述安全监控操作系统及所述第二操作系统分配至少一个所述虚拟内核和/或至少一个所述物理内核。
  6. 一种基于多操作系统的车载系统的控制方法，其特征在于，所述车载系统包括至少一个应用操作系统及安全监控操作系统，所述应用操作系统包括第二操作系统，与所述安全监控操作系统采用同一处理器的不同内核，所述第二操作系统用于运行快启应用，所述控制方法包括：
    为所述第二操作系统及所述安全监控操作系统配置内核；
    获取到上电启动指令，将所述安全监控操作系统的镜像文件加载到所述车 载系统的运行内存中，并启动所述安全监控操作系统对应的内核运行，以完成所述安全监控操作系统及其安全监控服务的启动；
    将所述第二操作系统的Kernel加载到所述运行内存中，并启动所述第二操作系统对应的内核运行，依次完成所述第二操作系统的驱动加载、所述快启应用依赖的服务的启动、所述快启应用的启动。
  7. 根据权利要求6所述的控制方法，其特征在于，所述应用操作系统还包括第一操作系统，与所述安全监控操作系统及所述第二操作系统采用所述处理器的不同内核，所述控制方法进一步包括：
    为所述第一操作系统配置内核；
    将所述第一操作系统的Kernel加载到所述运行内存中，并启动所述第一操作系统对应的内核运行，依次完成所述第一操作系统的驱动加载、服务启动、应用启动。
  8. 根据权利要求7所述的控制方法，其特征在于，为所述第一操作系统、所述第二操作系统及所述安全监控操作系统配置内核，包括：
    分别为所述安全监控操作系统及所述第二操作系统、所述第一操作系统分配至少一个物理内核；或者
    将至少部分物理内核虚拟化为多个虚拟内核；
    分别为所述安全监控操作系统及所述第二操作系统、所述第一操作系统分配至少一个所述虚拟内核和/或至少一个所述物理内核。
  9. 根据权利要求7所述的控制方法，其特征在于，为所述第二操作系统配置内核，包括：
    为所述第二操作系统分配预设数量的内核；
    所述控制方法进一步包括：在所述第二操作系统启动完成后，释放部分所述内核给所述第一操作系统。
  10. 根据权利要求6所述的控制方法，其特征在于，所述控制方法进一步包括：
    所述应用操作系统向共享内存写入消息；
    所述应用操作系统写中断，以触发所述安全监控操作系统接收所述中断；
    所述安全监控操作系统接收到所述中断后，进入中断处理程序，并从所述共享内存中读取所述消息。
  11. 根据权利要求6所述的控制方法，其特征在于，进一步包括：
    所述应用操作系统向所述安全监控操作系统发送消息；
    所述安全监控操作基于所述消息或者接收所述消息的等待时长确定所述应用操作系统的运行状态；
    若运行状态为异常状态，则所述安全监控操作系统重启所述应用操作系统。
PCT/CN2023/114652 2022-07-11 2023-08-24 基于多操作系统的车载系统及其控制方法 WO2024012603A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210813220.0A CN115168869A (zh) 2022-07-11 2022-07-11 基于多操作系统的车载系统及其控制方法
CN202210813220.0 2022-07-11

Publications (1)

Publication Number Publication Date
WO2024012603A1 true WO2024012603A1 (zh) 2024-01-18

Family

ID=83493359

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/114652 WO2024012603A1 (zh) 2022-07-11 2023-08-24 基于多操作系统的车载系统及其控制方法

Country Status (2)

Country Link
CN (1) CN115168869A (zh)
WO (1) WO2024012603A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117931529A (zh) * 2024-03-21 2024-04-26 上海励驰半导体有限公司 启动管理方法和设备、电子设备及存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115168869A (zh) * 2022-07-11 2022-10-11 合肥杰发科技有限公司 基于多操作系统的车载系统及其控制方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107402844A (zh) * 2017-07-14 2017-11-28 深圳市沃特沃德股份有限公司 操作系统重启方法、装置和辅助系统
WO2018036318A1 (zh) * 2016-08-26 2018-03-01 中兴通讯股份有限公司 一种在操作系统启动阶段收集异常信息的方法及装置
CN107783821A (zh) * 2017-01-25 2018-03-09 问众智能信息科技（北京）有限公司 车载一体虚拟化方法和装置
CN111745650A (zh) * 2020-06-15 2020-10-09 哈工大机器人（合肥）国际创新研究院 一种机器人操作系统的运行方法和机器人的控制方法
CN112947235A (zh) * 2021-03-11 2021-06-11 深圳市阿丹能量信息技术有限公司 一种基于X9平台和Xen技术的座舱域控制器系统及应用方法
CN115168869A (zh) * 2022-07-11 2022-10-11 合肥杰发科技有限公司 基于多操作系统的车载系统及其控制方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018036318A1 (zh) * 2016-08-26 2018-03-01 中兴通讯股份有限公司 一种在操作系统启动阶段收集异常信息的方法及装置
CN107783821A (zh) * 2017-01-25 2018-03-09 问众智能信息科技（北京）有限公司 车载一体虚拟化方法和装置
CN107402844A (zh) * 2017-07-14 2017-11-28 深圳市沃特沃德股份有限公司 操作系统重启方法、装置和辅助系统
CN111745650A (zh) * 2020-06-15 2020-10-09 哈工大机器人（合肥）国际创新研究院 一种机器人操作系统的运行方法和机器人的控制方法
CN112947235A (zh) * 2021-03-11 2021-06-11 深圳市阿丹能量信息技术有限公司 一种基于X9平台和Xen技术的座舱域控制器系统及应用方法
CN115168869A (zh) * 2022-07-11 2022-10-11 合肥杰发科技有限公司 基于多操作系统的车载系统及其控制方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117931529A (zh) * 2024-03-21 2024-04-26 上海励驰半导体有限公司 启动管理方法和设备、电子设备及存储介质

Also Published As

Publication number Publication date
CN115168869A (zh) 2022-10-11

Similar Documents

Publication Publication Date Title
WO2024012603A1 (zh) 基于多操作系统的车载系统及其控制方法
KR102356316B1 (ko) 차량 시스템, 차량 및 이러한 차량 시스템을 동작시키기 위한 방법
US9898304B2 (en) Fast booting a computing device to a specialized experience
US10073711B2 (en) Virtual machine monitor configured to support latency sensitive virtual machines
US11126420B2 (en) Component firmware update from baseboard management controller
RU2532708C2 (ru) Способ и устройство для осуществления операции ввода/вывода в среде виртуализации
EP2479666B1 (en) Methods and systems to display platform graphics during operating system initialization
US10133504B2 (en) Dynamic partitioning of processing hardware
US9639486B2 (en) Method of controlling virtualization software on a multicore processor
CN109522099B (zh) 提高非实时性操作系统实时性的方法及其系统
US11099884B2 (en) Dynamic control of halt polling based on receiving a monitoring instruction executed by a guest
WO2019212696A1 (en) Multithread framework for use in pre-boot environment of a system-on-chip
CN112352221A (zh) 用以支持虚拟化环境中的ssd设备驱动器与物理ssd之间的sq/cq对通信的快速传输的共享存储器机制
WO2019079128A1 (en) REMAPPING VIRTUAL DEVICES FOR VIRTUAL MACHINES
US11900097B2 (en) Application downtime reduction using detached mode operation during operating system updates
US11609797B1 (en) Single-click ejection of peripheral devices associated with virtual machines
CN113407247A (zh) 基于多核处理器的双系统启动方法
US10810032B2 (en) System and method for dynamic guest-controlled halt polling using a CPU governor
CN115285044A (zh) 资源共享方法、车载系统和车载控制器
US11157289B2 (en) Power management method and apparatus for virtualized I/O devices
US20230024607A1 (en) System-on-chip for sharing graphics processing unit that supports multimaster, and method for operating graphics processing unit
CN116880962A (zh) 确定虚拟机管理器延迟信息的方法、装置、设备及车辆
CN117519809A (zh) 基于X86架构的Linux和ReWorks的非对称整合系统及方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23839088

Country of ref document: EP

Kind code of ref document: A1