Processing method and processing system for emergency mode of cockpit system

Abstract

The invention discloses a processing method and a processing system for an emergency mode of a cockpit system, and relates to the technical field of intelligent operating systems. The system comprises an instrument system based on Linux, a central control entertainment system based on Android, an independent control kernel system based on FreeRTOS, an SOC chip running relatively independent kernels CORE1, CORE2 and CORE3, and performing mutual monitoring among the kernels to perform abnormal information recording and processing; and the kernel CORE3 is used for independently processing the pictures output from the kernel CORE1 and the kernel CORE2 respectively, and independently outputting the processed pictures to the corresponding display screens for display respectively. The emergency mode is introduced hierarchically, so that the system is in different failure states, adjustable resources are fully utilized to cover or repair the abnormity of the system, and the operation threshold is reduced and the maintenance difficulty is reduced as much as possible under the scene that manual operation is needed.

Description

Technical Field

[0001] The present invention belongs to the technical field of intelligent operating systems, and in particular relates to a method and system for processing an emergency mode of a cockpit system. Background Art

[0002] At present, the software systems used in cockpit projects are becoming increasingly complex, and the connected products of the vehicle body have basically covered the requirements of OTA upgrade functions. Therefore, the off-line upgrade scenarios of products will appear more and more in various connected products. Moreover, larger data packets lead to longer data transmission time. Offline upgrades may cause many unexpected process anomalies due to the complexity and changeability of the vehicle body scenes during the upgrade and the professionalism of the operators.

[0003] Most current products can only wait for professionals to disassemble and maintain the system after a system anomaly occurs. For example, Chinese patent CN112905222A discloses a method and system for repairing Android terminal system upgrade anomalies. When a file with an upgrade anomaly is encountered during the system upgrade process, it is recorded in the system upgrade anomaly list, and the file is skipped to continue the upgrade. After all upgrades are completed, the system upgrade anomaly list is uploaded to the system upgrade server. The system upgrade server triggers the ROM compilation server to extract the corresponding files in the full package corresponding to the ROM of the new version of the program to be upgraded and generate a repair package. The system upgrade server provides the Android terminal with the URL of the repair package. After the system upgrade program obtains the repair package, it performs a second system upgrade and directly replaces the abnormal files with the files in the repair package. For example, Chinese patent CN111142911A discloses an embedded system with abnormal recovery function and its upgrade method, which divides the image storage space into main / backup partitions; the steps are as follows: ① system startup, determine whether the main partition is upgraded, if so, load the image, if not, send an upgrade request, the request is successful, upgrade according to the main partition image, success, system reset, restart, request fails, and image loading; ② when executing image loading, first load the main partition image, if it fails, load the backup partition image, if both fail, reset the system, restart; if successfully loaded, start; ③ if the startup is successful, determine the image source, otherwise reset the system, restart; if it comes from the main partition, determine whether it is upgraded, if it has been upgraded, update the backup partition; if it has not been upgraded, reset to zero and complete the startup; if it comes from the backup partition, restore the main partition image; then clear the status mark and complete the startup. This method can ensure the validity of the upgraded image and ensure that the system will not fail to start due to upgrade failure.

[0004] The above-mentioned prior art can detect anomalies and recover, but lacks an effective processing technology when a system anomaly occurs and the backup or key information is lost or cannot be repaired. Therefore, the present application provides a cockpit system emergency mode processing method and processing system. Summary of the invention

[0005] The purpose of the present invention is to provide a cockpit system emergency mode processing method and processing system, which introduces a hierarchical processing emergency mode to reduce the operational difficulty of system recovery and appropriately compensate for the lack of key information caused by system abnormalities. In view of the lack of key information, more levels of recovery measures are introduced to reduce customer complaints, reduce the maintenance and rescue costs of later product failures, solve existing problems, lower the operating threshold, and minimize the difficulty of maintenance.

[0006] In order to solve the above technical problems, the present invention is achieved through the following technical solutions:

[0007] As a first aspect of the present invention, the present invention is a cockpit system emergency mode processing system, comprising:

[0008] A Linux-based instrument system running on CORE1, wherein the instrument system is in communication with the instrument display screen;

[0009] An Android-based central control entertainment system running on CORE2, wherein the central control entertainment system is in communication connection with the central control display screen;

