CN114356384A

CN114356384A - Vehicle-mounted system updating method, vehicle-mounted system detecting method and vehicle-mounted system detecting system

Info

Publication number: CN114356384A
Application number: CN202111583228.4A
Authority: CN
Inventors: 刘维彬; 邓郁霖; 林乔捷; 闫雪
Original assignee: Guangzhou Xiaopeng Motors Technology Co Ltd
Current assignee: Guangzhou Xiaopeng Motors Technology Co Ltd
Priority date: 2021-12-22
Filing date: 2021-12-22
Publication date: 2022-04-15

Abstract

The application relates to a vehicle-mounted system updating method, a vehicle-mounted system detecting method and a vehicle-mounted system detecting system. The method comprises the following steps: selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system, and using the rest vehicle-mounted systems as standby systems; starting the main system to provide vehicle-mounted system functions; and acquiring an update data packet, updating the standby system according to the update data packet, and setting a part of the standby system as a default started vehicle-mounted system. The scheme provided by the application can ensure normal use of the current vehicle-mounted system in the process of updating the vehicle-mounted system, improves functional reliability of the vehicle-mounted system, and improves vehicle safety.

Description

Vehicle-mounted system updating method, vehicle-mounted system detecting method and vehicle-mounted system detecting system

Technical Field

The application relates to the technical field of intelligent automobiles, in particular to a vehicle-mounted system updating method, a vehicle-mounted system detecting method and a vehicle-mounted system detecting system.

Background

The vehicle-mounted system, or called vehicle-mounted terminal system, is a management control system of a vehicle, and integrates functions of on-line monitoring, scheduling management, report management, real-time vehicle condition information management and the like, for example, to realize display control of an intelligent liquid crystal instrument of an automobile. The reliable and stable vehicle-mounted system can guarantee the driving safety of the automobile and ensure good automobile using experience of a driver.

However, in the process of upgrading and updating the system of the vehicle-mounted system, the instrument may not be used or the vehicle-mounted system may have functional disorder, and the vehicle-mounted system may be normally used after waiting for a long time for updating, so that the functional reliability of the instrument is affected, the vehicle-using experience of a user is affected, and the vehicle safety is reduced.

Disclosure of Invention

In order to solve or partially solve the problems in the related art, the application provides an updating method, a detection method and a system of a vehicle-mounted system, which can ensure the normal use of the current vehicle-mounted system in the process of updating the vehicle-mounted system, improve the functional reliability of the vehicle-mounted system and improve the safety of the vehicle.

The first aspect of the present application provides a vehicle-mounted system updating method, which is applied to a vehicle-mounted chip, where at least two vehicle-mounted systems are stored in advance, and the method includes:

selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system, and using the rest vehicle-mounted systems as standby systems;

starting the main system to provide vehicle-mounted system functions;

and acquiring an update data packet, updating the standby system according to the update data packet, and setting a part of the standby system as a default started vehicle-mounted system.

In one embodiment, the selecting one of at least two pre-stored in-vehicle systems as the main system includes:

reading a starting parameter;

and selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system according to the read starting parameters.

In one embodiment, the setting a share of the standby system as a default enabled vehicle-mounted system includes: and setting a spare system as a default started vehicle-mounted system by resetting the starting parameters.

In one embodiment, the update package is a system upgrade package or a system repair package.

In one embodiment, the method further comprises:

and detecting the standby system, and repairing the standby system with abnormal detection result.

In one embodiment, the updating the standby system according to the update package includes: and dynamically adjusting the read-write delay size of the disk and/or the read-write data block size of the disk according to the load condition of the main system.

In an embodiment, the dynamically adjusting the size of the disk read-write latency and/or the size of the disk read-write data block according to the load condition of the host system includes:

when the main system is in a low load condition, reducing the disk read-write delay and/or increasing the disk read-write data block; and under the condition that the main system is under a high load, the disk reading and writing delay is increased and/or the disk reading and writing data blocks are decreased.

In one embodiment, the startup parameter is at least two; the starting parameter contains a writing time mark;

the read initiation parameters include: and reading the starting parameters according to the writing times mark or according to the verification result of the starting parameters.

In one embodiment, before selecting one of the at least two pre-stored in-vehicle systems as the main system, the method further includes:

loading a bootstrap program;

after the boot program is loaded successfully, selecting one vehicle-mounted system from at least two pre-stored vehicle-mounted systems as a main system;

and starting the emergency vehicle-mounted system after the loading failure of the bootstrap program.

In one embodiment, after selecting one of the at least two pre-stored in-vehicle systems as the main system, the method further includes:

detecting whether the firmware of the main system is normal;

after the firmware of the main system is determined to be normal, starting the main system;

and after determining that the firmware of the main system is abnormal, selecting one spare system as the main system or starting an emergency vehicle-mounted system according to the firmware detection result of the spare system.

In one embodiment, after the activating the main system, the method further includes:

responding to a monitoring request of a micro-processing chip, and sending operation data of a main system to the micro-processing chip so that the micro-processing chip sends a recovery request after detecting that the operation data is abnormal;

and responding to a recovery request of the micro-processing chip, and switching a main system to start the standby system to replace the main system.

The second aspect of the present application provides a vehicle-mounted system detection method, which is applied to a vehicle-mounted chip, where at least two vehicle-mounted systems are stored in advance, and the method includes: selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system, and using the rest vehicle-mounted systems as standby systems;

starting the main system to provide vehicle-mounted system functions;

responding to a monitoring request of a micro-processing chip, and sending the running data of the main system to the micro-processing chip so that the micro-processing chip sends a recovery request after detecting that the running data is abnormal;

and responding to a recovery request of the micro-processing chip, and switching the main system to start the standby system to replace the main system.

In one embodiment, the method further comprises:

after the main system switching fails, sending a recovery failure signal to the micro-processing chip, so that the micro-processing chip sends an emergency request after receiving the recovery failure signal;

and responding to the emergency request of the micro-processing chip, receiving an emergency vehicle-mounted system file, and starting an emergency vehicle-mounted system.

In one embodiment, the receiving the emergency onboard system file, starting the emergency onboard system, includes:

writing the received emergency vehicle-mounted system file from the vehicle-mounted information entertainment system terminal into a memory, and starting the emergency vehicle-mounted system from the memory; or the like, or, alternatively,

writing the received emergency vehicle-mounted system file from the embedded storage chip in the micro-processing chip into a memory, and starting the emergency vehicle-mounted system from the memory; or the like, or, alternatively,

and writing the emergency vehicle-mounted system file received through the network into the memory, and starting the emergency vehicle-mounted system from the memory.

A third aspect of the present application provides an on-vehicle system detection system, including: the system comprises a vehicle-mounted chip, a micro-processing chip and a vehicle-mounted information entertainment system terminal; the vehicle-mounted chip is respectively in communication connection with the microprocessor chip and the vehicle-mounted information entertainment system terminal, and the microprocessor chip is in communication connection with the vehicle-mounted information entertainment system terminal;

the vehicle-mounted chip is used for selecting one vehicle-mounted system from at least two pre-stored vehicle-mounted systems as a main system, and the rest vehicle-mounted systems as standby systems; starting the main system to provide vehicle-mounted system functions; responding to a monitoring request of a micro-processing chip, and sending the running data of the main system to the micro-processing chip so that the micro-processing chip sends a recovery request after detecting that the running data is abnormal; responding to a recovery request of the micro-processing chip, switching the main system to start the standby system to replace the main system;

