CN116204353B

CN116204353B - Recovery and restoration method, device and equipment of vehicle-mounted system and storage medium

Info

Publication number: CN116204353B
Application number: CN202211572314.XA
Authority: CN
Inventors: 李林峰; 汪杨刚; 曹元�
Original assignee: Wuhan Haiwei Technology Co ltd
Current assignee: Wuhan Haiwei Technology Co ltd
Priority date: 2022-12-08
Filing date: 2022-12-08
Publication date: 2023-10-20
Anticipated expiration: 2042-12-08
Also published as: CN116204353A

Abstract

The invention belongs to the technical field of system restoration, and discloses a restoration method, a device, equipment and a storage medium of a vehicle-mounted system. The method comprises the following steps: when the SoC system enters a boot loading stage, the recorded value of a system damage marker bit is increased; determining whether the android system is damaged according to the starting state of the android system; when the android system is damaged, determining a target recovery and restoration strategy in a preset SoC recovery and restoration strategy according to the recorded numerical value, and recovering and restoring the android system; reading preset system compiling attributes, and determining MCU compatible version numbers according to the preset system compiling attributes; and when the current MCU version number does not accord with the MCU compatible version number, recovering and restoring the MCU system by using a preset MCU recovery and restoring strategy so as to enable the vehicle-to-machine system to work normally. By the method, the defect of an original restoration mechanism of the android system is overcome, the restoration mechanism of the MCU system is perfected, and the stability of the vehicle-mounted system is ensured.

Description

Recovery and restoration method, device and equipment of vehicle-mounted system and storage medium

Technical Field

The present invention relates to the field of vehicle systems, and in particular, to a recovery method, apparatus, device, and storage medium for a vehicle system.

Background

Currently, the main stream vehicle hardware architecture generally adopts a dual-chip scheme of SoC+MCU. The main control SoC chip is used for running a complex operating system to process big data, such as images, videos, audios and the like, and the MCU with higher instantaneity and reliability and lower power consumption is used for completing information interaction with a vehicle body, power management and state monitoring of a vehicle machine system and the like. Because of the openness of the Android system, the ecological system of the whole software is relatively sound, and most of the master control SoCs operate the Android system. In order to ensure the stability of the vehicle-mounted product, the situation that a user cannot normally use the vehicle-mounted product due to the fact that the system is abnormal is avoided, a backup and restore mechanism is designed for a vehicle-mounted system in general, a current system and configuration are backed up to a system partition, and when the vehicle-mounted system cannot enter the system due to the fact that system files are deleted, lost, damaged and the like, the vehicle-mounted system can start a system restore program to load the system backup files to restore the abnormal system.

At present, most of vehicle-mounted systems are designed, only an Android system running on an SoC end supports a recovery and restoration mechanism, and programs on an MCU end are generally not supported. In addition, the Android system generally uses a built-in Recovery mode for realizing a backup Recovery mechanism of the system, but if a backup file in a partition of the Android system is lost or a Recovery program Recovery of the system is damaged, the backup Recovery mechanism of the system is invalid. And if the independently restored Android system program is not matched with the version of the MCU system program currently running, abnormal functions of the vehicle and machine system can be caused. Abnormal vehicle systems and failure to recover and restore normally can cause customer complaints, claims and the like, and bring huge losses to a host factory.

The foregoing is provided merely for the purpose of facilitating understanding of the technical solutions of the present invention and is not intended to represent an admission that the foregoing is prior art.

Disclosure of Invention

The invention mainly aims to provide a recovery and restoration method, device, equipment and storage medium for a vehicle-mounted system, and aims to solve the technical problems that in the prior art, a recovery and restoration mechanism of the vehicle-mounted system designed by a double-chip architecture has defects, the stability of the vehicle-mounted system is influenced and the use experience of a user is influenced.

In order to achieve the above object, the present invention provides a recovery and restoration method for a vehicle system, where the vehicle system includes an MCU system and an SoC system, the SoC system includes an Android system, the MCU system and the SoC system communicate through UART, and the recovery and restoration method for a vehicle system includes:

when the MCU system of the vehicle-mounted system detects a preset starting signal, the vehicle-mounted system is started;

when the SoC system of the vehicle system enters a Bootloader stage, the recorded value of a system damage zone bit is increased;

acquiring a starting state of an Android system in the SoC system, and determining whether the Android system is damaged according to the starting state;

when the Android system is damaged, determining a target Recovery strategy in a preset SoC Recovery strategy according to the recorded numerical value, recovering and recovering the Android system according to the target Recovery strategy, restarting the Android system after successful Recovery and restoration, wherein the preset SoC Recovery and restoration strategy comprises a Recovery and restoration strategy and a Bootloader Recovery and restoration strategy;

Reading preset system compiling attributes in the Android system, and determining MCU compatible version numbers according to the preset system compiling attributes;

and acquiring a current MCU version number of the MCU system, and when the current MCU version number does not accord with the MCU compatible version number, recovering and recovering the MCU system by using a preset MCU recovery and recovery strategy so as to successfully match the Android system and the MCU system, wherein the vehicle-to-machine system works normally.

Optionally, when the Android system is damaged, determining a target recovery strategy in a preset SoC recovery strategy according to the record value, recovering and recovering the Android system according to the target recovery strategy, and restarting the Android system after successful recovery and recovery, including:

when the starting state does not meet a preset system starting completion state, determining that the Android system is damaged;

acquiring the recorded numerical value, and comparing the recorded numerical value with a first preset accumulated numerical value;

comparing the recorded value with a second preset accumulated value when the recorded value is smaller than the first preset accumulated value;

when the recorded value is greater than or equal to a second preset accumulated value, determining that the target Recovery strategy is a Recovery strategy;

