Control method and device of car machine system, electronic equipment and storage medium

Abstract

The present disclosure provides a control method and device of an in-vehicle infotainment system, electronic equipment and a storage medium. The control method of the in-vehicle infotainment system comprises: sending rendering data to a graphics processor at a preset frequency in a first running state to render a user interface; in response to receiving an instruction to start a second running state, archiving current rendering data in the graphics processor; and controlling the in-vehicle infotainment system to enter the second running state; wherein the first running state comprises a high-power consumption state or a running state; and the second running state comprises a low-power consumption state or a hibernation state.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle control technology, and in particular to a control method, device, electronic equipment and storage medium for a vehicle infotainment system. Background Technology

[0002] As the level of intelligence in automobiles continues to increase, the display technology of automotive instrument systems is gradually upgrading from static graphic displays to dynamic graphic displays. For example, the QNX (Quick UNIX) system, used as the real-time operating system for automotive instrument systems, has a microkernel architecture that ensures system stability, while also featuring fast data acquisition, fast refresh rate, and high display efficiency, thus well meeting the various needs of automotive instrument systems.

[0003] Currently, to reduce vehicle power consumption, in some scenarios, the in-vehicle infotainment system switches to a low-power mode when not in use. When exiting low-power mode, the in-vehicle infotainment system can boot up quickly without a cold start, thus reducing the user's anxiety about waiting for the system to boot up.

[0004] However, when the vehicle's infotainment system exits low-power mode and resumes operation, the instrument cluster often experiences a series of serious problems such as black screens and distorted screens, which can only be resolved by restarting the infotainment system, resulting in long startup times and severely impacting the user experience. Summary of the Invention

[0005] One objective of this disclosure is to provide a control method, device, electronic device, and storage medium for a vehicle infotainment system. By pre-loading the current rendering data in the GPU before entering a low-power state, the system can quickly and completely display the instrument panel content after waking up, eliminating the need to perform the resource loading process during cold start. This allows the vehicle to quickly enter a usable state, thereby improving the user experience.

[0006] Another objective of this disclosure is to provide a control method, device, electronic device, and storage medium for an in-vehicle infotainment system. The instrument system can use the QNX real-time operating system to achieve dynamic graphics display and achieve high-quality data processing and graphics rendering by leveraging the powerful computing power of the GPU. In addition, the GPU can further improve rendering performance by utilizing hardware-accelerated algorithms, thereby enhancing the user experience.

[0007] To achieve the above objectives, a first aspect of this disclosure provides a control method for a vehicle infotainment system, which may include: sending rendering data to a graphics processor at a preset frequency in a first operating state to render a user interface; in response to receiving an instruction to start a second operating state, storing the current rendering data in the graphics processor; and controlling the vehicle infotainment system to enter the second operating state; wherein the first operating state includes a high-power state or an operating state; and the second operating state includes a low-power state or a sleep state.

[0008] In some exemplary embodiments, the above method may further include: in response to detecting that a preset sleep condition is met, initiating an instruction to start a second operating state; and in response to detecting that a preset wake-up condition is met, initiating an instruction to end the second operating state and controlling the vehicle system to restore the first operating state.

[0009] In some exemplary embodiments, rendering the user interface may include: calling the rendering thread based on the configuration function interface of the graphics engine; the rendering thread generating a rendered image of the user interface based on the rendering data in the graphics processor; wherein the rendering data includes user interface (UI) logic and / or UI data.

[0010] In some exemplary implementations, pre-loading the current rendering data in the graphics processor may include: pre-loading the current rendering data in the graphics processor by using an overridable function interface based on the graphics engine, by skipping the call to the rendering thread.

[0011] In some exemplary embodiments, preserving the current rendering data in the graphics processor may include: backing up the current rendering data in the graphics processor; the method may also include: in response to receiving an instruction to end the second running state, rendering the user interface based on the backed-up rendering data.

[0012] In some exemplary embodiments, the above method may further include: updating the rendering data according to the received vehicle status change information in the first operating state; wherein the vehicle status change information includes at least one of the following: vehicle speed change information, steering information, battery level change information, and warning light change information.

[0013] In some exemplary embodiments, the above method may further include: displaying the generated rendered image on the instrument interface of the instrument system.