the microprocessor chip is used for sending the monitoring request to the vehicle-mounted chip; receiving and detecting the running data of the main system sent by the vehicle-mounted chip; and sending a recovery request to the vehicle-mounted chip after the abnormal operation data is detected.

In an embodiment, the on-board chip is further configured to send a recovery failure signal to the microprocessor chip after a failure in switching the main system occurs, so that the microprocessor chip sends an emergency request after receiving the recovery failure signal; responding to the emergency request of the micro-processing chip, receiving an emergency vehicle-mounted system file, and starting an emergency vehicle-mounted system;

the microprocessor chip is also used for sending an emergency request after receiving a recovery failure signal sent by the vehicle-mounted chip;

and the vehicle-mounted information entertainment system terminal is also used for responding to the emergency request of the microprocessor chip and sending an emergency vehicle-mounted system file to the vehicle-mounted chip.

A fourth aspect of the present application provides an electronic device, comprising:

a processor; and

a memory having executable code stored thereon, which when executed by the processor, causes the processor to perform the method as described above.

A fifth aspect of the present application provides a computer-readable storage medium having stored thereon executable code, which, when executed by a processor of an electronic device, causes the processor to perform the method as described above.

The technical scheme provided by the application can comprise the following beneficial effects:

the method comprises the steps that one vehicle-mounted system is selected from at least two pre-stored vehicle-mounted systems to serve as a main system, and the rest vehicle-mounted systems serve as standby systems; starting a main system to provide vehicle-mounted system functions; and acquiring an update data packet, updating the standby system according to the update data packet and setting the standby system as a default started vehicle-mounted system. Therefore, the standby system can be updated in the operation of the main system, the effect of silent updating is achieved, the influence on the operation of the main system can be avoided, the stable operation of the main system is ensured, and the normal use of the instrument is guaranteed. And after the vehicle-mounted system is started next time, the updated vehicle-mounted system is operated as a main system. By executing the method again, all the vehicle-mounted systems can be updated, and the default started vehicle-mounted system is switched. According to the method, in the process of updating the vehicle-mounted system, the normal use of the current vehicle-mounted system is guaranteed, the functional reliability of the vehicle-mounted system is improved, and the safety of the vehicle is improved.

Further, the method provided by the application can select one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as the main system according to the read starting parameter by reading the starting parameter.

Further, the method provided by the application can be used for setting a spare system as a default started vehicle-mounted system by resetting the starting parameters.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The foregoing and other objects, features and advantages of the application will be apparent from the following more particular descriptions of exemplary embodiments of the application as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts throughout the exemplary embodiments of the application.

FIG. 1 is a schematic flow chart illustrating an in-vehicle system updating method according to an embodiment of the present disclosure;

FIG. 2 is another schematic flow chart diagram illustrating an in-vehicle system updating method according to an embodiment of the present application;

FIG. 3 is another schematic flow chart diagram illustrating an in-vehicle system updating method according to an embodiment of the present application;

FIG. 4 is another schematic flow chart diagram illustrating an in-vehicle system updating method according to an embodiment of the present application;

FIG. 5A is another schematic flow chart diagram illustrating an in-vehicle system updating method according to an embodiment of the present disclosure;

fig. 5B is a schematic structural diagram of a hardware architecture for implementing an on-board system updating method according to an embodiment of the present application;

FIG. 6 is a schematic flow chart illustrating a vehicle-mounted system detection method according to an embodiment of the present application;

FIG. 7 is a schematic structural diagram of an on-board system detection system according to an embodiment of the present disclosure;

fig. 8A is a schematic structural diagram of an on-board system updating apparatus according to an embodiment of the present application;

FIG. 8B is another schematic structural diagram of an in-vehicle system updating apparatus according to an embodiment of the present disclosure;

FIG. 9 is a schematic structural diagram of an on-board system detection device according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of an electronic device shown in an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described in more detail below with reference to the accompanying drawings. While embodiments of the present application are illustrated in the accompanying drawings, it should be understood that the present application may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms "first," "second," "third," etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the present application, "a plurality" means two or more unless specifically limited otherwise.

In the related art, when the vehicle-mounted system is updated and upgraded, the instrument may not be used or the vehicle-mounted system has a function disorder, and the vehicle-mounted system can be normally used after waiting for a long time for updating, so that the reliability of the function of the instrument is influenced, the vehicle-using experience of a user is influenced, and the safety of the vehicle is reduced.

In order to solve the above problem, an embodiment of the present application provides a method for updating a vehicle-mounted system, which can ensure normal use of a current vehicle-mounted system in a process of updating the vehicle-mounted system, improve functional reliability of the vehicle-mounted system, and improve vehicle safety.

The technical solutions of the embodiments of the present application are described in detail below with reference to the accompanying drawings.

Fig. 1 is a schematic flowchart of an updating method for an in-vehicle system according to an embodiment of the present application. The method in the embodiment of fig. 1 may be applied to a vehicle-mounted Chip, where at least two vehicle-mounted systems are stored in advance in the vehicle-mounted Chip, the vehicle-mounted Chip may be an SOC (System on Chip) Chip, and is used as a main Chip of instrument hardware, and the vehicle-mounted Chip may be used for display control of an instrument screen.

Referring to fig. 1, the method includes:

and S101, selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system, and using the rest vehicle-mounted systems as standby systems.

Wherein, the at least two vehicle-mounted systems can be two vehicle-mounted systems, such as a vehicle-mounted system A and a vehicle-mounted system B; the at least two on-board systems may be a plurality of on-board systems of two or more. Each on-board system may be an identical system, and each on-board system may be stored on a disk of an on-board chip in advance. The in-vehicle system may be an operating system for an in-vehicle terminal, such as a Linux system; the in-vehicle system may be used to perform display control of in-vehicle system information.

Further, selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system may include: reading a starting parameter; and selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system according to the read starting parameters.

The starting parameter may be a data file stored in the vehicle-mounted chip, and the written content of the starting parameter may correspond to a piece of vehicle-mounted system. By reading the starting parameters, one vehicle-mounted system corresponding to the starting parameters can be determined from at least two vehicle-mounted systems.

And step S102, starting the main system to provide the functions of the vehicle-mounted system.

In this step, the main system is activated, that is, one of the on-board systems selected as the main system in the activation step S101 is activated, and the activated main system is used to provide on-board system functions (such as a vehicle instrument function), thereby ensuring normal use of the on-board system and normal use of the vehicle instrument.

And S103, acquiring an updating data packet, updating the standby system according to the updating data packet, and setting a standby system as a default started vehicle-mounted system.

In this step, the update data packet may be obtained in response to the system reminder push. The system reminding pushing can be system upgrading pushing or system repairing pushing, and the updating data packet can be a system upgrading data packet or a system repairing data packet. Further, the update package may be obtained from a vehicle infotainment system terminal connected to the vehicle chip, and the vehicle infotainment system terminal may obtain the update package through an OTA Technology (Over-the-Air Technology).

Wherein updating the standby system based on the update package may be performed after determining that the update package is correct. That is, before the backup system is updated according to the update packet, the update packet may be checked, and after the check is passed, the backup system may be updated according to the update packet. After determining that the update data packet is in error (i.e., the update data packet does not pass the verification), the update data packet may be obtained again from the in-vehicle infotainment system terminal connected to the in-vehicle chip and verified again. Therefore, the updating data packet for updating the standby system can be ensured to pass the verification, so that the updating safety and the updating accuracy of the standby system can be ensured.

