A pre-start control method, device, equipment and medium for vehicle parking

Abstract

This application relates to the field of intelligent parking, specifically to a pre-start control method, device, equipment, and medium for vehicle parking. This application remotely triggers the pre-start of the parking system, changing the XPU initialization process from a user-initiated command at the vehicle's side to execution after remote authentication. Users no longer need to wait for time-consuming steps such as hardware self-checks and software loading at the vehicle's side, completely solving the pain point of long startup waiting times. Simultaneously, Bluetooth authentication, XPU pre-start, and parking exit command issuance are separated into two independent stages, breaking the original linearly coupled execution chain and preventing the entire parking exit process from being interrupted due to XPU startup failure. Furthermore, after XPU pre-start is completed, it is in a ready state and can respond to parking exit commands, significantly improving process fault tolerance and stability, and significantly optimizing the user experience.

Description

Technical Field

[0001] This invention relates to the field of intelligent parking, specifically to a pre-start control method, device, equipment, and medium for vehicle parking. Background Technology

[0002] With the rapid development of automotive intelligent technology, automatic parking systems have become one of the core functions for enhancing the driving experience. Among them, Bluetooth-based parking systems are widely used in the civilian vehicle sector due to their advantages such as low deployment cost and convenient operation. The typical workflow of an existing Bluetooth-based parking system is as follows: After the user approaches the vehicle, they issue a parking command through a terminal device. Upon receiving the command, the system triggers the startup process of the parking control unit (eXclusive Parking Unit, XPU), which sequentially completes initialization operations such as hardware self-test, software loading, and sensor calibration. After the XPU enters the ready state, it executes the subsequent parking action based on the Bluetooth authentication result.

[0003] However, this technical solution has obvious efficiency bottlenecks and user experience shortcomings in practical applications, specifically in two aspects:

[0004] Firstly, the startup waiting time is too long, resulting in high waiting costs for users. The existing system only starts the XPU initialization process after the user issues a parking command. It usually takes about 20 seconds from the issuance of the command to the completion of XPU initialization. Users have to wait continuously next to the car. In emergency scenarios such as commuting in a hurry or in bad weather, the excessively long waiting time will seriously reduce the user experience.

[0005] Secondly, the command execution link is single and the process is highly coupled. The three core links of "Bluetooth authentication - docking command issuance - XPU startup" are linearly connected. The next link can only be entered after the previous link is completely completed. If a brief fault such as sensor initialization delay occurs during the XPU startup process, it will directly cause the entire docking process to be interrupted. Moreover, the system cannot detect startup risks in advance, and its fault tolerance and stability are poor. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a pre-start control method, device, equipment and medium for vehicle parking, in order to solve the problems of existing Bluetooth-based parking systems, which suffer from long start-up waiting time, poor user experience and insufficient process fault tolerance and stability due to the delayed start-up triggering timing of XPU and linear coupling of core execution links.

[0007] In a first aspect, embodiments of the present invention provide a pre-start control method for vehicle parking, the method comprising: Listen to remote connection requests sent by the control terminal, wherein the remote connection request includes user identity information; In response to the remote connection request, authenticate the user's identity information; If the user identity information is authenticated, the parking system of the vehicle is pre-started and enters a ready state, wherein the ready state is used to indicate that the parking system can respond to the parking command of the control terminal in real time. Upon receiving a parking command from the control terminal, the system controls the vehicle's parking system to execute the corresponding parking maneuver.

[0008] Furthermore, the pre-start and ready state of the vehicle parking system includes: Control the pre-start of the parking system and detect whether the functions of the vehicle components associated with the parking system are all in an effective state; If all the functions of the vehicle components are in an effective state, the coordinates of the vehicle components are calibrated, and the software operating environment supporting parking decisions is loaded. Once the coordinate calibration of the vehicle components is completed and the software operating environment is loaded, the parking system controlling the vehicle enters a ready state.

[0009] Furthermore, the method also includes: If at least one of the vehicle components is in an invalid state, the invalid vehicle component is marked as a faulty vehicle component, and the current fault status of the faulty vehicle component is detected. Obtain redundancy compensation data for the corresponding functions of other vehicle components; Analyze whether the redundancy compensation data for the aforementioned functions can cover the functions of the faulty vehicle components. If the redundancy compensation of the function can cover the function of the faulty vehicle component, then the step of calibrating the coordinates of the vehicle component is performed; or, if the redundancy compensation of the function cannot cover the fault of the faulty vehicle component, then the pre-start of the parking system is terminated, and detailed information of the faulty vehicle component is pushed to the control terminal.

[0010] Furthermore, the analysis of whether the redundancy compensation data for the function can cover the function of the faulty vehicle component includes: Obtain the parameter failure range of the corresponding function of the faulty vehicle component; Extract availability performance data of other vehicle components corresponding to their functions, and determine redundancy compensation data of other vehicle components in the scenario of taking over the function of the faulty component based on the availability performance data. By comparing the failure range of the parameters with the redundancy compensation data, it is determined whether the other vehicle components can fully assume the function of the faulty vehicle components.

[0011] Furthermore, after controlling the vehicle's parking system to perform the corresponding parking maneuver, the method further includes: Collect real-time parking status of the vehicles; Send the real-time parking status to the control terminal; Analyze the real-time parking situation to determine whether the vehicle has reached the corresponding parking position; If the vehicle reaches the corresponding parking position, a parking completion signal is sent to the control terminal.