[0010] An independent control kernel system based on FreeRTOS, which runs on CORE3, wherein the kernel CORE3 of the independent control kernel system is connected to the external Flash through the SPI protocol;

[0011] A SOC chip runs relatively independent cores CORE1, CORE2, and CORE3, and the cores monitor each other to record and process abnormal information;

[0012] The core CORE3 is used to independently process the images output from the cores CORE1 and CORE2, and independently output the processed images to corresponding display screens for display.

[0013] As a second aspect of the present invention, the present invention is a method for processing an emergency mode of a cockpit system. The processing method is implemented based on the processing system described in the first aspect, and the processing method comprises the following steps:

[0014] According to the functional performance of SOC, the emergency mode is divided into four response levels;

[0015] Process according to the response level of the emergency mode:

[0016] First level: If the central control entertainment system and instrument system boot program are normal, the cockpit system memory access function is normal, and the screen driver display is normal in emergency mode, then jump to the backup system partition to run;

[0017] Level 2: The central control entertainment system and instrument system boot program are normal, but the application program is abnormal and cannot automatically jump to the backup system partition or the data saved in the backup system partition is damaged. However, if the system storage partition can be rewritten, then overwrite and repair are performed;

[0018] Level 3: When the boot program of the central control entertainment system and the instrument system is abnormal, and the storage partition may have data damage or the application is abnormal, the data of the storage space is erased and rewritten through the external boot program;

[0019] Supplementary level: During the occurrence of level 1, level 2, and level 3 anomalies, when the display function is normal, the low-end pixel-level graphic display of the core CORE3 is used to display key information.

[0020] Furthermore, under the first level, the cockpit system divides the storage chip into two partitions, A and B; the same set of operating system startup files are independently stored in the two partitions, and the startup root directory is set to partition A and the backup startup root directory is set to partition B, and partition B is used as the backup system partition.

[0021] Furthermore, in the first-level emergency mode, if the storage data in the A partition is damaged, the cockpit system automatically jumps to the backup B partition to run after the startup file of the operating system in the A partition fails, and restarts the cockpit system with the same startup process as the A partition;

[0022] The judgment method adopted in the automatic jump process is as follows: when the cockpit system detects that the data loading process has timed out or failed during startup, the operating system startup file path of the B partition is selected for reloading;

[0023] When the data loading process times out or fails, it is determined that the stored data is damaged.

[0024] Furthermore, in the first-level emergency mode, if the cockpit system is successfully and stably started in the B partition for more than N times, it is determined that the operating system startup file in the B partition is stable. At this time, the operating system startup file in the A partition is refreshed to the same operating system startup file in the B partition;

[0025] The refresh process is: completely copy the operating system startup file of partition B to partition A. After the copying is completed, when the cockpit system is started again, partition A after the operating system startup file of partition B is copied will be used for startup and operation. Partition B is still used as a backup system partition to store the backup startup root directory.

[0026] Wherein, N is a preset value and N>10.

[0027] Furthermore, the entry conditions of the second level are:

[0028] When the system kernel is running normally, the central control entertainment system will enter the repair mode after the Bluetooth, WIFI, screen display and sound playback functions fail;

[0029] The method for determining whether the system kernel is operating normally is as follows: if the drive power supply system, SOC, EMMC, DDR, and core chip hardware driver are normal, then the system kernel is determined to be operating normally;

[0030] Wherein, in the second-level emergency mode, the external USB port is required to be driven normally.

[0031] Furthermore, in the second-level emergency mode:

[0032] If the display is abnormal, perform a custom upgrade by running the script in the upgrade package provided by the USB port;

[0033] Among them, the script is a set of UI control scripts that can be recognized by the repair system. The UI control scripts are:

[0034] write_raw_image, which is used to write the Flash partition;

[0035] copy_dir, which is used to copy a directory.

[0036] Furthermore, the entry conditions for the third level are:

[0037] When EMMC fails and the first and second level emergency modes cannot operate normally, the third level emergency mode is entered, and the third level is used to re-upgrade the firmware;

[0038] In the third level emergency mode, a minimum system is saved by an external Flash. After the minimum system is started, the EMMC chip and the USB port are continuously searched. If an upgrade file is found, the upgrade program is executed.