It can be understood that, if the update data packet is a system upgrade data packet, the backup system is updated by using the update data packet, so as to upgrade the backup system. And if the update data packet is a system repair data packet, updating the standby system by using the update data packet so as to realize repair of the standby system. Because the updating process aims at the standby system, the silent updating of the standby system is realized, the influence on the operation of the main system can be avoided, the stable operation of the main system is ensured, and the normal use of the instrument is ensured.

The spare system is set as the default started vehicle-mounted system, so that the updated spare system can be started after the vehicle-mounted chip is restarted. That is, after the vehicle-mounted system is started next time, the updated vehicle-mounted system will operate as the main system. It can be found that by executing the above method again, the updating of all the vehicle-mounted systems can be completed, and the default started vehicle-mounted system can be switched.

Further, setting a spare system as a default started vehicle-mounted system may include: and setting a spare system as a default started vehicle-mounted system by resetting the starting parameters. The starting parameter is used for being read before the vehicle-mounted system is started so as to select one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system. Thus, the vehicle-mounted system corresponding to the starting parameters can be started according to the main system.

It can be seen that the updating of each vehicle-mounted system can be completed by executing the above-described steps S101 to S103 twice. For example, if the at least two on-board systems include two on-board systems, i.e., an a-board system and a B-board system, respectively, during the first execution of the steps S101 to S103, if the a-board system is used as the main system and the a-board system is activated, the B-board system is the standby system and the B-board system is updated. In the process of performing the above-described step S101 to step S103 for the second time, the B on-vehicle system will be activated, and the a on-vehicle system as the backup system will be updated, thereby completing the updating of the respective on-vehicle systems. And the A vehicle-mounted system is set as a default started vehicle-mounted system and is started after the vehicle-mounted chip is restarted.

It can be seen from this embodiment that, the method provided in the embodiment of the present application can implement updating of the standby system during the operation of the main system, achieve the effect of silent updating, avoid affecting the operation of the main system, and ensure the stable operation of the main system, thereby ensuring the normal use of the instrument. And after the vehicle-mounted system is started next time, the updated vehicle-mounted system is operated as a main system. By executing the method again, all the vehicle-mounted systems can be updated, and the default started vehicle-mounted system is switched. According to the method, in the process of updating the vehicle-mounted system, the normal use of the current vehicle-mounted system is guaranteed, the automobile instrument can be ensured to be normal, the reliability of the functions (such as instrument functions) of the vehicle-mounted system is improved, and the safety of the vehicle is improved.

Fig. 2 is another schematic flow chart of an on-board system updating method according to an embodiment of the present application. Fig. 2 depicts the solution of the present application in more detail with respect to fig. 1. The method of the embodiment of fig. 2 may be applied to an on-board chip.

Referring to fig. 2, the method includes:

step S201, a boot program is loaded.

This step may be performed at startup of the onboard chip. For the description of the on-board chip, reference may be made to the embodiment of fig. 1, and details are not repeated here.

In this step, loading the boot program may refer to loading a bootloader. The bootloader is a first section of code executed by the embedded system after power-on, and can initialize hardware equipment and establish a memory space mapping diagram, so that the software and hardware environment of the system is brought to a proper state, and a correct environment is prepared for finally calling an operating system kernel.

Step S202, after the boot program is loaded successfully, one vehicle-mounted system is selected from at least two pre-stored vehicle-mounted systems to serve as a main system.

This step may be referred to collectively as the description in step S101.

Wherein, selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system may include: reading a starting parameter; and selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system according to the read starting parameters.

In the step, after the boot program is loaded successfully, the boot loader is started, the starting parameters are read, and one vehicle-mounted system is selected from at least two vehicle-mounted systems stored in advance as a main system according to the read starting parameters.

And step S203, after the loading of the bootstrap program fails, starting the emergency vehicle-mounted system.

Wherein starting the emergency vehicle-mounted system may include: and receiving the emergency vehicle-mounted system file and starting the emergency vehicle-mounted system.

After step S202 is executed, step S204 is executed.

Step S204, whether the firmware of the main system is normal is detected.

In this step, the detection may be performed by a boot loader, which may detect the firmware of the in-vehicle system. For example, whether a kernel (kernel), a kernel parameter (dtb), and a file system (rootfs) of the in-vehicle system are normal is detected, and CRC (cyclic Redundancy Check) checking or MD5(Message Digest Algorithm) matching is performed on a header file of the in-vehicle system.

Step S205, after determining that the firmware of the host system is normal, starting the host system.

In this step, if the host system passes the detection of step S203, it may be determined that the firmware of the host system is normal, so that the host system is activated.

And step S206, after the firmware of the main system is determined to be abnormal, selecting a spare system as the main system or starting the emergency vehicle-mounted system according to the firmware detection result of the spare system.

In this step, if the host system fails the detection of step S204, it may be determined that the firmware of the host system is abnormal. At this time, the backup system can be detected, and one backup system is selected as the main system or the emergency vehicle-mounted system is started according to the detection result of the firmware of the backup system.

The firmware detection result of the standby system may be: at least one spare system firmware is normal or all spare system firmware is abnormal.

In one embodiment, when at least one backup system passes the detection, that is, when the firmware of at least one backup system is normal, the backup system is selected as the main system, and step S207 is further performed; and starting the emergency vehicle-mounted system under the condition that all the standby systems fail to pass the detection, namely the firmware of all the standby systems is abnormal. Further, the starting of the emergency vehicle-mounted system comprises: and receiving the emergency vehicle-mounted system file and starting the emergency vehicle-mounted system.

And step S207, starting the main system to provide the functions of the vehicle-mounted system.

For ease of understanding, the following examples are given. For example, the at least two on-board systems include two on-board systems, i.e., an on-board system a and an on-board system B. Wherein, the A vehicle-mounted system corresponds to the starting parameter. The a vehicle system acts as the master system after reading the startup parameters. By detecting the vehicle-mounted system A, after the firmware of the vehicle-mounted system A is determined to be normal, the vehicle-mounted system A is started. And after determining that the firmware of the A vehicle-mounted system is abnormal, detecting the B vehicle-mounted system serving as a standby system. If the firmware of the vehicle-mounted system B is determined to be normal, taking the vehicle-mounted system B as a main system, and starting the vehicle-mounted system B; and if the firmware of the vehicle-mounted system B is determined to be abnormal, starting the emergency vehicle-mounted system.

After step S205 or step S207 is completed, one of the at least two vehicle-mounted systems is activated, the activated vehicle-mounted system is the main system, and the non-activated vehicle-mounted system is the standby system. At this time, step S208 may be performed.

Step S208, in response to the monitoring request of the microprocessor chip, sending the operating data of the main system to the microprocessor chip, so that the microprocessor chip sends a recovery request after detecting that the operating data is abnormal.

The Micro-processing chip may be an MCU (Micro Control Unit) chip, and may be used to monitor the on-board chip, and may also be used to take charge of vehicle Controller Area Network (CAN) communication, power management, and the like.

In the step, the vehicle-mounted chip can be used for regularly and automatically checking whether key functions such as instrument display are normal or not and feeding back the key functions to the micro-processing chip. The micro-processing chip monitors the main system by obtaining the operation data of the main system, and the micro-processing chip determines whether the operation condition of the main system is normal by judging whether the operation data of the main system is normal or not according to the operation data of the main system sent by the vehicle-mounted chip. And sending a recovery request after judging that the running data of the main system is abnormal so as to enable the vehicle-mounted chip to switch the main system.

