Method, device, equipment and medium for starting vehicle-mounted microcontroller unit

Through two-factor collaborative verification and multi-condition judgment, combined with the cache mechanism and backup HSM module, the problem of insufficient security during the on-board MCU startup process is solved, and a high-security startup control is achieved to ensure that the vehicle starts normally under the optimal conditions.

CN120354416APending Publication Date: 2025-07-22镁佳(北京)科技有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510446055.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-04-10
Publication Date
2025-07-22

AI Technical Summary

Technical Problem

The existing on-board microcontroller unit (MCU) is inadequate in security during startup and is vulnerable to overall system security crashes caused by man-in-the-middle attacks, illegal user-triggered startup and single verification conditions.

Method used

A two-factor collaborative verification mechanism is adopted to combine biometric verification by calculating message authentication code and cryptographic verification to generate multiple judgment conditions to ensure the MCU startup parameters, equipment and user legitimacy, and monitor the power supply voltage, environment and vehicle status. A cache mechanism and backup HSM module are introduced to improve system reliability.

Benefits of technology

Effectively defend against firmware tampering and illegal access, improve the credibility of startup parameters, reduce the risk of malicious attacks, ensure that the MCU starts under the best conditions, improve system security and reliability, and reduce the probability of startup failure.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120354416A_ABST
    Figure CN120354416A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of automobiles, and discloses a method, a device, equipment and a medium for starting a vehicle-mounted microcontroller unit, and the method comprises the steps: based on a vehicle-mounted microcontroller unit starting parameter, calculating a message authentication code, comparing the message authentication code with a preset safety threshold, based on a comparison result, generating a first judgment condition, and based on the representation of the first judgment condition, starting the vehicle-mounted microcontroller unit according to the first judgment condition. Whether starting parameters of the vehicle-mounted microcontroller unit are legal or not is judged; a second judgment condition is generated based on the vehicle safety verification state information, the vehicle safety verification state information comprises at least one of a cryptographic verification result and a biological recognition result, and whether the starting device and / or the starting user are / is legal or not is represented based on the second judgment condition; if the first judgment condition and the second judgment condition both meet the starting requirement, the vehicle-mounted microcontroller unit is started. Through a double-factor collaborative verification mechanism, the problems of tampering risk and permission out-of-control caused by single verification in the starting process of the vehicle-mounted MCU are solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of automobiles, and particularly to a method, device, equipment and medium for starting an in-vehicle microcontroller unit. Background Art

[0002] With the progress of technology and the rapid development of productivity, automobiles have been popularized in people's daily lives and have become one of the essential means of transportation for people's daily travel, greatly facilitating people's lives. Among them, the in-vehicle microcontroller unit (MCU) is one of the important components inside existing automobiles and is used to control various electronic components inside the vehicle. Specifically, during the startup process of existing vehicles, the in-vehicle MCU also needs to be safely started synchronously to ensure that the vehicle can drive normally.

[0003] In the MCU startup process in related technologies, the security is insufficient. Summary of the Invention

[0004] In view of this, the present invention provides a method, device, equipment and medium for starting an in-vehicle microcontroller unit to solve the problem of insufficient security in the MCU startup process in related technologies.

[0005] In a first aspect, the present invention provides a method for starting an in-vehicle microcontroller unit, the method including: calculating a message authentication code based on the startup parameters of the in-vehicle microcontroller unit, comparing the message authentication code with a preset security threshold, generating a first judgment condition based on the comparison result, and characterizing whether the startup parameters of the in-vehicle microcontroller unit are legal based on the first judgment condition; generating a second judgment condition based on the vehicle security verification status information, where the vehicle security verification status information includes at least one of the following, a cryptography verification result and a biometric result, and characterizing whether the startup device and / or the startup user are legal based on the second judgment condition; if both the first judgment condition and the second judgment condition meet the startup requirements, starting the in-vehicle microcontroller unit.

[0006] In an optional implementation, the method for starting an in-vehicle microcontroller unit further includes: obtaining power supply voltage information, if the power supply voltage information indicates that the power supply voltage is within a preset voltage threshold range, obtaining environmental status information, obtaining a third judgment condition based on the environmental status information, and characterizing whether the startup environment meets the preset requirements based on the third judgment condition; if the first judgment condition, the second judgment condition and the third judgment condition all meet the startup requirements, starting the in-vehicle microcontroller unit.

[0007] In an alternative embodiment, the method for starting an in-vehicle microcontroller unit further includes: generating a fourth judgment condition based on other vehicle state information, where the other vehicle state information includes at least one of the following, vehicle battery state information and vehicle network state information, and characterizing whether the states of other parts of the vehicle meet the preset state requirements based on the fourth judgment condition; if the first judgment condition, the second judgment condition, the third judgment condition, and the fourth judgment condition all meet the start requirements, start the in-vehicle microcontroller unit.

