A vehicle management method and device, electronic equipment and storage medium

Abstract

The application provides a vehicle management method and device, electronic equipment and a storage medium, wherein the method comprises: if a parking lock enters a drop lock state in response to a release instruction, obtaining a vehicle identifier in a detection area corresponding to the parking lock; determining whether the vehicle identifier changes; and controlling the parking lock to always be in the drop lock state during the period when no change occurs. The application embodiments help to solve the problem of vehicle scratching caused by change of the drop lock state.

Description

Technical Field

[0001] This application relates to the field of smart parking technology, and more specifically, to a vehicle management method, device, electronic device, and storage medium. Background Technology

[0002] With the increasing number of vehicles in cities, intelligent vehicle management equipment (such as parking locks, barriers, and ground locks) is widely used in parking management and access control scenarios. These devices typically identify vehicles to automatically perform release or interception actions, thereby achieving automated access verification and access control.

[0003] Currently, taking parking space lock scenarios as an example, the following logic is commonly used in existing technologies: Once a vehicle passes inspection, the parking lock will engage, but this engaged state typically lasts for a preset period before automatically reverting to the engaged state to prevent vehicle access. This mechanism has a significant drawback in practical applications: if vehicle traffic is slow or there are brief pauses, the lock may engage prematurely before the user has fully entered the parking space, posing a risk of scratching the vehicle.

[0004] The above situation reduces the reliability of access control and affects user experience and security effectiveness. Summary of the Invention

[0005] In view of this, embodiments of this application provide a vehicle management method, device, electronic device, and storage medium to solve the problem of vehicle scratches caused by changes in the locked state.

[0006] In a first aspect, embodiments of this application provide a vehicle management method, the method comprising: If the parking lock enters the locked state in response to the release command, the vehicle identifier in the detection area corresponding to the parking lock is obtained; Determine whether the vehicle identification has changed; During periods when no changes occur, the parking space lock is kept in the locked state.

[0007] In one feasible implementation, before the parking lock enters the locked state in response to a release command, the method further includes: Perform authentication operations on vehicles located in the detection area; If authentication is successful, the parking space lock is determined to enter the locked state in response to the release command.

[0008] In one feasible implementation, authentication is performed on vehicles located in the detection area, including: Obtain vehicle identification information; Determine whether the identity information meets the release conditions; If so, authentication is confirmed to be successful, and a release command is sent to the parking space lock.

[0009] In one feasible implementation, authentication is performed on vehicles located in the detection area, including: If the parking lock receives a release instruction forwarded by the parking lock, it is determined that the vehicle authentication has passed; the release instruction is an instruction forwarded by the parking lock after it receives it from the management terminal. Alternatively, if a release instruction is received from the management terminal, the vehicle authentication is confirmed to be successful, and the release instruction is forwarded to the parking space lock.

[0010] In one feasible implementation, obtaining the vehicle identifier within the detection area corresponding to the parking lock includes: Identify vehicle characteristics of vehicles within the detection area; Obtain the vehicle identifier assigned to the vehicle characteristics; And / or, use the pre-acquired vehicle identity information as the vehicle identifier.

[0011] In one feasible implementation, determining whether the vehicle identification has changed includes: In response to triggering an interception command, determine whether the vehicle identifier has changed; Controlling the parking space lock to always be in the locked state includes: Send information to the parking lock to prohibit the execution of the interception command and / or continue to execute the release command, so as to control the parking lock to always be in the locked state.

[0012] In a feasible implementation, the interception instruction is triggered, including at least one of the following: The vehicle was detected leaving the parking space; The vehicle was detected as not entering the parking space within a preset time period; The vehicle was detected as not meeting the release requirements; An interception command was received for the parking space lock.

[0013] Secondly, embodiments of this application also provide a vehicle management device, the device comprising: The acquisition module is used to acquire the vehicle identifier within the detection area corresponding to the parking lock if the parking lock enters the locked state in response to the release command. The tracking module is used to determine whether the vehicle identification has changed; The control module is used to keep the parking space lock in the locked state when no change occurs.

[0014] In one feasible implementation, the device further includes: The authentication module is used to perform authentication operations on vehicles located in the detection area before the parking lock enters the locking state in response to the release command; The status determination module is used to determine that the parking space lock enters the locked state in response to the release command if the authentication is successful.

[0015] In one feasible implementation, the authentication module is used to perform authentication operations on vehicles located in the detection area, including: Obtain vehicle identification information; Determine whether the identity information meets the release conditions; If so, authentication is confirmed to be successful, and a release command is sent to the parking space lock.