[0039] The minimum system includes a driving power supply system, a SOC, an EMMC, and a DDR.

[0040] Furthermore, the entry conditions of the supplementary level are:

[0041] When the Linux instrument system of core CORE1 and the Android central control entertainment system of core CORE2 completely fail and the first-level and second-level emergency modes cannot operate normally, the supplementary-level emergency mode is entered;

[0042] In the supplementary level of emergency mode, the core CORE3 depicts key information through pixels and displays it in the instrument display;

[0043] Among them, key information includes vehicle speed and indicator light information.

[0044] The present invention has the following beneficial effects:

[0045] The present invention solves the problem of abnormal startup or abnormal operation of some systems by making full use of multi-core independent systems. It divides the abnormal state into three levels according to the severity level, and mobilizes available resources for remediation or failure coverage at each level stage. In this way, the impact of system abnormalities is minimized; by introducing the emergency working mode in a hierarchical manner, the system is in different failure states and fully utilizes the available resources to cover or repair its own abnormalities. In the scenario where manual operation is required, the operation threshold is lowered and the maintenance difficulty is minimized.

[0046] Of course, any product implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for describing the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0048] Figure 1 The system framework diagram of the cockpit system emergency mode processing system of the present invention. DETAILED DESCRIPTION

[0049] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0050] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0051] It should also be understood that the term “and / or” used in the specification and appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0052] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0053] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0054] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0055] Embodiment 1:

[0056] like Figure 1As shown, as the first embodiment of the present invention, the present invention is a cockpit system emergency mode processing system, which realizes mutual monitoring between system cores and records and processes abnormal information through differential management between multiple independent systems. Among them, core CORE3 will independently process the images output from core CORE1 and core CORE2, and then independently output them to two display screens for display. In the embodiment of the present invention, there are four relatively independent processing systems, and three systems are respectively run in one SOC, running in three relatively independent chip physical cores. Divided according to the application scenario: Linux system is used for instrument functions, Android system is used for central control entertainment, and FreeRTOS system is used for security kernel operation (MCU is an independent control chip, and the RTOS system runs alone, which is not involved in the solution of the present invention); it is mainly for the systems running in core CORE1, core CORE2, and core CORE3, specifically, including:

[0057] Linux-based instrumentation system, which runs on CORE1;

[0058] The Android-based central control entertainment system runs on CORE2;

[0059] An independent control kernel system based on FreeRTOS, which runs on CORE3;

[0060] A SOC chip runs relatively independent cores CORE1, CORE2, and CORE3 (three independent cores are integrated or spliced ​​into one chip), and the cores monitor each other to record and process abnormal information;

[0061] The core CORE3 is used to independently process the images output from the cores CORE1 and CORE2, and independently output the processed images to corresponding display screens for display.

[0062] As an embodiment provided by the present invention, preferably, the instrument system is communicatively connected with the instrument display screen;

[0063] The central control entertainment system is communicatively connected with the central control display screen;

[0064] The core CORE3 of the independent control core system is connected to the external Flash through the SPI protocol.

[0065] Based on the different severity of failure of the intelligent operating system, the corresponding emergency working mode is formulated, which can enable the product to return to normal at a lower operating cost and reduce the risk of failure.

[0066] As an embodiment provided by the present invention, preferably, mainly for the current complex intelligent operating system, the emergency situation of abnormal system operation caused by the system operation before and after the upgrade or the accumulated errors, a relatively independent emergency mode operation environment is designed according to the abnormal level of the system. It is expected that in the emergency mode, the state of the system can be restored through simple operations. At the same time, the abnormal process record information is fed back and retained in time for targeted repair or auxiliary analysis.

[0067] Embodiment 2:

[0068] As a second embodiment of the present invention, the present invention is a method for processing an emergency mode of a cockpit system. The processing method is implemented based on the processing system described in the first embodiment, and the processing method includes the following steps:

[0069] According to the functional performance of the overall SOC, the emergency mode is divided into four response levels (hereinafter referred to as "first level", "second level", "third level" and "supplementary level");

[0070] Process according to the response level of the emergency mode:

