Vehicle door handle communication method, door handle, and vehicle

Abstract

This application provides a vehicle door handle communication method, a door handle, and a vehicle. The method, applied in the field of vehicle electronic control technology, includes: responding to a door handle interaction signal from the vehicle by acquiring a master node scheduling frame of a target bus; parsing the master node scheduling frame, and generating a scheduling request frame corresponding to the door handle interaction signal if no preset slave node identifier is found in the parsing result; and sending the scheduling request frame to the target bus to update the door handle node to the current scheduling table based on the scheduling request frame. Thus, by having the door handle actively listen to the bus scheduling frame and proactively send a scheduling request when it detects that it has been missed in scheduling, this solves the problem in related technologies where the door handle cannot send a heartbeat signal due to scheduling table anomalies, resulting in the door handle's inability to respond and autonomously resume normal communication. This enables the door handle to autonomously perceive, proactively request, and automatically recover from scheduling omissions, improving the reliability of the keyless entry system and the user experience.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic control technology, and more specifically, to a vehicle door handle communication method, door handle, and vehicle in the field of vehicle electronic control technology. Background Technology

[0002] With the increasing popularity of smart vehicles and keyless entry systems, the door handle, as a core node for user interaction with the vehicle, directly impacts user experience due to its responsiveness and reliability. The LIN (Local Interconnect Network) bus, with its advantages of low cost, low speed, and simple master-slave architecture, is widely used for communication between door handles and the body control module.

[0003] In related technologies, the communication status is determined by monitoring the heartbeat frames of the door handle module through the BCM (Body Control Module). That is, the door handle sends heartbeat signals periodically. If the BCM does not receive a heartbeat within a preset time, it determines that the communication is abnormal and attempts to reset the bus or the door handle module.

[0004] However, this method is difficult to effectively deal with scenarios where the door handle is unable to send heartbeat signals due to an abnormality in the target bus scheduler, resulting in the door handle still being unable to respond and unable to autonomously resume normal communication, which urgently needs to be solved. Summary of the Invention

[0005] This application provides a vehicle door handle communication method, a door handle, and a vehicle. The method enables the door handle to actively listen to the bus scheduling frame and actively send a scheduling request when it detects that it has been missed in the scheduling process. This solves the problem in related technologies where the door handle cannot send a heartbeat signal due to an abnormality in the target bus scheduling table, resulting in the door handle being unable to respond and unable to autonomously resume normal communication. This method enables the door handle to autonomously perceive, actively request, and automatically recover from the missing scheduling, thereby improving the reliability of the keyless entry system and the user experience.

[0006] In a first aspect, a vehicle door handle communication method is provided, the method comprising: in response to a door handle interaction signal of a vehicle, acquiring a master node scheduling frame of a target bus; parsing the master node scheduling frame, and generating a scheduling request frame corresponding to the door handle interaction signal if no preset slave node identifier is found in the parsing result; and sending the scheduling request frame to the target bus to update the door handle node to the current scheduling table based on the scheduling request frame.

[0007] Through the above technical solution, scheduling and listening are initiated only in response to door handle interaction signals, avoiding the door handle module's long-term meaningless listening to the bus and reducing system static power consumption. Secondly, by actively parsing the master node scheduling frame for its own preset slave node identifier, the door handle gains the ability to sense whether it has been included in the scheduling process, transforming from passive waiting to active listening. Finally, when the parsing result does not contain the preset slave node identifier, a scheduling request frame is actively generated and sent to update the door handle node in the current scheduling table, achieving a complete closed loop from fault detection to fault repair. This solves the problem in related technologies where the door handle cannot send heartbeat signals due to an abnormal target bus scheduling table, resulting in the door handle's inability to respond and autonomously resume normal communication, achieving low-power, high-reliability, and self-healing door handle communication assurance.

[0008] In conjunction with the first aspect, in some possible implementations, before generating the scheduling request frame corresponding to the door handle interaction signal, the method further includes: obtaining a first cumulative number of times that the preset slave node identifier does not exist in the parsing result; if the first cumulative number is greater than a first preset number, determining that the current scheduling table is abnormal, so as to generate the scheduling request frame corresponding to the door handle interaction signal.

[0009] The above technical solution achieves the following: First, before generating a scheduling request frame, the cumulative number of times the preset slave node identifier is absent from the parsing results is obtained, avoiding accidental triggering of scheduling requests due to occasional communication jitter or momentary interference. Second, a scheduling request frame is only generated when the cumulative number exceeds a first preset number, introducing a multiple-missing-confirmation mechanism to improve the accuracy and robustness of scheduling anomaly detection. This mechanism effectively prevents invalid scheduling requests caused by momentary bus interference or parsing errors, reducing unnecessary bus communication overhead. While ensuring timely fault response, it significantly reduces the false positive rate and the occupation of bus resources by invalid requests.

[0010] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, before sending the scheduling request frame to the target bus, the method further includes: acquiring the door handle voltage, door handle controller operating status, and door handle communication status of the vehicle; determining whether the door handle voltage is greater than a preset voltage, whether the door handle controller operating status is in normal operation, and whether the door handle communication status is in normal communication; if the door handle voltage is greater than the preset voltage, the door handle controller operating status is in normal operation, and the door handle communication status is in normal communication, determining that the door handle does not have a hardware fault, and then sending the scheduling request frame to the target bus.

[0011] The above technical solution firstly involves a multi-dimensional comprehensive detection of the door handle's hardware health. Only when all three conditions are met simultaneously—the door handle voltage exceeding a preset voltage, the controller operating normally, and communication functioning correctly—is the door handle deemed to be free of hardware faults and allowed to send a scheduling request frame. By making hardware self-testing a prerequisite for scheduling requests, misjudgments caused by hardware issues such as insufficient power supply to the door handle, controller malfunctions, or damaged communication interfaces are effectively eliminated. This achieves accurate differentiation between scheduling anomalies and hardware faults, avoiding the waste of communication resources caused by continuing to send invalid scheduling requests under hardware fault conditions. It also provides a reliable basis for accurate classification and targeted handling of subsequent fault logs.

[0012] In combination with the first aspect and the above implementation methods, in some possible implementation methods, after determining whether the door handle voltage is greater than a preset voltage, whether the door handle controller is in normal operation, and whether the door handle communication is in normal communication, the method further includes: determining that the door handle is a hardware fault if the door handle voltage is less than or equal to the preset voltage, or the door handle controller is in abnormal operation, or the door handle communication is in abnormal communication.

[0013] Through the above technical solution, if any one of the three detection conditions—door handle voltage, controller operating status, and communication status—is not met, a hardware fault is determined in the door handle, clearly defining the boundary between hardware anomalies and scheduling anomalies. This mechanism enables the door handle module to promptly identify its own fault type when hardware problems such as insufficient power supply, controller crashes, or damaged communication interfaces occur, avoiding misjudging it as a bus scheduling anomaly and making ineffective scheduling recovery attempts. By accurately identifying hardware faults, the system can trigger corresponding degradation processing strategies, thereby preventing power waste or communication conflicts caused by the door handle continuing to perform invalid operations under hardware anomaly conditions. Thus, a clear distinction between scheduling anomalies and hardware faults is achieved, providing an accurate basis for subsequent differentiated processing and improving the maintainability and operational safety of the system.