[0012] Furthermore, after the vehicle reaches the corresponding parking position, the method further includes: Obtain the relative position data between the vehicle body and the parking space line, as well as the distance data between the vehicle body and adjacent vehicles; Obtain the parallelism threshold and the safe distance threshold of the vehicle in a parking scenario, wherein the parallelism threshold is used to indicate that the vehicle body and the parking space line are nearly completely parallel; The actual parallelism between the vehicle body and the parking space line is calculated based on the relative position data. If the actual parallelism is less than the parallelism threshold, the parallelism deviation value between the actual parallelism and the parallelism threshold is obtained. The spacing deviation value is obtained by comparing the spacing data with the safe spacing threshold; When it is determined that the vehicle has a risk of alignment deviation based on the parallelism deviation value and the spacing deviation value, a vehicle control command is generated. The vehicle is controlled to perform posture adjustment according to the vehicle control command until the actual parallelism between the vehicle body and the parking line is higher than the parallelism threshold, and the actual distance between the vehicle body and the adjacent vehicle is higher than the safe distance threshold.

[0013] Furthermore, the method also includes: If the user identity information authentication fails, the remote connection request is intercepted, and the request frequency and request source characteristics within a set time range are obtained; Analyze the frequency and source characteristics of the requests to determine the type of request risk; If the requested risk type is accidental touch, a connection retry prompt is pushed to the control terminal; or, if the requested risk type is malicious request, the system security protection mode is triggered.

[0014] Secondly, embodiments of the present invention provide a pre-start control device for vehicle parking, the device comprising: The monitoring module is used to monitor remote connection requests sent by the control terminal, wherein the remote connection request includes user identity information; The response module is used to respond to the remote connection request and authenticate the user identity information; The control module is used to start the vehicle's parking system and put it into a ready state if the authentication is successful. The ready state is used to indicate that the parking system can respond to the parking command of the control terminal in real time. The control module is used to control the vehicle's parking system to perform the corresponding parking maneuver when it hears a parking command sent by the control terminal.

[0015] Thirdly, embodiments of the present invention provide an electronic device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0016] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a computer to perform the method described in the first aspect or any of its corresponding embodiments.

[0017] This application remotely triggers the pre-start of the parking system, changing the XPU initialization process from being initiated by the user's command at the vehicle to being executed after remote authentication. Users no longer need to wait for time-consuming steps such as hardware self-checks and software loading at the vehicle's location, completely resolving the pain point of long startup waiting times. Simultaneously, Bluetooth authentication, XPU pre-start, and parking exit command issuance are separated into two independent stages, breaking the original linearly coupled execution chain and preventing the entire parking exit process from being interrupted due to XPU startup failure. Furthermore, after XPU pre-start is completed, it is in a ready state and can respond to parking exit commands, significantly improving process fault tolerance and stability, and substantially optimizing the user experience. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a schematic flowchart of a vehicle parking pre-start control method according to some embodiments of the present invention; Figure 2 This is a flowchart illustrating another vehicle parking pre-start control method according to some embodiments of the present invention; Figure 3This is a flowchart illustrating another vehicle parking pre-start control method according to some embodiments of the present invention; Figure 4 This is a timing diagram of a vehicle parking pre-start control method according to some embodiments of the present invention; Figure 5 This is a structural block diagram of a vehicle parking pre-start control device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] According to embodiments of the present invention, a pre-start control method, apparatus, device, and medium for vehicle parking are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0022] This embodiment provides a pre-start control method for vehicle parking. Figure 1 This is a flowchart of a vehicle parking pre-start control method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Listen for remote connection requests sent by the control terminal, wherein the remote connection request includes user identity information.

[0023] In this embodiment, the vehicle's Bluetooth Low Energy (BLE) module maintains a real-time monitoring state, continuously scanning for Bluetooth connection broadcast signals from surrounding control terminals (such as mobile apps and smart keys) to ensure that no valid requests are missed. When a user triggers a connection action remotely, such as clicking the "Pre-start Parking" button on the mobile app interface or pressing and holding the corresponding function button on the smart key, the control terminal will actively initiate a connection request to the vehicle's BLE module. This request data packet encapsulates core user identity information, specifically including the MAC address of the mobile phone's Bluetooth and the unique hardware identifier of the smart key, which are exclusive identity credentials. This information is the core basis for subsequent authentication operations. After receiving the request, the vehicle's BLE module parses the data packet, extracts the user identity information field, and forwards the complete connection request to the vehicle domain controller according to a preset communication protocol.

[0024] Step S102: Respond to the remote connection request and authenticate the user's identity information.

[0025] In this embodiment, after receiving the remote connection request forwarded by the BLE module, the domain controller initiates the authentication response logic and enters the user identity verification stage. First, the domain controller retrieves a locally pre-stored database of legitimate user identities. This database records information about all authorized terminals bound to the vehicle, including registered mobile phone Bluetooth MAC addresses, smart key unique identifiers, and other baseline data. Then, the domain controller compares the user identity information extracted from the request data packet with the baseline data in the database one by one. If the two are completely consistent, the user identity is deemed legitimate, and authentication passes; if there is a mismatch or no corresponding record, authentication fails. After the authentication result is generated, the domain controller feeds back the result to the BLE module according to the communication protocol, and the BLE module synchronizes it to the control terminal: when authentication passes, it sends a "successful authentication" confirmation signal to the terminal, maintaining the Bluetooth connection; when authentication fails, it sends a failure message and triggers the connection disconnection process, while recording the time of the failure request, terminal characteristics, and other information for subsequent risk assessment.

