Control method, device, electronic device, storage medium, vehicle system and vehicle

Abstract

The present disclosure relates to a control method, device, electronic device, storage medium, vehicle-mounted system, and vehicle, wherein the method is used for the MCU of the vehicle-mounted system, and the method includes: during the startup process of the vehicle-mounted system-on-chip (SOC), sequentially monitoring the status information fed back by the SOC at each startup stage; if the status information fed back by the SOC is not monitored at any of the startup stages, sending a restart instruction to the SOC. The above technical solution is adopted to receive status information at each stage of the SOC startup process, and control the SOC to restart when no status information is received, thereby achieving real-time monitoring of the status of the SOC during startup. It is possible to restart the SOC in a timely manner when a fault occurs during the SOC startup process, without user intervention, thus avoiding the problem of the vehicle-mounted system failing to start normally.

Description

Technical Field

[0001] The present disclosure relates to the technical field of vehicle computer control, and in particular to a control method, device, electronic equipment, storage medium, vehicle computer system, and vehicle. Background Art

[0002] A vehicle's onboard computer typically consists of a microcontroller unit (MCU) and a system-on-chip (SOC). The MCU is responsible for power logic management and Controller Area Network (CAN) communication, while the SOC handles audio, video, and image processing. After receiving a power-on signal, the MCU powers up the SOC, allowing the computer to start. If the SOC fails during startup, user intervention and a restart are required; otherwise, recovery is impossible. Summary of the Invention

[0003] In order to solve the above technical problems or at least partially solve the above technical problems, at least one embodiment of the present disclosure provides a control method, device, electronic device, storage medium, vehicle system and vehicle.

[0004] In a first aspect, the present disclosure provides a control method for an MCU of a vehicle computer, comprising:

[0005] During the SOC startup process of the vehicle computer, the state information fed back by the SOC at each startup stage is monitored in sequence;

[0006] If the status information fed back by the SOC is not monitored during any of the startup phases, a restart instruction is sent to the SOC.

[0007] In a second aspect, the present disclosure provides another control method for the SOC of a vehicle computer, comprising:

[0008] receiving a restart instruction sent by the MCU of the vehicle computer, where the restart instruction is sent by the MCU because the MCU fails to detect status information of any startup phase within a waiting time corresponding to any startup phase of the SOC;

[0009] Restart according to the restart instruction.

[0010] In a third aspect, the present disclosure provides a control device for an MCU of a vehicle computer, comprising:

[0011] A monitoring module is used to monitor the status information fed back by the SOC at each startup stage during the startup process of the vehicle computer;

[0012] The restart control module is configured to send a restart instruction to the SOC when the state information fed back by the SOC is not monitored during any of the startup phases.

[0013] In a fourth aspect, the present disclosure provides a control device for a SOC of a vehicle computer, the device comprising:

[0014] a receiving module, configured to receive a restart instruction sent by the MCU of the vehicle computer, wherein the restart instruction is sent by the MCU when the MCU fails to detect the status information of any startup phase within a waiting time corresponding to any startup phase of the SOC;

[0015] The restart module is used to restart according to the restart instruction.

[0016] In a fifth aspect, the present disclosure provides an electronic device, including:

[0017] at least one processor;

[0018] and a memory communicatively connected to the at least one processor; wherein,

[0019] The at least one processor is configured to execute any vehicle control method provided by the embodiments of the present disclosure by calling the program or instruction stored in the memory.

[0020] In a sixth aspect, the present disclosure provides a computer-readable storage medium, wherein the computer-readable storage medium stores a program or instruction, and the program or instruction enables a computer to execute any of the control methods provided in the embodiments of the present disclosure.

[0021] In a seventh aspect, the present disclosure provides a vehicle system, including the control device provided in the embodiment of the present disclosure or the electronic device provided in the embodiment of the present disclosure.

[0022] In an eighth aspect, the present disclosure provides a vehicle, comprising the control device provided by an embodiment of the present disclosure, or the electronic device provided by an embodiment of the present disclosure, or the vehicle-mounted system provided by an embodiment of the present disclosure.

[0023] In a ninth aspect, the present disclosure provides a computer program product, which is used to execute any of the vehicle control methods provided in the embodiments of the present disclosure.

[0024] The technical solution provided by the embodiments of the present disclosure has at least the following advantages compared with the prior art:

[0025] In the disclosed embodiment, during the vehicle computer's SOC startup process, the MCU sequentially monitors the status information fed back by the SOC at each startup stage. If no status information fed back by the SOC is detected at any startup stage, a restart instruction is sent to the SOC. The above technical solution monitors the status information at each stage of the SOC startup process and sends a restart instruction to the SOC to control the SOC restart when no status information is detected at any stage. This achieves real-time monitoring of the SOC's status during startup, enabling timely restart of the SOC if a fault occurs during the SOC startup process. This automatic restart operation can be completed without user intervention, thus avoiding the problem of the vehicle computer failing to start normally due to a fault during startup without human intervention. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0027] In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0028] Figure 1 A flow chart of a control method provided in one embodiment of the present disclosure;

[0029] Figure 2 A flowchart of a control method provided in another embodiment of the present disclosure;

[0030] Figure 3 A schematic structural diagram of a control device provided in one embodiment of the present disclosure;

[0031] Figure 4 A schematic structural diagram of a control device provided in another embodiment of the present disclosure. DETAILED DESCRIPTION

[0032] In order to more clearly understand the above-mentioned purposes, features and advantages of the present disclosure, the present disclosure is further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the described embodiments are part of the embodiments of the present disclosure, rather than all of the embodiments. The specific embodiments described herein are only used to explain the present disclosure, rather than to limit the present disclosure. In the absence of conflict, the embodiments of the present disclosure and the features in the embodiments can be combined with each other. Based on the described embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field fall within the scope of protection of the present disclosure.