[0014] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, after sending the scheduling request frame to the target bus, the method further includes: in response to not receiving a scheduling response from the door handle node, obtaining a second cumulative number of times the scheduling request frame was sent to the target bus; if the second cumulative number is greater than or equal to a second preset number, generating a broadcast wake-up signal, wherein the broadcast wake-up signal includes a door handle wake-up identifier; and sending the broadcast wake-up signal to the target bus to update the door handle node to the current scheduling table based on the broadcast wake-up signal.

[0015] Through the above technical solution, firstly, if no scheduling response is received from the door handle node after sending a scheduling request frame, the number of transmissions is accumulated instead of being immediately abandoned after a single failure, thus avoiding misjudgments caused by momentary bus interference or brief busy periods of the master node; secondly, the next-level recovery mechanism is triggered only when the accumulated number of transmissions reaches a second preset threshold, ensuring that the redundant recovery process is only initiated after the scheduling request has indeed failed, avoiding communication redundancy caused by premature intervention; finally, after the request failure reaches the threshold, a broadcast wake-up signal containing the door handle wake-up identifier is generated and sent to the target bus to wake up the master node and force the door handle node to be updated in the current scheduling table. Therefore, this solution provides a redundant recovery path after a scheduling request frame failure, using a broadcast wake-up signal as a second-level recovery method, significantly improving the recovery success rate and system robustness in scheduling anomaly scenarios.

[0016] In combination with the first aspect and the above implementation methods, in some possible implementation methods, after determining that the door handle is a hardware fault, the method further includes: generating a hardware fault log and storing the hardware fault log in a local memory; reporting the hardware fault log to the vehicle controller and controlling the door handle to enter a preset low-power mode until a diagnostic command is received or the vehicle is powered on again.

[0017] The above technical solution achieves several key benefits. First, upon determining that the door handle is faulty due to hardware malfunction, a hardware fault log is generated and stored locally, enabling local retention of fault information and facilitating rapid root cause identification during after-sales diagnosis. Second, the hardware fault log is reported to the vehicle controller, allowing the fault information to be further transmitted to the central gateway or cloud, supporting remote diagnosis and predictive maintenance. Finally, the door handle is controlled to enter a preset low-power mode until a diagnostic command is received or the vehicle is powered on again, preventing continuous battery drain due to abnormal power consumption during a fault and preventing the door handle from attempting invalid communication when hardware malfunctions. This provides dual protection through local recording and remote reporting of hardware faults, while the low-power mode enhances system security and vehicle range, providing reliable data support for subsequent maintenance.

[0018] In combination with the first aspect and the above implementation, in some possible implementations, before obtaining the master node scheduling frame of the target bus in response to the door handle interaction signal of the vehicle, the method further includes: identifying the current state of the target bus; generating a wake-up signal in response to the current state being a sleep state or an idle state; and waking up the target bus based on the wake-up signal.

[0019] The above technical solution addresses several key issues. First, before acquiring the master node's scheduling frame in response to the door handle's interaction signal, the current state of the target bus is identified to determine whether it is in a sleep or idle state, preventing invalid acquisition of the scheduling frame when the bus is not awakened. Second, when the bus is in a sleep or idle state, a wake-up signal is actively generated and used to wake up the target bus, ensuring that the bus is in normal working condition before subsequent communication. Finally, the sequential design of waking up before acquiring the scheduling frame enables the door handle module to establish a reliable communication link with the master node. This solves the problem of the door handle being unable to receive scheduling frames or send requests due to bus sleep or idle states, ensuring that the scheduling monitoring and recovery process can be executed smoothly in the bus active state, thus improving communication success rate and user interaction response speed.

[0020] In combination with the first aspect and the above implementation, in some possible implementations, before obtaining the master node scheduling frame of the target bus in response to the vehicle's door handle interaction signal, the method further includes: obtaining the current perception state of the vehicle's door handle; and determining that the door handle interaction signal exists if the current perception state meets the preset keyless entry conditions.

[0021] The above technical solution achieves several key improvements. First, it acquires the current perception state of the vehicle's door handle before responding to the door handle interaction signal, clarifying that the trigger source of the interaction signal is the user's keyless entry intention. Second, it determines the presence of a door handle interaction signal only when the current perception state meets the preset keyless entry conditions, avoiding accidental door handle activation due to interference signals or accidental touches. Finally, by strongly binding the interaction signal to the actual user intent, the subsequent scheduling, listening, and recovery processes are only initiated when the user genuinely needs to open the door. This effectively prevents the door handle module from performing meaningless scheduling, listening, and request operations triggered by non-user intent, reducing system power consumption while improving the rationality of the interaction logic and the user experience.

[0022] In a second aspect, a vehicle door handle communication device is provided, the device comprising: The acquisition module is used to acquire the master node scheduling frame of the target bus in response to the door handle interaction signal of the vehicle. The processing module is used to parse the master node scheduling frame and, if there is no preset slave node identifier in the parsing result, generate a scheduling request frame corresponding to the door handle interaction signal. An update module is used to send the scheduling request frame to the target bus to update the door handle node to the current scheduling table based on the scheduling request frame.

[0023] In conjunction with the second aspect, in some possible implementations, before generating the scheduling request frame corresponding to the door handle interaction signal, the processing module is further configured to: Obtain the first cumulative count of times that the preset slave node identifier does not exist in the parsing result; If the first accumulated number is greater than the first preset number, it is determined that the current scheduling table is abnormal, and a scheduling request frame corresponding to the door handle interaction signal is generated.

[0024] In conjunction with the second aspect and the above implementation methods, in some possible implementations, before sending the scheduling request frame to the target bus, the update module further includes: The acquisition unit is used to acquire the door handle voltage, door handle controller operating status, and door handle communication status of the vehicle. The judgment unit is used to determine whether the voltage of the door handle is greater than the preset voltage, whether the operating state of the door handle controller is normal operation, and whether the communication state of the door handle is normal communication. The processing unit is configured to determine that there is no hardware fault in the door handle when the door handle voltage is greater than the preset voltage, the door handle controller is in the normal operating state, and the door handle communication state is in the normal communication state, and then send the scheduling request frame to the target bus.

[0025] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, after determining whether the door handle voltage is greater than a preset voltage, whether the door handle controller is in normal operating state, and whether the door handle communication state is in normal communication state, the processing unit is further configured to: If the door handle voltage is less than or equal to a preset voltage, or the door handle controller is in an abnormal operating state, or the door handle communication state is in an abnormal communication state, the door handle is determined to be a hardware fault.

