System calling method and apparatus

Abstract

A system calling method and apparatus. In the method, a first application (APP) is run in a first OS, and the first APP may initiate a first system calling request, wherein the first system calling request comprises a service identifier of a first service; the first OS sends a service request to a second OS on the basis of the service identifier; the second OS receives the service request, and allocates to the service request an available first thread among a plurality of threads; and the first thread processes the service request. By means of the method, in the scenario of multi-system coexistence on a computing node, a first OS can efficiently reuse the ecosystem of a second OS, thereby guaranteeing the system performance of the entire computing node to the greatest extent.

Description

System call method and device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on March 25, 2024, with application number 202410349538.7 and invention name "A system call method and device", the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of computer technology, and in particular to a system call method and device. Background Art

[0004] The evolution of automotive electrical and electronic (E / E) architectures has placed higher demands on vehicle computing platforms. The industry is gradually exploring the construction of dual guest operating systems (guest OSs) based on virtualization on vehicle computing platforms. For example, virtualization technology can be used to simultaneously run a general-purpose OS and a functional safety OS on the vehicle computing platform.

[0005] Among them, the functional safety OS of the computing platform in some designs is based on embedded OS solutions such as QNX, while the functional safety OS of the computing platform in other designs is developed based on the Linux kernel solution. However, due to the limitations of the microkernel architecture adopted by QNX and QNX's own ecological support capabilities, computing platforms based on embedded OS solutions such as QNX are unable to meet the development requirements of autonomous driving-related applications in functional safety OS for a rich ecosystem and rapid iteration. In computing platforms developed based on the Linux kernel solution, the functional safety OS relies on proxy mechanisms and proxy threads, and is strongly dependent on the Linux kernel in the general OS. Once the Linux kernel fails, the entire functional safety OS will be unable to run, making it difficult to meet the high functional safety requirements of the vehicle.

[0006] Therefore, how to build a dual Guest OS system on the vehicle's computing platform to take into account the ecological support capabilities and high-functional safety requirements of the computing platform as much as possible remains an important issue that needs to be solved urgently. Summary of the Invention

[0007] The present application provides a system call method and apparatus for enabling a first OS to efficiently reuse the ecology of a second OS in a scenario where multiple systems coexist on a computing node, thereby ensuring the system performance of the entire computing node as much as possible.

[0008] In a first aspect, the present application provides a system call method, which can be applied to a computing node of a vehicle, wherein the computing node includes a first operating system OS and a second OS, and a first application APP runs on the first OS. The method may include: the first APP initiates a first system call request, and the first system call request includes a service identifier of a first service; the first OS sends a service request to the second OS according to the service identifier; the second OS receives the service request and allocates an available first thread to the service request from multiple threads; the first thread processes the service request.

[0009] Through the above method, in a scenario where multiple OS systems coexist, by including only a small amount of management information (such as a service identifier) ​​in the cross-OS system service request from the first OS, but not the context information used to describe the execution state of the thread, the service request is released from the strong binding relationship with the thread state, so that the second OS side can allocate an available first thread to the service request in real time, thereby reducing the system noise floor (further reducing the resource usage of the second OS) and improving the performance of the entire system.

[0010] In combination with the first aspect, in a possible implementation, the first system call request also includes the system call parameters associated with the first service, and the first OS sends a service request to the second OS based on the service identifier, which may include: the first OS applies for a first memory space from a shared memory, and stores the system call parameters associated with the first service in the first memory space; the first OS sends the service request to the second OS through the shared memory, where the service request includes the service identifier and a first address, and the first address is the storage address of the system call parameters associated with the first service in the first memory space.

[0011] With the above method, a secure shared channel between the first OS and the second OS can be implemented through shared memory to pass information such as system call parameters without status to the second OS, so that the first thread of the second OS can process the service request when running.

[0012] In combination with the first aspect, in a possible implementation, the first thread processes the service request, including: when the first thread runs on the second OS, reading the system call parameters associated with the first service from the first memory space according to the first address, and processing the service request according to the system call parameters.

[0013] In combination with the first aspect, in a possible implementation, the method may further include: the first OS obtains status information of the second OS, the status information including a fault state or a non-fault state; the first OS sends a service request to the second OS according to the service identifier, including: if the second OS is in a non-fault state, the first OS sends a service request to the second OS according to the service identifier.

[0014] Through the above method, the first OS can detect whether the second OS is faulty. If not, the first OS can send a cross-OS system service request to the second OS to process the service request using system resources on the second OS side.

[0015] In combination with the first aspect, in a possible implementation, the first OS includes a first processing node, and the first processing node is at least used to send the service request to the second OS in response to the first system call request. The method may also include: the first processing node determines whether the second OS is in a fault state; wherein, if the first processing node determines that the second OS is in a fault state before the first APP initiates the first system call request, the method also includes: the first processing node stores the context information associated with the first system call request in the shared memory of the first OS and the second OS and then sleeps.

[0016] Through the above method, based on the fault self-healing mechanism, a checkpoint can be set on the first processing node to enable the first processing node to check the status of the second OS and control the subsequent execution process according to the check result. For example, when the second OS is in a faulty state, the first processing node saves the relevant context and then goes into sleep mode to prevent the service request sent by the first processing node during the second OS fault from being unable to be answered, thereby affecting the continuous operation of tasks or functions on the first OS side.

[0017] In combination with the first aspect, in a possible implementation, if the second OS recovers from a faulty state to a non-faulty state when the first processing node is in sleep mode, the method further includes: the first OS reads the context information associated with the first system call request from the shared memory and wakes up the first processing node; the first APP re-initiates the first system call request based on the context information associated with the first system call request; and the first processing node re-sends a service request to the second OS in response to the first system call request.

[0018] Through the above method, based on the fault self-healing mechanism, the first OS can also autonomously restore the context of the relevant task after the fault is recovered on the second OS side, so as to re-execute the task and realize cross-OS system calls to resources or services provided by the second OS.

[0019] In combination with the first aspect, in a possible implementation, the first OS includes a second thread associated with the first APP, the first processing node is used to manage the second thread, and the second thread is used to send the service request to the second OS. The method also includes: the second thread determines whether the second OS is in a fault state; wherein, if the second thread determines that the second OS is in a fault state during the process of sending the service request to the second OS, the method also includes: the second thread stores the context information associated with the service request in the shared memory and then sleeps.

[0020] Through the above method, based on the fault self-healing mechanism, a checkpoint can also be set in the second thread used to execute the task, so that the second thread can check the status of the second OS and control the subsequent execution process according to the check result. For example, when the second OS is in a faulty state, the relevant context is saved and then hibernated to prevent the service request sent by the second thread during the second OS failure from being unable to be answered, thereby affecting the continuous operation of the task or function on the first OS side.

[0021] In combination with the first aspect, in a possible implementation, if the second OS recovers from a faulty state to a non-faulty state when the second thread is dormant, the method further includes: the first processing node reads the context information associated with the service request from the shared memory and wakes up the second thread; the second thread re-sends the service request to the second OS based on the context information associated with the service request.

[0022] Through the above method, based on the fault self-healing mechanism, the first OS can also autonomously restore the context of the relevant task after the fault is recovered on the second OS side, so as to re-execute the task and realize cross-OS system calls to resources or services provided by the second OS.

[0023] In combination with the first aspect, in one possible implementation, a second APP is also running on the first OS, and the first OS obtains status information of the second OS, including: the second APP periodically initiating a second system call request; the first OS sends a service request to the second OS in response to the second system call request, and obtains the status information of the second OS based on the response information of the second OS to the service request.

[0024] Through the above method, the process of the second APP can also be started as a resident process in the first OS to periodically detect the status of the second OS, thereby improving the robustness and robustness of the entire system.

[0025] In combination with the first aspect, in a possible implementation, the method may further include: the second OS obtains the demand information of the first APP for the thread that implements the first service, and releases at least one thread among the multiple threads based on the demand information, or creates at least one new thread for the multiple threads based on the demand information.

[0026] Through the above method, multiple service threads are managed in a thread pool manner on the second OS side. This method supports dynamic expansion or contraction of the multiple threads to reduce the resource occupation on the second OS side while meeting the cross-OS system call requirements of the first OS side.

[0027] In combination with the first aspect, in one possible implementation, the computing node provides different virtual operating environments through virtual machines, and the first OS and the second OS run in different virtual operating environments of the computing node. In another embodiment, the computing node can also adopt a multi-domain chip, and the first OS and the second OS can correspond to different domains respectively. For example, the first OS is called a functional safety domain, which focuses more on the purpose of functional safety. The second OS is called a general domain, which pays more attention to general capabilities. In another embodiment, the computing node can also adopt a dual-chip architecture, and the first OS and the second OS can be deployed on the processors of the two chips respectively, and the information interaction between the first OS and the second OS is realized through network communication, so that the entire communication system can meet the optimal state of functional safety, performance, and ecology as much as possible.

[0028] In combination with the first aspect, in a possible implementation method, the first APP also provides a second service by calling the first OS when running, wherein the first APP includes at least one APP related to autonomous driving, and the at least one APP is used to provide at least one of the following services: perception service, fusion processing service or regulation and control service; the second service includes at least one of the scheduling service, process management service or memory management service involved in the autonomous driving related APP, and the first service includes at least one of the file management, interruption management or communication management involved in the autonomous driving related APP.