[0033] In the following description, many specific details are set forth to facilitate a full understanding of the present disclosure, but the present disclosure may also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all of the embodiments.

[0034] Before explaining the control method, device, electronic device, storage medium, vehicle system and vehicle of the embodiments of the present disclosure, the professional terms that may be involved in the present disclosure are explained as follows.

[0035] Car computer: Car computer refers to the abbreviation of the in-vehicle infotainment product installed in the car. The car computer can functionally realize information communication between people and cars, and between cars and the outside world (cars and cars).

[0036] MCU: A microcontroller unit, also known as a single-chip microcomputer or single-chip microcomputer, reduces the frequency and specifications of a central processing unit (CPU) and integrates peripheral interfaces such as memory, timers, universal serial bus (USB), analog-to-digital (A / D) conversion, universal asynchronous receiver / transmitter (UART), programmable logic controller (PLC), direct memory access (DMA), and even liquid crystal display (LCD) driver circuits onto a single chip, forming a chip-level computer that provides different control combinations for different applications.

[0037] SOC: System-on-Chip, also known as System on Chip, means that it is a product, an integrated circuit with a dedicated purpose, which contains all the contents of a complete system and embedded software.

[0038] RPC: The abbreviation of Remote Procedure Call, which refers to the communication technology between SOC and MCU in the embodiment of the present disclosure.

[0039] Android: Android is a free and open source operating system based on the Linux kernel.

[0040] XBL: Extensible Boot Loader / Secondary bootloader, is a stage in Android startup, responsible for initializing core application functions such as chip driver and charging. At this stage, it will distinguish between projects, board levels, devices, etc., and pass the distinction information to ABL through data structures.

[0041] ABL: Application Boot Loader, application boot program, is a stage when Android starts up. It guides Android to start up, loads the Linux kernel, including chip-independent applications, and receives some initialization information from XBL and passes it to the kernel. The kernel will parse the passed information.

[0042] A vehicle's onboard computer consists of an MCU and a system-on-chip (SoC). The MCU powers the SoC to start it up. The SoC boots up into the Android system through multiple stages, typically including the XBL stage, the ABL stage, the Android kernel boot, and the Android service (carservice) program boot, before entering the Android system. Failures can occur at any stage during the SoC boot process.

[0043] However, the existing SOC runs independently after power-on and does not dynamically interact with the MCU. If the SOC encounters a program failure at any startup stage or the system hangs or operates abnormally after startup, it cannot recover on its own without user intervention, causing the system to be unable to enter or be in a hung state, affecting the operation of the vehicle system.

[0044] To address the above-mentioned issues, the present disclosure provides a control method for an MCU in a vehicle computer. During the vehicle computer's SOC startup process, the MCU sequentially monitors the status information fed back by the SOC at each startup stage. If no status information fed back by the SOC is detected at any startup stage, a restart instruction is sent to the SOC. The above-mentioned technical solution monitors the status information of each stage during the SOC startup process, and sends a restart instruction to the SOC to control the SOC restart when no status information is detected at any stage. This achieves real-time monitoring of the SOC's status during startup, and enables timely restart of the SOC if a fault occurs during the SOC startup process, without requiring user intervention, thus avoiding the problem of the vehicle computer failing to start normally.

[0045] Figure 1This is a flow chart of a control method provided in one embodiment of the present disclosure. The control method can be executed by a control device provided in an embodiment of the present disclosure. The control device can be implemented using software and / or hardware and can be integrated into a vehicle, specifically, it can be integrated into the MCU of the vehicle computer in the vehicle. The vehicle computer also includes an SOC, and the MCU and the SOC are communicated with each other.

[0046] like Figure 1 As shown, the control method provided by the embodiment of the present disclosure may include the following steps:

[0047] Step 101 : During the process of starting the SOC of the vehicle computer, the state information fed back by the SOC in each starting stage is monitored in sequence.

[0048] Typically, a vehicle's onboard computer includes a system-on-chip (SOC) and a microcontroller (MCU). Upon receiving a power-on signal, the MCU powers up the SOC to start it up. In the disclosed embodiment, upon receiving the power-on signal, the MCU powers up the SOC. The SOC then begins booting, gradually progressing through various SOC startup phases, such as the XBL phase, the ABL phase, and the Android system kernel startup phase.

[0049] During the SOC startup process, a fault may occur at any stage, causing the SOC to fail to start normally. In the embodiment of the present disclosure, during the SOC startup process, the MCU monitors the status information fed back by the SOC at each startup stage in turn. Each time the SOC successfully starts a startup stage, it feeds back the status information of the startup stage to the MCU. The status information is used to indicate that the SOC has successfully entered the startup stage, so that the MCU can determine whether the SOC has an abnormality during the startup process based on the received status information of the startup stage. The startup process of the SOC includes multiple startup stages, and the next startup stage will not be entered until the current startup stage is successfully started. In the embodiment of the present disclosure, the MCU monitors the status information of each startup stage during the SOC startup process.