[0026] Step S103: If the user identity information is authenticated, the parking system controlling the vehicle is pre-started and enters the ready state. The ready state indicates that the parking system can respond to the parking command of the control terminal in real time.

[0027] In this embodiment, controlling the pre-start and ready state of the vehicle's parking system includes: controlling the pre-start of the parking system and detecting whether the functions of all vehicle components associated with the parking system are in an effective state. If the functions of all vehicle components are in an effective state, the coordinates of the vehicle components are calibrated, and the software runtime environment supporting parking decisions is loaded. After the coordinate calibration of the vehicle components is completed and the software runtime environment is loaded, the vehicle's parking system enters the ready state.

[0028] Specifically, after successful user authentication, the domain controller automatically sends a pre-start command to the parking control unit (XPU), triggering the parking system to enter the pre-start process. After starting, the XPU prioritizes functional validity checks on parking-related vehicle components. These checks cover sensing devices such as ultrasonic radar, cameras, and lidar, as well as actuators such as steering, braking, and power systems. The XPU sends self-test commands to verify the signal acquisition capabilities of the sensing devices and the response sensitivity of the actuators. It compares the detected data with preset thresholds to determine if all components are in a valid state. If an anomaly is detected, fault information is reported and the pre-start process is terminated.

[0029] After confirming the functionality of all parking-related vehicle components, the XPU initiates a coordinate calibration process. Using the vehicle's coordinate system as a reference, it calibrates the installation positions of the LiDAR, camera, and ultrasonic radar, eliminating coordinate offsets caused by equipment installation errors and ensuring spatial consistency of the perception data. Simultaneously, the software runtime environment loading process begins, sequentially loading core algorithm models such as parking path planning, obstacle recognition, and parking space contour extraction, as well as hardware drivers and communication protocol programs. At the same time, the integrity and compatibility of each software module are verified.

[0030] After the vehicle component coordinate calibration parameters meet the standards and the software operating environment loading verification passes, the XPU initiates the final state verification to confirm that the perception and decision-making modules are normal. Subsequently, the XPU switches to standby mode, the perception devices collect environmental data in real time, and the actuators are in a low-power active state. The XPU sends a "pre-start complete" signal to the domain controller, and the domain controller synchronizes the readiness prompt to the control terminal through the BLE module. At this point, the parking system officially enters the ready state, capable of responding to parking exit commands in real time.

[0031] Step S104: Upon receiving a parking instruction from the control terminal, control the vehicle's parking system to execute the corresponding parking maneuver.

[0032] In this embodiment, once the parking system enters the ready state, the domain controller maintains continuous communication with the BLE module, listening in real-time to the command signals sent by the control terminal. When a user approaches the vehicle within 15 meters with an authenticated mobile phone or smart key, the BLE module maintains a stable Bluetooth connection. At this time, the user can issue a parking command by clicking the "Parking Out" button on the mobile app or by pressing and holding the parking out function button on the smart key. After receiving the command, the BLE module quickly forwards it to the domain controller. After verifying the validity of the command, the domain controller issues the command to the XPU in the ready state.

[0033] Since the XPU has completed all initialization work, no additional startup waiting time is required. It can start executing logic within 1-2 seconds after receiving the parking command. According to the preset parking algorithm, the XPU first controls the vehicle to complete preparatory actions such as automatically unlocking the doors and adjusting the parking brake. Then, based on the parking space information and surrounding obstacle distribution data collected by the sensing device, it plans the optimal parking path. At the same time, it controls the steering system to adjust the steering angle and the power system to control the driving speed in real time, driving the vehicle smoothly out of the parking space. During the parking process, the XPU continuously collects the vehicle's real-time status data, including the current position coordinates, steering angle, real-time distance to obstacles, and driving speed. It also transmits status information back to the control terminal in real time through the domain controller and BLE module, such as "50cm out of parking space, no obstacles" and "approaching the target position", until the vehicle completes parking and comes to a stop. The XPU then sends a "parking complete" signal to the terminal.

[0034] In the embodiments of this application, such as Figure 2 As shown, the method also includes: Step S201: If at least one vehicle component is in an invalid state, the vehicle component in an invalid state is marked as a faulty vehicle component, and the current fault status of the faulty vehicle component is detected.

[0035] In this embodiment, if the XPU, through self-testing commands and comparison with data thresholds, finds that the function of at least one parking-related vehicle component fails to meet a preset standard, it initiates a fault component marking and fault detection process. First, the XPU marks invalid vehicle components as faulty vehicle components according to preset component coding rules. The marking information includes the component type (e.g., forward ultrasonic radar, left-side high-definition camera, power steering motor, etc.), installation location (e.g., front left corner of the vehicle, center left side of the vehicle body), and unique hardware identifier, ensuring accurate location of the faulty component. Subsequently, the XPU performs specific fault detection on the marked faulty vehicle components. For sensing components (e.g., radar, camera), it checks whether the signal transmission link is unobstructed, whether data acquisition is interrupted, and whether the detection accuracy exceeds the error range. For execution components (e.g., steering system, braking system), it checks whether the control command response is delayed, whether the action execution is stuttered, and whether the torque output is stable. During the detection process, the XPU records the operating parameters, abnormal behavior characteristics, and fault occurrence timestamps of the faulty component in real time.