[0029] In the second aspect, the present application provides a cross-system call method, which is applied to a first operating system OS, the first OS is deployed on a first processor, the first processor is set on a first chip, and a first APP is running on the first OS. The method may include: the first APP initiates a cross-system call request, the cross-system call request includes a service identifier of a first service, the first service is provided by a second OS, the second OS is deployed on a second processor, and the second processor is set on a second chip; the first OS sends a cross-system service request to the second OS according to the service identifier, the cross-system service request is used to request the second OS to allocate an available first thread, and the first thread is used to process the cross-system service request.

[0030] In combination with the second aspect, in a possible implementation, the first chip and the second chip communicate based on a network, and the first OS sends a cross-system service request to the second OS according to the service identifier, including: the first OS sends a cross-system service request to the second OS through the network, and the cross-system service request includes the service identifier and cross-system call parameters associated with the first service.

[0031] In combination with the second aspect, in a possible implementation, the method also includes: the first OS obtains status information of the second OS, and the status information includes a fault state or a non-fault state; the first OS sends a cross-system service request to the second OS according to the service identifier, including: if the second OS is in a non-fault state, the first OS sends a service request to the second OS according to the service identifier.

[0032] In combination with the second aspect, in a possible implementation, the first OS includes a first processing node, and the first processing node is at least used to send the cross-system service request to the second OS in response to the cross-system call request. The method also includes: the first processing node determines whether the second OS is in a fault state; wherein, if the first processing node determines that the second OS is in a fault state before the first APP initiates the cross-system call request, the method also includes: the first processing node stores the context information associated with the first system call request in a storage medium accessible to the first OS and then sleeps.

[0033] In combination with the second aspect, in a possible implementation, if the second OS recovers from a faulty state to a non-faulty state when the first processing node is in sleep mode, the method further includes: the first OS reads the context information associated with the cross-system call request from the storage medium and wakes up the first processing node; the first APP re-initiates the cross-system call request based on the context information associated with the cross-system call request; and the first processing node re-sends a cross-system service request to the second OS in response to the cross-system call request.

[0034] In combination with the second aspect, in a possible implementation, the first OS includes a second thread associated with the first APP, the first processing node is used to manage the second thread, and the second thread is used to send the cross-system service request to the second OS. The method also includes: the second thread determines whether the second OS is in a fault state; wherein, if the second thread determines that the second OS is in a fault state during the process of sending the cross-system service request to the second OS, the method also includes: the second thread stores the context information associated with the service request in the storage medium and then sleeps.

[0035] In combination with the second aspect, in a possible implementation, if the second OS recovers from a faulty state to a non-faulty state when the second thread is dormant, the method further includes: the first processing node reads the context information associated with the cross-system service request from the storage medium and wakes up the second thread; the second thread re-sends the cross-system service request to the second OS based on the context information associated with the cross-system service request.

[0036] In combination with the second aspect, in a possible implementation, a second APP is also running on the first OS, and the first OS obtains the status information of the second OS, including: the second APP periodically initiates a cross-system call request; the first OS sends a cross-system service request to the second OS in response to the cross-system call request, and obtains the status information of the second OS based on the response information of the second OS to the cross-system service request.

[0037] In combination with the second aspect, in one possible implementation method, the first APP also provides a second service by calling the first OS during operation, wherein the first APP includes at least one APP related to autonomous driving, and the at least one APP is used to provide at least one of the following services: perception service, fusion processing service or regulation and control service; the second service includes at least one of the scheduling service, process management service or memory management service involved in the autonomous driving related APP, and the first service includes at least one of the file management, interruption management or communication management involved in the autonomous driving related APP.

[0038] In the third aspect, the present application provides a cross-system call request, which is applied to a second operating system OS, the second operating system is deployed on a second processor, and the second processor is set on a second chip. The method may include: the second OS receives a cross-system service request from a first OS, the first OS is deployed on a first processor, the first processor is set on a first chip, and a first APP is running on the first OS, and the service request is sent by the first OS in response to a cross-system call request initiated by the first APP; the second OS allocates an available first thread to the cross-system service request from multiple threads, and the first thread is used to process the cross-system service request.

[0039] In combination with the third aspect, in a possible implementation method, the first chip and the second chip communicate based on a network, and the second OS receives a cross-system service request from the first OS, including: the second OS receives a cross-system service request from the first OS through the network, and the cross-system service request includes the service identifier and the cross-system call parameters associated with the first service.

[0040] In combination with the third aspect, in a possible implementation, the method also includes: the second OS obtains the demand information of the first APP for the thread that implements the first service, and releases at least one thread among the multiple threads based on the demand information, or creates at least one new thread for the multiple threads based on the demand information.

[0041] In a fourth aspect, the present application provides a communication device, comprising: a communication interface for communicating with other devices; a processor coupled to the communication interface, so that the communication device executes the method described in the first aspect and any implementation of the first aspect, or executes the method described in the second aspect and any possible implementation of the second aspect, or executes the method described in the third aspect and any possible implementation of the third aspect.

[0042] In a fifth aspect, the present application provides a chip system comprising at least one processor and an interface circuit, wherein the processor is used to execute instructions and / or data interaction through the interface circuit, so that the chip system executes the method described in the first aspect and any implementation of the first aspect, or executes the method described in the second aspect and any possible implementation of the second aspect, or executes the method described in the third aspect and any possible implementation of the third aspect.

[0043] In a sixth aspect, the present application provides a vehicle comprising a computing node, wherein the computing node is used to implement the method described in the first aspect and any implementation of the first aspect, or to implement the method described in the second aspect and any possible implementation of the second aspect, or to implement the method described in the third aspect and any possible implementation of the third aspect.

[0044] In the seventh aspect, the present application provides a computer-readable storage medium, including a program or instruction. When the program or instruction is executed, the method described in the first aspect and any implementation of the first aspect is executed, or the method described in the second aspect and any possible implementation of the second aspect is executed, or the method described in the third aspect and any possible implementation of the third aspect is executed.

[0045] In an eighth aspect, the present application provides a computer program product. When a computer reads and executes the computer program product, the computer executes the method described in the first aspect and any implementation of the first aspect, or executes the method described in the second aspect and any possible implementation of the second aspect, or executes the method described in the third aspect and any possible implementation of the third aspect.

[0046] In a ninth aspect, an embodiment of the present application provides a terminal device, comprising a unit for implementing the method described in the first aspect and any possible design of the first aspect, or a unit for implementing the method described in the second aspect and any possible design of the second aspect. By way of example, the terminal device includes, but is not limited to: intelligent transportation equipment (such as cars, ships, drones, trains, trucks, etc.), intelligent manufacturing equipment (such as robots, industrial equipment, intelligent logistics, smart factories, etc.), and intelligent terminals (mobile phones, computers, tablet computers, PDAs, desktops, headphones, speakers, wearable devices, vehicle-mounted devices, etc.).

[0047] Based on the implementations provided in the above aspects, the embodiments of the present application can be further combined to provide more implementations.

[0048] The technical effects that can be achieved by any possible implementation method in any of the second to ninth aspects mentioned above can be referred to the description of the technical effects that can be achieved by any possible implementation method in any of the first to second aspects mentioned above, and the repetitions will not be discussed. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] FIG1 shows a schematic diagram showing the principle of using virtual machines to achieve multi-system coexistence;

[0050] FIG2 shows a schematic diagram of the design architecture of an operating system based on a macro kernel;

[0051] FIG3 shows a schematic diagram of a design architecture of a microkernel-based operating system;

[0052] FIG4 shows a schematic diagram of the architecture of a computing platform based on an embedded OS solution such as QNX;

[0053] FIG5 shows a schematic diagram of the architecture of a computing platform developed based on the Linux kernel solution;

[0054] FIG6 shows a schematic diagram of the principle of the proxy mechanism in a computing platform developed based on the Linux kernel solution;

[0055] FIG7 shows a schematic diagram of the system architecture of an embodiment of the present application;

[0056] FIG8 is a schematic diagram showing a flow chart of a system calling method according to an embodiment of the present application;

[0057] FIG9 is a schematic diagram showing a flow chart of a system call method incorporating a fault self-healing mechanism according to an embodiment of the present application;

[0058] 10-11 are schematic flow charts showing different fault detection methods according to embodiments of the present application;

[0059] FIG12 is a schematic diagram showing a process flow of self-recovery after a fault according to an embodiment of the present application;

[0060] FIG13 shows a schematic diagram of a communication device according to an embodiment of the present application;

[0061] FIG14 shows a schematic diagram of a communication device according to an embodiment of the present application;

[0062] FIG15 shows a schematic diagram of a communication device according to an embodiment of the present application. DETAILED DESCRIPTION

[0063] In order to facilitate understanding of the technical solutions of the embodiments of the present application, some of the terms involved are explained below.

[0064] 1. Use virtual machines to achieve multi-system coexistence:

[0065] Virtual machine technology is a method of simulating hardware through software, dividing a computer into multiple independent virtual computing environments. These virtual computing environments can run different operating systems (OS) just like running on real computers.

[0066] A hypervisor, also known as a virtual machine monitor (VMM), is software, firmware, or hardware used to create and execute virtual machines.

[0067] The computer used by the hypervisor to execute one or more virtual machines is called the host machine, while these virtual machines are called guest machines. The hypervisor provides a virtual operating platform to execute guest operating systems (guest OSs) and manages the execution phase of other guest OSes. These guest OSes share virtualized hardware resources. As shown in Figure 1, virtual machine 1 and virtual machine 2 can be executed separately based on the virtualization hypervisor. Virtual machine 1 may include the kernel of operating system 1, which can run application 1. Virtual machine 2 may include the kernel of operating system 2, which can run application 2.

[0068] 2. Exception level (EL):