Step S209, responding to the recovery request of the microprocessor chip, switching the main system to start the standby system to replace the main system.

In this step, when a recovery request of the microprocessor chip is received, the main system may be triggered to enter a recovery mode, and the main system may be switched to enter a standby system to replace the main system. The execution process of the step can be performed in the background and is not shown on a display screen of a vehicle instrument and the like so as to realize silent recovery of the standby system.

The monitoring of the running condition of the main system can be realized through the micro-processing chip, the abnormal fault of the main system can be found in time, the usability and the reliability of the meter function can be improved through the mechanism of switching the main system, and the safety of a vehicle is improved.

Further, please refer to fig. 5B, and fig. 5B is a schematic structural diagram of a hardware architecture for implementing the update method of the in-vehicle system. The automobile ICM (Instrument Cluster Module) comprises an on-board chip and a micro-processing chip. The vehicle-mounted chip is SOC, and the microprocessing chip is MCU. The vehicle-mounted chip is connected with the micro-processing chip through a serial interface and a chip pin; the vehicle-mounted chip and the micro-processing chip can communicate through a serial interface, and the serial interface can be a uart (Universal Asynchronous Receiver/Transmitter) interface; the microprocessor chip may control the on-board chip through a chip pin, for example, the microprocessor chip may send a control instruction (e.g., a recovery request) to the on-board chip through a GPIO (General-purpose input/output) chip pin, so that the on-board chip executes the control instruction.

The method for switching the main system may include: and the micro-processing chip sends a recovery request to the vehicle-mounted chip through the GPIO chip pin, so that a standby system in a local disk of the vehicle-mounted chip is started. The local disk of the on-board chip may be emmc (Embedded Multi Media Card). In this way, the backup system may be activated to replace the primary system to effect a switchover to the primary system.

Step S210, after the failure of switching the main system, sending a recovery failure signal to the microprocessor chip, so that the microprocessor chip sends an emergency request after receiving the recovery failure signal.

It will be appreciated that the standby system may fail to boot, resulting in a failed handoff to the primary system. At this time, a recovery failure signal may be transmitted to the micro processing chip, so that the micro processing chip transmits an emergency request after receiving the recovery failure signal, thereby executing the scheme in step S211 to switch the main system.

And S211, responding to the emergency request of the microprocessor chip, receiving the emergency vehicle-mounted system file, and starting the emergency vehicle-mounted system.

Further, in step S203, step S206, and step S211, the receiving the emergency in-vehicle system file and starting the emergency in-vehicle system file may include the following three different embodiments:

(1) and writing the received emergency vehicle-mounted system file from the vehicle-mounted information entertainment system terminal into the memory, and starting the emergency vehicle-mounted system from the memory.

In this embodiment, the In-Vehicle Infotainment system terminal may be referred to as an IVI (In-Vehicle Infotainment). Referring to fig. 5B, the on-board chip (i.e., the SOC shown in fig. 5B) and the IVI may be connected via a USB (Universal Serial Bus) interface. The microprocessor chip (i.e. the MCU shown in fig. 5B) sends a control instruction (e.g. an emergency request) to the on-board chip through the chip pin, and the on-board chip can receive an emergency on-board system file from the IVI through the USB interface in response to the control instruction (e.g. the emergency request) of the microprocessor chip. For example, the vehicle chip may switch the USB interface to support an SDP (Serial Download Protocol) Protocol, so that the vehicle chip may receive the emergency vehicle system file through the USB interface and write the emergency vehicle system file into the memory. The IVI stores an emergency vehicle system file, which may be a system image file. The microprocessor chip is also in communication connection with the IVI through the CAN bus, so that the microprocessor chip CAN inform the IVI to send the emergency vehicle-mounted system file to the vehicle-mounted chip in a USB transmission mode, and the emergency vehicle-mounted system file CAN be written into a memory of the vehicle-mounted chip. For example, the in-vehicle infotainment system terminal may transmit an emergency in-vehicle system file to the in-vehicle chip in response to an emergency request by the microprocessor chip. The emergency vehicle system file may include a bootstrap (i.e., bootloader), a kernel (i.e., kernel), a ramfs file system (i.e., a memory file system formed by using the virtual file system structure), and the like. After receiving the emergency request sent by the microprocessor chip, the vehicle-mounted chip can run an emergency vehicle-mounted system file from the memory, so that the emergency vehicle-mounted system is started, and the main system is switched. It can be found that because the vehicle-mounted information entertainment system terminal is widely adopted in the field of intelligent automobiles, the implementation mode has high adaptability to the hardware equipment architecture of the current automobile, the applicability is wide, and the implementation cost is effectively reduced.

(2) And writing the received emergency vehicle-mounted system file from the embedded storage chip in the micro-processing chip into the memory, and starting the emergency vehicle-mounted system from the memory.

In this embodiment, an embedded memory chip (e.g., emmc memory chip) in the microprocessor chip stores the emergency on-board system file. The microprocessor chip can send the emergency vehicle-mounted system file to the vehicle-mounted chip through the serial interface, and the emergency vehicle-mounted system file can be written into a memory of the vehicle-mounted chip. After receiving the emergency request sent by the microprocessor chip, the vehicle-mounted chip can run an emergency vehicle-mounted system file from the memory, so that the emergency vehicle-mounted system is started, and the main system is switched.

(3) And writing the emergency vehicle-mounted system file received through the network into the memory, and starting the emergency vehicle-mounted system from the memory.

In this embodiment, the emergency in-vehicle system files may be stored in an external storage device, and the emergency in-vehicle system files may also be stored in the IVI. The vehicle-mounted chip can receive an emergency vehicle-mounted System File from an external storage device or an IVI (interactive File System) in a Network transmission mode through an NFS (Network File System) of the Network port and write the emergency vehicle-mounted System File into a memory of the vehicle-mounted chip. Therefore, the emergency vehicle-mounted system file can be operated from the memory, and the emergency vehicle-mounted system can be started, so that the main system can be switched.

It should be noted that the emergency vehicle-mounted system has a basic function of instrument display, so that instrument information is normally displayed to ensure vehicle safety. Further, after the emergency vehicle-mounted system is started, in the process of operating the emergency vehicle-mounted system, the disk in the vehicle-mounted chip may be repaired by the disk tool, for example, the repair operations such as scanning, repairing disk errors, reformatting, and hard resetting the disk chip are performed. Further, after the disk error is successfully recovered, the system image file of the vehicle-mounted system can be obtained from the IVI again, so that each vehicle-mounted system in the vehicle-mounted chip can be recovered. After the error recovery of the disk fails, a reminding message can be sent to remind a user that the instrument is in fault and needs to be repaired.

After step S205 or step S207 is performed, step S212 may also be performed.

And S212, acquiring the updating data packet, updating the standby system according to the updating data packet, and setting a standby system as a default started vehicle-mounted system.

This step can be referred to the description in step S103, and is not described herein again.

Further, in one embodiment, after the host system is started, the method may further include: and detecting the standby system, and repairing the standby system with abnormal detection result. The method for repairing the abnormal standby system may be to update the abnormal standby system by using a system repair data packet, so that the abnormal standby system is recovered to be normal. For a specific process of updating the standby system by using the update data packet, reference may be made to the related description in step 103, and details are not described here again.