Acquiring file information under a preset directory, and determining whether a system restoration package exists under the preset directory according to the file information, wherein the system restoration package comprises an Android system upgrade package, an MCU upgrade package and a configuration file containing Android and MCU version numbers;

when the system restoration package exists under the preset catalog, mapping the system restoration package to a process memory space so as to restore the Android system;

after the Android system is successfully restored, the MIsc partition is erased, the Recovery upgrading flag bit is cleared, the recorded numerical value is cleared, and the Android system is restarted.

Optionally, after the obtaining the file information under the preset directory and determining whether the system restore packet exists under the preset directory according to the file information, the method further includes:

when the system restoration package does not exist under the preset directory, acquiring the system restoration package in an external memory;

decompressing the system restore package in the external memory to the preset directory;

and performing the step of mapping the system restoration package to a process memory space so as to restore the Android system.

Optionally, after the obtaining the recorded value and comparing the recorded value with the first preset accumulated value, the method further includes:

When the recorded value is greater than or equal to a first preset accumulated value, determining that the target recovery strategy is a Bootloader recovery strategy;

mounting a backup partition and a root file system;

reading an image file in the backup partition, and restoring the image file to a corresponding main partition so as to restore the Android system, wherein the main partition comprises a recovery partition, a boot partition and a system partition, and the image file comprises a recovery image file, a boot image file and a system image file;

and after the Android system is successfully restored, erasing a MIsc partition, clearing the recorded numerical value, and restarting the Android system.

Optionally, after comparing the recorded value with the second preset accumulated value when the recorded value is smaller than the first preset accumulated value, the method further includes:

when the recorded value is smaller than a second preset accumulated value, performing heartbeat monitoring on the SoC system through the MCU system, and recording the heartbeat time;

and restarting the SoC system when the heartbeat time is longer than the preset heartbeat time, and returning to execute the step of increasing the record value of the system damage marker bit when the SoC system of the vehicle machine system enters a Bootloader stage.

Optionally, the restoring and restoring the MCU system using a preset MCU restoring and restoring policy includes:

acquiring a factory preset version number of the MCU and an upgrade backup version number of the MCU;

comparing the MCU upgrade backup version number with the MCU factory preset version number with the MCU compatible version number to obtain a comparison result;

obtaining an MCU upgrade file according to the comparison result, and copying the MCU upgrade file to a preset MCU upgrade directory;

restarting the vehicle-to-machine system when the MCU system receives an upgrade instruction sent by the Android system through a UART, so that the MCU system upgrades according to the MCU upgrade file after receiving the MCU upgrade file sent by the Android system through the UART;

and deleting the preset MCU upgrading catalog after the MCU system is successfully upgraded, determining that the MCU system is successfully recovered and restored, and restarting the vehicle-to-machine system.

Optionally, the obtaining the MCU upgrade file according to the comparison result includes:

when the MCU upgrade backup version number is matched with the compatible version number, taking the MCU system file under the backup upgrade directory as an MCU upgrade file;

when the MCU factory preset version number is matched with the compatible version number, taking a default factory preset MCU system file as an MCU upgrading file;

And when the MCU factory preset version number and/or the MCU upgrade backup version number are not matched with the compatible version number, taking the MCU system package in the external memory as an MCU upgrade file.

In addition, in order to achieve the above object, the present invention further provides a recovery and restoration device for a vehicle system, where the recovery and restoration device for a vehicle system includes:

the judging module is used for starting the vehicle-mounted system when the MCU system of the vehicle-mounted system detects a preset starting signal;

the judging module is further used for increasing the recorded value of the system damage marker bit when the SoC system of the vehicle system enters a Bootloader stage;

the judging module is further used for acquiring the starting state of the Android system in the SoC system and determining whether the Android system is damaged according to the starting state;

the Recovery module is used for determining a target Recovery strategy in a preset SoC Recovery strategy according to the recorded numerical value when the Android system is damaged, recovering and recovering the Android system according to the target Recovery strategy, and restarting the Android system after successful Recovery and Recovery, wherein the preset SoC Recovery strategy comprises a Recovery strategy and a Bootloader Recovery strategy;

The restoration module is further used for reading preset system compiling attributes in the Android system and determining MCU compatible version numbers according to the preset system compiling attributes;

and the restoration module is further used for acquiring the current MCU version number of the MCU system, and restoring the MCU system by using a preset MCU restoration and restoration strategy when the current MCU version number does not accord with the MCU compatible version number so as to successfully match the Android system and the MCU system, and the vehicle-computer system works normally.

In addition, in order to achieve the above object, the present invention also provides a recovery and restoration device for a vehicle-mounted system, the recovery and restoration device for a vehicle-mounted system comprising: the system comprises a memory, a processor and a recovery program of the vehicle system which is stored on the memory and can run on the processor, wherein the recovery program of the vehicle system is configured to realize the steps of the recovery method of the vehicle system.

In addition, in order to achieve the above object, the present invention also proposes a storage medium having stored thereon a restoration program of a vehicle-mounted system, which when executed by a processor, implements the steps of the restoration method of a vehicle-mounted system as described above.

According to the method, when a preset starting signal is detected by an MCU system of a vehicle system, the vehicle system is started, when the SoC system of the vehicle system enters a Bootloader stage, a record value of a system damage marker bit is increased, a starting state of an Android system in the SoC system is obtained, whether the Android system is damaged or not is determined according to the starting state, when the Android system is damaged, a target recovery strategy is determined in a preset SoC recovery strategy according to the record value, the Android system is recovered and restored according to the target recovery strategy, the Android system is restarted after successful recovery, preset system compiling attributes in the Android system are read, an MCU compatible version number is determined according to the preset system compiling attributes, a current MCU version number of the MCU system is obtained, and when the current MCU version number does not accord with the MCU compatible version number, the preset MCU recovery strategy is used for recovering and restoring the MCU system, so that the Android system and the MCU system are successfully matched, and the vehicle system works normally. Because most of the vehicle machine systems only support a Recovery and restoration mechanism by an Android system running on an SoC end, an MCU end is generally not supported, and once a system Recovery program Recovery is damaged, the Recovery and restoration mechanism of the Android system is invalid.

