Automobile instrument screen display process control method, intelligent cabin and electronic equipment

Abstract

The invention discloses an automobile instrument screen display process control method, which is applied to an automobile instrument screen display control system and comprises the following steps: an operating system initializes and starts a daemon process, and the daemon process receives health examination data from a rendering process according to a preset heartbeat cycle and issues a rendering starting instruction according to a priority strategy; the 3D UI process or the basic UI process receives the rendering starting instruction and executes an operation corresponding to the rendering starting instruction; if it is detected that the health examination data of one of the rendering processes is abnormal, the daemon process informs the other rendering process of starting rendering, and the abnormal rendering process is terminated. According to the method, the rendering process is detected in real time, and the real-time control instruction is sent according to the current state of the rendering process, so that the real-time control on the rendering process is realized, and abnormal rendering conditions such as black screen and frame jamming caused by frequent data interaction between the CPU and the GPU and the like are prevented.

Description

Technical Field

[0001] The present invention relates to a process control method, an intelligent cockpit and electronic equipment, and in particular to an automobile instrument screen display process control method, an intelligent cockpit and electronic equipment. Background Art

[0002] The current car instrument display uses a single-process control method, which can only meet basic requirements. With the addition of 3D display requirements, users experience a more intuitive and efficient human-computer interaction experience. Drivers can quickly understand the surrounding environment of the car from the 3D picture, making it easier to make the best judgment. However, the extremely high code complexity of the 3D display business code has led to a decrease in the stability and performance of the application itself, which may cause the following problems:

[0003] More memory consumption, complex and frequent scheduling of CPU and GPU, leading to a higher crash rate. If the application process crashes, the instrument panel may display black screen, stuck frames and other abnormal rendering situations. When an abnormality occurs, the recovery time of the abnormal state becomes longer due to the large amount of calculation required to start the 3D engine, and the driver will not be able to obtain driving information from the instrument for a longer period of time. When non-crash abnormalities occur, it may cause the display of wrong information, misleading the driver and posing a safety hazard.

[0004] The above problems have not been effectively solved, can no longer meet people's requirements, and are in urgent need of improvement. Summary of the invention

[0005] The purpose of the present invention is to provide a method for controlling the display process of an automobile instrument screen, an intelligent cockpit and an electronic device, which solves the problem in the prior art that the automobile instrument screen is prone to abnormal rendering such as black screen and frame jamming, and can ensure the stability of the automobile instrument screen in the complex and frequent mutual interaction of the CPU and GPU.

[0006] The present invention provides the following scheme:

[0007] A method for controlling the display process of an automobile instrument screen, applied to an automobile instrument screen display control system, comprising:

[0008] The operating system initializes and starts a daemon process, wherein the daemon process is used to create and start a rendering process, wherein the rendering process is specifically a 3D UI process and a basic UI process;

[0009] The daemon process receives health check data from the rendering process according to the preset heartbeat cycle. When the 3D UI process or the basic UI process starts to send heartbeat data, the daemon process determines that the rendering process has rendering capabilities and issues a rendering start instruction according to the priority strategy;

[0010] The 3D UI process or the basic UI process receives a rendering start instruction and executes an operation corresponding to the rendering start instruction;

[0011] The correctness of the rendering process is detected in real time. If an abnormality is detected in the health check data of one of the rendering processes, the daemon process notifies the other rendering process to start rendering and terminates the rendering process with the abnormality.

[0012] Furthermore, the real-time detection of the correctness of the rendering process, if it is detected that the health check data of one of the rendering processes is abnormal, the daemon process notifies another rendering process to start rendering, and terminates the rendering process with the abnormality, further includes:

[0013] The daemon process notifies another rendering process to start rendering, terminates the rendering process with the exception, and recreates the rendering process with the exception.

[0014] Furthermore, the operating system initializes and starts a daemon process, the daemon process is used to create and start a rendering process, the rendering process is specifically a 3D UI process and a basic UI process, and further includes: the 3D UI process and the basic UI process communicate through shared memory;

[0015] After receiving the rendering start instruction from the daemon process, the 3D UI process and the basic UI process perform rendering calculations according to the preset rendering logic and write the calculation results into the screen buffer.

[0016] Furthermore, after receiving the rendering stop instruction from the daemon process, the 3D UI process and the basic UI process stop rendering calculation according to the preset rendering logic and stop writing the calculation results into the screen buffer.

