Abnormality processing method and device for in-vehicle infotainment system and vehicle

Abstract

The application provides an abnormality processing method and device for a vehicle information entertainment system and a vehicle. The abnormality processing method for the vehicle information entertainment system comprises the following steps: acquiring an operation parameter of the vehicle information entertainment system; judging whether the operation parameter is abnormal, and if yes, acquiring a preset abnormality processing strategy; and performing abnormality processing on the vehicle information entertainment system according to the preset abnormality processing strategy. The abnormality processing method for the vehicle information entertainment system judges whether the vehicle information entertainment system is abnormal through the operation parameter, reads the preset abnormality processing strategy when the vehicle information entertainment system is abnormal, and thus solves or at least alleviates problems caused by the abnormality.

Description

Technical Field

[0001] This application belongs to the technical field of in-vehicle infotainment systems, and specifically relates to an exception handling method, an exception handling device, an in-vehicle infotainment system, and a vehicle. Background Technology

[0002] The automotive industry is currently moving towards intelligentization, and the functions and application scenarios of automobiles are becoming increasingly complex. After the car cabin has evolved into a connected form, the richness of cabin functions and content has been greatly improved, and the user experience is approaching or even beginning to surpass that of smartphones. However, due to the introduction of diversified functions of in-vehicle infotainment, higher requirements have been placed on system stability and security.

[0003] In existing technologies, in-vehicle infotainment systems can only record image data using cameras. When the processing performance of captured image data degrades, they cannot directly handle abnormal problems.

[0004] Therefore, it is desirable to have a technical solution to overcome or at least mitigate one of the aforementioned defects of the prior art. Summary of the Invention

[0005] The purpose of this application is to provide an exception handling method for an in-vehicle infotainment system to solve at least one of the problems mentioned above.

[0006] In a first aspect of this application, an exception handling method for an in-vehicle infotainment system is provided, the exception handling method for an in-vehicle infotainment system comprising:

[0007] Obtain the operating parameters of the in-vehicle infotainment system;

[0008] Determine if the operating parameters are abnormal; if so, then...

[0009] Obtain the preset exception handling strategy;

[0010] The in-vehicle infotainment system is subjected to anomaly handling according to the preset anomaly handling strategy.

[0011] Optionally, the operating parameters include one of the following:

[0012] Operating parameters of the in-vehicle entertainment system, Android startup status parameters, memory usage parameters, CPU usage parameters, and key process operating parameters;

[0013] The determination of whether the operating parameters are abnormal includes one of the following:

[0014] Determine whether the operating parameters of the in-vehicle entertainment system are abnormal, whether the Android startup status parameters are abnormal, whether the memory usage parameters are abnormal, whether the CPU usage parameters are abnormal, and whether the operating parameters of key processes are abnormal.

[0015] The preset exception handling strategy includes one of the following:

[0016] Strategies for handling operational anomalies in in-vehicle entertainment systems, Android startup anomalies, memory usage anomalies, CPU usage anomalies, and critical process execution anomalies.

[0017] The step of handling anomalies in the in-vehicle infotainment system according to the preset anomaly handling strategy includes:

[0018] When the operating parameters of the in-vehicle entertainment system are abnormal, the in-vehicle infotainment system shall be handled in accordance with the in-vehicle entertainment system operation abnormality handling strategy.

[0019] When the Android startup status parameters are abnormal, the in-vehicle infotainment system is handled according to the Android startup exception handling strategy.

[0020] When the memory usage parameters are abnormal, the in-vehicle infotainment system is handled according to the memory usage abnormality handling strategy.

[0021] When the CPU usage parameters are abnormal, the in-vehicle infotainment system is handled according to the CPU usage exception handling strategy.

[0022] When the operating parameters of the critical process are abnormal, the in-vehicle infotainment system is subjected to abnormal handling according to the critical process abnormal handling strategy.

[0023] Optionally, determining whether the operating parameters of the in-vehicle entertainment system are abnormal includes:

[0024] Determine if the heartbeat communication between the MCU module and the SOC module of the in-vehicle entertainment system is normal. If not, then...