Further, in one embodiment, in order to not affect the smoothness of use and display delay of the display process of the in-vehicle system and improve the read/write efficiency of the disk, when updating the standby system according to the update data packet, the method includes: and dynamically adjusting the read-write delay size of the disk and/or the read-write data block size of the disk according to the load condition of the main system. In this embodiment, the read/write occupancy of the processor (CPU) of the on-board chip and the magnetic disk can be adjusted by dynamically adjusting the size of the read/write delay (or interval delay) and the size of the read/write data block (or file block).

In one embodiment, dynamically adjusting the size of the disk read-write delay and/or the size of the disk read-write data block according to the load condition of the host system includes: when the main system is in a low load condition, reducing the disk read-write delay and/or increasing the disk read-write data block; and under the condition that the main system is under high load, the disk reading and writing delay is increased and/or the disk reading and writing data blocks are decreased. Therefore, when the standby system is upgraded according to the upgrading data packet or repaired according to the repairing data packet, the repairing or upgrading speed of the standby system can be effectively improved, and the screen of the vehicle-mounted system terminal is prevented from being jammed. It will be appreciated that shorter read/write latencies and larger read/write data blocks may improve disk read/write efficiency, but may also improve the utilization of both processor and disk reads and writes. Similarly, longer read/write latency and smaller read/write data blocks may reduce the read/write efficiency of the disk, but may also reduce the read/write occupancy of the processor and the disk. The read-write delay and the read-write data block size are dynamically adjusted according to the load condition of the main system, and the read-write delay and the read-write data block of the updated data packet in the vehicle-mounted chip can be dynamically adjusted according to the processor occupancy rate of the display process in different use scenes. As shown in table 1 below, for example, in a situation where the main system is under a high load, for example, in a usage scenario where the auxiliary three-dimensional picture is displayed, the processor occupancy of the display process is medium, the read/write delay can be increased, and the read/write data block can be decreased. For another example, when the host system is under normal load, for example, in a usage scenario of displaying a navigation map, the processor occupancy rate of the display process is medium, the read/write delay may be reduced, and the read/write data block may be reduced. For another example, when the main system is under a low load condition, for example, in a usage scenario where only the vehicle speed is displayed, the processor occupancy rate of the display process is low, and the read/write data block can be enlarged by reducing the read/write delay. Therefore, on the premise of not influencing the use fluency and display delay of the display process of the vehicle-mounted system, the read/write efficiency of the disk can be improved to the maximum extent, and the occupancy rate of the processor is reduced.

CPU occupancy of display process	Usage scenarios	Read/write latency	Read/write data block
				In	Displaying driving assistance 3D pictures	Big (a)	Small
In	Displaying navigation maps	Small	Small
				Is low in	Only the speed of the vehicle is displayed	Small	Big (a)

TABLE 1

Further, in one embodiment, the start-up parameter is at least two; the starting parameter comprises a writing time mark; the reading of the start-up parameters includes: and reading the starting parameters according to the writing times mark or according to the verification result of the starting parameters.

The starting parameters are at least two, and the starting parameters can be two or three. In this way, a redundant backup mechanism for startup parameters is implemented. The present embodiment is described with three start-up parameters, but is not limited thereto. Further, each set of startup parameters may be the same, at least two sets of startup parameters may be stored in advance on the vehicle-mounted chip, and each set of startup parameters may be stored in a different partition on a magnetic disk in the vehicle-mounted chip.

The reading of the start-up parameter may be reading the start-up parameter according to a result of the verification of the start-up parameter. In one embodiment, the read-through of the verified boot parameter may be performed. In this embodiment, each startup parameter may be checked first. For example, a CRC check is performed to select the startup parameters that pass the check. It can be understood that if the startup parameters are damaged or lost, they will not pass the verification; the verified startup parameters can be determined to be complete and undamaged startup parameters. Therefore, the starting parameters passing the verification can be read, so that the damaged starting parameters are prevented from being read, and the accuracy of selecting the vehicle-mounted system is guaranteed.

The read start parameter may also be marked according to the number of writes. In one embodiment, the starting parameter may be the maximum read/write count flag. In this embodiment, the number-of-times flag may be written to the startup parameter every time the startup parameter is reset, so that the startup parameter contains the number-of-times flag. When an exception occurs in the file system (rootfs), the boot parameters are read but not written, that is, the boot parameters cannot be reset. That is, the number of times of writing the startup parameter that cannot be written is small. In this way, the startup parameters with the largest number of written marks can be read, so that the read startup parameters are ensured to be newly reset, and the selection correctness of the vehicle-mounted system is guaranteed.

It can be seen from this embodiment that, the method provided by the embodiment of the present application can implement silent upgrade or silent repair of each vehicle-mounted system without affecting the main system, can ensure normal operation of the meter function, reduce the impact on the operation of the main system, and ensure the safety and reliability of the operation of the main system; the vehicle-mounted system is started after the boot program and the firmware are loaded for detection, so that the reliability of the vehicle-mounted system is guaranteed, and the reliability of instrument function display is further guaranteed; the micro-processing chip can find the abnormal condition of the main system in time and switch the abnormal main system in time, thereby ensuring the availability and reliability of the instrument; even if all the vehicle-mounted systems are abnormal, the usability of the functions of the instrument can be guaranteed in a mode of starting the emergency vehicle-mounted system, and then the safety and the reliability of the automobile are improved.

Fig. 3 is a schematic flowchart of an update method of an on-board system according to another embodiment of the present application. The method of the embodiment of fig. 3 may be applied to an on-board chip.

Referring to fig. 3, the process includes:

and S301, executing an updating task by the vehicle-mounted system A.

The vehicle-mounted chip can store two vehicle-mounted systems, namely a vehicle-mounted system A and a vehicle-mounted system B in advance. One of the vehicle-mounted systems can be selected as a main system and started, and the other vehicle-mounted system can be selected as a standby system.

In the step, the vehicle-mounted system A is a main system, and the vehicle-mounted system A executes an updating task in the running process. The update task may be an upgrade task for the system, or a repair task (or referred to as a recovery task) for the system.

And step S302, acquiring an updating data packet.

The update data packet may be a system upgrade data packet or a system repair data packet. The update package may be obtained from an in-vehicle infotainment system terminal connected to the in-vehicle chip, which may obtain the update package through an OTA Technology (Over-the-Air Technology). The update package may be an OTA image file and the update package may be an OTA package.

And step S303, checking the updating data packet.

In this step, the correctness of the obtained update data packet is ensured by checking the update data packet.

Step S304, judging whether the updating data packet is correct.

When the update packet is determined to be correct after being verified, step S305 is executed; when the update data packet is verified to be an error, the process returns to step S302 to retrieve the update data packet.

And step S305, updating the vehicle-mounted system B.

In this step, the B in-vehicle system may be updated using the acquired update package. That is, in the a in-vehicle system operation, the B in-vehicle system as the backup system is updated. Therefore, the updating process of the vehicle-mounted system B does not affect the currently running vehicle-mounted system A, silent updating is realized, and normal running of instrument function display is guaranteed.

And S306, resetting the starting parameters to set the B vehicle-mounted system as a default starting vehicle-mounted system.

It should be noted that, before the vehicle-mounted chip starts the vehicle-mounted system, the start parameter may be read, so as to select one vehicle-mounted system from the two vehicle-mounted systems as the main system according to the start parameter, and start the vehicle-mounted system according to the main system. And resetting the starting parameters, wherein the reset starting parameters correspond to the B vehicle-mounted system, so that the B vehicle-mounted system in the two vehicle-mounted systems can be started after the vehicle-mounted chip is restarted.