[0036] Step S202: Obtain redundancy compensation data for the corresponding functions of other vehicle components.

[0037] After marking and detecting the faulty vehicle components, the XPU initiates a redundancy compensation data acquisition process. The core objective of this process is to retrieve functional data from other normal vehicle components in the parking system to assess their ability to replace the faulty component. First, based on the type and functional location of the faulty component, the XPU filters out normal components with similar functions from the vehicle component database. For example, if the faulty component is a forward-facing ultrasonic radar, it filters out normal components with distance detection functions, such as ultrasonic radars in other locations at the front of the vehicle and forward-facing cameras; if the faulty component is the left-side power steering motor, it filters out the backup control unit of the right-side power steering system, etc. Then, the XPU sends data acquisition commands to the selected normal components to obtain their core functional parameters, including the detection range, detection accuracy, and data update frequency of sensing components, and the response speed, action stroke, and load capacity of execution components. Simultaneously, the XPU combines the vehicle's hardware topology to calculate key indicators such as the location coverage and functional overlap ratio of normal components relative to the faulty component, integrating these functional parameters with topological indicators to form complete redundancy compensation data.

[0038] Step S203: Analyze whether the redundancy compensation data of the analysis function can cover the function of the faulty vehicle component.

[0039] In this embodiment, analyzing whether the redundancy compensation data of the analysis function can cover the function of the faulty vehicle component includes: obtaining the parameter failure range of the corresponding function of the faulty vehicle component, extracting the availability performance data of the corresponding functions of other vehicle components, and determining the redundancy compensation data of other vehicle components in the scenario of taking over the function of the faulty component based on the availability performance data. The parameter failure range is compared with the redundancy compensation data to determine whether other vehicle components can fully take over the function of the faulty vehicle component.

[0040] XPU extracts the core functional parameters of faulty vehicle components from the fault detection report and, combined with their normal operating thresholds, determines the failure range of these parameters. For example, for sensing components (such as radar), it identifies the abnormal ranges for parameters such as detection distance and accuracy; for actuating components (such as steering motors), it defines the failure ranges for parameters such as torque and response speed, while also marking the critical values ​​and fluctuation ranges of the failure parameters. This forms precise parameter failure range data, providing a clear judgment benchmark for subsequent redundancy compensation analysis.

[0041] XPU identifies normal vehicle components with the same function as the faulty component and extracts their usability performance data, including core parameters such as the detection range and data update frequency of sensing components, and the response speed and load capacity of execution components. Then, combining the functional requirements of the faulty component, through performance superposition and range adaptation calculations, it determines the redundancy compensation data of these normal components in the scenario of undertaking the faulty function, clarifies their covered functional range, performance compliance level, and compensation effect when working collaboratively, forming a complete redundancy compensation data system.

[0042] XPU performs a comparative analysis of the parameter failure range of the faulty component with the redundancy compensation data of the normal component, focusing on verifying whether the functional coverage range of the redundancy compensation data completely includes the parameter failure range and whether the performance indicators meet or exceed the normal standards of the faulty component. If the two are perfectly matched and the normal component can independently or collaboratively meet the functional requirements of the faulty component, it is determined that it can be fully accepted; if there are coverage blind spots or performance failures, it is determined that it cannot be fully accepted.

[0043] Step S204: If the redundancy compensation for the function execution can cover the function of the faulty vehicle component, then the step of calibrating the coordinates of the vehicle component is performed. Alternatively, if the redundancy compensation for the function execution cannot cover the fault condition of the faulty vehicle component, then the parking system pre-start is terminated, and detailed information of the faulty vehicle component is pushed to the control terminal.

[0044] In this embodiment, after completing the functional coverage analysis of the redundancy compensation data, the XPU executes a differentiated processing procedure based on the analysis results. If the analysis results show that the redundancy compensation data of normal components can completely cover the core functions of the faulty vehicle components, that is, the functional coverage of normal components includes the working range of the faulty components and the performance indicators meet the requirements of the faulty components, the XPU determines that the redundancy compensation is effective. At this time, it will skip the faulty components and directly start the coordinate calibration step for all normal vehicle components. The calibration process uses the vehicle body coordinate system as a reference to complete the pixel mapping of the LiDAR and the camera, and the detection angle calibration of the ultrasonic radar, ensuring the spatial consistency of the perception data of normal components, and providing accurate hardware data support for subsequent software runtime environment loading and system readiness.

[0045] If the analysis results show that the redundancy compensation data cannot cover the functions of the faulty vehicle components, such as blind spots in the detection range of normal components or insufficient execution capabilities, the XPU will determine that the redundancy compensation is invalid, terminate the pre-start process of the parking system, and at the same time organize the detailed information of the faulty vehicle components, including component type, installation location, fault symptoms, and missing functions, and push it to the control terminal through the domain controller and BLE module. The terminal interface will clearly display the details of the faulty components and simultaneously send a prompt message "Parking system pre-start failed, please check the faulty components and try again" to ensure that the user can grasp the fault situation in a timely manner.