[0069] In advanced RISC machine (ARM) processors, exceptions are divided into four levels: EL0, EL1, EL2, and EL3. EL0 is the user level, or non-privileged mode, used to run applications (APPs), with limited access to other resources (insufficient permissions). EL1 is the kernel level, or privileged mode, used to run the operating system kernel and access all system resources. EL2 and EL3 are virtualization extension levels. EL2 is used to run the hypervisor, while EL3 is used to run the hypervisor in the secure world, the secure monitor.

[0070] 3. User state and kernel state:

[0071] In the operating system, the processor usually only allows EL0 and EL1 modes, which are often called user mode (corresponding to EL0) and kernel mode (corresponding to EL1).

[0072] Kernel state and user state are two different operating modes in an operating system. The main difference between the two lies in permissions and executable operations.

[0073] (1) Kernel state:

[0074] Kernel state is the core area where the operating system runs, which controls the computer's hardware resources and provides a running environment for upper-level applications.

[0075] In kernel mode, the central processing unit (CPU) can execute all instruction sets and access all hardware resources. This mode has the highest level of operational privileges and is primarily used for running and managing the operating system kernel.

[0076] In user mode, the CPU can only execute a privileged portion of the instruction set and cannot directly access hardware resources. In this mode, operating permissions are relatively low and it is mainly used to run the user's own programs.

[0077] (2) User mode:

[0078] User state is the embodiment of the application activity space. Applications request and use the services provided by the operating system through system calls and other means.

[0079] In user mode, a process is not allowed to execute privileged instructions, such as stopping the processor, changing mode bits, or initiating IO operations. The data and instructions of user mode programs are all executed in their own virtual address space.

[0080] 4. Mode switching:

[0081] Switching between user mode and kernel mode is called mode switching.

[0082] Switching between user mode and kernel mode can occur in a variety of ways, including but not limited to:

[0083] (1) System calls: Requests initiated by user-mode processes to request the use of service programs provided by the operating system to complete work.

[0084] (2) Exception: When an unexpected exception event occurs while the CPU is executing a program in user mode, the process will be switched to the kernel-related program that handles the exception.

[0085] (3) Peripheral device interrupt: When an external device completes an operation and issues an interrupt signal, it will also cause the process to switch from user mode to kernel mode in response to the interrupt.

[0086] 5. Process and thread:

[0087] In computers, a process is a running instance of a program. When a program starts, the operating system creates a process for it. A process is the basic unit of resource allocation in a computer, containing information such as the code, data, and stack required for program execution. A process can have multiple threads, each of which can execute code independently but share the process's memory and other resources. Each process has a unique process identifier (ID). Processes can communicate with other processes, for example, by exchanging data through associations, shared memory, and sockets.

[0088] A thread is the smallest unit of computational scheduling in an operating system and represents an execution flow within a process. A process can contain multiple threads, each of which is an execution unit within the process and can independently perform specific tasks. Within a program, multiple threads can simultaneously execute different tasks, thus achieving concurrent execution. Compared to processes, threads are more lightweight. Because they can share the process's memory and other resources, communication and data sharing between threads are easier and more efficient. Threads can be implemented in a variety of ways, such as user-level threads, kernel-level threads, and lightweight processes. Developers can choose the appropriate threading model based on their needs and goals.

[0089] 6. User space and kernel space:

[0090] Each process usually has two stacks, one in user space and the other in kernel space. When in user space, the contents of the stack pointer register used by the CPU point to the user stack address. When in kernel space, it points to the kernel stack space address.

[0091] When a process is in user mode, it cannot access kernel space or directly call kernel functions. When a call is required, the process switches to kernel mode. User mode can access kernel resources through system calls, library functions, and shell scripts. This design ensures security and stability, preventing user programs from arbitrarily accessing operating system resources or executing dangerous instructions.

[0092] 7. Context:

[0093] In computing, context generally refers to the environment in which a program or process executes, including all relevant variables and data. For a process, context includes register variables, open files, and memory information; for a thread, context includes registers and the thread stack; and for the CPU, context includes operand registers, stack registers, and status registers. Context contains all the information necessary for program execution and is crucial for its correct execution. If context is corrupted or lost during program execution, it can cause a program crash or exception.

[0094] In computer programming, context encompasses the environment and state information surrounding program execution, helping programs manage state, control flow, and execution. For example, a context switch occurs when an operating system manages processes and threads in a multitasking environment. This involves saving the state (i.e., context) of the current task for later restoration and transferring control to the next task. This process involves saving the register contents and program counter of the current task in a process control block, restoring the context of the next task, and resuming execution from the location pointed to by the program counter of the next task.

[0095] 8. User level thread and kernel level thread:

[0096] Processes and threads are managed and scheduled by the operating system, and their states can change at any time. A main thread typically appears with the creation of a process. The CPU divides these into two types based on their permissions: user-mode threads and kernel-mode threads.

[0097] Kernel-state threads, also known as kernel-level threads, have higher privileges and do not require system calls for certain operations. Kernel-state threads run in the kernel and are controlled by the kernel.

[0098] User-mode threads, also known as user-level threads, are created in user space and remain unaware of their existence. Their creation and destruction do not require system calls, allowing them to be maintained independently rather than managed by the kernel. This results in relatively low management costs. However, inter-thread communication costs are higher, as system calls are required to perform the necessary I / O. User-mode programs manage these threads, but frequent switching between user mode and kernel mode is required to collaborate with the kernel for I / O. Because they are not managed by the kernel, the kernel cannot promptly address issues that arise when a user-mode thread of a process becomes blocked.

[0099] 9. Shared Memory

[0100] Shared memory is one of the simplest forms of inter-process communication. It allows multiple processes to access the same memory, and when one process changes the contents of that memory, the other processes will also notice. This is both simple and efficient, but multiple processes participating in the sharing should not read or write to it at the same time.

[0101] 10. Macro kernel and micro kernel:

[0102] (1) Monolithic kernel:

[0103] A macro kernel, also known as a monolithic kernel, is a design architecture for an operating system kernel. Its characteristic is that most or all system functions are directly implemented in the kernel. For example, in addition to the most basic process, thread management, and memory management, the file system, device driver, network system, etc. are all implemented in the kernel.

[0104] As shown in Figure 2, the Linux operating system is an open-source multi-user, multi-tasking operating system. The Linux macro kernel includes multiple basic modules, such as the process management module (or process scheduler module), the memory management module, the file system module, the device driver module, the network system module, etc. Relying on hardware such as the CPU, RAM, hard disk, CD, terminal device, network adapter, etc., and using a combination of software and hardware, the various basic modules of the Linux kernel can provide multi-tasking scheduling functions, virtual memory management functions, file directory functions, terminal access functions, and network functions for application tools running in user space.

[0105] The monolithic kernel architecture allows operating system resources to be directly implemented internally, providing efficient performance and a high degree of integration. This reduces the performance loss that can result from inter-process communication, thereby improving overall system execution speed while also providing high execution efficiency and excellent operating system resource management capabilities. The compiled binary file of the monolithic kernel code runs in a large kernel address space, allowing direct access and use of the kernel code.

[0106] One of the biggest challenges of a monolithic kernel architecture is the sheer volume of kernel code, which can make it difficult to understand and maintain. Furthermore, since all components are implemented within the kernel, a problem with a single component can impact the stability of the entire system. However, due to its high performance and high level of integration, monolithic kernels are still adopted by many operating systems.

[0107] (2) Micro kernel:

[0108] A microkernel, also known as a microcore, is a streamlined form of the kernel. The microkernel architecture separates the system service layer into optional components that can be added as needed. Only the most basic kernel functions, such as scheduling, memory management, drivers, and file systems, are implemented by user-mode daemons. Functions within the microkernel are divided into independent processes, which communicate with each other through inter-process communication (IPC). The high degree of modularity in the microkernel architecture allows for better scalability. Furthermore, since the failure of one service does not affect another, it provides a more efficient application environment.

[0109] As shown in Figure 3, the QNX Neutrino real-time operating system (RTOS) is a distributed, embedded, scalable, and Unix-like real-time operating system that complies with the Portable Operating System Interface (POSIX) specification. Above the hardware layer, QNX provides a board support package (BSP), an RTOS microkernel, a software middleware layer, and an enhanced service layer to support applications. The RTOS microkernel provides only four services: process scheduling, inter-process communication, low-level network communication, and interrupt handling. Drivers, protocol stacks, file systems, and applications all run outside the microkernel in a secure, memory-protected user space. This prevents components from interfering with each other and allows for restart in the event of a failure.

[0110] 11. Electrical and electronic (E / E) architecture:

[0111] The automotive E / E architecture is an integrated vehicle electrical and electronic solution that integrates the design of the automotive electronic and electrical system principles, central electrical box design, connector design, and electronic and electrical distribution system.

[0112] With the increasing demand for automotive functionality and the rapid advancement of technology, the entire automotive industry has begun to undergo disruptive changes. In recent years, as the automotive industry has moved towards intelligence, traditional distributed E / E architectures have gradually evolved towards centralized integrated E / E architectures, which has also placed higher demands on vehicle design. For example, the three-electric systems of new energy vehicles (such as plug-in hybrid vehicles and pure electric vehicles) increase the complexity of the vehicle's E / E architecture. Or, for example, vehicles that utilize smart cockpits and autonomous driving technologies require updates based on over-the-air (OTA) technology, as well as large amounts of data processing and signal transmission. This places higher demands on the computing power of the on-board intelligent computing platform and vehicle safety design.

[0113] 12. In-vehicle intelligent computing platform (hereinafter referred to as computing platform):

