Driving dual-scene perception method and device, vehicle and storage medium

Abstract

This application relates to the field of digital key technology, and particularly to a perception method, device, vehicle, and storage medium for dual driving scenarios. The method includes: generating key information based on terminal instructions from corresponding terminals in different scenarios and synchronizing it to the vehicle; determining a broadcast mode based on the terminal and the current scenario, and controlling the vehicle to parse the key information based on the broadcast mode to obtain a key verification result; determining the actual distance between the terminal and the vehicle based on the received signal strength indication when the key verification result is successful; and generating control instructions for the vehicle based on the terminal, the broadcast mode, and the actual distance. This solves the problems in related technologies, such as lack of differentiated adaptation for passenger and ground staff scenarios, cumbersome interaction processes, slow wake-up responses, lack of hierarchical permission control mechanisms leading to permission conflicts, difficulty in balancing response speed and low power consumption requirements, and inability to meet the requirements of efficient and secure control in multiple scenarios.

Description

Technical Field

[0001] This application relates to the field of digital key technology, and in particular to a perception method, device, vehicle, and storage medium for dual driving scenarios. Background Technology

[0002] In related technologies, a first mapping table of device identifiers and non-contact unlocking / locking start / stop states, and a second mapping table of historical Bluetooth pairing terminal identifiers and pairing information can be retrieved first. Then, the start / stop state of the matching permission is associated with the Bluetooth pairing terminal identifier and the vehicle local configuration is completed. Subsequently, non-contact unlocking / locking actions are executed according to the configuration state. Thus, compliant and efficient vehicle non-contact unlocking / locking control is achieved by relying on permission mapping matching and local configuration management.

[0003] However, the relevant technologies have not been adapted to differentiate between passenger and ground staff scenarios. The interaction process is cumbersome, the wake-up response is slow, and there is a lack of hierarchical permission control mechanism, which can easily lead to permission conflicts. At the same time, it is difficult to balance response speed and low power consumption requirements, and cannot meet the requirements of efficient and safe control in multiple scenarios. Improvements are urgently needed. Summary of the Invention

[0004] This application provides a perception method, device, vehicle, and storage medium for dual driving scenarios to solve the problems in related technologies, such as the lack of differentiated adaptation for passenger and ground staff scenarios, cumbersome interaction process, slow wake-up response, lack of hierarchical permission control mechanism, easy to cause permission conflicts, difficulty in balancing response speed and low power consumption requirements, and inability to meet the requirements of efficient and safe control in multiple scenarios.

[0005] The first aspect of this application provides a vehicle driving dual-scenario perception method, comprising the following steps: generating key information corresponding to the terminal based on terminal instructions of the corresponding terminal in different scenarios, and synchronizing the terminal and the key information to the vehicle; determining the broadcast mode of the vehicle's communication unit based on the type characteristics of the terminal and the current scenario of the vehicle, and controlling the vehicle to parse the key information to obtain the corresponding key verification result based on the broadcast mode; when the key verification result is successful, determining the actual distance between the terminal and the vehicle based on the received signal strength indication; generating control instructions for the vehicle based on the terminal, the broadcast mode, and the actual distance, and controlling the vehicle according to the control instructions.

[0006] Optionally, in one embodiment of this application, determining the broadcast mode of the vehicle's communication unit based on the type characteristics of the terminal and the current scenario of the vehicle includes: acquiring the vehicle's status data; determining a first broadcast parameter of the communication unit based on the terminal and the current scenario; and determining the broadcast mode based on the status data and the first broadcast parameter.

[0007] Optionally, in one embodiment of this application, before generating the control command for the vehicle, the method further includes: obtaining a second broadcast parameter of the communication unit; sending a verification command to the target switching terminal based on the second broadcast parameter; and when the verification command meets a preset verification condition, generating a switching command for the vehicle based on the second broadcast parameter, and controlling the vehicle to switch from the current scene to the target scene corresponding to the switching command.

[0008] Optionally, in one embodiment of this application, before generating the switching instruction for the vehicle, the method further includes: obtaining the priority of the terminal instruction; and prohibiting the generation of the switching instruction if the priority meets a preset priority condition.

[0009] Optionally, in one embodiment of this application, the method further includes: when the key verification result is a verification failure, counting the duration and / or number of verifications of the key information; when the duration is greater than a preset time and / or the number of verifications is greater than a preset number, updating the key information to obtain updated key information.

[0010] Optionally, in one embodiment of this application, generating control commands for the vehicle based on the terminal, the broadcast mode, and the actual distance includes: generating the control commands based on the terminal, the broadcast mode, and the actual distance when the actual distance is less than or equal to a preset distance threshold.

[0011] A second aspect of this application provides a vehicle driving dual-scenario perception device, comprising: a synchronization module, configured to generate key information corresponding to a terminal based on terminal instructions of a terminal corresponding to different scenarios, and synchronize the terminal and the key information to the vehicle; a parsing module, configured to determine the broadcast mode of the vehicle's communication unit based on the type characteristics of the terminal and the current scenario of the vehicle, and control the vehicle to parse the key information to obtain a corresponding key verification result based on the broadcast mode; a determination module, configured to determine the actual distance between the terminal and the vehicle based on a received signal strength indication when the key verification result is successful; and a control module, configured to generate control instructions for the vehicle based on the terminal, the broadcast mode, and the actual distance, and control the vehicle according to the control instructions.

[0012] Optionally, in one embodiment of this application, the parsing module includes: a first acquisition unit, configured to acquire the vehicle's status data; a first determination unit, configured to determine a first broadcast parameter of the communication unit based on the terminal and the current scenario; and a second determination unit, configured to determine the broadcast mode based on the status data and the first broadcast parameter.

