Child lock state determination method and system, computing device and program product

Abstract

The invention provides a child lock state determination method and system, computing equipment and a program product, and the method applied to a central computing processing unit (CCU) in an intelligent cabin domain comprises the steps: receiving a lock command request; the lock command request is used for requesting to control a child lock on a target vehicle door; the lock command request is sent to a domain control unit LCU corresponding to the target vehicle door in a vehicle body domain; receiving lock state information reported by the LCU; the lock state information is used for indicating the on-off state of the child lock and the validity of a lock command; determining request feedback information corresponding to the lock command request according to the lock state information; the request feedback information is used for indicating whether the child lock has a fault or not.

Description

Technical Field

[0001] The present disclosure relates to the field of vehicle engineering technology, and in particular to a method, system, computing device and program product for determining a child lock state. Background Art

[0002] The car child lock, also known as the car door lock child insurance, is set on the rear door lock of the car. Its function is to prevent children from opening the door while driving when there are children in the back seat of the vehicle, thereby avoiding danger. Usually, the command control of the child lock can be realized by the door control module (DCM) in the smart cabin domain. The control result of the door control module determines the status of the child lock (for example, switch status, fault status, etc.). By displaying the status of the child lock on the human-computer interaction interface of the vehicle (such as the central control screen), it can help the driver quickly understand the current status of the child lock.

[0003] However, the method of using the door control module to control the child lock often causes the problem of misreporting the child lock status, for example, misreporting a non-fault status as a fault status, which affects the accuracy of determining the child lock status. Summary of the invention

[0004] The embodiments of the present disclosure at least provide a method, system, computing device, and program product for determining a child lock state.

[0005] In a first aspect, an embodiment of the present disclosure provides a child lock state method, which is applied to a central computing processing unit CCU in a smart cockpit domain, including:

[0006] Receiving a lock command request; the lock command request is used to request control of a child lock on a target vehicle door;

[0007] Sending the lock command request to a domain control unit LCU corresponding to the target door in the vehicle body domain;

[0008] Receiving lock status information reported by the LCU; the lock status information is used to indicate the switch status of the child lock and the validity of the lock command;

[0009] Request feedback information corresponding to the lock command request is determined according to the lock status information; the request feedback information is used to indicate whether the child lock has a fault.

[0010] This implementation uses the CCU in the smart cockpit domain and the LCU in the body domain to replace the door control module, and realizes the command control and status feedback of the child lock under the new domain control architecture, which plays a role in decoupling command control, status feedback and status display. In addition, by obtaining the lock status information indicating the lock command validity and switch status reported by the LCU, the CCU can accurately determine whether the state discrepancy is caused by a non-electrical fault of the lock based on whether the lock command request indicated by the lock command validity is executed when the switch state does not match the state expected by the lock command request, thereby accurately determining whether the child lock is actually faulty and avoiding the problem of false child lock status alarm.

[0011] In a possible implementation manner, the lock status information is also used to indicate circuit status diagnosis information and error feedback information of the child lock;

[0012] The determining, according to the lock state information, request feedback information corresponding to the lock command request includes:

[0013] When the lock command validity indicates that the circuit status diagnostic information is valid, the request feedback information is determined according to the lock circuit status indicated by the circuit status diagnostic information, whether there is an error in the child lock indicated by the error feedback information, the switch status, and whether the lock command request indicated by the lock command validity is executed.

[0014] In this implementation, based on the validity of the lock command, it can be determined whether the switch state is inconsistent with the state expected by the lock command request due to a non-electrical fault of the lock, and based on the lock circuit state and error feedback information, it can be determined whether the switch state is inconsistent with the state expected by the lock command request due to an electrical fault of the lock. Therefore, using the lock command validity, lock circuit state and error feedback information, it is not only possible to accurately determine whether the child lock is actually faulty, avoiding the problem of false child lock state alarms, but also to help quickly locate the cause of the fault.

[0015] In a possible implementation manner, receiving the lock state information reported by the LCU includes:

[0016] Receiving lock status information periodically reported by the LCU;

[0017] The determining, according to the lock state information, request feedback information corresponding to the lock command request includes:

[0018] Filtering target lock state information from each piece of the lock state information according to the reporting time of each piece of the lock state information reported periodically and the maximum allowed execution time after the lock command request is issued;

[0019] Request feedback information corresponding to the lock command request is determined according to the target lock state information.

[0020] In this implementation, the lock state information is screened using the maximum allowed execution time, so that the target lock state information that best matches the lock command request can be screened out, and relatively accurate request feedback information can be determined using the target lock state information.

[0021] In a possible implementation manner, the step of sending the lock command request to a domain control unit LCU corresponding to the target door in the vehicle body domain includes:

[0022] determining, based on the most recently received lock status information, whether the child lock on the target door is faulty;

[0023] If not, the lock command request is sent to the LCU corresponding to the target door in the vehicle body domain.

[0024] In this implementation, a lock command request is issued when it is determined that there is no fault in the child lock, thereby avoiding a waste of computing resources of the LCU.

[0025] In a possible implementation, determining, according to the lock state information, request feedback information corresponding to the lock command request includes:

[0026] When it is determined according to the lock status information that the child lock has no fault and the lock command validity indicates that the lock command request has not been executed, return to the step of sending the lock command request to the domain control unit LCU corresponding to the target door in the vehicle body domain until it is determined according to the lock status information that the child lock has a fault or the number of cycles reaches the target number or the lock command request is executed, and the request feedback information is determined.

[0027] In this implementation, when there is no fault in the child lock and the lock command request is not executed, it can be explained that the lock command is interrupted by other tasks with higher priority. Therefore, by resending the lock command request to the LCU, an attempt can be made to re-control the child lock, thereby achieving timely control of the child lock state to the expected state that meets the lock command request.

[0028] In a possible implementation manner, the step of sending the lock command request to a domain control unit LCU corresponding to the target door in the vehicle body domain includes:

[0029] If there is a first domain control command request related to the LCU corresponding to the target door, determining a first execution order of the lock command request compared to each of the first domain control command requests;

[0030] According to the first execution order, the lock command request is sent to the LCU corresponding to the target door.

[0031] In this implementation manner, the lock command request is sent to the LCU according to the priority of the lock command request over the first domain control command request, which can improve the rationality of sending the lock command request.

[0032] In a second aspect, an embodiment of the present disclosure further provides a method for determining a child lock state, which is applied to a domain control unit LCU in a vehicle body domain, wherein the LCU is deployed at a target door, and the method comprises:

[0033] Receiving a lock command request sent by a central computing processing unit CCU in the smart cockpit domain; the lock command request is used to request control of a child lock on the target door;

[0034] When the execution timing of the driving logic matching the lock command request is reached, the driving logic is executed, and the validity of the lock command is determined according to the execution result of the driving logic;

[0035] Lock status information is generated according to the lock command validity and the switch status of the child lock acquired in real time, and the lock status information is sent to the CCU.

[0036] In this implementation manner, the LCU can help the CCU to accurately determine whether the state discrepancy is caused by a non-electrical fault of the lock by reporting lock state information indicating the lock command validity and the switch state when the switch state does not match the state expected by the lock command request, based on whether the lock command request indicated by the lock command validity is executed, thereby achieving accurate determination of whether the child lock is actually faulty and avoiding the problem of false alarm of the child lock state.

[0037] In a possible implementation, determining the validity of the lock command according to the execution result of the driving logic includes:

[0038] Determining the validity of the lock command according to the execution result of the driving logic and the execution result of the circuit state diagnosis;

[0039] The generating lock status information according to the lock command validity and the switch status of the child lock acquired in real time includes:

[0040] The lock status information is generated according to the validity of the lock command, the circuit status diagnosis information of the child lock collected in real time, the error feedback information and the switch status.

[0041] This implementation method combines the execution results of the circuit status diagnosis and the execution results of the drive logic to determine the validity of the lock command, which can help the CCU to determine and report the fault only when it determines that the circuit diagnosis of the child lock is effective, thereby improving the rationality of the fault reporting.

[0042] In a possible implementation manner, the execution timing of the driving logic matching the lock command request is determined according to the following steps:

[0043] If there is currently a second domain control command request related to the LCU corresponding to the target door, determining a second execution order of the lock command request compared to each of the second domain control command requests;

[0044] According to the second execution order, the execution timing of the driving logic is determined.

[0045] In this implementation, the lock command request is executed according to the priority of the lock command request compared with each second domain control command request, which can improve the rationality of the execution of the lock command request.

[0046] In a third aspect, a child lock state determination system includes a central computing processing unit CCU in a smart cockpit domain and a domain control unit LCU in a vehicle body domain, wherein the LCU is deployed at a target vehicle door, wherein:

[0047] The CCU is configured to: receive a lock command request and send the lock command request to the LCU corresponding to the target door; the lock command request is used to request control of the child lock on the target door; and receive lock status information reported by the LCU and determine request feedback information corresponding to the lock command request according to the lock status information; the request feedback information is used to indicate whether the child lock has a fault;

[0048] The LCU is configured to: receive a lock command request sent by the CCU; execute the drive logic when the execution timing of the drive logic matching the lock command request is reached, and determine the validity of the lock command according to the execution result of the drive logic, and generate lock status information according to the validity of the lock command and the switch status of the child lock collected in real time, and send the lock status information to the CCU.

[0049] In a fourth aspect, an optional implementation of the present disclosure further provides a computer device, a processor, and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is used to execute the machine-readable instructions stored in the memory, and when the machine-readable instructions are executed by the processor, the steps in the first aspect or any possible implementation of the first aspect are executed; or, when the machine-readable instructions are executed by the processor, the steps in the second aspect or any possible implementation of the second aspect are executed.

[0050] In a fifth aspect, an optional implementation of the present disclosure further provides a computer program product, which, when run, executes the steps of the above-mentioned first aspect, or any possible implementation of the first aspect; or, the computer program product, when run, executes the above-mentioned second aspect, or any possible implementation of the second aspect.

[0051] For a description of the effects of the above-mentioned child lock state determination system, computer device, and computer program product, please refer to the description of the above-mentioned child lock state determination method, which will not be repeated here.

[0052] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following is a brief introduction to the drawings required for use in the embodiments. The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present disclosure and are used together with the specification to illustrate the technical solutions of the present disclosure. It should be understood that the following drawings only illustrate certain embodiments of the present disclosure and should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can also be obtained based on these drawings without creative work.

[0054] Figure 1 A flow chart of a method for determining a child lock state applied to a CCU provided by an embodiment of the present disclosure is shown;

[0055] Figure 2 A flow chart of a method for determining a child lock state applied to an LCU provided by an embodiment of the present disclosure is shown;

[0056] Figure 3 A system block diagram of a child lock state determination process provided by an embodiment of the present disclosure is shown;

[0057] Figure 4 A schematic diagram of the structure of a child lock state determination system provided by an embodiment of the present disclosure is shown;

[0058] Figure 5 A schematic diagram of the structure of a computer device provided by an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical scheme and advantages of the embodiments of the present disclosure clearer, the technical scheme in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all of the embodiments. The components of the embodiments of the present disclosure generally described and shown here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present disclosure is not intended to limit the scope of the present disclosure claimed for protection, but merely represents the selected embodiments of the present disclosure. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present disclosure.

[0060] In addition, the terms "first", "second", etc. in the description and claims of the embodiments of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein.

[0061] The "multiple or several" mentioned in this article refers to two or more. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects are in an "or" relationship.

[0062] After research, it was found that the current child lock control is that the intelligent cockpit domain controller sends the lock control command to the door control module, which then executes and feeds back the result. If the door control module executes the lock control command normally and the child lock status is switched to the desired state, it will report the normal status. If the door control module does not execute the lock control command, after reaching the maximum command execution time, the door control module will directly report the fault status, but at this time it may be because the lock control command is interrupted by other high-priority commands, rather than the child lock actually having a fault, so directly reporting the fault status will cause the problem of false status reporting. Therefore, how to avoid false reporting of the child lock status has become a technical issue worthy of attention.

[0063] Based on the above research, the present disclosure provides a method, system, computing device and program product for determining the state of a child lock, which uses the CCU in the smart cockpit domain and the LCU in the body domain to replace the door control module, and realizes the command control and state feedback of the child lock under a new domain control architecture, playing the role of decoupling command control, state feedback and state display. In addition, by obtaining the lock state information indicating the validity of the lock command and the switch state reported by the LCU, the CCU can accurately determine whether the state is caused by a non-electrical fault of the lock according to whether the lock command request indicated by the lock command validity is executed when the switch state does not match the state expected by the lock command request, thereby accurately determining whether the child lock is actually faulty and avoiding the problem of false alarm of the child lock state.

[0064] The defects existing in the above solutions are the results obtained by the inventor after practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed by the present disclosure for the above problems below should be the contributions made by the inventor to the present disclosure during the disclosure process.

[0065] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.

