Door lock motor control method and device, electronic equipment and storage medium

Abstract

The application provides a door lock motor control method and device, electronic equipment and storage medium, which are applied to a door lock control system. The system comprises a driving layer, an equipment abstraction layer and an application layer. The method comprises the following steps: receiving a pawl state uploaded by the driving layer; performing a first verification operation on the pawl state to obtain a first pawl state, and uploading the pawl state as a second pawl state to the application layer, so that the application layer generates a motor braking instruction under the condition that the second pawl state is monitored to change; if the first pawl state and the second pawl state are the same, the motor braking instruction from the application layer is sent to the driving layer, so that the driving layer controls the door lock motor to stop running in response to the motor braking instruction. The generation of the motor braking instruction and the verification of the pawl state are executed synchronously, the motor can be controlled to stop running in time under the condition that the motor braking is not triggered by mistake, and the locked-rotor time of the door lock motor is effectively reduced.

Description

Technical Field

[0001] The present application relates to the field of door lock control technology, and in particular to a door lock motor control method, device, electronic device and storage medium. Background Art

[0002] With the rapid development of the automotive industry, automotive electronic control systems are becoming increasingly complex and intelligent. As a crucial component of vehicle safety, the reliability and responsiveness of door lock systems significantly impact the overall vehicle safety and user experience. Traditional door lock control systems typically utilize a multi-layered software architecture based on a service-oriented architecture (SOA). This architecture operates through periodic tasks, with individual SWCs (Software Components) executing software logic on a cycle-by-cycle basis.

[0003] In related technologies, when faced with complex functions requiring the coordinated operation of multiple SWCs, this architecture experiences time delays in communication and data exchange between the SWCs, significantly compromising timing accuracy and making it difficult to achieve functional requirements when precise timing control is required. In door lock motor control, precise control of the motor's start, stop, and stall times is required. However, due to the extended response time of the multi-layered software architecture, it is impossible to precisely control the motor's stall time, causing the motor to operate in a stalled state for extended periods. This increases the likelihood of door lock motor fatigue, impacting component performance and lifespan, and thus the reliability of the door lock function. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the present application discloses a door lock motor control method, device, electronic device and storage medium, which are used to solve the technical problem in the prior art that the motor is damaged due to untimely control of the motor stall phenomenon.

[0005] In the first aspect, the present application provides a door lock motor control method, which is applied to a door lock control system, wherein the door lock control system includes a driver layer, a device abstraction layer and an application layer, and the method includes: receiving a pawl state uploaded by the driver layer; performing a first verification operation on the pawl state to obtain a first pawl state, and at the same time, uploading the pawl state as a second pawl state to the application layer, so that the application layer generates a motor braking instruction under the condition that the second pawl state is monitored to change; if the first pawl state is the same as the second pawl state, the motor braking instruction from the application layer is sent to the driver layer, so that the driver layer responds to the motor braking instruction and controls the door lock motor to stop running.

[0006] In one embodiment of the present application, the first verification operation is performed on the pawl state to obtain the first pawl state, including: continuously receiving multiple third pawl states uploaded by the drive layer; if each of the third pawl states is the same as the second pawl state, then obtaining the first pawl state that is the same as the second pawl state; if at least one of the third pawl states is opposite to the second pawl state, then obtaining the first pawl state that is opposite to the second pawl state.

[0007] In one embodiment of the present application, before uploading the pawl state as the second pawl state to the application layer, it also includes: obtaining duration information, the duration information including information transmission duration and processing duration, the information transmission duration is the duration for completing information transmission between the application layer, and the processing duration is the duration for the application layer to generate the motor braking instruction; determining a second verification duration based on a preset first verification duration, the information transmission duration and the processing duration, the first verification duration being the duration of the first verification operation, and the second verification duration being less than the first verification duration; performing a second verification operation on the pawl state according to the second verification duration to obtain the second pawl state.

[0008] In one embodiment of the present application, the second verification operation is performed on the pawl state according to the second verification time length to obtain the second pawl state, including: continuously receiving multiple fourth pawl states uploaded by the drive layer within the second verification time length; under the condition that the multiple fourth pawl states are the same, determining the second pawl state, and the second pawl state is the same as the state of the multiple fourth pawl states.

[0009] In one embodiment of the present application, after uploading the pawl state as the second pawl state to the application layer, it also includes: obtaining the motor operating temperature; setting a standard duration after obtaining the second pawl state according to the motor operating temperature, and the standard duration is inversely proportional to the motor operating temperature; monitoring the real-time processing duration of the first verification operation; if the real-time processing duration is greater than the standard duration, exiting the door lock motor control operation.

[0010] In one embodiment of the present application, after obtaining the first pawl state, the method further includes: if the first pawl state is opposite to the second pawl state, stopping the transmission of the motor braking command and resetting the motor braking command.

[0011] In one embodiment of the present application, the application layer generates a motor braking instruction when it detects a change in the second pawl state, including: obtaining the historical pawl state uploaded by the device abstraction layer; if the second pawl state is opposite to the historical pawl state, then generating the motor braking instruction.