Drawings

FIG. 1 is a schematic diagram of a recovery device of a vehicle-mounted system of a hardware operating environment according to an embodiment of the present invention;

FIG. 2 is a schematic flow chart of a first embodiment of a recovery method of the vehicle system according to the present invention;

FIG. 3 is a schematic diagram of a vehicle system according to an embodiment of a recovery method of the vehicle system of the present invention;

FIG. 4 is a schematic overall flow chart of an embodiment of a recovery method of the vehicle system according to the present invention;

FIG. 5 is a flowchart of a second embodiment of a recovery method of the vehicle system according to the present invention;

FIG. 6 is a schematic diagram of Recovery process according to an embodiment of the Recovery method of the vehicle system of the present invention;

FIG. 7 is a flowchart of a third embodiment of a recovery method of the vehicle system according to the present invention;

FIG. 8 is a schematic diagram of a Bootloader recovery and recovery process according to an embodiment of the recovery and recovery method of the vehicle system of the present invention;

FIG. 9 is a flowchart of a recovery method of the vehicle system according to a fourth embodiment of the present invention;

FIG. 10 is a schematic diagram of a recovery and restoration process of an MCU according to an embodiment of the recovery and restoration method of the vehicle system of the present invention;

FIG. 11 is a block diagram illustrating a recovery device for a vehicle system according to a first embodiment of the present invention.

The achievement of the objects, functional features and advantages of the present invention will be further described with reference to the accompanying drawings, in conjunction with the embodiments.

Detailed Description

It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.

Referring to fig. 1, fig. 1 is a schematic diagram of a recovery device of a vehicle-mounted system in a hardware running environment according to an embodiment of the present invention.

As shown in fig. 1, the recovery device of the vehicle system may include: a processor 1001, such as a central processing unit (Central Processing Unit, CPU), a communication bus 1002, a user interface 1003, a network interface 1004, a memory 1005. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display, an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a Wireless interface (e.g., a Wireless-Fidelity (Wi-Fi) interface). The Memory 1005 may be a high-speed random access Memory (Random Access Memory, RAM) Memory or a stable nonvolatile Memory (NVM), such as a disk Memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above.

It will be appreciated by those skilled in the art that the structure shown in fig. 1 does not constitute a limitation of the recovery apparatus of the vehicle system, and may include more or fewer components than shown, or may combine certain components, or may have a different arrangement of components.

As shown in fig. 1, the memory 1005, which is a storage medium, may include an operating system, a network communication module, a user interface module, and a restoration program of the vehicle system.

In the recovery device of the vehicle system shown in fig. 1, the network interface 1004 is mainly used for performing data communication with a network server; the user interface 1003 is mainly used for data interaction with a user; the processor 1001 and the memory 1005 in the recovery and restoration device of the vehicle-mounted system can be arranged in the recovery and restoration device of the vehicle-mounted system, and the recovery and restoration device of the vehicle-mounted system invokes the recovery and restoration program of the vehicle-mounted system stored in the memory 1005 through the processor 1001 and executes the recovery and restoration method of the vehicle-mounted system provided by the embodiment of the invention.

The embodiment of the invention provides a recovery method of a vehicle-mounted system, and referring to fig. 2, fig. 2 is a schematic flow chart of a first embodiment of the recovery method of the vehicle-mounted system.

In this embodiment, the recovery and restoration method of the vehicle-mounted system includes the following steps:

step S10: and when the MCU system of the vehicle-mounted system detects a preset starting signal, starting the vehicle-mounted system.

It should be noted that, the execution main body of the embodiment is a vehicle, and a restoration method program of the vehicle system is provided in the vehicle, and restoration of the vehicle system is realized through the restoration method program of the vehicle system.

It CAN be understood that, as shown in fig. 3, the vehicle system includes an MCU (micro control unit) system and an SoC (system-on-chip) system, where the MCU system is composed of an APP partition and a Boot partition, and the Boot partition implements the CAN (controller area network) communication with the whole vehicle, power management of the vehicle system, and functions of upgrading the APP partition, and the APP partition implements application functions such as MCU system version information, vehicle sound effect setting, and vehicle information. The SoC System runs an Android (Android) System, and is composed of a Main System and a Recovery System, wherein the Recovery System is used for realizing functions such as System Recovery and Recovery, and the Main System is used for realizing Main functions of a vehicle, such as: push screen display, touch, video play, camera input and the like, and the SoC system supports the function of an external USB flash disk. The MCU system and the SoC system communicate through a UART (Universal Asynchronous Receiver/Transmitter ), the inquiry and acquisition of system state information, a heartbeat mechanism and the like are realized through related handshake protocols, and the corresponding man-machine interaction such as vehicle information display control, sound effect setting and the like is finished through related functional protocols. Boot of the MCU system and Bootloader of the Android system are usually strongly related to hardware, and recovery restoration is not supported generally. The SoC system has a USB interface, and may access an external memory, for example: and the U disk is provided with backup system program files.

It should be understood that the preset start signal is a preset start signal of the vehicle system, for example: the PEPS (Passive Entry Passive Start, intelligent access and start system) signal may be other start signals, which is not limited in this embodiment and can be flexibly adjusted according to practical situations.