[0008] In an alternative embodiment, the method for starting an in-vehicle microcontroller unit further includes: obtaining the repeated operations during the starting process; determining cache data based on the repeated operations; before executing the target repeated operation among the repeated operations, determining whether there is cache data required for executing the target repeated operation in the cache, and if not, executing the target repeated operation and writing the cache data generated by the execution into the cache.

[0009] In an alternative embodiment, the determining cache data based on the repeated operations includes: configuring the life cycle of the cache data and the update policy of the cache data based on the repeated operations; obtaining the data stream and calculation frequency during the starting process, and optimizing the update policy based on the data stream and the calculation frequency.

[0010] In an alternative embodiment, the method for starting an in-vehicle microcontroller unit further includes: if there is a condition among the first judgment condition, the second judgment condition, the third judgment condition, and the fourth judgment condition that does not meet the start requirements, performing a system rollback.

[0011] In an alternative embodiment, the performing a system rollback includes: a secondary start, where the secondary start includes at least one of the following, restarting the in-vehicle microcontroller unit, and adjusting the start parameters of the in-vehicle microcontroller unit; if the number of times of performing the secondary start is greater than a preset start threshold, troubleshooting is performed.

[0012] In a second aspect, the present invention provides a device for starting an in-vehicle microcontroller unit. The device includes: a first determination module configured to calculate a message authentication code based on the starting parameters of the in-vehicle microcontroller unit, compare the message authentication code with a preset security threshold, generate a first determination condition based on the comparison result, and represent whether the starting parameters of the in-vehicle microcontroller unit are legal based on the first determination condition; a second determination module configured to generate a second determination condition based on vehicle safety verification status information, where the vehicle safety verification status information includes at least one of the following: a cryptography verification result and a biometric result, and represent whether the starting device and / or the starting user are legal based on the second determination condition; and a starting module configured to start the in-vehicle microcontroller unit if both the first determination condition and the second determination condition meet the starting requirements.

[0013] In a third aspect, the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the method for starting an in-vehicle microcontroller unit according to the first aspect or any corresponding embodiment thereof.

[0014] In a fourth aspect, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the method for starting an in-vehicle microcontroller unit according to the first aspect or any corresponding embodiment thereof.

[0015] In a fifth aspect, the present invention provides a computer program product including computer instructions for causing a computer to perform the method for starting an in-vehicle microcontroller unit according to the first aspect or any corresponding embodiment thereof.

[0016] During the generation of the first judgment condition, based on the MCU startup parameters, a Message Authentication Code (MAC for short) is generated. The MAC value is compared with a preset security threshold. Based on the comparison result, the first judgment condition is obtained. By verifying the startup parameters through the first judgment condition, attacks such as firmware tampering or configuration data injection can be effectively defended, ensuring the credibility of the startup parameters. During the generation of the second judgment condition, at least one of device-level cryptographic verification and user-level biometric recognition is combined to achieve multi-dimensional identity authentication at the device and / or user level, avoiding illegal physical access. When the first judgment condition indicates that the MCU startup parameters are legal and the second judgment condition indicates that the device and / or user is legal, the MCU can start, preventing single-point failure. At the same time, with dual-condition independent verification, an attacker needs to break through both the parameter integrity defense and the identity authentication system simultaneously, which can significantly increase the attack cost. In addition, through the dual-factor collaborative verification mechanism, the problems of tampering risk and permission out-of-control caused by single verification during the startup process of in-vehicle MCUs are solved. Technologically, by integrating cryptographic algorithms and multi-modal identity authentication, high-security-level startup control can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in related technologies, the following will briefly introduce the drawings required for use in the description of the specific embodiments or related technologies. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0018] Figure 1 FIG. shows a flowchart of a method for starting an in-vehicle microcontroller unit according to an embodiment of the present invention;

[0019] Figure 2 FIG. shows a structural diagram of a device for starting an in-vehicle microcontroller unit according to an embodiment of the present invention;

[0020] Figure 3 FIG. shows a structural diagram of another device for starting an in-vehicle microcontroller unit according to an embodiment of the present invention;

[0021] Figure 4 FIG. is a hardware structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0023] In the vehicle-mounted MCU startup method and system in the related art, by detecting the power-on state of the vehicle in real time, a startup signal is sent to the vehicle-mounted MCU. At the same time, the hardware security module (Hardware Security Module, abbreviated as HSM) module inside the vehicle is synchronously enabled. Based on this, in order to reduce the startup steps of the vehicle-mounted MCU, it is only necessary to obtain the initial startup parameters of the current vehicle-mounted MCU in real time and further calculate the corresponding MAC value. On this basis, by making corresponding judgments, the vehicle-mounted MCU inside the current vehicle can be simply and quickly enabled, correspondingly shortening the startup time significantly and improving the user experience at the same time.