[0114] Autonomous driving vehicles build software and hardware systems around the three major links of perception, decision-making and execution. The on-board intelligent computing platform is the "brain" of the autonomous driving vehicle. It is mainly responsible for completing the recognition and fusion tasks of the perception link and the entire decision-making link, and requires processing massive data and performing complex logical operations.

[0115] To meet the high computing power requirements, the current in-vehicle intelligent computing platform integrates multiple system-on-chips (SoCs), and each SoC integrates multiple types of computing units (such as CPU, GPU, FPGA, ASIC, etc.). At the same time, the in-vehicle intelligent computing platform also requires an efficient software architecture to support application development. Its software architecture is highly layered and modular, mainly divided into three layers: system software (virtual machine, operating system, and middleware), functional software, and application programs. Compared with traditional components, the in-vehicle intelligent computing platform involves various types of chips and software, and the suppliers come from different fields, with a diverse supply ecosystem.

[0116] With the evolution of E / E architecture, computing platforms are being redefined, and operating systems and application software also need to be redefined. Due to the rapid iteration of intelligent driving software algorithms and their reliance on numerous third-party libraries, the entire software stack is extremely complex, posing a significant challenge to the underlying software OS. Consequently, the industry has gradually begun exploring the construction of dual-Guest OS systems based on virtual machines within in-vehicle intelligent computing platforms, such as solutions that enable the simultaneous operation of two OSes through virtualization technology. Such systems typically operate on the same hardware platform through virtualization technology, sharing underlying hardware resources and providing multi-partition service capabilities. These two OSes can be referred to as general-purpose OS and functional safety OS, respectively. The general-purpose OS primarily addresses the needs of a rich ecosystem and ensures the functional completeness of the system; the functional safety OS primarily provides precise real-time control, deterministic scheduling, and a high-performance execution environment. The two work together to provide a system that meets these requirements.

[0117] However, different original equipment manufacturers (OEMs) have their own shortcomings when applying virtual machine-based dual Guest OS systems to computing platforms.

[0118] (1) Computing platforms based on embedded OS solutions such as QNX provided by traditional OEMs:

[0119] As shown in Figure 4, in the smart car sector, hypervisor-layer virtualization enables the operation of multiple guest OSes, providing computing platforms based on embedded OS solutions such as QNX. These platforms include general-purpose OSes based on the Linux kernel and secure OSes based on the QNX microkernel. On the general-purpose OS side, the Linux kernel provides standard system services, including gateway, management, mapping, and cloud services. On the secure OS side, the QNX microkernel provides QNX system services, such as the AUTOSAR (Automotive Open System Architecture)-compliant basic software framework and autonomous driving-related applications. These applications provide vehicle perception, integration, and regulatory control services.

[0120] While multiple components based on embedded OS solutions like QNX already support the highest Automotive Safety Integration Level (ASIL) D certification, demonstrating their safety advantages, the non-open-source nature of QNX results in insufficient ecosystem support and limited development flexibility, making it difficult to meet the development, debugging, and operational requirements of complex intelligent driving applications. Furthermore, since QNX drivers are processes, porting them requires custom rewriting, forcing automakers to be tied to multiple licensing and business models, resulting in high overall costs. Furthermore, due to QNX's microkernel architecture, some key OS performance issues are impacted by inter-process communication (IPC).

[0121] Therefore, computing platforms based on embedded OS solutions such as QNX are unable to meet the demands of developing autonomous driving-related applications in safe OS for a rich ecosystem and rapid iteration.

[0122] (2) Computing platforms developed based on Linux kernel solutions provided by emerging OEMs:

[0123] As shown in Figure 5, in the smart car sector, hypervisor-layer virtualization can provide the ability to run multiple guest operating systems, providing a computing platform developed based on the Linux kernel. This computing platform, based on the Linux kernel, adds a real-time and secure kernel. The hypervisor layer isolates the general-purpose OS and the secure OS. The general-purpose OS manages and executes applications related to ecosystem algorithms, while the secure OS provides real-time, high-performance, and secure algorithm application execution. However, the secure OS lacks independent operation capabilities. The operation of apps on the secure OS (referred to as secure apps) relies heavily on the general-purpose OS kernel. Through a proxy mechanism, the Linux kernel acts as a service partition, providing system call services, page fault exception services, and maintenance proxy services to apps on the secure OS side, ensuring real-time, high-performance, and secure algorithm application execution.

[0124] As shown in Figure 6, in this solution, the Linux kernel launches the security app as a normal Linux app. For example, in step 1, the Linux process / thread launches the security app, causing it to enter kernel state. However, after the Linux kernel completes kernel state initialization for the security app and prepares to enter execution, the execution flow is intercepted by the underlying hypervisor layer. For example, the hypervisor layer intercepts the thread context through interrupts and shared memory. The intercepted thread context is transferred to the security app on the secure OS for execution in step 2. While the security app is running, for example, a system call service / page fault exception service / maintenance proxy service is triggered in step 3. In step 4, the proxy mechanism set up by the secure OS kernel redirects the relevant service request to the Linux kernel for processing, which is also known as a proxy request. This proxy request must carry the relevant thread context on the secure OS side to describe the thread's execution status. The Linux kernel then waits to process the proxy request. In the Linux kernel, the secure APP kernel state is always blocked and waiting. Once it receives a proxy request sent by the secure OS, it runs a specific thread based on the relevant thread context carried in the proxy request, calls the corresponding function of the Linux kernel to process the proxy request, and returns the processing result to the secure OS kernel.

[0125] Based on the aforementioned proxy mechanism, threads in the general-purpose OS and threads in the security OS are strongly bound to each other based on thread context. This strong 1:1 binding relationship increases linearly with the increase in business volume, placing significant pressure on the general-purpose OS's maintenance and testing statistics. Furthermore, the overall execution path is lengthy, resulting in reduced system performance. Furthermore, the security OS's strong dependency on the general-purpose OS can render it inoperable if the general-purpose OS fails, making it difficult to meet high functional safety requirements.

[0126] In response to the above problems, the present application provides a system call method and device for realizing the coexistence of multiple systems on the computing platform of the vehicle, while enabling the safety OS to efficiently reuse the ecology of the general OS to ensure the system performance of the entire computing node as much as possible. In an optional embodiment, the scheme can also enable the general OS and the functional safety OS to cooperate with each other, so that the safety OS can still self-heal after the general OS fails, and meet the demand for high functional safety at a lower cost. Among them, the method and the device are based on the same technical concept. Since the principles of solving the problem by the method and the device are similar, the implementation of the device and the method can refer to each other, and the repetitions will not be repeated. Moreover, in the various embodiments of the present application, if there is no special explanation and logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced to each other, and the technical features in different embodiments can be combined to form new embodiments according to their internal logical relationships.

[0127] It should be noted that, in the embodiments of the present application, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

[0128] Furthermore, unless otherwise specified, ordinal numbers such as "first" and "second" in the embodiments of this application are used to distinguish between multiple objects and are not used to define the priority or importance of multiple objects. For example, "first OS" and "second OS" are only used to distinguish between different OSes, and do not indicate a difference in priority or importance between the two OSes.

[0129] The following is a detailed description with reference to the accompanying drawings and embodiments.

[0130] FIG7 shows a schematic diagram of the system architecture of an embodiment of the present application.

[0131] As shown in FIG. 7 , the architecture may include at least two operating systems (OS), for example, a first OS and a second OS, as well as other OSs not shown.

[0132] Among them, the at least two operating systems can be deployed on the same hardware platform and in different virtual operating environments obtained by dividing the processor using the virtual machine technology mentioned above. For example, after dividing the same processor into different virtual operating environments using virtual machine technology, different operating systems can be deployed in different operating environments. For example, the first OS in Figure 7 can be deployed in the first virtual operating environment of a processor, and the second OS can be deployed in the second virtual operating environment of the processor.

[0133] Alternatively, the at least two operating systems can be deployed on a multi-domain chip. For example, the chip is divided into different areas or functional blocks, each area or functional block can become a domain, and different domains can have different processor cores, memories, I / O interfaces and other resource configurations. Each domain is responsible for different tasks and functions to achieve different functions or performance requirements. Any of the at least two operating systems can be deployed on the processor core of a domain to achieve more efficient and safer chip operation. For example, the first OS in Figure 7 can be called a functional safety domain, deployed on the processor core of the functional safety domain, and the second OS is called a general domain, deployed on the processor core of the general domain.

[0134] Alternatively, the at least two operating systems may be deployed on different chips. For example, the first OS in FIG7 may be deployed on a first processor disposed on a first chip, and the second OS may be deployed on a second processor disposed on a second chip.

[0135] Regardless of which of the above deployment methods is adopted, a secure shared channel can be constructed between the first OS and the second OS. The first APP running on the first OS can apply for the use of resources or services provided by the first OS by means of system calls, and can also apply for the use of resources or services provided by the second OS through cross-OS system calls and the secure shared channel. The kernel of the first OS may include multiple functional nodes (or functional modules), and the multiple functional nodes may process the system call requests initiated by the first APP to the kernel of the first OS. The kernel of the second OS may also include multiple functional nodes (or functional modules), and the multiple functional nodes may process the cross-OS system (service) call requests initiated by the first APP to the second OS.

[0136] For ease of distinction, in the embodiments of the present application, the service provided by utilizing the system resources of the second OS may be referred to as the first service, and the service provided by utilizing the system resources of the first OS may be referred to as the second service. The kernel node in the kernel of the first OS that provides the same OS system call service for the first APP is referred to as the second processing node, and the kernel node in the kernel of the first OS that provides the cross-OS system call service for the first APP is referred to as the first processing node. The first processing node may also be referred to as the client of the cross-OS system call service, which is used to respond to the system cross-OS system call request from the first APP and send a service request to the second OS through the secure shared channel between the first OS and the second OS to apply for the use of the resources or services provided by the second OS. The kernel of the second OS may include a third processing node, which may also be referred to as the server of the cross-OS system call service, which is used to receive the service request from the first OS and allocate an available first thread to the service request from multiple threads of the second OS so that the first thread processes the service request, i.e., provide a cross-OS system call service for the APP on the first OS side.