[0013] Optionally, in one embodiment of this application, it further includes: a first acquisition module, configured to acquire a second broadcast parameter of the communication unit before generating a control command for the vehicle; a sending module, configured to send a verification command to a target switching terminal based on the second broadcast parameter; and a switching module, configured to generate a switching command for the vehicle based on the second broadcast parameter when the verification command meets preset verification conditions, and control the vehicle to switch from the current scene to the target scene corresponding to the switching command.

[0014] Optionally, in one embodiment of this application, it further includes: a second acquisition module, configured to acquire the priority of the terminal instruction before generating the switching instruction for the vehicle; and a generation module, configured to prohibit the generation of the switching instruction if the priority meets a preset priority condition.

[0015] Optionally, in one embodiment of this application, it further includes: a statistics module, used to count the duration and / or number of verifications of the key information when the key verification result is a verification failure; and an update module, used to update the key information when the duration is greater than a preset time and / or the number of verifications is greater than a preset number, to obtain updated key information.

[0016] Optionally, in one embodiment of this application, the control module includes: a generation unit, configured to generate the control command based on the terminal, the broadcast mode, and the actual distance when the actual distance is less than or equal to a preset distance threshold.

[0017] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle driving dual-scene perception method as described in the above embodiments.

[0018] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described vehicle driving dual-scenario perception method.

[0019] A fifth aspect of this application provides a computer program product, including a computer program that, when executed, implements the above-described vehicle driving dual-scenario perception method.

[0020] This application embodiment can generate key information corresponding to the terminal based on the terminal instructions of the corresponding terminal in different scenarios, and synchronize the terminal and key information to the vehicle, thereby determining the broadcast mode of the vehicle's communication unit, and then detecting the key verification result of the key information. When the key verification result is successful, the actual distance between the terminal and the vehicle is determined, thereby determining the vehicle control command and completing the vehicle control. Through scenario-driven key generation and adaptive matching of broadcast mode, while ensuring that the terminal identity is verified by key verification and near-field dual authentication by received signal strength indication, precise hierarchical control of permissions in multiple scenarios is achieved. This ensures security while taking into account response speed and low power consumption requirements, and effectively avoids permission conflicts. Thus, it solves the problems in related technologies, such as the lack of differentiated adaptation for passenger and ground staff scenarios, cumbersome interaction process, slow wake-up response, lack of hierarchical control mechanism, easy to cause permission conflicts, difficulty in balancing response speed and low power consumption requirements, and inability to meet the requirements of efficient and secure control in multiple scenarios.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a vehicle driving dual-scenario perception method provided according to an embodiment of this application; Figure 2 A flowchart illustrating the working principle of a vehicle driving dual-scenario perception method according to an embodiment of this application; Figure 3 This is a block diagram of a vehicle driving dual-scenario perception device provided according to an embodiment of this application; Figure 4 This is a structural schematic diagram of a vehicle provided according to an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] The following description, with reference to the accompanying drawings, illustrates a method, apparatus, vehicle, and storage medium for perceiving dual driving scenarios according to embodiments of this application. Addressing the issues mentioned in the background art, such as the lack of differentiated adaptation for passenger and ground service scenarios, cumbersome interaction processes, slow wake-up responses, and the absence of a hierarchical permission control mechanism leading to permission conflicts, while simultaneously struggling to balance response speed and low power consumption, thus failing to meet the requirements for efficient and safe control in multiple scenarios, this application provides a method for perceiving dual driving scenarios. In this method, key information corresponding to the terminal is generated based on the terminal instructions of the corresponding terminal in different scenarios. The terminal and key information are then synchronized to the vehicle to determine the broadcast mode of the vehicle's communication unit. The key verification result of the key information is then detected. If the key verification result is successful, the actual distance between the terminal and the vehicle is determined, thereby determining the vehicle's control instructions and completing vehicle control. Through scenario-driven key generation and adaptive matching of the broadcast mode, while ensuring that the terminal identity is verified by key verification and near-field dual authentication by received signal strength indication, precise hierarchical permission control in multiple scenarios is achieved. This ensures security while balancing response speed and low power consumption, and effectively avoids permission conflicts. This solves the problems in related technologies, such as the lack of differentiated adaptation for passenger and ground staff scenarios, cumbersome interaction processes, slow wake-up response, lack of hierarchical permission control mechanism, easy to cause permission conflicts, difficulty in balancing response speed and low power consumption requirements, and inability to meet the requirements of efficient and safe control in multiple scenarios.

[0025] Specifically, Figure 1 This is a flowchart of a vehicle driving dual-scenario perception method provided according to an embodiment of this application.

[0026] like Figure 1 As shown, the perception method for dual driving scenarios of this vehicle includes the following steps: In step S101, based on the terminal instructions of the corresponding terminal in different scenarios, key information corresponding to the terminal is generated, and the terminal and key information are synchronized to the vehicle.

[0027] It is understood that, in the embodiments of this application, the scenarios may include, but are not limited to, passenger scenarios, ground maintenance scenarios, etc.; the terminals may include, but are not limited to, passenger terminals, such as passenger mobile APP (Application), integrating a Bluetooth communication module (supporting BLE (Bluetooth Low Energy) 5.3), a GPS (Global Positioning System) positioning module, and a TEE (Trusted Execution Environment) security zone to realize automatic key application, near-field wake-up, and contactless unlocking, etc., and this application does not impose specific limitations; ground service terminals, such as ground service APP or tablets with NFC (Near Field Communication), integrating a Bluetooth module and an operation and maintenance APP, supporting permission application, NFC secondary authentication, vehicle wake-up and unlocking operations after power failure, etc., and this application does not impose specific limitations; the vehicle can be understood as a Robotaxi (Robot Taxi), and this application does not impose specific limitations.