[0014] Secondly, embodiments of this disclosure provide a control device for a vehicle infotainment system, which may include: a user interface rendering module connected to a graphics processor, the user interface rendering module being configured to: send rendering data to the graphics processor at a preset frequency in a first operating state to render the user interface; and, in response to receiving an instruction to start a second operating state, store the current rendering data in the graphics processor; and an operation control module configured to: in the first operating state, in response to receiving an instruction to start a second operating state, control the vehicle infotainment system to enter a second operating state; wherein the first operating state includes a high power consumption state or an operating state; and the second operating state includes a low power consumption state or a sleep state.

[0015] In some exemplary embodiments, the user interface rendering module may include a preprocessing unit, an interface calling unit, and a rendering unit. The preprocessing unit is configured to load rendering-related resources and configuration information and send rendering data to the graphics processor. The interface calling unit is configured to call the rendering unit based on the configuration function interface of the graphics engine. The rendering unit is configured to generate a rendered screen of the user interface based on the rendering data in the graphics processor in a first running state. The rendering data includes user interface (UI) logic and / or UI data.

[0016] Thirdly, embodiments of this disclosure provide an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the control method of the vehicle system as described in either the first or second aspect.

[0017] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer, when executed, to implement a control method for a vehicle system as described in any implementation of the first aspect.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0019] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0020] Figure 1 This is an exemplary system architecture to which this disclosure can be applied;

[0021] Figure 2A flowchart of a control method for a vehicle infotainment system provided in this embodiment of the present disclosure;

[0022] Figure 3 A flowchart illustrating another control method for a vehicle infotainment system provided in this embodiment of the present disclosure;

[0023] Figure 4 A structural block diagram of a control device for a vehicle infotainment system provided in an embodiment of this disclosure;

[0024] Figure 5 This is a schematic diagram of the structure of an electronic device suitable for executing a control method for a vehicle infotainment system, provided as an embodiment of the present disclosure. Detailed Implementation

[0025] To better understand this application, various aspects of this application will be described in more detail with reference to the accompanying drawings. It should be understood that these detailed descriptions are merely illustrative of exemplary embodiments of this application and are not intended to limit the scope of this application in any way. Furthermore, for clarity and conciseness, descriptions of features well-known in the art may be omitted.

[0026] Throughout the accompanying drawings and detailed embodiments, the same reference numerals refer to the same elements. For purposes of clarity, illustration, and convenience, the drawings may not be drawn to scale, and the relative dimensions, scale, and depiction of elements in the drawings may be exaggerated.

[0027] It should be noted that the acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0028] It should also be understood that the terms "comprising," "including," "having," "containing," and / or "comprising," when used in this specification, indicate the presence of the stated features, integrals, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Furthermore, when expressions such as "at least one of..." appear after a list of listed features, they modify the entire listed feature, not individual elements in the list. Additionally, when describing embodiments of this application, the word "may" is used to mean "one or more embodiments of this application." And the term "exemplary" is intended to refer to an example or illustration.

[0029] Unless otherwise specified, all terms used herein (including engineering and technical terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that, unless expressly stated herein, terms defined in common dictionaries shall be interpreted as having the meaning consistent with their meaning in the context of the relevant art, and not as having an idealized or overly formalized meaning.

[0030] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. Furthermore, unless explicitly limited or contradicted by the context, the specific steps included in the methods described in this application are not limited to the order in which they are described, but can be performed in any order or in parallel. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0031] In recent years, automobiles have been continuously evolving towards intelligentization. An intelligent cockpit is an integrated digital platform within the vehicle, combining various information technologies and artificial intelligence, designed to provide passengers with an intelligent experience and enhance driving safety. Currently, the main control system of intelligent cockpits generally adopts a multi-core heterogeneous architecture design. Commonly, the central control operating system of the vehicle's infotainment system mostly uses the Android system, the in-vehicle infotainment system is developed based on a System-on-Chip (SoC), and the instrument cluster system uses the QNX operating system. In this article, the term "vehicle system" or "system" generally refers to the vehicle's control system, but can also refer to the collective term for all electronic systems within the vehicle, which may include hardware and / or software systems.

[0032] As intelligent cockpit systems become more diverse and their hardware and software systems increasingly complex and large, system boot times are also increasing. To address this issue, the industry has introduced STR (Suspend to RAM) technology. If the vehicle is not used for an extended period, such as after locking the car for a while, the system enters a low-power STR state, which keeps the vehicle's infotainment system powered continuously. When the user needs to use the vehicle, the system can quickly power on and resume operation without restarting, achieving a so-called "warm start." When the system enters STR state, most of the power supply to the main chip, controller, peripherals, etc., is turned off, and the SOC's internal bus clock is reduced to its lowest operating frequency, with only the RAM (memory) in self-refresh mode.