[0026] In conjunction with the second aspect and the above implementation methods, in some possible implementations, after sending the scheduling request frame to the target bus, the processing unit is further configured to: In response to not receiving a scheduling response from the door handle node, obtain a second cumulative number of times the scheduling request frame was sent to the target bus; If the second cumulative count is greater than or equal to the second preset count, a broadcast wake-up signal is generated, wherein the broadcast wake-up signal includes a door handle wake-up identifier; The broadcast wake-up signal is sent to the target bus to update the door handle node to the current scheduling table based on the broadcast wake-up signal.

[0027] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, after determining that the door handle is a hardware failure, the processing unit is further configured to: Generate a hardware fault log and store the hardware fault log in local memory; The hardware fault log is reported to the vehicle controller, and the door handle is controlled to enter a preset low-power mode until a diagnostic command is received or the vehicle is powered on again.

[0028] In conjunction with the second aspect and the above implementation methods, in some possible implementations, before acquiring the master node scheduling frame of the target bus in response to the vehicle's door handle interaction signal, the acquisition module is further configured to: Identify the current state of the target bus; A wake-up signal is generated in response to the current state being either a sleep state or an idle state. The target bus is woken up based on the wake-up signal.

[0029] In conjunction with the second aspect and the above implementation methods, in some possible implementations, before acquiring the master node scheduling frame of the target bus in response to the vehicle's door handle interaction signal, the acquisition module is further configured to: Obtain the current sensing state of the vehicle door handle; If the current sensing state meets the preset keyless entry conditions, it is determined that the door handle interaction signal exists.

[0030] Thirdly, a door handle is provided, including a controller, the controller including 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 door handle communication method of the first aspect or any possible implementation thereof.

[0031] Fourthly, a vehicle is provided that includes the door handle described in the above embodiments.

[0032] Fifthly, a computer program product is provided, comprising: computer program code, which, when executed on a computer, causes the computer to perform the vehicle door handle communication method of the first aspect or any possible implementation thereof.

[0033] In a sixth aspect, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the vehicle door handle communication method of the first aspect or any possible implementation thereof. Attached Figure Description

[0034] Figure 1 A flowchart illustrating the vehicle door handle communication method provided in this application embodiment; Figure 2 A block diagram of a vehicle door handle communication device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the door handle structure according to an embodiment of this application. Detailed Implementation

[0035] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0036] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0037] In related technologies, the body control module (BCM), acting as the LIN master node, uses a fixed-period scheduling table to schedule each slave node. The door handle, as a slave node, only responds when queried by the master node within the scheduling window. When a user touches the door handle, the door handle module passively waits for the master node to schedule it; if the scheduling is normal, it responds with an unlock command; if the scheduling table does not contain the door handle node, the door handle cannot obtain a communication opportunity and appears unresponsive. To address this issue, the BCM can monitor the heartbeat frames of the door handle module to determine the communication status. Specifically, the door handle periodically sends heartbeat signals; if the BCM does not receive a heartbeat within a preset time, it determines that the communication is abnormal and attempts to reset the bus or the door handle module.

[0038] However, the heartbeat frame itself requires scheduling by the LIN master node to be sent. When the scheduling table does not contain the door handle node, the door handle has no chance to send the heartbeat frame. This causes the BCM to be unable to distinguish between the door handle's own failure and the scheduling table not containing the node, which can easily lead to misjudgment. Moreover, the door handle module itself is still in a completely passive state. After a failure occurs, it can only rely on the reset logic on the BCM side, which has low recovery efficiency and limited success rate.

[0039] Based on the above problems, this application proposes a vehicle door handle communication method. By having the door handle actively listen to the bus scheduling frame and actively send a scheduling request when it detects that it has been missed in the scheduling, the method solves the problem in related technologies that the door handle cannot respond and cannot recover autonomously due to the abnormality of the target bus scheduling table. This method enables the door handle to autonomously perceive, actively request, and automatically recover from the missing scheduling, thereby improving the reliability of the keyless entry system and the user experience.

[0040] Figure 1 This is a schematic flowchart of a vehicle door handle communication method provided in an embodiment of this application.

[0041] For example, such as Figure 1 As shown, the communication method via vehicle door handle includes the following steps: In step S101, in response to the door handle interaction signal of the vehicle, the master node scheduling frame of the target bus is acquired.

[0042] It is understood that, in this embodiment, the door handle interaction signal refers to the electrical signal triggered when a user interacts with the door handle, such as a sensing signal generated when the user touches the door handle, pulls the door handle, or approaches the door handle with an authorized key, used to characterize the user's intention to open or unlock the door. The target bus refers to the communication bus connecting the door handle module and the body control module, i.e., the LIN bus, on which the door handle is mounted as a slave node. The master node scheduling frame refers to the communication frame periodically sent by the LIN bus master node (i.e., the body control module) according to a preset scheduling table, used to query or wake up each slave node on the bus. The scheduling frame contains the identifier information of the scheduled slave node.

[0043] In other words, this embodiment of the application can embed a LIN scheduling and perception engine inside the door handle module. This engine can first receive the door handle interaction signal of the vehicle, which is triggered by the user's actual operation, indicating that the user intends to open or unlock the door. In response to the interaction signal, the LIN scheduling and perception engine starts a listening operation on the target bus to obtain the master node scheduling frame on the target bus.

[0044] It should be noted that the LIN scheduling awareness engine only performs listening actions after receiving a clear interaction intent trigger signal, avoiding continuous occupation of bus resources or unnecessary power consumption when there is no user demand. Through this step, the LIN scheduling awareness engine can accurately obtain the scheduling information sent by the master node within the current scheduling cycle, providing the necessary data foundation for subsequent determination of whether the door handle module itself has been included in the scheduling.

[0045] Furthermore, the door handle module has a complete system architecture deployed internally to support scheduling awareness and recovery functions. This mainly includes a LIN transceiver, an MCU (Microcontroller Unit, the LIN scheduling awareness engine being the software logic running within the MCU), a timer and counter module, a LIN frame parsing module, and local Flash memory. The LIN transceiver is responsible for establishing a physical connection with the LIN bus, supporting communication between master and slave nodes. The MCU, as the core processing unit, runs the real-time scheduling awareness logic and manages the local state machine. The timer and counter module is used to accurately measure the period of the master node's scheduling frames, with a measurement accuracy of ±1μs. The LIN frame parsing module is used to parse the scheduling frame header and scheduling table structure sent by the master node. The local Flash memory is used to cache scheduling missing event logs, supporting the recording of up to 20 historical events.

[0046] Furthermore, the door handle module is equipped with a watchdog timer and interrupt priority protection mechanism to ensure the real-time performance and reliability of the LIN scheduling awareness engine. Interrupt priority protection, by setting the master node scheduling frame receive interrupt and timer interrupt to the highest priority, ensures that the LIN scheduling awareness engine can promptly preempt CPU (Central Processing Unit) resources, avoiding being blocked by other tasks and missing the parsing opportunity of critical scheduling frames. The watchdog timer acts as the last line of defense at the hardware level. If the LIN scheduling awareness engine is unable to perform the watchdog feeding operation normally for an extended period due to abnormal conditions, the watchdog timer will time out and automatically reset the MCU, forcing the door handle module to return to its initial state. Working together, interrupt priority protection focuses on preventing blocking to ensure real-time response, while the watchdog timer focuses on preventing deadlock to ensure system recoverability, thereby ensuring that the scheduling detection mechanism can operate stably under any abnormal scenario.