[0046] In this embodiment of the application, after the parking system controls the vehicle to perform the corresponding parking exit action, such as Figure 3 As shown, the method also includes: Step S301: Collect real-time parking status of vehicles.

[0047] In this embodiment, during the parking system's control of the vehicle to perform a parking maneuver, the XPU continuously drives sensing devices such as ultrasonic radar, high-definition cameras, and lidar to collect real-time parking data. This data covers multiple dimensions, including the vehicle's current position coordinates, real-time distance to surrounding obstacles (adjacent vehicles, curbs, pillars, etc.), the relative angle between the vehicle body and parking space lines, and dynamic parameters such as driving speed and steering angle. Simultaneously, the XPU also acquires vehicle operating status information via the CAN bus, such as the braking system's operating status and steering system response. All collected data is aggregated and preprocessed at a preset frequency to remove invalid interference data, forming structured real-time parking status data.

[0048] Step S302: Send real-time parking status to the control terminal.

[0049] In this embodiment, after collecting and preprocessing real-time parking status data, the XPU forwards the structured dataset to the vehicle's BLE module via the domain controller according to a preset communication protocol. The BLE module encrypts and packages the data, transmitting it to the user's control terminal (mobile app or smart key) via a stable Bluetooth communication link. To enhance the user's intuitive experience, the data is presented in diverse formats, including not only the original parameter values ​​but also real-time parking trajectory animations, distance warning prompts, and other visual content. The entire transmission process maintains low latency and high stability, ensuring that the user can monitor the vehicle's parking progress and changes in the surrounding environment in real time.

[0050] Step S303: Analyze the real-time parking situation to determine whether the vehicle has reached the corresponding parking position.

[0051] In this embodiment, the XPU retrieves the preprocessed real-time parking status dataset and initiates a position determination algorithm for analysis. First, the vehicle's current position coordinates are compared with the preset target parking position coordinates, and the deviation is calculated. Second, combining the parallelism data between the vehicle body and the parking space lines, and the distance data between the vehicle and adjacent vehicles and the curb, it is determined whether the vehicle meets the preset parking standards. Simultaneously, it also detects whether the vehicle's speed is approaching zero and whether the braking system has triggered the parking state. If all determination indicators meet the preset thresholds—that is, the deviation between the vehicle's position coordinates and the target position is within the allowable range, the parallelism and distance meet the standards, and the vehicle is in a stable parking state—then the vehicle is determined to have reached the corresponding parking position. If any indicator fails to meet the standards, the vehicle is determined not to have completed parking and must continue with parking or fine-tuning actions.

[0052] In step S304, if the vehicle reaches the corresponding parking position, a parking completion signal is sent to the control terminal.

[0053] In this embodiment, when the XPU analyzes the real-time parking situation and determines that the vehicle has reached the corresponding parking position, it generates a "parking complete" status signal. This signal is first synchronized to the domain controller, which performs a status verification to confirm that the vehicle's parking brake is active and that the sensing devices have not detected any abnormal risks. Then, it is sent to the user's control terminal via the BLE module. Upon receiving the signal, the terminal will notify the user of "parking complete" with a prominent prompt tone and text pop-up. The control terminal will also simultaneously display a final parking position diagram, marking the distance data between the vehicle body and the parking space lines, as well as the distance data between adjacent vehicles.

[0054] As an example, such as Figure 4As shown, the user remotely initiates a Bluetooth connection request via mobile phone or key. After receiving the request, the BLE module forwards it to the domain controller. After the domain controller completes user authentication and passes the authentication, it automatically performs preprocessing of the startup conditions. If the conditions are met, a pre-start command is issued to the XPU. After the XPU starts and completes initialization, it enters the parking wait state and simultaneously sends the pre-start completion information back to the domain controller and the user terminal. When the user approaches the vehicle with the device, a parking command is issued. The command is forwarded to the ready XPU via the BLE module and the domain controller. The XPU immediately executes the parking action and continuously sends the real-time parking status back to the user terminal via the domain controller and the BLE module until parking is completed.

[0055] In this embodiment, after the vehicle reaches the corresponding parking position, the method further includes: acquiring relative position data between the vehicle body and the parking space line, and distance data between the vehicle body and adjacent vehicles. A parallelism threshold and a safe distance threshold are acquired for the vehicle in the parking scenario, wherein the parallelism threshold indicates that the vehicle body and the parking space line are nearly perfectly parallel. The actual parallelism between the vehicle body and the parking space line is calculated based on the relative position data, and if the actual parallelism is less than the parallelism threshold, a parallelism deviation value is acquired between the actual parallelism and the parallelism threshold. The distance deviation value is obtained by comparing the distance data with the safe distance threshold. When it is determined that the vehicle has a risk of alignment deviation based on the parallelism deviation value and the distance deviation value, a vehicle control command is generated. The vehicle is controlled to perform attitude adjustment according to the vehicle control command until the actual parallelism between the vehicle body and the parking space line is higher than the parallelism threshold, and the actual distance between the vehicle body and adjacent vehicles is higher than the safe distance threshold.

