Smart driving domain controller security starting control method, smart driving domain controller and vehicle

Abstract

The smart driving domain controller security startup control method, the smart driving domain controller and the vehicle provided by the application relate to the field of intelligent driving, and aim to eliminate the security blind area of independent verification of multiple chips lacking unified arbitration and improve the security and consistency of the startup process of the smart driving domain controller. The micro control unit (MCU) applied to the smart driving domain controller comprises: after the MCU completes self security startup, the system on chip (SOC) and the switch chip (LSW) are powered on; the SOC is configured to load the intelligent driving application program corresponding to the first version partition; the LSW is configured to load the network communication protocol firmware corresponding to the second version partition; first version number information from the SOC and second version number information from the LSW are received, which respectively represent version number information corresponding to the first version partition and version number information corresponding to the second version partition; the above version number information is compared with preset version information stored in the MCU respectively; and according to the comparison result, corresponding security control instructions are sent to the SOC and the LSW respectively.

Description

Technical Field

[0001] This application relates to the field of intelligent driving, and in particular to a safe start control method for an intelligent driving domain controller, an intelligent driving domain controller, and a vehicle. Background Technology

[0002] With the rapid iteration and development of intelligent driving technology, the intelligent driving domain controller needs to ensure that all internal chips work together safely and collaboratively to complete the initialization process during power-on. In existing solutions, most chips within the intelligent driving domain controller operate independently, lacking a unified security verification mechanism, which can easily create security blind spots and prevent the chips from collaboratively entering a unified safe operating state. Therefore, it is urgent to improve the security and consistency of the intelligent driving domain controller's startup process. Summary of the Invention

[0003] This application provides a safe startup control method for an intelligent driving domain controller, an intelligent driving domain controller, and a vehicle. It aims to eliminate the security blind spot of lacking unified arbitration in multi-chip independent verification by using an MCU to uniformly control the power-on sequence, centrally acquire and compare version information, and distribute control commands according to the comparison results, thereby improving the security and consistency of the intelligent driving domain controller startup process.

[0004] In a first aspect, embodiments of this application provide a safe startup control method for an intelligent driving domain controller, applied to a microcontroller unit (MCU) of the intelligent driving domain controller, comprising: after the MCU completes its own safe startup, controlling the system-on-a-chip (SOC) and switching chip (LSW) in the intelligent driving domain controller to power on; wherein, the SOC is configured to load the intelligent driving application corresponding to a first version partition; the LSW is configured to load the network communication protocol firmware corresponding to a second version partition; receiving first version number information from the SOC and second version number information from the LSW, wherein the first version number information is used to characterize the version number information corresponding to the first version partition, and the second version number information is used to characterize the version number information corresponding to the second version partition; comparing the first version number information and the second version number information with preset version information respectively; the preset version information is stored in the MCU; and sending corresponding safety control commands to the SOC and LSW respectively according to the comparison results.

[0005] Based on the aforementioned technical means, the intelligent driving domain controller secure startup control method provided in this application, after the MCU completes its own secure startup, uniformly controls the power-on of the SOC and LSW. The SOC loads the intelligent driving application corresponding to the first version partition, and the LSW loads the network communication protocol firmware corresponding to the second version partition. This allows the MCU to uniformly manage the startup timing of the other chips under the premise of its own trustworthiness, preventing the SOC and LSW from running prematurely in an uncontrolled state and introducing security risks. Simultaneously, the MCU receives the first version number information reported by the SOC and the second version number information reported by the LSW, enabling it to obtain the current actual version number information corresponding to the first and second version partitions. Thus, based on the chips completing their own security verification, the MCU uniformly collects the version status data of the two chips, providing a true and complete input basis for subsequent centralized version consistency comparison on the MCU side. On this basis, the aforementioned first and second version number information are compared with preset version information stored in the MCU, allowing the MCU to independently confirm the version consistency of the SOC and LSW based on a unified version whitelist, ensuring the uniformity and objectivity of the version judgment standard. Furthermore, based on the comparison results, the MCU sends corresponding security control commands to the SOC and LSW respectively, allowing chips with matching versions to enter normal working state and promptly preventing chips with mismatched versions from entering. This achieves coordinated and reliable startup of the SOC and LSW under the centralized arbitration of the MCU. In summary, this application eliminates the security blind spot of independent multi-chip verification lacking unified arbitration by uniformly controlling the power-on sequence, centrally acquiring and comparing version information, and distributing control commands based on the comparison results through the MCU, thereby improving the security and consistency of the intelligent driving domain controller startup process.

[0006] In one possible implementation, the MCU completes its secure boot process by: performing a signature verification of the application image in the MCU after a cold boot; the cold boot characterizes the first startup and operation of the MCU after power-on; after the signature verification of the application image passes, setting a preset flag bit to a first state value and triggering an MCU reset; the first state value indicates that the application image has passed the signature verification; the reset is used to restart the MCU and reload the application image; after the MCU resets, in response to the flag bit being set to the first state value, skipping the signature verification of the application image to complete the secure boot of the MCU; wherein the duration of the handshake signal sent externally after the MCU resets and restarts is less than a preset timeout threshold, and the preset timeout threshold is less than the time when the handshake signal is sent externally after the MCU cold boots.

[0007] Based on the above technical means, after completing the signature verification of the application image and setting the flag bit during the cold start phase, the system actively resets. After the reset and restart, the system responds to the flag bit to skip the duplicate signature verification. This allows the MCU to shorten the time for sending the handshake signal after the reset and restart to within the preset timeout threshold while ensuring the complete verification of the application image. At the same time, since the preset timeout threshold is less than the time when the MCU sends the handshake signal after the cold start, the handshake signal can be sent earlier, thereby meeting the vehicle's requirements for the real-time startup of the MCU and avoiding the vehicle from misjudging the domain control status due to waiting timeout.

[0008] In one possible implementation, after the application image signature verification fails, a preset flag is set to a second state value, and the signature verification of the application image in the MCU is performed again; the second state value is that the application image has failed the signature verification.

[0009] Based on the above technical means, by setting the flag to the second state value and re-performing the signature verification when the application image signature verification fails, the MCU can retry and confirm the first verification failure, avoiding misjudgment caused by occasional read errors or transient interference, thereby improving the reliability and fault tolerance of the MCU's own secure startup.

[0010] In one possible implementation, based on the comparison result, corresponding security control instructions are sent to the SOC and LSW respectively, including: if the first version number information is consistent with the preset version information and the second version number information is consistent with the preset version information, sending an allow operation instruction to the SOC and LSW respectively.

[0011] Based on the above technical means, the MCU only sends a run permission instruction to both SOC and LSW when the version number information reported by both SOC and LSW is consistent with the preset version information. This ensures that SOC and LSW can only enter normal working state after passing the unified version verification of the MCU, thus preventing any chip from running prematurely with an abnormal version or without verification, and ensuring version consistency and operational security during the startup process of the intelligent driving domain controller.

[0012] In one possible implementation, based on the comparison result, corresponding security control instructions are sent to the SOC and LSW respectively, including: when the target version number information is inconsistent with the preset version information, sending a partition switching instruction to the target chip corresponding to the target version number information; the target version number information is either a first version number information or a second version number information, and the target chip is an SOC or an LSW; the partition switching instruction is used to instruct the target chip to switch to the backup partition and restart; receiving the new version number information reported by the target chip after restarting, the new version number information is used to characterize the version of the first version partition or the second version partition running after the target chip switches; based on the secondary comparison result of the new version number information and the preset version information, sending corresponding security control instructions to the target chip.