[0047] In step S102, the master node scheduling frame is parsed, and if the preset slave node identifier is not found in the parsing result, a scheduling request frame corresponding to the door handle interaction signal is generated.

[0048] It is understood that, in this embodiment, the preset slave node identifier is the LIN bus identifier (such as 0x3C) used to uniquely identify the door handle node. In LIN bus communication, the master node schedules the corresponding slave node through the identifier. The door handle module determines whether it has been included in the current scheduling by comparing the identifier in the master node's scheduling frame with its own identifier. The scheduling request frame refers to the communication frame actively sent by the door handle module to the LIN bus master node when it detects that it has not been included in the scheduling table. This frame is used to inform the LIN bus master node that the current door handle node has a scheduling need and requests the master node to re-include it in the scheduling table.

[0049] Specifically, the MCU in the door handle module can use the LIN scheduling awareness engine to parse the master node scheduling frame obtained in step S101 and extract the slave node identifier information carried in the scheduling frame. Then, the door handle module can compare the parsed slave node identifier with a preset slave node identifier pre-stored within the door handle module to determine if they match. If a matching identifier exists in the parsing result, the door handle module determines that its own node has been included in the current scheduling by the master node; conversely, if no matching identifier exists in the parsing result, the door handle module determines that its own node has been omitted from the current scheduling table of the LIN bus master node, i.e., the current scheduling table is abnormal. In response to this abnormality, the door handle module controls the LIN scheduling awareness engine to generate a scheduling request frame corresponding to the current door handle interaction signal. This scheduling request frame is used to request the LIN bus master node to re-include the door handle node in the scheduling. Through this step, the door handle module achieves autonomous awareness of its own scheduling status and can proactively generate a recovery request when scheduling is missing.

[0050] In step S103, a scheduling request frame is sent to the target bus to update the door handle node to the current scheduling table based on the scheduling request frame.

[0051] It is understood that, in this embodiment, the current scheduling table is the scheduling table currently being executed by the LIN bus master node. This scheduling table specifies the order and period at which the master node queries the slave nodes on the bus. The scheduling table is stored in the master node's RAM (Random Access Memory) and can be dynamically updated.

[0052] In other words, the LIN scheduling awareness engine can send the scheduling request frame generated in step S102 to the target bus (i.e., the LIN bus). This scheduling request frame can then be transmitted to the LIN bus master node via the target bus. After receiving the scheduling request frame, the LIN bus master node parses it and identifies the scheduling needs of the door handle node. In response to this request, the LIN bus master node can dynamically insert the preset identifier of the door handle node into the current scheduling table, enabling the door handle node to be normally queried by the LIN bus master node in subsequent scheduling cycles. Through this step, the door handle module realizes the transition from sensing scheduling failure to actively requesting recovery, providing a clear trigger signal for the LIN bus master node to update the scheduling table.

[0053] Therefore, by responding to the door handle interaction signal before initiating scheduling listening, the door handle module avoids meaningless long-term bus listening, reducing system static power consumption. By actively parsing the master node scheduling frame for its own preset slave node identifier, the door handle gains the ability to sense whether it has been included in the scheduling, transforming from passive waiting to active listening. When the parsing result does not contain the preset slave node identifier, a scheduling request frame is actively generated and sent to update the door handle node in the current scheduling table, realizing a complete closed loop from fault detection to fault repair. This solves the problem in related technologies where the door handle cannot send heartbeat signals due to an abnormal target bus scheduling table, resulting in the door handle's inability to respond and autonomously resume normal communication, achieving low-power, high-reliability, and self-healing door handle communication assurance.

[0054] Optionally, in some embodiments, before generating the scheduling request frame corresponding to the door handle interaction signal, the method further includes: obtaining a first cumulative number of times that the preset slave node identifier does not exist in the parsing result; if the first cumulative number is greater than a first preset number, determining that the current scheduling table is abnormal, so as to generate the scheduling request frame corresponding to the door handle interaction signal.

[0055] It is understood that in this embodiment, the first cumulative count refers to the cumulative number of times that the preset slave node identifier is not present in the parsing results during multiple consecutive master node scheduling frame parsing processes. This count can be recorded by an internal counter of the door handle module to characterize the duration of scheduling absence. The first preset count is a pre-set threshold number used to determine whether scheduling absence constitutes an anomaly. Only when the cumulative number of absences exceeds this threshold is it considered that the current scheduling table has an anomaly, rather than an occasional transient communication interference. Preferably, in this embodiment, the first preset count can be set to 3 consecutive times.

[0056] To avoid accidental triggering of scheduling requests due to isolated incidents, the door handle module can first accumulate the first number of times a preset slave node identifier is missing from the parsed results before generating a scheduling request frame. Specifically, after parsing each master node scheduling frame, if the door handle module finds that it does not contain the door handle's own preset slave node identifier, it increments its internal counter by one. When this first accumulated count exceeds a first preset count (e.g., three consecutive times), the door handle module can determine that there is indeed an anomaly in the current scheduling table (i.e., a scheduling missing event), rather than a temporary missing event caused by occasional bus interference or momentary communication jitter. Only then does the door handle module generate a scheduling request frame.

[0057] Furthermore, each time a scheduling loss event is triggered, the door handle module can automatically write a structured fault log to the local Flash memory. The log content can include: an event timestamp accurate to 10ms, the vehicle's current status (including whether it is off, charging, and ambient temperature), the number of consecutive times it has not been scheduled, the identifier of the last successfully scheduled frame, whether a scheduling response was successfully received subsequently, and whether the LIN bus master node responded to the scheduling request. The above log can be exported through the vehicle's OBD-II interface (forwarded via a gateway) or Bluetooth debugging interface, allowing relevant personnel to analyze the root cause of the scheduling table loss, thereby achieving accurate reproduction and location of intermittent faults.

[0058] Therefore, by accumulating the number of times the preset slave node identifier is absent from the parsing result before generating the scheduling request frame, the system avoids erroneous scheduling requests due to occasional communication jitter or momentary interference. Only when the accumulated number exceeds a first preset number is the current scheduling table deemed abnormal and a scheduling request frame generated. This multi-missible confirmation mechanism improves the accuracy and robustness of scheduling anomaly detection. This mechanism effectively prevents invalid scheduling requests caused by momentary bus interference or parsing errors, reducing unnecessary bus communication overhead. While ensuring timely fault response, it significantly reduces the false positive rate and the occupation of bus resources by invalid requests.