[0012] In the second aspect, the present application provides a door lock motor control device, which is applied to a door lock control system. The door lock control system includes a driver layer, a device abstraction layer and an application layer. The device includes: a receiving module for receiving the pawl state uploaded by the driver layer; a processing module for performing a first verification operation on the pawl state to obtain a first pawl state, and at the same time, uploading the pawl state as a second pawl state to the application layer, so that the application layer generates a motor braking instruction under the condition that the second pawl state is detected to change; a transmission module for sending the motor braking instruction from the application layer to the driver layer if the first pawl state is the same as the second pawl state, so that the driver layer responds to the motor braking instruction and controls the door lock motor to stop running.

[0013] In a third aspect, the present application provides an electronic device comprising: one or more processors; a storage device for storing one or more programs, which, when executed by one or more processors, enables the electronic device to implement the door lock motor control method described in the first aspect.

[0014] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor of a computer, the computer executes the door lock motor control method described in the first aspect.

[0015] As described above, the door lock motor control method, device, electronic device, and storage medium provided by the embodiments of the present application have the following beneficial effects:

[0016] The device abstraction layer first receives the pawl state uploaded by the driver layer, then performs a first verification operation on the pawl state to obtain the first pawl state, and at the same time, uploads the pawl state as the second pawl state to the application layer, so that the application layer generates a motor braking instruction under the condition that the second pawl state changes. If the first pawl state is the same as the second pawl state, the motor braking instruction from the application layer is sent to the driver layer, so that the driver layer responds to the motor braking instruction and controls the door lock motor to stop running. Based on the driving logic of the door lock motor in the original door lock control software architecture, that is, the driver layer collects the pawl state, the device abstraction layer is responsible for reporting the pawl state collected by the driver layer to the application layer. The application layer handles the logical control of the door lock function and issues instructions that are passed to the driver layer in sequence. Without affecting the current driving logic of the door lock motor, the device abstraction layer performs the verification and reporting operations of the pawl status synchronously, so that the generation of the motor braking instruction and the verification of the pawl status are executed synchronously, reducing the waiting time of the verification operation. In the motor control, the door lock motor is driven in advance, achieving the effect of reducing the overall driving time. It can not only avoid the false triggering of the motor brake, but also can control the motor to stop running in time, effectively reducing the stall time of the door lock motor, thereby reducing the fatigue probability of the door lock motor, ensuring the performance and life of the motor, and reducing the impact on the door lock function.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings are incorporated into and constitute a part of the specification, illustrating embodiments consistent with the present application and, together with the specification, serving to explain the principles of the present application. It is obvious that the drawings described below are merely some embodiments of the present application, and a person of ordinary skill in the art can derive other drawings based on these drawings without inventive effort. In the drawings:

[0019] Figure 1 1 is a schematic structural diagram of a door lock control system according to an exemplary embodiment of the present application;

[0020] Figure 2 This is a schematic diagram of an implementation environment of a door lock motor control device shown in an exemplary embodiment of the present application;

[0021] Figure 3 is a flow chart of a door lock motor control method shown in an exemplary embodiment of the present application;

[0022] Figure 4 is a schematic diagram of a door lock motor control timing sequence shown in an exemplary embodiment of the present application;

[0023] Figure 5 is a flow chart of another door lock motor control method shown in an exemplary embodiment of the present application;

[0024] Figure 6 is a block diagram of a door lock motor control device shown in an exemplary embodiment of the present application;

[0025] Figure 7 This is a structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0026] The following will describe the embodiments of the present application with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand the other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be understood that the preferred embodiments are only for the purpose of illustrating the present application and are not intended to limit the scope of protection of the present application.

[0027] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present application. Therefore, the illustrations only show components related to the present application rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the shape, quantity and proportion of each component may be changed at will, and the component layout may also be more complicated.

[0028] In the following description, a large number of details are discussed to provide a more thorough explanation of the embodiments of the present application. However, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present application difficult to understand.

[0029] Currently, door lock control systems typically utilize a multi-layered SOA-based software architecture. This architecture operates through periodic tasks, with individual SWCs executing software logic on a cycle-by-cycle basis. Door lock motor control requires precise control of the motor's start, stop, and stall times. However, the inventors of this application have discovered that communication and data exchange between SWCs experience time delays. Due to the extended response time in this multi-layered software architecture, the motor's stall time cannot be precisely controlled, potentially causing the motor to operate in a stalled state for extended periods. This increases the likelihood of door lock motor fatigue, impacting component performance and lifespan, and thus the reliability of the door lock function.

[0030] See Figure 1 , Figure 1This is a schematic diagram of a door lock control system shown in an exemplary embodiment of the present application. Figure 1 As shown in Figure 1, the software architecture of a door lock control system based on a service-oriented architecture includes a driver layer, a device abstraction layer, and an application layer. This software architecture is used to implement door lock control. The driver layer is responsible for collecting hardware signals and outputting drive levels and PWM (Pulse Width Modulation) wave signals. The device abstraction layer is responsible for reporting the hardware signals collected by the driver to the application layer. The application layer is responsible for handling the logical control of the door lock function and issuing control signals based on the hardware signals. The device abstraction layer transmits the control signals issued by the application layer to the driver layer, which then controls the hardware based on the control signals. In door lock motor control, the application layer issues unlock or lock commands, which are then transmitted to the driver layer. The driver layer controls the motor rotation to achieve unlocking or locking. The driver layer then begins to collect the pawl status and reports it to the device abstraction layer. The device abstraction layer is responsible for reporting the pawl status collected by the driver layer to the application layer. The application layer performs the motor braking logic control and issues commands that are then transmitted to the driver layer, causing the driver layer to control the motor to stop.