[0017] Furthermore, the daemon process receives health check data from the rendering process according to a preset heartbeat cycle. When the 3D UI process or the basic UI process starts to send heartbeat data, the daemon process determines that the rendering process has rendering capability, and issues a rendering start instruction according to the priority strategy, further including:

[0018] Detect whether the rendering process sends heartbeat data according to the preset conditions. If it is detected that the rendering process sends heartbeat data according to the preset conditions, the 3D UI process is started first;

[0019] The daemon process detects the health check data of the rendering process in real time. If abnormal data is detected in the rendering process, the process with abnormal data is killed and restarted, or:

[0020] The daemon process does not receive the health check data of a rendering process. The daemon process kills the process that did not receive the health check data and notifies another process to start rendering.

[0021] Furthermore, the heartbeat signal detection step is also included:

[0022] The daemon process receives the heartbeat signal from the rendering process and detects whether the heartbeat signal is normal. If the heartbeat signal is correct, the status of the rendering process is marked as available;

[0023] If the heartbeat signal of the rendering process is lost, the rendering processes that have lost the heartbeat signal are counted to detect whether the number of heartbeat signal losses exceeds a preset threshold;

[0024] If the number of lost detection heartbeat signals exceeds a preset threshold, the corresponding rendering process is restarted, or: if the number of lost detection heartbeat signals does not exceed the preset threshold, the available state of the corresponding rendering process is marked as true.

[0025] An automobile instrument screen display process control system, used to implement the automobile instrument 3D display process control method, comprising:

[0026] The rendering process creates a startup module, the operating system initializes and starts a daemon process, the daemon process is used to create and start a rendering process, the rendering process is specifically a 3D UI process and a basic UI process;

[0027] A rendering start instruction processing module, in which a 3D UI process or a basic UI process receives a rendering start instruction and executes an operation corresponding to the rendering start instruction;

[0028] The rendering process correctness detection module detects the correctness of the rendering process in real time. If an abnormality is detected in the health check data of one of the rendering processes, the daemon process notifies the other rendering process to start rendering and terminates the rendering process with the abnormality.

[0029] A smart cockpit is provided with the automobile instrument screen display process control system and executes the automobile instrument screen display process control method.

[0030] An electronic device comprises: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the method.

[0031] A computer-readable storage medium stores a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of the method.

[0032] Compared with the prior art, the present invention has the following advantages:

[0033] The present invention receives health check data of different rendering processes using a preset heartbeat cycle according to the characteristics of different rendering processes, judges the rendering capability of the rendering process based on the health check data, and issues a rendering start instruction according to a priority strategy. The correctness of the rendering process is detected in real time during the rendering process. Once an abnormality is detected in the health check data of one of the rendering processes, the rendering process with the abnormality is immediately terminated, and the other rendering process is notified to start rendering. By detecting the rendering process in real time and sending real-time control instructions according to the current state of the rendering process, real-time control of the rendering process is achieved, thereby preventing the occurrence of abnormal rendering situations such as black screen and stuck frames due to reasons such as frequent data interaction between the CPU and GPU. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0035] Figure 1 It is a flow chart of a method for controlling a process of displaying a car instrument screen.

[0036] Figure 1A This is a flow chart of the optimization technical solution after improving step S2.

[0037] Figure 1B This is a flowchart of the heartbeat signal detection step of step S5.

[0038] Figure 2 It is the architecture diagram of the automobile instrument screen display process control system.

[0039] Figure 3 It is a structural diagram of an implementation method of an embodiment of the present invention in a specific application scenario.

[0040] Figure 4 It is the logical flow chart of the daemon process.

[0041] Figure 5 It is a structural diagram of an electronic device. DETAILED DESCRIPTION

[0042] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0043] like Figure 1 The automobile instrument screen display process control method shown is applied to automobile instrument screen display control, and includes:

[0044] Step S1, the operating system initializes and starts a daemon process, the daemon process is used to create and start a rendering process, the rendering process is specifically a 3D UI process and a basic UI process; in step S1, the 3D UI process is developed using a 3D engine, and is used to realize all 3D display functions of the automobile instrument, and its characteristics are slow startup speed, high resource consumption, and poor stability; the basic UI process is developed using a visualization application development framework such as QT, and is used to display key information to ensure driving safety;