[0013] Based on the above technical means, when the version number information of any chip is inconsistent, the MCU does not directly determine the system failure. Instead, it first sends a partition switching command to the target chip, causing it to switch to the backup partition and restart. It then receives the new version number information that is re-reported, thus providing a recovery opportunity for occasional partition anomalies. By using the backup partition as an alternative boot source, the chip is prevented from becoming unusable due to a single partition anomaly, thereby improving the fault tolerance of the intelligent driving domain controller boot process.

[0014] In one possible implementation, based on the result of a secondary comparison between the new version number information and the preset version information, a corresponding security control command is sent to the target chip, including: when the new version number information matches the preset version information, sending an allow-to-run command to the target chip; when the new version number information still does not match the preset version information, executing a system-level degradation strategy; wherein the system-level degradation strategy includes at least one of the following: sending a fault message to the vehicle controller; sending a disable function output command to the SOC; and disabling the LSW data forwarding function.

[0015] Based on the above technical means, according to the results of the second comparison, the target chip is allowed to operate normally when the new version number information is consistent, and when it is still inconsistent, a system-level degradation strategy is executed, so that the system can continue to work normally when the recovery is successful, and can uniformly enter the known safe degradation state when the recovery fails. By sending fault messages to the vehicle controller, disabling SOC function output or turning off LSW data forwarding, the abnormal chip is prevented from continuing to output control signals or forward network data, thus ensuring the safety of the vehicle in fault scenarios.

[0016] In one possible implementation, the method further includes: if no new version number information is received from the target chip after restarting within a preset time, a system-level downgrade strategy is executed.

[0017] Based on the above technical means, after sending the partition switching command to the target chip, if no new version number information is received within a preset time, the system-level degradation strategy is directly executed. This allows the MCU to control the system to enter a safe state in a timely manner without having to wait indefinitely for the target chip's response. This avoids the startup process being suspended for a long time due to the target chip's lack of response or communication abnormalities, thus improving the timeliness of fault handling and the reliability of the system.

[0018] Secondly, this application provides a safe startup control device for an intelligent driving domain controller, comprising: a power-on control module, used to control the system-on-a-chip (SOC) and the switching chip (LSW) in the intelligent driving domain controller to power on after the microcontroller unit (MCU) in the intelligent driving domain controller completes its own safe startup; wherein, the SOC is configured to load the intelligent driving application corresponding to a first version partition; the LSW is configured to load the network communication protocol firmware corresponding to a second version partition; a version receiving module, used to receive first version number information from the SOC and second version number information from the LSW, wherein the first version number information is used to characterize the version number information corresponding to the first version partition, and the second version number information is used to characterize the version number information corresponding to the second version partition; a version comparison module, used to compare the first version number information and the second version number information with preset version information respectively; the preset version information is stored in the MCU; and an instruction sending module, used to send corresponding safety control instructions to the SOC and the LSW respectively according to the comparison results.

[0019] Thirdly, this application provides an intelligent driving domain controller, including a microcontroller unit (MCU); the MCU is configured to perform the method of the first aspect or any possible implementation thereof.

[0020] Fourthly, this application provides a vehicle including a smart driving domain controller safety start control device as described in the second aspect above and any possible implementation thereof, or a smart driving domain controller as described in the third aspect above.

[0021] Fifthly, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed on a device, cause the device to perform the method of the first aspect or any possible implementation thereof.

[0022] In a sixth aspect, this application provides a computer program product comprising a computer program or instructions that, when executed on a device, cause the device to perform the method of the first aspect or any possible implementation thereof.

[0023] The second to sixth aspects described above correspond to the technical solutions of the first aspect of the embodiments of this application. The beneficial effects achieved by each aspect and its corresponding feasible implementation are similar, and will not be repeated here. It should be noted that various possible implementations of any aspect described above can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0024] Figure 1 A schematic diagram illustrating the composition of an intelligent driving domain controller provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the communication connection relationship of an intelligent driving domain controller provided in an embodiment of this application; Figure 3 A flowchart illustrating a safe startup control method for an intelligent driving domain controller provided in this application embodiment; Figure 4 A timing diagram illustrating a secure boot process for an MCU provided in this application embodiment; Figure 5 A schematic diagram of a region retries and secondary comparison provided for an embodiment of this application; Figure 6 This application provides a schematic diagram of a smart driving domain controller degradation process. Figure 7 An interactive timing diagram of a safe start control method for an intelligent driving domain controller provided in an embodiment of this application; Figure 8 This application provides an overall flowchart of a safe start control method for an intelligent driving domain controller. Figure 9 This application provides a schematic diagram of the structure of a safe start control device for an intelligent driving domain controller. Figure 10 This is a schematic diagram of the composition of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Those skilled in the art will recognize that, with the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0026] Based on the aforementioned background technology, the intelligent driving domain controller secure startup control method provided in this application, after the MCU completes its own secure startup, uniformly controls the power-on of the SOC and LSW. The SOC loads the intelligent driving application corresponding to the first version partition, and the LSW loads the network communication protocol firmware corresponding to the second version partition. This allows the MCU to uniformly manage the startup timing of the other chips under the premise of its own trustworthiness, preventing the SOC and LSW from running prematurely in an uncontrolled state and introducing security risks. Simultaneously, the MCU receives the first version number information reported by the SOC and the second version number information reported by the LSW, enabling it to obtain the actual version number information corresponding to the first and second version partitions. Thus, based on the chips completing their own security verification, the MCU uniformly collects the version status data of the two chips, providing a true and complete input basis for subsequent centralized version consistency comparison on the MCU side. Based on this, the aforementioned first and second version number information are compared with preset version information stored in the MCU, allowing the MCU to independently confirm the version consistency of the SOC and LSW based on a unified version whitelist, ensuring the uniformity and objectivity of the version judgment standard. Furthermore, based on the comparison results, the MCU sends corresponding security control commands to the SOC and LSW respectively, allowing chips with matching versions to enter normal working state and promptly preventing chips with mismatched versions from entering. This achieves coordinated and reliable startup of the SOC and LSW under the centralized arbitration of the MCU. In summary, this application eliminates the security blind spot of independent multi-chip verification lacking unified arbitration by uniformly controlling the power-on sequence, centrally acquiring and comparing version information, and distributing control commands based on the comparison results through the MCU, thereby improving the security and consistency of the intelligent driving domain controller startup process.

[0027] The intelligent driving domain controller safety start control method provided in this application embodiment is applied to the intelligent driving domain controller and can be installed in a vehicle. Please refer to [link / reference]. Figure 1 The intelligent driving domain controller 100 includes a microcontroller unit (MCU) 101, a system-on-chip (SOC) 102, and a switching chip (LSW) 103. It should be understood that the intelligent driving domain controller 100 is used to perform a coordinated and safe startup of the MCU 101, SOC 102, and LSW 103 in the intelligent driving domain controller when the vehicle is powered on, ensuring that the intelligent driving functions operate in a trusted state.

[0028] Among them, vehicles can be, but are not limited to, pure electric vehicles (PEV / BEV), hybrid electric vehicles (HEV), range-extended electric vehicles (REEV), plug-in hybrid electric vehicles (PHEV), new energy vehicles, fuel cell electric vehicles (FCEV), intelligent connected vehicles (ICV), and autonomous vehicles (AV).

[0029] In one possible implementation, the aforementioned MCU 101, SOC 102, and LSW 103 are integrated on the same PCB board. MCU 101 is connected to the power enable pins of both SOC 102 and LSW 103 via a power management circuit to control their power-on and power-off. MCU 101 is also connected to SOC 102 and LSW 103 via a serial peripheral interface (SPI) or an inter-integrated circuit (IIC) communication channel to receive version number information and issue safety control commands. MCU 101 is further connected to the vehicle controller via a CAN bus to send first-frame messages and fault messages. SOC 102 and LSW 103, as well as MCU 101 and LSW 103, can also be connected via an Ethernet interface, but MCU 101 serves as the arbitration center during the safe startup process.