[0033] However, in practical applications, the following problems exist during the process of the vehicle's infotainment system waking up from STR (Signal Activated State) and returning to running state: the instrument panel display frequently experiences black screens or distorted images, failing to display correctly and directly impacting the user experience. Currently, there is no corresponding solution to this problem; the only solution is to restart the system. However, restarting the system means performing a cold start, resulting in a longer boot time, which also affects the user experience and defeats the purpose of using the STR function to enable rapid system startup.

[0034] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the control methods, apparatus, electronic devices, and computer-readable storage media of the vehicle infotainment system to which the present disclosure can be applied are illustrated.

[0035] like Figure 1 As shown, system architecture 100 may include an MCU (Micro Controller Unit) 101, an in-vehicle infotainment system 102, an instrument cluster system 103, and a GPU (Graphics Processing Unit) 104, etc. It should be understood that system architecture 100 may also include other modules or units such as a CAN (Controller Area Network) bus, a power supply module, and a sensing module.

[0036] The microcontroller unit 101 is the main control module of the vehicle, containing essential components such as a processor, memory (RAM), and input / output interfaces. It can handle tasks such as timing, initiating sleep requests, and power switch control. The in-vehicle infotainment system 102 is responsible for multimedia, navigation, and communication functions, displaying multimedia playback, navigation, and reversing camera information on the central control display screen. The instrument cluster system 103 can be a full LCD screen, used to display basic information such as vehicle speed, coolant temperature, and indicator lights, as well as information such as location navigation or media information. The in-vehicle infotainment system 101, instrument cluster system 103, and graphics processor 104 can all communicate with the MCU 101.

[0037] As an exemplary implementation, the in-vehicle infotainment system 102 of system architecture 100 adopts the Android system. The instrument cluster system adopts the QNX operating system, which runs on the chip and can be used to provide a hypervisor virtual process. This system architecture can realize the construction of a QNX instrument cluster system + Android in-vehicle infotainment system.

[0038] The control methods for the vehicle infotainment system provided in the subsequent embodiments of this disclosure are generally executed by the instrument system 103 and / or the microcontroller unit 101. Correspondingly, the control device for the vehicle infotainment system is also generally located in the instrument system 103 and / or the microcontroller unit 101.

[0039] Please refer to Figure 2 , Figure 2 The flowchart 200 of one embodiment of the control method for a vehicle infotainment system according to the present disclosure is shown. The flowchart 200 may include the following steps:

[0040] Step S201: In the first running state, the rendering data is sent to the graphics processor at a preset frequency to render the user interface.

[0041] This step is intended for the execution body of the vehicle system's control method (e.g., Figure 1 The instrument system 103 (or other devices) shown in the diagram renders the user interface using a graphics processing unit (GPU) when the vehicle infotainment system is in its first operating state. This first operating state can be either a normal operating state or a high-power state.

[0042] Under normal operating conditions, the execution entity will send rendering data to the GPU at a preset frequency, and use the GPU to implement the graphical rendering of the user interface.

[0043] Compared to traditional instrument panels that simply modify vehicle operating parameters using stored static images, fully digital instrument panels can display dynamic information such as real-time changes in vehicle speed and RPM, or navigation and positioning. This requires rendering of graphic data. Storing and rendering resource files within the instrument panel system or QNX system necessitates high-performance hardware resources.

[0044] Instrumentation systems typically utilize GPUs for graphics rendering. The advantage of GPU rendering lies in its powerful computing capabilities, enabling efficient completion of graphics rendering tasks and achieving high-quality data processing and graphics rendering. Furthermore, GPUs can leverage hardware-accelerated algorithms, such as rasterization and shaders, to further enhance rendering performance. Overall, the GPU acts as the graphics rendering processor, writing the results of graphics processing into system memory or video memory address space. Video memory is a dedicated high-speed storage space for the GPU, used to temporarily store image data being processed or about to be displayed on the screen. All graphics data, including vertex information, textures, and color buffers (frame buffers), is loaded into video memory for direct GPU access.

[0045] Step S202: In response to receiving an instruction to start the second running state, the current rendering data in the graphics processor is archived.