[0045] Step S2, the daemon process receives health check data from the rendering process according to a preset heartbeat cycle. When the 3D UI process or the basic UI process starts to send heartbeat data, the daemon process determines that the rendering process has rendering capability and issues a rendering start instruction according to the priority strategy;

[0046] Step S3, the 3D UI process or the basic UI process receives a rendering start instruction and executes an operation corresponding to the rendering start instruction; exemplarily, the corresponding operation refers to executing rendering calculations and writing the results to a screen buffer, or: the process that receives a rendering stop instruction stops executing rendering calculations and writing to a screen buffer.

[0047] Step S4, detecting the correctness of the rendering process in real time. If it is detected that the health check data of one of the rendering processes is abnormal, the daemon process notifies another rendering process to start rendering and terminates the rendering process with the abnormality.

[0048] Steps S1 to S4 are a method for managing a 3D UI process and a basic UI process of a car instrument by using a daemon process:

[0049] During the initialization phase, the operating system first starts the daemon process, which is responsible for creating and starting two key rendering processes, namely the 3D UI process and the basic UI process. The 3D UI process uses the 3D engine to achieve comprehensive 3D display functions, while the basic UI process uses frameworks such as QT to display key driving safety information.

[0050] During the heartbeat monitoring phase, the daemon receives health check data from the two rendering processes according to the preset heartbeat cycle. Once the heartbeat data is received, the daemon determines whether the corresponding process has rendering capabilities and decides whether to issue a rendering start instruction based on the priority strategy.

[0051] In the rendering instruction execution phase, the rendering process that receives the rendering start instruction will perform rendering calculations and write the calculation results to the screen buffer to update the display content. If a rendering stop instruction is received, the corresponding process will stop rendering calculations and screen buffer writing.

[0052] During the exception handling phase, the vehicle operating system monitors the health status of the rendering process in real time. Once an abnormality is detected in the health check data of a rendering process, the daemon process will immediately notify another rendering process to start rendering and terminate the abnormal process.

[0053] Through the above-mentioned initialization stage, heartbeat monitoring stage, rendering instruction execution stage and exception handling stage, the implementation of steps S1 to S4 can ensure that when any rendering process fails, another process can immediately take over the rendering task, thereby avoiding display interruption, improving system reliability, having rapid response capabilities and resource optimization effects, improving system stability, and enhancing system flexibility.

[0054] Due to its fast startup speed and low resource consumption, the basic UI process can quickly provide key information display when the 3D UI process starts or fails, ensuring that the driver can obtain necessary driving information in a timely manner; the 3D UI process and the basic UI process use appropriate development frameworks and engines according to their characteristics and needs to achieve reasonable allocation and optimized use of resources; the daemon process can promptly discover and solve problems in the rendering process based on health checks and exception handling mechanisms, reduce the risk of system crashes, and improve overall stability. Through the flexible setting of priority strategies, the system can dynamically adjust the use of 3D UI processes or basic UI processes for rendering according to the current operating status and needs to adapt to different driving scenarios and conditions.

[0055] In summary, step S1 to step S4 achieves high reliability, fast response, resource optimization, improved stability and enhanced flexibility of the automobile instrument display through the designed process management and exception handling mechanism.

[0056] Preferably, further improvements can be made to step S4. In the optimization technical solution of step S4, the real-time detection of the correctness of the rendering process, if an abnormality is detected in the health check data of one of the rendering processes, the daemon process notifies another rendering process to start rendering, and terminates the rendering process with the abnormality, further comprising:

[0057] The daemon process notifies another rendering process to start rendering, terminates the rendering process with the exception, and recreates the rendering process with the exception.

[0058] Preferably, further improvements can be made to step S1 to form an optimized technical solution for step S1, wherein the operating system initializes and starts a daemon process, the daemon process is used to create and start a rendering process, the rendering process is specifically a 3D UI process and a basic UI process, and further includes: the 3D UI process and the basic UI process communicate with each other through shared memory;

[0059] After receiving the rendering start instruction from the daemon process, the 3D UI process and the basic UI process perform rendering calculations according to the preset rendering logic and write the calculation results to the screen buffer to ensure that only one rendering process performs rendering and writing operations at the same time.

[0060] Preferably, step S3 can be further improved: after receiving the rendering stop instruction from the daemon process, the 3D UI process and the basic UI process stop rendering calculation according to the preset rendering logic and stop writing the calculation results into the screen buffer.

