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

Abstract

The invention provides a door lock motor control method and device, electronic equipment and a storage medium, and is applied to a door lock control system, the system comprises a driving layer, an equipment abstraction layer and an application layer, and the method comprises the following steps: receiving a pawl state uploaded by the driving layer; performing first verification operation on the pawl state to obtain a first pawl state, and meanwhile, uploading the pawl state as a second pawl state to an application layer to enable the application layer to generate a motor braking instruction under the condition that the application layer monitors that the second pawl state is changed; and if the first pawl state is the same as the second pawl state, a motor braking instruction from the application layer is issued to the driving layer, so that the driving layer responds to the motor braking instruction, and a door lock motor is controlled to stop running. According to the technical scheme, generation of the motor braking instruction and verification of the pawl state are executed synchronously, the motor can be controlled to stop running in time under the condition that motor braking false triggering is avoided, and the locked-rotor time of the door lock motor is effectively shortened.

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 automobile industry, automotive electronic control systems are becoming more and more complex and intelligent. As an important part of automobile safety, the reliability and response speed of the door lock system have a significant impact on the safety of the entire vehicle and the user experience. Traditional door lock control systems usually adopt a multi-layer software architecture based on SOA (Service-Oriented Architecture). This architecture runs in a periodic task mode, and a single SWC (Software Component) needs to execute software logic in cycles.

[0003] In related technologies, when this architecture faces complex functions that require multiple SWCs to work together, there is a time delay in the communication and data exchange between the SWCs, which greatly reduces the accuracy of time and makes it difficult to achieve functional requirements when precise timing control is required. In door lock motor control, it is necessary to accurately control the start, stop and stall time of the motor. However, due to the extended response time on the multi-layer software architecture, it is impossible to accurately control the stall time of the motor, so that the motor may work in a stalled state for a long time, increasing the probability of door lock motor fatigue, affecting the performance and life of the parts, and thus affecting the reliability of the door lock function. Summary of the invention

[0004] In view of the above-mentioned shortcomings of the prior art, 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 to the application layer as a second pawl state, 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 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 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 pawl state is obtained by performing a second verification operation on the pawl state according to the second verification duration, including: continuously receiving multiple fourth pawl states uploaded by the drive layer within the second verification duration; under the condition that the multiple fourth pawl states are the same, determining the second pawl state, the second pawl state being the same as 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 an 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 detecting 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, 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, which is used to receive the pawl state uploaded by the driver layer; a processing module, which is used to perform a first verification operation on the pawl state to obtain a first pawl state, and at the same time, upload the pawl state to the application layer as a second pawl state, 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, which is used to send 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 to control 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, when the one or more programs are executed by one or more processors, the electronic device implements 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 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 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 to the driver layer in sequence. On the basis of not affecting the current driving logic of the door lock motor, at the device abstraction layer, the verification operation and reporting operation of the pawl state are performed synchronously, so that the generation of the motor braking instruction and the verification of the pawl state 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 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 drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

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

[0020] Figure 2 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 It is a structural schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0026] The following will describe the implementation methods of the present application with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand 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 implementation methods, 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 illustrating the present application, not for limiting the scope of protection of the present application.

[0027] It should be noted that the illustrations provided in the following embodiments are only used to illustrate the basic concept of the present application in a schematic manner, and 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 form, quantity and proportion of each component may be changed arbitrarily, 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] At present, door lock control systems usually adopt a multi-layer software architecture based on SOA. This architecture runs in the form of periodic tasks, and a single SWC needs to execute software logic in cycles. In the door lock motor control, it is necessary to accurately control the start, stop and stall time of the motor. However, the inventors of this application have found that there is a time delay in the communication and data exchange between each SWC. Due to the extension of the response time on the multi-layer software architecture, the stall time of the motor cannot be accurately controlled, so that the motor may work in a long-term stalled state, which increases the probability of door lock motor fatigue, affects the performance and life of the parts, and thus affects the reliability of the door lock function.