[0024] In the related art, only by determining whether the MAC value is less than a preset threshold to decide whether to start the MCU, this single-condition judgment may not be comprehensive enough and may ignore other key factors affecting startup. Moreover, the MAC value needs to be calculated in real time for each startup process, which may increase the startup time, especially if the calculation is complex or the performance of the HSM module is limited. At the same time, if the calculation method or threshold setting of the MAC value is improper, there may be a risk of being maliciously attacked, especially in an environment where the vehicle safety requirements are extremely high. In addition, if the startup fails and there is no clear fallback or retry mechanism, it may cause the vehicle to fail to start normally and depends on the performance of the HSM. If the HSM module fails, the entire startup process will not be able to proceed.

[0025] There are problems with insufficient security in the MCU startup process in the related art. First, the startup process in the related art relies on firmware verification and is vulnerable to man-in-the-middle attacks or malicious injection. Second, only verifying the program legality may cause illegal users to trigger the MCU startup. Third, relying on a single verification condition, if this condition is bypassed, it will cause the overall security of the system to collapse.

[0026] According to the embodiments of the present invention, a method embodiment for starting a vehicle-mounted microcontroller unit is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in a different order.

[0027] In this embodiment, a method for starting a vehicle microcontroller unit is provided, which can be used for vehicles. Figure 1 The flowchart of the method for starting a vehicle microcontroller unit according to the embodiment of the present invention is shown, as Figure 1 shown, and the process includes the following steps:

[0028] Step S101: Calculate a message authentication code based on the vehicle microcontroller unit startup parameters, compare the message authentication code with a preset security threshold, generate a first judgment condition based on the comparison result, and based on the representation of the first judgment condition, determine whether the vehicle microcontroller unit startup parameters are legal.

[0029] In this step, the MCU startup parameters include a preset security threshold and system status information. The message authentication code (Message Authentication Code, abbreviated as MAC) is a cryptographic tool used to verify message integrity and identity authenticity. After the MCU is powered on, it can load the system status information corresponding to the preset startup parameters from the memory, calculate the MAC value through the Hardware Security Module (abbreviated as HSM), and compare the MAC value with the preset security threshold. If the generated first judgment condition is that the MAC value is less than the preset security threshold, then the first judgment condition indicates that the MCU startup parameters are legal; if the generated first judgment condition is that the MAC value is greater than or equal to the preset security threshold, then the first judgment condition indicates that the MCU startup parameters are illegal.

[0030] Step S102: Generate a second judgment condition based on the vehicle safety verification status information. The vehicle safety verification status information includes at least one of the following: cryptographic verification result and biometric result. Based on the representation of the second judgment condition, determine whether the starting device and / or the starting user are legal.

[0031] In this step, the cryptographic verification result can be to verify the legality of the starting device through a digital certificate or token. The biometric result can be fingerprint recognition or facial recognition. Performing biometric verification can ensure that the starting user is an authorized user.

[0032] Based on the vehicle safety verification status information, generate a second judgment condition: It can be to generate a second judgment condition based on the cryptographic verification result. If the generated second judgment condition is that the cryptographic verification is passed, then the second judgment condition indicates that the starting device is legal.

[0033] It can also be to generate a second judgment condition based on the biometric result. If the generated second judgment condition is that the biometric verification is passed, then the second judgment condition indicates that the starting user is legal.

[0034] It can also be to generate a second judgment condition based on the cryptographic verification result and the biometric result at the same time. If the generated second judgment condition is that the cryptographic verification and the biometric verification are passed, the second judgment condition indicates that both the starting device and the starting user are legal.

[0035] Step S103, if both the first judgment condition and the second judgment condition meet the startup requirements, start the in-vehicle microcontroller unit.

[0036] In this step, the startup requirements include that the first judgment condition indicates that the in-vehicle MCU startup parameters are legal, and the second judgment condition indicates that the starting device and / or the starting user are legal. After starting the MCU, the running state of the MCU can be monitored in real time to ensure the successful startup of the MCU.

[0037] In the method for starting an in-vehicle microcontroller unit provided in this embodiment, during the generation of the first judgment condition, based on the MCU startup parameters, a Message Authentication Code (MAC) is generated, and the MAC value is compared with a preset security threshold. Based on the comparison result, the first judgment condition is obtained. By verifying the startup parameters through the first judgment condition, attacks such as firmware tampering or configuration data injection can be effectively defended, ensuring the credibility of the startup parameters; during the generation of the second judgment condition, at least one of device-level cryptographic verification and user-level biometric recognition is combined, and multi-dimensional identity authentication at the device and / or user level can be realized to avoid illegal physical access; when the first judgment condition indicates that the MCU startup parameters are legal and the second judgment condition indicates that the device and / or user are legal, the MCU starts, which can prevent single-point failure; at the same time, with dual-condition independent verification, the attacker needs to break through both the parameter integrity defense and the identity authentication system simultaneously, which can significantly increase the attack cost; in addition, through the two-factor collaborative verification mechanism, the problems of tampering risk and permission out-of-control caused by single verification during the startup process of the in-vehicle MCU are solved. In terms of technical implementation, cryptographic algorithms and multi-modal identity authentication are integrated to achieve high-security-level startup control.