[0071] Level 1: If the central control entertainment system and instrument system boot program are normal, the cockpit system memory access function is normal, and the screen driver display is normal in emergency mode, then the system will jump to the backup system partition for operation. At this level, the system can automatically jump to another backup B system partition for operation after the system startup in the A partition fails. If the new system partition is successfully and stably started for more than N (N>10) times, the new system is considered stable and the data in the old system partition needs to be updated to the new system data.

[0072] Level 2: The central control entertainment system and instrument system boot program are normal, but the application program is abnormal and cannot automatically jump to the backup system partition or the data saved in the backup system partition is damaged, but the system storage partition can be rewritten, then overwrite and repair; if the system kernel can still run normally, then the IVI system will enter the recovery mode according to the current state of the system after some functions fail. At this level, factory reset, OTA upgrade, patch upgrade and firmware upgrade can be performed;

[0073] Level 3: When the boot program of the central control entertainment system and the instrument system is abnormal, and the storage partition may have data damage or the application is abnormal, the data in the storage space is erased and rewritten through the external boot program; if the third level cannot be executed, it is considered that the product may have hardware damage, which is beyond the operation capability of non-professionals and needs to be returned for repair and investigation;

[0074] Supplementary level: During the first, second, and third level abnormalities, when the display function is normal, the low-end pixel-level graphic display of the core CORE3 is used to display key information. In order to ensure that the basic information of the vehicle can still be displayed, it is necessary to enter the simplified instrument mode of the Safety core. The necessary functional information is displayed on the instrument display to avoid danger caused by the driver's lack of understanding of the vehicle body condition.

[0075] As an embodiment provided by the present invention, preferably, under the first level, the cockpit system divides the storage chip into two partitions, A and B; the same set of operating system startup files are independently stored in the two partitions, and the startup root directory is set to partition A and the backup startup root directory is partition B, and partition B is used as the backup system partition. Under normal circumstances, the data in partition B is more stable than that in partition A because of the isolation between storage partitions and fewer system access opportunities.

[0076] As an embodiment provided by the present invention, preferably, in the emergency mode of the first level, if the stored data in the A partition is damaged (the data loading process times out or fails), the system will automatically jump to the backup B system partition to run after the system startup in the A partition fails. Restart with the same startup process as the A partition. The jump process adopts a judgment statement: when the system startup identifies that the data loading process times out or fails, the B partition file path is selected for reloading.

[0077] As an embodiment provided by the present invention, preferably, in the first level emergency mode, after successfully and stably starting for more than N (N>10) times, the new system file is considered stable. It is necessary to refresh the data in the old system A partition to the same system data in the B partition;

[0078] The refresh process is: completely copy the operating system startup file of partition B to partition A. After the copying is completed, when the cockpit system is started again, partition A after copying the operating system startup file of partition B will be used to start and run. Partition B is still used as a backup system partition to store the backup startup root directory.

[0079] As an embodiment provided by the present invention, preferably, the entry condition of the second level is:

[0080] The system kernel can still operate normally (the driver power supply system, SOC, EMMC, DDR are the minimum system, and the core chip hardware driver is normal). Then the IVI system will enter the recovery mode after the Bluetooth, WIFI, screen display, and sound playback functions fail (the failure here is for the parts other than the minimum system). According to the current minimum system driver of the system is normal, but the peripheral device driver is abnormal.

[0081] Among them, in the second-level emergency mode, the external USB port is required to be driven normally, so that personnel can perform data recovery processing through the external USB port, and can perform factory reset, OTA upgrade, patch upgrade and firmware upgrade.

[0082] As an embodiment provided by the present invention, preferably, in the second level emergency mode: if the display screen is abnormal, a custom upgrade can be performed by running a script in an upgrade package provided by the USB port, wherein the script is a set of UI controls that can be recognized by the recovery system, such as write_raw_image (write FLASH partition), copy_dir (copy directory). If the touch screen works normally at this time, the upgrade package can also be stored in a U disk, and upgraded according to the normal process through interface operation.

[0083] As an embodiment provided by the present invention, preferably, in the second level emergency mode: if the screen can be displayed normally, a menu list of all allowed operations should be displayed, and the operating instructions for restoring the system should be written. The preliminary function list is as follows:

[0084] ① Provide factory reset option (steering wheel buttons + capacitive touch)

[0085] ②System restart option (steering wheel button + capacitive touch)