[0028] As one possible implementation, embodiments of this application can receive terminal instructions sent by corresponding terminals in different scenarios, generate key information uniquely corresponding to the terminal based on the terminal instructions, and simultaneously send the terminal's identification information and key information to the vehicle so that the vehicle can authenticate the terminal based on the key information.

[0029] For example, in combination Figure 2 As shown, in a passenger scenario, such as when a passenger books a Robotaxi for seamless boarding, this embodiment of the application allows the passenger to complete the order booking through a mobile app. After confirming the terminal instruction, the cloud-based order and permission management automatically stores the passenger's identity, vehicle identity, trip validity period (e.g., 9:00-9:30), GPS coordinates of the pick-up and drop-off points, and permission mask based on the Robotaxi order information in the terminal instruction. This information is then synchronized to the key management module. The key management module then generates a time-limited temporary key (containing the vehicle's identity and trip validity period) using an encryption algorithm (e.g., AES (Advanced Encryption Standard)-256 encryption algorithm, which is not specifically limited in this application). This temporary key is then sent to the TEE security area of ​​the passenger terminal. Simultaneously, the key information, such as the hash digest of the temporary key (not the complete key), is synchronized to the vehicle's onboard security chip for subsequent verification. This ensures that the onboard system can recognize the legitimate terminal key and prevents the key from being stolen during transmission. By strongly binding the trip information with the key, the risk of unlocking during unauthorized periods or to untarget vehicles is eliminated.

[0030] In addition, in ground maintenance scenarios, such as Robotaxi cleaning and maintenance scenarios when the vehicle is powered off, ground staff obtain the vehicle's identification via an NFC-enabled ground staff app and submit a terminal instruction for cleaning as the maintenance type, with an estimated duration of 30 minutes. The ground staff app automatically attaches the ground staff's identification (such as employee ID and role) and uploads it to the cloud layer. The cloud layer's order and permission management verifies the ground staff's identification and, if the role is identified as a cleaning staff member, configures the permission level as Level 1 with a validity period of 45 minutes (including 15 minutes of redundancy) and generates a permission token. Then, the key management module generates a temporary key (including permission level, validity parameters, and operation scope) based on the permission token and sends it to the ground staff terminal. At the same time, the digest of the temporary key is synchronized to the vehicle's security chip, achieving precise matching of permissions with maintenance needs, avoiding over-authorization, and reducing the risk of permission abuse through time limits.

[0031] It should be noted that the maintenance types in this application embodiment may include, but are not limited to, cleaning, inspection, and debugging types; the permission levels are divided into three levels, which may include, but are not limited to, Level 1 permission (only door unlocking), unlocking all doors; Level 2 permission (device operation), access to all doors and specific devices; and Level 3 permission (system access), access to the entire system. This application does not impose specific restrictions, and then executes the corresponding unlocking range based on the permission level, and records the operation log and synchronizes it to the cloud layer; the validity period can be set to a dynamic validity period of 15 minutes to 2 hours. If no operation is performed within the time limit or after maintenance is completed, the permission will be automatically revoked and the device will be locked.

[0032] In step S102, based on the terminal type characteristics and the current scenario of the vehicle, the broadcast mode of the vehicle's communication unit is determined, and based on the broadcast mode, the vehicle is controlled to parse the key information to obtain the corresponding key verification result.

[0033] It is understood that, in the embodiments of this application, the broadcast mode may include, but is not limited to, a high-frequency low-latency mode, such as a broadcast interval of 50ms and a 20% increase in transmission power; a stable mode, such as a broadcast interval of 100ms; and a low-power standby mode, such as a broadcast interval of 500ms and a 50% reduction in transmission power. Furthermore, in the embodiments of this application, when the current scenario is a passenger scenario, the corresponding broadcast mode is a high-frequency low-latency mode; and when the current scenario is a ground maintenance scenario, the corresponding broadcast mode is a low-power standby mode.

[0034] In some embodiments, this application can first identify the type characteristics of the terminal, such as a passenger terminal or a ground service terminal, and the current scenario of the vehicle, such as a scenario where a passenger has booked a Robotaxi for seamless boarding and Robotaxi cleaning and maintenance in a power-off state. Then, it matches and determines the broadcast mode of the vehicle's communication unit. In the broadcast mode, it controls the vehicle to decrypt and parse the key information to obtain the key verification result. The communication unit can be understood as a BCU (Bluetooth Control Unit).

[0035] For example, in a passenger scenario, when the passenger terminal approaches the vehicle and the actual distance between the passenger terminal and the vehicle is ≤10 meters, the passenger terminal activates GPS positioning verification and matches it with the GPS coordinates of the boarding and alighting points. This automatically activates the BCU to switch the broadcast mode to a high-frequency, low-latency mode, i.e., the broadcast interval is shortened from the default 100ms to 50ms and the transmission power is increased by 20% (to ensure signal penetration). In addition, when the vehicle is in a power-on standby state (i.e., not powered off), the BCU continuously scans for surrounding Bluetooth signals. When it detects the key information (including key digest) sent by the passenger terminal through encrypted broadcast, it actively initiates a connection request while using dynamic broadcast adjustment, increasing the transmission power when approaching, shortening the connection establishment time, and ensuring a rapid response when approaching.