In a specific implementation, when the MCU system detects signals such as PEPS, the vehicle-mounted system is started, and the SoC system starts to be started.

Step S20: when the SoC system of the vehicle system enters a Bootloader stage, the recorded value of the system damage zone bit is increased.

It should be noted that, the system damage flag bit is a currently used system damage flag bit, for example: flag_count, the recorded value refers to the value of the Flag bit.

In a specific implementation, in the stage that the SoC system walks to the Bootloader, the system is assumed to be damaged, the system damage Flag bit is recorded as flag_count, flag_count++ is written into the MIsc partition, and the value of the system damage Flag bit is increased.

Step S30: acquiring a starting state of an Android system in the SoC system, and determining whether the Android system is damaged according to the starting state.

Further, the step S30 further includes: and when the starting state meets a preset system starting completion state, determining that the Android system is in normal operation, and when the Android system is in normal operation, resetting the recorded numerical value, and executing step S50.

It can be understood that the start-up state refers to a start-up condition of the Android system, and the preset system start-up completion state refers to a system start-up completion attribute sys.

In a specific implementation, if the system service MCUService reads that the system startup completion attribute sys.boot_completed is 1, the current Android system is considered to be intact, flag_count is cleared, and if the system startup completion attribute cannot be acquired, it is indicated that MCUService cannot be started, and the current Android system is considered to be damaged.

It should be understood that if the Android system cannot be started normally, the MCUService service cannot be started either, and flag_count cannot be cleared.

Step S40: when the Android system is damaged, determining a target recovery and restoration strategy in a preset SoC recovery and restoration strategy according to the recorded value, recovering and restoring the Android system according to the target recovery and restoration strategy, and restarting the Android system after successful recovery and restoration.

It should be noted that the preset SoC restoration policy refers to restoration logic of the SoC System, including a Recovery restoration policy and a Bootloader restoration policy, where the Recovery restoration policy is performed in a Recovery System, and the Bootloader restoration policy is performed in a Bootloader. The target restoration policy is a restoration policy which is currently required to be used.

It can be understood that, in order to determine a suitable restoration policy to restore, the present embodiment sets two thresholds of the recorded values, which are a first preset accumulation value and a second preset accumulation value, respectively, where the first preset accumulation value is greater than the second preset accumulation value, for example: the first preset accumulation value is 8, the second preset accumulation value is 3, and other values can be used, which is not limited in this embodiment and can be adjusted according to practical situations. And when the recorded value is smaller than the first preset accumulated value and is larger than or equal to the second preset accumulated value, the Recovery strategy is used as the target Recovery strategy.

In the specific implementation, if the recorded numerical value meets the condition that 3 is less than or equal to flag_count < 8, the system Recovery program is considered to be normal, and a Recovery strategy is entered; when the condition flag_count is more than or equal to 8, the Recovery strategy is considered to be failed, the system Recovery program is damaged, and the Bootloader Recovery strategy is entered. And restarting the Android system after the Android system is successfully restored.

Further, when the recorded value is smaller than a second preset accumulated value, performing heartbeat monitoring on the SoC system through the MCU system, recording a heartbeat time, and restarting the SoC system when the heartbeat time is greater than the preset heartbeat time, and returning to execute step S20.

It should be understood that a heartbeat handshake mechanism is arranged between the SoC system and the MCU system, the heartbeat time refers to the duration of the heartbeat of the SoC system, the preset heartbeat time refers to a set time threshold value, and the preset heartbeat time is used for judging whether the heartbeat of the SoC system is overtime or not, and the value of the preset heartbeat time can be adjusted according to actual conditions.

In a specific implementation, after judging that the Android system is damaged, if flag_count is less than 3, if the MCU system detects that the heartbeat of the SoC system is overtime, the SoC system is powered off and restarted, and whether the Android system is damaged is judged again.

Step S50: and reading preset system compiling attributes in the Android system, and determining MCU compatible version numbers according to the preset system compiling attributes.

It should be noted that, the preset system compiling attribute is a custom system compiling attribute, and is obtained through MCUService, and the MCU compatible version numbers refer to all compatible version numbers of the MCU, which form a version number array.

In a specific implementation, when the Android system operates normally, the MCUService reads the custom system compiling attribute and obtains the MCU compatible version number from the custom system compiling attribute.

It can be understood that there are two situations in normal operation of the Android system, and the normal operation can be realized after the recovery is successful and the normal operation can be realized without the recovery.

Step S60: and acquiring a current MCU version number of the MCU system, and when the current MCU version number does not accord with the MCU compatible version number, recovering and recovering the MCU system by using a preset MCU recovery and recovery strategy so as to successfully match the Android system and the MCU system, wherein the vehicle-to-machine system works normally.

It should be understood that the current MCU version number refers to the version number currently used by the MCU system. The current MCU version number does not conform to the MCU compatible version number and comprises two cases, the current MCU version number is not in the compatible version number and the current MCU version number is not obtained. The preset MCU restoration strategy refers to restoration logic of the MCU system, and is performed in the MCU system.

In a specific implementation, if the detected current MCU version number is not in the acquired compatible version number or the MCU version number is not acquired, the Android system program is not matched with the currently running MCU system program version, a preset MCU restoration strategy is used for restoration, and after restoration is successful, the Android and MCU version are successfully matched, so that the vehicle-to-machine system can work normally.