[0038] In some alternative embodiments, the foregoing method for starting an in-vehicle MCU further includes: obtaining power supply voltage information. If the power supply voltage information indicates that the power supply voltage is within a preset voltage threshold range, obtaining environmental status information, and based on the environmental status information, obtaining a third judgment condition, and based on the third judgment condition, indicating whether the startup environment meets the preset requirements; if the first judgment condition, the second judgment condition, and the third judgment condition all meet the startup requirements, start the in-vehicle microcontroller unit.

[0039] In this embodiment, the preset voltage threshold can be set to 9V to 16V. By monitoring the power supply voltage information, the stability and sufficiency of the power supply can be checked to ensure that the power supply voltage is within a safe range and avoid hardware failures caused by overvoltage or undervoltage. The environmental state information includes at least one of the environmental temperature and the environmental humidity. After obtaining the environmental parameters characterized by the environmental state information, it is possible to prevent extreme conditions from affecting the stability of the system by judging whether the current environment is within the allowable range based on the environmental parameters.

[0040] If the third judgment condition indicates that both the power supply voltage and the environmental parameters are compliant, the environment meets the preset requirements is started. In this embodiment, the start requirements include that the first judgment condition indicates that the in-vehicle MCU start parameters are legal, the second judgment condition indicates that the starting device and / or the starting user are legal, and the third judgment condition indicates that the starting environment meets the preset requirements, then the MCU can be started.

[0041] In this way, by monitoring the power supply voltage and the environmental state, the third judgment condition is generated, which can prevent hardware damage caused by the start of the MCU under extreme conditions and effectively improve the robustness of the system. At the same time, it ensures that the MCU is started in a suitable environment and avoids start failures caused by environmental problems.

[0042] In some optional embodiments, the foregoing method for starting an in-vehicle MCU further includes: generating a fourth judgment condition based on other vehicle state information, where the other vehicle state information includes at least one of the following, vehicle battery state information and vehicle network state information, and based on the fourth judgment condition indicating whether the states of other parts of the vehicle meet the preset state requirements; if the first judgment condition, the second judgment condition, the third judgment condition, and the fourth judgment condition all meet the start requirements, start the in-vehicle microcontroller unit.

[0043] In this embodiment, the vehicle battery state information may include at least one of the following, state of charge (SOC), battery health state, and battery temperature state. Among them, the remaining power can be used to detect whether the current battery meets the start threshold, which can avoid abnormal shutdown caused by insufficient power. The electrochemical model can be used to evaluate the battery capacity attenuation rate, which can prevent safety hazards caused by battery aging. The battery temperature can be monitored in real time to determine whether it is within a safe range, which can avoid battery thermal runaway.

[0044] The fourth judgment condition can be generated based on the vehicle battery state information. If the generated fourth judgment condition indicates that the remaining battery power, the battery health state, and the battery temperature state are all compliant, then the vehicle battery state meets the preset state requirements, and the states of other parts of the vehicle meet the preset state requirements.

[0045] The vehicle network status information may include network load information. The bus load rate can be detected to avoid communication delay or loss caused by network congestion. If the network load information indicates that the network load is lower than the preset network load threshold, the network load is legal.

[0046] Based on the vehicle network status, a fourth judgment condition can also be generated. If the generated fourth judgment condition indicates that the vehicle network load is legal, then the vehicle network status meets the preset status requirements, and the status of other parts of the vehicle meets the preset status requirements.

[0047] Based on the vehicle battery status information and the vehicle network status information simultaneously, a fourth judgment condition can also be generated. If the generated fourth judgment condition indicates that both the vehicle battery status and the vehicle network status meet the preset status requirements, then the status of other parts of the vehicle meets the preset status requirements.

[0048] In this embodiment, the startup requirements include that the first judgment condition indicates that the in-vehicle MCU startup parameters are legal, the second judgment condition indicates that the startup device and / or the startup user are legal, the third judgment condition indicates that the startup environment meets the preset requirements, and the fourth judgment condition indicates that the status of other parts of the vehicle meets the preset status requirements, and then the MCU can be started.