[0036] Furthermore, in this embodiment of the application, after the passenger terminal establishes a Bluetooth connection with the BCU, two-way authentication can be performed: the passenger terminal sends an encrypted temporary key, the BCU parses the key information, verifies the validity and expiration of the key through the vehicle security chip, and obtains the corresponding key verification result; at the same time, the BCU sends the vehicle's identity identifier to the passenger terminal, and the passenger terminal verifies the match with the order.

[0037] In addition, in ground support scenarios, when the vehicle is powered off, the BCU automatically switches to a low-power standby mode, i.e., the broadcast interval is adjusted to 500ms and the transmission power is reduced by 50% (static power consumption ≤10mA), only responding to broadcast signals containing the authorization token prefix; when the ground support terminal is close to the vehicle and the actual distance between the ground support terminal and the vehicle is ≤3 meters, clicking "Wake up the vehicle" in the NFC-enabled ground support APP will send an encrypted broadcast containing the authorization token; after receiving the matching broadcast signal, the BCU wakes up from the low-power standby mode, starts the Bluetooth connection, and simultaneously sends a "low-power standby mode wake-up command" to the BCM (Body Control Module) via the CAN (Controller Area Network) bus (only activating the door control-related circuits, without starting the vehicle power); after being woken up, the BCM reports "standby status" to the BCU. The entire wake-up process takes ≤3 seconds, solving the problems of slow wake-up and high power consumption of powered-off vehicles, balancing response speed and energy consumption.

[0038] Furthermore, in this embodiment of the application, after the ground support terminal establishes a connection with the BCU, the ground support personnel complete secondary identity authentication by bringing their NFC badge close to the vehicle's NFC module (to prevent the terminal from being stolen), and upload the key information and NFC authentication result to the security chip for verification. After confirming the permission level and validity period, the corresponding key verification result is obtained.

[0039] Optionally, in one embodiment of this application, determining the broadcast mode of the vehicle's communication unit based on the terminal's type characteristics and the vehicle's current scenario includes: acquiring vehicle status data; determining a first broadcast parameter of the communication unit based on the terminal and the current scenario; and determining the broadcast mode based on the status data and the first broadcast parameter.

[0040] It is understood that, in the embodiments of this application, the first broadcast parameter may include, but is not limited to, broadcast interval, transmission power, etc.; the status data may include, but is not limited to, power-off state and non-power-off state, such as power-on standby state, etc., and this application does not impose specific limitations.

[0041] In some embodiments, the present application embodiments can acquire vehicle status data and adaptively determine the first broadcast parameters of the communication unit for the terminal and the current scenario, and then output the broadcast mode of the communication unit based on the joint decision of the status data and the first broadcast parameters.

[0042] It should be noted that the embodiments of this application can automatically identify the current scene of the vehicle based on status data and the type characteristics of the terminal, such as passenger terminal and ground service terminal.

[0043] In step S103, when the key verification result is successful, the actual distance between the terminal and the vehicle is determined based on the received signal strength indication.

[0044] It is understood that, in the embodiments of this application, the Received Signal Strength Indication (RSSI) can be understood as the signal power strength value detected by the communication unit when receiving wireless signals. It is a core basic parameter for wireless ranging and location determination. The value directly reflects the distance of the signal and the degree of signal attenuation. The smaller the value, the weaker the signal. For example, when the RSSI is -30dBm, it means that the signal is extremely strong and the actual distance between the terminal and the vehicle is very close, about 1 meter; when the RSSI is -50dBm, it means that the signal is moderate and the actual distance between the terminal and the vehicle is relatively close, about 3 meters; when the RSSI is -80dBm, it means that the signal is very weak and the actual distance between the terminal and the vehicle is relatively far, about 10 meters.

[0045] In some embodiments, this application can calculate the actual distance between the terminal and the vehicle based on the received signal strength indicator when the key verification result is successful. The formula for calculating the actual distance can be, but is not limited to, expressed as: , in, The distance between the terminal and the vehicle is the actual distance; the applicable distance measurement range is 1-5 meters. The RSSI value (in dBm) is located at a distance of 1 meter. This is the environmental path attenuation factor, with a value range of 2-4.

[0046] For example, in a passenger scenario, after the key verification result is successful, the BCU calculates the actual distance between the passenger terminal and the vehicle based on RSSI.

[0047] Optionally, in one embodiment of this application, the method further includes: when the key verification result is a verification failure, counting the duration of the key information and / or the number of verifications; when the duration is greater than a preset time and / or the number of verifications is greater than a preset number, updating the key information to obtain the updated key information.

[0048] In some embodiments, when the key verification result is a verification failure, the duration of the key information can be counted, and if the duration exceeds a preset time, the key information can be updated to obtain updated key information. The preset time can be set by those skilled in the art according to actual conditions, and this application does not impose specific limitations.

[0049] In some embodiments, when the key verification result is a verification failure, the present application can count the number of verification attempts of the key information, and update the key information when the number of verification attempts exceeds a preset number, thereby obtaining updated key information. The preset number of attempts can be set by those skilled in the art according to actual circumstances, and the present application does not impose specific limitations.

[0050] In some embodiments, when the key verification result is a verification failure, the duration of the key information and the number of key verifications are counted respectively. When the duration is greater than a preset time and the number of verifications is greater than a preset number, the key information is updated to obtain the updated key information.

[0051] Optionally, in one embodiment of this application, before generating the vehicle switching command, the method further includes: obtaining the priority of the terminal command; and prohibiting the generation of the switching command if the priority meets a preset priority condition.