[0030] The vehicle controller is connected to the MCU 101 via the CAN bus to receive the first frame message and fault message sent by the MCU 101, and switches the vehicle to the restricted mode according to the fault message.

[0031] The MCU 101 includes a boot read-only memory (Boot ROM), flash memory, and non-volatile registers or protected memory cells.

[0032] In one possible implementation, the Boot ROM is used to execute initial startup code when the MCU 101 is powered on and to verify the bootloader in Flash as a root of trust.

[0033] In one possible implementation, the Flash memory includes a bootloader area, an application area, and a configuration area. The bootloader area stores the bootloader program, the application area stores the application image, and the configuration area stores the configuration parameters required for MCU operation.

[0034] In one possible implementation, a non-volatile register or protected memory cell is used to store preset version information and a flag bit that indicates whether the application image has passed signature verification.

[0035] In one possible implementation, the application image is the main control program running on MCU 101. This application image is used to execute secure boot control logic to perform version verification and operation control on the intelligent driving application loaded and running in SOC 102 and the network communication protocol firmware loaded and running in LSW 103.

[0036] In one possible implementation, the MCU 101 acts as the root of trust and centralized arbitration center of the intelligent driving domain controller, used to implement the secure startup control method provided in this application embodiment. Specifically, it includes: completing its own secure startup, controlling the power-on of the SOC 102 and LSW 103, receiving version number information reported by the SOC 102 and LSW 103, comparing the version number information with preset version information, and sending secure control commands to the SOC 102 and LSW 103 respectively based on the comparison result.

[0037] SOC 102 includes a bootloader area, an operating system area, an algorithm model area, a first-version partition, and a backup first-version partition. The bootloader area stores the bootloader program for SOC 102; the operating system area stores the operating system required for SOC 102 to run; and the algorithm model area stores intelligent driving-related algorithm models. The first-version partition and the backup first-version partition store different versions of intelligent driving applications, with the version number information corresponding to the currently running application partition being reported to MCU 101.

[0038] In one possible implementation, SOC 102 is used to load and run the first version partition corresponding to the intelligent driving related application, and respond to the partition switching instruction sent by MCU 101 to switch to the backup first version partition and restart when the version of the current first version partition is inconsistent with the preset version information.

[0039] The LSW 103 is an Ethernet switch chip that supports firmware signature verification. Its internal firmware storage includes a second version partition and a backup second version partition.

[0040] In one possible implementation, the second version partition and the backup second version partition are used to store different versions of the network communication protocol firmware, and the version number information of the currently running second version partition is used to report to the MCU 101; the LSW 103 may also include a configuration table for storing Ethernet data forwarding rules. The network communication protocol firmware is used to implement Ethernet data exchange within the intelligent driving domain controller and between the intelligent driving domain controller and the external vehicle network, providing a data communication channel for the intelligent driving application in the SOC 102.

[0041] In one possible implementation, LSW 103 is used to load and run the second version partition of the network communication protocol firmware, and respond to the partition switching command sent by MCU 101 to switch to the backup second version partition and restart when the version of the current second version partition is inconsistent with the preset version information; LSW 103 is also used to perform Ethernet data forwarding after the secure boot is completed.

[0042] In summary, during operation, after completing its own safe startup, MCU 101 controls the power-on of SOC 102 and LSW 103 through the power management circuit. SOC 102 and LSW 103 load and run from their respective first and second version partitions, and report their version number information to MCU 101 via SPI or IIC communication channels. After comparing the version number information with the preset version information stored in itself, MCU 101 sends the corresponding safety control commands to SOC 102 and LSW 103 through the communication channel, and exchanges messages with the vehicle controller through the CAN bus, thereby completing the coordinated safe startup of the intelligent driving domain controller.

[0043] based on Figure 1 Please see Figure 2 , Figure 2 This is a schematic diagram illustrating the communication connection relationship of an intelligent driving domain controller provided in an embodiment of this application, including an MCU 101, a SOC 102, an LSW 103, and a first power management chip (such as...). Figure 2 PMIC_1) and second power management chip (such as Figure 2 (PMIC_2). Among them, MCU 101 includes Boot ROM, FBL, APP, configuration area and data segment; LSW103 includes A / B second version partition and configuration table; SOC 102 includes A / B first version partition and operating system / model storage area.

[0044] MCU 101 connects to PMIC_1 and PMIC_2 via the IIC control interface to control their power outputs. PMIC_1 connects to SOC 102 via a power control line to power SOC 102. PMIC_2 connects to LSW 103 via a power control line to power LSW 103. MCU 101 also connects to SOC 102 and LSW 103 via SPI / IIC control channels to transmit version number information and security control commands. Furthermore, MCU 101 and LSW 103, as well as SOC 102 and LSW 103, are connected via Ethernet communication interfaces.

[0045] It should be noted that the A / B application partition of SOC 102 corresponds to the first version partition or backup first version partition mentioned above; the operating system / model storage area is used to store the operating system and algorithm model. In MCU 101, the Boot ROM is used to execute the initial startup code and verify the FBL (Flyer Bootloader), which is used to verify the APP; the APP is the application image used to execute the main control logic of MCU 101, i.e., to perform safe startup control of the intelligent driving application running in SOC 102; the configuration area is used to store configuration parameters; the data segment is used to store runtime data. The A / B firmware partition of LSW 103 corresponds to the second version partition or backup second version partition, used to store different versions of network communication protocol firmware; the configuration table is used to store Ethernet data forwarding rules.

[0046] It should be noted that, in the embodiments of this application, Figure 1 The structure shown and Figure 2 The connections shown do not constitute a limitation on the intelligent driving domain controller of this application. The intelligent driving domain controller may include more or fewer components or modules than shown in the figures, or combine or separate certain components, or employ different arrangements. The components shown in the figures can be implemented in hardware, software, or a combination of both.

[0047] The following describes the intelligent driving domain controller safe start control method provided in this application with reference to specific embodiments. These embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0048] Figure 3 This application provides a flowchart illustrating a safe startup control method for an intelligent driving domain controller, applicable to... Figure 1 The MCU in the intelligent driving domain controller. (Refer to...) Figure 3 The intelligent driving domain controller safe start control method provided in this application embodiment may include: S301. After the MCU completes its own safe startup, it controls the system-on-a-chip (SOC) and switching chip (LSW) in the intelligent driving domain controller to power on.

[0049] The SOC is configured to load the intelligent driving application corresponding to the first version partition; the LSW is configured to load the network communication protocol firmware corresponding to the second version partition.

[0050] Microcontroller unit (MCU) refers to a microprocessor integrated inside the intelligent driving domain controller, used to perform vehicle communication, power management, and safety arbitration functions.

[0051] A System-on-a-Chip (SOC) is a large-scale integrated circuit that integrates a processor core, a memory controller, and peripheral interfaces for running intelligent driving-related applications. A first-version partition refers to a storage area within the SOC used to store intelligent driving applications, and each first-version partition corresponds to a version number. For example, an intelligent driving application may include at least one of a perception fusion algorithm, a planning and decision-making algorithm, and a vehicle control algorithm.