[0061] like Figure 1A As shown, step S2 can be further improved to form an optimized technical solution for step S2: the daemon process receives health check data from the rendering process according to a preset heartbeat cycle. When the 3D UI process or the basic UI process starts to send heartbeat data, the daemon process determines that the rendering process has rendering capabilities, and issues a rendering start instruction according to the priority strategy, further including:

[0062] Step S21, detecting whether the rendering process sends heartbeat data according to preset conditions, if it is detected that the rendering process sends heartbeat data according to the preset conditions, the 3D UI process is started first;

[0063] Step S22: The daemon process detects the health check data of the rendering process in real time. If abnormal data is detected in the rendering process, the process with abnormal data is killed and restarted, or:

[0064] Step S23: If the daemon process does not receive the health check data of a certain rendering process, the daemon process kills the process that has not received the health check data and notifies another process to start rendering.

[0065] Kill process glossary:

[0066] Killing a Process is a computer term that refers to ending or terminating a running process. A process is an instance of a running program in a computer that can perform tasks, use system resources, and may interact with other processes.

[0067] Killing a process can be done in several ways:

[0068] Command line: In the command line interface (CLI), you can use specific commands (such as the kill command in Unix / Linux systems) to send signals to a process, requesting or forcing it to terminate.

[0069] Graphical User Interface (GUI): In an operating system's graphical user interface, you can usually select and end a process through a task manager (such as Windows' Task Manager).

[0070] Programming: In software development, programming interfaces (APIs) can be used to control the lifecycle of other processes, including ending them.

[0071] By improving the implementation example in a specific application scenario through the optimization technical solution provided by steps S21 to S23, the automobile instrument screen display process control method enhances the monitoring capability. By real-time detection of heartbeat data and health check data, the daemon process can more accurately understand the running status of each rendering process and achieve rapid exception response. Once an abnormality is detected, the daemon process can quickly take measures, such as terminating the abnormal process and restarting it, to minimize the impact of the abnormality on system operation.

[0072] The optimization technical solution provided by steps S21 to S23 ensures the flexibility of the priority strategy: by giving priority to starting the 3D UI process, the system can quickly respond to user needs while ensuring the display effect; improves the robustness of the system: by promptly terminating the unresponsive process and switching to the backup process, the system can maintain stable operation in the face of various abnormal situations; ensures the continuity of the car instrument screen display: even when a problem occurs in a rendering process, the system can switch to another process to ensure the continuity of the car instrument display and avoid information interruption.

[0073] In summary, the optimization technical solution provided in steps S21 to S23 improves the stability, reliability and response speed of the automobile instrument display system by strengthening the monitoring and exception handling capabilities of the daemon process, thereby ensuring driving safety and user experience.

[0074] like Figure 1B As shown, on the basis of steps S1 to S4, step S5 can also be included. Step S5 is a heartbeat signal detection step, and step S5 can be further optimized to form an optimized technical solution based on step S5: the heartbeat signal corresponds to the heartbeat cycle, and the heartbeat signal is sent according to the heartbeat cycle to indicate that the system, process or service is working normally.

[0075] Step S51, the daemon process receives a heartbeat signal from a rendering process, detects whether the heartbeat signal is normal, and if the heartbeat signal is correct, marks the state of the rendering process as available, wherein the rendering process includes a 3D UI process and / or a basic UI process;

[0076] Step S52: if the heartbeat signal of the rendering process (3D UI process and / or basic UI process) is lost, the rendering process that loses the heartbeat signal is counted to detect whether the number of lost heartbeat signals exceeds a preset threshold;

[0077] Step S53: if the number of lost heartbeat signals detected exceeds a preset threshold, restart the corresponding rendering process; or: if the number of lost heartbeat signals detected does not exceed the preset threshold, mark the available state of the corresponding rendering process as true.

[0078] Step S51 is used for heartbeat signal reception and status marking: the daemon process receives heartbeat signals from the 3D UI process and / or the basic UI process, and checks whether these signals are normal. If the heartbeat signal is normal, the daemon process marks the status of the corresponding rendering process as available, indicating that the rendering process can perform rendering tasks normally.

[0079] Step S52 is used for counting and detecting the loss of heartbeat signals: if the heartbeat signal of a rendering process is lost, the daemon process will count the heartbeat losses of the process and detect whether the number of losses exceeds a preset threshold.