[0137] In a specific implementation, the kernel of the first OS may also include a service routing node. After the first APP in user mode initiates a system call request, it falls into kernel mode. In kernel mode, the service routing node in the kernel of the first OS will analyze whether the system call request from the first APP is initiated towards the kernel of the first OS or towards the second OS. If the system call request is initiated towards the kernel of the first OS, the service routing node will route the system call request to the second processing node, which can use the system resources of the first OS to process the system call request so that the first APP can implement the corresponding task or function. If the system call request is initiated towards the second OS, the service routing node will route the system call request to the first processing node, which can send a corresponding service request to the second OS based on the information carried in the system call request and the secure shared channel between the first OS and the second OS, so as to apply to the second OS for the use of resources or services provided by the second OS.

[0138] In an embodiment of the present application, a secure shared channel between the first OS and the second OS can be implemented in different ways. For example, a network communication channel can be established between the first OS and the second OS through network communication technology as the secure shared channel, and the first processing node can send a service request to the second OS through the network communication channel. The service request can include a service identifier of the first service and a system call parameter associated with the first service, so that the first thread allocated on the second OS side can process the service request based on the service identifier and the system call parameter, using the system resources on the second OS side to implement the task or function of the first APP on the first OS side. Or, for example, the secure shared channel can be implemented between the first OS and the second OS through shared memory and interrupt mechanism. A stateless system service request module (not shown in the figure) can also be provided in the secure shared channel. The first processing node can send the service identifier and the system call parameter associated with the first service to the stateless system service request module in response to the system call request from the first APP. The stateless system service request module can store the system call parameter in the shared memory and construct a service request. The service request includes the storage address of the service identifier (or management information / control information) and the system call parameter in the shared memory. Accordingly, the first thread may read corresponding system call parameters from the shared memory based on the address information carried in the service request, so as to process the service request based on the service identifier and the system call parameters.

[0139] The second OS may include multiple threads (e.g., represented as thread 1, thread 2, ... thread n, where n is an integer greater than or equal to 2). These threads may be kernel threads (lightweight threads). When any thread is idle, it can be scheduled to handle a service request from the first OS, thereby enabling the first app to utilize the system resources of the second OS to implement the corresponding task or function. This method will be described in detail below in conjunction with the flowchart and will not be detailed here.

[0140] It should be understood that this is only an introduction to the implementation method of the task or function of the first APP using the system call method as an example, and it is not any limitation. In other embodiments, the software development kit (SDK) of the first APP can also integrate the access interface of the third-party library (external open source library). When the first APP is running, it can also access the third-party library through the access interface to obtain more resources or implement more functions. Alternatively, the multiple threads of the second OS can also include threads running in user mode. When the first APP initiates a system call request to the second OS, the corresponding service request can also be processed by the idle thread running in user mode of the second OS. The embodiment of the present application does not limit the service provision method of the first APP.

[0141] Therefore, through the above solution, the service request from the first OS only contains the service identifier and system call parameters associated with the first service (or the storage address of the system call parameters in shared memory), but does not contain complete thread context information. It is a stateless cross-OS system call request that can decouple the service request from the thread state, so that the second OS side can allocate an available idle thread to the service request in real time. This is different from the solution based on the proxy mechanism introduced above, which requires a 1:1 strong binding of the cross-OS system service request to a specific thread based on the thread context. It can reduce the system noise floor and improve the performance of the entire system. This solution can also change the thread management method of the second OS, such as changing to managing multiple threads of the second OS in a thread pool manner, supporting dynamic expansion or reduction of the threads of the second OS to meet system requirements, while reducing the system resource overhead of the second OS.

[0142] In addition, since the implementation of some tasks or functions of the first APP depends on the threads of the second OS, if the second OS fails, the threads of the second OS will not be able to receive service requests from the first OS, which will affect the continued operation of the functions or services of the first APP. Therefore, in order to ensure the robustness and robustness of the system, one implementation method is to set up a fault self-recovery node in the first OS and set up a fault self-recovery mechanism in the first APP and the first processing node, so that before the first APP initiates a system call request to the second OS or during the process of initiating a system call request to the second OS, it can detect whether the second OS is faulty, and when the second OS fails or after the failure is recovered, the fault self-recovery mechanism is promptly activated to ensure the resumption of execution of the tasks or functions of the first APP.

[0143] For example, the fault self-recovery node can be based on a heartbeat detection mechanism to detect the operating status of the second OS in real time or periodically, and inform the first processing node and / or the first APP of the status information of the second OS. The status information may include the fault state or non-fault state of the second OS. Alternatively, a "dying words" function can be set on the second OS side, so that when the second OS fails, the "dying words" function is activated to actively inform the fault self-recovery node on the first OS side that it is in a fault state. The embodiment of the present application does not limit the specific implementation method of the fault detection mechanism of the second OS.

[0144] In one example, if the first processing node determines that the second OS is in a faulty state before the first APP initiates a system call request to the second OS, the first processing node can sleep after saving the context information associated with the system call request to suspend the system call to the second OS to prevent the system call request from being unresponsive. At the same time, if the second OS recovers from a faulty state to a non-faulty state when the first processing node is in sleep, the first OS needs to re-acquire the context information associated with the system call request and wake up the first processing node. The first APP can re-initiate the system call request based on the context information associated with the system call request, and the first processing node can re-respond to the system call request and send a service request to the second OS. Since the second OS has recovered to a non-faulty state, the service request can be re-received and processed by the second OS side, which does not affect the implementation of the tasks or functions on the first OS side.

[0145] In another example, if the thread (or process) of the first APP determines that the second OS is in a faulty state during the process of sending a service request to the second OS, the thread (or process) of the first APP goes into hibernation after saving the context information associated with the service request to prevent the service request from being unresponsive. At the same time, if the second OS recovers from a faulty state to a non-faulty state while the second thread is in hibernation, the first processing node can re-acquire the context information associated with the service request and wake up the thread (or process) of the first APP, and the thread (or process) of the first APP can re-send the service request to the second OS based on the context information associated with the service request. Since the second OS has recovered to a non-faulty state, the service request can be re-received and processed by the second OS side, which does not affect the implementation of the tasks or functions on the first OS side.

[0146] If the thread (or process) of the first APP determines that the second OS is in a faulty state after sending a service request to the second OS, the service request may have been received and processed by the thread of the second OS. Even if the second OS side recovers after the failure, the service request is recognized and restored, and does not affect the continued operation of the tasks or functions on the first OS side. There is no need to execute the fault self-healing mechanism on the first OS side.

[0147] In another embodiment, a second app can be installed and run on the first OS. The second app can be used to trigger the fault self-recovery node in the first OS kernel to detect the running status of the second OS in real time or periodically. The embodiment of the present application does not limit the implementation method of this fault detection mechanism.

[0148] Therefore, in the above solution, based on the first OS independently implementing the tasks or functions of the first app, the above-mentioned self-healing mechanism allows the first OS to independently run security tasks for several minutes even if a fault occurs on the second OS. After the second OS recovers from the fault, the system calls from the first OS to the second OS can self-heal. As an example, the second OS can use a Linux system with excellent ecological capabilities to ensure that the entire communication system meets the optimal functional safety, performance, and ecological conditions.

[0149] For ease of understanding, the following describes the system call method of an embodiment of the present application, using the example of the first and second OSs deployed on a vehicle's computing nodes via virtual machine technology in Figure 7. The first OS, which may also be referred to as a functional safety OS, may run a first app on the first OS, which may include an autonomous driving-related app. The second service provided by the first OS may include at least one of a scheduling service, a process management service, or a memory management service associated with the autonomous driving-related app. The second OS, which may also be referred to as a general-purpose OS, may provide a first service including at least one of file management, interrupt management, or communication management associated with the autonomous driving-related app.

[0150] Figure 8 shows a schematic flow chart of a system call method according to an embodiment of the present application. As shown in Figure 8, the method may include the following steps:

[0151] S810: The first APP initiates a first system call request.

[0152] In the embodiments of the present application, both the first and second OSs may have numerous system resources that cannot be freely accessed by APPs. Therefore, the OSs may provide access for APPs to use, such as providing a system call (function) interface and a system call number, with each system call corresponding to a unique system call number. On the first OS side, different system call numbers may be preset to bind to the first and second services, respectively. For example, the system service call number corresponding to the read / write interface may be set to the system call number bound to the second service to provide read / write management services for memory. Alternatively, the system service call number corresponding to the mount interface may be set to the system call number bound to the first service to provide file management services.

[0153] If in S810, the first APP initiates the first system call request to the second OS, the first system call request may include the service identifier of the first service, and the service identifier may be the system call number bound to the first service. If the first APP initiates the first system call request to the first OS, the first system call request may include the service identifier of the second service, and the service identifier may be the system call number bound to the second service. In an optional embodiment, if certain services can be provided by both the first OS and the second OS, the service identifier included in the first system call request may be implemented as a combination of a system call number and a label, and the label may indicate whether it is provided by the first OS or the second OS. Based on the service identifier, the service routing node in the kernel of the first OS can know whether to route the first system service request to the first processing node or the second processing node.