[0016] In one feasible implementation, the authentication module is used to perform authentication operations on vehicles located in the detection area, including: If the parking lock receives a release instruction forwarded by the parking lock, it is determined that the vehicle authentication has passed; the release instruction is an instruction forwarded by the parking lock after it receives it from the management terminal. Alternatively, if a release instruction is received from the management terminal, the vehicle authentication is confirmed to be successful, and the release instruction is forwarded to the parking space lock.

[0017] In one feasible implementation, the acquisition module is used to acquire vehicle identifiers within the detection area corresponding to the parking lock, including: Identify vehicle characteristics of vehicles within the detection area; Obtain the vehicle identifier assigned to the vehicle characteristics; And / or, use the pre-acquired vehicle identity information as the vehicle identifier.

[0018] In one feasible implementation, the tracking module is used to determine whether the vehicle identification has changed, including: In response to triggering an interception command, determine whether the vehicle identifier has changed; Controlling the parking space lock to always be in the locked state includes: Send information to the parking lock to prohibit the execution of the interception command and / or continue to execute the release command, so as to control the parking lock to always be in the locked state.

[0019] In a feasible implementation, the interception instruction is triggered, including at least one of the following: The vehicle was detected leaving the parking space; The vehicle was detected as not entering the parking space within a preset time period; The vehicle was detected as not meeting the release requirements; An interception command was received for the parking space lock.

[0020] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the vehicle management method as described in any one of the first aspects.

[0021] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the vehicle management method as described in any one of the first aspects.

[0022] The vehicle management method, device, electronic device, and storage medium provided in this application firstly acquire the vehicle identification within its detection area when the parking lock enters the locked state due to a release command, thereby establishing the real-time identity of the currently passing vehicle; then, by determining whether the vehicle identification has changed, dynamic monitoring is achieved to determine whether the same vehicle is still within the detection area; finally, during the entire period when the vehicle identification has not changed, the parking lock is controlled to always remain in the locked state.

[0023] Through the aforementioned closed-loop control logic, this embodiment of the application can dynamically extend the duration of the locked state based on the persistence determination result of the vehicle identification, rather than relying on a fixed preset time. Compared with the prior art's timed reset locking scheme, this avoids the risk of scratches caused by premature locking due to vehicle passage delays, thus improving the safety and reliability of the passage control process.

[0024] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 A flowchart of a vehicle management method provided in an embodiment of this application is shown.

[0027] Figure 2 A flowchart of another vehicle management method provided by an embodiment of this application is shown.

[0028] Figure 3 A schematic diagram of the structure of a vehicle management device provided in an embodiment of this application is shown.

[0029] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0031] With the increasing number of vehicles in cities, intelligent vehicle management equipment (such as parking locks, barriers, and ground locks) is widely used in parking management and access control scenarios. These devices typically identify vehicles to automatically perform release or interception actions, thereby achieving automated access verification and access control.

[0032] Currently, taking parking space lock scenarios as an example, the following logic is commonly used in existing technologies: Once a vehicle passes inspection, the parking lock will engage, but this engaged state typically lasts for a preset period before automatically reverting to the engaged state to prevent vehicle access. This mechanism has a significant drawback in practical applications: if vehicle traffic is slow or there are brief pauses, the lock may engage prematurely before the user has fully entered the parking space, posing a risk of scratching the vehicle.

[0033] The above situation reduces the reliability of access control and affects user experience and security effectiveness.

[0034] Based on this, embodiments of this application provide a vehicle management method, apparatus, electronic device, and storage medium, which are described below through embodiments.

[0035] To facilitate understanding of this embodiment, a vehicle management method disclosed in this application is first described. The method provided in this application can be applied to a processing terminal that maintains communication with a parking space lock. This processing terminal can be a standalone controller, a control module integrated within the parking space lock, or a logic processing unit deployed on a remote server, as long as it can acquire sensing data from the detection area and send control commands to the parking space lock. In actual deployment, the processing terminal is typically used in conjunction with video acquisition equipment or radio frequency reading equipment to acquire vehicle identity information within the detection area and decide on the state switching of the parking space lock accordingly. A detailed description follows, such as... Figure 1 As shown, it includes the following steps: Step 101: If the parking lock enters the locked state in response to the release command, then obtain the vehicle identifier in the detection area corresponding to the parking lock.

[0036] Once the parking lock receives a release command and locks, it will immediately trigger a detection operation on the detection area. The release command can come from various sources, such as a manual control signal from the user via remote control or a command issued by the processing terminal after automatic authentication. The purpose of the detection is to obtain the vehicle identifiers of vehicles currently within the detection area, serving as the basis for subsequent determinations of whether the same vehicle remains within the area.