[0046] This step addresses the issue of screen content loading failures that often occur when the vehicle infotainment system exits a low-power state (e.g., STR state). Upon receiving the instruction to initiate the second operating state, the current rendering data in the GPU will be archived. This effectively ensures the correctness of the graphics data when the vehicle infotainment system exits the low-power state. The second operating state can be either a low-power state or a sleep state.

[0047] Step S203: Control the vehicle system to enter the second operating state.

[0048] Based on step S202, the aforementioned execution entity archives the rendering data in the GPU and then controls the vehicle system to enter the second operating state (e.g., STR state).

[0049] In this embodiment, before step S201, the following step may be included: in response to detecting that a preset sleep condition is met, an instruction to start the second operating state is initiated. The preset sleep condition may, for example, include locking the vehicle for a period of time, or the system not operating for a period of time, in which case the system will determine to enter the low-power STR state.

[0050] In this embodiment, after the execution entity enters the STR state according to the method described above, it may further include the following steps: in response to receiving a preset wake-up condition, initiating an instruction to end the second operating state, and controlling the vehicle system to restore the first operating state. The preset wake-up condition may include, for example, an interrupt signal or a wake-up event.

[0051] The vehicle infotainment system control method provided in this embodiment, before controlling the vehicle infotainment system to enter the second operating state (e.g., STR state), seals the current rendering data in the GPU to ensure the consistency and integrity of the rendering data in the GPU. In this way, the correctness of the graphics data loaded when exiting the STR state and restarting can be guaranteed, so that it can be displayed normally on the instrument system display screen. This avoids the problem of screen distortion or black screen caused by inconsistent graphics data, which requires restarting the system, thereby improving the success rate of screen rendering and enhancing the user experience.

[0052] Continue to refer to Figure 3 , Figure 3 A flow 300 of another embodiment of the control method for a vehicle infotainment system according to the present disclosure is shown. This flow 300 may include the following steps:

[0053] Step 301: Cold start.

[0054] When the vehicle's infotainment system is powered on or restarted, a cold start process will begin.

[0055] Step 302: Initialize program configuration.

[0056] After the system starts, it performs initialization program configuration, such as detecting interfaces and initializing memory, bus, clock and other related configurations.

[0057] Step 303: Load program resources.

[0058] After the initialization program is configured, it loads some program resources necessary for running the kernel.

[0059] Step 304: Enter running state.

[0060] After completing the initialization program configuration and loading program resources, the vehicle system enters the running state.

[0061] Step 305: Receive / update rendering data.

[0062] When in operation, the vehicle's infotainment system can receive (or collect) rendering data in real time via the communication interface. This rendering data includes data or information needed to render the user interface, such as vehicle operating parameters or warning signals, and may also include UI (User Interface) logic, UI parameters, or data models.

[0063] Furthermore, the vehicle infotainment system can update the rendered data based on received information about changes in vehicle status. For example, upon receiving information about changes in vehicle speed, steering, battery level, or warning lights from the underlying system, the corresponding rendered data will be updated.

[0064] Step 306: If an instruction to enter the STR state is received, proceed to step 308; otherwise, continue with step 307.

[0065] Step 307: Render the user interface.

[0066] Under normal operating conditions, the vehicle infotainment system sends rendering data to the GPU at a preset frequency (e.g., frame refresh rate or a frequency matching the frame refresh rate) for user interface rendering. For example, the GPU performs rasterization, texture mapping, color / layer blending, and other processing on the received rendering data to generate image frames and place them in a frame buffer for the instrument cluster system to read. By reading the image frames in the frame buffer, static images or dynamic displays can be shown on the instrument cluster screen.

[0067] As an exemplary implementation, in this embodiment, the instrument system adopts the QNX system, and the step of rendering the user interface may include the following sub-steps:

[0068] Step 3071: Call the rendering thread based on the configuration function interface of the graphics engine;

[0069] Step 3072: The rendering thread generates a rendered user interface based on the rendering data in the GPU;

[0070] Step 3073: Display the generated rendered image on the instrument interface of the instrument system.

[0071] The graphics engine can be, for example, the Kanzi engine, or Unity or other HMI (Human Machine Interface) graphics engines. The rendering thread can be, for example, the Render thread, or other threads used for UI drawing and rendering. This application does not impose specific restrictions on the graphics engine and rendering thread used.

[0072] Step 308: When an instruction to enter the STR state is received, skip the rendering thread call.