[0030] See also Figure 1 , Figure 1FIG. 1 is a schematic diagram of a door lock control system according to an exemplary embodiment of the present application. Figure 1 As shown, the software architecture of the door lock control system based on the service-oriented architecture includes a driver layer, a device abstraction layer and an application layer, and the software architecture is used to realize the door lock control. Among them, the driver layer is responsible for collecting hardware signals, outputting driving 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 processing the logical control of the door lock function, and sending control signals based on hardware signals. The device abstraction layer passes the control signals sent by the application layer to the driver layer, and the driver layer controls the hardware according to the control signals. In the door lock motor control, the unlocking command or locking command sent by the application layer is sequentially transmitted to the driver layer, and the driver layer controls the motor to rotate to achieve unlocking or locking, and then the driver layer starts to collect the ratchet state and report it to the device abstraction layer. The device abstraction layer is responsible for reporting the ratchet state collected by the driver layer to the application layer, and the application layer performs the motor braking logic control, and sends instructions sequentially to the driver layer, so that the driver layer controls the motor to stop running.

[0031] The pawl state includes an unlocked state and a locked state. The unlocked state can be understood as the pawl being separated from the structure inside the lock body (such as the lock tongue or lock core), allowing the lock tongue to be retracted or the lock core to rotate, so that the door can be opened; the locked state can be understood as the pawl being tightly combined with the structure inside the lock body, preventing the lock tongue from extending or the lock core from rotating, so that the door remains closed and cannot be opened. When the door lock is unlocked, if the pawl state is unlocked, it means that the door lock is unlocked and the motor brake control can be performed. When the door lock is locked, if the pawl state is locked, it means that the door lock is locked and the motor brake control can be performed.

[0032] However, in the software architecture layer, it takes a certain amount of time for each layer to process signals, 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 affects the unlocking and locking functions of the normal door lock, the device abstraction layer will first verify the collected pawl state, and only report it after determining the final pawl state. The application layer implements 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 stalling time.