[0049] In this way, the risk prevention and control ability of the system can be further improved. By monitoring the vehicle battery status, it is possible to prevent system downtime or fire risks caused by insufficient battery power or thermal runaway, and ensure the reliability of the vehicle's basic power supply; by monitoring the SOH, the battery life can be extended, and sudden failures caused by battery aging can be reduced; communication failures of in-vehicle systems caused by bus overload can be avoided, and the stability of real-time control functions can be ensured. Through multiple judgment conditions, it is possible to ensure that the MCU is started under the best conditions and reduce the probability of startup failure.

[0050] By introducing the fourth judgment condition, that is, at least one of the vehicle battery and network status, the startup verification of the in-vehicle microcontroller is upgraded from a single function verification to a full-dimensional security system covering hardware, logic, network, and energy. It not only prevents risks such as traditional firmware tampering and illegal operations, but also further solves the unique battery safety and network attack hazards of new energy vehicles, providing a highly reliable, adaptive, and compliant security startup solution for intelligent connected vehicles.

[0051] In addition, full-dimensional security coverage can be achieved. At the physical layer, through hardware-level monitoring such as power supply voltage, battery status, and environmental parameters, hardware damage can be prevented. At the logical layer, through multi-factor authentication such as system status legality and user identity, illegal operations can be blocked. At the system layer, through the integrated analysis of network health and battery status, vehicle-level security protection can be achieved.

[0052] In some alternative embodiments, the foregoing method for starting an in-vehicle microcontroller unit further includes: obtaining repeated operations during the startup process; determining cached data based on the repeated operations; before performing a target repeated operation among the repeated operations, determining whether there is cached data required for performing the target repeated operation in the cache, and if not, performing the target repeated operation and writing the cached data generated by the execution into the cache.

[0053] In this embodiment, the operations during the startup process include calculating the MAC value, obtaining environmental status information, loading MCU startup parameters, etc. When determining the repeated operations, it is determined which data needs to be cached, such as environmental status information, MCU startup parameters, or vehicle safety verification status information, etc. Before performing the repeated operations, first check whether there is already cached data required for the repeated operations in the cache. If there is already cached data required for the repeated operations in the cache, directly use the cached data, which can avoid repeated calculations. If there is no cached data required for the repeated operations in the cache, or the cached data required for the repeated operations has expired, the repeated operations can be performed and the execution results of the repeated operations can be written into the cache.

[0054] In this way, by introducing a caching mechanism, repeated calculations can be reduced, the calculation time during the startup process can be reduced, and the startup time of the MCU can be significantly shortened.

[0055] In the related art, the MAC value needs to be calculated in real time for each startup process, which may increase the startup time, especially when the calculation is complex or the performance of the HSM module is limited.

[0056] In some alternative embodiments, determining cached data based on the repeated operations includes: configuring the lifecycle of the cached data and the update policy of the cached data based on the repeated operations; obtaining the data stream and calculation frequency during the startup process, and optimizing the update policy based on the data stream and calculation frequency.

[0057] In this embodiment, operation frequency detection can be performed to mark the data associated with high-frequency operations. The lifecycle of the cached data can be configured to be valid during the MCU startup process, or the cache can be cleared after the MCU starts. The update policy of the cached data can be to update the cache when the environmental conditions change, or to update the cache regularly during the MCU startup process.

[0058] A cache memory, such as SRAM or a cache chip, can be used to ensure that its speed can meet the requirements of the startup process, and the capacity and access method of the cache memory can be configured to ensure that sufficient results of repeated calculations can be stored.

[0059] When the MCU is started, high-frequency data can be pre-loaded into the cache based on the analysis results of historical data streams to reduce the first access latency. The data stream is bucketed by time window, and the access frequency and computing load of each cache item are counted. If the access frequency of a cache item exceeds the threshold in three consecutive time windows, its update policy is switched from passive update to active pre-update. For example, on-demand refresh is switched to timed refresh.

[0060] When the computing node load is too high, the update frequency of low-frequency cache items is reduced. Multiple update requests for the same data source are merged into a single batch operation to reduce I / O overhead.

[0061] In this way, by identifying high-frequency operations, the cache hit rate of hot data can be improved. At the same time, the adaptive update policy can reduce the system resource occupancy rate and also reduce the MCU startup time.

[0062] In the related art, in the case of MCU startup failure, there is no clear fallback or retry mechanism, which may cause the vehicle to fail to start normally.

[0063] In some alternative embodiments, the method for starting an in-vehicle microcontroller unit described above further includes, if there is a condition that does not meet the startup requirements among the first judgment condition, the second judgment condition, the third judgment condition, and the fourth judgment condition, performing a system fallback.

[0064] In this embodiment, during the MCU startup process, the status of the four judgment conditions is monitored in parallel. Each condition runs an independent verification logic. In the case of a condition that does not meet the startup requirements, a system fallback is performed to terminate the current MCU startup process.

[0065] Performing a system fallback in the case of a condition that does not meet the startup requirements can effectively prevent risks such as hardware damage or data tampering and improve system reliability.