[0031] The pawl states include unlocked and locked states. The unlocked state can be understood as the state in which the pawl is separated from the internal structure of the lock body (such as the lock tongue or lock cylinder), allowing the lock tongue to retract or the lock cylinder to rotate, thereby allowing the door to be opened. The locked state can be understood as the state in which the pawl is tightly engaged with the internal structure of the lock body, preventing the lock tongue from extending or the lock cylinder from rotating, thereby keeping the door closed and unable to be opened. When the door lock is unlocked, if the pawl state is unlocked, it indicates that the door lock is completely unlocked and motor braking control can be performed. When the door lock is locked, if the pawl state is locked, it indicates that the door lock is completely locked and motor braking control can be performed.

[0032] However, in the software architecture layer, it takes a certain amount of time for signal processing at each layer, and it takes a certain amount of time for signal transmission between layers. In addition, during motor braking, considering that the false triggering of motor braking may affect the unlocking and locking functions of the normal door lock, the device abstraction layer will first verify the collected pawl status and report it after determining the final pawl status. The application layer will then implement the issuance of the braking command. Based on the existence of the verification time, the time for the motor to stop running is delayed to a certain extent, which prolongs the motor stall time.

[0033] Taking the door lock unlocking driver as an example, after the application layer issues an unlock command (e.g., doorLockCmd=1), the driver periodically (e.g., 10ms) collects the pawl status. After the application layer detects that the pawl is disengaged (i.e., released) (e.g., clawSigStatus=0 jumps to clawSigStatus=1), it immediately issues a generator braking command (e.g., doorLockCmd=3) for a certain period of time (e.g., 200ms) to quickly control the motor to stop rotating. It then waits for the lock tongue signal (secondarySigStatus=0 jumps to secondarySigStatus=1) and immediately issues a reset command (e.g., doorLockCmd=2) to drive the door lock motor to reset (reset to the reverse command of the unlock or lock drive). Due to the structure of the lock body, after a certain period of time (e.g., 60ms) after the pawl is disengaged, the motor runs to the limit position and begins to stall. At the same time, it takes a certain period of time (e.g., 30ms) after the pawl is disengaged to ensure that the pawl enters the mechanical limit state. At this time, the pawl position is restricted and cannot move, ensuring that it will not affect subsequent door lock control. Stalling is one of the basic operating conditions of a motor. A small amount of short-term stalling will not have a significant impact on the motor. However, stalling will increase the internal resistance of the motor and increase the temperature. In the long run, it will reduce the performance and service life of the motor. Therefore, this function requires extremely high timing accuracy of the software architecture. Taking the aforementioned 30ms and 60ms as an example, it is necessary to control the motor to stop running after at least 30ms after the pawl is disengaged, while at the same time, it is necessary to avoid motor stalling as much as possible. In other words, the optimal braking command time is within 30-60ms after the pawl is disengaged.

[0034] If, however, the driver collects the pawl signal once within a 10ms task cycle and outputs the specific value, there will be a 0-10ms delay before the signal is collected and stored in the task, depending on the driver task cycle. The 10ms task may have just begun or ended when the hardware status changes. In either case, the current value is fed into the task for internal calculation at the start of the next task, and the result is sent to the device abstraction layer. The device abstraction layer also has a 10ms cycle and verifies the value reported by the driver. For example, it needs to detect five identical values ​​consecutively before it determines a status change. This results in a 40-50ms verification delay, and an additional 0-10ms delay before the device abstraction layer reports it to the application layer. After processing the logic, the application layer issues a generator braking command within the same task. This command is received by the device abstraction layer with a 0-10ms delay, and the driver layer receives the command from the device abstraction layer with another 0-10ms delay. The entire link has a possible delay of 40-90ms, which makes it difficult to meet the target time of 30-60ms, causing the motor to operate in a stalled state for a long time.

[0035] Therefore, see Figure 2 , Figure 2 FIG. 1 is a schematic diagram showing an implementation environment of a door lock motor control device according to an exemplary embodiment of the present application. Figure 2 As shown, the implementation environment may include a door lock motor control device 210 and a computer device 220. The door lock motor control device 220 may be disposed in the computer device 220 to implement control of the door lock motor. The computer device 220 may be at least one of a desktop graphics processing unit (GPU) computer, a GPU computing cluster, a neural network computer, and the like. The door lock motor control device 210 is based on the driving logic of the door lock motor in the original door lock control software architecture, that is, the driving layer collects the pawl status, and the device abstraction layer is responsible for reporting the pawl status collected by the driving layer to the application layer. The application layer processes the logic control of the door lock function and issues instructions to the driving layer in sequence. On the basis of not affecting the current driving logic of the door lock motor, the pawl status verification operation and reporting operation are performed synchronously at the device abstraction layer, so that the generation of the motor braking instruction and the verification of the pawl status are executed synchronously, reducing the waiting time of the verification operation. In the motor control, the door lock motor is driven in advance, achieving the effect of reducing the overall driving time. It can not only avoid the false triggering of the motor brake, but also can timely control the motor to stop running, effectively reducing the stall time of the door lock motor, thereby reducing the fatigue probability of the door lock motor, ensuring the performance and life of the motor, and reducing the impact on the door lock function.