[0050] First, after power-on, the SOC enters the first startup phase. After the first startup phase is successfully started, the SOC sends status information to the MCU. The MCU monitors the status information of the first startup phase. If the corresponding status information is detected within the waiting time corresponding to the first startup phase, it continues to monitor the status information of the next startup phase. After the SOC successfully starts the first startup phase, it enters the second startup phase. After the second startup phase is successfully started, the SOC sends the status information of the second startup phase to the MCU to inform the MCU that the phase has been successfully started. The MCU monitors the status information of the SOC's second startup phase. If the corresponding status information is detected within the waiting time corresponding to the second startup phase, it continues to monitor the status information of the next startup phase. After the SOC successfully starts the second startup phase, it enters the third startup phase. After the third startup phase is successfully started, the SOC sends the status information of the third startup phase to the MCU to inform the MCU that the phase has been successfully started. The MCU monitors the status information of the SOC's third startup phase. If the corresponding status information is detected within the waiting time corresponding to the third startup phase, it continues to monitor the status information of the next startup phase. By analogy, the MCU monitors the status information of each startup stage in the SOC startup process in turn until the SOC starts successfully, or sends a restart instruction to the SOC to control the SOC restart when the status information of a startup stage is not detected, and re-monitors the status information of each startup stage in the process of starting each startup stage after the SOC restarts.

[0051] Among them, the waiting time corresponding to each startup stage of the SOC can be pre-set according to actual needs, that is, the waiting time corresponding to each startup stage of the SOC is pre-set in the MCU, which is called the standard waiting time; the waiting time corresponding to each startup stage of the SOC can also be provided to the MCU by the SOC according to the time required for starting each stage. For example, the SOC can provide the waiting time corresponding to the next stage to the MCU when feeding back the status information of the current stage. The present disclosure does not impose any restrictions on this.

[0052] For example, a communication connection can be directly established between the MCU and the SOC to exchange the status information of each stage of the SOC. After the MCU powers on the SOC, a communication connection is established with the SOC to receive the status information of each startup stage fed back by the SOC through the communication connection.

[0053] For example, the MCU and SOC can exchange status information of each startup stage during the SOC startup process through third-party forwarding. After successfully starting a startup stage, the SOC can send the status information of the startup stage to the third party, and the third party will feed back the received status information to the MCU.

[0054] It should be noted that, in the embodiment of the present disclosure, the status information of each startup stage fed back by the SOC to the MCU may be a feedback message sent by the SOC to the MCU after the SOC successfully starts a startup stage, which is used to indicate that the startup stage has been successfully started. The feedback message may be pre-agreed between the MCU and the SOC, and the MCU believes that the SOC has successfully entered the corresponding stage upon receiving the feedback message; the status information may also be the startup information generated during the process of the SOC starting each startup stage. The MCU and the SOC may pre-agreed that the SOC feeds back all the startup information of each stage to the MCU, or may agree that the SOC feeds back part of the startup information of each stage to the MCU. This may be set according to actual needs, and the present disclosure does not impose any restrictions on this.

[0055] Step 102: If the state information fed back by the SOC is not monitored during any of the startup phases, a restart instruction is sent to the SOC.

[0056] In the embodiment of the present disclosure, during the startup process of the SOC, the MCU monitors the status information of each startup stage of the SOC in sequence. If the MCU does not monitor the status information of any startup stage fed back by the SOC, it is considered that an abnormality has occurred during the startup process of the SOC, and the MCU sends a restart instruction to the SOC to control the restart of the SOC.

[0057] For example, assuming that the SOC successfully starts the XBL stage, the MCU can monitor the status information of the XBL stage fed back by the SOC during the XBL startup stage, and then continue to monitor the status information of the next stage (i.e., the ABL stage). If the MCU does not monitor the status information of the ABL stage fed back by the SOC during the ABL stage, it is considered that an abnormality occurs during the process of the SOC entering the ABL stage, which makes it impossible for the SOC to enter the ABL stage normally, and thus it is impossible to complete this startup process and enter the Android system. The MCU then sends a restart instruction to the SOC to control the SOC to restart.

[0058] In the control method of the disclosed embodiment, during the startup process of the vehicle computer's SOC, the MCU sequentially monitors the status information fed back by the SOC at each startup stage. If no status information fed back by the SOC is detected at any startup stage, a restart instruction is sent to the SOC. The above technical solution monitors the status information of each stage during the SOC startup process, and sends a restart instruction to the SOC to control the SOC restart when no status information is detected at any stage. This achieves real-time monitoring of the SOC startup status, and enables timely restart of the SOC if a fault occurs during the SOC startup process. The automatic restart operation can be completed without user intervention, thus avoiding the problem of the vehicle computer failing to start normally due to a fault during the startup process without human intervention.

[0059] In an optional implementation manner of the present disclosure, when the MCU sequentially monitors the status information fed back by the SOC in each startup phase, the status information fed back by the SOC may be monitored within the waiting time of each startup phase.

[0060] Among them, the waiting time is the time length that the MCU waits for the SOC to feedback the status information of the corresponding stage. If the MCU successfully receives the status information of the startup stage within the waiting time length corresponding to a certain startup stage, it is determined that the SOC has successfully entered this stage, and then waits to receive the status information of the next stage within the waiting time length corresponding to the next stage; if the MCU still does not receive the status information of the startup stage within the waiting time length corresponding to a certain startup stage, it is considered that the SOC has failed to enter this stage, and the MCU sends a restart instruction to the SOC to control the SOC to restart.

[0061] It should be noted that the waiting time corresponding to each stage can be pre-set according to actual needs, that is, the waiting time corresponding to each startup stage of the SOC is pre-set in the MCU, which is called the standard waiting time. The SOC can also provide it to the MCU based on the time required for startup of each stage. For example, the SOC can provide the waiting time corresponding to the next stage to the MCU when feedbacking the status information of the current stage. This disclosure does not impose any restrictions on this.

[0062] In the embodiment of the present disclosure, by monitoring the status information fed back by the SOC during the waiting time of each startup phase, when the status information of a startup phase is not monitored within the waiting time, a restart instruction can be sent to the SOC in a timely manner to restart the SOC in time.