[0059] Optionally, in some embodiments, before sending the scheduling request frame to the target bus, the method further includes: acquiring the vehicle's door handle voltage, door handle controller operating status, and door handle communication status; determining whether the door handle voltage is greater than a preset voltage, whether the door handle controller operating status is in normal operation, and whether the door handle communication status is in normal communication; if the door handle voltage is greater than the preset voltage, the door handle controller operating status is in normal operation, and the door handle communication status is in normal communication, determining that the door handle does not have a hardware fault, and then sending the scheduling request frame to the target bus.

[0060] It is understood that, in this embodiment, the door handle controller operating state refers to the current operating state of the MCU inside the door handle module, including whether it is operating normally, whether it is in an infinite loop, and whether it is responding to commands. This state can be used to determine whether the microcontroller has software or logic abnormalities. The door handle communication state refers to the current operating state of the wireless communication module (such as Bluetooth or UWB (Ultra-Wideband)) inside the door handle module, which may include whether it can send and receive signals normally and whether it can establish communication with the key device. This state can be used to determine whether there are abnormalities in the wireless communication link. The preset voltage is the minimum voltage threshold (such as 3V) required for the normal operation of the door handle module. When the actual voltage is higher than this threshold, it indicates that the door handle is adequately powered and can support normal communication and processing operations.

[0061] To avoid wasting communication resources by continuing to send invalid scheduling requests while the door handle is in a hardware malfunction state, the door handle module can perform a multi-dimensional comprehensive check of its own hardware health status before sending a scheduling request frame. Specifically, the door handle module can obtain the current power supply voltage (i.e., door handle voltage), the door handle controller's operating status, and the door handle's communication status, and compare them with their respective normal standards: the door handle module determines whether the door handle voltage is greater than a preset voltage (e.g., 3V), whether the door handle controller is in normal operating status, and whether the door handle communication status is normal communication status. Only when all three conditions are met simultaneously can the door handle module determine that it does not have a hardware malfunction, and thus allow the sending of a scheduling request frame to the target bus.

[0062] Therefore, by conducting a comprehensive multi-dimensional test of the door handle's hardware health, the door handle is only deemed to be free of hardware faults and allowed to send scheduling request frames when all three conditions are met simultaneously: the door handle voltage is greater than the preset voltage, the controller is in normal operating condition, and the communication status is normal. By introducing hardware self-test as a prerequisite for scheduling requests, misjudgments caused by hardware problems such as insufficient power supply to the door handle itself, microcontroller crashes, or damaged wireless communication interfaces can be effectively eliminated. This ensures that the scheduling recovery process is initiated only when the door handle hardware is functioning properly, thereby avoiding the waste of communication resources caused by continuing to send invalid scheduling requests under hardware fault conditions and providing a reliable basis for subsequent fault type differentiation.

[0063] Optionally, in some embodiments, after determining whether the door handle voltage is greater than a preset voltage, whether the door handle controller is in normal operation, and whether the door handle communication is in normal communication, the method further includes: determining that the door handle is a hardware fault if the door handle voltage is less than or equal to the preset voltage, or the door handle controller is in abnormal operation, or the door handle communication is in abnormal communication.

[0064] Understandably, in some embodiments, an abnormal operating state refers to a state where the MCU inside the door handle module is not in its expected normal operating mode. Examples include situations such as the MCU entering an infinite loop, program crashing, watchdog timeout failure, or register configuration errors. An abnormal communication state refers to a state where the wireless communication inside the door handle module is not in normal transmit / receive capability. Examples include situations such as Bluetooth or UWB initialization failure, abnormal signal transmission and reception, inability to establish a connection with the key device, or communication timeout.

[0065] In other words, after performing multi-dimensional checks on its own hardware health status, the door handle module can further clarify the boundaries for determining hardware faults. Specifically, when the door handle module detects that the door handle voltage is less than or equal to a preset voltage, or the door handle controller is in an abnormal operating state, or the door handle communication is in an abnormal communication state, the door handle module can determine that it has a hardware fault as long as any of the above three conditions are met.

[0066] By clearly defining the boundary between hardware failures and scheduling anomalies, this embodiment can provide an accurate basis for subsequent differentiated processing, avoiding the continued execution of invalid communication operations under abnormal hardware conditions, and improving the maintainability and operational security of the system.

[0067] Therefore, by detecting three conditions—door handle voltage, controller operating status, and communication status—if any condition is not met, a hardware fault is determined in the door handle, clearly defining the boundary between hardware anomalies and scheduling anomalies. This mechanism enables the door handle module to promptly identify its own fault type when hardware problems such as insufficient power supply, controller crashes, or damaged communication interfaces occur, avoiding misjudging it as a bus scheduling anomaly and making ineffective scheduling recovery attempts. By accurately identifying hardware faults, the system can trigger corresponding degradation processing strategies, thereby preventing power waste or communication conflicts caused by the door handle continuing to perform invalid operations under hardware anomaly conditions. This achieves a clear distinction between scheduling anomalies and hardware faults, providing an accurate basis for subsequent differentiated processing and improving the system's maintainability and operational security.

[0068] Optionally, in some embodiments, after sending a scheduling request frame to the target bus, the method further includes: in response to not receiving a scheduling response from the door handle node, obtaining a second cumulative number of times the scheduling request frame was sent to the target bus; if the second cumulative number is greater than or equal to a second preset number, generating a broadcast wake-up signal, wherein the broadcast wake-up signal includes a door handle wake-up identifier; and sending the broadcast wake-up signal to the target bus to update the door handle node to the current scheduling table based on the broadcast wake-up signal.

[0069] It is understood that, in this embodiment, the scheduling response refers to the acknowledgment signal returned by the LIN bus master node to the door handle module after receiving the scheduling request frame sent by the door handle module. This response indicates that the LIN bus master node has successfully received the scheduling request and is ready to include the door handle node in the current scheduling table. The second cumulative number is the cumulative number of times the door handle module has continuously sent scheduling request frames without receiving a scheduling response. This number can be recorded by an internal counter of the door handle module to determine whether the scheduling request continues to fail. The second preset number is a pre-set threshold number of transmissions used to determine whether the scheduling request has indeed failed and requires the activation of the next-level recovery mechanism. Only when the cumulative number of transmissions reaches or exceeds this threshold is the generation of the broadcast wake-up signal triggered. Preferably, in this embodiment, the second preset number can be set to 5 consecutive times. The broadcast wake-up signal refers to the wireless broadcast signal generated by the door handle module after the scheduling request continues to fail. This signal may contain a door handle wake-up identifier, used to trigger the LIN bus master node to force a refresh of the current scheduling table wirelessly. The door handle wake-up identifier is a unique identifier pre-stored in the door handle module and embedded in the broadcast wake-up signal. It is used to enable the LIN bus master node to identify which door handle node the wake-up signal comes from.