[0073] As described in the preceding steps, the UI rendering screen can be generated by calling the rendering thread through the configuration function interface while in runtime. However, if the rendering data is updated during the process of the vehicle system entering the STR state, the rendering thread will still perform rendering operations based on the updated rendering data. This operation will modify the current rendering data in the GPU. Since the temporary data cached in the GPU is not stored in the STR state, the inconsistent rendering data may cause the rendering screen to fail to load when exiting the STR state and resuming the runtime state.

[0074] To address this issue, this embodiment utilizes the graphics engine's rewriteable function interface to skip the rendering thread's calls, thereby preserving the current rendering data in the GPU.

[0075] In addition, in other embodiments of this disclosure, the current rendering data can be preserved by backing up the data in the GPU. For example, the data in the GPU's video memory and cache can be backed up before the GPU goes into sleep mode. This way, when the STR state is terminated and the GPU exits the STR state, the user interface can continue to be rendered based on the backed-up rendering data, thus ensuring the integrity and consistency of the rendering data.

[0076] Step 309: Enter STR state.

[0077] After skipping the rendering thread call, the vehicle infotainment system enters the STR state.

[0078] Step 310: When an instruction to exit the STR state is received, proceed to step 304.

[0079] Based on the preset wake-up event, a command to exit the STR state will be initiated, controlling the vehicle system to resume operation.

[0080] The vehicle system control method provided in this embodiment of the present disclosure saves the current rendering data in the GPU by skipping the rendering process call or backing up the rendering data before entering the STR state. This allows the system to quickly and completely display the instrument screen content after waking up, without having to execute the resource loading process during cold start. This allows the vehicle to quickly enter a usable state, thereby improving the user experience.

[0081] Further reference Figure 4 As an implementation of the methods in the above embodiments, this disclosure provides an embodiment of a control device for a vehicle infotainment system.

[0082] like Figure 4 As shown, the control device 400 of the vehicle system in this embodiment may include a user interface rendering module 410 and a running control module 420. The user interface rendering module 410 is connected to a GPU and is configured to send rendering data to the GPU at a preset frequency in a first running state to render the user interface; and, in response to receiving an instruction to start a second running state, to archive the current rendering data in the GPU. The running control module 420 is configured to, in the first running state, control the vehicle system to enter a second running state in response to receiving an instruction to start a second running state. The first running state may include a high-power state or a running state; the second running state may include a low-power state (e.g., STR state) or a sleep state.

[0083] refer to Figure 4 In some optional implementations of this embodiment, the user interface rendering module 410 may further include a preprocessing unit, an interface calling unit, and a rendering unit. The preprocessing unit is configured to load rendering-related resources and configuration information, and send the rendering data to the GPU. The interface calling unit is configured to call the rendering unit based on the graphics engine's configuration function interface. The rendering unit is configured to generate a rendered user interface based on the rendering data in the GPU in a first operating state. The rendering data includes at least UI logic and / or UI data. For example, the user interface rendering module 410 may be installed in an instrumentation system, for example, using the QNX real-time operating system.

[0084] In some optional implementations of this embodiment, the interface calling unit is further configured as a rewriteable function interface based on the graphics engine, which can save the current rendering data in the GPU by skipping the call to the rendering thread.

[0085] In some optional implementations of this embodiment, the operation control module 420 is further configured to control the vehicle system to resume the first operation state in response to receiving an instruction to end the second operation state. For example, the operation control module 420 may be located in the MCU.

[0086] In some optional implementations of this embodiment, the operation control module 420 is further configured to, upon receiving an instruction to start the second operation state, back up the current rendering data in the GPU to save the current rendering data in the GPU; and upon receiving an instruction to end the second operation state, provide the backed-up rendering data to the rendering unit so as to render the user interface based on the backed-up rendering data.

[0087] In some optional implementations of this embodiment, the preprocessing unit is further configured to update the rendering data based on the received vehicle status change information in the first operating state. The vehicle status change information may include at least one of the following: vehicle speed change information, steering information, battery level change information, warning light change information, etc.

[0088] In this embodiment, other features of the user interface rendering module 410 and the operation control module 420 in the vehicle system control device 400, and their resulting technical effects, can be found by referring to [reference needed]. Figure 2 Steps S201-S203 in the corresponding embodiment and Figure 3 The relevant descriptions of steps 304-310 in the corresponding embodiments will not be repeated here.