[0052] A Lightning Switching Module (LSW) is a dedicated chip that supports firmware signature verification and is used to implement Ethernet data exchange. A Second Version Partition (SMP) is a storage area within the LSW used to store network communication protocol firmware; each SMP partition corresponds to a version number. For example, the network communication protocol firmware may include at least one of the following: Ethernet switching configuration, Virtual Local Area Network (VLAN) partitioning, data forwarding rules, and diagnostic protocol stack.

[0053] In one possible implementation, the MCU, SOC, and LSW are all located on the same PCB board of the intelligent driving domain controller. The MCU is connected to the power enable terminals of the SOC and LSW respectively through a power management circuit, and is connected to the SOC and LSW respectively through SPI or IIC communication channels.

[0054] In one possible implementation, the MCU can complete its secure boot process as follows: after a cold boot, the MCU performs a signature verification on the application image within the MCU. Once the signature verification is successful, the MCU enters normal operation. The application image refers to the binary code file stored in the application area of ​​the MCU's Flash memory, used to execute the MCU's main control logic.

[0055] In another possible implementation, the MCU completes its own secure boot by: performing a signature verification of the application image in the MCU after a cold boot; setting a preset flag to a first state value and triggering an MCU reset after the application image's signature verification passes; and skipping the signature verification of the application image after the MCU resets in response to the flag being set to the first state value, thereby completing the MCU's own secure boot.

[0056] The first status value indicates that the application image has passed signature verification; the reset function restarts the MCU and reloads the application image. It should be understood that the first status value is a preset non-zero value, and the reset is a hot reset actively triggered by the MCU, used to separate the time-consuming application image signature verification from the complete hardware initialization into two startup phases.

[0057] A cold start refers to the first startup and operation of an MCU after it has been powered on from a power-off state. That is, the first time the MCU is powered on, it starts executing from the Boot ROM and goes through the complete startup process of boot loading and application loading in sequence.

[0058] A hot reset refers to a reset operation triggered by the application program while the MCU is already powered on and running. After a hot reset, the MCU resumes execution from the Boot ROM, but this startup is not the first run after power-on, so it is different from a cold start in terms of startup type.

[0059] In one implementation, the duration for which the MCU sends a handshake signal after a reset and restart is less than a preset timeout threshold, and the preset timeout threshold is less than the time when the MCU sends a handshake signal after a cold start.

[0060] The preset timeout threshold is determined based on the timing requirements of the vehicle system for the first frame message of the MCU, and this application does not impose specific limitations on it.

[0061] The duration for the MCU to send a handshake signal after a reset and restart refers to the time interval between the moment the MCU undergoes a hot reset and the moment it sends the handshake signal via the CAN bus. Since the MCU skips signature verification of the application image after reset due to the flag being in the first state value, this duration is relatively short and can be less than the preset timeout threshold.

[0062] The timing of the handshake signal sent by the MCU after a cold start refers to the time interval between the MCU's power-on and the first time it sends a handshake signal via the CAN bus. Because the cold start phase requires a complete signature verification of the application image, this timing is relatively late.

[0063] It should be understood that the preset timeout threshold is the maximum time allowed for the domain controller in the vehicle system to send a handshake signal from reset. If this preset timeout threshold is less than the time it takes for the MCU to send a handshake signal after a cold start, it means that the timing requirement cannot be met under the cold start path. However, if the time it takes for the MCU to send a handshake signal after a reset and restart is less than the preset timeout threshold, it indicates that the hot reset path can meet the vehicle's timing requirements. Therefore, by using a two-stage startup method—completing signature verification and active reset during the cold start phase, and skipping signature verification and quickly sending a handshake signal during the hot reset phase—the MCU can compress the time for sending a handshake signal to within the vehicle's allowed time window while ensuring complete signature verification of the application image, thus balancing the integrity of security verification and the real-time nature of the startup response.

[0064] This implementation separates the complete signature verification in the cold start path from the rapid handshake signal transmission in the hot reset path, ensuring that the duration of the handshake signal transmission after the MCU resets and restarts is less than a preset timeout threshold. This satisfies the vehicle's requirements for the domain controller's startup sequence without compromising the security of signature verification.

[0065] In one implementation, the MCU's secure boot process is achieved through a bootable read-only memory (Boot ROM) and a Flash bootloader (FBL). After power-on, the MCU executes from the Boot ROM, which acts as a root of trust and verifies the signature of the FBL. Upon successful verification, it jumps to the FBL. The FBL reads preset flags; when the flags are in their initial state, it performs signature verification on the application image. Upon successful verification, it jumps to the application. When the application first enters and is determined to be a cold boot, it only initializes the clock, stack, and watchdog timer, without initializing the CAN peripherals. It sets the flags to the first state value, performs a security self-test, and actively triggers an MCU reset. After the MCU resets, it boots again from the Boot ROM. The Boot ROM verifies the FBL again. Upon reading the first state value, the FBL clears the flags and skips the signature verification of the application image, directly jumping to the application. When the application re-enters and is determined to be a hot reset, it initializes the CAN / CANFD controller, GPIO, and communication protocol stack, and sends the first status message to the vehicle controller via the CAN bus. At this point, the MCU completes its secure boot process. This two-stage startup method separates the time-consuming application image verification from the complete hardware initialization through an actively triggered functional safety reset, and skips repeated verification and initialization in the hot reset path, thereby shortening the time for sending the first frame message while ensuring security.

[0066] For example, please refer to Figure 4 , Figure 4 This is a timing diagram illustrating a secure boot process for an MCU, as provided in an embodiment of this application. Figure 4As shown, during a cold start upon power-on, the Boot ROM completes the signature verification and then starts the FBL. The FBL reads the flag bit as 0 and performs signature verification on the APP. If the signature verification is successful, the user jumps to the APP. After the APP completes its initialization, it performs minimal initialization and writes the flag bit to 0xA5A5A5A5. It then executes functional safety logic and triggers a hot reset. A reset signal is sent to the Boot ROM to enter the hot reset process. Under the hot reset, the Boot ROM quickly performs signature verification and then starts the FBL. The FBL reads the flag bit as 0xA5A5A5A5 and clears the flag bit. Without needing to verify the signature on the APP again, the user jumps directly to the APP. The APP performs a complete initialization, including CAN, and sends the first CAN message.

[0067] This implementation separates the application image (APP) signature verification from the complete hardware initialization into two stages: cold start and hot reset. By skipping repeated signature verification during the hot reset stage, the MCU can significantly shorten the time for sending the first frame message while ensuring complete security verification, thus meeting the vehicle's requirements for the real-time performance of the first frame message during cold start.

[0068] In one possible implementation, after the application image signature verification fails, a preset flag is set to a second state value, and the signature verification of the application image in the MCU is performed again; the second state value is that the application image has failed the signature verification.

[0069] The second state value refers to a preset flag value that differs from the first state value, used to record the application image signature verification failure status. Re-performing signature verification means that after the initial signature verification fails, the MCU re-performs the signature verification operation on the application image to eliminate occasional verification failures caused by momentary interference or read anomalies.

[0070] It should be understood that when the application image signature verification fails, the MCU does not immediately enter normal operating state. Instead, it sets the flag to the second state value and performs signature verification again. If the verification passes again, the flag can be updated to the first state value, and the subsequent startup process can continue. If the verification fails again, the MCU remains in abnormal operating state and does not send the first frame message.

[0071] In this embodiment, by setting a second state value and re-performing the signature verification when the signature verification fails, the MCU can retry and confirm the initial verification failure, thereby reducing the probability of startup failure due to occasional errors and improving the fault tolerance and reliability of the MCU's own secure startup.

[0072] In one possible implementation, when the MCU fails to verify during its own safe startup process, the MCU does not initiate any communication, nor does it power on the SOC and LSW. The entire vehicle directly detects that the intelligent driving domain controller is unresponsive. This situation belongs to the highest level of fault handling.