[0056] Specifically, when the parking system enters the parking exit or fine-tuning phase, the XPU drives a high-definition camera to capture image information of the parking space lines. Image recognition algorithms extract the edge features and position coordinates of the parking space lines. Simultaneously, combined with point cloud data from the LiDAR, a mapping relationship is constructed between the vehicle's coordinate system and the parking space line coordinate system. This allows for the calculation of the relative position data between the vehicle and the parking space lines, including the angle between the vehicle's centerline and the parking space lines, and the vertical distance between the front and rear ends of the vehicle and the parking space lines. Regarding the distance data between the vehicle and adjacent vehicles, the XPU utilizes ultrasonic radars distributed around the vehicle to continuously detect the real-time distance between the vehicle and adjacent vehicles in all directions. Through multi-radar data fusion algorithms, blind spots and errors are eliminated, ultimately generating accurate distance data.

[0057] XPU retrieves the parallelism threshold and safety distance threshold matching the current parking space type (e.g., parallel or perpendicular) from a locally pre-set parking standard database. The parallelism threshold is defined based on the percentage of fit between the vehicle body and the parking line, with a high value (e.g., 95%) to characterize the ideal degree of fit where the vehicle body and the parking line are nearly perfectly parallel. This threshold setting comprehensively considers factors such as the vehicle size of different models and the space constraints of parking scenarios. The safety distance threshold is set according to industry safety standards and user habits, including parameters such as the minimum safe distance between the vehicle body and adjacent vehicles, and the minimum distance between the vehicle body and the curb, ensuring sufficient door opening space and passage allowance after parking, avoiding the risk of scratches.

[0058] Based on the acquired relative position data between the vehicle body and the parking space line, the XPU initiates a parallelism calculation model. Using the angle between the vehicle's centerline and the parking space line as the core parameter, it converts the angle value into a percentage of fit through trigonometric functions, obtaining the actual parallelism between the vehicle body and the parking space line. Subsequently, the actual parallelism is compared with a preset parallelism threshold. If the actual parallelism is less than the threshold, it indicates that the vehicle body has not achieved the ideal parallelism and there is a misalignment. In this case, the XPU calculates the difference between the two values ​​through subtraction, obtaining the parallelism deviation value. This deviation value directly reflects the gap between the vehicle body and the ideal parallelism.

[0059] The XPU collects real-time distance data between the vehicle and adjacent vehicles and compares it one by one with preset safe distance thresholds. For the distance data in each direction (e.g., front of the vehicle and the vehicle in front, rear of the vehicle and the vehicle behind, side of the vehicle and adjacent vehicle), the difference between the real-time distance and the safe distance threshold is calculated to obtain the distance deviation value in each direction. If the real-time distance is greater than the safe distance threshold, the deviation value is positive, indicating that the distance in that direction is sufficient and there is no risk of collision; if the real-time distance is less than the safe distance threshold, the deviation value is negative, indicating that the distance in that direction is insufficient and there is a risk of alignment deviation. The distance deviation values ​​in all directions are summarized and compiled to form complete distance deviation data.

[0060] The XPU inputs parallelism deviation and spacing deviation values ​​into the alignment deviation risk assessment model. When the parallelism deviation exceeds the allowable range, or the spacing deviation in either direction is negative, the vehicle is deemed to have alignment deviation risk. In this case, the XPU generates corresponding vehicle control commands based on the magnitude and direction of the deviation. For example, if the parallelism deviation is large and the vehicle leans to the left, a command to "slightly adjust the steering angle to the right by 5°" is generated; if the spacing deviation between the rear of the vehicle and the vehicle behind is negative, a command to "move forward 10cm" is generated. The control commands specify detailed parameters such as steering angle, travel distance, and vehicle speed.

[0061] The XPU generates vehicle control commands and sends them to the vehicle's actuators (steering system, powertrain, and braking system) via the CAN bus, controlling the vehicle to perform precise attitude adjustments. During the adjustment process, the XPU continuously collects data on the relative position of the vehicle body to the parking lines and the distance to adjacent vehicles, calculating the actual parallelism and distance values ​​in real time and comparing them with preset thresholds. If the actual parallelism is still lower than the parallelism threshold, or the distance value is still lower than the safe distance threshold, the control command parameters are adjusted based on the new deviation value, driving the vehicle to perform a second fine-tuning. The XPU will only stop attitude adjustment when the real-time data shows that the actual parallelism between the vehicle body and the parking lines is higher than the parallelism threshold, and the distance between the vehicle body and adjacent vehicles in all directions is higher than the safe distance threshold, ensuring that the vehicle is finally in the optimal parking position.

[0062] In this embodiment, the method further includes: if user identity authentication fails, intercepting the remote connection request and obtaining the request frequency and request source characteristics within a set time range. Analyzing the request frequency and request source characteristics to determine the request risk type. If the request risk type is an accidental touch type, pushing a connection retry prompt to the control terminal. Alternatively, if the request risk type is a malicious request type, triggering the system security protection mode.

[0063] Specifically, when the domain controller completes authentication of the user's identity information and fails the authentication, it triggers a connection interception mechanism, directly severing the Bluetooth communication link between the control terminal and the vehicle's BLE module, prohibiting any subsequent commands initiated by the terminal from entering the parking system. Simultaneously, the domain controller initiates an abnormal request data collection process, retrieving connection request records from the terminal within a preset time range (e.g., 10 minutes), counting the frequency of requests, and extracting request source characteristics, including the terminal's Bluetooth MAC address, IP address, device model, request initiation timestamp, and other key identifying information, forming a complete abnormal request data archive to provide accurate data support for subsequent risk type determination.