[0089] This embodiment exists as a device embodiment corresponding to the above method embodiment. Before the vehicle system control device provided in this embodiment controls the vehicle system to enter the second operating state (e.g., STR state), it seals the current rendering data in the GPU to ensure the consistency and integrity of the rendering data in the GPU. In this way, the correctness of the graphics data loaded when exiting the STR state and restarting can be guaranteed, so that it can be displayed normally on the instrument system display screen, thereby improving the success rate of screen rendering and enhancing the user experience.

[0090] According to embodiments of this disclosure, this disclosure also provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to implement the control method of the vehicle system described in any of the above embodiments.

[0091] According to embodiments of this disclosure, this disclosure also provides a readable storage medium storing computer instructions that, when executed by a computer, enable the control method of the vehicle system described in any of the above embodiments.

[0092] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0093] like Figure 5 As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 502 or a computer program loaded from storage unit 508 into random access memory (RAM) 503. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0094] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0095] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the control methods of a vehicle infotainment system. For example, in some embodiments, the control methods of a vehicle infotainment system may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the control methods of the vehicle infotainment system described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the control methods of the vehicle infotainment system by any other suitable means (e.g., by means of firmware).

[0096] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0097] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0098] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0099] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0100] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0101] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0102] According to the technical solution of this disclosure, upon receiving an instruction to enter a second operating state (e.g., STR state), the currently rendered data in the GPU can be archived to ensure the consistency and integrity of the rendered data in the GPU before the vehicle system is controlled to enter the second operating state. This ensures the correctness of the graphics data loaded upon exiting the STR state and restarting, allowing it to be displayed correctly on the instrument panel screen, thereby improving the success rate of image rendering and enhancing the user experience.

[0103] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0104] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A control method for a vehicle infotainment system, characterized in that, include: In the first running state, rendering data is sent to the graphics processor at a preset frequency to render the user interface; In response to receiving an instruction to start the second running state, the current rendering data in the graphics processor is archived; as well as Control the vehicle system to enter the second operating state; The first operating state includes a high-power state or an operating state; the second operating state includes a low-power state or a sleep state.

2. The method according to claim 1, wherein, The method further includes: In response to detecting that a preset hibernation condition is met, the command to start the second operating state is initiated; and In response to the detection that a preset wake-up condition is met, an instruction is issued to end the second operating state, and the vehicle system is controlled to resume the first operating state.

3. The method according to claim 2, wherein, The rendering of the user interface includes: The configuration function interface based on the graphics engine calls the rendering thread; The rendering thread generates a rendered image of the user interface based on the rendering data in the graphics processor; The rendering data includes user interface (UI) logic and / or UI data.

4. The method according to claim 3, wherein, The step of saving the current rendering data in the graphics processor includes: Based on the rewriteable function interface of the graphics engine, the current rendering data in the graphics processor is archived by skipping the call to the rendering thread.

5. The method according to claim 3, wherein, The step of sealing the current rendering data in the graphics processor includes: backing up the current rendering data in the graphics processor; The method further includes: In response to receiving the instruction to end the second running state, the user interface is rendered according to the backed-up rendering data.

6. The method according to any one of claims 1-5, wherein, The method further includes: In the first operating state, the rendering data is updated according to the received vehicle status change information; The vehicle status change information includes at least one of the following: vehicle speed change information, steering information, battery level change information, and warning light change information.

7. The method according to claim 6, wherein, The method further includes: The generated rendered image is displayed on the instrument interface of the instrument system.

8. A control device for a vehicle infotainment system, characterized in that, include: A user interface rendering module, connected to a graphics processor, is configured to: in a first operating state, send rendering data to the graphics processor at a preset frequency to render the user interface; and, in response to receiving an instruction to start a second operating state, archive the current rendering data in the graphics processor. The operation control module is configured to: in the first operating state, in response to receiving an instruction to start the second operating state, control the vehicle system to enter the second operating state; The first operating state includes a high-power state or an operating state; the second operating state includes a low-power state or a sleep state.

9. The apparatus according to claim 8, wherein, The user interface rendering module includes a preprocessing unit, an interface call unit, and a rendering unit. The preprocessing unit is configured to load rendering-related resources and configuration information, and send the rendering data to the graphics processor; The interface calling unit is configured to call the rendering unit based on the configuration function interface of the graphics engine; The rendering unit is configured to generate a rendered image of the user interface based on the rendering data in the graphics processor in the first operating state; wherein the rendering data includes user interface (UI) logic and / or UI data.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

11. A computer-readable storage medium having stored thereon machine-executable instructions, which, when executed, cause a machine to perform the method of any one of claims 1 to 7.

Images