[0052] It is understood that the terminal instructions in the embodiments of this application may include, but are not limited to, ground emergency maintenance (such as fault repair) instructions, ground non-emergency maintenance (such as cleaning) instructions, passenger usage instructions, etc., wherein the priority of ground emergency maintenance instructions is higher than the priority of passenger usage instructions, and the priority of passenger usage instructions is higher than the priority of ground non-emergency maintenance instructions. The specific settings can be made by those skilled in the art according to the actual situation, and this application does not impose specific limitations.

[0053] In some embodiments, the priorities of terminal instructions can be obtained first, and if the priorities meet preset priority conditions, the generation of switching instructions can be prohibited. The preset priority conditions can be set by those skilled in the art according to actual circumstances, and this application does not impose specific limitations.

[0054] For example, in this embodiment, when ground staff initiates an emergency maintenance request and generates an emergency maintenance instruction, a "Vehicle requires emergency maintenance" notification is pushed to the passenger terminal. At the same time, the validity of the passenger key is suspended. After receiving the unlock instruction from the ground staff, the BCU executes the operation, and the passenger's permissions are restored after the maintenance is completed. When ground staff submits a cleaning request and generates a non-emergency maintenance instruction, a "Do you allow temporary maintenance?" confirmation box is first pushed to the passenger terminal. If the passenger agrees, their permissions are suspended, and the ground staff can then unlock the vehicle. If the passenger refuses, the ground staff is notified that "the maintenance time needs to be adjusted." This priority and user confirmation mechanism completely resolves the conflict between permissions in two scenarios, balancing the travel experience and maintenance needs. In addition, all permission switching operations in this embodiment are recorded in the cloud audit log (retained for 3 years) for traceability.

[0055] Optionally, in one embodiment of this application, before generating the vehicle control command, the method further includes: obtaining a second broadcast parameter of the communication unit; sending a verification command to the target switching terminal based on the second broadcast parameter; and when the verification command meets the preset verification conditions, generating a vehicle switching command based on the second broadcast parameter, and controlling the vehicle to switch from the current scene to the target scene corresponding to the switching command.

[0056] It is understood that, in order to achieve seamless switching between passenger scenarios and ground maintenance scenarios, the embodiments of this application can pre-store the second broadcast parameters in the passenger scenario. In this case, the second broadcast parameters can be understood as high-frequency connection parameters, that is, a broadcast interval of 50ms and a transmission power of 120%. In the ground maintenance scenario, the second broadcast parameters can be pre-stored. In this case, the second broadcast parameters can be understood as low-frequency stable connection parameters, that is, a broadcast interval of 100ms and a transmission power of 100%. The specific settings can be made by those skilled in the art according to the actual situation, and this application does not impose any specific limitations.

[0057] In some embodiments, this application can obtain the second broadcast parameters of the communication unit and send a verification command to the target switching terminal based on the second broadcast parameters. Then, when the verification command meets the preset verification conditions, a vehicle switching command is generated based on the second broadcast parameters, thereby controlling the vehicle to switch from the current scene to the target scene corresponding to the switching command. The preset verification conditions can be set by those skilled in the art according to actual conditions, and this application does not impose specific limitations.