[0025] The operating parameters of the in-vehicle entertainment system are determined to be abnormal.

[0026] Optionally, determining whether the heartbeat communication between the MCU module and the SOC module of the in-vehicle entertainment system is normal includes:

[0027] Determine whether the MCU module receives a heartbeat response from the SOC module within a predetermined period after sending the heartbeat packet. If not, then...

[0028] The operating parameters of the in-vehicle entertainment system are determined to be abnormal.

[0029] Optionally, when the operating parameters of the in-vehicle entertainment system are abnormal, the abnormal handling of the in-vehicle infotainment system according to the abnormal operation handling strategy of the in-vehicle entertainment system includes:

[0030] When the operating parameters of the in-vehicle entertainment system are abnormal, the SOC module is restarted.

[0031] Optionally, when the running parameter is an Android startup status parameter, determining whether the running parameter is abnormal includes:

[0032] Determine if the Android system in the SOC module is starting up abnormally.

[0033] Optionally, determining whether the Android system startup in the SOC module is abnormal includes:

[0034] Determine whether the Linux system in the SOC module received the heartbeat packet sent by the Android system within the first preset time. If not, then...

[0035] Determine if the Android system in the SOC module is experiencing startup errors.

[0036] Optionally, when the Android startup status parameters are abnormal, the in-vehicle infotainment system is subjected to abnormal handling according to the Android startup abnormality handling strategy, including:

[0037] When the Android startup status parameters are abnormal, restart the Android system.

[0038] Optionally, determining whether memory usage parameters are abnormal includes:

[0039] Get memory usage;

[0040] Determine whether the memory usage rate is greater than a first preset threshold; if so, then...

[0041] The system detected abnormal memory usage parameters.

[0042] Optionally, when the memory usage parameters are abnormal, the step of performing abnormal handling on the in-vehicle infotainment system according to the memory usage abnormality handling strategy includes:

[0043] Retrieve memory usage status when memory usage parameters are abnormal;

[0044] The memory usage status is synchronized to cloud data.

[0045] Optionally, the step of performing anomaly handling on the in-vehicle infotainment system according to the memory usage anomaly handling strategy when the memory usage parameters are abnormal further includes:

[0046] Configure a reasonable cache recycling mechanism, and clearly define the lifecycle of each component and minimize the runtime of each component;

[0047] Reduce the number of processes that the system allows to run simultaneously; if the number is exceeded, release them directly according to their priority.

[0048] The system adds an app usage frequency detection mechanism. Apps with high usage frequency retain the native cache mechanism when exiting, while apps with low usage frequency release it immediately when exiting.

[0049] Optionally, determining whether the CPU usage parameters are abnormal includes:

[0050] Get CPU utilization;

[0051] Determine whether the CPU utilization rate is greater than a second preset threshold; if so, then...

[0052] Determine if the CPU usage parameters are abnormal.

[0053] Optionally, when the CPU usage parameters are abnormal, the in-vehicle infotainment system is subjected to abnormal handling according to the CPU usage abnormal handling strategy, including:

[0054] Obtain information on a preset number of CPU processes;

[0055] Print and / or upload the acquired CPU process information to the cloud.

[0056] Optionally, when the CPU usage parameters are abnormal, performing abnormal handling on the in-vehicle infotainment system according to the CPU usage abnormality handling strategy further includes:

[0057] Obtain the priority and lifecycle parameters of each process;

[0058] Determine whether a process can be released based on its priority and lifecycle parameters. If so, then...

[0059] Release processes that can be released.

[0060] Optionally, when the CPU usage parameters are abnormal, performing abnormal handling on the in-vehicle infotainment system according to the CPU usage abnormality handling strategy further includes:

[0061] Get the data parameters of currently active processes;

[0062] Get the preset parameters of active processes;

[0063] The active process data parameters are compared with their preset parameters to determine if the process is abnormal. If so, then...

[0064] End the process.

[0065] Optionally, determining whether the critical process running parameters are abnormal includes:

[0066] Get the status of the Weston process;

[0067] Check if the PID of the Weston process has changed; if so, then...

[0068] Determine if the runtime parameters of critical processes are abnormal.