[0066] In some alternative embodiments, performing a system fallback includes: a second startup, which includes at least one of the following, restarting the in-vehicle microcontroller unit, and adjusting the startup parameters of the in-vehicle microcontroller unit; if the number of times of performing the second startup is greater than a preset startup threshold, troubleshooting is performed.

[0067] In this embodiment, to restart the MCU, a hard reset or a soft reset can be executed. A hard reset can be to cut off the power supply of the MCU through a power management chip and power it on again to completely clear the residual state in the memory. A soft reset can be to only reset the kernel and key peripherals and retain non-volatile configuration parameters. To adjust the MCU startup parameters, the startup condition threshold can be adjusted according to the environmental data.

[0068] A preset startup threshold can be recorded by a non-volatile counter to accumulate the number of startup failures. If the threshold is exceeded, it is determined as a persistent fault and the restart process is terminated. Troubleshooting can include fault classification and response, and can also notify the vehicle owner for manual intervention.

[0069] In this way, if the startup conditions are not met, the system will automatically attempt to restart or adjust parameters, improving the startup success rate, enhancing system reliability, and fault location can improve the repair efficiency.

[0070] In this embodiment, a device for starting an in-vehicle microcontroller unit is also provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0071] Figure 2 The structural schematic diagram of the device for starting an in-vehicle microcontroller unit according to an embodiment of the present invention is shown. This embodiment provides a device for starting an in-vehicle microcontroller unit, as Figure 2 shown, including:

[0072] A first judgment module 201, configured to calculate a message authentication code based on the startup parameters of the in-vehicle microcontroller unit, compare the message authentication code with a preset security threshold, generate a first judgment condition based on the comparison result, and represent whether the startup parameters of the in-vehicle microcontroller unit are legal based on the first judgment condition.

[0073] A second judgment module 202, configured to generate a second judgment condition based on the vehicle safety verification status information, where the vehicle safety verification status information includes at least one of the following, the cryptographic verification result and the biometric result, and represent whether the startup device and / or the startup user are legal based on the second judgment condition.

[0074] A startup module 203, configured to start the in-vehicle microcontroller unit if both the first judgment condition and the second judgment condition meet the startup requirements.

[0075] Among them, the HSM module can be started while obtaining the MCU startup parameters, and the MAC value can be calculated through the HSM module. At the same time, a standby HSM module is started to prevent HSM failures. The use of the standby HSM module improves the fault tolerance of the system in case of hardware failures.

[0076] In some alternative implementation manners, the aforementioned device for starting an in-vehicle microcontroller unit further includes:

[0077] A third judgment module is used to obtain power supply voltage information. If the power supply voltage information indicates that the power supply voltage is within a preset voltage threshold range, it obtains environmental status information, and based on the environmental status information, obtains a third judgment condition. Based on the representation of the third judgment condition, it determines whether the environment meets the preset requirements; if the first judgment condition, the second judgment condition, and the third judgment condition all meet the startup requirements, it starts the in-vehicle microcontroller unit.

[0078] In some alternative embodiments, the aforementioned device for starting the in-vehicle microcontroller unit further includes:

[0079] A fourth judgment module is used to generate a fourth judgment condition based on other vehicle status information. The other vehicle status information includes at least one of the following: vehicle battery status information and vehicle network status information. Based on the representation of the fourth judgment condition, it determines whether the status of other parts of the vehicle meets the preset status requirements; if the first judgment condition, the second judgment condition, the third judgment condition, and the fourth judgment condition all meet the startup requirements, it starts the in-vehicle microcontroller unit.

[0080] In some alternative embodiments, the aforementioned device for starting the in-vehicle microcontroller unit further includes:

[0081] A cache module is used to obtain repeated operations during startup; based on the repeated operations, it determines cache data; before executing the target repeated operation among the repeated operations, it judges whether there is cache data required for executing the target repeated operation in the cache. If not, it executes the target repeated operation and writes the generated cache data into the cache.

[0082] In some alternative embodiments, the cache module includes:

[0083] A cache unit is used to determine cache data based on repeated operations, including: configuring the lifecycle of the cache data and the update strategy of the cache data based on the repeated operations; obtaining the data stream and calculation frequency during startup, and optimizing the update strategy based on the data stream and calculation frequency.

[0084] In some alternative embodiments, the aforementioned device for starting the in-vehicle microcontroller unit further includes:

[0085] A fallback module is used to perform system fallback if there is a condition among the first judgment condition, the second judgment condition, the third judgment condition, and the fourth judgment condition that does not meet the startup requirements.

[0086] In some alternative embodiments, the fallback module includes:

[0087] A fallback unit for system fallback, including: secondary startup, which includes at least one of the following, restarting the in-vehicle microcontroller unit and adjusting the startup parameters of the in-vehicle microcontroller unit; the number of times of secondary startup is greater than a preset startup threshold for troubleshooting.