[0063] The startup process of the SOC includes multiple stages, such as the XBL stage, the ABL stage, the Android kernel startup stage, etc. After a stage is successfully started, the startup process of the next stage will be entered. Therefore, the status information of each stage of the SOC monitored by the MCU is also stage by stage. After monitoring the status information of one stage, the status information of the next stage is received. Since the time consumed when starting different stages in the SOC may be different, the time consumed when starting the same stage of the SOC in different vehicle computers may also be different. In order to ensure the rationality of the waiting time corresponding to each stage and improve the applicability of this solution, in the embodiment of the present disclosure, except for the first startup stage in the startup process of the SOC, the waiting time of each other startup stage can be sent by the SOC to the MUC. The SOC can feedback the waiting time corresponding to the next startup stage at the same time as feedback of the status information of the current startup stage. Therefore, in an optional embodiment of the present disclosure, the MCU presets a standard waiting time corresponding to the first startup stage in the startup process of the SOC. Within the waiting time of each startup stage, before monitoring the status information fed back by the SOC, the method also includes:

[0064] Determine the waiting time of each startup phase; wherein,

[0065] If the startup phase is the first startup phase, the standard waiting time of the startup phase is determined as the waiting time of the startup phase;

[0066] If the startup phase is not the first startup phase, the first waiting time period fed back by the SOC when feeding back the status information of the previous startup phase is determined as the waiting time period of the startup phase.

[0067] In the disclosed embodiment, the MCU is preset with a standard waiting time corresponding to the first startup phase of the SOC, and the standard waiting time can be pre-set based on experience. When the SOC feeds back the status information of each startup phase to the MCU, it will also feed back the first waiting time corresponding to the next startup phase to the MCU. For the first startup phase in the SOC, since there is no other startup phase before it, the SOC cannot feed back the first waiting time corresponding to the first startup phase to the MCU, so that if the startup phase currently being monitored is the first startup phase, the MCU can determine the preset standard waiting time as the waiting time of the startup phase. If the startup phase currently being monitored is not the first startup phase, for example, the startup phase currently being monitored is the second startup phase in the process of the SOC starting up, then when the SOC feeds back the status information of the first startup phase to the MCU, it will also feed back the first waiting time of the second startup phase to the MCU, and the MCU can determine the monitored first waiting time as the waiting time of the startup phase currently being monitored.

[0068] The first waiting time can be determined based on the startup time of the startup phase, and the first waiting time can be set to be no less than the startup time of the startup phase. Thus, the SOC can set the waiting time of the corresponding phase based on the startup time of each phase, which is conducive to avoiding the phenomenon of the waiting time of each phase being too short or too long, thereby ensuring the rationality of the waiting time of each phase.

[0069] In the embodiment of the present disclosure, when the startup phase is the first startup phase in the SOC startup process, the standard waiting time of the startup phase is determined as the waiting time of the startup phase; when the startup phase is not the first startup phase, the first waiting time fed back when the SOC feeds back the status information of the previous startup phase is determined as the waiting time of the startup phase. Thus, the waiting time corresponding to each phase is dynamically set, avoiding the MCU side from pre-setting the waiting time corresponding to each phase of the SOC. Moreover, the SOC can set the waiting time of the corresponding phase according to the time consumed by each phase of its own startup, which is beneficial to avoid the phenomenon that the waiting time of each phase is too short or too long, thereby ensuring the rationality of the waiting time of each phase.

[0070] In order to avoid the situation where the MCU fails to detect the waiting time corresponding to the next stage when monitoring the status information of each node fed back by the SOC, resulting in the MCU being in a state of receiving the status information of the next stage and being unable to determine whether the status information of the next stage is received within the waiting time, in an optional embodiment of the present disclosure, standard waiting times corresponding to other startup stages except the first startup stage during the startup process of the SOC may be preset in the MCU. Thus, the first waiting time fed back when the SOC feeds back the status information of the previous startup stage is determined as the waiting time of the startup stage, including:

[0071] The waiting time corresponding to the startup phase is updated from the standard waiting time corresponding to the startup phase to the first waiting time.

[0072] Among them, the standard waiting time corresponding to other startup stages can be pre-set according to actual needs.

[0073] In the embodiment of the present disclosure, a standard waiting time corresponding to each startup stage is pre-set and stored in the MCU. When the startup stage being monitored is the first startup stage started after the SOC is powered on, the MCU can monitor the status information of the first startup stage and the first waiting time of the next startup stage fed back by the SOC within the preset standard waiting time corresponding to the first startup stage. If the MCU does not detect the status information of the first startup phase within the standard waiting time corresponding to the first startup phase, a restart instruction is sent to the SOC to control the SOC restart; if the MCU detects the status information of the first startup phase fed back by the SOC but does not detect the first waiting time of the second startup phase, the status information of the second startup phase fed back by the SOC and the first waiting time of the third startup phase can be monitored within the preset standard waiting time corresponding to the second startup phase; if the MCU detects the status information of the first startup phase fed back by the SOC and the first waiting time of the second startup phase, the waiting time corresponding to the second startup phase can be updated from the standard waiting time corresponding to the second startup phase to the monitored first waiting time, so that the MCU can monitor the status information of the second startup phase and the first waiting time of the third startup phase within the first waiting time, and so on, until the SOC enters the system operation phase or reaches the preset number of restarts, and reminds relevant personnel to intervene.