As shown in the overall flow diagram of fig. 4, the vehicle system is started, android Bootloader in the SoC system is started, the system damage Flag bit is flag_count++, when the Android system is not normally started, whether the system damage Flag bit flag_count is greater than or equal to 8 is judged, if yes, bootloader restoration logic is entered; if the system damage Flag bit flag_count is smaller than 8, judging whether the system damage Flag bit flag_count is larger than or equal to 3, if so, entering a Recovery logic; if the system damage Flag bit flag_count is smaller than 3, the MCU system monitors that the heartbeat of the SoC system is overtime, and the SoC system is powered off and restarted. When the system starting completion attribute sys.boot_completed read by the system service MCUService is 1, the current Android system is considered to be intact, flag_count is cleared, the MCUService detects whether the MCU system version is matched with the Android system through a handshake protocol, if so, the vehicle-mounted system is recovered to be normal, and if not, the preset MCU recovery and restoration logic is entered.

In this embodiment, when an SoC system of a vehicle-mounted system enters a Bootloader stage, a record value of a system damage flag bit is added to obtain a start-up state of an Android system in the SoC system, whether the Android system is damaged is determined according to the start-up state, when the Android system is damaged, a target recovery and restoration strategy is determined in a preset SoC recovery and restoration strategy according to the record value, the Android system is restored and restored according to the target recovery and restoration strategy, the Android system is restarted after successful recovery and restoration, a preset system compiling attribute in the Android system is read, an MCU compatible version number is determined according to the preset system compiling attribute, a current MCU version number of the MCU system is obtained, and when the current MCU version number does not accord with the MCU compatible version number, the MCU system is restored and restored by using the preset MCU recovery and restoration strategy, so that the Android system and the MCU system are successfully matched, and the vehicle-mounted system normally works. Because most of the vehicle machine systems only support a Recovery and restoration mechanism by an Android system running on an SoC end, an MCU end is generally not supported, and once a system Recovery program Recovery is damaged, the Recovery and restoration mechanism of the Android system is invalid.

Referring to fig. 5, fig. 5 is a flowchart illustrating a recovery method of a vehicle system according to a second embodiment of the present invention.

Based on the first embodiment, the step S40 includes:

step S401: and when the starting state does not meet a preset system starting completion state, determining that the Android system is damaged.

In a specific implementation, if the system start completion attribute cannot be obtained, it is indicated that MCUService cannot be started, and the current Android system is considered to be damaged.

Step S402: and obtaining the recorded numerical value, and comparing the recorded numerical value with a first preset accumulated numerical value.

In a specific implementation, the value of the system corruption Flag flag_count is compared with a first preset accumulated value 8.

Step S403: and when the recorded value is smaller than the first preset accumulated value, comparing the recorded value with a second preset accumulated value.

In a specific implementation, when the value of the system failure Flag bit flag_count is smaller than 8, the system Recovery program is considered to be normal at the moment, and the value of the system failure Flag bit flag_count is compared with a second preset accumulated value 3.

Step S404: and when the recorded value is greater than or equal to a second preset accumulated value, determining that the target Recovery strategy is a Recovery strategy.

In a specific implementation, when the value of the system damage Flag bit flag_count is smaller than 8 and larger than or equal to 3, recovering and restoring the Android system by using a Recovery strategy.

Step S405: acquiring file information under a preset catalog, and determining whether a system restoration package exists under the preset catalog according to the file information.

It should be noted that, the system restore package is file data required by system restore, including an Android system upgrade package, an MCU upgrade package, and a configuration file version. The preset directory is a directory of a system restoration package obtained when the system is restored, and in this embodiment, the preset directory is set to mnt/sdcard/. Update, and the file information refers to information of all files existing in the preset directory.

In a specific implementation, after entering a Recovery strategy, whether a system Recovery package exists in the mnt/sdcard/. Update directory is required to be judged, so that the system Recovery package is acquired later to recover and recover the Android system.

Step S406: and when the system restoration package exists under the preset catalog, mapping the system restoration package to a process memory space so as to restore the Android system.

It will be appreciated that the mapping of the system restore packet to the process memory space may use mmap method, or other methods of mapping files may be used, which is not limited in this embodiment.

In a specific implementation, a mmap method is called, system restoration packet data is mapped from mnt/sdcard/. Update to a process memory space, the integrity and the legality of the system restoration packet are checked, and a Recovery process creates an update-binary sub-process to execute restoration.

Further, when the system restoration packet does not exist under the preset directory, a system restoration packet in an external memory is obtained, the system restoration packet in the external memory is decompressed to the preset directory, and step S406 is executed.

In a specific implementation, the mnt/sdcard/. Update does not have a system restore package, and the system interface may prompt: after the user inserts the U disk, the SoC system identifies and mounts the U disk, decompresses the system restoration packet in the U disk to the mnt/sdcard/. Update directory, and performs the next system restoration packet mapping.

Step S407: after the Android system is successfully restored, the MIsc partition is erased, the Recovery upgrading flag bit is cleared, the recorded numerical value is cleared, and the Android system is restarted.

In a specific implementation, after the Android System is successfully restored, exiting the update-binary sub-process, erasing the MIsc partition, clearing the values of the Recovery upgrading Flag bit and the System damage Flag bit flag_count, and normally starting the Android System to the Main System after restarting.

As shown in a Recovery flow chart of fig. 6, when the value of the flag_count of the system damage is less than 8 and greater than or equal to 3, entering Recovery logic, judging whether a system Recovery packet exists under the mnt/sdcard/. Update, if so, calling a mmap method to map the data of the system Recovery packet from the mnt/sdcard/. Update to a process memory space, and creating an update-binary sub-process by the Recovery process to execute Recovery; if the system restoration packet does not exist, after the user inserts the U disk with the system restoration packet, the SoC system identifies and mounts the U disk, and decompresses the system restoration packet to the mnt/sdcard/. Update directory for the next system restoration packet mapping. After the Android system is successfully restored, the MIsc partition is erased, the Recovery upgrading Flag bit and the flag_count are cleared, and the Android system is restarted.