[0037] The specific form of the vehicle identification can be determined based on the actual detection technology used. For example, if radio frequency-based communication methods (such as RFID) are used, the vehicle identification can be a unique identifier in an electronic tag; if images are captured using video capture equipment, the license plate number can be used as the vehicle identification. In addition, the license plate can be replaced with other unique vehicle body features, such as the vehicle's color, model, logo, etc., forming a feature vector individually or in combination. In other scenarios, the processing unit can first identify the vehicle's appearance features and then temporarily generate or assign a vehicle identification, which can then be used to distinguish different vehicles during subsequent detection. Of course, other identification methods that can uniquely distinguish different vehicles can also be used.

[0038] The above data acquisition operation can be performed proactively the moment the parking lock closes, or it can begin within a short delay after the lock closes, as long as the identity of the vehicle currently attempting to pass can be captured. In practical applications, the timing of data acquisition can be adjusted according to the response speed of the detection equipment and the normal traffic speed of vehicles to avoid missed or incorrect data acquisition.

[0039] Step 102: Determine whether the vehicle identification has changed.

[0040] Furthermore, after obtaining the vehicle identification, this embodiment continuously monitors whether the vehicle identification changes. These changes include, but are not limited to, the vehicle identification within the detection area changing from present to absent, or from the current identification to a different identification. Through this continuous comparison, it can be determined whether the vehicle is consistently within the detection area, or whether the same vehicle continuously occupies the area.

[0041] Step 103: During the period when no changes occur, control the parking space lock to always be in the locked state.

[0042] During the entire period when the vehicle identification remains unchanged, the parking lock will remain locked. In other words, as long as the same vehicle remains within the detection area, the parking lock will not automatically engage, regardless of whether the vehicle is moving slowly, stationary, or at other low speeds. Thus, the state change logic will only be triggered when the vehicle completely leaves or is replaced by another vehicle.

[0043] It's easy to understand that this approach differs fundamentally from traditional timed reset schemes. Traditionally, parking locks typically start a countdown after locking, forcibly raising the lock once the time is up, without considering whether the vehicle has safely passed. The method provided in this application, however, bases control decisions on real-time vehicle identification comparison. Only when it's confirmed that the vehicle no longer needs to pass will the locking status be changed, effectively avoiding the risk of scratches caused by premature lock raising due to traffic congestion.

[0044] The vehicle management method, device, electronic device, and storage medium provided in this application firstly acquire the vehicle identification within its detection area when the parking lock enters the locked state due to a release command, thereby establishing the real-time identity of the currently passing vehicle; then, by determining whether the vehicle identification has changed, dynamic monitoring is achieved to determine whether the same vehicle is still within the detection area; finally, during the entire period when the vehicle identification has not changed, the parking lock is controlled to always remain in the locked state.

[0045] Through the aforementioned closed-loop control logic, this embodiment of the application can dynamically extend the duration of the locked state based on the persistence determination result of the vehicle identification, rather than relying on a fixed preset time. Compared with the prior art's timed reset locking scheme, this avoids the risk of scratches caused by premature locking due to vehicle passage delays, thus improving the safety and reliability of the passage control process.

[0046] In a feasible implementation plan, such as Figure 2 As shown, before the parking lock enters the locked state in response to the release command, the method further includes: Step 201: Perform authentication on vehicles located in the detection area.

[0047] Step 202: If authentication is successful, the parking space lock is determined to enter the locked state in response to the release command.

[0048] Before the parking lock performs the locking action, it will first perform an authentication operation on the vehicles located in the detection area. The purpose of authentication is to confirm whether the current vehicle has the legal qualification to pass. Only after the authentication is successful can the processing terminal determine that the parking lock should respond to the release command and enter the locking state.

[0049] Authentication operations can be categorized into two main types. One type is automatic authentication, where the processing unit automatically acquires the vehicle's identity information via video equipment, RFID readers, or other sensors, compares it with a pre-configured permission database, and determines whether access is granted based on the comparison result. The permission database may contain information on monthly rental vehicles, reserved vehicles, whitelisted vehicles, or other vehicles with long-term or temporary access rights. In this case, authentication is typically triggered when the vehicle enters the detection area, automatically initiated by the processing unit through its connected data acquisition equipment after detecting the vehicle's entry.

[0050] Another type is manual authentication, which is common when users send a release signal via remote control or when administrators manually confirm the release on the management terminal. In this method, whether authentication is successful depends on human judgment or authorization. Once the processing terminal receives a valid release command, it considers the authentication to be successful and determines that the parking lock has entered the locked state in response to the release command.