[0036] See Figure 3 , Figure 3 This is a flow chart of a door lock motor control method shown in an exemplary embodiment of the present application. This method can be applied to Figure 2 The implementation environment shown is shown. It should be understood that the method can also be applied to other exemplary implementation environments, and this embodiment does not limit the implementation environment to which the method is applicable.

[0037] In addition, the method is applicable to the control of the door lock motor during unlocking and locking, that is, the braking control of the door lock motor after unlocking or locking is completed.

[0038] like Figure 3 As shown, in an exemplary embodiment, the door lock motor control method includes at least steps S310 to S330, which are described in detail as follows:

[0039] Step S310: receiving the pawl status uploaded by the driving layer.

[0040] The pawl state includes an unlocked state and a locked state. When the door lock is unlocked, if the pawl state is unlocked, it indicates that the door lock is unlocked. When the door lock is locked, if the pawl state is locked, it indicates that the door lock is locked. If the door lock is unlocked or locked, it indicates that the motor can be controlled to stop running.

[0041] In step S320, a first check operation is performed on the pawl state to obtain a first pawl state. At the same time, the pawl state is uploaded to the application layer as a second pawl state, so that the application layer generates a motor braking instruction when detecting a change in the second pawl state.

[0042] In this embodiment, to account for the possibility of false triggering of the motor braking command, the pawl status reported by the driver layer is verified at the abstract device layer, thereby ensuring the reliability of the motor braking control. Furthermore, given that the device abstraction layer first verifies the pawl status and then reports the verified pawl status to the application layer, which then generates and issues the motor braking command, this involves significant processing time. Therefore, the device abstraction layer synchronizes the pawl status verification and reporting operations, allowing the generation of the motor braking command and the verification of the pawl status to be performed simultaneously. This reduces the waiting time for the verification operation and effectively reduces the stall time of the door lock motor.

[0043] In addition, the device abstraction layer performs a first check operation on the pawl state and uploads the second pawl state to the application layer with triggering conditions, that is, the device abstraction layer triggers the check operation and upload operation of the pawl state after detecting a change in the pawl state.

[0044] Taking the door lock unlocking driver as an example, the device abstraction layer stores the pawl status reported by the driver layer before and after verification in two independent variables. Before verification, it is set to clawSigStatus, representing the second pawl state mentioned above, and after verification, it is set to clawSigStatusAfterFilter, representing the first pawl state mentioned above. In addition, the value 0 indicates that the pawl state is locked, and the value 1 indicates that the pawl state is unlocked. If the historical pawl state reported by the driver layer has always been clawSig = 0, that is, the locked state, and the currently uploaded pawl state is clawSig = 1, that is, the unlocked state, this indicates that the pawl state has changed, and the pawl state verification operation is performed, and the pawl state upload operation is performed, that is, the second pawl state is set to clawSigStatus = 1 and uploaded to the application layer.

[0045] In one embodiment, a first verification operation is performed on the pawl state to obtain a first pawl state, including: continuously receiving multiple third pawl states uploaded by the drive layer; if each third pawl state is the same as the second pawl state, then a first pawl state that is the same as the second pawl state is obtained; if at least one third pawl state is opposite to the second pawl state, then a first pawl state that is opposite to the second pawl state is obtained.

[0046] In this embodiment, the device abstraction layer continuously receives multiple pawl states uploaded by the driver layer, which are recorded as third pawl states. If each third pawl state is the same as the second pawl state (i.e., the initial pawl state), it indicates that the pawl state received by the device abstraction layer is always in the same state after the current door lock is unlocked or the door lock is locked. The first pawl state obtained at this time is the same as the second pawl state uploaded to the application layer. If at least one third pawl state is opposite to the second pawl state, it indicates that the pawl state received by the device abstraction layer is not always in the same state under the current door lock unlocking or door lock locking. Due to the uncertainty of the pawl state, it cannot be determined whether the unlocking or locking is completed. Therefore, the motor brake may be falsely triggered. Therefore, the set first pawl state is opposite to the second pawl state. In this way, by continuously receiving multiple pawl states to perform the pawl state verification operation, the reliability of the motor braking control can be guaranteed.

[0047] Taking the door lock unlocking drive as an example, if the multiple third pawl states reported by the driving layer are all clawSig=1, that is, they are consistent with the second pawl state clawSigStatus=1. At this time, the verified first pawl state clawSigStatusAfterFilter=1 is the same as the second pawl state clawSigStatus=1; if clawSig=0 exists among the multiple third pawl states reported by the driving layer, that is, the pawl state has not been in the same state within the preset time length or the preset number of acquisitions, at this time, the verified first pawl state clawSigStatusAfterFilter=0 is opposite to the second pawl state clawSigStatus=1.