[0080] Step S53 is used for responding to the heartbeat loss threshold: according to the count result of the heartbeat loss, the daemon process will take corresponding measures. If the number of heartbeat losses exceeds the preset threshold, the daemon process will restart the corresponding rendering process to restore its function. If the number of heartbeat losses does not exceed the threshold, the daemon process will keep the available state of the rendering process as true, allowing it to continue running.

[0081] Based on the optimization technical solution from step S51 to step S53, the self-repair capability of the system can be improved, the stability of the system can be enhanced, resource management can be optimized, and the user experience can be improved.

[0082] By monitoring the heartbeat signal and counting the loss, the daemon can automatically identify and respond to abnormal conditions in the rendering process, restart the abnormal process in time, and reduce system failure time. By setting preset thresholds, the system avoids frequent restarts of processes due to occasional heartbeat losses, thereby reducing unnecessary system interference and improving overall stability. By precisely controlling the restart of processes, the system can more effectively utilize computing resources and avoid resource waste caused by frequent restarts. By quickly responding to abnormalities in the rendering process and performing self-repair, the system ensures the continuity and accuracy of the car's instrument display, thereby improving the driver's user experience. By monitoring the heartbeat signal, the system can predict potential failures and take measures before they occur, improving the system's predictability and initiative.

[0083] In summary, the heartbeat monitoring mechanism provided by the optimization technical solution of step S51 to step S53 significantly improves the stability, reliability and user experience of the automobile instrument display system through precise signal detection and intelligent exception handling.

[0084] For the method steps disclosed in the above embodiments, the method steps are described as a series of action combinations for the purpose of simple description, but those skilled in the art should know that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0085] Any process or method description described in a flowchart or other manner may be understood as representing a module, fragment or portion of a code including one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations, in which the order shown or discussed may not be followed, including executing and implementing the functions in a substantially simultaneous manner or in a reverse order according to the functions involved, or executing computer instructions and implementing the corresponding functions according to program structures such as loops and branches, which can be naturally understood by those skilled in the art when implementing the embodiments of the present invention.

[0086] like Figure 2 The automobile instrument screen display process control system shown is used to implement the automobile instrument 3D display process control method, including:

[0087] The rendering process creates a startup module, the operating system initializes and starts a daemon process, the daemon process is used to create and start a rendering process, the rendering process is specifically a 3D UI process and a basic UI process;

[0088] A rendering start instruction processing module, in which a 3D UI process or a basic UI process receives a rendering start instruction and executes an operation corresponding to the rendering start instruction;

[0089] The rendering process correctness detection module detects the correctness of the rendering process in real time. If an abnormality is detected in the health check data of one of the rendering processes, the daemon process notifies the other rendering process to start rendering and terminates the rendering process with the abnormality.

[0090] The implementation methods of the system described above are merely illustrative, for example, the various functional modules, units or subsystems in the system may or may not be physically separated, or may or may not be physical units, that is, they may be located in the same place, or they may be distributed to multiple different systems and their subsystems or modules. Those skilled in the art may select some or all of the functional modules, units or subsystems according to actual needs to achieve the purpose of the embodiments of the present invention, and those of ordinary skill in the art may understand and implement the above-mentioned situations without creative work.

[0091] like Figure 3 and Figure 4 As shown, this embodiment consists of three units, including a daemon process, a 3D UI process, and a basic UI process. The specific processing flow is as follows:

[0092] At startup, the operating system is responsible for launching the daemon process, which is responsible for launching two rendering processes at the same time;

[0093] The 3D UI process is a 3D application developed using a 3D engine, covering all functions on the instrument side. It is characterized by slow startup speed, high resource consumption, and poor stability.

[0094] The basic UI process is an application developed using a visual application development framework such as QT. It only supports the display of some information to ensure driving safety. It has the characteristics of fast startup speed, low resource consumption, and good stability.

[0095] The processes use shared memory to establish communication. The two rendering processes maintain the ability to receive and process data. The rendering-related calculations and writing to the screen buffer of the two rendering processes are scheduled and started by the daemon process. Only one rendering process will perform rendering and write to the screen buffer at the same time.

[0096] The daemon receives health check data from the two applications according to the heartbeat cycle. When the rendering process starts heartbeating, the daemon considers that the rendering process has the rendering capability and issues the rendering start instruction according to the strategy of giving priority to the 3D process.