[0086] ③OTA upgrade option (steering wheel buttons + capacitive touch)

[0087] ④ Obtain key system LOG and copy it to external storage device, display process error code

[0088] ⑤ Jump to another system backup area

[0089] ⑥Export key customer information (if stored locally)

[0090] ⑦Other functions that allow users to achieve through external control

[0091] It should be noted that all operations need to support both touch screen and physical button input methods to reduce the risk of failure of a single input method.

[0092] As an embodiment provided by the present invention, preferably, the entry condition of the third level is:

[0093] When EMMC fails and the first and second level emergency modes cannot operate normally, the third level emergency mode is entered. The third level emergency mode is mainly used to successfully re-upgrade the firmware.

[0094] In the third-level emergency mode, the solution needs to use an independent memory chip. Design an independent FLASH chip outside the SOC. It is necessary to save a minimum system, and continuously search for EMMC chips and USB ports after startup. If the upgrade file is found, the upgrade program is executed; the minimum system includes the drive power supply system, SOC, EMMC, and DDR.

[0095] As an embodiment provided by the present invention, preferably, the system in emergency mode should try to realize screen display, but screen display is not an essential functional requirement.

[0096] As an embodiment provided by the present invention, preferably, the entry condition of the supplementary level is:

[0097] When the Linux instrument system of core CORE1 and the Android central control entertainment system of core CORE2 completely fail and the first-level and second-level emergency modes cannot operate normally, the supplementary-level emergency mode is entered;

[0098] In the supplementary emergency mode, the core CORE3 uses pixels to depict key information and displays it on the instrument display screen; key information includes vehicle speed and indicator light information. At this time, in order to ensure that the basic information of the vehicle can still be displayed, the core CORE3 will use pixels to depict the vehicle speed and indicator light information and display it on the instrument display screen. This ensures driving safety and avoids dangers caused by the driver's lack of understanding of the vehicle's condition.

[0099] As another embodiment provided by the present invention, preferably, the supporting background is a cockpit product using one-chip, multi-screen and multi-system, and an emergency processing solution under abnormal conditions. The present invention proposes countermeasures and design ideas for such system solutions, and takes the smart cockpit system (Linux+Android1+Free RTOS) solution of a smart car as an example to complete the implementation of the contents of the present invention. The present invention is also applicable to emergency processing of all other multi-systems.

[0100] As another embodiment provided by the present invention, preferably, the system framework, software framework and software program designed according to the present invention can run in various multi-system levels that meet the requirements, that is, they are not limited to use in Linux and Android systems; but the implementation of the present invention is mainly based on the Linux+Android+Free RTOS system, so in the example of the present invention, the invention content is the system framework, software framework and software program existing in the Linux+Android+Free RTOS system.

[0101] A cockpit system emergency mode processing method and processing system, by introducing the emergency working mode in a hierarchical manner, the system is in different failure states, making full use of the available resources to cover or repair its own abnormalities. In the scenario where manual operation is required, the operation threshold is lowered and the maintenance difficulty is reduced as much as possible. The design of the present invention can solve the recovery needs when the system is abnormal in a convenient and fast way with low technical thresholds and tools, providing convenience for users, car manufacturers, and their own product maintenance.

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

[0103] The preferred embodiments of the present invention disclosed above are only used to help illustrate the present invention. The preferred embodiments do not describe all the details in detail, nor do they limit the invention to the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A cockpit system emergency mode processing system, characterized in that: include: A Linux-based instrumentation system that runs on CORE1; The Android-based central control entertainment system runs on CORE2; An independent control kernel system based on FreeRTOS, which runs on CORE3; A SOC chip runs relatively independent cores CORE1, CORE2, and CORE3, and the cores monitor each other to record and process abnormal information; The core CORE3 is used to independently process the images output from the cores CORE1 and CORE2, and independently output the processed images to corresponding display screens for display.

2. A cockpit system emergency mode processing system according to claim 1, characterized in that: The instrument system is communicatively connected with the instrument display screen; The central control entertainment system is communicatively connected with the central control display screen; The core CORE3 of the independent control core system is connected to the external Flash through the SPI protocol.