[0048] In a possible embodiment, the device abstraction layer continuously receives multiple third pawl states uploaded by the driver layer, wherein the specific number of the third pawl states can be set according to needs or specific circumstances, and the embodiment does not limit the number.

[0049] In one embodiment, before uploading the pawl state as the second pawl state to the application layer, it also includes: obtaining duration information, the duration information includes information transmission duration and processing duration, the information transmission duration is the duration for completing information transmission between the application layer, and the processing duration is the duration for the application layer to generate a motor braking instruction; according to the preset first verification duration, information transmission duration and processing duration, the second verification duration is determined, the first verification duration is the duration of the first verification operation, and the second verification duration is less than the first verification duration; according to the second verification duration, a second verification operation is performed on the pawl state to obtain the second pawl state.

[0050] The first verification time can be set according to needs or specific circumstances.

[0051] In this embodiment, the device abstraction layer reports the pawl state as the second pawl state to the application layer as soon as the pawl state changes. Considering that single-shot state data is unreliable, the application layer might generate motor braking instructions based on erroneous state change information, wasting resources. Therefore, the device abstraction layer performs a preliminary check of the pawl state before reporting. This second check prevents false triggering of the motor brake and avoids wasting application layer resources.

[0052] In this embodiment, taking into account the purpose of reducing the stall time of the door lock motor, the generation operation of the motor braking instruction is executed synchronously with the first verification operation of the pawl state. Based on the first verification duration, if there is still time redundancy after the generation operation of the motor braking instruction is completed, that is, the first verification operation is still in progress after the device abstraction layer receives the motor braking instruction issued by the application layer, at this time, based on the redundant duration, the device abstraction layer can also perform a verification operation on the pawl state before reporting. In this way, it will not only not affect the reduction of the stall time of the door lock motor, but also further enhance the reliability of the motor braking instruction and avoid waste of resources at the application layer.

[0053] As one possible embodiment, the device abstraction layer's processing logic is divided into two verification operation routes. After receiving a change in the pawl state, the device abstraction layer performs a first verification operation in one verification operation route and a second verification operation in the other verification operation route. The second verification operation lasts for a shorter period of time than the first verification operation. The device abstraction layer's first verification operation continues for the first verification duration. After the second verification operation is completed, if the verification result meets the requirements, indicating that the pawl state has changed, the second pawl state after the second verification operation is reported to the application layer, and the motor braking command issued by the application layer is received.

[0054] Taking the door lock unlocking driver as an example, assuming that the second verification operation is to continuously receive 2 clawSig=1, then set clawSigStatus=1. At this time, clawSigStatus=1 can be reported to the application layer; and the first verification operation is to continuously receive 5 clawSig=1, then set clawSigStatusAfterFilter=1.

[0055] In one embodiment, a second verification operation is performed on the pawl state according to the second verification time length to obtain the second pawl state, including: continuously receiving multiple fourth pawl states uploaded by the drive layer within the second verification time length; under the condition that the multiple fourth pawl states are the same, determining the second pawl state, and the second pawl state is the same as the state of the multiple fourth pawl states.

[0056] In this embodiment, the device abstraction layer continuously receives multiple pawl states uploaded by the driver layer during the second verification operation, which are recorded as fourth pawl states. If the fourth pawl states are the same, it indicates that the pawl state received by the device abstraction layer has been in the same state after the current door lock is unlocked or locked. At this time, the second pawl state is determined. In this way, the verification of the second pawl state is realized, and the reliability of the pawl state uploaded to the application layer is guaranteed.

[0057] Taking the door lock unlocking driver as an example, if the multiple fourth pawl states reported by the driver layer are all clawSig=1, the second pawl state is determined to be clawSigStatus=1. On the contrary, if clawSig=0 exists in the multiple fourth pawl states, the second pawl state is clawSigStatus=0.

[0058] In a possible embodiment, the second verification time is determined based on the preset first verification time, information transmission time and processing time, including: doubling the information transmission time and calculating the sum with the processing time; calculating the difference between the first verification time and the above sum to obtain the second verification time.

[0059] The information transmission time is doubled, including the time for the device abstraction layer to upload the second pawl state to the application layer and the time for the application layer to send the generator braking instruction to the device abstraction layer.

[0060] As a possible embodiment, the calculation formula for the second verification time is:

[0061] T2=T1-(2T a +T b )

[0062] Among them, T2 represents the second verification time, T1 represents the first verification time, T a Indicates the information transmission time, Tb Indicates the processing time.

[0063] In a possible embodiment, the pawl state is represented by a PWM signal, and the first verification operation and the second verification operation are filtering operations.

[0064] In one embodiment, after uploading the pawl state as the second pawl state to the application layer, it also includes: obtaining the motor operating temperature; setting a standard duration after obtaining the second pawl state according to the motor operating temperature, and the standard duration is inversely proportional to the motor operating temperature; monitoring the real-time processing duration of the first verification operation; if the real-time processing duration is greater than the standard duration, exiting the door lock motor control operation.