[0069] Optionally, when the critical process operating parameters are abnormal, the in-vehicle infotainment system is subjected to anomaly handling according to the critical process operation anomaly handling strategy, including:

[0070] Restart the Android system in the SOC module.

[0071] This application also provides an anomaly handling device for an in-vehicle infotainment system, the anomaly handling device for an in-vehicle infotainment system comprising:

[0072] An operating parameter acquisition module is used to acquire the operating parameters of the in-vehicle infotainment system.

[0073] The judgment module is used to determine whether the operating parameters are abnormal;

[0074] An exception handling strategy acquisition module is used to acquire a preset exception handling strategy when the judgment module determines that it is true.

[0075] An exception handling module is used to handle exceptions in the in-vehicle infotainment system according to the preset exception handling strategy.

[0076] This application also provides an in-vehicle infotainment system, which includes a SOC module, an MCU module, and an exception handling device for an in-vehicle infotainment system as described in claim 19.

[0077] This application also provides a vehicle that includes the in-vehicle infotainment system described above.

[0078] This application has at least the following beneficial technical effects:

[0079] The in-vehicle infotainment system of this application uses an exception handling method to determine whether the in-vehicle infotainment system is abnormal by using operating parameters. When an abnormality is found, a preset exception handling strategy is read to solve or at least mitigate the problems caused by the abnormality. Attached Figure Description

[0080] Figure 1This is a flowchart illustrating an exception handling method for an in-vehicle infotainment system provided in one embodiment of this application.

[0081] Figure 2 This is a system architecture diagram of an exception handling device for an in-vehicle infotainment system according to an embodiment of this application. Detailed Implementation

[0082] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below with reference to the accompanying drawings. In the drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The described embodiments are some, but not all, embodiments of this application. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0083] It should be noted that in the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0084] Figure 1 This is a flowchart illustrating an exception handling method for an in-vehicle infotainment system provided in one embodiment of this application. Figure 2 This is a system architecture diagram of an exception handling device for an in-vehicle infotainment system according to an embodiment of this application.

[0085] like Figure 1 The fault handling methods for the in-vehicle infotainment system shown include:

[0086] Step 1: Obtain the operating parameters of the in-vehicle infotainment system;

[0087] Step 2: Determine if the running parameters are abnormal. If so, then...

[0088] Step 3: Obtain the preset exception handling strategy;

[0089] Step 4: Perform anomaly handling on the in-vehicle infotainment system according to the preset anomaly handling strategy.

[0090] The in-vehicle infotainment system of this application uses an exception handling method to determine whether the in-vehicle infotainment system is abnormal by using operating parameters. When an abnormality is found, a preset exception handling strategy is read to solve or at least mitigate the problems caused by the abnormality.

[0091] In this embodiment, the operating parameters include one of the following:

[0092] Operating parameters of the in-vehicle entertainment system, Android startup status parameters, memory usage parameters, CPU usage parameters, and key process operating parameters;

[0093] Determining whether the operating parameters are abnormal includes one of the following:

[0094] Determine whether the operating parameters of the in-vehicle entertainment system are abnormal, whether the Android startup status parameters are abnormal, whether the memory usage parameters are abnormal, whether the CPU usage parameters are abnormal, and whether the operating parameters of key processes are abnormal.

[0095] Pre-defined exception handling strategies include one of the following:

[0096] Strategies for handling operational anomalies in in-vehicle entertainment systems, Android startup anomalies, memory usage anomalies, CPU usage anomalies, and critical process execution anomalies.

[0097] The fault handling of the in-vehicle infotainment system according to the preset fault handling strategy includes:

[0098] When the operating parameters of the in-vehicle entertainment system are abnormal, the in-vehicle infotainment system is handled according to the in-vehicle entertainment system operation abnormality handling strategy;

[0099] When the Android startup status parameters are abnormal, the in-vehicle infotainment system is handled according to the Android startup exception handling strategy.

[0100] When memory usage parameters are abnormal, the in-vehicle infotainment system is handled according to the memory usage exception handling strategy.