And step S307, restarting the vehicle-mounted chip.

The restarting of the on-board chip may refer to that the on-board chip is turned on and started again after being turned off. And after the vehicle-mounted chip is started, selecting the updated B vehicle-mounted system as a main system and starting the B vehicle-mounted system by reading the starting parameters, wherein the A vehicle-mounted system is used as a standby system.

And step S308, updating the vehicle-mounted system A.

In this step, the update package determined to be correct after the verification in step S303 may be used to update the a onboard system. Similarly, in the operation of the B vehicle-mounted system, the A vehicle-mounted system serving as a standby system is updated. Therefore, in the updating process of the vehicle-mounted system A, the vehicle-mounted system B which is currently operated cannot be influenced, silent updating is realized, and normal operation of instrument function display is guaranteed.

And S309, resetting the starting parameters to set the A vehicle-mounted system as a default starting vehicle-mounted system.

In this step, the on-board chip can be enabled to start the a on-board system after the restart by resetting the start parameter again. Therefore, the switching of the vehicle-mounted system can be realized, and the initial starting setting of the vehicle-mounted chip to the two vehicle-mounted systems is recovered.

It can be seen from this embodiment that, the method provided in the embodiment of the present application can implement silent upgrade or silent repair of each vehicle-mounted system without affecting the main system, and can ensure normal operation of the meter function. It should be noted that, for a detailed description of each step in the embodiment shown in fig. 3, reference may be made to the introduction in the embodiment shown in fig. 2.

Fig. 4 is a schematic flowchart of an update method of an on-board system according to another embodiment of the present application.

Referring to fig. 4, the process includes:

and step S401, starting the vehicle-mounted chip.

The vehicle-mounted chip can be an SOC chip and is used for instrument function display control.

Step S402, loading a bootstrap program.

And step S403, judging whether the boot program loading is normal.

When the boot program is loaded normally, step S404 is executed; when the boot program loading fails, step S405 is performed.

Step S404, entering a bootstrap program.

After the bootstrap bootloader is loaded correctly, the bootstrap bootloader can be entered.

And step S405, starting the emergency vehicle-mounted system.

In the step, the emergency vehicle-mounted system file received from the vehicle-mounted infotainment system terminal can be written into the memory, and the emergency vehicle-mounted system can be started from the memory; or writing the received emergency vehicle-mounted system file from the embedded storage chip in the micro-processing chip into the memory, and starting the emergency vehicle-mounted system from the memory; or writing the emergency vehicle-mounted system file received through the network into the memory, and starting the emergency vehicle-mounted system from the memory.

Step S406, reading the starting parameters.

After entering the bootstrap bootloader, the boot parameters may be read. The starting parameters can be stored in the vehicle-mounted chip in advance, the vehicle-mounted chip can store at least two vehicle-mounted systems in advance, and the written content of the starting parameters corresponds to one of the vehicle-mounted systems. By reading the starting parameters, one vehicle-mounted system corresponding to the starting parameters can be determined from at least two vehicle-mounted systems.

Step S407, detecting the firmware.

In this step, detecting the firmware may refer to detecting a piece of firmware of the in-vehicle system corresponding to the startup parameter. Further, the bootloader can perform detection through a boot loader, and the bootloader can detect the firmware of the vehicle-mounted system. For example, whether a kernel (kernel), a kernel parameter (dtb), and a file system (rootfs) of the in-vehicle system are normal is detected, and CRC check is performed on a header file of the in-vehicle system or MD5 matching is performed.

Step S408, judging whether the firmware is normal.

It can be understood that when a piece of the vehicle-mounted system corresponding to the starting parameter passes the verification, the firmware of the vehicle-mounted system is normal. In this step, it is determined whether a piece of firmware of the in-vehicle system corresponding to the startup parameter is normal, and if so, step S409 is executed, and if not, step S410 is executed.

And step S409, starting the vehicle-mounted system.

In this step, the activation of the on-board system is performed, and the remaining on-board systems that are not activated will serve as backup systems

And step S410, judging whether the firmware of the rest vehicle-mounted systems is normal.

And when one piece of firmware of the vehicle-mounted system corresponding to the starting parameter is abnormal, performing firmware detection on the rest of the vehicle-mounted systems to judge whether the rest of the vehicle-mounted systems are normal. When all the other in-vehicle system firmware is abnormal, step S405 is executed. When the remaining in-vehicle system firmware is normal, step S411 is executed.

And step S411, switching to the vehicle-mounted system with normal firmware.

In this step, the activated in-vehicle system is switched so that in step S409, a copy of the in-vehicle system whose firmware is normal is activated.

Step S412, detecting a standby system.

After the vehicle system is started, the detection of the standby system which is not started can be carried out.

Step S413 determines whether the firmware of the standby system is normal.

By detecting the backup system, whether the firmware of the backup system is normal is determined, and when the firmware of the backup system is abnormal, step S414 is performed.

And step S414, repairing the standby system.

In this step, the manner of repairing the standby system may be: and receiving the update data packet to update the vehicle-mounted system according to the update data packet, so that the vehicle-mounted system serving as the standby system is repaired.

According to the method, the vehicle-mounted system is started after the boot program is loaded and the firmware is detected, so that the reliability of the vehicle-mounted system is guaranteed, and the reliability of instrument function display is further guaranteed; it should be noted that, for a detailed description of each step in the embodiment shown in fig. 4, reference may be made to the introduction in the embodiment shown in fig. 2.

Fig. 5A is a schematic flowchart of an update method of an on-board system according to another embodiment of the present application.

The interaction process between the on-board chip, the microprocessor chip and the on-board infotainment system terminal is illustrated in fig. 5A. As shown in fig. 5A, the vehicle-mounted chip may be an SOC, the vehicle-mounted chip stores at least two vehicle-mounted systems in advance, the microprocessor chip may be an MCU, and the vehicle-mounted infotainment system terminal may be an IVI.

Referring to fig. 5A, the process includes:

step S501, the micro-processing chip sends a monitoring request.

In this step, the microprocessor chip sends a monitoring request to the on-board chip.

And step S502, the vehicle-mounted chip sends the operation data of the main system.

In this step, the on-board chip responds to the monitoring request and transmits the operation data of the main system to the microprocessor chip. The vehicle-mounted chip can store at least two vehicle-mounted systems in advance, one vehicle-mounted system is selected as a main system by the vehicle-mounted chip and is started, and the rest vehicle-mounted systems are used as standby systems. That is, the main system is one of at least two vehicle-mounted systems which is activated, and the rest of the vehicle-mounted systems which are not activated are standby systems.

Step S503, the micro-processing chip sends a recovery request.

In this step, the microprocessor chip determines the operating condition of the main system according to the operating data of the main system sent by the vehicle-mounted chip. And when the main system is judged to be abnormal, sending a recovery request so as to enable the vehicle-mounted chip to switch the main system.

And step S504, the vehicle-mounted chip switches the main system to start the standby system to replace the main system.

In this step, the in-vehicle chip switches the main system in response to a recovery request of the micro-processing chip.

And step S505, after the main system switching fails, sending a recovery failure signal.

In this step, after the failure of switching the main system, the vehicle-mounted chip sends a recovery failure signal to the micro-processing chip.

Step S506, the micro-processing chip sends an emergency request.

In this step, the microprocessor chip will send an emergency request to the on-board chip after receiving the recovery failure signal.