[0065] In this embodiment, taking into account the fact that the first verification operation has not been completed for a long time due to a fault, or the driver layer uploads the pawl status as an erroneous trigger, resulting in the first verification operation being unable to be completed for a long time, a standard duration is set to avoid the device abstraction layer being in a state of waiting for the first verification operation to be completed for a long time.

[0066] In this embodiment, after the first verification operation starts, the real-time processing duration of the first verification operation is monitored, and by comparing the standard duration with the real-time processing duration, it is determined whether the first verification operation has not been completed for a long time. If not, the first verification operation is continued until the first verification operation is completed. If so, the door lock motor control operation is directly exited to avoid resource occupation.

[0067] As a possible embodiment, taking into account the influence of the motor operating temperature on the motor speed, that is, the lower the temperature, the greater the current, and the faster the motor rotates, therefore, the faster the motor runs to the limit position. In order to avoid increasing the motor stall time, the faster the motor rotates, that is, the lower the motor operating temperature, the shorter the standard duration is set, so that the real-time processing time is shortened through control.

[0068] In addition, the standard duration here is different from the above-mentioned preset first verification duration. The above-mentioned preset first verification duration is the ideal duration for completing the first verification operation, while the standard duration is the maximum duration of the first verification operation allowed by the device abstraction layer.

[0069] In one embodiment, the application layer generates a motor braking instruction when detecting a change in the second pawl state, including: obtaining a historical pawl state uploaded by the device abstraction layer; and generating a motor braking instruction if the second pawl state is opposite to the historical pawl state.

[0070] The second pawl state is opposite to the historical pawl state, including: when the door lock is locked, the historical pawl state is unlocked and the second pawl state is locked, or, when the door lock is unlocked, the historical pawl state is locked and the second pawl state is unlocked.

[0071] In this embodiment, after receiving the second pawl state, the application layer will again determine whether the pawl state has changed. Only when it has changed will it generate and issue a motor braking instruction. This further avoids false triggering of the motor braking and ensures the reliability of the motor drive control.

[0072] Step S330: If the first pawl state and the second pawl state are the same, the motor braking instruction from the application layer is sent to the driving layer, so that the driving layer responds to the motor braking instruction and controls the door lock motor to stop running.

[0073] The first pawl state and the second pawl state being the same includes: when the door lock is unlocked, the first pawl state and the second pawl state are both unlocked states, or when the door lock is locked, the first pawl state and the second pawl state are both locked states.

[0074] In this embodiment, the device abstraction layer sends the motor braking instruction to the driver layer only when the first pawl state and the second pawl state are the same, so as to ensure the reliability of the motor braking.

[0075] In one embodiment, after obtaining the first pawl state, the method further includes: if the first pawl state is opposite to the second pawl state, stopping the transmission of the motor braking command and resetting the motor braking command.

[0076] The first pawl state and the second pawl state are opposite in state, including: when the door lock is unlocked, the first pawl state is locked and the second pawl state is unlocked, or, when the door lock is locked, the first pawl state is unlocked and the second pawl state is locked.

[0077] In this embodiment, if the first pawl state is opposite to the second pawl state, the second pawl state is considered to be inaccurate. It can be understood that the motor braking instruction generated and issued by the application layer based on the second pawl state is generated by a false trigger. Therefore, the device abstraction layer stops transmitting the motor braking instruction and resets the motor braking instruction. In this way, the reliability of motor braking is guaranteed, thereby ensuring the normal operation of the door lock drive.

[0078] Taking the door lock unlocking drive as an example, if the first pawl state is clawSigStatusAfterFilter=0 and the second pawl state is clawSigStatus=1, the transmission of the motor braking command is stopped and the motor braking command is reset.

[0079] See him 4, Figure 4 FIG. 1 is a schematic diagram of a door lock motor control sequence according to an exemplary embodiment of the present application. Figure 4 As shown, A represents the motor braking control scheme shown in the embodiment of the present application, and B represents the existing motor braking control scheme. Starting from the acquisition of the ratchet state, both Scheme A and Scheme B first acquire the ratchet state through the driver layer and upload it to the device abstraction layer. After the device abstraction layer receives the ratchet state, Scheme B first performs a verification operation. After the verification is completed and successful, the ratchet state is uploaded to the application layer, so that the application layer generates a motor braking instruction and sends it to the device abstraction layer, and then the device abstraction layer sends it to the driver layer to control the motor to stop. In Scheme A, the first verification operation and the second verification operation are performed simultaneously. The second verification operation serves as the initial verification, and the verification time is shorter than the verification time of the first verification operation. After the second verification operation is completed and successful, the ratchet state is uploaded to the application layer, so that the application layer generates a motor braking instruction and sends it to the device abstraction layer. At this time, the device abstraction layer waits for the verification result of the first verification operation. If the verification is successful, the device abstraction layer sends it to the driver layer to control the motor to stop.

[0080] Therefore, Figure 4 Taking the duration in as an example, when the total verification time is the same, the maximum delay of solution B is 90ms, while that of solution A is 70ms. This does not affect the current drive logic of the door lock, the verification time of the device abstraction layer, or the user perception. It reduces the stall time by 20ms for each unlocking. Similarly, it reduces the stall time by 20ms for each locking. This greatly improves the performance and usability of the door lock motor and ensures the reliability of the door lock function.