In this embodiment, when the startup state does not meet the preset system startup completion state, determining that the Android system is damaged, acquiring the record value, comparing the record value with a first preset accumulation value, when the record value is smaller than the first preset accumulation value, comparing the record value with a second preset accumulation value, when the record value is greater than or equal to the second preset accumulation value, determining that the target Recovery strategy is a Recovery strategy, acquiring file information under the preset catalog, determining whether a system Recovery package exists under the preset catalog according to the file information, mapping the system Recovery package to a process memory space when the system Recovery package exists under the preset catalog, so that the Android system is recovered, after the Android system is successfully recovered, erasing a misc partition, clearing a Recovery upgrade flag bit, resetting the record value, and restarting the Android system. When the system Recovery program is normal, the backup file can be loaded from the USB flash disk or the built-in storage of the system to restore the Android system, so that a restoring mechanism under the SoC-end Android system is realized.

Referring to fig. 7, fig. 7 is a flowchart illustrating a recovery method of a vehicle system according to a third embodiment of the present invention.

Based on the second embodiment, after the step S402, the method further includes:

step S403': and when the recorded value is greater than or equal to a first preset accumulated value, determining that the target recovery strategy is a Bootloader recovery strategy.

In a specific implementation, when the value of the system damage Flag bit flag_count is greater than or equal to 8, the system Recovery program is considered to be damaged at the moment, and a Bootloader Recovery strategy is used for recovering and recovering the Android system.

Step S404': and mounting the backup partition and the root file system.

It can be understood that when the vehicle is produced and shipped in quantity, the main partition (recovery partition, boot partition and system partition) of the Android system and the MUC (micro unit control unit) upgrade file MUC. Bin are manufactured into a backup partition sysbackup, and the backup partition is burnt into the system eMMC (Embedded Multi Media Card, embedded memory standard specification) when the vehicle is produced in a production line. The backup partition defaults to be not mounted, so that the backup partition loss caused by abnormal power failure or error writing and other operations can not occur when the system operates, the created backup partition has a EXT4 (Fourth extended filesystem, fourth-generation extended file system) type file system format, and the corresponding mirror image file can be restored to the appointed partition directory conveniently through the read-write operation of the file during restoration.

In a specific implementation, after a Bootloader restoration logic is entered, a sysbackup partition is mounted in the Bootloader to a/sysbackup directory, and a root file system is mounted in the Bootloader.

Step S405': and reading the image file in the backup partition, and restoring the image file to the corresponding main partition.

It should be understood that the main partition refers to a main partition in the Android system, including a recovery partition, a boot partition and a system partition, and the image files are a recovery image file recovery. Img, a boot image file boot. Img and a system image file system. Img.

In a specific implementation, the recovery. Img, boot. Img, and system. Img are read from the/sysbackup directory through the file system interface and restored to the recovery partition, boot partition, and system partition, respectively. After the mirror image files in the backup partition sysbackup are restored successfully, unloading the sysbackup partition to ensure that the files in the backup partition cannot be lost.

Step S406': and after the Android system is successfully restored, erasing a MIsc partition, clearing the recorded numerical value, and restarting the Android system.

In the specific implementation, the Bootloader restores the Android system successfully, erases the misc partition, clears the system damage Flag bit flag_count, and the Android system can be started normally after restarting.

And (3) starting a Bootloader recovery flow chart shown in fig. 8, entering Bootloader recovery logic of an Android system in the SoC system, mounting a sysback partition to/sysback in the Bootloader, mounting a root file system in the Bootloader, reading a recovery. Img, a boot. Img and a system. Img from/sysback directory through a file system interface, respectively recovering to the recovery partition, the boot partition and the system partition, unloading the sysback partition after the partition is recovered successfully, resetting a system damage Flag flag_Count, and restarting the Android system.

In this embodiment, when the recorded value is greater than or equal to a first preset accumulated value, determining that the target recovery strategy is a Bootloader recovery strategy, mounting a backup partition and a root file system, reading an image file in the backup partition, recovering the image file to a corresponding main partition, so that the Android system is recovered, after the Android system is successfully recovered, erasing the MIsc partition, resetting the recorded value, and restarting the Android system. When the system Recovery program is damaged, a Bootloader can be used for restoring the backup files in the default factory preset partition of the system, so that the defect of a native restoring mechanism of the SoC-end Android system is overcome, the stability of the vehicle-mounted system is improved, and the user experience is ensured.

Referring to fig. 9, fig. 9 is a flowchart of a recovery method of a vehicle system according to a fourth embodiment of the present invention.

Based on the first embodiment, the step S60 includes:

step S601: and acquiring a current MCU version number of the MCU system, and acquiring a factory preset version number of the MCU and an upgrade backup version number of the MCU when the current MCU version number does not accord with the MCU compatible version number.

It should be noted that, the MCU factory preset version number refers to an MCU version number in a default factory preset system, and the MCU upgrade backup version number refers to an MCU version number in an upgrade backup system.

In a specific implementation, the Android system MCUService service reads a custom system compiling attribute to obtain a compatible version number group compatible version Vers of the MCU, and if the current MCU version number is detected not to be in the compatible version Vers, or the MCU version number is not obtained, the method enters the MCU restoration and restoration logic. And the Android system MCUService service reading system compiles the attribute to obtain the version number of the MCU in the default factory preset system, and reads/mnt/sdcard/. Update/version.xml to obtain the version number of the MCU in the upgrade backup system.

Step S602: and comparing the MCU upgrade backup version number and the MCU factory preset version number with the MCU compatible version number to obtain a comparison result.

It will be appreciated that the comparison results refer to a match between version numbers.

In a specific implementation, whether the version numbers of the upgrade backup version number of the MCU and the factory preset version number of the MCU are in the compatible version [ ].