[0070] Specifically, after sending a scheduling request frame, the door handle module can further introduce a redundancy recovery mechanism to handle the situation where the LIN bus master node is unresponsive. That is, after the door handle module sends a scheduling request frame, if it does not receive a scheduling response from the LIN bus master node, the door handle module accumulates the number of scheduling requests sent, obtaining a second accumulated count. When this second accumulated count reaches or exceeds a second preset count (e.g., 5 consecutive times), it indicates that the scheduling request frame method cannot successfully restore communication. The door handle module then generates a broadcast wake-up signal, which may carry a door handle wake-up identifier. The door handle module can wirelessly (e.g., via Bluetooth broadcast) send this broadcast wake-up signal to the vehicle network where the target bus is located. After receiving the broadcast wake-up signal, the LIN bus master node parses the door handle wake-up identifier and forcibly refreshes the current scheduling table, re-including the door handle node in the scheduling.

[0071] In addition, the LIN bus master node can also trigger and store scheduling table abnormal diagnostic codes (such as DTC (Diagnostic Trouble Code) U1010). These diagnostic codes can be read by a diagnostic tool, which makes it easier for maintenance personnel to quickly locate the root cause of the fault as a scheduling table abnormality rather than a door handle hardware failure, thereby greatly shortening the troubleshooting time and reducing the rate of incorrect replacement of parts.

[0072] Therefore, if no scheduling response is received from the door handle node after sending a scheduling request frame, the system accumulates the number of transmissions instead of immediately abandoning the task after a single failure, avoiding misjudgments caused by momentary bus interference or brief periods of busy master nodes. The next-level recovery mechanism is triggered only when the accumulated number of transmissions reaches a second preset threshold, ensuring that the redundant recovery process is only initiated after the scheduling request has truly failed, avoiding communication redundancy caused by premature intervention. After the request failure threshold is reached, a broadcast wake-up signal containing the door handle wake-up identifier is generated and sent to the target bus to wake up the master node and force the door handle node to be updated in the current scheduling table. Thus, this solution provides a redundant recovery path after a scheduling request frame failure, using a broadcast wake-up signal as a second-level recovery method, effectively addressing the abnormal scenario where the master node does not respond to the scheduling request frame, significantly improving the recovery success rate and system robustness under abnormal scheduling scenarios.

[0073] Optionally, in some embodiments, after determining that the door handle is a hardware fault, the method further includes: generating a hardware fault log and storing the hardware fault log in a local memory; reporting the hardware fault log to the vehicle controller and controlling the door handle to enter a preset low-power mode until a diagnostic command is received or the vehicle is powered on again.

[0074] It is understood that, in this embodiment, the hardware fault log refers to structured data that records information related to door handle hardware faults, including at least the fault type, fault occurrence timestamp, voltage value at the time of the fault, controller operating status code, and communication status code, for fault tracing and diagnostic analysis. Local memory refers to a non-volatile storage unit (such as Flash memory) integrated within the door handle module, characterized by data retention after power failure, used for persistent storage of the hardware fault log. The vehicle controller refers to the control unit in the vehicle responsible for centrally managing the vehicle network or receiving information reported by various modules, such as a vehicle domain controller or central gateway, used to collect fault information from various subsystems. The preset low-power mode refers to an energy-saving operating state that the door handle module enters after detecting a hardware fault. In this mode, the door handle can shut down unnecessary functional modules (such as wireless communication and sensor detection), maintaining only the most basic standby power consumption to avoid abnormal consumption of vehicle battery power during fault conditions. Diagnostic commands refer to dedicated commands sent by maintenance personnel to the door handle module via a diagnostic tool or vehicle diagnostic system for reading fault information or performing diagnostic operations.

[0075] Specifically, after determining that it has a hardware fault, the door handle module can further perform fault information recording and reporting operations, and control itself to enter an energy-saving state. That is, the door handle module first generates a hardware fault log, which can include key diagnostic information such as fault type, timestamp of occurrence, voltage value at the time of fault occurrence, controller operating status code, and communication status code. The door handle module can store this log in local non-volatile memory to ensure that the log is not lost after power failure. Subsequently, the door handle module can report the hardware fault log to the vehicle controller, enabling the fault information to be transmitted to the upper-level management unit in the vehicle network, facilitating vehicle-level fault aggregation and remote diagnosis. Simultaneously, the door handle module controls itself to enter a preset low-power mode, shutting down unnecessary functional modules and maintaining only basic standby power consumption to avoid continuously consuming vehicle battery power in the event of a hardware malfunction. The door handle module will maintain this preset low-power mode until it receives an external diagnostic command (such as a technician reading fault information using a diagnostic tool) or the vehicle is powered on again.

[0076] Furthermore, in the event of a hardware failure in the door handle module, the door handle module determines that it does not have normal communication capabilities and therefore prohibits sending scheduling request frames to the target bus to avoid invalid communication and waste of bus resources due to hardware abnormalities.

[0077] Therefore, by generating a hardware fault log and storing it locally after determining that the door handle is experiencing a hardware failure, local retention of fault information is achieved, facilitating rapid root cause location during after-sales diagnosis. By reporting the hardware fault log to the vehicle controller, fault information can be further transmitted to the central gateway or cloud, supporting remote diagnosis and predictive maintenance. By controlling the door handle to enter a preset low-power mode until a diagnostic command is received or the vehicle is powered on again, the continuous drain on the vehicle battery caused by abnormal power consumption during a fault condition is avoided, while also preventing the door handle from continuing to attempt invalid communication when hardware malfunctions. This achieves dual protection through local recording and remote reporting of hardware faults, and improves system security and vehicle range through low-power mode, providing reliable data support for subsequent maintenance.

[0078] Optionally, in some embodiments, before acquiring the master node scheduling frame of the target bus in response to the door handle interaction signal of the vehicle, the method further includes: identifying the current state of the target bus; generating a wake-up signal in response to the current state being a sleep state or an idle state; and waking up the target bus based on the wake-up signal.

[0079] It is understood that, in the embodiments of this application, the current state of the target bus refers to the operating mode of the target bus at the current moment, which may include a sleep state, an idle state, and an active communication state. A sleep state means the bus is in a low-power mode with no communication activity; an idle state means the bus has exited sleep but has not yet started scheduling communication; an active communication state means the bus is performing normal data transmission. A wake-up signal refers to a signal used to activate the target bus from a low-power sleep mode or an idle mode to a normal operating mode. In a LIN bus, the wake-up signal can be represented by a dominant level on the bus for a certain period of time.

[0080] Specifically, before responding to the door handle interaction signal and obtaining the master node scheduling frame, the door handle module can first identify the current state of the target bus. That is, the door handle module determines whether the target bus is in a sleep or idle state by detecting the level status or communication activity on the bus. When the door handle module identifies that the target bus is in a sleep or idle state, it indicates that the bus has not yet entered the normal scheduling communication mode, and directly attempting to obtain the scheduling frame will fail. If the LIN bus master node has stopped scheduling, causing the bus to enter an idle or sleep mode, the door handle module cannot obtain a response by sending a scheduling request frame. In this case, the door handle module can actively pull the bus low for at least 70 microseconds to generate a standard LIN wake-up signal.