3. A method for processing an emergency mode of a cockpit system, characterized in that: The processing method is implemented based on the processing system according to any one of claims 1 to 2, and the processing method comprises the following steps: According to the functional performance of SOC, the emergency mode is divided into four response levels; Process according to the response level of the emergency mode: First level: If the central control entertainment system and instrument system boot program are normal, the cockpit system memory access function is normal, and the screen driver display is normal in emergency mode, then jump to the backup system partition to run; Level 2: The central control entertainment system and instrument system boot program are normal, but the application program is abnormal and cannot automatically jump to the backup system partition or the data saved in the backup system partition is damaged. However, if the system storage partition can be rewritten, then overwrite and repair are performed; Level 3: When the boot program of the central control entertainment system and the instrument system is abnormal, and the storage partition may have data damage or the application is abnormal, the data of the storage space is erased and rewritten through the external boot program; Supplementary level: During the occurrence of level 1, level 2, and level 3 anomalies, when the display function is normal, the low-end pixel-level graphic display of the core CORE3 is used to display key information.

4. A cockpit system emergency mode processing method according to claim 3, characterized in that: At the first level, the cockpit system divides the storage chip into two partitions, A and B; The same set of operating system startup files are stored independently in the two partitions, and the startup root directory is set to partition A and the backup startup root directory is set to partition B, and partition B is used as the backup system partition.

5. A method for processing a cockpit system emergency mode according to claim 4, characterized in that: In the first-level emergency mode, if the storage data in partition A is damaged, the cockpit system will automatically jump to the backup partition B to restart the cockpit system with the same startup process as partition A after the cockpit system fails to start through the operating system startup file in partition A. The judgment method adopted in the automatic jump process is as follows: when the cockpit system detects that the data loading process has timed out or failed during startup, the operating system startup file path of the B partition is selected for reloading; When the data loading process times out or fails, it is determined that the stored data is damaged.

6. A method for processing a cockpit system emergency mode according to claim 5, characterized in that: In the first level of emergency mode, if the cockpit system successfully and stably starts in the B partition for more than N times, the operating system startup file in the B partition is determined to be stable. At this time, the operating system startup file in the A partition is refreshed to the same operating system startup file in the B partition; The refresh process is: completely copy the operating system startup file of partition B to partition A. After the copying is completed, when the cockpit system is started again, partition A after the operating system startup file of partition B is copied will be used for startup and operation. Partition B is still used as a backup system partition to store the backup startup root directory. Wherein, N is a preset value and N>10.

7. A cockpit system emergency mode processing method according to claim 3, characterized in that: The entry conditions for the second level are: When the system kernel is running normally, the central control entertainment system will enter the repair mode after the Bluetooth, WIFI, screen display and sound playback functions fail; The method for determining whether the system kernel is operating normally is as follows: if the drive power supply system, SOC, EMMC, DDR, and core chip hardware driver are normal, then the system kernel is determined to be operating normally; Wherein, in the second-level emergency mode, the external USB port is required to be driven normally.

8. A cockpit system emergency mode processing method according to claim 7, characterized in that: In the second level of emergency mode: If the display is abnormal, perform a custom upgrade by running the script in the upgrade package provided by the USB port; Among them, the script is a set of UI control scripts that can be recognized by the repair system. The UI control scripts are: write_raw_image, which is used to write the Flash partition; copy_dir, which is used to copy a directory.

9. The method for processing the emergency mode of a cockpit system according to claim 3, characterized in that: The entry conditions for the third level are: When EMMC fails and the first and second level emergency modes cannot operate normally, the third level emergency mode is entered, and the third level is used to re-upgrade the firmware; In the third level emergency mode, a minimum system is saved by an external Flash. After the minimum system is started, the EMMC chip and the USB port are continuously searched. If an upgrade file is found, the upgrade program is executed. The minimum system includes a driving power supply system, a SOC, an EMMC, and a DDR.

10. The method for processing the emergency mode of a cockpit system according to claim 3, characterized in that: The entry conditions for the supplementary tier are: When the Linux instrument system of core CORE1 and the Android central control entertainment system of core CORE2 completely fail and the first-level and second-level emergency modes cannot operate normally, the supplementary-level emergency mode is entered; In the supplementary level of emergency mode, the core CORE3 depicts key information through pixels and displays it in the instrument display; Among them, key information includes vehicle speed and indicator light information.

Images