[0051] Whether it's automatic or manual authentication, the core principle is to confirm that the current vehicle can legally pass, thereby deciding whether to allow the parking lock to lower. It should be noted that in manual authentication scenarios, the release signal issued by the remote control or management terminal already includes human authorization confirmation. The processing end does not need to perform additional identity verification; it only needs to regard the release command as the basis for successful authentication.

[0052] The aforementioned pre-authentication mechanism ensures that the locking action is only performed on vehicles that have been granted permission to enter, preventing unauthorized vehicles from entering when the parking space lock is engaged. Simultaneously, the vehicle identification information collected during automatic authentication can be retained and used as a reference identifier for comparison in subsequent vehicle tracking phases. For manual authentication, since the release command itself typically does not carry specific vehicle identification information, the processing unit can separately obtain the vehicle identifier within the detection area (corresponding to step 101) after confirming successful authentication and the parking space lock has engaged, which also provides initial data for subsequent continuous monitoring.

[0053] In one feasible implementation, this method of automatic authentication is described, in which authentication is performed on vehicles located in the detection area, including: Obtain the vehicle's identity information; determine whether the identity information meets the release conditions; if so, confirm that the authentication is successful and send a release command to the parking space lock.

[0054] First, vehicle identification information needs to be obtained. This acquisition is performed by the processing unit through a connected data acquisition device. The specific type of data acquisition device can be selected based on the actual deployment conditions. For example, when using a video camera, identification information can be obtained by capturing images of the front or rear of the vehicle and identifying the license plate number; when using an RFID reader, a unique identification code can be obtained by reading the electronic tag installed on the vehicle; when using wireless communication methods such as Bluetooth or ultra-wideband, the device address can be obtained by detecting the signal emitted by the onboard unit. In addition, multiple data acquisition methods can be combined, with another method used as a supplement if one method fails, to improve the success rate of identification information acquisition.

[0055] After obtaining the vehicle's identity information, the processing unit further determines whether this identity information meets the pre-set release conditions. Release conditions refer to the criteria used to determine whether a vehicle has passage permission, and their specific content can be flexibly configured according to management needs. For example, a set of permitted license plate numbers can be stored in a permission list, and the currently identified license plate is compared with the list; if a match is found, the condition is considered met. Another example is setting automatic release permissions for certain vehicle types or tags, such as internal official vehicles or pre-booked vehicles that have paid fees. In some temporary visitor scenarios, the validity of a one-time pass code can also be used as a criterion for release. As long as the current vehicle's identity information matches the pre-set release rules, the vehicle is determined to meet the release conditions.

[0056] Once the identity information meets the release conditions, the processing terminal confirms successful authentication and sends a release command to the parking lock. Since this release command is issued by the processing terminal itself, it is aware that a release action has been triggered and can therefore determine that the parking lock will respond and enter the locking state. Upon receiving the command, the parking lock executes the locking action, allowing the vehicle to pass smoothly. It should be noted that the entity sending the release command can be the processing terminal itself, or it can forward the command to the parking lock through an intermediate device, as long as the parking lock ultimately receives and responds to the release command. The timing of sending the command is usually immediately after successful authentication. In some special scenarios, the execution can be selected at an appropriate time based on the vehicle's current position and speed after successful authentication, and the parking lock can be determined to respond to the release command and enter the locking state at that appropriate time, thus ensuring that the vehicle is just about to pass when the parking lock locks.

[0057] The series of operations described above—acquiring identity information, comparing release conditions, and sending release instructions—constitutes a complete automated authentication process. The core of this process lies in centralizing the authorization logic at the processing end, with the parking lock merely acting as the executor of the instructions. This simplifies the functional requirements of the parking lock and facilitates unified updates to release rules or maintenance of the authorization database when needed. Furthermore, since identity information is collected and recorded during the authentication phase, this information can be directly used in the subsequent vehicle tracking phase or provide a reference for obtaining vehicle identification later, thereby reducing the overhead of repeated data collection and improving the overall response efficiency of the control process.

[0058] In one feasible implementation, a manual authentication method is described, in which authentication is performed on vehicles located in the detection area, including: If the parking lock receives a release instruction forwarded from the parking lock, it is determined that the vehicle authentication has passed; the release instruction is an instruction forwarded by the parking lock after it receives it from the management terminal.

[0059] Alternatively, if a release instruction is received from the management terminal, the vehicle authentication is confirmed to be successful, and the release instruction is forwarded to the parking space lock.

[0060] This approach differs from the automatic authentication logic in the aforementioned embodiments, mainly in the source and transmission path of the release command.