[0073] In this implementation, by not initiating any communication or powering on the SOC and LSW when verification fails during the MCU's own secure startup process, the MCU remains silent when it is untrusted. The entire vehicle can directly detect the lack of response from the intelligent driving domain controller. This prevents the untrusted MCU from continuing to power on the system-on-a-chip and switching chip, preventing security risks from spreading from the MCU to the SOC, LSW, and the vehicle network, achieving the highest level of fault isolation and ensuring vehicle safety.

[0074] In one possible implementation, the MCU sends an enable command to the power management circuit via the IIC control interface, and the power management circuit provides independent power to the SOC and LSW respectively, so that the SOC and LSW are powered on simultaneously and begin their respective safe boot processes.

[0075] Based on S301, by controlling the power-on of the SOC and LSW after the MCU completes its own secure boot, the power-on timing of the SOC and LSW is uniformly controlled by a trusted MCU that has completed security verification. This avoids the security risks introduced by the SOC and LSW powering on and running prematurely before the MCU is ready. At the same time, the SOC is configured to load and run the first version partition corresponding to the intelligent driving application, and the LSW is configured to load and run the second version partition of the network communication protocol. This allows the MCU to perform targeted verification and control on the partition versions actually running by the two chips in subsequent processes, providing a reliable timing basis and state acquisition prerequisite for the secure boot of multi-chip collaborative boot, thereby ensuring the security and consistency of the intelligent driving domain controller boot process.

[0076] S302, Receive the first version number information from the SOC and the second version number information from the LSW.

[0077] The first version number information is used to identify the version of the first version partition currently running in the SOC, and the second version number information is used to identify the version of the second version partition currently running in the LSW.

[0078] It should be understood that the first version number information refers to the data reported by the SOC to the MCU after completing its own security verification, which is used to identify the first version partition version it is currently running; the second version number information refers to the data reported by the LSW to the MCU after completing its own security verification, which is used to identify the second version partition version it is currently running.

[0079] In some embodiments, after the SOC powers on, it begins execution from its Boot ROM. The Boot ROM verifies the bootloader, which then verifies the operating system kernel and AI model files. After verification, the SOC does not immediately enter normal operating mode but waits for the MCU's permission to run. After the LSW powers on, it verifies the firmware image and configuration table through its internal firmware secure boot mechanism. After verification, it also waits for the MCU's permission to run. During the boot process, both the SOC and LSW store the version numbers of their respective currently running first and second version partitions in their local memory for later reporting to the MCU.

[0080] In one possible implementation, the MCU receives a first version number from the SOC and a second version number from the LSW via an SPI or IIC communication channel. A secure communication channel is pre-established between the SOC, LSW, and MCU, through which the version number information is transmitted. As a feasible implementation, this secure communication channel employs a pre-shared key-based authentication mechanism to prevent the version number information from being forged or tampered with during transmission. After receiving the version number information, the MCU temporarily stores it in its internal storage area for later comparison with preset version information.

[0081] In this embodiment, by receiving the first version number information reported by the SOC and the second version number information reported by the LSW, the MCU can obtain the first version partition version currently running by the SOC and the second version partition version currently running by the LSW, thereby eliminating the blind spot caused by independent verification between chips and providing a data basis for the MCU to centrally determine whether the running version of each chip meets the system expectations.

[0082] Based on S302, the MCU uniformly receives version number information from SOC and LSW, enabling the MCU, as a centralized arbitration center, to simultaneously grasp the actual running version status of the two chips. This avoids the problem of failing to detect version anomalies by relying solely on the chip's own verification declaration, and provides a unified status acquisition channel for multi-chip collaborative secure boot.

[0083] S303. Compare the first version number information and the second version number information with the preset version information respectively.

[0084] The preset version information is stored in the MCU. This preset version information refers to the set of data stored within the MCU that characterizes the expected partition versions that the SOC and LSW should run. The preset version information can be stored as a whitelist in the MCU's non-volatile registers or protected memory, with its contents corresponding to the expected first partition version number of the SOC and the expected second partition version number of the LSW, respectively. Upon receiving the first version number information from the SOC and the second version number information from the LSW, the MCU compares the first version number information with the portion corresponding to the SOC in the preset version information, and compares the second version number information with the portion corresponding to the LSW in the preset version information.

[0085] In one possible implementation, when performing the comparison, the MCU verifies the validity of the formats of the first and second version number information, and matches the version number values ​​with preset version information item by item. If the version number format is valid and the value matches the preset version information, the comparison is considered successful; if the version number format is incorrect or the value does not match the preset version information, the comparison is considered unsuccessful. The MCU's comparison processes for the SOC and LSW are independent and do not affect each other.

[0086] For example, the preset version information may store the SOC expected first version partition version number field and the LSW expected second version partition version number field. When comparing, the MCU parses the corresponding version number field from the first version number information and the second version number information respectively, and matches it with the preset field to obtain the comparison result.

[0087] Based on S303, by comparing the received first version number information and second version number information with the preset version information stored in the MCU, the MCU can independently determine whether the current running partition version of the SOC and LSW meets the system expectations based on a unified standard, rather than relying on the self-declaration of the chip's own reported results. This provides an accurate and reliable basis for sending corresponding security control commands to the SOC and LSW based on the comparison results.

[0088] S304. Based on the comparison results, send the corresponding security control commands to the SOC and LSW respectively.

[0089] It should be understood that security control instructions refer to the instructions sent by the MCU to the SOC and LSW based on the version number comparison result to control their operating status. These include allow operation instructions and partition switching instructions. The allow operation instruction is used to instruct the corresponding chip to enter the normal operating state; the partition switching instruction is used to instruct the corresponding chip to switch to the backup partition and restart.

[0090] In one possible implementation, based on the comparison result, corresponding security control instructions are sent to the SOC and LSW respectively, including: if the first version number information is consistent with the preset version information and the second version number information is consistent with the preset version information, sending an allow operation instruction to the SOC and LSW respectively.

[0091] For example, once the MCU determines that the verification is successful, it sends an enable command to the SOC and LSW respectively through the SPI or IIC communication channel. After receiving the command, the SOC and LSW officially enter the normal working state and complete the safe startup of the entire intelligent driving domain controller. At this time, the system has complete intelligent driving functions.

[0092] In this embodiment, when the version numbers match, an instruction to allow operation is sent to the SOC and LSW respectively, so that the SOC and LSW are only allowed to enter the normal working state after passing the version verification of the MCU, thus ensuring the safety and controllability of the startup process.

[0093] Based on S301-S303, after completing its own secure boot, the MCU controls the SOC and LSW to power on. It receives the first version number from the SOC and the second version number from the LSW, comparing them with preset version information to determine if the current running partition version of the SOC and LSW matches the system's expectations. Based on this comparison, the MCU sends corresponding security control commands to the SOC and LSW, ensuring that only chips with matching versions are allowed to enter normal operation; chips with mismatched versions are prevented from operating. This allows for controllable management of the SOC and LSW's running versions under the MCU's centralized arbitration.

[0094] In another possible implementation, please refer to Figure 5 As shown, based on S304, "send corresponding security control commands to the SOC and LSW respectively according to the comparison results", including: S501. When the target version number information is inconsistent with the preset version information, a partition switching command is sent to the target chip corresponding to the target version number information.

[0095] The target version number information can be either the first version number information or the second version number information, and the target chip can be either a SOC or an LSW; the partition switching command is used to instruct the target chip to switch to the backup partition and restart.