[0074] In the embodiment of the present disclosure, the MCU and the SOC can pre-agree on the status information of each stage that the SOC needs to feedback to the MCU. The status information can be a feedback message that can indicate that the corresponding stage has been successfully started, or it can be all or part of the startup information generated during the startup process of the corresponding stage. After the MCU monitors the status information of each stage, it determines whether the corresponding stage has been successfully started based on the status information.

[0075] In an optional embodiment of the present disclosure, a feedback message is agreed upon in advance between the SOC and the MCU, and the feedback message is used to indicate that the corresponding stage has been successfully started, wherein the feedback messages corresponding to different stages may be the same or different, and the MCU may record the feedback messages of the corresponding stages according to the startup sequence of each stage in the SOC. After the SOC successfully starts a stage, it feeds back the feedback message corresponding to the stage to the MCU. If the MCU detects the corresponding feedback message within the waiting time of the corresponding stage, it will not restart the SOC and continue to wait for the feedback message of the next stage. If the MCU does not detect the corresponding feedback message within the waiting time of the corresponding stage, it means that the SOC has failed to enter the stage, and the MCU sends a restart instruction to the SOC to control the restart of the SOC.

[0076] In an optional embodiment of the present disclosure, the SOC and the MCU pre-agreed on the startup information of each stage that needs to be fed back by the SOC. In order to facilitate the MCU to distinguish the startup information of each stage, the feedback information of each stage fed back by the SOC to the MCU includes the stage identifier and startup information of the corresponding stage. Thus, the MCU can determine whether the status information of the target stage corresponding to the stage identifier has been received based on the startup information. In the embodiment of the present disclosure, the state information fed back by the SOC at each startup stage is sequentially monitored, including:

[0077] receiving feedback information fed back by the SOC during each startup phase, the feedback information including a phase identifier and startup information;

[0078] According to the stage identifier, acquiring target reference information corresponding to the stage identifier from reference information corresponding to each startup stage preset in the MCU;

[0079] If the startup information is inconsistent with the target reference information, determining that the state information of the SOC feedback is not monitored during the target startup phase corresponding to the phase identifier;

[0080] In a case where the startup information is consistent with the target reference information, it is determined that the state information of the SOC feedback is monitored in the target startup phase corresponding to the phase identifier.

[0081] Among them, the reference information is the information pre-agreed between the MCU and the SOC to indicate that the SOC has successfully entered the corresponding stage. The reference information can be part or all of the startup information generated during the startup process of the corresponding stage. When the startup information of a startup stage received by the MCU is consistent with the reference information of the startup stage, it is considered that the MCU has successfully received the status information of the startup stage and the SOC has successfully started the stage.

[0082] For example, it is assumed that reference information corresponding to each startup phase of the SOC is preset in the MCU and stored in the local storage space of the MCU. In the embodiment of the present disclosure, when the MCU receives feedback information from the SOC within the waiting time of any startup phase, the received feedback information can be verified. First, based on the phase identifier contained in the feedback information, the target reference information corresponding to the phase identifier is obtained from the reference information stored in the local storage space of the MCU. Then, the startup information contained in the feedback information is matched with the obtained target reference information. If the startup information is consistent with the target reference information, it is determined that the status information of the target startup phase fed back by the SOC has been successfully received within the waiting time corresponding to the target startup phase corresponding to the phase identifier, and the state information of the next phase is continued to be received. If the startup information is inconsistent with the target reference information, it is determined that the status information of the target startup phase fed back by the SOC has not been received within the waiting time corresponding to the target startup phase corresponding to the phase identifier, and a restart instruction is sent to the SOC to control the SOC to restart.

[0083] It should be noted that, in the embodiments of the present disclosure, the startup information being consistent with the target reference information means that the startup information includes all reference information for the corresponding stage. The startup information can be identical to the target reference information, i.e., the amount of information included and the content of the information are the same. The startup information can also include more information than the target reference information, but it cannot include only part of the target reference information or no target reference information. In other words, when the startup information includes at least all the reference information for the corresponding stage, the startup information is considered consistent with the target reference information. When there is reference information not included in the startup information, the startup information is considered inconsistent with the target reference information.

[0084] In an embodiment of the present disclosure, the feedback information includes a stage identifier and startup information of the corresponding stage. The target reference information corresponding to the stage identifier is obtained from the reference information corresponding to each startup stage preset in the MCU according to the stage identifier contained in the feedback information. When the startup information in the feedback information is inconsistent with the target reference information, it is determined that the status information of the SOC feedback is not received in the target startup stage corresponding to the stage identifier. When the startup information is consistent with the target reference information, it is determined that the status information of the SOC feedback is monitored in the target startup stage corresponding to the stage identifier. In this way, the received startup information is verified according to the pre-agreed reference information to determine whether the status information of the first stage is successfully received, which can improve the judgment accuracy of the reception result, thereby effectively avoiding the phenomenon that the system is in a hung state due to incorrect restart or failure to restart the SOC in time.

[0085] After the SOC's XBL, ABL, and Android system kernel are successfully started, the SOC enters the Android system operation phase. Because the vehicle system (Android) sometimes freezes or important vehicle information cannot be obtained, resulting in the vehicle system not being able to operate normally, in this case, the SOC can also be controlled to restart to restart the vehicle system, so that the vehicle system can resume normal operation without manual intervention, avoiding the vehicle system being stuck in a black screen or abnormal state. Therefore, in an optional embodiment of the present disclosure, the method further includes:

[0086] After the SOC enters the system operation stage, monitoring system status information fed back by the SOC;

[0087] If the system status information fed back by the SOC is not monitored within a preset period, the SOC is controlled to restart.