[0088] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding embodiments above, and will not be elaborated here.

[0089] Figure 3 The structural schematic diagram of another device for starting an in-vehicle microcontroller unit according to an embodiment of the present invention is shown, as Figure 3 shown, the device for starting the in-vehicle microcontroller unit includes: a power management module 301, an environment detection module 302, a security verification module 303, a startup parameter management module 304, a system status monitoring module 305, a startup decision module 306, a cache and optimization module 307, an exception handling module 308, and a redundancy and backup module 309.

[0090] Specifically, the power management module 301 is used to detect the power voltage status of the vehicle to ensure stable and sufficient voltage for safely starting the MCU, and the environment detection module 302 is used to monitor parameters such as temperature and humidity of the startup environment to ensure that the MCU starts in a suitable environment.

[0091] Further, the power management module 301 includes a power monitoring chip and a battery status detector, and the environment detection module 302 includes a temperature sensor, a humidity sensor, and an environment detection chip.

[0092] Specifically, the security verification module 303 is used to calculate the MAC value, perform cryptographic verification, and execute biometric identification, and the startup parameter management module 304 is used to load and manage the MCU startup parameters.

[0093] Further, the security verification module 303 includes an HSM module, a biometric sensor, and a cryptographic accelerator, and the startup parameter management module 304 is a non-volatile memory.

[0094] Specifically, the system status monitoring module 305 is used to monitor the status of other key systems of the vehicle to ensure that the startup conditions are met, and the startup decision module 306 is used to decide whether to start the MCU according to the verification results of all conditions, and the cache and optimization module 307 is used to provide a cache mechanism to reduce repeated calculations and optimize the startup process.

[0095] Further, the system status monitoring module 305 includes a network interface and a status monitoring chip, and the cache and optimization module 307 is a cache memory.

[0096] Specifically, the exception handling module 308 is used to handle exceptions during the startup process, provide troubleshooting guidance or restart strategies. The redundancy and backup module 309 is used to provide a backup of the HSM module to ensure that security verification can still be performed in case of a failure of the primary HSM.

[0097] Furthermore, the power management module 301 provides power voltage status information to the environment detection module 302 and shares the power status with the startup decision module 304 through a bus (such as a CAN bus). The environment detection module 302 sends the environment detection results to the startup decision module 306 and shares information with the system status monitoring module 305 through a network interface. The HSM module communicates with the startup parameter management module 304 to obtain startup parameters and sends the verification results (such as MAC values) to the startup decision module 306.

[0098] Furthermore, the startup decision module 306 collects information from the power management module 301, the environment detection module 302, the security verification module 303, the startup parameter management module 304, and the system status monitoring module 305, makes a comprehensive judgment, sends a startup instruction to the MCU through an internal bus or a direct connection, and shares the startup decision result with the exception handling module 308.

[0099] Furthermore, the exception handling module 308 receives the startup decision result of the startup decision module 306 through an internal bus or a direct connection. When the primary HSM module fails, the redundancy and backup module 309 communicates with the security verification module through the standby HSM module to ensure the continuity of the security verification process.

[0100] The method, device, equipment, and medium for starting an in-vehicle microcontroller unit according to the embodiments of the present invention reduce the real-time calculation time during the startup process through a pre-computation and caching mechanism, significantly shortening the startup time of the MCU. By introducing multiple security verification mechanisms, such as biometric recognition and cryptographic verification, the security of the system is greatly improved, and the risk of being maliciously attacked is reduced. The use of the standby HSM module improves the fault tolerance of the system in case of hardware failures. By adding multiple conditional judgments, it is ensured that the MCU starts under the best conditions, reducing the probability of startup failure. If the startup conditions are not met, the system will automatically attempt to restart or adjust parameters, increasing the startup success rate and ensuring that the MCU starts in a suitable environment, avoiding startup failures caused by environmental problems. Through the standby HSM module and other startup schemes that do not completely rely on the HSM, the overall reliability of the system is improved, solving the problem that the technology in the comparative document only determines whether to start the MCU by whether the MAC value is less than a preset threshold, and this single conditional judgment may not be comprehensive enough and may ignore other key factors affecting startup.

[0101] The device for starting an in-vehicle microcontroller unit in this embodiment is presented in the form of a functional unit. Here, the unit refers to an Application Specific Integrated Circuit (ASIC) circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0102] An embodiment of the present invention further provides a computer device having the above Figure 2 shown device for starting an in-vehicle microcontroller unit.

[0103] Please refer to Figure 4 , Figure 4 which is a schematic structural diagram of a computer device provided by an alternative embodiment of the present invention. As Figure 4 shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of a graphical user interface on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system). Figure 4 In

[0104] this example, one processor 10 is taken as an example.