[0101] When the CPU usage parameters are abnormal, the in-vehicle infotainment system is handled according to the CPU usage exception handling strategy.

[0102] When critical process running parameters are abnormal, the in-vehicle infotainment system is handled according to the critical process running exception handling strategy.

[0103] This application monitors the internal system status of in-vehicle infotainment systems, providing comprehensive monitoring dimensions, including operating parameters, Android startup status parameters, memory usage parameters, CPU usage parameters, and key process running parameters, all synchronized to the cloud. This allows for the most comprehensive monitoring of the overall internal status of the in-vehicle infotainment system.

[0104] In this embodiment, determining whether the operating parameters of the in-vehicle entertainment system are abnormal includes:

[0105] Determine if the heartbeat communication between the MCU module and SOC module of the in-vehicle entertainment system is normal. If not, then...

[0106] Determine if the operating parameters of the in-vehicle entertainment system are abnormal.

[0107] In this embodiment, determining whether the heartbeat communication between the MCU module and the SOC module of the in-vehicle entertainment system is normal includes:

[0108] Determine whether the MCU module receives a heartbeat response from the SOC module within a predetermined period after sending the heartbeat packet. If not, then...

[0109] Determine if the operating parameters of the in-vehicle entertainment system are abnormal.

[0110] In this embodiment, when the operating parameters of the in-vehicle entertainment system are abnormal, the abnormal handling of the in-vehicle infotainment system according to the in-vehicle entertainment system abnormal handling strategy includes:

[0111] When the operating parameters of the in-vehicle entertainment system are abnormal, the SOC module will be restarted.

[0112] Specifically, after the MCU starts up successfully, it will actively send a heartbeat packet to the failsafe module of the Linux system on the SOC side. The failsafe module will respond upon receiving the heartbeat packet. If the MCU does not receive a failsafe heartbeat packet response for 10 consecutive cycles (10 cycles is the predetermined cycle), the SOC will be forcibly restarted.

[0113] In this embodiment, when the running parameter is an Android startup status parameter, determining whether the running parameter is abnormal includes:

[0114] Determine if the Android system in the SOC module is starting up abnormally.

[0115] In this embodiment, determining whether the Android system startup in the SOC module is abnormal includes:

[0116] Determine whether the Linux system in the SOC module received the heartbeat packet sent by the Android system within the first preset time. If not, then...

[0117] Determine if the Android system in the SOC module is experiencing startup errors.

[0118] In this embodiment, the application further includes instrument operating parameters.

[0119] In this application, determining whether the operating parameters are abnormal further includes:

[0120] Determine if the instrument's operating parameters are abnormal.

[0121] In this application, the preset anomaly handling strategy further includes an instrument anomaly handling strategy.

[0122] In this embodiment, determining whether the instrument operating parameters are abnormal includes:

[0123] Determine if the instrument system in the SOC module is starting abnormally.

[0124] In this embodiment, determining whether the instrument system startup in the SOC module is abnormal includes:

[0125] After the instrument system starts up, determine whether the Linux system in the SOC module receives the heartbeat packet from the instrument system within a second preset time (e.g., within 2 seconds). If not, then...

[0126] Determine if the instrument system startup is abnormal.

[0127] In this embodiment, when the Android startup status parameters are abnormal, the in-vehicle infotainment system is subjected to abnormal handling according to the Android startup abnormality handling strategy, including:

[0128] When the Android startup status parameters are abnormal, restart the Android system.

[0129] Specifically, determining whether the Android system startup in the SOC module is abnormal involves:

[0130] After the Android system's failsafeMgr module starts, it sends a heartbeat packet every 2 seconds to the Linux system's failsafe module. If no heartbeat packet is received for 30 consecutive seconds (the first preset time), it requests powerMgr to restart the abnormal Android system. When the SOC starts, the Linux-side failsafe module starts a 1-minute timer (4 minutes for the first upgrade startup) waiting for the Android system's handshake message. If no handshake message is received within the specified time, it indicates an Android system error. The Linux-side failsafe module then sends a request to powerMgr to restart Android's communication. Upon receiving the message, powerMgr restarts the specified Android system, and then the Linux-side failsafe module resumes listening for handshake messages.