[0088] The system operation phase may be, for example, the phase in which an operating system such as Android or Apple OS enters operation after startup. For example, when the XBL, ABL, and Android kernel startup phases of the SOC are successfully started, the Android system is successfully started, and the SOC enters the Android system operation phase.

[0089] In the embodiment of the present disclosure, the preset period can be set according to actual needs, for example, the preset period can be set to 1 minute, 5 minutes, etc. The preset period can be pre-agreed by the SOC and the MCU. After entering the Android system, the SOC feeds back the system status information of the Android system to the MCU according to the preset period, and the MCU receives the system status information according to the preset period.

[0090] For example, after the MCU monitors the status information fed back by the SOC indicating that the system has entered the Android system stage, it can be determined that the SOC has entered the system operation stage. Thereafter, the MCU receives the system status information fed back by the SOC according to a preset period.

[0091] The system status information may be a preset message agreed upon in advance between the MCU and the SOC to indicate that the Android system is in a normal operating state. When the MCU receives the preset message, it determines that the Android system is currently in a normal operating state.

[0092] In the embodiment of the present disclosure, the MCU monitors the system status information fed back by the SOC. When the system status information fed back by the SOC is successfully monitored within a preset period, the MCU enters the next preset period, restarts the timing, and continues to monitor the system status information within the preset period. When the system status information is not monitored within a preset period, it is considered that an abnormality occurs during the operation of the Android system, and the MCU sends a restart instruction to the SOC to control the SOC to restart.

[0093] In the embodiment of the present disclosure, after the SOC enters the system operation stage, the system status information fed back by the SOC is monitored, and the SOC is controlled to restart when the system status information fed back by the SOC is not monitored within a preset period. In this way, when an abnormality occurs during the operation of the vehicle system, the SOC can be restarted in time to restore the normal operation of the vehicle system, effectively avoiding the vehicle system from being in a hung or abnormal operating state.

[0094] In an optional embodiment of the present disclosure, after the MCU powers on the SOC, it establishes a communication connection with the SOC to receive status information from the SOC at each stage via the communication connection. The communication connection includes, but is not limited to, a CAN bus connection, a Local Interconnect Network (LIN) connection, and other vehicle network connection methods. As a result, the SOC can establish a communication process with the MCU for interaction after powering on. The MCU can promptly obtain status information from the SOC at each startup stage through the communication connection, monitor the status of the SOC throughout its entire operating cycle in real time, and restart the SOC promptly when necessary. This ensures that the SOC successfully enters the system operation stage and the normal operation of the vehicle system without human intervention.

[0095] In an optional embodiment of the present disclosure, the communication connection is a remote procedure call. In the embodiment of the present disclosure, RPC is used for communication between the MCU and the SOC, which enables the MCU to call content on the SOC just like calling local content, with flexible deployment and strong scalability.

[0096] Figure 2This is a flow chart of a control method provided in another embodiment of the present disclosure. The control method can be executed by a control device provided in an embodiment of the present disclosure. The control device can be implemented using software and / or hardware and can be integrated into a vehicle, specifically, it can be integrated into the SOC of the vehicle computer in the vehicle. The vehicle computer also includes an MCU, and the MCU and the SOC are communicated with each other.

[0097] like Figure 2 As shown, the control method provided by the embodiment of the present disclosure may include the following steps:

[0098] Step 201: receiving a restart instruction sent by the MCU of the vehicle computer, wherein the restart instruction is sent by the MCU when the MCU fails to detect the status information of any startup phase within the waiting time corresponding to any startup phase of the SOC.

[0099] In the disclosed embodiment, after the MCU powers on the SOC, the SOC starts to boot up and gradually enters various boot-up phases of the SOC, such as the XBL phase, the ABL phase, the Android system kernel boot phase, etc. During the boot-up process, the SOC sends status information of each phase to the MCU.

[0100] In an optional implementation, the SOC may send the waiting time for the next startup phase while sending the status information of a certain startup phase.

[0101] The next startup phase is a phase that the SOC enters after starting the target phase corresponding to the sent status information.

[0102] For example, assume that during startup, the SOC sequentially initiates the XBL phase, the ABL phase, and the Android kernel startup phase. After initiating the XBL phase, the SOC enters the ABL phase, and after initiating the ABL phase, the SOC enters the Android kernel startup phase. Therefore, when the SOC sends XBL phase status information to the MCU, it also sends the wait time for the next startup phase, the ABL phase. Similarly, when the SOC sends ABL phase status information to the MCU, it also sends the wait time for the next startup phase, the Android kernel startup phase.

[0103] The MCU monitors the status information of any startup phase during the waiting period corresponding to the SOC. If no status information of the startup phase is detected within the waiting period, the MCU sends a restart instruction to the SOC, and the SOC receives the restart instruction sent by the MCU. For example, if the MCU does not receive the status information of the ABL phase within the waiting period corresponding to the ABL phase, the MCU sends a restart instruction to the SOC.

[0104] Step 202: Restart according to the restart instruction.

[0105] In the disclosed embodiment, after the SOC receives the restart instruction sent by the MCU of the vehicle computer, it can automatically restart without manual intervention.

[0106] In the control method of the disclosed embodiment, the SOC of the vehicle computer receives a restart instruction sent by the MCU of the vehicle computer, and the restart instruction is sent by the MCU when the MCU fails to monitor the status information of any startup stage within the waiting time corresponding to any startup stage of the SOC, and restarts according to the restart instruction. Therefore, when a fault occurs during the startup of the SOC, the restart instruction can be received in time for restart, and the automatic restart operation can be completed without user intervention, thereby avoiding the problem that the vehicle computer cannot start normally due to a fault during the startup of the vehicle computer but without human intervention.