[0097] When a rendering process receives a rendering start signal, it starts rendering calculation and writing to the screen buffer. When a rendering process receives a rendering stop signal, it stops rendering calculation and writing to the screen buffer.

[0098] When the health check data of a rendering process is incorrect, the daemon process is responsible for notifying another process to start rendering, and then killing the abnormal process and restarting it;

[0099] When no health check data of the rendering process is received within several heartbeat cycles, the daemon process is responsible for notifying another process to start rendering, and kills the abnormal process and restarts it.

[0100] like Figure 5 As shown, the present invention not only provides a method and system for controlling the display process of an automobile instrument screen, but also provides a corresponding intelligent cockpit, electronic equipment and storage medium:

[0101] A smart cockpit, characterized in that the smart cockpit is provided with the automobile instrument screen display process control system according to claim 7, and executes the automobile instrument screen display process control method.

[0102] An electronic device comprises: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of a method for controlling a process of displaying a car instrument screen.

[0103] A computer-readable storage medium stores a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of a method for controlling a vehicle instrument screen display process.

[0104] Figure 5 7 is a schematic diagram of a structure of an electronic device provided in an embodiment of the present invention. The electronic device provided in an embodiment of the present invention includes: one or more processors 710 and a storage device 720; the processor 710 in the electronic device may be one or more, Figure 5 A processor 710 is taken as an example; the storage device 720 is used to store one or more programs; the one or more programs are executed by the one or more processors 710, so that the one or more processors 710 implement the automobile instrument screen display process control method as described in any one of the embodiments of the present invention.

[0105] The electronic device may further include: an input device 730 and an output device 740 .

[0106] Case No.: FAW040701-C-XCN1240557 13

[0107] The processor 710, storage device 720, input device 730 and output device 740 in the electronic device can be connected via a bus or other means. Figure 5 The example of connecting through bus is taken in the following.

[0108] The storage device 720 in the electronic device is a computer-readable storage medium that can be used to store one or more programs, which can be software programs, computer executable programs and modules, such as the program instructions / modules corresponding to the automobile instrument screen display process control method provided in the embodiment of the present invention. The processor 710 executes various functional applications and data processing of the electronic device by running the software programs, instructions and modules stored in the storage device 720, that is, the automobile instrument screen display process control method in the above method embodiment is implemented.

[0109] The storage device 720 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the storage device 720 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the storage device 720 may further include a memory remotely arranged relative to the processor 710, and these remote memories may be connected to the device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0110] The input device 730 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the electronic device. The output device 740 may include a display device such as a display screen.

[0111] Furthermore, when one or more programs included in the electronic device are executed by the one or more processors 710, the program executes all instructions from step S1 to step S4.

[0112] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0113] Case No.: FAW040701-C-XCN1240557 14

[0114] In addition, those skilled in the art will appreciate that, although some embodiments described herein include certain features included in other embodiments but not other features, the combination of features of different embodiments is meant to be within the scope of the present invention and form different embodiments. For example, any one of the embodiments claimed in the claims can be used in any combination in the embodiments of the present invention.

[0115] In the description of this specification, the description with reference to the terms "one embodiment", "example", "specific example", etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0116] In addition, the technical solutions between the various embodiments of the present invention can be combined with each other, but it must be based on the fact that ordinary technicians in the field can implement it. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0117] All features disclosed in this specification, or steps in all methods or processes disclosed, except mutually exclusive features and / or steps, can be combined in any way. Any feature disclosed in this specification, unless otherwise stated, can be replaced by other equivalent or alternative features with similar purposes. That is, unless otherwise stated, each feature is only an example of a series of equivalent or similar features. Throughout the specification, the same reference numerals indicate the same elements.

[0118] Those skilled in the art will appreciate that the modules in the device in the embodiment can be adaptively changed and set in one or more devices different from the embodiment. The modules or units or components in the embodiment can be combined into one module or unit or component, and furthermore they can be divided into multiple sub-modules or sub-units or sub-components. All features disclosed in this specification (including corresponding claims, abstracts and drawings) and any method or device disclosed in this manner can be used in any combination, except that at least some of such features and / or processes or units are mutually exclusive.