[0058] For example, in the embodiments of this application, when switching scenarios, the BCU retains the encryption context of the previous connection, adjusts the broadcast mode based on the second broadcast parameter, and the new connection establishment delay is ≤300ms (such as when a ground staff emergency maintenance command is inserted during a passenger's journey, seamlessly switching from high-frequency low-latency mode to low-power standby mode), avoiding connection interruption during scenario switching and ensuring operational continuity.

[0059] In this embodiment of the application, since the priority of ground staff emergency maintenance instructions is higher than the priority of passenger usage instructions, this embodiment of the application can push notifications to passengers to switch scenarios. However, if switching to ground staff non-emergency maintenance instructions, since the priority of passenger usage instructions is higher than the priority of ground staff non-emergency maintenance instructions, passenger confirmation is required before switching to avoid conflicts.

[0060] In step S104, control commands for the vehicle are generated based on the terminal, broadcast mode, and actual distance, and the vehicle is controlled according to the control commands.

[0061] In some embodiments, the present application can generate vehicle control commands based on the terminal, broadcast mode, and actual distance, and then complete vehicle control based on the control commands.

[0062] Optionally, in one embodiment of this application, generating control commands for the vehicle based on the terminal, broadcast mode, and actual distance includes: generating control commands based on the terminal, broadcast mode, and actual distance when the actual distance is less than or equal to a preset distance threshold.

[0063] In some embodiments, this application can generate vehicle control commands based on the terminal, broadcast mode, and actual distance when the actual distance is less than or equal to a preset distance threshold. The preset distance threshold can be set by those skilled in the art according to actual conditions, and this application does not impose specific limitations.

[0064] For example, in the passenger scenario, the preset distance threshold can be set to 3 meters. When the actual distance is ≤3 meters, the BCU switches the Bluetooth connection to high frequency and low latency mode, sends an unlocking command to the BCM (unlock only the passenger side door), determines the vehicle control command, and controls the BCM to perform the unlocking action, unlocking only the passenger side door to ensure safety. The BCU sends a "successful unlock" message, and the passenger terminal receives the unlocking notification simultaneously. No user operation is required, enabling seamless boarding.

[0065] Furthermore, in this embodiment, after the passenger boards and the vehicle starts (the BCM reports a "power-on" status), the BCU switches the Bluetooth connection to a stable mode to maintain a continuous connection to support temporary operations during driving (such as opening the trunk). At the end of the trip, after the vehicle reaches its destination, the BCU detects the arrival status and starts timing. When the passenger terminal moves more than 5 meters away from the vehicle, the BCU disconnects from the passenger terminal or the vehicle is turned off, triggering the BCM to lock and switching the Bluetooth connection to a low-power standby mode via the BCU. Upon receiving the "trip ended" signal, the cloud-level status synchronization module notifies the key management module to cancel the temporary key, and the key is automatically deleted from the terminal's TEE area. The entire trip is fully automated without user intervention, and permissions are promptly revoked after completion to ensure vehicle safety.

[0066] In addition, in the ground maintenance scenario, this application embodiment can send a "unlock all doors" command to the BCM when the actual distance between the ground terminal and the vehicle is ≤3 meters and the permission level is 1, thus determining the vehicle control command; the BCM executes the unlocking action and reports "unlocking successful", while the BCU records the operation log (such as the identity of the ground staff, unlocking time, permission level, etc.) and uploads it to the cloud layer; the combination of secondary authentication and targeted unlocking further improves the security of maintenance operations.

[0067] It should be noted that, in this embodiment of the application, during the maintenance process, the cloud layer synchronizes the permission expiration every 5 minutes. When the remaining time is ≤5 minutes, the ground terminal pops up a reminder that "permission is about to expire." After the ground staff completes cleaning, they click "Maintenance Complete" in the APP, and the cloud layer immediately notifies the key management module to cancel the temporary key. After receiving the instruction, the BCU controls the BCM to lock. If the ground terminal does not actively submit the permission, the cloud automatically cancels the key after the expiration, the BCU triggers the BCM to lock, and records an "automatic timeout" log. The permission reclamation mechanism ensures that the vehicle is locked in time after maintenance to avoid being in an unlocked state for a long time.

[0068] The working principle of the vehicle driving dual-scenario perception method proposed in this application will be introduced below with reference to a specific embodiment.

[0069] in, Figure 2 This is a flowchart illustrating the working principle of a vehicle driving dual-scenario perception method provided according to an embodiment of this application.

[0070] (1) In terms of architecture, the architecture includes cloud layer, terminal layer and vehicle layer.

[0071] The cloud layer includes order and permission management, key management, and status synchronization modules.

[0072] The order and permission management section stores terminal instructions from passenger terminals, such as passenger identification, vehicle identification, trip validity period (e.g., 9:00-9:30), and GPS coordinates of pick-up and drop-off points; and terminal instructions from ground service terminals, such as maintenance type, ground service personnel identification, estimated duration, permission level, and validity period, enabling the binding of people and vehicles and the configuration of permissions.

[0073] The key management module is used to generate or cancel temporary keys and synchronize them to the terminal layer and the vehicle layer.

[0074] The status synchronization module is used to acquire vehicle status data (power-off state / power-off state), terminal connection status and permission validity in real time, and support scene switching.

[0075] The terminal layer includes passenger terminals and ground service terminals.

[0076] The automotive layer includes the BCU, BCM, and automotive security chip.

[0077] The BCU supports switching between broadcast modes and is responsible for establishing connections with passenger terminals or ground service terminals, parsing keys, and calculating RSSI values.

[0078] The BCM receives commands from the BCU, determines the vehicle's control commands, and executes door unlocking / locking actions according to the control commands, while also providing feedback on the vehicle's status (such as door status and power-off status).

[0079] The vehicle's security chip stores the vehicle's unique identifier and participates in two-way key authentication to prevent signal hijacking.

[0080] (2) An introduction from a theoretical perspective, which may include: Step 1: The cloud layer sends a temporary key to the passenger terminal.

[0081] Interaction content: The cloud layer sends a temporary key linked to the trip to the passenger's mobile app, such as a ride-hailing app.

[0082] Technical details: The key is generated using the AES-256 encryption algorithm and contains encrypted information such as passenger identification, vehicle identification, trip validity period, GPS coordinates of pick-up and drop-off points, and permission mask. It is stored in the secure area of ​​the passenger terminal TEE, and the key validity period is strictly bound to the trip validity period.

[0083] Step S2: Synchronize the temporary key to the BCU from the cloud layer.

[0084] Interaction content: The cloud layer synchronizes the digest information of the temporary key to the BCU.

[0085] Technical details: The key is a hash digest of the synchronization key, not the full key, and the onboard security chip stores the key digest for subsequent verification, ensuring that the onboard system can recognize the legitimate terminal key and preventing the key from being stolen during transmission.

[0086] Step 3: The passenger terminal initiates a Bluetooth connection request to the BCU.

[0087] Interaction content: The passenger's mobile phone initiates a Bluetooth connection request to the BCU.

[0088] Technical details: When a passenger's mobile phone detects that the vehicle is close (≤10 meters away), it automatically triggers a Bluetooth connection request and switches the broadcast mode to a high-frequency, low-latency mode through the BCU, sending an encrypted broadcast signal containing a key digest. At the same time, dynamic power adjustment is used to increase the transmission power when the vehicle is close.

[0089] Step 4: After successful verification by the BCU, an unlock command is sent to the BCM.

[0090] Interaction content: After successful verification by BCU, an unlock command is sent to BCM.

[0091] Technical details: After completing the key validity verification (if the key verification result is successful) and RSSI distance verification (if the actual distance is ≤3 meters), unlocking is performed, but only the passenger side door is unlocked to ensure security.

[0092] Step 5: The BCM performs the unlocking action and sends feedback to the passenger terminal.

[0093] Interaction content: The BCM performs the unlocking action and sends the result back to the passenger's mobile phone.

[0094] Technical details: When the BCM receives the instruction, it controls the door lock motor to unlock the door and notifies the passenger's mobile app of the unlock status. The mobile app displays that the unlock is complete, enabling users to board the vehicle without any notice.

[0095] Step 6: The cloud layer assigns maintenance permissions based on the permission level of the ground terminal.

[0096] Interaction content: The cloud layer assigns corresponding permission levels based on the terminal instructions of the ground support terminal.

[0097] Technical details: The permission level is divided into three levels, and the validity period can be dynamically set from 15 minutes to 2 hours according to the maintenance type. The permission token is generated and encrypted before being sent to the ground terminal.

[0098] Step 7: The ground terminal switches the broadcast mode to low-power standby mode via the BCU.

[0099] Interaction content: The ground terminal wakes up the vehicle system, which is in low-power standby mode, through the BCU.

[0100] Technical details: When the vehicle is powered off, the BCU wakes up from the low-power standby mode with a response time of ≤3 seconds, and the ground terminal sends a special broadcast signal containing an authorization token to activate only the door control-related circuits without starting the vehicle power supply.

[0101] Step 8: BCU performs permission verification with the cloud layer.

[0102] Interaction content: BCU verifies the validity of ground crew permissions with the cloud layer.

[0103] Technical details: The BCU uploads the received permission token to the cloud layer for verification. The cloud layer checks the permission level, validity period, and usage status, and returns the verification result, such as valid / expired / insufficient permissions. At the same time, it records the verification log for audit trail.

[0104] Step 9: The BCU sends a targeted unlock command to the BCM.

[0105] Interaction content: After successful permission verification, BCU sends a targeted unlock command to BCM.

[0106] Technical details: The unlocking scope is determined based on the permission level, and operation logs are recorded and synchronized to the cloud.

[0107] The vehicle driving dual-scenario perception method proposed in this application can generate key information corresponding to the terminal based on the terminal instructions of the corresponding terminal in different scenarios, and synchronize the terminal and key information to the vehicle to determine the broadcast mode of the vehicle's communication unit. Then, it detects the key verification result of the key information, and when the key verification result is successful, it determines the actual distance between the terminal and the vehicle, thereby determining the vehicle's control command and completing vehicle control. Through scenario-driven key generation and adaptive matching of the broadcast mode, while ensuring that the terminal identity is verified by key verification and near-field dual authentication by received signal strength indication, it achieves precise hierarchical control of permissions in multiple scenarios. This ensures security while also considering response speed and low power consumption requirements, and effectively avoids permission conflicts. Therefore, it solves the problems in related technologies, such as the lack of differentiated adaptation for passenger and ground staff scenarios, cumbersome interaction processes, slow wake-up response, lack of hierarchical permission control mechanisms, easy occurrence of permission conflicts, difficulty in balancing response speed and low power consumption requirements, and inability to meet the requirements of efficient and safe control in multiple scenarios.

[0108] Next, referring to the accompanying drawings, a vehicle driving dual-scenario perception device according to an embodiment of this application is described.

[0109] Figure 3 This is a block diagram of a vehicle driving dual-scenario perception device provided according to an embodiment of this application.

[0110] like Figure 3 As shown, the vehicle driving dual-scenario perception device 10 includes: a synchronization module 100, a parsing module 200, a determination module 300, and a control module 400.

[0111] The synchronization module 100 is used to generate key information corresponding to the terminal based on the terminal instructions of the corresponding terminal in different scenarios, and to synchronize the terminal and key information to the vehicle.

[0112] The parsing module 200 is used to determine the broadcast mode of the vehicle's communication unit based on the terminal's type characteristics and the vehicle's current scenario, and based on the broadcast mode, control the vehicle to parse the key information to obtain the corresponding key verification result.

[0113] The determination module 300 is used to determine the actual distance between the terminal and the vehicle based on the received signal strength indication when the key verification result is successful.

[0114] The control module 400 is used to generate control commands for the vehicle based on the terminal, broadcast mode, and actual distance, and to control the vehicle according to the control commands.

[0115] Optionally, in one embodiment of this application, the parsing module 200 includes: a first acquisition unit, a first determination unit, and a second determination unit.

[0116] The first acquisition unit is used to acquire the vehicle's status data.

[0117] The first determining unit is used to determine the first broadcast parameters of the communication unit based on the terminal and the current scenario.

[0118] The second determining unit is used to determine the broadcast mode based on the status data and the first broadcast parameters.

[0119] Optionally, in one embodiment of this application, it further includes: a first acquisition module, a sending module, and a switching module.

[0120] The first acquisition module is used to acquire the second broadcast parameters of the communication unit before generating the control commands for the vehicle.

[0121] The sending module is used to send a verification command to the target switching terminal based on the second broadcast parameters.

[0122] The switching module is used to generate a vehicle switching command based on the second broadcast parameters when the verification command meets the preset verification conditions, and to control the vehicle to switch from the current scene to the target scene corresponding to the switching command.

[0123] Optionally, in one embodiment of this application, it further includes a second acquisition module and a generation module.

[0124] The second acquisition module is used to acquire the priority of the terminal instruction before generating the vehicle switching instruction.

[0125] The generation module is used to prevent the generation of switching instructions when the priority meets the preset priority conditions.

[0126] Optionally, in one embodiment of this application, it further includes a statistics module and an update module.

[0127] The statistics module is used to count the duration and / or number of verifications of the key information when the key verification result is a verification failure.

[0128] The update module is used to update the key information and obtain the updated key information when the duration is greater than a preset time and / or the number of verifications is greater than a preset number.

[0129] Optionally, in one embodiment of this application, the control module 400 includes a generation unit.

[0130] The generation unit is used to generate control commands based on the terminal, broadcast mode, and actual distance when the actual distance is less than or equal to a preset distance threshold.

[0131] It should be noted that the explanation of the above-mentioned method for perceiving dual driving scenarios also applies to the perception device for dual driving scenarios in this embodiment, and will not be repeated here.

[0132] The vehicle driving dual-scenario perception device proposed in this application can generate key information corresponding to the terminal based on the terminal instructions of the corresponding terminal in different scenarios, and synchronize the terminal and key information to the vehicle, thereby determining the broadcast mode of the vehicle's communication unit, detecting the key verification result of the key information, and determining the vehicle control command based on the actual distance between the terminal and the vehicle when the key verification result is successful, thus completing the vehicle control. Through scenario-driven key generation and adaptive matching of broadcast mode, while ensuring that the terminal identity is verified by key verification and near-field dual authentication by received signal strength indication, precise hierarchical control of permissions in multiple scenarios is achieved. This ensures security while taking into account response speed and low power consumption requirements, and effectively avoids permission conflicts. Thus, it solves the problems in related technologies, such as the lack of differentiated adaptation for passenger and ground staff scenarios, cumbersome interaction process, slow wake-up response, lack of hierarchical control mechanism, easy to cause permission conflicts, difficulty in balancing response speed and low power consumption requirements, and inability to meet the requirements of efficient and safe control in multiple scenarios.

[0133] Figure 4 This is a schematic diagram of the structure of a vehicle according to an embodiment of this application. The vehicle may include: The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.

[0134] When the processor 402 executes the program, it implements the vehicle driving dual-scene perception method provided in the above embodiments.

[0135] Furthermore, the vehicle also includes: Communication interface 403 is used for communication between memory 401 and processor 402.

[0136] The memory 401 is used to store computer programs that can run on the processor 402.

[0137] Memory 401 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0138] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized into address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0139] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0140] Processor 402 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0141] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described vehicle driving dual-scene perception method.