[0154] It should be understood that the first APP's call to the second service is a system call of the same OS. The specific implementation of the system call process can be found in the relevant technology and will not be repeated here. The following will mainly introduce the system call process of the first APP for the first service provided by the second OS.

[0155] S820: The first OS sends a service request to the second OS according to the service identifier.

[0156] In an embodiment of the present application, as shown in FIG7 , the kernel of the first OS may include a service routing node. The service routing node may identify, based on the service identifier carried in the first system service request, whether the first system service request is specifically initiated for the second service provided by the first OS or for the first service provided by the second OS. If the first system service request is initiated for the first service provided by the second OS, the service routing node may route the first system service request to the first processing node in the kernel of the first OS. When implementing S820, the first processing node may send a service request to the second OS based on the service identifier carried in the first system call request. For example, the first processing node may send a service request to the second OS via a network communication channel between the first and second OSs. The service request includes the service identifier of the first service requested by the first APP and the system call parameters associated with the first service, such as the thread identifier of the first APP and the input parameters of the system call function. A third processing node may receive the service request and allocate an available first thread to the service request. When the first thread runs, it may process the service request based on the service identifier of the first service and the system call parameters associated with the first service, utilizing the system resources of the second OS.

[0157] In an optional implementation, the first system call request may also include system call parameters associated with the first service, such as the thread identifier of the first APP, the input parameters of the system call function, etc. The secure shared channel between the first OS and the second OS can be implemented as a shared memory between the two. When implementing S820, the first OS may also apply for a first memory space from the shared memory, and store the system call parameters associated with the first service in the first memory space, such as the thread identifier of the first APP, the input parameters of the system call function, etc., and the context state information (including various status registers) of the task on the first OS side is not included. The shared memory may include a stateless system service request module, and the stateless system service request module may send a service request to the second OS. The service request may include a service identifier and a first address, and the first address is the storage address of the system call parameters associated with the first service in the first memory space. Accordingly, after receiving the service request, the second OS may read the system call parameters associated with the first service from the first memory space according to the first address, so that the second OS processes the service request according to the system call parameters.

[0158] S830: The second OS receives the service request and allocates an available first thread from a plurality of threads to the service request.

[0159] In an embodiment of the present application, as shown in FIG7 , the multiple threads may be kernel threads of the second OS, and the second OS may sequentially select an idle thread as an available first thread to allocate (or called "taking out" or "taking off") to the service request. In one example, the multiple kernel threads may be specifically scheduled and managed by a third processing node in the kernel of the second OS. For example, the second OS may create a service thread pool when the third processing node is initialized, and the service thread pool includes multiple kernel threads that can be used to provide cross-system call services for the first OS side. Upon receiving a service request from the first OS, the third processing node may allocate an available first thread to the service request. For example, in FIG7 , if thread 1 is occupied and thread 2 is idle, the third processing node may allocate thread 2 to the service request.

[0160] In an optional embodiment, the kernel service thread pool on the second OS side also supports dynamic expansion or dynamic contraction. For example, the third processing node in the second OS can obtain the demand information of the first APP for the thread of the first service, and release at least one of the multiple threads according to the demand information, or create at least one new thread for the multiple threads according to the demand information. In this way, by releasing the resources of the abundant service threads in the kernel of the second OS, the utilization rate of the system resources of the second OS can be improved, or more service threads can be created for the first OS to meet the needs of cross-OS system services on the first OS side.

[0161] S840: The first thread processes the service request.

[0162] For example, when the first thread runs on the second OS, it reads the system call parameters associated with the first service from the first memory space according to the first address carried in the service request. The system call parameters do not involve the context state of the first OS task. The first thread does not need to perceive the context state of the first OS task and can directly process the service request according to the system call parameters. After processing, the first thread can feedback the processing results to the first processing node through the secure shared channel between the first OS and the second OS, and release the resources applied for this process. For example, the first thread sends a return value to the first processing node through the secure shared channel, that is, the processing result of this system service request, indicating whether it is successful or not. The first processing node will return the return value to the first APP in user state, thereby completing a cross-OS system call service.

[0163] In the above process, since the system call parameters provided by the first processing node to the second OS through the secure shared channel do not contain the context information of the process / thread executing the task on the first OS side, the kernel thread on the second OS side does not need to be aware of the context state of the first OS task, and does not need to be strongly bound 1:1 with the thread on the first OS side. The service thread on the second OS side can be decoupled from the task on the first OS side, thereby reducing the background noise of the entire system and improving system performance.

[0164] In addition, the execution process of the thread of the first APP initiating the first system call request on the first OS side is called an execution flow. The checkpoint of the fault self-healing mechanism of the embodiment of the present application can be a control node in the execution flow, and the subsequent execution steps can be controlled at this checkpoint by checking the status of the second OS.

[0165] In one example, the checkpoint can be set at the first processing node. As shown in FIG9 , in combination with the fault self-healing mechanism of the embodiment of the present application, the system call method may include the following steps:

[0166] S901: A first APP initiates a first system call request to request the use of a cross-OS system service.

[0167] S902: The service routing node in the first OS kernel determines whether the first system call request is initiated for the second OS. If so, the process proceeds to S903; otherwise, the process proceeds to S909.

[0168] S903: The service routing node routes the first system call request to the first processing node in the first OS kernel.

[0169] S904: A checkpoint is set at the first processing node to obtain status information of the second OS to determine whether the second OS is in a faulty state. If so, the process proceeds to S905, where a fault self-recovery mechanism is implemented to save the context information associated with the service request. When the second OS recovers from the faulty state, the service request is resent to the second OS based on the saved context information. If not, the process proceeds to S906.

[0170] S905: Implement a fault self-recovery mechanism to save the context information associated with the service request. When the second OS recovers from a faulty state, the first processing node can resend the service request to the second OS based on the saved context information. After recovery, the process returns to S903 to detect whether the second OS has failed in real time or periodically at the first processing node.

[0171] Among them, the kernel of the first OS may include a second thread associated with the first APP, and the second thread may be a thread of the first APP running in the kernel state for implementing the task of the first APP, and the first processing node may be used to manage the second thread to make a system call to the second OS. When implementing S904, it may be that the second thread determines whether the second OS is in a faulty state. If so, when implementing S905, the second thread saves the context information associated with the service request and then goes to sleep. For example, the second thread may go to sleep after storing the context information associated with the service request in a shared memory (such as a first memory space). Later, when the second OS recovers from a faulty state to a non-faulty state, the first processing node may read the context information associated with the service request from the shared memory and wake up the second thread. The second thread may resend the service request to the second OS based on the context information associated with the service request.

[0172] S906: The first processing node sends a service request to the second OS through the stateless system service request module in the secure shared channel to request to call the system service of the second OS. For example, the first processing node can inform the stateless system service request module of the service identifier of the first service to be called, and at the same time apply for a first memory space from the shared memory, and store the system call parameters associated with the first service in the first memory space. The stateless system service request module can send a service request to the second OS based on the service identifier and the first address of the first service. The service request includes the service identifier and the first address, and the first address is the storage address of the system call parameters associated with the first service in the first memory space.

[0173] S907: The third processing node in the second OS kernel receives the service request and allocates an available first thread from the plurality of kernel threads to the service request. When the first thread runs, it reads system call parameters associated with the first service from the shared memory based on the first address carried in the service request and processes the service request based on the system call parameters.

[0174] S908: After the processing is completed, the first thread sends the processing result to the first processing node through a secure shared channel and releases the relevant service resources. For example, a return value is sent to indicate success or failure. The relevant service resources may include the running resources corresponding to the first thread, and may also include the system resources of the second OS used by the first thread to process the service request. This embodiment of the present application does not limit this. Accordingly, the first processing node can also send the processing result to the first APP in the user state, that is, complete the processing of this cross-OS system call service.

[0175] S909: The second processing node in the second OS kernel responds to the same OS system call request from the first APP and uses the system resources of the first OS to provide system services for the first APP.

[0176] Therefore, the above method checks the status of the second OS during the process in which the kernel-mode thread managed by the first processing node sends a service request to the second OS in response to the first system call request, so as to timely save the context information associated with the service request and control the second thread to sleep when the second OS is in a faulty state, so that after the fault of the second OS is recovered, the second thread can be autonomously awakened to resend the service request to the second OS, thereby reducing the situation in which the service request cannot be received and processed by the second OS due to the failure of the second OS, and restoring the first APP that uses the system service to continue running, thereby improving the robustness and security of the data plane OS.

[0177] In another example, the failure of the second OS may occur at any time in the execution flow of the cross-OS system call service of the first APP. In the embodiment of the present application, different processing flows can also be executed according to different occurrence times of the second OS failure.

[0178] As shown in Figure 10, a checkpoint can be set for a first app in user mode. For example, in the first OS, a second app can be started as a resident process to monitor the status of the second OS. The second app can periodically initiate a second system call request to the second OS. The first processing node in the first OS can, via a third thread, send a service request to the second OS in response to the second system call request and obtain the second OS's status information based on the second OS's response to the service request. For example, the response information can include a return value and a timestamp, and the return value can indicate that the second OS has successfully received the service request. The first processing node can notify the second app of the second OS's response to the service request. The second app can determine whether it has received the expected return result, such as whether it has received the expected return result within a fixed time interval or whether it has received the expected return result within multiple fixed time intervals. If so, it can be determined that the second OS's status is normal, that is, it is in a non-faulty state. If not, it can be determined that the second OS is in a faulty state.