[0131] Specifically, determining whether the instrumentation system in the SOC module has an abnormal startup involves:

[0132] After the SOC starts up, the failsafe module on the Linux side will begin listening for heartbeat messages from the instrument module. After the instrument starts up, it sends a heartbeat message to the failsafe module every 2 seconds. Upon receiving the heartbeat message, the failsafe module resets the 3-second timeout timer and clears the timeout count. If no heartbeat message is received from the instrument for 30 consecutive times, it will request a restart of the MCU to restart the SOC.

[0133] In this embodiment, determining whether memory usage parameters are abnormal includes:

[0134] Get memory usage;

[0135] Determine if memory usage exceeds a first preset threshold; if so, then...

[0136] The system detected abnormal memory usage parameters.

[0137] In this embodiment, when the memory usage parameters are abnormal, the abnormal handling of the in-vehicle infotainment system according to the memory usage abnormality handling strategy includes:

[0138] Retrieve memory usage status when memory usage parameters are abnormal;

[0139] The memory usage status is synchronized to cloud data.

[0140] In this embodiment, when the memory usage parameters are abnormal, the abnormal handling of the in-vehicle infotainment system according to the memory usage abnormality handling strategy further includes:

[0141] Configure a reasonable cache recycling mechanism, clearly define the lifecycle of each component, and minimize the runtime of each component. For example, first determine whether the running component is a frequently used application. If it is not frequently used, it can be recycled directly when it is pushed to the background. If it is a navigation, music, or other application, it can be kept alive after entering the background and can be set to high priority as needed. When resources are limited, high-priority applications will take protective measures.

[0142] Reduce the number of processes that the system allows to run simultaneously; release processes that exceed this number directly according to their priority. For example, when a process occupies more than 70% of the system's memory, kill the processes one by one according to their priority until the process occupies less than 70% of the memory.

[0143] The system adds an app usage frequency detection mechanism. Apps with high usage frequency retain the native cache mechanism when exiting, while apps with low usage frequency release it immediately when exiting.

[0144] In this embodiment, determining whether CPU usage parameters are abnormal includes:

[0145] Get CPU utilization;

[0146] Determine if CPU utilization exceeds a second preset threshold; if so, then...

[0147] Determine if the CPU usage parameters are abnormal.

[0148] In this embodiment, when the CPU usage parameters are abnormal, the abnormal handling of the in-vehicle infotainment system according to the CPU usage abnormality handling strategy includes:

[0149] Obtain information on a preset number of CPU processes;

[0150] Print and / or upload the acquired CPU process information to the cloud.

[0151] In this embodiment, when the CPU usage parameters are abnormal, the abnormal handling of the in-vehicle infotainment system according to the CPU usage abnormality handling strategy further includes:

[0152] Obtain the priority and lifecycle parameters of each process;

[0153] Determine whether a process can be released based on its priority and lifecycle parameters. If so, then...

[0154] Release processes that can be released.

[0155] In this embodiment, when the CPU usage parameters are abnormal, the abnormal handling of the in-vehicle infotainment system according to the CPU usage abnormality handling strategy further includes:

[0156] Get the data parameters of currently active processes;

[0157] Get the preset parameters of active processes;

[0158] The active process data parameters are compared with their preset parameters to determine if the process is abnormal. If so, then...

[0159] End the process.

[0160] In this embodiment, determining whether the running parameters of a critical process are abnormal includes:

[0161] Get the status of the Weston (layer) process;

[0162] Check if the PID of the Weston process has changed; if so, then...

[0163] Determine if the runtime parameters of critical processes are abnormal.

[0164] In this embodiment, when the operating parameters of a critical process are abnormal, the abnormal handling of the in-vehicle infotainment system according to the critical process abnormality handling strategy includes:

[0165] Restart the Android system in the SOC module.

[0166] This application can monitor the system status within an in-vehicle infotainment system, providing comprehensive monitoring dimensions, including fault information and performance parameters such as memory, GPU, critical processes, and communication mechanisms, and synchronizing these parameters to the cloud. Furthermore, when monitored parameters reach certain thresholds, the system will perform anomaly handling according to a preset anomaly handling strategy, quickly reducing the system's operational load.