[0142] This application also provides a computer program product, including a computer program that, when executed, implements the above-described vehicle driving dual-scenario perception method.

[0143] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0144] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0145] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0146] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). In addition, the computer-readable medium can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting or otherwise processing as necessary, and then stored in computer memory.

[0147] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or more of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0148] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0149] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0150] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for perceiving dual driving scenarios in a vehicle, characterized in that, Includes the following steps: Based on the terminal instructions of the corresponding terminal in different scenarios, generate key information corresponding to the terminal, and synchronize the terminal and the key information to the vehicle; Based on the type characteristics of the terminal and the current scenario of the vehicle, the broadcast mode of the vehicle's communication unit is determined, and based on the broadcast mode, the vehicle is controlled to parse the key information to obtain the corresponding key verification result; When the key verification result is successful, the actual distance between the terminal and the vehicle is determined based on the received signal strength indication; Based on the terminal, the broadcast mode, and the actual distance, control commands for the vehicle are generated, and the vehicle is controlled according to the control commands.

2. The method according to claim 1, characterized in that, Determining the broadcast mode of the vehicle's communication unit based on the terminal's type characteristics and the vehicle's current scenario includes: Obtain the status data of the vehicle; Based on the terminal and the current scenario, the first broadcast parameters of the communication unit are determined; The broadcast mode is determined based on the status data and the first broadcast parameters.