[0061] In one scenario, the management terminal directly sends a release command to the parking lock. Upon receiving this command, the parking lock locks itself and forwards the release command or information indicating its arrival to the processing terminal. Upon receiving the forwarded release command from the parking lock, the processing terminal determines that a vehicle has been manually released, thus confirming successful authentication. In this transmission path, the processing terminal does not participate in the issuance of the release command; instead, it learns of the release action by receiving feedback information from the parking lock.

[0062] In another scenario, the management terminal sends the release command directly to the processing terminal. Upon receiving the release command, the processing terminal verifies that authentication has been successful and then forwards the release command to the parking lock, which then performs the locking action. In this path, the processing terminal acts as a relay for the command, both detecting the arrival of the release command and being responsible for transmitting the command to the final execution device.

[0063] Regardless of the command transmission method used, the processing end will ultimately receive notification that the release command has been triggered, and accordingly determine that authentication is successful and the parking lock responds by locking. Unlike automatic authentication, in manual authentication scenarios, the processing end does not need to actively obtain and compare the vehicle's identity information; the release signal issued by the remote control or management terminal itself includes human authorization confirmation. In other words, manual operation replaces the automatic comparison process; the processing end only needs to confirm that a valid release command has been received to consider authentication successful.

[0064] It should be noted that in actual deployment, the management terminal can take many forms. For example, it can be a dedicated remote control that communicates with the parking lock or processing terminal via radio frequency signals; it can also be host computer software installed in the guard booth or management center that sends commands via network protocols; or it can be a mobile application that is remotely triggered via Bluetooth or the Internet. These different types of management terminals, as long as they can issue valid access commands, can all utilize either of the two command transmission paths mentioned above.

[0065] By including manual authentication as an option in the solution, management scenarios that lack automatic identification or require manual intervention can be addressed. For example, in cases such as temporary visitor entry, equipment malfunction causing automatic identification to fail, or special vehicle passage requiring manual confirmation, managers can manually complete authentication and allow vehicles to pass. The subsequent vehicle tracking and protection logic remains completely consistent with the automatic authentication scenario, ensuring that the entire solution maintains the same control logic under different triggering methods.

[0066] It is particularly important to point out a problem that is easily overlooked but quite common in manual authentication scenarios. After an administrator manually releases a vehicle via remote control or management terminal, the vehicle begins to reverse or slowly drive into the parking space, but the automatic identification device may still be running. If the automatic identification device fails to recognize the vehicle's license plate due to poor lighting, a damaged license plate, or other reasons, it determines that authentication has failed and triggers an locking command. The parking lock may then suddenly lift before the vehicle is fully in the parking space. In this case, since the release is manually confirmed while the locking is generated by automatic logic, the conflict between the two command sources poses a risk of scratching the moving vehicle. The method provided in this application, after processing the release command and entering the locking state, initiates continuous tracking of the vehicle identifier. Regardless of whether the release command is generated by automatic or manual authentication, the subsequent protection logic is executed uniformly. As long as the vehicle identifier remains unchanged, no interception command will be actually executed, and the parking lock will always remain locked. This mechanism avoids the problem of accidental locking due to automatic authentication failure after manual release, ensuring the safety of vehicles throughout the entire entry process.

[0067] In one feasible implementation, obtaining the vehicle identifier within the detection area corresponding to the parking lock includes: Identify vehicle characteristics of vehicles within the detection area; obtain vehicle identifiers assigned to the vehicle characteristics; and / or use the pre-acquired vehicle identity information as the vehicle identifier.

[0068] When performing step 101 to obtain the vehicle identifier, one approach is to identify the vehicle features within the detection area and then obtain the vehicle identifier assigned to those features. These vehicle features can be exterior attributes of the vehicle body, such as model, color, headlight position, window outline, etc., either individually or in combination. After identifying these features, the processing unit assigns a unique identifier to the vehicle within the specific scenario, which serves as the basis for comparison during subsequent tracking.

[0069] Another approach is to use pre-acquired vehicle identification information directly as a vehicle identifier. It's important to note that the source of this identification information is not limited to automatic recognition. In manual authentication scenarios, administrators can also input vehicle identification information through a management terminal, such as manually entering the license plate number while remotely releasing the vehicle, or selecting the corresponding vehicle record from a candidate list on the management interface. Furthermore, even if the release command is manually triggered, if video capture equipment is deployed on-site, the processing unit can actively capture and identify the license plate of the current vehicle after the parking space lock is engaged, thereby obtaining its identification information. In other words, the acquisition of identification information can be decoupled from the authentication method. Regardless of whether authentication is completed through automatic comparison or manual operation, as long as the vehicle's identification information can be obtained, it can be used as a vehicle identifier.