[0096] It should be understood that when the MCU detects that the version number information reported by any chip in the SOC or LSW is inconsistent with the preset version information, it does not directly determine that the system has failed. Instead, it first attempts to recover by using a partition switching instruction. The target chip is the chip whose version number information is inconsistent. The partition switching instruction is the instruction sent by the MCU to the target chip, instructing it to switch from the currently running partition to another backup partition and restart.

[0097] In one possible implementation, when the target version number information is the first version number information and is inconsistent with the preset version information, the MCU sends a partition switching command to the SOC, instructing the SOC to switch the boot state from the current first version partition to the backup first version partition and perform a soft reset.

[0098] For example, if the SOC is currently running the first version partition and the reported first version number is inconsistent with the preset expected version number of the SOC, the MCU sends a partition switching command to the SOC. The SOC switches the boot partition to the backup first version partition and performs a soft reset, re-executing its secure boot process.

[0099] In one possible implementation, when the target version number information is the second version number information and is inconsistent with the preset version information, the MCU sends a partition switching command to the LSW, instructing the LSW to switch to the backup second version partition and perform a soft reset.

[0100] For example, if the LSW is currently running the second version partition and the reported second version number is inconsistent with the preset expected LSW version number, the MCU sends a partition switching command to the LSW. The LSW switches the boot partition to the backup second version partition and performs a soft reset, re-executing its secure boot process.

[0101] In one possible implementation, if the version number information reported by both the SOC and LSW is inconsistent with the preset version information, the MCU can process the SOC and LSW in parallel or serially. However, each target chip can send a switching partition instruction at most once, that is, each chip can switch partitions at most once, in order to avoid infinite loop retries.

[0102] S502: Receive the new version number information reported by the target chip after it restarts.

[0103] The new version number information is used to characterize the version of the first or second version partition that runs after the target chip is switched.

[0104] It should be understood that after the target chip switches to the backup partition and restarts, it will load and run the corresponding program or firmware from the backup partition. After completing the internal security verification, it will report the version number information of its currently running partition to the MCU again. This re-reported version number information is the new version number information.

[0105] In one possible implementation, when the target chip is a System-on-a-Chip (SOC), the new version number information is the third version number information, used to characterize the version of the first version partition running after the SOC switch. After the SOC switches to the backup first version partition and restarts, the reported third version number information is the version number of the backup first version partition.

[0106] In one possible implementation, when the target chip is an LSW, the new version number information is the fourth version number information, used to characterize the version of the second version partition running after the LSW switch. After the LSW switches to the backup second version partition and restarts, the reported fourth version number information is the version number of the backup second version partition.

[0107] S503: Based on the second comparison result between the new version number information and the preset version information, send the corresponding security control command to the target chip.

[0108] It should be understood that after receiving the new version number information re-reported by the target chip, the MCU will compare the new version number information with the preset version information for the second time, and decide whether to send an instruction to allow operation to the target chip or execute a system-level downgrade strategy based on the result of the second comparison.

[0109] In one possible implementation, based on the result of a second comparison between the new version number information and the preset version information, a corresponding security control instruction is sent to the target chip, including: when the new version number information is consistent with the preset version information, sending an instruction to allow operation to the target chip; when the new version number information is still inconsistent with the preset version information, executing a system-level downgrade strategy.

[0110] In one implementation, when the new version number information matches the preset version information, the MCU sends a permission to run instruction to the target chip. For example, if the third version number information re-reported after the SOC switches to the backup first version partition matches the preset expected SOC version number, the MCU sends a permission to run instruction to the SOC, the SOC enters normal working state, and the system resumes the normal startup process.

[0111] In one implementation, when the new version number information is still inconsistent with the preset version information, the MCU determines that the target chip has an unrecoverable fault and executes a system-level degradation strategy. For example, if the fourth version number information re-reported after the LSW switches to the backup second version partition is still inconsistent with the preset expected LSW version number, the MCU executes a system-level degradation strategy, disables the LSW's network data forwarding function, and sends a fault message to the vehicle controller.

[0112] The system-level degradation strategy includes at least one of the following: sending a fault message to the vehicle controller; sending a command to disable function output to the SOC; and disabling the data forwarding function of the LSW.

[0113] For example, sending a fault message to the vehicle controller can be as follows: The MCU sends a fault message to the vehicle controller via the CAN bus. The message identifier indicates that the message originates from the intelligent driving domain controller and is of type fault. The data fields include a fault level field, a fault source field, an error code field, and a version number field. The fault level field takes a preset value corresponding to a severe fault. The fault source field indicates whether the failed chip is a SOC or LSW. The error code field indicates whether the failure stage is an initial version check failure, a secondary version check failure, or a partition switching timeout. The version number field records the version number reported by the failed chip. After receiving the fault message, the vehicle controller parses the above fields, switches the vehicle to restricted mode, and executes the corresponding vehicle protection strategy based on the fault source and error code.

[0114] For example, sending a disable function output command to the SOC can be as follows: The MCU sends a command frame to the SOC via the SPI or IIC communication channel. The function code of this command frame is used to instruct the SOC to stop outputting various control signals. After receiving the command, the SOC stops outputting intelligent driving control commands to the actuators, retaining only communication and diagnostic functions to avoid unreliable control signals affecting the overall vehicle driving safety.

[0115] For example, disabling the data forwarding function of the LSW can be achieved by the MCU sending a disable data forwarding command to the LSW via the SPI or IIC communication channel. The function code of this command instructs the LSW to disable data forwarding on the ordinary Ethernet port. After receiving the command, the LSW disables the data forwarding function of the ordinary Ethernet port, allowing only diagnostic communication to pass through, in order to prevent untrusted firmware from spreading abnormal data to other domain controllers through the in-vehicle network.

[0116] In this embodiment, when versions are inconsistent, the MCU actively sends a partition switching command to the target chip, receives the re-reported new version number information, and performs a second comparison, enabling the MCU to actively recover from occasional partition anomalies. If the second comparison still fails, a system-level degradation strategy is executed to ensure that the system enters a known safe state, thereby improving the robustness and security of multi-chip collaborative startup.

[0117] Based on S501-S503, when the target version number information is inconsistent with the preset version information, the MCU sends a partition switching command to the target chip and receives the new version number information reported by the target chip after switching to the backup partition and restarting. Then, based on the second comparison result between the new version number information and the preset version information, the MCU sends the corresponding security control command to the target chip, thus forming a closed-loop control process: version verification failure, partition switching retry, second reporting, second comparison, and finally, allowing operation or downgrading. This closed-loop control process ensures that a single version verification failure does not directly lead to system unavailability, but rather attempts to recover through backup partition switching. Simultaneously, when recovery fails, a unified system-level downgrading strategy is executed, balancing fault tolerance and recovery capabilities with a safety fallback guarantee.

[0118] In one possible implementation, the method further includes: if no new version number information is received from the target chip after restarting within a preset time, a system-level downgrade strategy is executed.

[0119] The preset time is used to limit the time the MCU waits for the target chip to respond to the partition switching instruction, but this application does not impose specific restrictions on it.

[0120] It should be understood that if a new version number is not received after the preset time, it indicates that the target chip may be unable to complete the partition switch or the communication link is abnormal. Based on this, the MCU determines that the target chip has an unrecoverable fault and directly executes the system-level degradation strategy to avoid the system being unable to enter a safe state in time due to infinite waiting.

[0121] One implementation of the system-level degradation strategy further includes recording the failure event to internal non-volatile memory. This means that after entering system-level degradation mode, the MCU writes the relevant information of the failure event into its internal non-volatile memory. In one possible implementation, the failure event includes a failed chip identifier, a failure stage, an error code, and a version number. For example, when executing the system-level degradation strategy, the MCU writes the failed chip identifier (SOC), the failure stage (secondary version check failure), the error code (version number mismatch), and the version number reported by the SOC into the non-volatile memory for after-sales diagnostics and analysis.