[0167] This application can solve the following problems:

[0168] 1. Avoid user experience issues caused by the system's own operating load, such as screen freezing and slow interface switching.

[0169] 2. In the event of a malfunction, the status data of the vehicle system at the time of the event can be obtained through cloud data to assist in analysis.

[0170] See Figure 2 This application also provides an anomaly handling device for an in-vehicle infotainment system. The anomaly handling device for an in-vehicle infotainment system includes an operating parameter acquisition module 11, a judgment module 12, an anomaly handling strategy acquisition module 13, and an anomaly handling module 14. The operating parameter acquisition module 11 is used to acquire the operating parameters of the in-vehicle infotainment system; the judgment module 12 is used to judge whether the operating parameters are abnormal; the anomaly handling strategy acquisition module 13 is used to acquire a preset anomaly handling strategy when the judgment module judges that the parameters are abnormal; and the anomaly handling module 14 is used to perform anomaly handling on the in-vehicle infotainment system according to the preset anomaly handling strategy.

[0171] This application also provides an in-vehicle infotainment system, which includes a SOC module, an MCU module, and an exception handling device for an in-vehicle infotainment system as described above. In this embodiment, the SOC module includes an Android system and a Linux module. In this embodiment, an instrument cluster system is installed in the Linux module.

[0172] This application also provides a vehicle that includes the in-vehicle infotainment system described above.

[0173] In this embodiment, the in-vehicle infotainment system may include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0174] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0175] Computer-readable media include both permanent and non-permanent, removable and non-removable media, and information storage can be achieved by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, DVD or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0176] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0177] Furthermore, it is clear that the word "comprising" does not exclude other units or steps. Multiple units, modules, or devices recited in the apparatus claims may also be implemented by a single unit or overall apparatus via software or hardware.

[0178] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutively marked blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or the overall flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0179] In this embodiment, the processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0180] Memory can be used to store computer programs and / or modules. The processor implements various functions of the device / terminal equipment by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area can store data created based on the use of the mobile phone (such as audio data, phonebook, etc.). In addition, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0181] In this embodiment, if the modules / units integrated into the device / terminal equipment are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