[0107] In order to implement the above embodiments, the present disclosure also provides a control device.

[0108] Figure 3 This is a structural diagram of a control device provided in one embodiment of the present disclosure. The device can be implemented using software and / or hardware and can be integrated into a vehicle. Specifically, it can be integrated into the MCU of the vehicle computer in the vehicle. The vehicle computer also includes a SOC, and the MCU and the SOC are communicated with each other.

[0109] like Figure 3 As shown, the control device 30 provided in the embodiment of the present disclosure may include: a monitoring module 301 and a restart control module 302, wherein:

[0110] The monitoring module 301 is used to monitor the status information fed back by the SOC at each startup stage in sequence during the startup process of the vehicle computer;

[0111] The restart control module 302 is configured to send a restart instruction to the SOC when no status information fed back by the SOC is monitored during any of the startup phases.

[0112] Optionally, the monitoring module 301 is further configured to:

[0113] During the waiting period of each startup phase, the status information fed back by the SOC is monitored.

[0114] Optionally, the MCU is preset with a standard waiting time corresponding to the first startup phase in the startup process of the SOC.

[0115] The control device 30 further includes:

[0116] The determination module is used to determine the waiting time of each startup phase; wherein,

[0117] If the startup phase is the first startup phase, the standard waiting time of the startup phase is determined as the waiting time of the startup phase;

[0118] If the startup phase is not the first startup phase, the first waiting time period fed back by the SOC when feeding back the status information of the previous startup phase is determined as the waiting time period of the startup phase.

[0119] Optionally, the MCU is further preset with standard waiting times corresponding to other startup stages except the first startup stage during the startup process of the SOC, and the determining module is further configured to:

[0120] The waiting time corresponding to the startup phase is updated from the standard waiting time corresponding to the startup phase to the first waiting time.

[0121] Optionally, the monitoring module 301 is further configured to:

[0122] receiving feedback information fed back by the SOC during each startup phase, the feedback information including a phase identifier and startup information;

[0123] According to the stage identifier, acquiring target reference information corresponding to the stage identifier from reference information corresponding to each startup stage preset in the MCU;

[0124] If the startup information is inconsistent with the target reference information, determining that the state information of the SOC feedback is not monitored during the target startup phase corresponding to the phase identifier;

[0125] In a case where the startup information is consistent with the target reference information, it is determined that the state information of the SOC feedback is monitored in the target startup phase corresponding to the phase identifier.

[0126] Optionally, the status information is a feedback message sent by the SOC to the MCU after starting any startup phase, indicating that any startup phase is successfully started; or, the status information is startup information generated during the process of the SOC starting each startup phase.

[0127] Optionally, the monitoring module 301 is further configured to:

[0128] After the SOC enters the system operation stage, monitoring system status information fed back by the SOC;

[0129] The restart control module 302 is further configured to:

[0130] If the system status information fed back by the SOC is not monitored within a preset period, the SOC is controlled to restart.

[0131] Optionally, the control device 30 further includes:

[0132] The communication establishing module is used to establish a communication connection with the SOC after the SOC is powered on, so as to receive the status information of each stage fed back by the SOC through the communication connection.

[0133] Optionally, the communication connection is a remote procedure call.

[0134] The control device provided in the embodiments of the present disclosure, which can be configured on an MCU of a vehicle computer, can execute any of the control methods provided in the embodiments of the present disclosure for use on an MCU of a vehicle computer, and has the corresponding functional modules and beneficial effects. Any details not fully described in the embodiments of the present disclosure may be referred to in the description of any of the method embodiments of the present disclosure.

[0135] In order to implement the above embodiments, the present disclosure also provides a control device.

[0136] Figure 4 This is a structural schematic diagram of a control device provided in one embodiment of the present disclosure. The device can be implemented using software and / or hardware and can be integrated into a vehicle. Specifically, it can be integrated into the SOC of the vehicle computer in the vehicle. The vehicle computer also includes an MCU, and the SOC is communicatively connected to the MCU.

[0137] like Figure 4 As shown, the control device 40 provided in the embodiment of the present disclosure may include: a receiving module 401 and a restarting module 402, wherein:

[0138] The receiving module 401 is configured to receive a restart instruction sent by the MCU of the vehicle computer, wherein the restart instruction is sent by the MCU when the MCU fails to detect the status information of any startup phase within a waiting time corresponding to any startup phase of the SOC;

[0139] The restart module 402 is configured to restart according to the restart instruction.

[0140] The control device provided in the embodiments of the present disclosure, which can be configured on a vehicle-mounted SOC, can execute any of the control methods provided in the embodiments of the present disclosure for use on a vehicle-mounted SOC, and has the corresponding functional modules and beneficial effects. Any details not fully described in the device embodiments of the present disclosure may be referenced in the description of any of the method embodiments of the present disclosure.

[0141] The present disclosure also provides an electronic device, including:

[0142] at least one processor;

[0143] and a memory communicatively connected to the at least one processor; wherein,

[0144] The at least one processor is used to execute the steps of each embodiment of the control method as described in any of the above embodiments by calling the program or instructions stored in the memory. To avoid repeated description, they are not repeated here.

[0145] An embodiment of the present disclosure also provides a computer-readable storage medium, which is non-transitory and stores programs or instructions. The programs or instructions enable a computer to execute the steps of each embodiment of the control method as described in any of the aforementioned embodiments. To avoid repeated description, they will not be repeated here.

[0146] The embodiments of the present disclosure also provide a vehicle system, including the control device provided by the embodiments of the present disclosure or the electronic device provided by the embodiments of the present disclosure.