[0122] For example, please refer to Figure 6 , Figure 6 This is a schematic diagram illustrating a degradation process for an intelligent driving domain controller, provided as an embodiment of this application. Figure 6As shown, after the system enters normal operation, if the SOC secondary verification fails, the SOC is disabled, and then system-level degradation begins. If the LSW secondary verification fails, the LSW communication capability is restricted, and then system-level degradation begins. The process ends after the system-level degradation completes fault information recording. Furthermore, if the MCU fails verification during its own safe startup process, the MCU performs a hardware lock, does not initiate any communication, and does not power on the SOC or LSW. The vehicle directly detects that the intelligent driving domain controller is unresponsive, and the process also ends after fault information recording.

[0123] In summary, for example, please refer to Figure 7 , Figure 7 This is a schematic diagram illustrating the interaction timing of a safe startup control method for an intelligent driving domain controller, provided in an embodiment of this application. Figure 7 As shown, after the MCU completes its own secure boot and sends the first frame status message, the control power management circuit simultaneously sends a power-on enable signal to both the SOC and LSW. After completing their respective internal security checks, the SOC and LSW report the first version number information and the second version number information to the MCU. The MCU performs an initial comparison of the first version number information (e.g., Ver_A) and the second version number information (e.g., Ver_B) with the preset version information. If the initial comparison fails, the MCU sends a partition switching command (version error) to the SOC or LSW with inconsistent version number information. The SOC or LSW switches to the backup partition and restarts. After completing the security check, it reports a new version number information to the MCU, where the new version number information reported by the SOC is (e.g., Ver_AA) and the new version number information reported by the LSW is (e.g., Ver_BB). The MCU performs a second comparison of the new version number information with the preset version information. If the second comparison matches, it sends an allow-to-run command to the SOC or LSW, completing the secure boot of the intelligent driving domain controller.

[0124] For example, please refer to Figure 8 , Figure 8 This is a schematic diagram of the overall process of a safe start control method for an intelligent driving domain controller provided in an embodiment of this application. Figure 8As shown, the process begins with MCU secure boot verification. If verification fails, the MCU enters a hardware lock state, and the process ends. If verification succeeds, the MCU starts normally and sends out CAN messages. Simultaneous SOC secure boot verification and LSW secure boot verification are performed. After both verifications succeed, the version number is reported to the MCU. The MCU compares the version numbers. If the comparison fails, the MCU sends a partition switching command to the chip that failed the comparison. This chip performs a second secure boot verification. If the second verification fails, a system-level degradation strategy is executed, and the process ends. If the second verification succeeds, the version number is reported to the MCU again. The MCU performs a second version comparison. If the second comparison fails, a system-level degradation strategy is executed, and the process ends. If the second comparison succeeds, the MCU sends an allow-to-run command. When the first comparison succeeds, the MCU directly sends an allow-to-run command. After the MCU sends the allow-to-run command, the intelligent driving domain controller starts normally, and the process ends.

[0125] Furthermore, the embodiments of this application mainly rely on firmware logic such as flag management, version number comparison, and partitioning instruction interaction in the MCU, as well as the existing partitioning hardware resources in the SOC and LSW, without adding additional hardware costs; the communication between the MCU and the SOC and LSW adopts mature low-speed buses such as SPI or IIC, which are easy to develop and integrate, and are convenient for rapid deployment and promotion on relevant intelligent driving domain controller platforms.

[0126] The intelligent driving domain controller safe start control method of the present application has been described above. The apparatus for executing the above method provided in the embodiments of the present application is described below. Those skilled in the art will understand that the method and apparatus can be combined with and referenced by each other. The related apparatus provided in the embodiments of the present application can execute the steps in the above intelligent driving domain controller safe start control method. The related apparatus can be referred to the following description: Figure 9 This is a schematic diagram of a safe start control device for an intelligent driving domain controller provided in an embodiment of this application. The safe start control device 900 for an intelligent driving domain controller may include: a power-on control module 901, a version receiving module 902, a version comparison module 903, and an instruction sending module 904.

[0127] The power-on control module 901 is used to control the power-on of the system-on-a-chip (SOC) and the switching chip (LSW) in the intelligent driving domain controller after the microcontroller unit (MCU) in the intelligent driving domain controller completes its own safe startup. The SOC is configured to load the intelligent driving application corresponding to the first version partition, and the LSW is configured to load the network communication protocol firmware corresponding to the second version partition. The version receiving module 902 is used to receive first version number information from the SOC and second version number information from the LSW. The first version number information represents the version number information corresponding to the first version partition, and the second version number information represents the version number information corresponding to the second version partition. The version comparison module 903 is used to compare the first and second version number information with preset version information, which is stored in the MCU. The instruction sending module 904 is used to send corresponding safety control instructions to the SOC and LSW respectively based on the comparison results.

[0128] In one possible implementation, the power-on control module 901 is specifically used for the MCU to complete its own secure startup, including: after the MCU cold-starts, performing signature verification on the application image in the MCU; the cold start is used to characterize the first startup and operation of the MCU after power-on; after the signature verification of the application image passes, setting a preset flag bit to a first state value and triggering the MCU reset; the first state value is used to indicate that the application image has passed the signature verification; the reset is used to restart the MCU and reload the application image; after the MCU resets, in response to the flag bit being the first state value, skipping the signature verification of the application image to complete the MCU's own secure startup; wherein, the duration of the handshake signal sent externally after the MCU resets and restarts is less than a preset timeout threshold, and the preset timeout threshold is less than the time when the handshake signal is sent externally after the MCU cold-starts.

[0129] In one possible implementation, the power-on control module 901 is specifically used to set a preset flag bit to a second state value after the signature verification of the application image fails, and to perform the signature verification of the application image in the MCU again; the second state value is that the application image has failed the signature verification.

[0130] In one possible implementation, the instruction sending module 904 is specifically used to send corresponding security control instructions to the SOC and LSW respectively based on the comparison result, including: sending an allow-to-run instruction to the SOC and LSW respectively when the first version number information is consistent with the preset version information and the second version number information is consistent with the preset version information.

[0131] In one possible implementation, the instruction sending module 904 is specifically used to send corresponding security control instructions to the SOC and LSW respectively based on the comparison result, including: when the target version number information is inconsistent with the preset version information, sending a partition switching instruction to the target chip corresponding to the target version number information; the target version number information is either a first version number information or a second version number information, and the target chip is an SOC or an LSW; the partition switching instruction is used to instruct the target chip to switch to the backup partition and restart; receiving the new version number information reported by the target chip after restarting, the new version number information is used to characterize the version of the first version partition or the second version partition running after the target chip switches; and sending the corresponding security control instruction to the target chip based on the secondary comparison result of the new version number information and the preset version information.

[0132] In one possible implementation, the instruction sending module 904 is specifically used to send corresponding security control instructions to the target chip based on the result of a secondary comparison between the new version number information and the preset version information. This includes: sending an allow-to-run instruction to the target chip when the new version number information matches the preset version information; and executing a system-level degradation strategy when the new version number information still does not match the preset version information. The system-level degradation strategy includes at least one of the following: sending a fault message to the vehicle controller; sending a disable function output instruction to the SOC; and disabling the LSW's data forwarding function.

[0133] In one possible implementation, the instruction sending module 904 is further configured to execute a system-level degradation strategy if it does not receive a new version number information reported by the target chip after restarting within a preset time.