[0064] The domain controller compares the collected request frequency with a preset risk frequency threshold and performs multi-dimensional analysis of the request source characteristics. If the request frequency is below the threshold and the source characteristics match the historical operation records of the vehicle-bound terminal (such as occasional incorrect identity information input), it is determined to be an accidental touch. If the request frequency far exceeds the threshold, or the source characteristics show an unfamiliar device or abnormal IP address, and there is a pattern of repeated requests, it is determined to be a malicious request. The entire analysis process relies on a preset risk assessment model and cross-validates it with historical abnormal request data to ensure the accuracy and reliability of risk type determination.

[0065] When the domain controller determines that the request risk type is accidental touch, it generates a connection retry prompt message. This message includes the specific reason for the authentication failure (such as identity information mismatch, unstable Bluetooth signal), and correct operation instructions (such as verifying the terminal binding status, or improving signal strength by moving closer to a vehicle). Subsequently, the domain controller pushes the prompt message to the control terminal via the BLE module. The terminal interface displays this content in the form of a pop-up window or message notification, while retaining the terminal's connection permissions. This allows the user to re-initiate the remote connection request after correcting the operation, avoiding disruption to the user's normal experience due to accidental misoperation.

[0066] When the domain controller determines that a request is of a malicious type, it will trigger the system security protection mode. First, it adds the Bluetooth MAC address, IP address, and other information of the control terminal to the parking system's blacklist, restricting it from initiating connection requests again within a preset period (such as 24 hours). Second, it activates an abnormal request recording and reporting mechanism, encrypting and storing data such as the frequency, source characteristics, and time of malicious requests in the vehicle's local database and cloud backup system for easy tracing by the vehicle owner. At the same time, it pushes malicious intrusion warning information to the main account bound to the vehicle, prompting the owner to check the vehicle status in time. If necessary, the vehicle's parking function can be remotely locked to comprehensively protect the security of the parking system and the vehicle.

[0067] This embodiment also provides a vehicle parking pre-start control device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0068] This embodiment provides a pre-start control device for vehicle parking, such as... Figure 5 As shown, it includes: The listening module 501 is used to listen for remote connection requests sent by the control terminal, wherein the remote connection request includes user identity information; The response module 502 is used to respond to remote connection requests and authenticate user identity information; The control module 503 is used to control the vehicle's parking system to start and enter a ready state if the authentication is successful. The ready state is used to indicate that the parking system can respond to the parking command of the control terminal in real time. The control module 504 is used to control the vehicle's parking system to perform the corresponding parking maneuver when it hears a parking command sent by the control terminal.

[0069] In this embodiment, the control module 504 is used to control the pre-start of the parking system and detect whether the functions of the vehicle components associated with the parking system are all in an effective state; if the functions of the vehicle components are all in an effective state, the coordinates of the vehicle components are calibrated and the software operating environment supporting the parking decision is loaded; after the coordinate calibration of the vehicle components is completed and the software operating environment is loaded, the parking system controlling the vehicle enters the ready state.

[0070] In this embodiment of the application, the device further includes: a fault handling module, configured to: if at least one vehicle component is in an invalid state, mark the vehicle component in an invalid state as a faulty vehicle component and detect the current fault status of the faulty vehicle component; acquire redundancy compensation data for the corresponding functions of other vehicle components; analyze whether the redundancy compensation data can cover the function of the faulty vehicle component; if the redundancy compensation can cover the function of the faulty vehicle component, perform a step of calibrating the coordinates of the vehicle component; or, if the redundancy compensation cannot cover the fault status of the faulty vehicle component, terminate the pre-start of the parking system and push detailed information of the faulty vehicle component to the control terminal.

[0071] In this embodiment of the application, the fault handling module is specifically used to obtain the parameter failure range of the corresponding function of the faulty vehicle component; extract the availability performance data of the corresponding function of other vehicle components, and determine the redundancy compensation data of other vehicle components in the scenario of taking over the function of the faulty component based on the availability performance data; compare the parameter failure range with the redundancy compensation data to determine whether other vehicle components can fully take over the function of the faulty vehicle component.

[0072] In this embodiment of the application, the device further includes: a data acquisition module, used to acquire real-time parking status of the vehicle; send the real-time parking status to the control terminal; analyze the real-time parking status to determine whether the vehicle has reached the corresponding parking position; and if the vehicle has reached the corresponding parking position, send a parking completion signal to the control terminal.

[0073] In this embodiment, the device further includes: an adjustment module, configured to acquire relative position data between the vehicle body and the parking space line, and distance data between the vehicle body and adjacent vehicles; acquire a parallelism threshold and a safe distance threshold for the vehicle in a parking scenario, wherein the parallelism threshold indicates that the vehicle body and the parking space line are nearly perfectly parallel; calculate the actual parallelism between the vehicle body and the parking space line based on the relative position data, and if the actual parallelism is less than the parallelism threshold, acquire a parallelism deviation value between the actual parallelism and the parallelism threshold; compare the distance data with the safe distance threshold to obtain a distance deviation value; when it is determined that the vehicle has a risk of alignment deviation based on the parallelism deviation value and the distance deviation value, generate a vehicle control command; control the vehicle to perform posture adjustment according to the vehicle control command until the actual parallelism between the vehicle body and the parking space line is higher than the parallelism threshold, and the actual distance between the vehicle body and the adjacent vehicle is higher than the safe distance threshold.