[0182] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0183] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An abnormality processing method for an in-vehicle infotainment system, characterized by, The abnormality processing method for the in-vehicle infotainment system comprises: obtaining an operation parameter of the in-vehicle infotainment system; determining whether the operation parameter is abnormal, and if so, obtaining a preset abnormality processing strategy; processing the in-vehicle infotainment system according to the preset abnormality processing strategy; the operation parameter comprises at least one of the following: an operation parameter of the in-vehicle infotainment system, an Android startup state parameter, a memory usage parameter, a CPU usage parameter, and a key process operation parameter; the determination of whether the operation parameter is abnormal comprises at least one of the following: determining whether the operation parameter of the in-vehicle infotainment system is abnormal, determining whether the Android startup state parameter is abnormal, determining whether the memory usage parameter is abnormal, determining whether the CPU usage parameter is abnormal, and determining whether the key process operation parameter is abnormal; the preset abnormality processing strategy comprises at least one of the following: an operation abnormality processing strategy of the in-vehicle infotainment system, an Android startup abnormality processing strategy, a memory usage abnormality processing strategy, a CPU usage abnormality processing strategy, and a key process operation abnormality processing strategy; the processing of the in-vehicle infotainment system according to the preset abnormality processing strategy comprises at least one of the following: when the operation parameter of the in-vehicle infotainment system is abnormal, processing the in-vehicle infotainment system according to the operation abnormality processing strategy of the in-vehicle infotainment system; when the Android startup state parameter is abnormal, processing the in-vehicle infotainment system according to the Android startup abnormality processing strategy; when the memory usage parameter is abnormal, processing the in-vehicle infotainment system according to the memory usage abnormality processing strategy; when the CPU usage parameter is abnormal, processing the in-vehicle infotainment system according to the CPU usage abnormality processing strategy; when the key process operation parameter is abnormal, processing the in-vehicle infotainment system according to the key process operation abnormality processing strategy; the determination of whether the operation parameter of the in-vehicle infotainment system is abnormal comprises: determining whether the heartbeat packet conversation between the MCU module and the SOC module of the in-vehicle infotainment system is normal, and if not, determining that the operation parameter of the in-vehicle infotainment system is abnormal; when the operation parameter is the Android startup state parameter, the determination of whether the operation parameter is abnormal comprises: determining whether the startup of the Android system in the SOC module is abnormal; the determination of whether the memory usage parameter is abnormal comprises: obtaining a memory usage rate; determining whether the memory usage rate is greater than a first preset threshold, and if so, determining that the memory usage parameter is abnormal; the determination of whether the CPU usage parameter is abnormal comprises: obtaining a CPU usage rate; determining whether the CPU usage rate is greater than a second preset threshold, and if so, determining that the CPU usage parameter is abnormal; when the CPU usage parameter is abnormal, the processing of the in-vehicle infotainment system according to the CPU usage abnormality processing strategy comprises: obtaining CPU process information of a preset number; printing and / or uploading the obtained CPU process information to the cloud data; When the Android startup state parameter is abnormal, the abnormal handling of the vehicle infotainment system according to the Android startup abnormal handling strategy includes: The android system failsafeMgr module sends a heartbeat packet every 2 seconds after starting. If no heartbeat packet message is received for 30 seconds, the powerMgr is requested to restart the abnormal android system. After the SOC starts, the linux side failsafe starts a 1-minute timer to wait for the handshake message of the android system startup. If no handshake message is received within the specified time, it indicates that the android system is abnormal, and the failsafe module of the linux side sends a request to restart the android communication to the powerMgr. After receiving the message, the powerMgr restarts the specified android system, and then the failsafe of the linux side starts to listen to the handshake message again. The judgment of whether the key process running parameter is abnormal includes: Obtaining the state of the weston process; Judging whether the pid of the weston process changes, if yes, then Judging that the key process running parameter is abnormal; When the key process running parameter is abnormal, the abnormal handling of the vehicle infotainment system according to the key process running abnormal handling strategy includes: Restarting the android system in the SOC module; First, judge whether the running component is a user's frequently used application. If not, directly recycle when retreating to the background. If it is a navigation or music application, keep alive after entering the background, and can be set to high priority as needed. When the resource is limited, the application with high priority will be protected; Reduce the number of processes allowed to run simultaneously by the system. If the number exceeds, directly release according to the priority; for example, when the process occupancy exceeds 70%, gradually kill the process according to the priority until the process reaches within 70%. The system increases the APP usage frequency detection mechanism. The APP with high usage frequency retains the original cache mechanism when exiting, and the APP with low frequency is released immediately.

2. The abnormality handling method for a vehicle infotainment system according to claim 1, characterized by, When the CPU usage parameter is abnormal, the abnormal handling of the vehicle infotainment system according to the CPU usage abnormal handling strategy further includes: Obtaining the priority and life cycle parameters of each process; Judging whether the process can be released according to the priority and life cycle parameters of each process, if yes, then Releasing the releasable process.