[0070] The two methods for obtaining vehicle identification described above can be used individually or in combination. When one method cannot be used normally due to limitations in detection conditions, the other method can be used as a supplement or alternative, thereby ensuring that a continuous identification basis can be determined for vehicles within the detection area under various working conditions, and ensuring the reliable operation of subsequent tracking logic.

[0071] In one feasible implementation, determining whether the vehicle identification has changed includes: In response to the triggering of the interception command, determine whether the vehicle identifier has changed.

[0072] At this time, controlling the parking space lock to always be in the locked state includes: Send information to the parking lock to prohibit the execution of the interception command and / or continue to execute the release command, so as to control the parking lock to always be in the locked state.

[0073] In this embodiment of the application, the operation of determining whether the vehicle identification has changed can be triggered when a specific condition is met.

[0074] For example, when the processing terminal receives or generates an interception command, it does not immediately send the command to the parking lock and execute the locking action. Instead, it first responds to the interception command to confirm whether the vehicle identification in the current detection area has changed compared to before. The interception command mentioned here can be understood as any trigger signal that intends to switch the parking lock from the locked state to the locked state.

[0075] The reason for adopting this "confirm first, then decide" approach is that in actual traffic scenarios, the generation of an interception command does not necessarily mean that the vehicle has safely left. For example, the automatic authentication logic may determine a timeout and trigger an interception due to a vehicle's prolonged stop, or the license plate recognition result within the detection area may be abnormal at a certain moment, causing the system to believe that the current vehicle does not meet the release conditions. However, the vehicle may still be within the detection area, or even slowly reversing into the parking space. If the processing terminal executes these interception commands directly without discrimination, it is very likely that the parking lock will suddenly rise before the vehicle has completely passed, thus causing a minor collision.

[0076] By linking the vehicle identification confirmation action with the triggering of the interception command, a verification step can be added before each locking action is executed. Only when it is confirmed that the vehicle identification has changed, such as from present to absent or from the current vehicle's identification to that of a different vehicle, will the processor consider the current vehicle to have left, thus allowing the interception command to be executed. Conversely, if the vehicle identification has not changed, it means that the same vehicle is still occupying the detection area, and the interception command will be suspended or prohibited from execution.

[0077] Accordingly, to ensure the parking lock remains locked while the vehicle identification remains unchanged, the processing terminal can send a message prohibiting the execution of an interception command to the parking lock, informing it to ignore or postpone the currently received locking request. Alternatively, the processing terminal can choose to resend a release command or continuously send a keep-lock command to override any previously received interception commands, ensuring the parking lock's execution status matches the actual situation of the vehicle. These two methods can be used individually or in combination; for example, sending a keep-lock command while simultaneously sending a prohibition message provides double protection against malfunctions due to command conflicts.

[0078] It should be noted that the monitoring of whether vehicle identification has changed can be implemented at different frequencies. The processing end can use a periodic approach, collecting vehicle identification data within the detection area at regular intervals and comparing it with the previously recorded identification; alternatively, it can use continuous tracking, i.e., continuously tracking the vehicle's movement trajectory via video stream or signal to determine whether the identification has changed in real time. Regardless of the monitoring frequency used, when an interception command is triggered, the processing end needs to make a status decision based on the latest confirmation result, rather than relying on a single detection value at a particular moment. This design ensures both response speed and avoids erroneous interceptions caused by momentary interference or false alarms.

[0079] In a feasible implementation, the interception instruction is triggered, including at least one of the following: The system detects that a vehicle has left the parking space; detects that a vehicle has not entered the parking space within a preset time period; detects that a vehicle does not meet the release conditions; and receives an interception command for the parking space lock.

[0080] In other words, there are multiple scenarios that can trigger the interception command. The following are some common triggering conditions. These conditions can appear individually or simultaneously.

[0081] One scenario is that the vehicle has been detected as having left the parking space. This detection can be achieved through various sensing methods, such as a geomagnetic sensor installed in the parking space detecting that the magnetic field has returned to a vehicle-free state, or video capture equipment recognizing that the vehicle has completely moved out of the detection area boundary. Once it is confirmed that the vehicle has left, the processing unit can determine that it is no longer necessary to keep the parking lock in place, thereby triggering an interception command.