Step S603: and obtaining an MCU upgrade file according to the comparison result, and copying the MCU upgrade file to a preset MCU upgrade directory.

Further, when the MCU upgrade backup version number is matched with the compatible version number, taking the MCU system file under the backup upgrade directory as an MCU upgrade file; when the MCU factory preset version number is matched with the compatible version number, taking a default factory preset MCU system file as an MCU upgrading file; and when the MCU factory preset version number and/or the MCU upgrade backup version number are not matched with the compatible version number, taking the MCU system package in the external memory as an MCU upgrade file.

It should be understood that the MCU upgrade file refers to file data MCU. Bin required for restoration, and the MCU system package refers to a system restoration package matched with version numbers in compactibelvers [ ], for restoration of the MCU system. The preset MCU upgrading catalog is/mnt/sdcard/. MCU. When the MCU upgrade backup version number is matched with the MCU compatible version number, the MCU system file under the backup upgrade directory can be used for automatic recovery and restoration, when the MCU factory preset version number is matched with the MCU compatible version number, the MCU system file preset by default can be used for automatic recovery and restoration, and when the MCU factory preset version number is not matched with the MCU compatible version number, the matched MCU system package in the U disk is needed.

In the specific implementation, firstly judging whether the MCU upgrading backup version number is matched with the MCU compatible version number, if so, copying the MCU system file from the backup upgrading catalog/mnt/sdcard/. Update to/mnt/sdcard/. MCU, if not, further judging whether the MCU factory preset version number is matched with the MCU compatible version number, if so, mounting the backup partition sysback to/sysback, copying the MCU system file from/sysback to/mnt/sdcard/. MCU, and unloading the sysback partition. If the MCU upgrade backup version number and the MCU factory preset version number are not matched with the MCU compatible version number, prompting on a vehicle-computer system interface: the system recovery and restoration method includes the steps that a U disk with an MCU version file with a compatible version Vers median is inserted, after a user inserts a corresponding U disk, the system identifies and mounts the U disk, and an MCU system recovery package is copied to the position of/mnt/sdcard/. MCU.

Step S604: and restarting the vehicle-to-machine system when the MCU system receives an upgrade instruction sent by the Android system through the UART, so that the MCU system upgrades according to the MCU upgrade file after receiving the MCU upgrade file sent by the Android system through the UART.

In a specific implementation, after the Android system extracts a corresponding upgrade file of the MCU system, an upgrade instruction is sent to the MCU system through a UART, the MCU system is informed to enter an upgrade mode for upgrade, meanwhile, the vehicle machine system is restarted, the MCU enters the upgrade mode, the Android system sends MCU. Bin under the condition of/mnt/sdcard/. MCU to the MCU system through the UART, and the MCU starts to execute upgrade.

Step S605: and deleting the preset MCU upgrading directory after the MCU system is successfully upgraded, determining that the MCU system is successfully restored, restarting the vehicle-to-machine system, so that the Android system and the MCU system are successfully matched, and enabling the vehicle-to-machine system to work normally.

In the specific implementation, after the MCU is successfully upgraded, the Android system is deleted/mnt/sdcard/. MCU is used for completing system recovery, the MCU exits from the upgrading mode, the vehicle system is restarted, and at the moment, the Android and MCU versions are successfully matched, so that the vehicle system can work normally.

As shown in the schematic diagram of the MCU restoration flow shown in fig. 10, the Android system MCUService service obtains the version number of the MCU in the default factory preset system and the version number of the MCU in the upgrade backup system, queries whether the two version numbers are matched with the compatible version numbers, and when the two version numbers are matched, judges whether to use the MCU system file under the backup upgrade directory or the default factory preset MCU system file to restore automatically, and when the two version numbers are not matched, prompts the user to insert a U disc with the MCU system package of the matched version to restore, and after the Android end extracts the corresponding MCU system upgrade file, the Android end notifies the MCU system to enter the upgrade mode for upgrade through the UART, and after the MCU is restored successfully, the Android and MCU versions are successfully matched, and the vehicle system can work normally.

In this embodiment, the MCU factory preset version number and the MCU upgrade backup version number are obtained, the MCU upgrade backup version number and the MCU factory preset version number are compared with the MCU compatible version number to obtain a comparison result, an MCU upgrade file is obtained according to the comparison result, the MCU upgrade file is copied to a preset MCU upgrade directory, when the MCU system receives an upgrade instruction sent by the Android system through the UART, the vehicle system is restarted, so that the MCU system upgrades according to the MCU upgrade file after receiving the MCU upgrade file sent by the Android system through the UART, after the MCU system is successfully upgraded, the preset MCU upgrade directory is deleted, and the MCU system is determined to be successfully restored and restarted. When the program version of the Android system is not matched with the program version of the currently running MCU system, the MCU restoration logic is entered, restoration and restoration are carried out at the MCU end, the restoration mechanism of the MCU system in the vehicle-mounted system is perfected, the matching of the program versions of the MCU system and the SoC system is ensured, the problem that after the restoration and restoration of a single system, the function of the whole vehicle-mounted system is abnormal due to the fact that the program versions of two systems are not matched is avoided, the stability of the vehicle-mounted system is improved, and user experience is ensured.

Referring to fig. 11, fig. 11 is a block diagram illustrating a first embodiment of a recovery device of a vehicle system according to the present invention.

As shown in fig. 11, a recovery device for a vehicle-mounted system according to an embodiment of the present invention includes:

and the judging module 10 is used for starting the vehicle-mounted system when the MCU system of the vehicle-mounted system detects a preset starting signal.

The judging module 10 is further configured to increase a record value of a system damage flag bit when the SoC system of the vehicle-mounted system enters a Bootloader stage.