And step S507, the microprocessor chip informs the vehicle-mounted information entertainment system terminal to send the emergency vehicle-mounted system file.

In this step, the microprocessor chip may be communicatively coupled to the in-vehicle infotainment system terminal via the CAN bus to notify the in-vehicle infotainment system terminal to send an emergency in-vehicle system file to the in-vehicle chip, such as to send an emergency request to the in-vehicle infotainment system terminal via the CAN bus.

And step S508, the vehicle-mounted information entertainment system terminal sends the emergency vehicle-mounted system file to the vehicle-mounted chip.

In this step, the in-vehicle infotainment system terminal may transmit an emergency in-vehicle system file to the in-vehicle chip in response to the emergency request.

Step S509, the vehicle chip starts the emergency vehicle system.

In this step, the vehicle-mounted chip can receive the emergency vehicle-mounted system file from the vehicle-mounted infotainment system terminal and start the emergency vehicle-mounted system.

According to the embodiment, the method provided by the embodiment of the application can find the abnormal condition of the main system in time and switch the abnormal main system in time through the micro-processing chip, so that the availability and the reliability of the instrument are guaranteed; even if all the vehicle-mounted systems are abnormal, the usability of the functions of the instrument can be guaranteed in a mode of starting the emergency vehicle-mounted system, and then the safety and the reliability of the automobile are improved. It should be noted that, for a detailed description of each step in the embodiment shown in fig. 5A, reference may be made to the introduction in the embodiment shown in fig. 2.

Fig. 6 is a schematic flowchart of a vehicle-mounted system detection method according to an embodiment of the present application. The method of the embodiment of fig. 6 may be applied to an on-board chip, and the on-board chip may store at least two on-board systems in advance.

Referring to fig. 6, the method includes:

step S601, selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system, and using the rest vehicle-mounted systems as standby systems.

And step S602, starting the main system to provide the functions of the vehicle-mounted system.

Step S603, in response to the monitoring request of the microprocessor chip, sending the operating data of the main system to the microprocessor chip, so that the microprocessor chip sends a recovery request after detecting that the operating data is abnormal.

Step S604, responding to the recovery request of the microprocessor chip, switching the main system to start the standby system to replace the main system.

It can be seen from this embodiment that, with the method provided in the embodiment of the present application, the abnormal condition of the main system can be found in time through the microprocessor chip, and the abnormal main system can be switched in time, so as to ensure the availability and reliability of the instrument.

Further, after the main system switching fails, a recovery failure signal is sent to the micro-processing chip, so that the micro-processing chip sends an emergency request after receiving the recovery failure signal; and responding to the emergency request of the micro-processing chip, receiving the emergency vehicle-mounted system file, and starting the emergency vehicle-mounted system.

Wherein, receive urgent on-vehicle system file, start urgent on-vehicle system, include:

writing the received emergency vehicle-mounted system file from the vehicle-mounted information entertainment system terminal into a memory, and starting the emergency vehicle-mounted system from the memory; or writing the received emergency vehicle-mounted system file from the embedded storage chip in the micro-processing chip into the memory, and starting the emergency vehicle-mounted system from the memory; or writing the emergency vehicle-mounted system file received through the network into the memory, and starting the emergency vehicle-mounted system from the memory.

It should be noted that, for a detailed description of each step in the embodiment shown in fig. 6, reference may be made to the introduction in the embodiment shown in fig. 2.

Fig. 7 is a schematic structural diagram of an on-vehicle system detection system shown in the embodiment of the present application.

Referring to fig. 7, an on-board system detection system 70 includes: a microprocessor chip 701, a vehicle-mounted chip 702 and a vehicle-mounted infotainment system terminal 703. The vehicle-mounted chip 702 is respectively connected with the microprocessor chip 701 and the vehicle-mounted infotainment system terminal 703 in a communication mode, and the microprocessor chip 701 is connected with the vehicle-mounted infotainment system terminal 703 in a communication mode.

The on-board chip 702 and the micro-processing chip 701 can be connected through a serial interface and chip pins; the vehicle-mounted chip 702 and the micro-processing chip 701 can communicate through a serial interface, and the serial interface can be a uart interface; the micro-processing chip 701 may send a control instruction (e.g., a recovery request, an emergency request) to the on-board chip 702 through the GPIO chip pin. The on-board chip 702 and the on-board infotainment system terminal 703 may be connected via a USB interface. The microprocessor chip 701 CAN be connected with the vehicle-mounted infotainment system terminal 703 in a communication way through a CAN bus.

The on-board chip 702 is configured to select one of at least two pre-stored on-board systems as a main system, and the rest of the on-board systems as standby systems. And starting the main system to provide the functions of the vehicle-mounted system. In response to the monitoring request of the micro-processing chip 701, the operating data of the main system is sent to the micro-processing chip 701, so that the micro-processing chip 701 sends a recovery request after detecting that the operating data is abnormal. In response to a recovery request of the microprocessor chip 701, the main system is switched to start the backup system to replace the main system.

The micro-processing chip 701 is configured to send a monitoring request to the on-board chip 702. And receives and detects the operation data of the main system sent by the vehicle-mounted chip 702. A recovery request is sent to the on-board chip 702 after an operational data anomaly is detected.

Further, the on-board chip 702 is further configured to send a recovery failure signal to the micro-processing chip 701 after failure of switching the main system, so that the micro-processing chip 701 sends an emergency request after receiving the recovery failure signal. And responding to the emergency request of the micro-processing chip 701, receiving an emergency vehicle-mounted system file, and starting an emergency vehicle-mounted system. The micro-processing chip 701 is further configured to send an emergency request after receiving a recovery failure signal sent by the on-board chip 702. The in-vehicle infotainment system terminal 703 is further configured to send an emergency in-vehicle system file to the in-vehicle chip 702 in response to the emergency request from the microprocessor chip 701.

It is understood that the microprocessor chip 701, the in-vehicle chip 702, and the in-vehicle infotainment system terminal 703 may respectively perform some or all of the above-mentioned methods, and will not be described in detail herein.

Corresponding to the embodiment of the application function implementation method, the application also provides a vehicle-mounted system updating device, a detection device, electronic equipment and corresponding embodiments.

Fig. 8A is a schematic structural diagram of an in-vehicle system update apparatus shown in an embodiment of the present application.

Referring to fig. 8A, an in-vehicle system updating apparatus 80 includes: a selection module 801, an activation module 802, an update module 803, and a setup module 804.

A selecting module 801, configured to select one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system, and use the remaining vehicle-mounted systems as standby systems;

a starting module 802, configured to start according to the main system determined by the selecting module 801;

and an updating module 803, configured to obtain the update data packet, and update the standby system determined by the selecting module 801 according to the update data packet.

A setting module 804, configured to set a backup system updated by the updating module 803 as a default started vehicle-mounted system.

It can be seen from this embodiment that the vehicle-mounted system updating device 80 provided by the present application can ensure the normal use of the instrument in the process of updating the vehicle-mounted system, and improves the reliability of the instrument function and the safety of the vehicle.

Optionally, the selection module 801 is further configured to read a start parameter; and selecting one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system according to the read starting parameters.

Fig. 8B is a schematic structural diagram of an on-board system updating apparatus according to another embodiment of the present application.

Referring to fig. 8B, an on-vehicle system updating apparatus 80 includes: a selection module 801, a starting module 802, an updating module 803, a setting module 804, a repairing module 805, a loading module 806, a detection module 807, a sending module 808, and a switching module 809.