[0066] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0067] It should be noted that the specific terms mentioned in the embodiments of the present disclosure include:

[0068] HMI: Human Machine Interface, refers to the vehicle's large screen and other related display devices;

[0069] CDC: Cockpit Domain Controller, as the brain of HMI, all interactive information can be processed by CDC;

[0070] CCU: Central Computer Unit, which can be used to make logical judgments and send command requests to LCU for execution;

[0071] LCU: Location Control Unit, domain control unit, located in the vehicle body domain, is mainly used for function execution. In this application, it can be used to control the functions of child locks and door locks.

[0072] To facilitate understanding of this embodiment, a child lock status determination method disclosed in an embodiment of the present disclosure is first introduced in detail. The executor of the child lock status determination method provided in the embodiment of the present disclosure is generally a terminal device or other processing device with certain computing capabilities, wherein the terminal device may be a user equipment (User Equipment, UE), a mobile device, a user terminal, a terminal, a personal digital assistant device (Personal Digital Assistant, PDA), a handheld device, a computer device, a domain controller in a vehicle, a functional module in a domain controller, etc.; in some possible implementation methods, the child lock status determination method may be implemented by a processor calling computer-readable instructions stored in a memory.

[0073] The method for determining the child lock state provided by the embodiment of the present disclosure is described below by taking the execution subject as the central computing processing unit CCU in the smart cockpit domain as an example.

[0074] like Figure 1 As shown, it is a flowchart of a method for determining a child lock state applied to a CCU provided by an embodiment of the present disclosure, which may include the following steps:

[0075] S101: receiving a lock command request; the lock command request is used to request control of a child lock on a target vehicle door.

[0076] Here, the lock command request may be a request initiated by a vehicle occupant through voice or HMI screen, and the request is used to control the child lock on the target door. The vehicle occupant may be the vehicle driver or other person riding in the vehicle. Usually, the child lock is installed on the left rear door and / or the right rear door of the vehicle, so the target door may be the left rear door and / or the right rear door of the vehicle.

[0077] In specific implementation, the CCU in the CDC can receive a lock command request from the HMI screen or user voice. For example, a vehicle occupant can trigger the opening or closing control of the child lock through the HMI screen, and the CCU can receive a lock command request based on the trigger operation. Alternatively, the vehicle occupant can speak a voice command to open or close the child lock, and the CCU can obtain a lock command request based on the voice command. Among them, the lock command request can be represented by ChdLockReq, which can specifically include two value types: locking and unlocking.

[0078] S102: Send a lock command request to a domain control unit LCU corresponding to the target door in the vehicle body domain.

[0079] In the disclosed embodiment, a CCU is provided in the smart cockpit domain, and an LCU can be provided on the left rear door and the right rear door respectively, wherein the LCU of the left rear door is represented by LCU-L, and the LCU of the right rear door is represented by LCU-R. Both LCU-L and LCU-R are located in the body domain.

[0080] In specific implementation, the CCU can parse the lock command request, determine the target door where the child lock requested to be controlled by the lock command request is located, and then send the lock command request to the LCU corresponding to the target door. For example, RLChdLockCmd can be used to represent the lock command for the child lock of the left rear door, and RRChdLockCmd can be used to represent the lock command for the child lock of the right rear door. Among them, RLChdLockCmd and RRChdLockCmd can both include two class value types: locking and unlocking.

[0081] When the CCU determines that the lock command request is for the child lock for the left rear door, RLChdLockCmd can be sent to the LCU-L; when the CCU determines that the lock command request is for the child lock for the right rear door, RRChdLockCmd can be sent to the LCU-R.

[0082] S103: receiving lock status information reported by the LCU; the lock status information is used to indicate the switch status of the child lock and the validity of the lock command.

[0083] Here, the switch state is used to indicate whether the child lock is in an unlocked state or a locked state, and can be represented by XXChdLockSts, where RL / RRChdLockSts represent the switch state of the left rear / right rear child lock, respectively. The lock command validity is used to indicate whether the lock command request is valid, which is specifically reflected in whether the drive logic corresponding to the lock command request has not been fully executed by the LCU because it is interrupted by other high-priority commands. In the embodiment of the present disclosure, the flag bit "XXChdLockCmdValid" of the child lock command execution is designed to identify the validity of the lock command. When the LCU successfully receives the lock command request and executes the complete drive logic and / or circuit status diagnosis, the flag bit will be set to valid, otherwise it will be set to invalid. Among them, since the child lock exists in the child lock of the left rear door and the child lock of the right rear door, the flag bit "XXChdLockCmdValid" can include the flag bit "RLChdLockCmdValid" of the left rear child lock command execution and the flag bit "RRChdLockCmdValid" of the right rear child lock command execution.

[0084] In specific implementation, the LCU can cache the lock command request and execute the motor drive logic for the child lock, thereby realizing the opening and closing lock control of the child lock. After receiving the lock command request, the LCU can execute the drive logic when the execution timing of the drive logic matching the lock command request is reached, and determine the validity of the lock command (that is, determine the flag of the child lock) according to the execution result of the drive logic, and collect the real-time switch status of the child lock. According to the lock command validity and the switch status, the lock status information is generated and fed back to the CCU. Among them, the execution timing can be a timing for determining the execution of the lock command request, which can be determined according to the priority of the lock command request compared to other domain control command requests synchronously received by the LCU, and the safe driving rules. Among them, the safe driving rules can be pre-specified, and the embodiments of the present disclosure are not specifically limited. For example, when the current vehicle is driving at high speed, even if a lock command request to close the child lock is received, it will not be executed because it does not meet the safe driving rules, and thus the execution timing will not be reached.

[0085] It should be noted that the LCU can periodically report lock status information to the CCU according to a preset cycle. Therefore, when a certain reporting cycle is reached, if the execution timing of the drive logic has not been reached, the lock command validity will indicate that the lock command request has not been executed.

[0086] S104: Determine request feedback information corresponding to the lock command request according to the lock state information; the request feedback information is used to indicate whether the child lock has a fault.

[0087] Here, the request feedback information is used to indicate whether the child lock has a fault and the current switch state of the child lock.

[0088] In specific implementation, after receiving the lock status information, the CCU can determine whether the child lock has a fault according to the switch status indicated by the lock status information, whether it is consistent with the expected state that the child lock needs to reach as requested by the lock command, and the validity of the lock command indicated by the lock status information. For example, when the switch status of the child lock is consistent with the expected state, and the drive logic corresponding to the lock command request is fully executed, it can be determined that the request feedback information is that there is no fault in the child lock and the switch status is the expected state; when the switch status of the child lock is inconsistent with the expected state, and the drive logic corresponding to the lock command request is not fully executed, it can be determined that the request feedback information is that there is no fault in the child lock and the switch status is the switch status indicated by the lock command request; when the switch status of the child lock is inconsistent with the expected state, and the drive logic corresponding to the lock command request is fully executed, it can be determined that the request feedback information is that there is a fault in the child lock and the switch status is the expected state.