[0147] An embodiment of the present disclosure further provides a vehicle, comprising the control device provided by an embodiment of the present disclosure, the electronic device provided by an embodiment of the present disclosure, or the vehicle-mounted system provided by an embodiment of the present disclosure.

[0148] The embodiments of the present disclosure further provide a computer program product, which is used to execute the steps of each embodiment of the control method as described in any of the aforementioned embodiments.

[0149] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0150] The foregoing description is intended only to provide specific embodiments of the present disclosure, intended to enable those skilled in the art to understand and implement the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the embodiments described herein, but rather to be construed in the broadest manner consistent with the principles and novel features disclosed herein.

Claims

1. A control method, characterized in that: The method for the MCU used in a vehicle computer includes: During the SOC startup process of the vehicle computer, the state information fed back by the SOC in each startup phase is sequentially monitored, wherein the state information fed back by the SOC is monitored during the waiting time of each startup phase; If the state information fed back by the SOC is not monitored during any of the startup phases, sending a restart instruction to the SOC; The MCU is preset with a standard waiting time corresponding to the first startup phase in the startup process of the SOC, and the method further includes: Determine the waiting time of each startup phase; wherein, If the startup phase is the first startup phase, the standard waiting time is determined as the waiting time of the startup phase; If the startup phase is not the first startup phase, the first waiting time period fed back by the SOC when feeding back the status information of the previous startup phase is determined as the waiting time period of the startup phase.

2. The method according to claim 1, characterized in that The MCU is also preset with standard waiting times corresponding to other startup stages except the first startup stage during the startup process of the SOC. The first waiting time fed back when the SOC feeds back the status information of the previous startup stage is determined as the waiting time of the startup stage, including: The waiting time corresponding to the startup phase is updated from the standard waiting time corresponding to the startup phase to the first waiting time.

3. The method according to any one of claims 1-2, characterized in that The sequentially monitoring the state information fed back by the SOC in each startup phase includes: receiving feedback information fed back by the SOC during each startup phase, the feedback information including a phase identifier and startup information; According to the stage identifier, acquiring target reference information corresponding to the stage identifier from reference information corresponding to each startup stage preset in the MCU; If the startup information is inconsistent with the target reference information, determining that the state information of the SOC feedback is not monitored during the target startup phase corresponding to the phase identifier; In a case where the startup information is consistent with the target reference information, it is determined that the state information of the SOC feedback is monitored in the target startup phase corresponding to the phase identifier.

4. The method according to any one of claims 1 to 2, characterized in that The status information is a feedback message sent by the SOC to the MCU after starting any startup phase, indicating that any startup phase is successfully started; or The state information is startup information generated during the process of the SOC starting each startup phase.

5. The method according to any one of claims 1-2, characterized in that The method further comprises: After the SOC enters the system operation stage, monitoring system status information fed back by the SOC; If the system status information fed back by the SOC is not monitored within a preset period, the SOC is controlled to restart.

6. A control method, characterized in that: For a vehicle-mounted SOC, the method includes: receiving a restart instruction sent by the MCU of the vehicle computer, the restart instruction being sent by the MCU because the MCU fails to detect status information of any startup stage within a waiting time corresponding to any startup stage of the SOC, the MCU being preset with a standard waiting time corresponding to the first startup stage in the startup process of the SOC, and the MCU determining the waiting time of each startup stage; wherein, if the startup stage is the first startup stage, the standard waiting time is determined as the waiting time of the startup stage; if the startup stage is not the first startup stage, the first waiting time fed back by the SOC when feeding back status information of the previous startup stage is determined as the waiting time of the startup stage; Restart according to the restart instruction.

7. A control device, characterized in that: An MCU for a vehicle computer, the device comprising: A monitoring module is configured to monitor, in sequence, the state information fed back by the SOC during each startup phase of the vehicle computer during startup, wherein the state information fed back by the SOC is monitored during the waiting period of each startup phase; a restart control module, configured to send a restart instruction to the SOC when no status information fed back by the SOC is monitored during any of the startup phases; The MCU is preset with a standard waiting time corresponding to the first startup phase in the startup process of the SOC, and the device further includes: The determination module is used to determine the waiting time of each startup phase; wherein, If the startup phase is the first startup phase, the standard waiting time is determined as the waiting time of the startup phase; If the startup phase is not the first startup phase, the first waiting time period fed back by the SOC when feeding back the status information of the previous startup phase is determined as the waiting time period of the startup phase.

8. A control device, characterized in that: The SOC for a vehicle computer includes: a receiving module, configured to receive a restart instruction sent by the MCU of the vehicle computer, the restart instruction being sent by the MCU when the MCU fails to detect status information of any startup stage within a waiting time corresponding to any startup stage of the SOC, the MCU being preset with a standard waiting time corresponding to the first startup stage in the startup process of the SOC, and the MCU determining the waiting time of each startup stage; wherein, if the startup stage is the first startup stage, the standard waiting time is determined as the waiting time of the startup stage; if the startup stage is not the first startup stage, the first waiting time fed back by the SOC when feeding back status information of the previous startup stage is determined as the waiting time of the startup stage; The restart module is used to restart according to the restart instruction.

9. An electronic device, characterized in that: include: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The at least one processor is configured to execute the control method according to any one of claims 1 to 6 by calling the program or instruction stored in the memory.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program or an instruction, wherein the program or the instruction causes a computer to execute the control method according to any one of claims 1 to 6.

11. A vehicle computer system, characterized in that: The device comprises the control device according to claim 7 or 8 or the electronic device according to claim 9.

12. A vehicle, characterized in that: It includes the control device according to claim 7 or 8, the electronic device according to claim 9, or the vehicle system according to claim 11.

Images