The judging module 10 is further configured to obtain a starting state of an Android system in the SoC system, and determine whether the Android system is damaged according to the starting state.

The restoration module 20 is configured to determine a target restoration policy in a preset SoC restoration policy according to the record value when the Android system is damaged, restore the Android system according to the target restoration policy, and restart the Android system after successful restoration, where the preset SoC restoration policy includes a restoration policy and a Bootloader restoration policy.

The restoration module 20 is further configured to read a preset system compiling attribute in the Android system, and determine an MCU compatible version number according to the preset system compiling attribute.

The restoration module 20 is further configured to obtain a current MCU version number of the MCU system, and restore the MCU system by using a preset MCU restoration policy when the current MCU version number does not conform to the MCU compatible version number, so that the Android system and the MCU system are successfully matched, and the vehicle-to-machine system works normally.

In this embodiment, when the SoC system of the vehicle-mounted system enters a Bootloader stage, a record value of a system damage flag bit is added to obtain a start state of an Android system in the SoC system, according to the start state, whether the Android system is damaged is determined, when the Android system is damaged, a target recovery strategy is determined in a preset SoC recovery strategy according to the record value to recover and restore, the Android system is restarted after successful recovery and restore, a preset system compiling attribute in the Android system is read, an MCU compatible version number is determined according to the preset system compiling attribute, a current MCU version number of the MCU system is obtained, and when the current MCU version number does not conform to the MCU compatible version number, the MCU system is recovered and restored by using the preset MCU recovery strategy, so that the Android system and the MCU system are successfully matched, and the vehicle-mounted system works normally. Because most of the vehicle machine systems only support a Recovery and restoration mechanism by an Android system running on an SoC end, an MCU end is generally not supported, and once a system Recovery program Recovery is damaged, the Recovery and restoration mechanism of the Android system is invalid.

In an embodiment, the restoration module 20 is further configured to determine that the Android system is damaged when the start-up state does not meet a preset system start-up completion state;

In an embodiment, the restoration module 20 is further configured to obtain a system restoration package in an external memory when the system restoration package does not exist under the preset directory;

In an embodiment, the restoration module 20 is further configured to determine that the target restoration policy is a Bootloader restoration policy when the recorded value is greater than or equal to a first preset accumulated value;

mounting a backup partition and a root file system;

In an embodiment, the restoration module 20 is further configured to perform heartbeat monitoring on the SoC system through the MCU system and record a heartbeat time when the recorded value is less than a second preset accumulated value;

In an embodiment, the restoration module 20 is further configured to obtain a factory preset version number of the MCU and an upgrade backup version number of the MCU;

In an embodiment, the restoration module 20 is further configured to use the MCU system file in the backup upgrade directory as the MCU upgrade file when the MCU upgrade backup version number matches the compatible version number;

The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. Read Only Memory)/RAM, magnetic disk, optical disk) and including several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method according to the embodiments of the present invention.

The foregoing description is only of the preferred embodiments of the present invention, and is not intended to limit the scope of the invention, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.

Claims

1. The recovery and restoration method of the vehicle-mounted system is characterized in that the vehicle-mounted system comprises an MCU system and a SoC system, the SoC system comprises an Android system, the MCU system and the SoC system communicate through a UART, and the recovery and restoration method of the vehicle-mounted system comprises the following steps:

acquiring a current MCU version number of the MCU system, and when the current MCU version number does not accord with an MCU compatible version number, recovering and recovering the MCU system by using a preset MCU recovery and recovery strategy to successfully match the Android system and the MCU system, wherein the vehicle-to-machine system works normally;

when the Android system is damaged, determining a target recovery strategy in a preset SoC recovery strategy according to the recorded numerical value, recovering and recovering the Android system according to the target recovery strategy, and restarting the Android system after successful recovery and recovery, wherein the method comprises the following steps:

after the Android system is successfully restored, the MIsc partition is erased, the Recovery upgrading flag bit is cleared, the recorded numerical value is cleared, and the Android system is restarted;

the step of obtaining the recorded value, and after comparing the recorded value with a first preset accumulated value, the step of further comprises:

mounting a backup partition and a root file system;

2. The method of claim 1, wherein after obtaining the file information in the preset directory and determining whether the system restore packet exists in the preset directory according to the file information, further comprises:

3. The method of claim 1, wherein said comparing said recorded value with a second predetermined cumulative value when said recorded value is less than said first predetermined cumulative value further comprises:

4. A method according to any one of claims 1 to 3, wherein the restoration of the MCU system using a preset MCU restoration policy comprises:

5. The method of claim 4, wherein the obtaining the MCU upgrade file according to the comparison result comprises:

6. The recovery device of the vehicle-mounted system is characterized by comprising the following components:

the restoration module is further configured to obtain a current MCU version number of the MCU system, and restore the MCU system by using a preset MCU restoration policy when the current MCU version number does not conform to the MCU compatible version number, so that the Android system and the MCU system are successfully matched, and the vehicle-to-machine system works normally;

the restoration module is further used for determining that the Android system is damaged when the starting state does not meet a preset system starting completion state;

the restoration module is further configured to determine that the target restoration policy is a Bootloader restoration policy when the recorded value is greater than or equal to a first preset accumulated value;

mounting a backup partition and a root file system;

7. A restoration apparatus of a vehicle-mounted system, the apparatus comprising: a memory, a processor, and a restoration program of a vehicle system stored on the memory and operable on the processor, the restoration program of the vehicle system configured to implement the steps of the restoration method of the vehicle system according to any one of claims 1 to 5.

8. A storage medium, wherein a restoration program of an on-vehicle system is stored on the storage medium, and the restoration program of the on-vehicle system, when executed by a processor, implements the steps of the restoration method of an on-vehicle system according to any one of claims 1 to 5.