[0089] Exemplarily, truth tables corresponding to various lock status information and various lock command requests may be preset. After the CCU obtains the lock status information, a table lookup operation may be performed according to the lock status information and the lock command request to obtain request feedback information.

[0090] The request feedback information can be used to indicate the information to be displayed on the HMI large screen. For example, under different request feedback information, different display modes can be used to characterize the child lock status, thereby helping vehicle occupants to quickly and intuitively understand the switch status and fault status of the child lock. The large screen display strategy corresponding to the request feedback information can be set according to actual development needs, and the embodiments of the present disclosure do not specifically limit it.

[0091] Exemplarily, when the lock command request is RLChdLockCmd for the child lock of the left rear door, the CCU can send RLChdLockCmd to the LCU-L. LCU-L can execute the drive logic when the execution timing of the drive logic matching the lock command request is reached, and determine the value of RLChdLockCmdValid according to the execution result of the drive logic, and collect the real-time switch status of the child lock. According to the value of RLChdLockCmdValid and the switch status of the child lock, the lock status information is generated and sent to the CCU. Then, the CCU can determine the request feedback information based on the lock status information and feed the request feedback information upward. Finally, the display of the left rear child lock status can be controlled on the HMI large screen according to the large screen display strategy and the request feedback information.

[0092] When the lock command request is RRChdLockCmd for the child lock of the right rear door, the CCU can send RRChdLockCmd to the LCU-R. LCU-R can execute the drive logic when the execution timing of the drive logic matching the lock command request is reached, and determine the value of RRChdLockCmdValid according to the execution result of the drive logic, and collect the real-time switch status of the child lock. According to the value of RRChdLockCmdValid and the switch status of the child lock, the lock status information is generated and sent to the CCU, and then the CCU can determine the request feedback information according to the lock status information and feed the request feedback information upward. Finally, the display of the right rear child lock status can be controlled on the HMI large screen according to the large screen display strategy and the request feedback information. Among them, the upward feedback process can, for example, use the CCU to send the request feedback information to the microcontroller (MicroController Unit, MCU), which is routed by the MCU to the microprocessor unit (Micro Processor Unit, MPU) service, and then reported by the MPU service for display processing.

[0093] In this way, the lock status feedback party (ie, LCU) and the lock status judgment party (ie, CCU) serve as domain control units in different domains, so the logical decoupling of child lock control and status judgment can be achieved by using LCU and CCU.

[0094] In one embodiment, the lock status information is also used to indicate the circuit status diagnostic information and error feedback information of the child lock. The circuit status diagnostic information is used to characterize the circuit status information of the lock circuit of the child lock, for example, the current, voltage, open circuit state, short circuit state and other information of the circuit. The circuit status diagnostic information can be represented by XXChdLockDiag, where RL / RRChdLockDiag respectively represents the circuit status diagnostic information of the left rear / right rear child lock.

[0095] The error feedback information is used to indicate whether there is a problem with the lock circuit of the child lock. This information is related to the circuit status diagnostic information. The error feedback information can be represented by XXChdLockErrFb, where RL / RRChdLockErrFb represents the error feedback information of the left rear / right rear child lock, respectively.

[0096] That is, in the embodiment of the present disclosure, the lock status information may include the switch status of the child lock XXChdLockSts, the lock command validity XXChdLockCmdValid, the circuit status diagnostic information XXChdLockDiag, and the error feedback information XXChdLockErrFb.

[0097] Circuit status diagnosis information and error feedback information can be obtained by LCU performing circuit diagnosis and error status collection on the child lock in real time.

[0098] In specific implementation, when the LCU receives a lock command request, if the execution timing of the lock command request is reached, the drive logic matching the lock command request will be executed, and the circuit of the child lock will be diagnosed. When the complete drive logic is executed and the circuit diagnosis is completed, the value of XXChdLockCmdValid will be set to valid; if the complete drive logic is not executed and the circuit diagnosis is completed, the value of XXChdLockCmdValid will be set to invalid; if the complete drive logic is executed but the circuit diagnosis is not completed, the value of XXChdLockCmdValid will be set to unknown unknow; if the complete drive logic is not executed and the circuit diagnosis is not completed, the value of XXChdLockCmdValid will be set to unknow.

[0099] In addition, when the LCU receives a lock command request, if the execution timing of the lock command request has not been reached, only the circuit of the child lock will be diagnosed. If the circuit diagnosis is completed, the value of XXChdLockCmdValid will be set to invalid; if the circuit diagnosis is not completed, the value of XXChdLockCmdValid will be set to unknow or a reserved value.

[0100] If the lock command request is not received, only the circuit of the child lock will be diagnosed. If the circuit diagnosis is completed, the value of XXChdLockCmdValid will be set to invalid; if the circuit diagnosis is not completed, the value of XXChdLockCmdValid will be set to unknow or a reserved value. Therefore, it can be seen that the lock command validity in the embodiment of the present disclosure can not only be used to indicate whether the lock command request is valid, but also to indicate whether the circuit diagnosis is completed. If the circuit diagnosis is completed, it can be said that the circuit status diagnosis information is valid. If the circuit diagnosis is not completed, it can be said that the circuit status diagnosis information is invalid.

[0101] The above S104 can be implemented according to the following steps:

[0102] When the lock command validity indication circuit status diagnostic information is valid, the request feedback information is determined based on the lock circuit status indicated by the circuit status diagnostic information, whether there is an error in the child lock indicated by the error feedback information, the switch status, and whether the lock command request indicated by the lock command validity indication is executed.

[0103] Exemplarily, when the lock command validity is valid or invalid, it can indicate that the circuit status diagnostic information is valid. In this case, it can be determined whether the lock circuit has a fault according to the lock circuit state indicated by the circuit status diagnostic information. If so, it can be directly determined whether the child lock has a fault. If not, it can be determined whether the child lock has a fault according to whether the child lock has an error indicated by the error feedback information. For example, if there is an error in the child lock, it can be determined that the child lock has a fault. If there is no error in the child lock, it can be determined whether the child lock has a fault according to whether the switch state and the expected state are consistent, and whether the lock command request indicated by the lock command validity is executed. According to the judgment result of whether the child lock has a fault and the switch state of the child lock, the request feedback information corresponding to the child lock is determined.