[0119] Unless explicitly stated otherwise, each feature disclosed in this specification (including corresponding claims, abstract and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0120] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for controlling the display process of an automobile instrument screen, applied to an automobile instrument screen display control system, characterized in that: include: The operating system initializes and starts a daemon process, wherein the daemon process is used to create and start a rendering process, wherein the rendering process is specifically a 3D UI process and a basic UI process; The daemon process receives health check data from the rendering process according to the preset heartbeat cycle. When the 3D UI process or the basic UI process starts to send heartbeat data, the daemon process determines that the rendering process has rendering capabilities and issues a rendering start instruction according to the priority strategy; The 3D UI process or the basic UI process receives a rendering start instruction and executes an operation corresponding to the rendering start instruction; The correctness of the rendering process is detected in real time. If an abnormality is detected in the health check data of one of the rendering processes, the daemon process notifies the other rendering process to start rendering and terminates the rendering process with the abnormality.

2. The automobile instrument screen display process control method according to claim 1, characterized in that: The real-time detection of the correctness of the rendering process, if it is detected that the health check data of one of the rendering processes is abnormal, the daemon process notifies another rendering process to start rendering, and terminates the rendering process with the abnormality, further includes: The daemon process notifies another rendering process to start rendering, terminates the rendering process with the exception, and recreates the rendering process with the exception.

3. The automobile instrument screen display process control method according to claim 1, characterized in that: The operating system initializes and starts a daemon process, the daemon process is used to create and start a rendering process, the rendering process is specifically a 3D UI process and a basic UI process, further comprising: the 3D UI process and the basic UI process communicate through shared memory; After receiving the rendering start instruction from the daemon process, the 3D UI process and the basic UI process perform rendering calculations according to the preset rendering logic and write the calculation results into the screen buffer.

4. The automobile instrument screen display process control method according to claim 3 is characterized in that: After receiving the rendering stop instruction from the daemon process, the 3D UI process and the basic UI process stop rendering calculation according to the preset rendering logic and stop writing the calculation results to the screen buffer.

5. The automobile instrument screen display process control method according to claim 1, characterized in that: The daemon process receives health check data from the rendering process according to a preset heartbeat cycle. When the 3D UI process or the basic UI process starts to send heartbeat data, the daemon process determines that the rendering process has rendering capability, and issues a rendering start instruction according to a priority strategy, further comprising: Detect whether the rendering process sends heartbeat data according to the preset conditions. If it is detected that the rendering process sends heartbeat data according to the preset conditions, the 3D UI process is started first; The daemon process detects the health check data of the rendering process in real time. If abnormal data is detected in the rendering process, the process with abnormal data is killed and restarted, or: The daemon process does not receive the health check data of a rendering process. The daemon process kills the process that did not receive the health check data and notifies another process to start rendering.

6. The automobile instrument screen display process control method according to claim 1, characterized in that: It also includes the heartbeat signal detection step: The daemon process receives the heartbeat signal from the rendering process and detects whether the heartbeat signal is normal. If the heartbeat signal is correct, the status of the rendering process is marked as available; If the heartbeat signal of the rendering process is lost, the rendering processes that have lost the heartbeat signal are counted to detect whether the number of heartbeat signal losses exceeds a preset threshold; If the number of lost detection heartbeat signals exceeds a preset threshold, the corresponding rendering process is restarted, or: if the number of lost detection heartbeat signals does not exceed the preset threshold, the available state of the corresponding rendering process is marked as true.

7. A vehicle instrument screen display process control system, used to implement the vehicle instrument 3D display process control method according to any one of claims 1 to 6, characterized in that: include: The rendering process creates a startup module, the operating system initializes and starts a daemon process, the daemon process is used to create and start a rendering process, the rendering process is specifically a 3D UI process and a basic UI process; A rendering start instruction processing module, in which a 3D UI process or a basic UI process receives a rendering start instruction and executes an operation corresponding to the rendering start instruction; The rendering process correctness detection module detects the correctness of the rendering process in real time. If an abnormality is detected in the health check data of one of the rendering processes, the daemon process notifies the other rendering process to start rendering and terminates the rendering process with the abnormality.

8. A smart cockpit, characterized in that: The smart cockpit is provided with the automobile instrument screen display process control system according to claim 7, and executes the automobile instrument screen display process control method according to any one of claims 1 to 6.

9. An electronic device, characterized in that: include: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the method described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: It stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the method described in any one of claims 1 to 6.

Images