[0081] After the LIN bus master node is woken up, it can send a frame header containing a synchronization interval field and synchronization bytes to achieve clock synchronization with each slave node. Then, the LIN bus master node performs initialization operations, including resetting the LIN hardware module, configuring the baud rate (such as 9600bps), setting the message identifier and data length, etc., to ensure that the communication parameters are consistent with the application layer configuration, thereby restoring normal data exchange and re-including the door handle node in the current scheduling table.

[0082] Therefore, before responding to the door handle interaction signal and obtaining the master node scheduling frame, the current state of the target bus is first identified to determine whether the bus is in a sleep or idle state, avoiding invalid acquisition of the scheduling frame when the bus is not awakened. When the bus is in a sleep or idle state, a wake-up signal is actively generated and used to wake up the target bus, ensuring that the bus has entered a normal working state before subsequent communication. Through the sequential design of waking up before acquiring the scheduling frame, the door handle module can establish a reliable communication link with the master node, providing a reliable communication foundation for subsequent acquisition of scheduling frames and sending request frames. This solves the problem that the door handle cannot receive scheduling frames or send requests due to bus sleep or idle states, ensuring that the scheduling monitoring and recovery process can be executed smoothly in the bus active state, improving the communication success rate and user interaction response speed.

[0083] Optionally, in some embodiments, before acquiring the master node scheduling frame of the target bus in response to the vehicle's door handle interaction signal, the method further includes: acquiring the current perception state of the vehicle's door handle; and determining that a door handle interaction signal exists if the current perception state meets the preset keyless entry conditions.

[0084] It is understood that, in this embodiment, the current sensing state of the vehicle door handle refers to the interaction information between the user and the door handle acquired in real time by the door handle module through its built-in sensing methods, including but not limited to sensing results such as whether the user touches the door handle, pulls the door handle, or whether the authorized key is near the door handle. The preset keyless entry condition refers to a pre-set criterion used to determine whether the user has a genuine intention to open or unlock the door. When the sensing information detected by the door handle module meets this criterion, it indicates that the user does indeed have an interaction intention, rather than a false signal caused by accidental touch or environmental interference.

[0085] Specifically, the door handle module can detect user actions (i.e., the current sensing state) in real time through built-in sensing methods. For example, the door handle module can detect whether the user has touched the door handle, pulled the door handle, or whether the authorized key is near the vehicle. Subsequently, the door handle module can compare the acquired current sensing state with preset keyless entry conditions: if the current sensing state meets the preset keyless entry conditions, the door handle module can determine that there is a real door handle interaction signal, indicating that the user has the intention to open or unlock the door; otherwise, if the preset keyless entry conditions are not met, the door handle module can determine that it is a mis-touch or environmental interference, and no door handle interaction signal is generated.

[0086] Therefore, before responding to the door handle interaction signal, the current perception state of the vehicle's door handle is first obtained, clarifying that the trigger source of the door handle interaction signal is the user's keyless entry intention. The presence of a door handle interaction signal is only determined when the current perception state meets the preset keyless entry conditions, avoiding false door handle activation due to interference signals or accidental touches. By strongly binding the interaction signal to the actual user intention, the subsequent scheduling, listening, and recovery processes are only initiated when the user genuinely needs to open the door. This effectively prevents the door handle module from performing meaningless scheduling, listening, and request operations triggered by non-user intentions, reducing system power consumption while improving the rationality of the interaction logic and the user experience.

[0087] It is understandable that the reason why this application embodiment chooses the scheduling request frame instead of the LIN wake-up frame as the recovery means door handle scheduling is as follows: Limitations of the wake-up frame: The LIN bus wake-up mechanism is mainly used to activate the bus when it is in a sleep state. The master or slave node sends a wake-up signal to activate bus communication. The wake-up signal is a dominant pulse, typically lasting 250μs to 5ms. Other nodes will interpret a dominant pulse exceeding 150μs as a wake-up signal.

[0088] Wake-up frames are invalid in non-sleep mode: When the LIN bus is in normal communication mode (non-sleep mode), the LIN bus master node performs data transmission and management according to the predefined schedule. It does not specifically listen for wake-up frames but focuses on processing normal communication frames on the bus. If a slave node sends a wake-up frame in non-sleep mode, the master node may treat it as an invalid communication frame and ignore it because the LIN bus master node's operating mode and processing logic in non-sleep mode are different from those in sleep mode.

[0089] Bus interference can occur if a slave node, due to a fault, mistakenly determines that the master node has stopped scheduling and sends a wake-up frame while not in sleep mode, which may affect normal messages. This could lead to bus conflicts, data transmission errors, or communication interruptions. The extent of the impact depends on the bus load, the implementation of the communication protocol, and other factors.

[0090] Unable to carry scheduling request information: The wake-up frame is only a physical layer pulse signal and cannot carry the semantic information of requesting scheduling, so it cannot inform the LIN bus master node which slave node needs to be included in the scheduling table.

[0091] This application embodiment uses a scheduling request frame, which can be recognized and processed by the LIN bus master node under normal bus communication conditions, and can carry a specific slave node identifier and request command, thereby achieving precise scheduling recovery.

[0092] To ensure the normal operation and reliability of the LIN bus, the following measures can be taken: Configure and program nodes correctly to ensure they can correctly identify and handle changes in bus state. Design reasonable communication protocols and scheduling mechanisms to avoid conflicts and interference between nodes. Conduct thorough testing and verification, including testing node wake-up and communication functions under different operating conditions. Employ appropriate error detection and correction mechanisms to promptly detect and handle communication errors. Regularly maintain and inspect the bus system to ensure its normal operation.

[0093] Figure 2 This is a block diagram of a vehicle door handle communication device provided in an embodiment of this application.

[0094] For example, such as Figure 2 As shown, the vehicle door handle communication device 10 may include: an acquisition module 100, a processing module 200, and an update module 300.

[0095] The acquisition module 100 is used to acquire the master node scheduling frame of the target bus in response to the door handle interaction signal of the vehicle. Processing module 200 is used to parse the master node scheduling frame and generate a scheduling request frame corresponding to the door handle interaction signal if there is no preset slave node identifier in the parsing result. The update module 300 is used to send a scheduling request frame to the target bus to update the door handle node to the current scheduling table based on the scheduling request frame.

[0096] Optionally, in one embodiment of this application, before generating the scheduling request frame corresponding to the door handle interaction signal, the processing module 200 is further configured to: The first cumulative count of the parsing result not containing the preset slave node identifier is obtained; If the first cumulative count is greater than the first preset count, it is determined that there is an anomaly in the current scheduling table, and a scheduling request frame corresponding to the door handle interaction signal is generated.

[0097] Optionally, in one embodiment of this application, before sending the scheduling request frame to the target bus, the update module 300 further includes: The acquisition unit is used to acquire the vehicle's door handle voltage, door handle controller operating status, and door handle communication status. The judgment unit is used to determine whether the door handle voltage is greater than the preset voltage, whether the door handle controller is in normal operation, and whether the door handle communication is in normal communication. The processing unit is used to determine that there is no hardware fault in the door handle when the door handle voltage is greater than the preset voltage, the door handle controller is in normal operation, and the door handle communication is in normal communication, and then sends a scheduling request frame to the target bus.