[0104] On the contrary, when the lock command validity is unknown or a reserved value, it can indicate that the circuit status diagnostic information is invalid, and then it can be directly determined whether the child lock has a fault based on whether the switch state matches the expected state. Alternatively, when the lock command validity indicates that the circuit status diagnostic information is invalid, the switch state of the child lock can be directly used as the request feedback information without performing fault reporting.

[0105] Optionally, after determining whether the child lock is faulty and the switch status of the child lock based on the lock status information, the value of the child lock error status XXChdLockFltSts can be set according to the result, and the value is used to represent the request feedback information and feedback upward. Among them, RL / RRChdLockFltSts respectively represent the left rear / right rear child lock error status, which can often be used in the case where the lock command request cannot be implemented. When there is a lock command request, if it is determined whether the child lock is faulty based on the periodically reported lock status information, XXChdLockFltSts can be used for reporting, or it can be reported directly without using XXChdLockFltSts.

[0106] In one embodiment, for any LCU set, regardless of whether the LCU receives a lock command request from the CCU, the LCU can collect lock status information in real time and periodically report the collected lock status information. Among them, the reporting period can be a preset period. The LCU can determine the real-time lock status information based on the switch status, lock command validity, circuit status diagnostic information and error feedback information collected in real time, and send the real-time determined lock status information to the CCU according to the preset period. Therefore, the CCU can receive the lock status information periodically reported by the LCU. In the case that the CCU does not receive the lock command request, the CCU can feedback the switch status in the lock status information received in real time, and determine whether the child lock has a fault and feedback it upward based on the circuit status diagnostic information and error feedback information received in real time. In the case that the CCU receives a lock command request and sends it to the LCU, the CCU can determine the request feedback information of the child lock based on all the information in the lock status information received in real time and feedback it upward.

[0107] After the CCU sends the lock command request to the LCU, the CCU can still receive the lock status information periodically reported by the LCU. At this time, S104 can be implemented according to the following steps:

[0108] According to the reporting time of each periodically reported lock status information and the maximum allowed execution time after the lock command request is issued, the target lock status information is filtered from each lock status information; according to the target lock status information, the request feedback information corresponding to the lock command request is determined.

[0109] Here, the maximum allowed execution time can be set based on experience, and the embodiment of the present disclosure does not specifically limit it. For example, the maximum allowed execution time can be 2s, 3s, etc.

[0110] During specific implementation, after the CCU sends the lock command request to the LCU, it can count according to the maximum allowed execution time. For example, the timing is 3s. During the timing period, the CCU can receive the lock status information periodically reported by the LCU. At the end of the timing, the CCU can determine the lock status information that is within the timing period and has the latest reporting time based on the reporting time of each lock status information reported periodically, and use the lock status information as the target lock status information. That is, the lock status information last received before the end of the timing can be used as the target lock status information. Then, the CCU can determine the request feedback information and feed it back upward based on the switch status, lock command validity, circuit status diagnostic information and error feedback information in the target lock status information. Regarding the steps of determining the request feedback information based on the target lock status information, please refer to the introduction of the above-mentioned embodiments, which will not be repeated here.

[0111] In an embodiment, the above S102 may also be implemented according to the following steps:

[0112] S102-1: Determine whether the child lock on the target door is faulty based on the most recently received lock status information.

[0113] S102 - 2 : If not, a lock command request is sent to the LCU corresponding to the target door in the vehicle body domain.

[0114] Here, the most recently received lock status information may be the most recently received lock status information related to the child lock of the target door before the lock status request for the target door is issued.

[0115] In specific implementation, the CCU can determine whether the child lock of the target door is faulty based on XXChdLockDiag in the most recently received lock status information. If so, the request feedback information indicating that the child lock is faulty can be directly fed back upward. If not, the lock command request can be sent to the LCU corresponding to the target door. Alternatively, in the case where it is determined that the child lock of the target door is not faulty based on XXChdLockDiag, it can also be determined based on XXChdLockSts in the most recently received lock status information whether the current switch state of the child lock of the target door is consistent with the expected state corresponding to the lock command request. If so, the expected state can be directly fed back upward as the request feedback information. If not, the lock command request can be sent to the LCU corresponding to the target door.

[0116] In one embodiment, S104 may also be implemented according to the following steps:

[0117] When it is determined according to the lock status information that there is no fault in the child lock and the lock command validity indicates that the lock command request has not been executed, return to the step of sending the lock command request to the domain control unit LCU corresponding to the target door in the vehicle body domain until it is determined according to the lock status information that there is a fault in the child lock or the number of cycles reaches the target number or the lock command request is executed, and the request feedback information is determined.

[0118] Here, the target number of times can be set based on experience, and the present disclosure embodiment does not specifically limit it. For example, the target number of times can be 1 time, 2 times, 3 times, etc.

[0119] In specific implementation, after the CCU sends the lock command request to the LCU corresponding to the target door, it can start the timing, and then obtain the corresponding target lock status information when the timing ends. If the target lock status information indicates that the switch state of the child lock has not jumped to the expected state corresponding to the lock command request, there is no fault in the child lock, and the lock command validity indicates that the lock command request has not been executed, the lock command request can be resent to the domain control unit LCU corresponding to the target door (that is, a retry command is executed) until it is determined according to the subsequently received lock status information that there is a fault in the child lock or the number of cycles reaches the target number or the lock command validity indicates that the lock command request is executed, and the final request feedback information is obtained and fed back upward.

[0120] Optionally, after the lock command request is sent to the LCU, after the timing ends, the final request feedback information can be directly determined according to the target lock state information, and no retry operation will be performed.

[0121] In one embodiment, for S102, it can also be implemented according to the following steps: if there is a first domain control command request related to the LCU corresponding to the target door, determine the first execution order of the lock command request compared to each first domain control command request; according to the first execution order, send the lock command request to the LCU corresponding to the target door.

[0122] Here, the first domain control command request and the lock command request can be requests that are synchronously acquired by the CCU and need to be sent to the LCU corresponding to the target door for processing. The first domain control command request can be, for example, a door control command request for the vehicle occupant to release the electric door when the electric door is closed, other command requests for child locks, etc.

[0123] The first execution order is used to indicate the execution order between the lock command request and each first domain control command request in the CCU.