3. The method according to claim 2, characterized in that, Before generating the control commands for the vehicle, the following are also included: Obtain the second broadcast parameters of the communication unit; Based on the second broadcast parameters, a verification command is sent to the target switching terminal; When the verification command meets the preset verification conditions, a switching command for the vehicle is generated based on the second broadcast parameters, and the vehicle is controlled to switch from the current scene to the target scene corresponding to the switching command.

4. The method according to claim 3, characterized in that, Before generating the switching command for the vehicle, the following is also included: Obtain the priority of the terminal command; If the priority meets the preset priority conditions, the generation of the switching instruction is prohibited.

5. The method according to claim 1, characterized in that, Also includes: When the key verification result is a verification failure, the duration and / or number of verifications of the key information are recorded. When the duration exceeds a preset time and / or the number of verifications exceeds a preset number, the key information is updated to obtain the updated key information.

6. The method according to claim 1, characterized in that, The process of generating control commands for the vehicle based on the terminal, the broadcast mode, and the actual distance includes: When the actual distance is less than or equal to a preset distance threshold, the control command is generated based on the terminal, the broadcast mode, and the actual distance.

7. A vehicle driving dual-scenario sensing device, characterized in that, include: The synchronization module is used to generate key information corresponding to the terminal based on the terminal instructions of the corresponding terminal in different scenarios, and to synchronize the terminal and the key information to the vehicle. The parsing module is used to determine the broadcast mode of the vehicle's communication unit based on the type characteristics of the terminal and the current scenario of the vehicle, and control the vehicle to parse the key information based on the broadcast mode to obtain the corresponding key verification result; The determination module is used to determine the actual distance between the terminal and the vehicle based on the received signal strength indication when the key verification result is successful. The control module is used to generate control commands for the vehicle based on the terminal, the broadcast mode, and the actual distance, and to control the vehicle according to the control commands.

8. The apparatus according to claim 7, characterized in that, The parsing module includes: The first acquisition unit is used to acquire the status data of the vehicle; The first determining unit is configured to determine the first broadcast parameters of the communication unit based on the terminal and the current scenario; The second determining unit is used to determine the broadcast mode based on the status data and the first broadcast parameters.

9. A vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the vehicle driving dual-scenario perception method as described in any one of claims 1-6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the vehicle driving dual-scenario perception method as described in any one of claims 1-6.

Images