[0098] Optionally, in one embodiment of this application, after determining whether the door handle voltage is greater than a preset voltage, whether the door handle controller is in normal operating state, and whether the door handle communication state is in normal communication state, the processing unit is further configured to: If the door handle voltage is less than or equal to the preset voltage, or the door handle controller is in an abnormal operating state, or the door handle communication state is abnormal, the door handle is determined to be a hardware fault.

[0099] Optionally, in one embodiment of this application, after sending the scheduling request frame to the target bus, the processing unit is further configured to: In response to not receiving a scheduling response from the door handle node, obtain the second cumulative number of times a scheduling request frame has been sent to the target bus; If the second cumulative count is greater than or equal to the second preset count, a broadcast wake-up signal is generated, wherein the broadcast wake-up signal includes a door handle wake-up identifier; Send a broadcast wake-up signal to the target bus to update the door handle node to the current schedule table based on the broadcast wake-up signal.

[0100] Optionally, in one embodiment of this application, after determining that the door handle is a hardware failure, the processing unit is further configured to: Generate a hardware fault log and store it in local memory; The hardware fault log is reported to the vehicle controller, and the door handle is controlled to enter a preset low-power mode until a diagnostic command is received or the vehicle is powered on again.

[0101] Optionally, in one embodiment of this application, before acquiring the master node scheduling frame of the target bus in response to the vehicle's door handle interaction signal, the acquisition module 100 is further configured to: Identify the current state of the target bus; A wake-up signal is generated in response to the current state being either sleep or idle. The target bus is woken up based on the wake-up signal.

[0102] Optionally, in one embodiment of this application, before acquiring the master node scheduling frame of the target bus in response to the vehicle's door handle interaction signal, the acquisition module 100 is further configured to: Obtain the current sensing status of the vehicle door handle; If the current sensing state meets the preset keyless entry conditions, it is determined that there is a door handle interaction signal.

[0103] In summary, the vehicle door handle communication device according to the embodiments of this application solves the problem in related technologies where the door handle cannot send a heartbeat signal due to an abnormality in the target bus scheduling table, resulting in the door handle being unable to respond and unable to autonomously resume normal communication. This enables the door handle to autonomously perceive, actively request, and automatically recover from missing scheduling, thereby improving the reliability of the keyless entry system and the user experience.

[0104] Figure 3 This is a schematic diagram of the structure of a door handle provided in an embodiment of this application.

[0105] It should be understood that the methods described above can be applied to... Figure 3 In the door handle with the structure shown.

[0106] like Figure 3As shown, the door handle includes a controller, which may include a memory 301 and a processor 302. The memory 301 stores executable program code, and the processor 302 is used to call and execute the executable program code to perform the door handle scheduling and recovery method provided in this application embodiment.

[0107] Furthermore, the controller also includes a communication interface 303 for communication between the memory 301 and the processor 302.

[0108] This embodiment can divide the door handle into functional modules according to the above method example. For example, each module can correspond to a different function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0109] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0110] It should be understood that the vehicle provided in this embodiment is used to execute the above-described vehicle door handle communication method, and therefore can achieve the same effect as the above-described implementation method.

[0111] This embodiment also provides a vehicle that includes a door handle provided in the above embodiment.

[0112] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement the vehicle door handle communication method provided in the above embodiment.

[0113] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement a vehicle door handle communication method provided in the above embodiment.

[0114] In this embodiment, the door handle, vehicle, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0115] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0117] The above description is merely a specific embodiment 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 door handle communication method characterized by, Includes the following steps: In response to the door handle interaction signal of the vehicle, obtain the master node scheduling frame of the target bus; The master node scheduling frame is parsed, and if the preset slave node identifier is not found in the parsing result, a scheduling request frame corresponding to the door handle interaction signal is generated. Send the scheduling request frame to the target bus to update the door handle node to the current scheduling table based on the scheduling request frame.

2. The method of claim 1, wherein, Before generating the scheduling request frame corresponding to the door handle interaction signal, the method further includes: Obtain the first cumulative count of times that the preset slave node identifier does not exist in the parsing result; If the first accumulated number is greater than the first preset number, it is determined that the current scheduling table is abnormal, and a scheduling request frame corresponding to the door handle interaction signal is generated.

3. The method according to claim 1, characterized in that, Before sending the scheduling request frame to the target bus, the method further includes: The door handle voltage, door handle controller operating status, and door handle communication status of the vehicle are obtained. Determine whether the voltage of the door handle is greater than the preset voltage, whether the operating state of the door handle controller is normal, and whether the communication state of the door handle is normal. If the door handle voltage is greater than the preset voltage, and the door handle controller is in normal operation mode and the door handle communication mode is in normal communication mode, it is determined that the door handle does not have a hardware fault, and the scheduling request frame is sent to the target bus.

4. The method according to claim 3, characterized in that, After determining whether the door handle voltage is greater than a preset voltage, whether the door handle controller is in normal operating condition, and whether the door handle communication is in normal communication condition, the method further includes: If the door handle voltage is less than or equal to a preset voltage, or the door handle controller is in an abnormal operating state, or the door handle communication state is in an abnormal communication state, the door handle is determined to be a hardware fault.

5. The method according to claim 4, characterized in that, After sending the scheduling request frame to the target bus, the process further includes: In response to not receiving a scheduling response from the door handle node, obtain a second cumulative number of times the scheduling request frame was sent to the target bus; If the second cumulative count is greater than or equal to the second preset count, a broadcast wake-up signal is generated, wherein the broadcast wake-up signal includes a door handle wake-up identifier; The broadcast wake-up signal is sent to the target bus to update the door handle node to the current scheduling table based on the broadcast wake-up signal.

6. The method according to claim 4, characterized in that, After determining that the door handle is a hardware malfunction, the process also includes: Generate a hardware fault log and store the hardware fault log in local memory; The hardware fault log is reported to the vehicle controller, and the door handle is controlled to enter a preset low-power mode until a diagnostic command is received or the vehicle is powered on again.

7. The method according to claim 1, characterized in that, Before acquiring the master node scheduling frame of the target bus in response to the vehicle's door handle interaction signal, the process also includes: Identify the current state of the target bus; A wake-up signal is generated in response to the current state being either a sleep state or an idle state; The target bus is woken up based on the wake-up signal.

8. The method according to claim 1, characterized in that, Before acquiring the master node scheduling frame of the target bus in response to the vehicle's door handle interaction signal, the process also includes: Obtain the current sensing state of the vehicle door handle; If the current sensing state meets the preset keyless entry conditions, it is determined that the door handle interaction signal exists.

9. A door handle, 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 door handle communication method as described in any one of claims 1-8.

10. A vehicle, characterized in that, include: The door handle as described in claim 9.

Images