[0124] In specific implementation, when the CCU receives a lock command request for the child lock on the target door, if there are no other domain control command requests that need to be executed by the LCU of the target door at this time, the lock command request can be directly sent to the LCU corresponding to the target door for execution. If the CCU also simultaneously receives other domain control command requests that need to be executed by the LCU of the target door (these domain control command requests can be defined as first domain control command requests), at this time, the CCU can determine the first execution order of the lock command request compared to each first domain control command request based on the priority of the lock command request and the priority of each first domain control command request, and then, when the first execution order is reached, the lock command request is sent to the LCU corresponding to the target door.

[0125] In this way, the CCU in the smart cockpit domain and the LCU in the body domain are used to replace the door control module, the CCU replaces the logic amplifier judgment part of the DCM, and the LCU replaces the function execution part of the DCM, so as to realize the command control and status feedback of the child lock under the new domain control architecture, and play the role of decoupling command control, status feedback and status display. In addition, by obtaining the lock status information indicating the validity of the lock command and the switch status reported by the LCU, the CCU can accurately determine whether the state is caused by a non-electrical fault of the lock according to whether the lock command request indicated by the lock command validity is executed when the switch state does not match the expected state of the lock command request, thereby accurately determining whether the child lock is actually faulty and avoiding the problem of false alarm of the child lock status.

[0126] Take the lock command request issued by the CCU as XXChdLockCmd=Unlock, and the timing after issuing the lock command request for 3 seconds as an example. Within 3 seconds, determine whether the child lock has a fault according to XXChdLockCmdValid and XXChdLockSts and the truth table described in Table 1 below:

[0127]

[0128] (Table 1)

[0129] According to the third row in Table 1, after the unlock lock command request was issued, there was no problem with the child lock, but the child lock did not jump to the expected state and the lock command request had been executed, so it can be determined that there was a mechanical structure coordination failure in the child lock, that is, there was a non-electrical failure. According to the fifth row in Table 1, after the unlock lock command request was issued, there was a problem with the child lock, the child lock did not jump to the expected state and the lock command request had been executed, so it can be determined that there was an electrical circuit failure in the child lock, that is, there was an electrical failure.

[0130] It is understandable that the above Table 1 only shows several situations by way of example, and the specific truth table can be set by the developer based on experience, and the situations it includes will be richer and more comprehensive.

[0131] Optionally, in addition to generating request feedback information and feeding it upward, the CCU can also design a log recording function to record the lock status information uploaded by the LCU. When a child lock is found to have a fault later, the original equipment manufacturer (OEM) can extract the log information from the background, and combine the log information with the truth table to analyze the fault category of the child lock and solve it in a timely manner. For example, based on the lock status information and the truth table, it is determined whether the failure of the child lock is due to a problem with the mechanical structure of the lock, or an electrical circuit fault in the lock circuit, thereby quickly locating the cause of the fault.

[0132] At the same time, the embodiment of the present disclosure also provides a method for determining the child lock state applied to the LCU, such as Figure 2 As shown, it is a flowchart of a method for determining a child lock state applied to an LCU provided in an embodiment of the present disclosure, which may include the following steps:

[0133] S201: receiving a lock command request sent by a central computing processing unit CCU in the smart cockpit domain; the lock command request is used to request control of a child lock on a target door.

[0134] S202: When the execution timing of the driving logic matching the lock command request is reached, the driving logic is executed, and the validity of the lock command is determined according to the execution result of the driving logic.

[0135] Here, the execution result of the driving logic is used to indicate whether the driving logic is fully executed. The execution timing is used to indicate the timing when the lock command request can be executed. The driving logic matching the lock command request can be, for example, a child lock unlocking driving logic, a child lock locking driving logic, etc.

[0136] For example, after receiving the lock command request, the LCU can determine the execution timing of the lock command request according to the vehicle's driving state (such as speed, driving mode, etc.), safe driving rules, etc. When the execution timing is reached, the drive logic matching the lock command request is executed, and the value of the flag "XXChdLockCmdValid" is determined according to the execution result of the drive logic, and the validity of the lock command is determined according to the value.

[0137] S203: Generate lock status information according to the lock command validity and the switch status of the child lock acquired in real time, and send the lock status information to the CCU.

[0138] In specific implementation, the LCU can collect the switch status of the child lock in real time. After determining the validity of the lock command, the switch status of the child lock and the lock command validity collected in real time can be used as lock status information, and the lock status information can be fed back to the CCU.

[0139] In one embodiment, the step of “determining the validity of the lock command according to the execution result of the driving logic” in S202 may also be implemented according to the following steps:

[0140] The validity of the lock command is determined based on the execution results of the drive logic and the execution results of the circuit status diagnosis.

[0141] Here, the execution result of the circuit status diagnosis is used to indicate whether the status diagnosis of the lock circuit of the child lock is completed. If the diagnosis is completed, valid circuit status diagnosis information can be obtained; if the diagnosis is not completed, valid circuit status diagnosis information cannot be obtained.

[0142] In specific implementation, when the drive logic matching the lock command request is executed, a circuit status diagnosis for the child lock can be triggered synchronously. Then, the execution result of the drive logic and the execution result of the circuit status diagnosis can be obtained. When it is determined that the complete drive logic and the complete diagnostic operation have been executed according to the two execution results, the value of "XXChdLockCmdValid" can be set to valid, otherwise the value of "XXChdLockCmdValid" will be set to invalid or unknown.

[0143] It is understandable that, when the LCU does not receive a lock command request, it can also periodically trigger the status diagnosis of the lock circuit of the child lock, so as to obtain effective circuit status diagnosis information for feedback to the CCU.

[0144] Furthermore, the lock status information may also include circuit status diagnosis information and error feedback information. In this case, the above S203 may be implemented according to the following steps:

[0145] The lock status information is generated based on the lock command validity, the circuit status diagnostic information of the child lock collected in real time, the error feedback information and the switch status.

[0146] For example, after determining the validity of the lock command based on the execution results of the drive logic and the execution results of the circuit state diagnosis, the current circuit state diagnosis information, current error feedback information and current switch state of the child lock can be collected. The validity of the lock command, the current circuit state diagnosis information, the current error feedback information and the current switch state are then fed back to the CCU as lock state information.

[0147] It is understandable that, for the LCU, it can not only cache the XXChdLockCmd from the CCU and execute the motor drive logic matching the XXChdLockCmd, but also feed back the collected XXChdLockSts, XXChdLockDiag and XXChdLockErrFb to the CCU in real time.