[0082] Another scenario is when a vehicle fails to enter a parking space within a preset timeframe. In actual traffic, after the parking space lock engages, a vehicle may fail to enter the space promptly for various reasons, such as the driver needing to get out temporarily, pedestrians crossing behind requiring waiting, or the vehicle's reversing speed being too slow. To allow sufficient buffer time for such situations, a preset timeframe is typically set as a tolerance window. When this preset timeframe expires and the vehicle still hasn't entered the parking space, the processing unit can trigger an interception command. The specific value of the preset timeframe can be set according to on-site traffic conditions and management requirements. For example, in large parking lots, due to wider aisles and larger vehicle turning radii, a longer timeframe can be used; while in compact parking areas, where vehicle speeds are generally slower, a more sufficient buffer time is needed. Therefore, the value of the preset timeframe is not fixed but can be flexibly adjusted based on the size of the detection area, historical statistics of normal vehicle speeds, and the management's balance between safety and efficiency.

[0083] Another scenario is when a vehicle is detected as not meeting the release conditions. This commonly occurs during the continuous operation of the automatic identification device. A vehicle that had previously passed authentication may have its identity information unable to be confirmed again during passage for various reasons. For example, the license plate recognition result may change, or the system may find that the vehicle's actual status no longer matches the release conditions during secondary verification. In this case, the processing unit will also trigger an interception command.

[0084] Another scenario is that the processing end directly receives an interception command from an external device. This external device can be a management terminal, a remote control, or other devices with control permissions. For example, an administrator might actively press the lock button after discovering an anomaly, or the backend system might issue a lock-up command based on a scheduling policy.

[0085] Regardless of which of the above scenarios triggers the interception command, the processing unit will first confirm whether the current vehicle identification has changed before actually executing the locking action, as described above. Only after confirming that the same vehicle is no longer occupying the detection area will the parking lock be allowed to lift. In this way, a unified secondary confirmation barrier is established in the face of various possible interception triggers, ensuring that the interception action is not rashly executed before the vehicle has safely passed through.

[0086] The vehicle management method, device, electronic device, and storage medium provided in this application firstly acquire the vehicle identification within its detection area when the parking lock enters the locked state due to a release command, thereby establishing the real-time identity of the currently passing vehicle; then, by determining whether the vehicle identification has changed, dynamic monitoring is achieved to determine whether the same vehicle is still within the detection area; finally, during the entire period when the vehicle identification has not changed, the parking lock is controlled to always remain in the locked state.

[0087] Through the aforementioned closed-loop control logic, this embodiment of the application can dynamically extend the duration of the locked state based on the persistence determination result of the vehicle identification, rather than relying on a fixed preset time. Compared with the prior art's timed reset locking scheme, this avoids the risk of scratches caused by premature locking due to vehicle passage delays, thus improving the safety and reliability of the passage control process.

[0088] Based on the same technical concept, embodiments of this application also provide a vehicle management device, such as... Figure 3 As shown, the device includes: The acquisition module 301 is used to acquire the vehicle identifier within the detection area corresponding to the parking lock if the parking lock enters the locked state in response to the release command.

[0089] The tracking module 302 is used to determine whether the vehicle identification has changed.

[0090] The control module 303 is used to control the parking space lock to always be in the locked state when there is no change.

[0091] In one feasible implementation, the device further includes: The authentication module is used to perform authentication operations on vehicles located in the detection area before the parking lock enters the locking state in response to the release command.

[0092] The status determination module is used to determine that the parking space lock enters the locked state in response to the release command if the authentication is successful.

[0093] In one feasible implementation, the authentication module is used to perform authentication operations on vehicles located in the detection area, including: Obtain vehicle identification information.

[0094] Determine whether the identity information meets the release conditions.

[0095] If so, authentication is confirmed to be successful, and a release command is sent to the parking space lock.

[0096] In one feasible implementation, the authentication module is used to perform authentication operations on vehicles located in the detection area, including: If the parking lock receives a release instruction forwarded from the parking lock, it is determined that the vehicle authentication has passed; the release instruction is an instruction forwarded by the parking lock after it receives it from the management terminal.

[0097] Alternatively, if a release instruction is received from the management terminal, the vehicle authentication is confirmed to be successful, and the release instruction is forwarded to the parking space lock.

[0098] In one feasible implementation, the acquisition module is used to acquire vehicle identifiers within the detection area corresponding to the parking lock, including: Identify vehicle characteristics of vehicles within the detection area.

[0099] Obtain the vehicle identifier assigned to the vehicle characteristics.

[0100] And / or, use the pre-acquired vehicle identity information as the vehicle identifier.

[0101] In one feasible implementation, the tracking module is used to determine whether the vehicle identification has changed, including: In response to the triggering of the interception command, determine whether the vehicle identifier has changed.

[0102] Controlling the parking space lock to always be in the locked state includes: Send information to the parking lock to prohibit the execution of the interception command and / or continue to execute the release command, so as to control the parking lock to always be in the locked state.