The functions of the selection module 801, the start module 802, the update module 803, and the setting module 804 may refer to the description in fig. 8A, and are not described herein again.

The repairing module 805 is configured to detect a standby system, and repair the standby system with an abnormal detection result.

A loading module 806 for loading the boot program.

Optionally, the selecting module 801 is further configured to select one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as the main system after the boot program is successfully loaded.

Optionally, the starting module 802 is further configured to start the emergency vehicle-mounted system after the boot program fails to be loaded.

A detecting module 807 for detecting whether the firmware of the host system is normal.

Optionally, the starting module 802 is further configured to start according to the host system after determining that the firmware of the host system is normal.

Optionally, the selecting module 801 is further configured to select a spare system as the main system or start the emergency vehicle-mounted system according to a firmware detection result of the spare system after determining that the firmware of the main system is abnormal.

A sending module 808, configured to send, in response to a monitoring request of the microprocessor chip, the operating data of the main system to the microprocessor chip, so that the microprocessor chip sends a recovery request after detecting that the operating data is abnormal.

The switching module 809 is configured to switch the main system in response to the recovery request of the micro processing chip.

Optionally, the sending module 808 is further configured to send a recovery failure signal to the microprocessor chip after the failure of switching the main system, so that the microprocessor chip sends the emergency request after receiving the recovery failure signal.

Optionally, the starting module 802 is further configured to receive an emergency vehicle-mounted system file in response to an emergency request from the microprocessor chip, and start the emergency vehicle-mounted system.

Fig. 9 is a schematic structural diagram of an on-vehicle system detection device shown in an embodiment of the present application.

Referring to fig. 9, an in-vehicle system detection apparatus 90 includes: a selection module 901, a starting module 902, a sending module 903 and a switching module 904.

The selection module 901 is configured to select one vehicle-mounted system from at least two vehicle-mounted systems stored in advance as a main system, and use the remaining vehicle-mounted systems as backup systems.

And a starting module 902, configured to start the main system selected by the selecting module 901, so as to provide the in-vehicle system function.

A sending module 903, configured to send, in response to a monitoring request of the microprocessor chip, the running data of the main system started by the starting module 902 to the microprocessor chip, so that the microprocessor chip sends a recovery request after detecting that the running data is abnormal.

A switching module 904, configured to switch the main system activated by the activating module 902 in response to a recovery request of the microprocessor chip, so as to activate the standby system to replace the main system.

It can be seen from this embodiment that, the apparatus provided in this embodiment of the present application can find the abnormal situation of the main system in time through the microprocessor chip, and switch the abnormal main system in time, so as to ensure the availability and reliability of the instrument.

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Referring to fig. 10, the electronic device 1000 includes a memory 1010 and a processor 1020.

The Processor 1020 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 1010 may include various types of storage units, such as system memory, Read Only Memory (ROM), and permanent storage. Wherein the ROM may store static data or instructions that are needed by the processor 1020 or other modules of the computer. The persistent storage device may be a read-write storage device. The persistent storage may be a non-volatile storage device that does not lose stored instructions and data even after the computer is powered off. In some embodiments, the persistent storage device employs a mass storage device (e.g., magnetic or optical disk, flash memory) as the persistent storage device. In other embodiments, the permanent storage may be a removable storage device (e.g., floppy disk, optical drive). The system memory may be a read-write memory device or a volatile read-write memory device, such as a dynamic random access memory. The system memory may store instructions and data that some or all of the processors require at runtime. Further, the memory 1010 may comprise any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), magnetic and/or optical disks, among others. In some embodiments, memory 1010 may include a removable storage device that is readable and/or writable, such as a Compact Disc (CD), a digital versatile disc read only (e.g., DVD-ROM, dual layer DVD-ROM), a Blu-ray disc read only, an ultra-dense disc, a flash memory card (e.g., SD card, min SD card, Micro-SD card, etc.), a magnetic floppy disk, or the like. Computer-readable storage media do not contain carrier waves or transitory electronic signals transmitted by wireless or wired means.

The memory 1010 has stored thereon executable code that, when processed by the processor 1020, may cause the processor 1020 to perform some or all of the methods described above.

Furthermore, the method according to the present application may also be implemented as a computer program or computer program product comprising computer program code instructions for performing some or all of the steps of the above-described method of the present application.

Alternatively, the present application may also be embodied as a computer-readable storage medium (or non-transitory machine-readable storage medium or machine-readable storage medium) having executable code (or a computer program or computer instruction code) stored thereon, which, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the various steps of the above-described method according to the present application.

Having described embodiments of the present application, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A vehicle-mounted system updating method is applied to a vehicle-mounted chip, wherein at least two vehicle-mounted systems are stored in the vehicle-mounted chip in advance, and the method comprises the following steps:

starting the main system to provide vehicle-mounted system functions;

2. The method of claim 1, wherein selecting one of at least two pre-stored on-board systems as the master system comprises:

reading a starting parameter;

3. The method of claim 1, wherein said setting a share of said backup system as a default enabled on-board system comprises: and setting a spare system as a default started vehicle-mounted system by resetting the starting parameters.

4. The method of claim 1, wherein:

the updating data packet is a system upgrading data packet or a system repairing data packet.

5. The method of claim 1, further comprising:

6. The method of claim 1, wherein:

when the standby system is updated according to the update data packet, the method includes: and dynamically adjusting the read-write delay size of the disk and/or the read-write data block size of the disk according to the load condition of the main system.

7. The method according to claim 6, wherein dynamically adjusting the size of the disk read-write latency and/or the size of the disk read-write data block according to the load condition of the host system comprises:

8. The method of claim 2, wherein:

the starting parameters are at least two; the starting parameter contains a writing time mark;

9. The method of claim 1, wherein before selecting one of the at least two pre-stored on-board systems as the master system, further comprising:

loading a bootstrap program;

10. The method of claim 1, wherein after selecting one of the at least two pre-stored on-board systems as the main system, the method further comprises:

detecting whether the firmware of the main system is normal;

11. The method of claim 1, wherein after the activating the host system, further comprising:

12. A vehicle-mounted system detection method is applied to a vehicle-mounted chip, wherein at least two vehicle-mounted systems are stored in the vehicle-mounted chip in advance, and the method comprises the following steps:

starting the main system to provide vehicle-mounted system functions;

13. The method of claim 12, further comprising:

14. The method of claim 13, wherein receiving the emergency vehicle system file and initiating the emergency vehicle system comprises:

15. An in-vehicle system detection system, comprising: the system comprises a vehicle-mounted chip, a micro-processing chip and a vehicle-mounted information entertainment system terminal; the vehicle-mounted chip is respectively in communication connection with the microprocessor chip and the vehicle-mounted information entertainment system terminal, and the microprocessor chip is in communication connection with the vehicle-mounted information entertainment system terminal;

16. The system of claim 15, wherein:

the vehicle-mounted chip is also used for sending a recovery failure signal to the micro-processing chip after the main system switching fails, so that the micro-processing chip sends an emergency request after receiving the recovery failure signal; responding to the emergency request of the micro-processing chip, receiving an emergency vehicle-mounted system file, and starting an emergency vehicle-mounted system;

and the vehicle-mounted information entertainment system terminal is used for responding to the emergency request of the microprocessor chip and sending an emergency vehicle-mounted system file to the vehicle-mounted chip.

17. A computer-readable storage medium having stored thereon executable code, which when executed by a processor of an electronic device, causes the processor to perform the method of any of claims 1-14.