[0105] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0106] The memory 20 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 may optionally include a memory remotely provided with respect to the processor 10, and these remote memories may be connected to the computer device through a network. Examples of the above-mentioned network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0107] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, a hard disk, or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0108] The computer device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30, and the output device 40 may be connected through a bus or other means. Figure 4 Taking connection through a bus as an example.

[0109] The input device 30 can receive input digital or character information and generate key signal inputs related to the user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (such as a light-emitting diode), and a tactile feedback device (such as a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light-emitting diode, a display, and a plasma display. In some alternative embodiments, the display device may be a touch screen.

[0110] Embodiments of the present invention also provide a computer-readable storage medium. The methods according to the embodiments of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented as computer code that is originally stored in a remote storage medium or a non-transitory machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the methods described herein can be stored as such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the methods shown in the above embodiments are implemented.

[0111] A part of the present invention can be applied as a computer program product, for example, computer program instructions. When executed by a computer, through the operation of the computer, the methods and / or technical solutions according to the present invention can be invoked or provided. Those skilled in the art should be able to understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Herein, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to the computer.

[0112] Although the embodiments of the present invention are described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for starting a vehicle-mounted microcontroller unit, characterized in that, The method includes: Calculating a message authentication code based on the in-vehicle microcontroller unit startup parameters, comparing the message authentication code with a preset security threshold, generating a first judgment condition based on the comparison result, and determining whether the in-vehicle microcontroller unit startup parameters are legal based on the representation of the first judgment condition; Generating a second judgment condition based on the vehicle safety verification status information, where the vehicle safety verification status information includes at least one of the following, a cryptographic verification result and a biometric result, and determining whether the startup device and / or the startup user are legal based on the representation of the second judgment condition; If both the first judgment condition and the second judgment condition meet the startup requirements, start the in-vehicle microcontroller unit.

2. The method according to claim 1, wherein The method further includes: Obtaining power supply voltage information, if the power supply voltage information indicates that the power supply voltage is within a preset voltage threshold range, obtaining environmental status information, obtaining a third judgment condition based on the environmental status information, and determining whether the startup environment meets the preset requirements based on the representation of the third judgment condition; If the first judgment condition, the second judgment condition, and the third judgment condition all meet the startup requirements, start the in-vehicle microcontroller unit.

3. The method according to claim 2, characterized in that, The method further includes: Generating a fourth judgment condition based on other vehicle status information, where the other vehicle status information includes at least one of the following, vehicle battery status information and vehicle network status information, and determining whether the status of other parts of the vehicle meets the preset status requirements based on the representation of the fourth judgment condition; If the first judgment condition, the second judgment condition, the third judgment condition, and the fourth judgment condition all meet the startup requirements, start the in-vehicle microcontroller unit.

4. The method according to claim 3, characterized in that, The method further includes: Obtaining the repeated operations during the startup process; Determining cached data based on the repeated operations; Before executing the target repeated operation in the repeated operations, determining whether there is cached data required for executing the target repeated operation in the cache, if not, executing the target repeated operation and writing the cached data generated by the execution into the cache.

5. The method according to claim 4, wherein The determining the cached data based on the repeated operations includes: Configuring the lifecycle and the update strategy of the cached data based on the repeated operations; Obtaining the data stream and the calculation frequency during the startup process, and optimizing the update strategy based on the data stream and the calculation frequency.

6. The method according to claim 3, characterized in that, The method further includes that if there is a condition among the first judgment condition, the second judgment condition, the third judgment condition, and the fourth judgment condition that does not meet the startup requirements, perform system rollback.

7. The method according to claim 6, characterized in that The performing system rollback includes: Performing a secondary startup, where the secondary startup includes at least one of the following, restarting the in-vehicle microcontroller unit, and adjusting the in-vehicle microcontroller unit startup parameters; If the number of times of performing the secondary startup is greater than a preset startup threshold, perform troubleshooting.

8. A device for starting an in-vehicle microcontroller unit, characterized in that, The device includes: The first judgment module is used to calculate a message authentication code based on the in-vehicle microcontroller unit startup parameters, compare the message authentication code with a preset security threshold, generate a first judgment condition based on the comparison result, and characterize whether the in-vehicle microcontroller unit startup parameters are legal based on the first judgment condition; The second judgment module is used to generate a second judgment condition based on the vehicle security verification status information, where the vehicle security verification status information includes at least one of the following: cryptographic verification result and biometric result, and characterize whether the startup device and / or the startup user are legal based on the second judgment condition; The startup module is used to start the in-vehicle microcontroller unit if both the first judgment condition and the second judgment condition meet the startup requirements.

9. A computer device, characterized in that, Comprising: A memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to execute the method for starting an in-vehicle microcontroller unit according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the method for starting an in-vehicle microcontroller unit according to any one of claims 1 to 7.