[0103] In a feasible implementation, the interception instruction is triggered, including at least one of the following: The vehicle has been detected leaving the parking space.

[0104] The vehicle was detected as not entering the parking space within a preset time period.

[0105] The vehicle was detected as not meeting the release conditions.

[0106] An interception command was received for the parking space lock.

[0107] The vehicle management method, device, electronic device, and storage medium provided in this application firstly acquire the vehicle identification within its detection area when the parking lock enters the locked state due to a release command, thereby establishing the real-time identity of the currently passing vehicle; then, by determining whether the vehicle identification has changed, dynamic monitoring is achieved to determine whether the same vehicle is still within the detection area; finally, during the entire period when the vehicle identification has not changed, the parking lock is controlled to always remain in the locked state.

[0108] Through the aforementioned closed-loop control logic, this embodiment of the application can dynamically extend the duration of the locked state based on the persistence determination result of the vehicle identification, rather than relying on a fixed preset time. Compared with the prior art's timed reset locking scheme, this avoids the risk of scratches caused by premature locking due to vehicle passage delays, thus improving the safety and reliability of the passage control process.

[0109] Figure 4 A schematic diagram of an electronic device provided in this application embodiment includes: a processor 401, a storage medium 402, and a bus 403. The storage medium 402 stores machine-readable instructions executable by the processor 401. When the electronic device runs the vehicle management method as described in the embodiment, the processor 401 communicates with the storage medium 402 via the bus 403, and the processor 401 executes the machine-readable instructions to perform the steps as described in the embodiment.

[0110] In this embodiment, the storage medium 402 may also execute other machine-readable instructions to perform other methods as described in the embodiment. For details on the specific execution steps and principles, please refer to the description of the embodiment, which will not be repeated here.

[0111] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to perform the steps as described in the embodiments.

[0112] In this embodiment, the computer program, when run by the processor, can also execute other machine-readable instructions to perform other methods as described in the embodiments. For details on the specific execution steps and principles, please refer to the description of the embodiments, which will not be repeated here.

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

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

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

[0116] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A vehicle management method, characterized in that, The method includes: If the parking lock enters the locked state in response to the release command, the vehicle identifier in the detection area corresponding to the parking lock is obtained; Determine whether the vehicle identification has changed; During periods when no changes occur, the parking space lock is kept in the locked state.

2. The method according to claim 1, characterized in that, Before the parking lock enters the locked state in response to the release command, the method further includes: Perform authentication operations on vehicles located in the detection area; If authentication is successful, the parking space lock is determined to enter the locked state in response to the release command.

3. The method according to claim 2, characterized in that, Perform authentication operations on vehicles located in the detection area, including: Obtain vehicle identification information; Determine whether the identity information meets the release conditions; If so, authentication is confirmed to be successful, and a release command is sent to the parking space lock.

4. The method according to claim 2, characterized in that, Perform authentication operations on vehicles located in the detection area, including: If the parking lock receives a release instruction forwarded by the parking lock, it is determined that the vehicle authentication has passed; the release instruction is an instruction forwarded by the parking lock after it receives it from the management terminal. Alternatively, if a release instruction is received from the management terminal, the vehicle authentication is confirmed to be successful, and the release instruction is forwarded to the parking space lock.

5. The method according to claim 1, characterized in that, Obtain the vehicle identifier within the detection area corresponding to the parking lock, including: Identify vehicle characteristics of vehicles within the detection area; Obtain the vehicle identifier assigned to the vehicle characteristics; And / or, use the pre-acquired vehicle identity information as the vehicle identifier.

6. The method according to claim 1, characterized in that, Determining whether the vehicle identification has changed includes: In response to triggering an interception command, determine whether the vehicle identifier has changed; Controlling the parking space lock to always be in the locked state includes: Send information to the parking lock to prohibit the execution of the interception command and / or continue to execute the release command, so as to control the parking lock to always be in the locked state.

7. The method according to claim 6, characterized in that, The interception command is triggered by at least one of the following: The vehicle was detected leaving the parking space; The vehicle was detected as not entering the parking space within a preset time period; The vehicle was detected as not meeting the release requirements; An interception command was received for the parking space lock.

8. A vehicle management device, characterized in that, The device includes: The acquisition module is used to acquire the vehicle identifier within the detection area corresponding to the parking lock if the parking lock enters the locked state in response to the release command. The tracking module is used to determine whether the vehicle identification has changed; The control module is used to keep the parking space lock in the locked state when no change occurs.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the vehicle management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the vehicle management method as described in any one of claims 1 to 7.

Images