[0033] Taking the door lock unlocking drive as an example, after the application layer sends the unlocking command (such as doorLockCmd=1), the driver periodically (such as 10ms) collects the pawl status. After the application layer detects that the pawl is disengaged (i.e. released) (such as clawSigStatus=0 jumps to clawSigStatus=1), it immediately sends the generator braking command (such as doorLockCmd=3) and continues for a certain period of time (such as 200ms) to quickly control the motor to stop rotating, and waits for the lock tongue signal (secondarySigStatus=0 jumps to secondarySigStatus=1) and immediately sends the reset command (such as doorLockCmd=2) to drive the door lock motor to reset (reset to the reverse command of unlocking or locking drive). According to the structure of the lock body, after a certain period of time (such as 60ms) after the pawl is disengaged, the motor runs to the limit position and starts to stall. At the same time, it takes a certain period of time (such as 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 the subsequent door lock control. Stalling is one of the basic working conditions of a motor. A small amount of short-term stalling will not have much impact on the motor, but 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 has extremely high requirements on the timing accuracy of the software architecture. Taking the above 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, and at the same time, it is necessary to avoid motor stalling as much as possible. That is, the best braking command time is within 30-60ms after the pawl is disengaged.

[0034] If the driver collects the ratchet signal once in a Task with a cycle of 10ms and outputs the specific value of the signal, when the ratchet hardware is disengaged, there will be a delay of 0-10ms before the signal is collected into the Task according to the running status of the driver Task cycle. When the hardware status changes, the driver's 10ms Task may have just started running or has ended, but in any case, the current value will be sent to the Task for internal calculation at the beginning of the next Task, and the result will be sent to the device abstraction layer. The device abstraction layer also has a cycle of 10ms and will verify the value reported by the driver. For example, it will determine that the state has changed only after 5 identical values ​​are detected continuously. At this time, there will be a delay of 40-50ms for the verification time, and there will be an additional 0-10ms delay when the device abstraction layer reports to the application layer. After the application layer processes the logic, it will issue a generator braking command in the same Task. At this time, there will be a delay of 0-10ms for the device abstraction layer to receive the command, and there will be another 0-10ms delay for the driver layer to receive the command from the device abstraction layer. 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 of 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 also Figure 3 , Figure 3 is a flow chart of a door lock motor control method shown in an exemplary embodiment of the present application. The method can be applied to Figure 2 The implementation environment shown is a schematic diagram. It should be understood that the method may also be applicable 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 an unlocked state, it indicates that the door lock is unlocked. When the door lock is locked, if the pawl state is a locked state, 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] Step S320, 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 of detecting a change in the second pawl state.

[0042] In this embodiment, considering the false triggering of the motor braking command, the pawl state reported by the driver layer is verified at the abstract device layer, so as to ensure the reliability of the motor braking control. In addition, considering that the device abstract layer first verifies the pawl state, and then reports the verified pawl state to the application layer, the application layer generates and issues the motor braking command, which takes a long processing time, therefore, the device abstract layer synchronously performs the verification operation and reporting operation of the pawl state, so that the generation of the motor braking command and the verification of the pawl state are executed synchronously, thus reducing the waiting time of the verification operation and effectively reducing the stall time of the door lock motor.

[0043] In addition, the device abstraction layer performs a first verification operation on the pawl state and uploads the second pawl state to the application layer with a trigger condition, that is, the device abstraction layer triggers the verification operation and the upload operation of the pawl state after monitoring the change of 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, then it indicates that the pawl state has changed, and the pawl state verification operation and the pawl state upload operation are 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, 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, 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 drive 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. At this time, the first pawl state obtained 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 braking may be falsely triggered. Therefore, the first pawl state is set to be opposite to the second pawl state. In this way, the pawl state verification operation is performed by continuously receiving multiple pawl states to ensure the reliability of the motor braking control.

[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, 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 collections, at this time, the verified first pawl state clawSigStatusAfterFilter=0, which 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 demand or specific circumstances, and the number is not limited in this embodiment.

[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 to complete the 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 a preset first verification duration, information transmission duration and processing duration, a 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 a second pawl state.

[0050] Among them, the first verification duration 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 the state data only once is not reliable, the application layer will generate the motor braking instruction according to the wrong state change information, which occupies resources. Therefore, before the device abstraction layer reports, the pawl state is also preliminarily verified, that is, the second verification operation mentioned above, to avoid the waste of application layer resources while avoiding the false triggering of the motor braking.

[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 completing the generation operation of the motor braking instruction, 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 also verifies the pawl state before reporting. In this way, it will 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 a possible embodiment, the processing logic of the device abstraction layer is divided into two verification operation routes. After the device abstraction layer receives the changed ratchet state, one verification operation route performs a first verification operation, and the other verification operation route performs a second verification operation. The duration of the second verification operation is less than the duration of the first verification operation. The first verification operation of the device abstraction layer will be performed based on the first verification duration. After the second verification operation is completed, if the verification result meets the requirements, that is, the ratchet state has changed, the second ratchet state after the second verification operation is reported to the application layer, and the motor braking instruction 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 a second verification duration to obtain a second pawl state, including: continuously receiving multiple fourth pawl states uploaded by the drive layer within the second verification duration; 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 drive layer during the second verification operation, which are recorded as the fourth pawl state. 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 ensured.

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

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

[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 of the second verification time length 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, 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 that the first verification operation has not been completed for a long time due to a fault, or the driver layer uploads the pawl state as an erroneous trigger, resulting in the first verification operation being unable to be completed for a long time, therefore, 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 been unfinished 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, and only generate and issue a motor braking instruction if it has changed. 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 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 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 driving 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 is opposite to the second pawl state in that: when the door lock is unlocked, the first pawl state is a locked state and the second pawl state is an unlocked state, or, when the door lock is locked, the first pawl state is an unlocked state and the second pawl state is a locked state.

[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 timing sequence shown in 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 is used as an 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, which does not affect the current drive logic of the door lock, the verification time of the device abstraction layer, and the user perception. It reduces the stall time by 20ms for each unlocking. Similarly, it reduces the stall time by 20ms for each locking, greatly improving the performance and usability of the door lock motor and ensuring 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 jamming time of the vehicle door lock motor 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 also 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 of the car door as an example, the door unlocking is first triggered, and then the pawl state is received and the value of clawSigS is determined to be 1. If clawSigS=1 reported by the drive layer is not received within the preset time, the monitoring reception is performed again after the door unlocking is triggered next time. If clawSig=1 is received within the preset time, multiple pawl states are continued to be received. If clawSig=1 is satisfied for 2 consecutive cycles, clawSigStatus=1 is set and reported to the application layer, so as to obtain the motor braking instruction (such as preDoorLockCmd=3) issued by the application layer. At the same time, if clawSig=1 is satisfied for 5 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 drive layer to realize 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 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. 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 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 verification operation and reporting operation of the pawl state are synchronously performed, so that the generation of the motor braking instruction and the verification of the pawl state 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 also Figure 6 , Figure 6 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 a schematic diagram. It should be understood that the device may also be applicable 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 computer system, a vehicle-mounted computer, and the like.

[0086] like Figure 6 As shown, in an exemplary embodiment, the 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, and the door lock motor control device 600 includes at least a receiving module 610, a processing module 620 and a transmission module 630, which are described in detail as follows:

[0087] A receiving module 610 is used to receive the pawl status uploaded by the driving layer;

[0088] The processing module 620 is used to perform a first verification operation on the pawl state to obtain a first pawl state, and at the same time, upload 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 changes;

[0089] The transmission module 630 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.

[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, wherein 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 also Figure 7 , Figure 7 It is a structural schematic diagram of an electronic device provided by an embodiment of the present application. Figure 7 The structure diagram of the computer system suitable for implementing the electronic device of the embodiment of the present application is shown. It should be noted that: 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, computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to the program stored in read-only memory (ROM) 702 or the program loaded from storage part 708 to random access memory (RAM) 703, such as executing the method in the above embodiment. In RAM 703, various programs and data required for system operation are also stored. CPU 701, ROM 702 and RAM 703 are connected to each other through bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0093] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including 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 needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed so that a computer program read therefrom is installed into the storage section 708 as needed.

[0094] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 709, and / or installed from a removable medium 711. When the computer program is executed by a 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 on which a computer program is stored. When the computer program is executed by a processor of a computer, the computer executes the door lock motor control method as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0096] It should be noted that the computer-readable medium shown in the embodiment 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 may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. 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, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. A computer program contained on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0097] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order 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 a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0098] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0099] The above embodiments are merely illustrative of the principles and effects of the present application, and are not intended to limit the present application. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present application. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed in the present application shall still 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, and the method includes: Receiving the pawl status uploaded by the driving layer; Performing a first verification operation on the ratchet state to obtain a first ratchet state, and at the same time, uploading the ratchet state as a second ratchet state to the application layer, so that the application layer generates a motor braking instruction under the condition that the second ratchet 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 responds to the motor braking instruction and controls the door lock motor to stop running.

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, the duration information including information transmission duration and processing duration, 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; Determine 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; Under the condition that the plurality of fourth pawl states are the same, the second pawl state is determined, 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; A standard duration after the second pawl state is obtained is set according to the motor operating temperature, wherein 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 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 that the state of the second pawl changes, 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, and the device includes: A receiving module, used for receiving the pawl status uploaded by the driving layer; a processing module, configured to perform a first verification operation on the ratchet state to obtain a first ratchet state, and upload the ratchet state as a second ratchet state to the application layer, so that the application layer generates a motor braking instruction under the condition that the second ratchet state is detected to change; The transmission module is used for sending 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, when the one or more programs are executed by the one or more processors, enables the electronic device to implement the door lock motor control method as described in 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 as described in any one of claims 1 to 7.

Images