[0179] As shown in Figure 11, a checkpoint can be set in kernel mode. Before initiating a cross-OS system call request, the first APP can obtain the status information of the second OS by interacting with the second APP. If it is determined that the second OS is in a faulty state before the first APP initiates a cross-OS system service call request, the first APP can instruct the first processing node to store the context information associated with the first system call request to be initiated in the shared memory and then sleep. The second thread managed by the first processing node, that is, the second thread of the first APP running in kernel mode, can interact with the fault self-healing module of the first OS kernel to obtain the status information of the second OS. If the first processing node controls the second thread to send a service request to the second OS in response to the first system call request and determines that the second OS is in a faulty state, the first processing node can instruct the second thread to sleep after storing the context information associated with the service request in the shared memory. If it is determined that the second OS is in a faulty state after the second thread sends a service request to the second OS, the service request may have been received by the second OS. After the second OS recovers from the fault, the second OS can schedule the available first thread for the service request and the first thread can process the service request. This process has no effect on the operation of the process / thread on the first OS side. The first OS only needs to execute the cross-OS system call process of the embodiment of the present application normally, which will not be repeated here.

[0180] Accordingly, under various fault conditions shown in FIG. 10 or FIG. 11 , if the second OS side recovers from the faulty state to the non-faulty state, the first OS side also needs to quickly self-heal to re-initiate a system call to the second OS.

[0181] As shown in FIG12 , the self-healing process of the first OS and the second OS may include the following steps:

[0182] S1201: The second OS recovers from a faulty state to a non-faulty state.

[0183] S1202: Rapidly create a service thread pool in the kernel of the second OS. The service thread pool may include multiple kernel threads for processing service requests triggered by cross-OS system call requests from the first OS.

[0184] S1203: The first OS detects that the second OS has recovered from a faulty state to a non-faulty state. For example, the second APP detects that the second OS has recovered from a faulty state to a non-faulty state.

[0185] S1204: Wake up the task that was dormant when the fault occurred, restore the context state of the task at that time and complete data verification.

[0186] For example, if the second OS recovers from a faulty state to a non-faulty state while the first processing node is dormant, the first OS can read the context information associated with the first system call request from the shared memory and wake up the first processing node. The first processing node can verify the context information associated with the first system call request based on the management information in the shared memory to verify the integrity of the data before the fault.

[0187] Or for example, if the second OS recovers from a faulty state to a non-faulty state when the second thread is dormant, the first processing node reads the context information associated with the service request from the shared memory and wakes up the second thread. The second thread can verify the context information associated with the service request based on the management information in the shared memory to verify the integrity of the data before the failure.

[0188] S1205: Enable the awakened task to re-initiate the cross-OS system call service for the second OS.

[0189] For example, after the first processing node is awakened, the first APP may re-initiate the first system call request according to the context information associated with the first system call request, and the first processing node re-sends a service request to the second OS in response to the first system call request.

[0190] Or for example, after the second thread is awakened, the second thread may resend the service request to the second OS based on the context information associated with the service request.

[0191] Accordingly, on the second OS side, the third processing node can re-receive the cross-OS system service request from the first OS and call the available first thread for the service request to process the service request. This process is the same as described above in conjunction with Figures 8 and 9. The specific implementation can be found in the relevant description above and will not be repeated here.

[0192] Therefore, through the above method, during the cross-OS system call process, by detecting the status of the second OS at different checkpoints in the cross-OS system call execution flow, saving the context information of the task at different fault occurrence times, and putting the execution node and / or thread of the corresponding task to sleep, that is, putting this cross-OS system call process to sleep to suspend the execution of the cross-OS system call, so as to prevent the service request related to the cross-OS system call from not being received by the faulty second OS and affecting the operation of the first APP on the first OS side. Accordingly, based on this fault self-healing mechanism, after the fault on the second OS side is recovered, the first OS side can also re-execute the cross-system call for the second OS by waking up the dormant nodes and / or threads, thereby improving the robustness and robustness of the entire system.

[0193] On the computing node of the vehicle based on the above solution, compared with the computing platform shown in Figure 4, the first OS's support for the standard POSIX interface can be improved. Compared with the computing platform shown in Figure 5, the kernel thread can provide system services in the kernel of the second OS, and the service request from the first OS does not contain thread context state information, so that the APP thread in the first OS can be bound to any general kernel thread of the second OS as a service thread to process cross-OS system service requests, which can effectively reduce the amount of communication data, and at the same time greatly shorten the creation delay of the service thread on the second OS side, and improve the critical path performance of cross-OS system service calls. On this basis, a fault self-healing mechanism is implemented to enable the APP task of the first OS to run in a self-healing manner, which helps the entire computing node reach a better state that meets functional safety, performance, and ecology.

[0194] It should be understood that the above method flow is only an example of cross-OS system call service and is not limited in any way. The method is also applicable to initiating a page fault processing process or a maintenance process from the first OS side to the second OS side. Through the cross-OS system processing process, the first OS side can reuse the various resources and services provided by the second OS side, so that the first OS can reuse the ecology of the second OS. For example, the first OS supports the ability to reuse the disk file system of the second OS, and the APP file running on the first OS can be saved in the second OS. During the page fault processing process, the APP file can be read from the second OS side to the first OS side using the method of the embodiment of the present application. Or for example, the first OS supports the ability to reuse the second OS terminal, and the method of the embodiment of the present application can be used to implement the ability to debug the first OS on the second OS side.

[0195] The above method can also be applied to implement cross-OS system call services in a multi-domain chip architecture scenario. The specific implementation method is the same as the process described above in conjunction with Figures 8-12. The specific implementation details can be found in the relevant description above and will not be repeated here. In addition, the above method can also be applied to a dual-chip architecture scenario. The OSs of processors deployed on different chips can exchange information through the network communication channel between the two chips, so that the operating system on one chip can apply for and use the resources or services provided by the other chip. Similarly, the fault self-healing mechanism of the embodiment of this application can also be used to improve the robustness and robustness of the entire chip system.

[0196] The embodiment of the present application further provides a communication device for executing the method executed by the first OS or the second OS in the above method embodiment. The relevant features can be found in the above method embodiment and will not be repeated here.

[0197] As shown in Figure 13, in one example, a communication device 1300 may include: a first APP 1301 for initiating a first system call request, wherein the first system call request includes a service identifier of a first service; a transceiver unit 1302 for sending a service request to the second OS based on the service identifier. As shown in Figure 14, in another example, a communication device 1400 may include: a transceiver unit 1401 for receiving the service request and allocating an available first thread to the service request from multiple threads; and a first thread 1402 for processing the service request. For specific implementation methods, please refer to the method steps implemented by the first OS or the second OS in the above method embodiment, which will not be repeated here.

[0198] It should be understood that the division of the various units in the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into a physical entity, or they can be physically separated. In addition, the units in the device can be implemented in the form of a processor calling software; for example, the device includes a processor, the processor is connected to a memory, and the memory stores instructions. The processor calls the instructions stored in the memory to implement any of the above methods or realize the functions of the various units of the device, where the processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is a memory within the device or a memory outside the device. Alternatively, the units in the device can be implemented in the form of hardware circuits, and the functions of some or all of the units can be realized by designing the hardware circuits. The hardware circuit can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC), which realizes the functions of some or all of the above units by designing the logical relationship of the components in the circuit. For another example, in another implementation, the hardware circuit can be implemented by a programmable logic device (PLD). Taking a field programmable gate array (FPGA) as an example, it can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured by configuring the configuration file, thereby realizing the functions of some or all of the above units. All units of the above devices can be implemented in the form of software called by the processor, or in the form of hardware circuits, or in part by the form of software called by the processor, and the rest by hardware circuits.

[0199] In an embodiment of the present application, a processor is a circuit with a signal processing capability. In one implementation, the processor may be a circuit with instruction reading and execution capability, such as a CPU, a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP); in another implementation, the processor may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and implementing the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.

[0200] It can be seen that each unit in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0201] In addition, the various units in the above devices can be fully or partially integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of the various units of the device. The type of the at least one processor can be different, for example, including a CPU and FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.

[0202] In a simple embodiment, those skilled in the art may conceive that the communication devices in the above embodiments may all adopt the form shown in FIG. 15 .

[0203] As shown in FIG15 , the apparatus 1500 includes at least one processor 1510 and a communication interface 1530. In an optional design, a memory 1520 may also be included.

[0204] The specific connection medium between the processor 1510 and the memory 1520 is not limited in the embodiment of the present application.

[0205] In the apparatus as shown in FIG. 15 , the processor 1510 may transmit data through the communication interface 1530 when communicating with other devices.

[0206] When the communication device adopts the form shown in Figure 15, the processor 1510 in Figure 15 can call the computer-executable instructions stored in the memory 1520, so that the device 1500 can execute any of the above method embodiments.

[0207] An embodiment of the present application also relates to a chip system, which includes a processor for calling a computer program or computer instructions stored in a memory so that the processor executes the method of any of the above embodiments.

[0208] In a possible implementation, the processor may be coupled to the memory through an interface.

[0209] In a possible implementation, the chip system may also directly include a memory, in which a computer program or computer instructions are stored.

[0210] For example, the memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache memory. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0211] An embodiment of the present application further relates to a processor, which is used to call a computer program or computer instruction stored in a memory so that the processor executes the method described in any of the above embodiments.

[0212] For example, in the embodiments of the present application, the processor is an integrated circuit chip with signal processing capabilities. For example, the processor can be an FPGA, a general-purpose processor, a DSP, an ASIC or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, a system on chip (SoC), a CPU, a network processor (NP), a microcontroller unit (MCU), a PLD or other integrated chip, and can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0213] It should be understood that the embodiments of the present application may be provided as methods, systems, or computer program products.