[0148] Optionally, the LCU may also periodically report the collected lock status information according to a preset period. For example, in the absence of a cache lock command request, the LCU may periodically report lock status information including real-time XXChdLockSts, real-time XXChdLockDiag, and real-time XXChdLockErrFb to the CCU. In the case of a cache lock command request, the LCU may periodically report lock status information including real-time XXChdLockSts, real-time XXChdLockCmdValid, real-time XXChdLockDiag, and real-time XXChdLockErrFb to the CCU.

[0149] In one embodiment, the execution timing of the lock command request may be determined according to the following steps:

[0150] If there is currently a second domain control command request related to the LCU corresponding to the target door, determine the second execution order of the lock command request compared to each second domain control command request; and determine the execution timing of the drive logic according to the second execution order.

[0151] Here, the second domain control command request and the lock command request may be requests synchronously acquired by the LCU corresponding to the target door. The second domain control command request may be, for example, a door control command request for a vehicle occupant to release the electric door when the electric door is closed, or other command requests for a child lock.

[0152] The second execution order is used to indicate the execution order between the lock command request and each second domain control command request.

[0153] In specific implementation, when the LCU caches a lock command request, it can be determined whether there are other second domain control command requests that need to be executed. If not, it can be determined that the second execution order of the lock command request is the first order (i.e., immediate execution). If so, the second execution order of the lock command request compared to each second domain control command request can be determined based on the priority of the lock command request and the priority of each second domain control command request. Then, when the second execution order is reached, the execution timing of the lock command request is determined, and the driving logic matching the lock command request is executed.

[0154] In this way, when there are multiple lock commands (all lock commands cannot be covered by the CCU), the LCU will receive multiple lock commands synchronously. At this time, the priority, timing and interruption logic of the lock command request are all executed by the LCU. For example, if XXChdLockCmd is squeezed out due to priority issues, then the LCU logic judgment is completed and XXChdLockCmdValid = Invalid is output for the CCU to accurately judge the child lock status.

[0155] like Figure 3 As shown, it is a system block diagram of a child lock state determination process provided by an embodiment of the present disclosure, wherein the CCU can obtain the lock command request ChdLockReq through voice or HMI large screen, and process it into the lock command corresponding to the target door and send it to the LCU of the target door. For example, the lock command RLChdLockCmd of the left rear door child lock is sent to the LCU-L corresponding to the left rear door, and the lock command RRChdLockCmd of the right rear door child lock is sent to the LCU-R corresponding to the left rear door. Both LCU-L and LCU-R can feedback the lock state information such as the switch state XXChdLockSts, the lock command validity XXChdLockCmdValid, the circuit state diagnostic information XXChdLockDiag and the error feedback information XXChdLockErrFb to the CCU. Based on the received lock state information, the CCU determines the child lock state ChdLockSts and the child lock error state XXChdLockFltSts and feeds them upward. Furthermore, voice prompts or HMI large-screen displays can be provided based on the information fed back upward.

[0156] In general, the CCU receives the lock command request and processes it into the left / right rear door child lock command, distributes it to LCU-L and LCU-R, and receives the lock status information fed back by LCU-L and LCU-R, and uniformly feeds back the status information for demand call, such as HMI display, voice broadcast, etc.

[0157] In addition, the embodiment of the present disclosure also provides a child lock state determination system, such as Figure 4 FIG. 4 is a schematic diagram of a structure of a child lock state determination system provided by an embodiment of the present disclosure, which includes a central computing processing unit CCU401 in a smart cockpit domain and a domain control unit LCU402 in a vehicle body domain, wherein the LCU402 is deployed at a target door, wherein:

[0158] The CCU 401 is configured to: receive a lock command request and send the lock command request to the LCU 402 corresponding to the target door; the lock command request is used to request control of the child lock on the target door; and receive lock status information reported by the LCU 402 and determine request feedback information corresponding to the lock command request according to the lock status information; the request feedback information is used to indicate whether the child lock has a fault;

[0159] The LCU402 is configured to: receive a lock command request sent by the CCU401; execute the drive logic when the execution timing of the drive logic matching the lock command request is reached, and determine the validity of the lock command according to the execution result of the drive logic, and generate lock status information according to the validity of the lock command and the switch status of the child lock collected in real time, and send the lock status information to the CCU401.

[0160] Regarding the specific execution steps of each part of the above-mentioned child lock status determination system, reference can be made to the above-mentioned embodiments, which will not be repeated here.

[0161] Those skilled in the art will appreciate that, in the above method of specific implementation, the order in which the steps are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of the steps should be determined by their functions and possible internal logic.

[0162] Based on the same technical concept, the embodiment of the present application also provides a computer device. Figure 5 FIG. 1 is a schematic diagram of a computer device provided in an embodiment of the present application, including:

[0163] Processor 501, memory 502 and bus 503. The memory 502 stores machine-readable instructions executable by the processor 501, and the processor 501 is used to execute the machine-readable instructions stored in the memory 502. When the machine-readable instructions are executed by the processor 501, the processor 501 performs the following steps: S101: receiving a lock command request; the lock command request is used to request to control the child lock on the target door; S102: sending the lock command request to the domain control unit LCU corresponding to the target door in the vehicle body domain; S103: receiving lock status information reported by the LCU; the lock status information is used to indicate the switch status of the child lock and the validity of the lock command; and S104: determining, according to the lock status information, whether the lock command request corresponds to the lock state information of the child lock. ; the request feedback information is used to indicate whether the child lock has a fault; or, when the machine-readable instruction is executed by the processor 501, the processor 501 performs the following steps: S201: receiving a lock command request sent by the central computing processing unit CCU in the smart cockpit domain; the lock command request is used to request control of the child lock on the target door; S202: when the execution timing of the drive logic matching the lock command request is reached, the drive logic is executed, and the validity of the lock command is determined according to the execution result of the drive logic; S203: according to the lock command validity and the switch status of the child lock collected in real time, the lock status information is generated and sent to the CCU.

[0164] The above-mentioned memory 502 includes a memory 5021 and an external memory 5022; the memory 5021 here is also called an internal memory, which is used to temporarily store the calculation data in the processor 501, as well as the data exchanged with the external memory 5022 such as a hard disk. The processor 501 exchanges data with the external memory 5022 through the memory 5021. When the computer device is running, the processor 501 communicates with the memory 502 through the bus 503, so that the processor 501 executes the execution instructions mentioned in the above method embodiment.

[0165] The present disclosure also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the child lock state determination method described in the above method embodiment are executed. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0166] The computer program product of the child lock status determination method provided in the embodiment of the present disclosure includes a computer-readable storage medium storing program code, and the instructions included in the program code can be used to execute the steps of the child lock status determination method described in the above method embodiment. For details, please refer to the above method embodiment, which will not be repeated here.