[0081] In a possible embodiment, the door lock motor control method shown in the embodiment of the present application can be used in a vehicle. This solution can effectively reduce the time that the vehicle door lock motor is blocked while ensuring the braking reliability of the vehicle door lock motor, thereby improving the reliability of the vehicle function, ensuring the safety of the entire vehicle, and improving the safety of users using the vehicle.

[0082] See Figure 5 , Figure 5 FIG. 1 is a flow chart of another door lock motor control method shown in an exemplary embodiment of the present application. Figure 5As shown, taking the door lock unlocking drive as an example, the door unlocking is first triggered, then the pawl status is received and the value of clawSigS is determined to be 1. If clawSigS=1 reported by the driver layer is not received within the preset time, it will wait until the door unlocking is triggered next time to monitor and receive again. If clawSig=1 is received within the preset time, multiple pawl statuses will continue to be received. If clawSig=1 is satisfied within two consecutive cycles, clawSigStatus=1 is set and reported to the application layer, thereby obtaining the motor braking instruction (such as preDoorLockCmd=3) issued by the application layer. At the same time, if clawSig=1 is satisfied within five cycles, clawSigStatusAfterFilter=1 is set. If clawSigStatus=1, preDoorLockCmd=3 and clawSigStatusAfterFilter=1 in the device abstraction layer are satisfied at the same time, the final motor braking instruction (such as DoorLockCmd=3) is generated and sent to the driver layer to implement motor braking control.

[0083] In the above-mentioned door lock motor control method, the device abstraction layer first receives the pawl state uploaded by the driver layer, and then performs a first verification operation on the pawl state to obtain the first pawl state. At the same time, the pawl state is uploaded to the application layer as the second pawl state, so that the application layer generates a motor braking instruction under the condition that the second pawl state is detected to have changed. If the first pawl state is the same as the second pawl state, the motor braking instruction from the application layer is sent to the driver layer, so that the driver layer responds to the motor braking instruction and controls the door lock motor to stop running. Based on the driving logic of the door lock motor in the original door lock control software architecture, that is, the driver layer collects the pawl state, the device abstraction layer is responsible for reporting the pawl state collected by the driver layer To the application layer, the application layer handles the logical control of the door lock function and issues instructions to the driver layer in sequence. Without affecting the current driving logic of the door lock motor, at the device abstraction layer, the pawl status verification operation and reporting operation are performed synchronously, so that the generation of the motor braking instruction and the verification of the pawl status are executed synchronously, reducing the waiting time of the verification operation. In the motor control, the door lock motor is driven in advance, achieving the effect of reducing the overall driving time. It can not only avoid the false triggering of the motor brake, but also can control the motor to stop running in time, effectively reducing the stall time of the door lock motor, thereby reducing the fatigue probability of the door lock motor, ensuring the performance and life of the motor, and reducing the impact on the door lock function.

[0084] See Figure 6 , Figure 6 This is a block diagram of a door lock motor control device shown in an exemplary embodiment of the present application. The device can be applied to Figure 2The implementation environment shown is shown. It should be understood that the device can also be applied to other exemplary implementation environments, and this embodiment does not limit the implementation environment to which the device is applicable.

[0085] In addition, the door lock motor control device can be embedded in a vehicle to implement door lock motor control in the vehicle. The door lock motor control device includes but is not limited to a vehicle system, an onboard computer, and the like.

[0086] like Figure 6 As shown, in an exemplary embodiment, a door lock motor control device 600 is applied to a door lock control system. The door lock control system includes a driver layer, a device abstraction layer, and an application layer. The door lock motor control device 600 includes at least a receiving module 610, a processing module 620, and a transmission module 630. The details are as follows:

[0087] Receiving module 610, used to receive the pawl status uploaded by the driving layer;

[0088] a processing module 620 configured to perform a first verification operation on the pawl state to obtain a first pawl state, and upload the pawl state as a second pawl state to the application layer, so that the application layer generates a motor braking instruction when a change in the second pawl state is detected;

[0089] The transmission module 630 is configured to send the motor braking instruction from the application layer to the driving layer if the first pawl state is the same as the second pawl state, so that the driving layer responds to the motor braking instruction and controls the door lock motor to stop running.

[0090] It should be noted that the door lock motor control device provided in the above embodiment and the door lock motor control method provided in the above embodiment belong to the same concept, and the contents of the operations performed by each module have been described in detail in the method embodiment and will not be repeated here.

[0091] See Figure 7 , Figure 7 This is a structural diagram of an electronic device provided by an embodiment of the present application. Figure 7 The following is a schematic diagram showing the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application. Figure 7 The computer system 700 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0092] like Figure 7As shown, the computer system 700 includes a central processing unit (CPU) 701 which can perform various appropriate actions and processes in accordance with a program stored in a read-only memory (ROM) 702 or a program loaded from the storage section 708 into a random access memory (RAM) 703, such as executing the method in the above-described embodiments. In the RAM 703, various programs and data required for the operation of the system are also stored. The CPU 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0093] Connected to the I / O interface 705 are an input section 706 including a keyboard, a mouse, etc.; an output section 707 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as necessary. A removable recording medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 710 as necessary, so that a computer program read therefrom is installed into the storage section 708 as necessary.