3. An abnormality processing device for an in-vehicle information entertainment system, characterized by comprising: The vehicle infotainment system abnormal handling device includes: A running parameter acquisition module, the running parameter acquisition module is used to acquire the running parameter of the vehicle infotainment system; A judgment module, the judgment module is used to judge whether the running parameter is abnormal; An abnormal handling strategy acquisition module, the abnormal handling strategy acquisition module is used to acquire a preset abnormal handling strategy when the judgment module judges yes; An abnormal handling module, the abnormal handling module is used to handle the abnormal vehicle infotainment system according to the preset abnormal handling strategy; The running parameter includes at least one of the following: The running parameter of the in-vehicle entertainment system, an Android startup state parameter, a memory usage parameter, a CPU usage parameter, and a key process running parameter; The judging whether the running parameter is abnormal comprises at least one of the following: judging whether the running parameter of the in-vehicle entertainment system is abnormal, judging whether the Android startup state parameter is abnormal, judging whether the memory usage parameter is abnormal, judging whether the CPU usage parameter is abnormal, and judging whether the key process running parameter is abnormal; The preset abnormal processing strategy comprises at least one of the following: the running abnormal processing strategy of the in-vehicle entertainment system, the Android startup abnormal processing strategy, the memory usage abnormal processing strategy, the CPU usage abnormal processing strategy, and the key process running abnormal processing strategy; The abnormal processing of the in-vehicle information entertainment system according to the preset abnormal processing strategy comprises at least one of the following: when the running parameter of the in-vehicle entertainment system is abnormal, the in-vehicle information entertainment system is abnormally processed according to the running abnormal processing strategy of the in-vehicle entertainment system; when the Android startup state parameter is abnormal, the in-vehicle information entertainment system is abnormally processed according to the Android startup abnormal processing strategy; when the memory usage parameter is abnormal, the in-vehicle information entertainment system is abnormally processed according to the memory usage abnormal processing strategy; when the CPU usage parameter is abnormal, the in-vehicle information entertainment system is abnormally processed according to the CPU usage abnormal processing strategy; when the key process running parameter is abnormal, the in-vehicle information entertainment system is abnormally processed according to the key process running abnormal processing strategy; The judging whether the running parameter of the in-vehicle entertainment system is abnormal comprises: judging whether the heartbeat packet conversation between the MCU module and the SOC module of the in-vehicle entertainment system is normal, if not, then judging that the running parameter of the in-vehicle entertainment system is abnormal; when the running parameter is an Android startup state parameter, the judging whether the running parameter is abnormal comprises: judging whether the Android system startup in the SOC module is abnormal; The judging whether the memory usage parameter is abnormal comprises: obtaining the memory usage rate; judging whether the memory usage rate is greater than a first preset threshold, if yes, then judging that the memory usage parameter is abnormal; The judging whether the CPU usage parameter is abnormal comprises: obtaining the CPU usage rate; judging whether the CPU usage rate is greater than a second preset threshold, if yes, then judging that the CPU usage parameter is abnormal; when the CPU usage parameter is abnormal, the abnormal processing of the in-vehicle information entertainment system according to the CPU usage abnormal processing strategy comprises: obtaining a preset number of CPU process information; printing and / or uploading the obtained CPU process information to the cloud data; when the Android startup state parameter is abnormal, the abnormal processing of the in-vehicle information entertainment system according to the Android startup abnormal processing strategy comprises: The android system failsafeMgr module sends a heartbeat packet every 2 seconds after starting. If no heartbeat packet message is received for 30 seconds, the powerMgr is requested to restart the abnormal android system. After the SOC starts, the linux side failsafe starts a 1-minute timer to wait for a handshake message from the android system. If no handshake message is received within the specified time, it indicates that the android system is abnormal, and the failsafe module on the linux side sends a request to restart the android communication to the powerMgr. After receiving the message, the powerMgr restarts the specified android system, and then the failsafe on the linux side starts listening to the handshake message again. The method further includes: Obtaining the state of the weston process; Determining whether the pid of the weston process has changed, and if so, Determining that the key process running parameter is abnormal; When the key process running parameter is abnormal, performing abnormal processing on the vehicle information entertainment system according to the key process running abnormal processing strategy includes: Restarting the android system in the SOC module; First, determine whether the running component is a user frequently used application. If not, directly recycle when returning to the background. If it is a navigation or music application, perform keep-alive after entering the background, and can be set to high priority as needed. When resources are limited, high-priority applications will perform protection behavior. Reduce the number of processes allowed to run simultaneously by the system. If the number exceeds, directly release according to the priority. For example, when the process occupancy exceeds 70%, gradually kill the process according to the priority until the process reaches within 70% to stop. The system increases the APP usage frequency detection mechanism. The APP with high usage frequency retains the original cache mechanism when exiting, and the APP with low frequency is immediately released when exiting.

4. A vehicle information entertainment system, comprising a SOC module, an MCU module, and the abnormal processing device for the vehicle information entertainment system according to claim 3.

5. A vehicle characterized by comprising: The vehicle comprises the vehicle information entertainment system according to claim 4.

Images