[0167] The computer program product may be implemented in hardware, software or a combination thereof. In one optional embodiment, the computer program product is embodied as a computer storage medium, and in another optional embodiment, the computer program product is embodied as a software product, such as a software development kit (SDK) and the like.

[0168] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the system and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here. In the several embodiments provided in the present disclosure, it should be understood that the disclosed system, device and method can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the device or unit can be electrical, mechanical or other forms.

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

[0170] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0171] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present disclosure, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0172] If the technical solution of this application involves personal information, the product using the technical solution of this application has clearly informed the personal information processing rules and obtained the individual's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using the technical solution of this application has obtained the individual's separate consent before processing the sensitive personal information, and at the same time meets the "explicit consent" requirement. For example, on personal information collection devices such as cameras, clear and prominent signs are set to inform that the personal information collection scope has been entered and personal information will be collected. If the individual voluntarily enters the collection scope, it is deemed that he or she agrees to the collection of his or her personal information; or on the device that processes personal information, the personal information processing rules are notified by obvious signs / information, and the individual's authorization is obtained through pop-up information or by asking the individual to upload his or her personal information; among them, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the type of personal information processed.

[0173] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present disclosure, which are used to illustrate the technical solutions of the present disclosure, rather than to limit them. The protection scope of the present disclosure is not limited thereto. Although the present disclosure is described in detail with reference to the aforementioned embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the aforementioned embodiments within the technical scope disclosed in the present disclosure, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure shall be based on the protection scope of the claims.

Claims

1. A method for determining a child lock state, characterized in that: The central computing processing unit (CCU) used in the smart cockpit domain includes: Receiving a lock command request; the lock command request is used to request control of a child lock on a target vehicle door; Sending the lock command request to a domain control unit LCU corresponding to the target door in the vehicle body domain; Receiving lock status information reported by the LCU; the lock status information is used to indicate the switch status of the child lock and the validity of the lock command; Request feedback information corresponding to the lock command request is determined according to the lock status information; the request feedback information is used to indicate whether the child lock has a fault.

2. The method according to claim 1, characterized in that The lock status information is also used to indicate circuit status diagnosis information and error feedback information of the child lock; The determining, according to the lock state information, request feedback information corresponding to the lock command request includes: When the lock command validity indicates that the circuit status diagnostic information is valid, the request feedback information is determined according to the lock circuit status indicated by the circuit status diagnostic information, whether there is an error in the child lock indicated by the error feedback information, the switch status, and whether the lock command request indicated by the lock command validity is executed.

3. The method according to claim 1, characterized in that Receiving lock status information reported by the LCU, including: Receiving lock status information periodically reported by the LCU; The determining, according to the lock state information, request feedback information corresponding to the lock command request includes: Filtering target lock state information from each piece of the lock state information according to the reporting time of each piece of the lock state information reported periodically and the maximum allowed execution time after the lock command request is issued; Request feedback information corresponding to the lock command request is determined according to the target lock state information.

4. The method according to any one of claims 1 to 3, characterized in that: The step of sending the lock command request to a domain control unit LCU corresponding to the target door in the vehicle body domain includes: determining, based on the most recently received lock status information, whether the child lock on the target door is faulty; If not, the lock command request is sent to the LCU corresponding to the target door in the vehicle body domain.

5. The method according to any one of claims 1 to 3, characterized in that: The determining, according to the lock state information, request feedback information corresponding to the lock command request includes: When it is determined according to the lock status information that the child lock has no fault and the lock command validity indicates that the lock command request has not been executed, return to the step of sending the lock command request to the domain control unit LCU corresponding to the target door in the vehicle body domain until it is determined according to the lock status information that the child lock has a fault or the number of cycles reaches the target number or the lock command request is executed, and the request feedback information is determined.

6. The method according to claim 1, characterized in that The step of sending the lock command request to a domain control unit LCU corresponding to the target door in the vehicle body domain includes: If there is a first domain control command request related to the LCU corresponding to the target door, determining a first execution order of the lock command request compared to each of the first domain control command requests; According to the first execution order, the lock command request is sent to the LCU corresponding to the target door.

7. A method for determining a child lock state, characterized in that: A domain control unit LCU is applied in a vehicle body domain, and the LCU is deployed at a target door. The method includes: Receiving a lock command request sent by a central computing processing unit CCU in the smart cockpit domain; the lock command request is used to request control of a child lock on the target door; When the execution timing of the driving logic matching the lock command request is reached, the driving logic is executed, and the validity of the lock command is determined according to the execution result of the driving logic; Lock status information is generated according to the lock command validity and the switch status of the child lock acquired in real time, and the lock status information is sent to the CCU.

8. The method according to claim 7, characterized in that Determining the validity of the lock command according to the execution result of the driving logic includes: Determining the validity of the lock command according to the execution result of the driving logic and the execution result of the circuit state diagnosis; The generating lock status information according to the lock command validity and the switch status of the child lock acquired in real time includes: The lock status information is generated according to the validity of the lock command, the circuit status diagnosis information of the child lock collected in real time, the error feedback information and the switch status.

9. The method according to claim 7, characterized in that: The execution timing of the driving logic matching the lock command request is determined according to the following steps: If there is currently a second domain control command request related to the LCU corresponding to the target door, determining a second execution order of the lock command request compared to each of the second domain control command requests; According to the second execution order, the execution timing of the driving logic is determined.

10. A child lock status determination system, characterized in that: It includes a central computing processing unit CCU in the smart cockpit domain and a domain control unit LCU in the body domain, wherein the LCU is deployed at the target door: The CCU is configured to: receive a lock command request and send the lock command request to the LCU corresponding to the target door; the lock command request is used to request control of the child lock on the target door; and receive lock status information reported by the LCU and determine request feedback information corresponding to the lock command request according to the lock status information; the request feedback information is used to indicate whether the child lock has a fault; The LCU is configured to: receive a lock command request sent by the CCU; execute the drive logic when the execution timing of the drive logic matching the lock command request is reached, and determine the validity of the lock command according to the execution result of the drive logic, and generate lock status information according to the validity of the lock command and the switch status of the child lock collected in real time, and send the lock status information to the CCU.

11. A computer device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is used to execute the machine-readable instructions stored in the memory. When the machine-readable instructions are executed by the processor, the processor executes the steps of the child lock status determination method as described in any one of claims 1 to 9.

12. A computer program product, characterized in that When the computer program product is executed by a computer device, the steps of the method for determining the state of a child lock according to any one of claims 1 to 9 are executed.

Images