[0134] This application also provides an electronic device, as described in the embodiments. Figure 10 The electronic device 1000 may include a memory 1010, a processor 1020, and a communication interface 1030. The memory 1010, processor 1020, and communication interface 1030 are connected via internal connection paths. The memory 1010 stores instructions, and the processor 1020 executes the instructions stored in the memory 1010 to control the communication interface 1030 to acquire information, thereby enabling the electronic device 1000 to implement the aforementioned intelligent driving domain controller safe start control method. Optionally, the memory 1010 may be coupled to the processor 1020 via an interface, or it may be integrated with the processor 1020.

[0135] It should be noted that the communication interface 1030 described above uses a transceiver device, such as, but not limited to, a transceiver. The communication interface 1030 may also include an input / output interface.

[0136] The processor 1020 stores one or more computer programs, which include instructions. When the instructions are executed by the processor 1020, the electronic device 1000 performs the methods described in the above embodiments.

[0137] In implementation, each step of the above method can be completed by the integrated logic circuitry of the hardware in the processor 1020 or by instructions in software form. The method disclosed in the embodiments of this application can be directly implemented by the hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 1010, and the processor 1020 reads the information in memory 1010 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0138] As one possible implementation, the electronic device 1000 can be a physical device. For example, the electronic device 1000 may include one or more of the following modules: central processing unit, microprocessor, application-specific integrated circuit, field-programmable gate array, complex programmable logic device (CPLD), coprocessor (assisting the central processing unit in completing corresponding processing and applications), microcontroller unit (MCU), domain controller (DC), vehicle domain controller unit (VDC), electronic control unit (ECU), cockpit domain controller (CDC), vehicle integrated unit (VIU), vehicle control unit (VCU), motor control unit (MCU), etc. Furthermore, the electronic device 1000 includes at least one processor integrated in the form of a system-on-chip (SoC), which is commonly referred to as a SoC by those skilled in the art. The SoC may include at least one processor, and when the SoC includes multiple processors, the types of the multiple processors may be different.

[0139] Optionally, Figure 10 The memory 1010 in the memory can store computer program instructions, preset version information, and flag bits, etc. Figure 10 The processor 1020 in the above embodiment can implement the steps in the intelligent driving domain controller safe start control method.

[0140] This application also provides a computer-readable storage medium storing program code that, when run on a computer, causes the computer to perform any of the methods described in the above embodiments.

[0141] This application also provides a computer program product, which includes a computer program that, when run, causes the computer to perform any of the methods described in the above embodiments.

[0142] This application also provides a chip, including: a circuit for performing any of the methods in the above embodiments.

[0143] This application also provides a device, including... Figure 9 The intelligent driving domain controller safety start control device 900 shown is... Figure 10 The electronic device 1000 shown can perform any of the methods described in the above embodiments.

[0144] This application also provides a vehicle, including... Figure 9 The intelligent driving domain controller safety start control device 900 shown is... Figure 10 The electronic device shown is 1000.

[0145] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0146] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0147] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0148] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0149] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0150] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0151] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0152] The terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the description of embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0153] It is understood that, in the embodiments of this application, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

Claims

1. A safe start control method for an intelligent driving domain controller, applied to the microcontroller unit (MCU) in the intelligent driving domain controller, characterized in that, include: After the MCU completes its own secure boot, it controls the system-on-a-chip (SOC) and switching chip (LSW) in the intelligent driving domain controller to power on; wherein, the SOC is configured to load the intelligent driving application corresponding to the first version partition; and the LSW is configured to load the network communication protocol firmware corresponding to the second version partition. Receive first version number information from the SOC and second version number information from the LSW, wherein the first version number information is used to characterize the version number information corresponding to the first version partition, and the second version information is used to characterize the version number information corresponding to the second version partition; The first version number information and the second version number information are compared with preset version information respectively; the preset version information is stored in the MCU; Based on the comparison results, corresponding security control commands are sent to the SOC and the LSW respectively.

2. The method according to claim 1, characterized in that, The MCU completes its secure boot process, including: After the MCU cold start, a signature verification of the application image in the MCU is performed; the cold start is used to characterize the first startup and operation of the MCU after power-on. After the application image passes signature verification, a preset flag is set to a first status value, and the MCU is triggered to reset; the first status value is used to indicate that the application image has passed signature verification; the reset is used to restart the MCU and reload the application image. After the MCU is reset, in response to the flag bit being the first state value, the signature verification of the application image is skipped to complete the secure boot of the MCU itself; Wherein, the duration for which the MCU sends a handshake signal after being reset is less than a preset timeout threshold, and the preset timeout threshold is less than the time when the MCU sends a handshake signal after a cold start.

3. The method according to claim 1, characterized in that, Also includes: After the signature verification of the application image fails, the preset flag is set to the second state value, and the signature verification of the application image in the MCU is performed again. The application image in the second status value failed signature verification.

4. The method according to claim 1, characterized in that, The step of sending corresponding security control commands to the SOC and the LSW respectively based on the comparison result includes: If the first version number information is consistent with the preset version information and the second version number information is consistent with the preset version information, a run permission instruction is sent to the SOC and the LSW respectively.

5. The method according to claim 1, characterized in that, The step of sending corresponding security control commands to the SOC and the LSW respectively based on the comparison result includes: When the target version number information is inconsistent with the preset version information, a partition switching command is sent to the target chip corresponding to the target version number information; the target version number information is either the first version number information or the second version number information, and the target chip is the SOC or the LSW; the partition switching command is used to instruct the target chip to switch to the backup partition and restart. Receive the new version number information reported by the target chip after restarting. The new version number information is used to characterize the version of the first version partition or the second version partition that the target chip is running after switching. Based on the result of a second comparison between the new version number information and the preset version information, a corresponding security control command is sent to the target chip.

6. The method according to claim 5, characterized in that, The step of sending a corresponding security control command to the target chip based on the secondary comparison result between the new version number information and the preset version information includes: When the new version number information matches the preset version information, a command to allow operation is sent to the target chip. When the new version number information is still inconsistent with the preset version information, a system-level downgrade strategy is executed; The system-level degradation strategy includes at least one of the following: sending a fault message to the vehicle controller; sending a command to disable function output to the SOC; and disabling the data forwarding function of the LSW.

7. The method according to claim 6, characterized in that, The method further includes: If no new version number information is received from the target chip after restarting within a preset time, the system-level degradation strategy is executed.

8. A smart driving domain controller, characterized in that, Includes a microcontroller unit (MCU); the MCU is configured to perform the safe startup control method as described in any one of claims 1 to 7.

9. A safe start control device for an intelligent driving domain controller, characterized in that, include: The power-on control module is used to control the system-on-a-chip (SOC) and the switching chip (LSW) in the intelligent driving domain controller to power on after the microcontroller unit (MCU) in the intelligent driving domain controller completes its own safe startup; wherein, the SOC is configured to load the intelligent driving application corresponding to the first version partition; and the LSW is configured to load the network communication protocol firmware corresponding to the second version partition. The version receiving module is used to receive first version number information from the SOC and second version number information from the LSW, wherein the first version number information is used to characterize the version number information corresponding to the first version partition, and the second version information is used to characterize the version number information corresponding to the second version partition. The version comparison module is used to compare the first version number information and the second version number information with preset version information respectively; the preset version information is stored in the MCU; The instruction sending module is used to send corresponding security control instructions to the SOC and the LSW respectively based on the comparison result.

10. A vehicle, characterized in that, Includes the intelligent driving domain controller as described in claim 8, or the intelligent driving domain controller safety start control device as described in claim 9.

Images