[0214] In one possible implementation, an embodiment of the present application provides a computer-readable storage medium, which stores program code. When the program code runs on the computer, the computer executes the above method embodiment.

[0215] In a possible implementation, an embodiment of the present application provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above method embodiment.

[0216] Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0217] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0218] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0219] Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the scope of the embodiments of the present application. Thus, if these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these changes and variations. In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced to each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

Claims

1. A system call method, characterized in that: A computing node applied to a vehicle, the computing node including a first operating system (OS) and a second OS, a first application (APP) running on the first OS, and the method including: The first APP initiates a first system call request, where the first system call request includes a service identifier of a first service; The first OS sends a service request to the second OS according to the service identifier; The second OS receives the service request and allocates an available first thread from a plurality of threads to the service request; The first thread processes the service request.

2. The method according to claim 1, characterized in that The first system call request also includes system call parameters associated with the first service, and the first OS sends a service request to the second OS according to the service identifier, including: The first OS applies for a first memory space from a shared memory, and stores system call parameters associated with the first service in the first memory space; The first OS sends the service request to the second OS through the shared memory. The service request includes the service identifier and a first address. The first address is a storage address of the system call parameters associated with the first service in the first memory space.

3. The method according to claim 2, characterized in that The first thread processes the service request, including: When the first thread runs on the second OS, it reads the system call parameters associated with the first service from the first memory space according to the first address, and processes the service request according to the system call parameters.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: The first OS acquires status information of the second OS, where the status information includes a fault state or a non-fault state; The first OS sends a service request to the second OS according to the service identifier, including: If the second OS is in a non-faulty state, the first OS sends a service request to the second OS according to the service identifier.

5. The method according to claim 4, characterized in that The first OS includes a first processing node, and the first processing node is at least configured to send the service request to the second OS in response to the first system call request. The method further includes: determining, by the first processing node, whether the second OS is in a fault state; If the first processing node determines that the second OS is in a fault state before the first APP initiates the first system call request, the method further includes: The first processing node stores context information associated with the first system call request in a shared memory of the first OS and the second OS and then goes into sleep.

6. The method according to claim 5, characterized in that If the second OS recovers from a faulty state to a non-faulty state when the first processing node is in hibernation, the method further includes: The first OS reads context information associated with the first system call request from the shared memory and wakes up the first processing node; The first APP re-initiates the first system call request according to the context information associated with the first system call request; The first processing node resends a service request to the second OS in response to the first system call request.

7. The method according to claim 5 or 6, characterized in that The first OS includes a second thread associated with the first APP, the first processing node is used to manage the second thread, and the second thread is used to send the service request to the second OS. The method further includes: The second thread determines whether the second OS is in a fault state; If the second thread determines that the second OS is in a fault state during the process of sending the service request to the second OS, the method further includes: The second thread stores the context information associated with the service request in the shared memory and then goes into sleep.

8. The method according to claim 7, characterized in that If the second OS recovers from a faulty state to a non-faulty state when the second thread is dormant, the method further includes: The first processing node reads context information associated with the service request from the shared memory and wakes up the second thread; The second thread resends the service request to the second OS based on the context information associated with the service request.

9. The method according to any one of claims 4 to 8, characterized in that A second APP is also running on the first OS. The first OS obtains status information of the second OS, including: The second AP P periodically initiates a second system call request; The first OS sends a service request to the second OS in response to the second system call request, and obtains state information of the second OS according to response information of the second OS to the service request.

10. The method according to any one of claims 1 to 9, characterized in that The method further comprises: The second OS obtains the demand information of the first APP for the thread implementing the first service, and releases at least one thread from the multiple threads according to the demand information, or creates at least one new thread for the multiple threads according to the demand information.

11. The method according to any one of claims 1 to 10, characterized in that The computing node provides different virtual operating environments through virtual machines, and the first OS and the second OS run in different virtual operating environments of the computing node.

12. The method according to any one of claims 1 to 11, characterized in that When the first APP is running, it further provides a second service by calling the first OS, wherein the first APP includes at least one APP related to autonomous driving, and the at least one APP is used to provide at least one of the following services: Perception services, integrated processing services, or regulatory control services; The second service includes at least one of the scheduling service, process management service or memory management service involved in the autonomous driving related APP, and the first service includes at least one of the file management, interruption management or communication management involved in the autonomous driving related APP.

13. A cross-system calling method, characterized in that: Applied to a first operating system (OS), the first OS is deployed on a first processor, the first processor is set on a first chip, and a first APP runs on the first OS, the method includes: The first APP initiates a cross-system call request, the cross-system call request includes a service identifier of a first service, the first service is provided by a second OS, the second OS is deployed on a second processor, and the second processor is set on a second chip; The first OS sends a cross-system service request to the second OS according to the service identifier, where the cross-system service request is used to request the second OS to allocate an available first thread, and the first thread is used to process the cross-system service request.

14. The method according to claim 13, characterized in that The first chip and the second chip communicate with each other based on a network, and the first OS sends a cross-system service request to the second OS according to the service identifier, including: The first OS sends a cross-system service request to the second OS through the network, where the cross-system service request includes the service identifier and cross-system call parameters associated with the first service.

15. The method according to claim 13 or 14, characterized in that The method further comprises: The first OS acquires status information of the second OS, where the status information includes a fault state or a non-fault state; The first OS sends a cross-system service request to the second OS according to the service identifier, including: If the second OS is in a non-faulty state, the first OS sends a service request to the second OS according to the service identifier.

16. The method according to claim 15, characterized in that The first OS includes a first processing node, and the first processing node is at least configured to send the cross-system service request to the second OS in response to the cross-system call request. The method further includes: determining, by the first processing node, whether the second OS is in a fault state; If the first processing node determines that the second OS is in a fault state before the first APP initiates the cross-system call request, the method further includes: The first processing node stores context information associated with the first system call request in a storage medium accessible to the first OS and then goes into hibernation.

17. The method according to claim 15, characterized in that If the second OS recovers from a faulty state to a non-faulty state when the first processing node is in hibernation, the method further includes: The first OS reads the context information associated with the cross-system call request from the storage medium and wakes up the first processing node; The first APP re-initiates the cross-system call request according to the context information associated with the cross-system call request; The first processing node resends a cross-system service request to the second OS in response to the cross-system call request.

18. The method according to claim 16 or 17, characterized in that The first OS includes a second thread associated with the first APP, the first processing node is used to manage the second thread, and the second thread is used to send the cross-system service request to the second OS. The method further includes: The second thread determines whether the second OS is in a fault state; If the second thread determines that the second OS is in a fault state during the process of sending the cross-system service request to the second OS, the method further includes: The second thread stores the context information associated with the service request in the storage medium and then goes into hibernation.

19. The method according to claim 18, characterized in that If the second OS recovers from a faulty state to a non-faulty state when the second thread is dormant, the method further includes: The first processing node reads the context information associated with the cross-system service request from the storage medium, and wakes up the second thread; The second thread re-sends the cross-system service request to the second OS based on the context information associated with the cross-system service request.

20. The method according to any one of claims 15 to 19, characterized in that A second APP is also running on the first OS. The first OS obtains status information of the second OS, including: The second AP P periodically initiates a cross-system call request; The first OS sends a cross-system service request to the second OS in response to the cross-system call request, and obtains state information of the second OS according to response information of the second OS to the cross-system service request.

21. A cross-system calling method, characterized in that: Applied to a second operating system (OS), the second operating system is deployed on a second processor, and the second processor is provided on a second chip, the method comprising: The second OS receives a cross-system service request from a first OS, where the first OS is deployed on a first processor, the first processor is provided on a first chip, a first APP runs on the first OS, and the service request is sent by the first OS in response to a cross-system call request initiated by the first APP; The second OS allocates an available first thread from a plurality of threads to the cross-system service request, where the first thread is used to process the cross-system service request.

22. The method according to claim 21, characterized in that The first chip and the second chip communicate with each other based on a network, and the second OS receives a cross-system service request from the first OS, including: The second OS receives a cross-system service request from the first OS through the network, where the cross-system service request includes the service identifier and cross-system call parameters associated with the first service.

23. The method according to claim 20 or 21, characterized in that The method further comprises: The second OS obtains the demand information of the first APP for the thread implementing the first service, and releases at least one thread from the multiple threads according to the demand information, or creates at least one new thread for the multiple threads according to the demand information.

24. A communication device, characterized in that: The communication device comprises: a communication interface for communicating with other devices; A processor, coupled to the communication interface, causes the communication device to execute the method according to any one of claims 1 to 12, or the method according to any one of claims 13 to 20, or the method according to any one of claims 21 to 23.

25. A chip system, characterized in that: It includes at least one processor and an interface circuit, wherein the processor is used to execute instructions and / or data interaction through the interface circuit, so that the chip system executes the method of any one of claims 1-12, or executes the method of any one of claims 13-20, or executes the method of any one of claims 21-23.

26. A vehicle, characterized in that: The method comprises a computing node, wherein the computing node is used to implement the method according to any one of claims 1 to 12, or to implement the method according to claims 13 to 20, or to implement the method according to any one of claims 21 to 23.

27. A computer-readable storage medium, characterized in that The method comprises a program or an instruction. When the program or the instruction is executed, the method according to any one of claims 1 to 12 is executed, or the method according to any one of claims 13 to 20 is executed, or the method according to any one of claims 21 to 23 is executed.

28. A computer program product, characterized in that When a computer reads and executes the computer program product, the computer is enabled to execute the method according to any one of claims 1 to 12, or the method according to any one of claims 13 to 20, or the method according to any one of claims 21 to 23.

Images