[0074] In this embodiment of the application, the device further includes: a processing module, configured to intercept remote connection requests if user identity information authentication fails, and obtain the request frequency and request source characteristics within a set time range; analyze the request frequency and request source characteristics to determine the request risk type; if the request risk type is a mistaken touch type, push a connection retry prompt to the control terminal; or, if the request risk type is a malicious request type, trigger the system security protection mode.

[0075] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of the present invention, such as... Figure 6 As shown, the electronic device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise as required. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0076] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GPA), or any combination thereof.

[0077] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0078] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device as displayed on a mini-program landing page. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

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

[0080] The electronic device also includes a communication interface 30 for communicating with other devices or communication networks.

[0081] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0082] Although embodiments of the invention have been 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 invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A pre-start control method for vehicle parking, characterized in that, The method includes: Listen to remote connection requests sent by the control terminal, wherein the remote connection request includes user identity information; In response to the remote connection request, authenticate the user's identity information; If the user identity information is authenticated, the parking system of the vehicle is pre-started and enters a ready state, wherein the ready state is used to indicate that the parking system can respond to the parking command of the control terminal in real time. Upon receiving a parking command from the control terminal, the system controls the vehicle's parking system to execute the corresponding parking maneuver.

2. The method according to claim 1, characterized in that, The pre-start and ready state of the vehicle parking system includes: Control the pre-start of the parking system and detect whether the functions of the vehicle components associated with the parking system are all in an effective state; If all the functions of the vehicle components are in an effective state, the coordinates of the vehicle components are calibrated, and the software operating environment supporting parking decisions is loaded. Once the coordinate calibration of the vehicle components is completed and the software operating environment is loaded, the parking system controlling the vehicle enters a ready state.

3. The method according to claim 2, characterized in that, The method further includes: If at least one of the vehicle components is in an invalid state, the invalid vehicle component is marked as a faulty vehicle component, and the current fault status of the faulty vehicle component is detected. Obtain redundancy compensation data for the corresponding functions of other vehicle components; Analyze whether the redundancy compensation data for the aforementioned functions can cover the functions of the faulty vehicle components. If the redundancy compensation of the function can cover the function of the faulty vehicle component, then the step of calibrating the coordinates of the vehicle component is performed; or, if the redundancy compensation of the function cannot cover the fault of the faulty vehicle component, then the pre-start of the parking system is terminated, and detailed information of the faulty vehicle component is pushed to the control terminal.

4. The method according to claim 3, characterized in that, The analysis of whether the redundancy compensation data for the function can cover the function of the faulty vehicle component includes: Obtain the parameter failure range of the corresponding function of the faulty vehicle component; Extract availability performance data of other vehicle components corresponding to their functions, and determine redundancy compensation data of other vehicle components in the scenario of taking over the function of the faulty component based on the availability performance data. By comparing the failure range of the parameters with the redundancy compensation data, it is determined whether the other vehicle components can fully assume the function of the faulty vehicle components.

5. The method according to claim 1, characterized in that, After controlling the vehicle's parking system to perform the corresponding parking exit action, the method further includes: Collect real-time parking status of the vehicles; Send the real-time parking status to the control terminal; Analyze the real-time parking situation to determine whether the vehicle has reached the corresponding parking position; If the vehicle reaches the corresponding parking position, a parking completion signal is sent to the control terminal.

6. The method according to claim 5, characterized in that, After the vehicle reaches the corresponding parking position, the method further includes: Obtain the relative position data between the vehicle body and the parking space line, as well as the distance data between the vehicle body and adjacent vehicles; Obtain the parallelism threshold and the safe distance threshold of the vehicle in a parking scenario, wherein the parallelism threshold is used to indicate that the vehicle body and the parking space line are nearly completely parallel; The actual parallelism between the vehicle body and the parking space line is calculated based on the relative position data. If the actual parallelism is less than the parallelism threshold, the parallelism deviation value between the actual parallelism and the parallelism threshold is obtained. The spacing deviation value is obtained by comparing the spacing data with the safe spacing threshold; When it is determined that the vehicle has a risk of alignment deviation based on the parallelism deviation value and the spacing deviation value, a vehicle control command is generated. The vehicle is controlled to perform posture adjustment according to the vehicle control command until the actual parallelism between the vehicle body and the parking line is higher than the parallelism threshold, and the actual distance between the vehicle body and the adjacent vehicle is higher than the safe distance threshold.

7. The method according to claim 1, characterized in that, The method further includes: If the user identity information authentication fails, the remote connection request is intercepted, and the request frequency and request source characteristics within a set time range are obtained; Analyze the frequency and source characteristics of the requests to determine the type of request risk; If the requested risk type is accidental touch, a connection retry prompt is pushed to the control terminal; or, if the requested risk type is malicious request, the system security protection mode is triggered.

8. A pre-start control device for vehicle parking, characterized in that, The device includes: The monitoring module is used to monitor remote connection requests sent by the control terminal, wherein the remote connection request includes user identity information; The response module is used to respond to the remote connection request and authenticate the user identity information; The control module is used to start the vehicle's parking system and put it into a ready state if the authentication is successful. The ready state is used to indicate that the parking system can respond to the parking command of the control terminal in real time. The control module is used to control the vehicle's parking system to perform the corresponding parking maneuver when it hears a parking command sent by the control terminal.

9. An electronic device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1 to 7.

Images