[0094] In particular, according to the embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments of the present application include a computer program product including a computer program carried on a computer-readable medium, the computer program containing a computer program for executing the method shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication section 709, and / or installed from the removable recording medium 711. When the computer program is executed by the central processing unit (CPU) 701, various functions defined in the system of the present application are executed.

[0095] The present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor of a computer, causes the computer to perform the door lock motor control method as described above. The computer-readable storage medium can be included in the electronic device described in the above embodiments, or can exist separately without being assembled into the electronic device.

[0096] It should be noted that the computer-readable medium shown in the embodiments of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable computer program. This propagated data signal can take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0097] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0098] The units described in the embodiments of the present application can be implemented in the form of software, or can be implemented in the form of hardware, and the described units can also be arranged in a processor. In some cases, the names of the units do not constitute a limitation on the units themselves.

[0099] The above-described embodiments are merely illustrative for the principles and effects of the present application, and are not intended to limit the present application. Any person skilled in the art can modify or change the above-described embodiments without departing from the spirit and scope of the present application. Therefore, all equivalent modifications or changes made by those skilled in the art without departing from the spirit and technical ideas disclosed by the present application should be covered by the claims of the present application.

Claims

1. A door lock motor control method, characterized in that: Applied to a door lock control system, the door lock control system includes a driver layer, a device abstraction layer, and an application layer. The method is configured in the device abstraction layer and includes: Receiving the pawl status uploaded by the driving layer; performing a first verification operation on the pawl state to obtain a first pawl state, and simultaneously uploading the pawl state as a second pawl state to the application layer, so that the application layer generates a motor braking instruction under the condition that the second pawl state is detected to change; If the first pawl state is the same as the second pawl state, the motor braking instruction from the application layer is sent to the driving layer, so that the driving layer controls the door lock motor to stop running in response to the motor braking instruction.

2. The door lock motor control method according to claim 1, characterized in that: The performing a first verification operation on the pawl state to obtain a first pawl state includes: Continuously receiving a plurality of third pawl states uploaded by the driving layer; If each of the third pawl states is the same as the second pawl state, a first pawl state that is the same as the second pawl state is obtained; If at least one of the third pawl states is opposite to the state of the second pawl state, a first pawl state opposite to the second pawl state is obtained.

3. The door lock motor control method according to claim 1, characterized in that: Before uploading the ratchet state as the second ratchet state to the application layer, the method further includes: Acquire duration information, where the duration information includes information transmission duration and processing duration, where the information transmission duration is the duration for completing information transmission with the application layer, and the processing duration is the duration for the application layer to generate the motor braking instruction; Determining a second verification duration according to a preset first verification duration, the information transmission duration, and the processing duration, wherein the first verification duration is the duration of the first verification operation, and the second verification duration is less than the first verification duration; A second verification operation is performed on the pawl state according to the second verification time to obtain the second pawl state.

4. The door lock motor control method according to claim 3, characterized in that: The performing a second verification operation on the pawl state according to the second verification time to obtain the second pawl state includes: within the second verification time period, continuously receiving a plurality of fourth pawl states uploaded by the driving layer; The second pawl state is determined under the condition that the plurality of fourth pawl states are the same, and the second pawl state is the same as the plurality of fourth pawl states.

5. The door lock motor control method according to claim 1, characterized in that: After uploading the ratchet state as the second ratchet state to the application layer, the method further includes: Get the motor operating temperature; Setting a standard duration after obtaining the second pawl state according to the motor operating temperature, wherein the standard duration is inversely proportional to the motor operating temperature; monitoring a real-time processing duration of the first verification operation; If the real-time processing duration is longer than the standard duration, the door lock motor control operation is exited.

6. The door lock motor control method according to any one of claims 1 to 5, characterized in that: After obtaining the first pawl state, the method further includes: If the first pawl state is opposite to the second pawl state, the transmission of the motor braking command is stopped and the motor braking command is reset.

7. The door lock motor control method according to claim 6, characterized in that: The application layer generates a motor braking instruction when detecting a change in the state of the second pawl, including: Get the historical pawl status uploaded by the device abstraction layer; If the second pawl state is opposite to the historical pawl state, the motor braking command is generated.

8. A door lock motor control device, characterized in that: Applied to a door lock control system, the door lock control system includes a driver layer, a device abstraction layer, and an application layer. The device is configured in the device abstraction layer, including: A receiving module, configured to receive the pawl status uploaded by the driving layer; a processing module, configured to perform a first verification operation on the pawl state to obtain a first pawl state, and upload the pawl state as a second pawl state to the application layer, so that the application layer generates a motor braking instruction when detecting a change in the second pawl state; The transmission module is used to send the motor braking instruction from the application layer to the driving layer if the first pawl state is the same as the second pawl state, so that the driving layer responds to the motor braking instruction and controls the door lock motor to stop running.

9. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the door lock motor control method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor of a computer, the computer is caused to execute the door lock motor control method according to any one of claims 1 to 7.

Images