Device control method, electronic device, vehicle, and storage medium

Abstract

The embodiment of the application provides a device control method, an electronic device, a vehicle and a storage medium, which can receive a user command for controlling a target device; based on the user command, a first drive control command corresponding to the target device and a load expected state of the target device are determined; the load of the target device is controlled based on the first drive control command, and first control feedback information is obtained, the first control feedback information comprising a first drive feedback state and a first load actual state of the target device; if at least one of a first matching result and a second matching result is met, a second drive control command is generated to control the load of the target device through the second drive control command, the first matching result being that the first drive control command does not match the first drive feedback state, and the second matching result being that the load expected state does not match the first load actual state, so that the accuracy of device control can be improved.

Description

Technical Field

[0001] This application relates to the field of computer equipment technology, and more particularly to a device control method, electronic equipment, vehicle, and storage medium. Background Technology

[0002] In related technologies, driver chips can control devices through driver commands, thereby controlling the devices to achieve desired results. For example, controlling an air conditioner to turn on or off.

[0003] However, the inventors discovered through long-term research that the control of the equipment in the related technologies is inaccurate. Summary of the Invention

[0004] This application provides a device control method, electronic device, vehicle, and storage medium, which aims to reduce the technical problem of inaccurate device control and improve the accuracy of device control.

[0005] In a first aspect, embodiments of this application propose a device control method, comprising: receiving a user command for controlling a target device; determining, based on the user command, a first drive control command corresponding to the target device and a desired load state of the target device, wherein the first drive control command represents a desired control intention for the load of the target device, and the desired load state of the target device represents a desired control result for controlling the load of the target device according to the first drive control command; controlling the load of the target device based on the first drive control command and obtaining first control feedback information, wherein the first control feedback information includes a first drive feedback state and a first actual load state of the target device, wherein the first drive feedback state represents an actual control intention for controlling the load of the target device through the first drive control command, and the first actual load state of the target device represents an actual control result for controlling the load of the target device through the first drive control command; and generating a second drive control command if at least one of a first matching result and a second matching result is satisfied, wherein the first matching result is that the first drive control command and the first drive feedback state do not match, and the second matching result is that the desired load state and the first actual load state do not match.

[0006] In this embodiment, a user command for controlling a target device can be received; based on the user command, a first drive control command corresponding to the target device and a desired load state of the target device are determined. The first drive control command represents the desired control intention for the load of the target device, and the desired load state of the target device represents the desired control result of controlling the load of the target device according to the first drive control command; the load of the target device is controlled based on the first drive control command, and first control feedback information is obtained. The first control feedback information includes a first drive feedback state and a first actual load state of the target device. The first drive feedback state represents the actual control intention for controlling the load of the target device through the first drive control command, and the first actual load state of the target device represents the actual control result of controlling the load of the target device through the first drive control command; if the first matching result and the second matching result are satisfied... If at least one of the following results is obtained, a second drive control command is generated to control the load of the target device. The first matching result is that the first drive control command does not match the first drive feedback state, and the second matching result is that the expected load state does not match the actual first load state. In this way, the first drive control command and the first load state can be matched, specifically the first drive control command matches the first drive feedback state, and the actual first load state matches the expected load state. This allows for the generation of a new second drive control command when the first drive control command does not match the first drive feedback state and / or the actual first load state does not match the expected load state. In other words, it can generate a new second drive control command when there are problems such as call failure, ineffective call, or execution not matching expectations in the underlying driver. This can help improve the accuracy of device control.

[0007] In one possible implementation, the controller has a built-in driver chip, which includes a driver layer, and acquires first control feedback information, including: when the driver chip is in the target operating phase, periodically acquiring the first control feedback information through the driver layer.

[0008] In this embodiment, when the driver chip is in the target running stage, the first control feedback information is periodically obtained through the driver layer. This allows the driver layer to periodically obtain the first control feedback information during a specific running period, thereby reducing the invalid acquisition of control feedback information and improving the resource utilization of the driver layer.

[0009] In one possible implementation, the load is a load with a first-frame requirement, and the wake-up process of the driver chip, from early to late, includes: network wake-up, driver layer preparation, and full working state, with sampling starting after driver layer preparation is completed. The target running phase includes the running phase between driver layer preparation and network sleep. Alternatively, the load is a load without a first-frame requirement, or the load is a load with a first-frame requirement, but the wake-up process of the driver chip, from early to late, includes: driver layer preparation, full working state, and network wake-up, with sampling starting after full working state, and the target running phase includes the running phase between full working state and network sleep. Here, having a first-frame requirement means that activation is required through first-frame interaction.

[0010] In this embodiment, different target operation stages can be set according to whether the load has a first frame requirement and the working order between Wake-up and full working state. This can improve the effectiveness of obtaining control feedback information in the target operation stage and help reduce resource waste.

[0011] In one possible implementation, the first control feedback information is periodically obtained through the driver layer, including: periodically obtaining the first drive feedback state through the driver layer according to a first preset period; and periodically obtaining the first actual load state through the driver layer according to a second preset period, wherein the first preset period is less than the second preset period.

[0012] In this embodiment, the first drive feedback state is periodically acquired by the drive layer according to a first preset period; the first load actual state is periodically acquired by the drive layer according to a second preset period. The first preset period is shorter than the second preset period, which makes the period of the original signal read by the drive layer shorter, which is conducive to timely updating of the control of the device. The period of acquiring the first load actual state is longer, which can reduce the occurrence of overload.

[0013] In one possible implementation, after controlling the load of the target device via the second drive control command, the method further includes: acquiring second control feedback information, which includes a second drive feedback state and a second load actual state of the target device. The second drive feedback state indicates the actual control intention to control the load of the target device via the second drive control command, and the second load actual state of the target device indicates the actual control result of controlling the load of the target device via the second drive control command; determining the target fault level based on the second control feedback information; and executing the fault action corresponding to the target fault level.

[0014] In this embodiment, by acquiring second control feedback information, which includes a second drive feedback state and a second actual load state of the target device, the second drive feedback state represents the actual control intention to control the load of the target device through the second drive control command, and the second actual load state of the target device represents the actual control result of controlling the load of the target device through the second drive control command; the target fault level is determined based on the second control feedback information; and the fault action corresponding to the target fault level is executed. This allows for the execution of the fault action corresponding to the target fault level after determining the target fault level, which is beneficial to improving the intelligence level when the device control fails.

[0015] In one possible implementation, determining the target fault level based on the second control feedback information includes: if the second drive control command matches the second drive feedback state and the actual state of the second load matches the expected state of the load, then the target fault level is determined to be a first fault level; if the actual state of the second load does not match the expected state of the load but the control range corresponding to the actual state of the second load matches the expected state of the load, then the target fault level is determined to be a second fault level; if the actual state of the second load does not match the expected state of the load and the control range corresponding to the actual state of the second load does not match the expected state of the load, then the target fault level is determined to be a third fault level; wherein the first fault level is lower than the second fault level, the second fault level is lower than the third fault level, and the fault action corresponding to the first fault level, the fault action corresponding to the second fault level, and the fault action corresponding to the third fault level are all different.

[0016] In this embodiment, if the second drive control command matches the second drive feedback state and the actual state of the second load matches the expected state of the load, then the target fault level is determined as the first fault level; if the actual state of the second load does not match the expected state of the load but the control range corresponding to the actual state of the second load matches the expected state of the load, then the target fault level is determined as the second fault level; if the actual state of the second load does not match the expected state of the load and the control range corresponding to the actual state of the second load does not match the expected state of the load, then the target fault level is determined as the third fault level. The first fault level is lower than the second fault level, and the second fault level is lower than the third fault level. The fault actions corresponding to the first fault level, the second fault level, and the third fault level are all different. Multiple fault levels can be determined based on the second control feedback information, thus improving the precision of fault level determination.

[0017] In one possible implementation, the fault action corresponding to the target fault level is executed, including: if the target fault level is the first fault level, then record the fault; if the target fault level is the second fault level, then record the fault and degrade the output capability of the target device's load; if the target fault level is the third fault level, then record the fault and disable the output capability of the target device's load.

[0018] In this embodiment, if the target fault level is the first fault level, the fault is recorded; if the target fault level is the second fault level, the fault is recorded and the output capability of the target device's load is downgraded; if the target fault level is the third fault level, the fault is recorded and the output capability of the target device's load is disabled. In this way, different fault actions can be set according to different fault levels, and the higher the fault level, the more in-depth the corresponding fault action, which is beneficial to improving the safety of device control.

[0019] Secondly, embodiments of this application propose a device control apparatus, comprising: a receiving module for receiving a user command for controlling a target device; a device control module for determining, based on the user command, a first drive control command corresponding to the target device and a desired load state of the target device, wherein the first drive control command represents a desired control intention for the load of the target device, and the desired load state of the target device represents a desired control result for controlling the load of the target device according to the first drive control command; controlling the load of the target device based on the first drive control command and obtaining first control feedback information, wherein the first control feedback information includes a first drive feedback state and a first actual load state of the target device, wherein the first drive feedback state represents an actual control intention for controlling the load of the target device through the first drive control command, and the first actual load state of the target device represents an actual control result for controlling the load of the target device through the first drive control command; and generating a second drive control command if at least one of a first matching result and a second matching result is satisfied, thereby controlling the load of the target device through the second drive control command, wherein the first matching result is that the first drive control command and the first drive feedback state do not match, and the second matching result is that the desired load state and the first actual load state do not match.

[0020] Thirdly, embodiments of this application propose an electronic device, including a processor and a memory, wherein: the memory is used to store computer programs; and the processor is used to execute the programs stored in the memory to implement the method of the first aspect.

[0021] Fourthly, embodiments of this application propose an in-vehicle system, including a target device and a controller, the controller being used to implement the method of the first aspect.

[0022] Fifthly, embodiments of this application propose a vehicle that includes electronic equipment of the third aspect or an in-vehicle system of the fourth aspect.

[0023] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of the first aspect. Attached Figure Description

[0024] Figure 1 This is a schematic flowchart illustrating a device control method according to an embodiment of this application.

[0025] Figure 2 This is a schematic diagram illustrating the changes in the operating state of an MCU according to an embodiment of this application.

[0026] Figure 3 This is a schematic diagram illustrating the change of the operating state of an MCU according to another embodiment of this application.

[0027] Figure 4 This is a schematic flowchart illustrating a device control method according to another embodiment of this application.

[0028] Figure 5 This is a structural block diagram of a device control apparatus according to an embodiment of this application.

[0029] Figure 6 This is a structural diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0030] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0031] Terminology Explanation: Low-level drive control commands (also simply drive control commands): Low-level drivers refer to the underlying software that directly controls the drive pins through the drive chip on the controller. Low-level drive control commands are commands given by the application software to the low-level driver and represent the pure software state calculated by the air conditioning application. In this embodiment, drive control commands can be used to express the desired control intent regarding the load of the device. For example, a low-level drive control command could control the air conditioner motor to rotate forward or backward.

[0032] Low-level driver feedback state (also simply referred to as driver feedback state): This is the current state of the driver obtained by the application through the low-level driver interface. It is a purely software state fed back to the air conditioning application by the low-level driver. In this embodiment, the low-level driver feedback state can be used to represent the actual control intention for the device's load. For example, the low-level driver feedback state could be used to control the air conditioner's motor to rotate forward or backward.

[0033] Expected Load State: The expected operating state of the load calculated by the air conditioning application based on received user commands. It is the expected physical state calculated by the air conditioning application. In this embodiment, the expected load state represents the actual control result of controlling the load on the device. For example, the expected load state could be that the motor is moving and the feedback voltage is approaching 0%.

[0034] Actual load state: The current state of the air conditioning load, collected by the application through sensors or based on the load's feedback pin, can be considered the actual physical state of the load. In this embodiment, the actual load state is used to represent the actual control result of controlling the load of the device. For example, the actual load state may be that the motor is moving and the feedback voltage is approaching 0%, or the actual load state may be that the motor is not moving.

[0035] Pulse Width Modulation (PWM): A digital control technology that adjusts the duty cycle of a pulse signal (the proportion of the high-level duration to the entire cycle) to control analog quantities such as voltage, current, and power. It has certain applications in scenarios such as vehicle motors, air conditioning dampers, and dimming.

[0036] In related technologies, driver chips can control devices through driver commands, thereby controlling the devices to achieve desired results. For example, controlling an air conditioner to turn on or off.

[0037] However, through long-term research, the inventors discovered that current vehicle air conditioning application software for Zone Control Units (ZCUs) is primarily designed based on the characteristics of the air conditioning actuators. It presupposes that the underlying driver software is stable and reliable during operation, but in reality, the underlying driver may experience problems such as call failures, ineffective calls, and execution discrepancies with expectations. This leads to inaccurate control of the equipment in related technologies.

[0038] In view of this, embodiments of this application propose a device control method, an electronic device, a vehicle, and a storage medium, which can receive user commands for controlling a target device; based on the user commands, determine a first drive control command corresponding to the target device and a desired load state of the target device, wherein the first drive control command represents the desired control intention for the load of the target device, and the desired load state of the target device represents the desired control result of controlling the load of the target device according to the first drive control command; control the load of the target device based on the first drive control command, and obtain first control feedback information, wherein the first control feedback information includes a first drive feedback state and a first actual load state of the target device, wherein the first drive feedback state represents the actual control intention for controlling the load of the target device through the first drive control command, and the first actual load state of the target device represents the actual control result of controlling the load of the target device through the first drive control command; if If at least one of the first matching result and the second matching result is satisfied, a second drive control command is generated to control the load of the target device. The first matching result is that the first drive control command does not match the first drive feedback state, and the second matching result is that the expected load state does not match the actual first load state. In this way, the first drive control command and the first load state can be matched, specifically the first drive control command matches the first drive feedback state, and the actual first load state matches the expected load state. This allows for the generation of a new second drive control command when the first drive control command does not match the first drive feedback state and / or the actual first load state does not match the expected load state. In other words, it can generate a new second drive control command when there are problems such as call failure, ineffective call, or execution not matching expectations in the underlying driver, which helps to improve the accuracy of device control.

[0039] Please see Figure 1 , Figure 1 This is a schematic flowchart illustrating a device control method according to an embodiment of this application. Figure 1 The method shown can be executed by a controller, for example, by a ZCU.

[0040] like Figure 1 The methods shown may include: S110, Receive user commands for controlling the target device.

[0041] The user command can be a command from the user, representing the user's intent. Optionally, the user command can be sent by the user via voice or by pressing a button on an external device; there is no limitation on this. For example, the target device could be a car air conditioner, and the user command could be, for example, a "turn off the air conditioner" command.

[0042] S120. Based on the user command, determine the first drive control command corresponding to the target device and the expected load state of the target device. The first drive control command is used to express the expected control intention of the load of the target device, and the expected load state of the target device is used to express the expected control result of controlling the load of the target device according to the first drive control command.

[0043] In this embodiment, the first drive control command can control the load of the target device. For example, when the target device is a vehicle air conditioner, the load of the air conditioner can be, for example, a motor, which can control the start or stop of the air conditioner. For instance, when the motor moves forward, the air conditioner starts; when the motor rotates backward, the air conditioner stops.

[0044] In this embodiment, the first drive control command and the desired load state correspond to the user command. For example, the user command could be, for instance, a "turn off the air conditioner" command, then the first drive control command could be, for instance, controlling the motor to rotate backward (i.e., the desired control intention), and the desired load state could be, for instance, the motor being in motion and the feedback voltage approaching 0%.

[0045] In this embodiment, different drive types can correspond to different loads. For example, the relationship between drive type and corresponding actual load is shown in Table 1: Table 1 S130. Control the load of the target device based on the first drive control command and obtain the first control feedback information. The first control feedback information includes the first drive feedback state and the first load actual state of the target device. The first drive feedback state is used to indicate the actual control intention of controlling the load of the target device through the first drive control command, and the first load actual state of the target device is used to indicate the actual control result of controlling the load of the target device through the first drive control command.

[0046] In this embodiment, since the actual underlying driver may have problems such as call failure, ineffective call, or execution not matching expectations, it is necessary to obtain the first control feedback information to determine whether the underlying driver has problems such as call failure, ineffective call, or execution not matching expectations, so that timely remediation can be carried out when the above problems exist.

[0047] In this embodiment, the first drive feedback state can verify the first drive control command. For example, the first drive feedback state may be that the motor is not rotating, or the motor is rotating backward, or the motor is rotating forward, etc., which are related to the actual situation and are not limited here.

[0048] In this embodiment, the first actual load state can verify the expected load state. For example, the first actual load state may be that the motor is moving and the feedback voltage is approaching 0%, or the motor is not moving, or the motor is moving and the feedback voltage is approaching 100%, etc., which are related to the actual situation and are not limited here.

[0049] S140. If at least one of the first matching result and the second matching result is satisfied, a second drive control command is generated to control the load of the target device through the second drive control command. The first matching result is that the first drive control command does not match the first drive feedback state, and the second matching result is that the expected load state does not match the actual first load state.

[0050] In this embodiment, the mismatch between the first drive control command and the first drive feedback state can be due to a discrepancy between the expected control intention and the actual control intention. For example, this discrepancy could occur when the expected control intention indicates that the motor should rotate backward, while the actual control intention indicates that the motor should rotate forward or not rotate at all.

[0051] In this embodiment, the mismatch between the expected load state and the actual first load state can be due to inconsistencies between the expected control result and the actual control result. For example, such inconsistencies could be that the expected control result is that the motor is moving and the feedback voltage is approaching 0%, while the actual control result is that the motor is not moving, or that the motor is moving and the feedback voltage is approaching 100%, etc.

[0052] In this embodiment, a user command for controlling a target device can be received; based on the user command, a first drive control command corresponding to the target device and a desired load state of the target device are determined. The first drive control command represents the desired control intention for the load of the target device, and the desired load state of the target device represents the desired control result of controlling the load of the target device according to the first drive control command; the load of the target device is controlled based on the first drive control command, and first control feedback information is obtained. The first control feedback information includes a first drive feedback state and a first actual load state of the target device. The first drive feedback state represents the actual control intention for controlling the load of the target device through the first drive control command, and the first actual load state of the target device represents the actual control result of controlling the load of the target device through the first drive control command; if the first matching result and the second matching result are satisfied... If at least one of the following results is obtained, a second drive control command is generated to control the load of the target device. The first matching result is that the first drive control command does not match the first drive feedback state, and the second matching result is that the expected load state does not match the actual first load state. In this way, the first drive control command and the first load state can be matched, specifically the first drive control command matches the first drive feedback state, and the actual first load state matches the expected load state. This allows for the generation of a new second drive control command when the first drive control command does not match the first drive feedback state and / or the actual first load state does not match the expected load state. In other words, it can generate a new second drive control command when there are problems such as call failure, ineffective call, or execution not matching expectations in the underlying driver. This can help improve the accuracy of device control.

[0053] In one possible implementation, the controller has a built-in driver chip, which includes a driver layer and acquires first control feedback information, including: When the driver chip is in the target operation phase, it periodically obtains the first control feedback information through the driver layer.

[0054] The target operating phase can be a partial operating phase within the complete operating phase of the driver chip. In this embodiment, the target operating phase can be understood as the acquisition time of control feedback information. The driver layer in this embodiment can be connected to an acquisition device. After the acquisition device obtains the first control feedback information, it sends it to the driver layer, allowing the driver chip to acquire the first control feedback information through the driver layer.

[0055] It should be noted that the acquisition device may actively feed back the first control feedback information to the driver layer, or the acquisition device may feed back the first control feedback information at the request of the driver layer; there is no limitation on this.

[0056] In this embodiment, when the driver chip is in the target running stage, the first control feedback information is periodically obtained through the driver layer. This allows the driver layer to periodically obtain the first control feedback information during a specific running period, thereby reducing the invalid acquisition of control feedback information and improving the resource utilization of the driver layer.

[0057] In another possible implementation, the first control feedback information can be periodically obtained through the driver layer at any stage of the complete operation of the driver chip. This can improve the timeliness of obtaining the first control feedback information, which is conducive to timely control and adjustment of the device, and thus improves the accuracy of device control.

[0058] Optionally, in this embodiment, the driver chip further includes an application layer, which includes an application (APP). In this case, the application can receive user commands for controlling the target device. Then, the application instructs the driver layer to determine the first drive control command corresponding to the target device and the expected load state of the target device based on the user command. Then, the driver layer controls the load of the target device based on the first drive control command and obtains first control feedback information, which includes a first drive feedback state and a first actual load state of the target device. If at least one of the first matching result and the second matching result is satisfied, the application instructs the driver layer to generate a second drive control command to control the load of the target device. The first matching result is that the first drive control command does not match the first drive feedback state, and the second matching result is that the expected load state does not match the first actual load state.

[0059] The target operation phase is described below. In one possible implementation, the load is a load with first-frame requirements, and the wake-up process of the driver chip, from early to late, includes: network wake-up, driver layer preparation, and full working state. Sampling begins after driver layer preparation is completed. The target operation phase includes the operation phase between driver layer preparation and network sleep.

[0060] The requirement of a first frame indicates that activation requires interaction with the first frame. For loads with this requirement, after power-on, wake-up, or network recovery, the load must receive the first configuration frame / control frame / handshake frame within a specified timeframe. If the first frame is not received on time, the load will enter a default protection state, go into sleep mode, report an error, or experience power-on malfunctions, and will be unable to enter a normal controllable state. In other words, the load cannot rely on the hardware default state; it must be activated by the driver chip (MCU) actively sending an initialization first frame. First frame interaction is a prerequisite for the load to enter a controllable state. The timing of the first frame is strict; it must be completed after network wake-up and before entering FullWork mode. The first frame relies on the underlying driver for early initialization and cannot be delayed and sent at the application layer.

[0061] In this scenario, the MCU's operating states include MCU Sleep, APPStart, Drive Ready, FullWork, Network Wake, Network Sleep, and App Stop. The changes in each operating state can be described as follows: Figure 2 As shown. Figure 2 This is a schematic diagram illustrating the changes in the operating state of an MCU according to an embodiment of this application.

[0062] like Figure 2 As shown, the MCU's operating states can be in the following order: MCU Sleep, APP Start, Network Wake, Drive Ready, MCU FullWork, Network Sleep, App Stop, and MCU Sleep.

[0063] like Figure 2 As shown, the application's runtime is the time between APP Start and App Stop, and the MCU's wake-up time is the time between MCU Sleep. Therefore, the target runtime phase can be the phase between Drive Ready and Network Sleep.

[0064] Specifically, before Drive Ready, feedback data is unreliable because the underlying driver has not yet been initialized: the sensor ADC, driver chip, and bus peripherals are all in an unconfigured state. Therefore, the collected AD values, current, voltage, and switch states are invalid, random, and uncalibrated data. Only after Drive Ready is complete, with all underlying hardware, drivers, and calibrations ready, is the collected feedback real, valid, and reliable. After Network Sleep, the feedback link is cut off because upon entering the Network Sleep phase: the bus controller begins to shut down, the network link enters a sleep process, and the driver chip and sensors also enter low-power / power-down preparation with the system. Collecting feedback at this time is meaningless and may even result in false fault reports. Furthermore, since peripherals are in sleep mode and their outputs are no longer updated or remain fixed, continued collection is pointless and may even lead to false fault reports.

[0065] For the reasons mentioned above, the target operating phase in this embodiment can be the phase between Drive Ready and Network Sleep, which can ensure the effectiveness of the collection of control feedback information.

[0066] In another possible implementation, the load is a load without a first frame requirement, or the load has a first frame requirement but the wake-up process of the driver chip in the order from early to late includes: driver layer preparation, full working state and network wake-up, and sampling begins after full working state. The target running phase includes the running phase between full working state and network sleep.

[0067] In this situation, the changes in each working state can be described as follows: Figure 3 As shown. Figure 3 This is a schematic diagram illustrating the change of the operating state of an MCU according to another embodiment of this application.

[0068] like Figure 3 As shown, the MCU's operating states can be in the following order: MCU Sleep, APP Start, Drive Ready, MCU FullWork, Network Wake, Network Sleep, App Stop, and MCU Sleep.

[0069] like Figure 3 As shown, the application's runtime is the time between APP Start and App Stop, and the MCU's wake-up time is the time between MCU Sleep. Therefore, the target runtime phase can be the phase between MCU FullWork and Network Sleep.

[0070] In this embodiment, "Drive Ready" only indicates that the underlying driver initialization is complete and the hardware peripherals can work; however, at this time, the system clock and power domain may not have completed their final configuration; the network protocol stack and application layer scheduling are not yet fully ready; and loads requiring the first frame may not have completed the first frame handshake, resulting in an unstable state. The feedback data collected at this time may contain transient interference, unfiltered glitches, and fluctuating bus messages that have not yet entered a stable cycle. Furthermore, the load has just been awakened and has not yet entered a stable operating condition, so the feedback has no business reference value.

[0071] MCU FullWork means that the underlying drivers, network protocol stack, system scheduling, and security mechanisms are all ready and running stably; all loads requiring the first frame have completed handshakes and entered a normal and controllable state; the bus communication cycle is stable, and application layer task scheduling is normal. The feedback data collected at this time is stable, reliable, and free from transient interference.

[0072] For the reasons mentioned above, the target operating phase in this embodiment can be the phase between MCU FullWork and Network Sleep.

[0073] In general, if Wake-on-Network occurs before FullWork, it is necessary to read the driver's initialization state. Data acquisition begins as soon as the driver completes initialization. Figure 2 As shown. For workloads with first-frame requirements, it's necessary to determine whether the network wake-up occurs before or after FullWork. If the network wake-up occurs after FullWork, sampling should begin after FullWork; if the network wake-up occurs before FullWork, sampling should begin at Drive Ready.

[0074] In this embodiment, different target operation stages can be set according to whether the load has a first frame requirement and the working order between Wake-up and full working state. This can improve the effectiveness of obtaining control feedback information in the target operation stage and help reduce resource waste.

[0075] In one possible implementation, the first control feedback information is acquired periodically by the driver layer, including: The first drive feedback state is periodically obtained by the drive layer according to a first preset period; the first load actual state is periodically obtained by the drive layer according to a second preset period, wherein the first preset period is shorter than the second preset period.

[0076] In this embodiment, the first driver feedback state can be a raw signal directly read from the hardware by the driver layer, such as register state, ADC sample value, or interrupt flag. The first actual load state, on the other hand, can be the final state required by the application layer after processing, such as the load state after filtering, debouncing, and fault diagnosis.

[0077] In this embodiment, the first drive feedback state is periodically acquired by the drive layer according to a first preset period; the first load actual state is periodically acquired by the drive layer according to a second preset period. The first preset period is shorter than the second preset period, which makes the period of the original signal read by the drive layer shorter, which is conducive to timely updating of the control of the device. The period of acquiring the first load actual state is longer, which can reduce the occurrence of overload.

[0078] In another possible implementation, the period for obtaining the first drive feedback state may be the same as the period for obtaining the first load actual state, or the period for obtaining the first drive feedback state may be greater than the period for obtaining the first load actual state; no restrictions are imposed here.

[0079] In one possible implementation, after controlling the load of the target device via a second drive control command, the method further includes: Acquire second control feedback information, which includes a second drive feedback state and a second load actual state of the target device. The second drive feedback state is used to indicate the actual control intention to control the load of the target device through the second drive control command, and the second load actual state of the target device is used to indicate the actual control result of controlling the load of the target device through the second drive control command. Determine the target fault level based on the second control feedback information. Execute the fault action corresponding to the target fault level.

[0080] The description of the second drive feedback state can be found in the description of the first drive feedback state, and the description of the second load actual state can be found in the description of the first load actual state. They will not be repeated here.

[0081] In this embodiment, the result of the second drive control command controlling the device can be determined through the second control feedback information, thereby determining the target fault level.

[0082] In this embodiment, by acquiring second control feedback information, which includes a second drive feedback state and a second actual load state of the target device, the second drive feedback state represents the actual control intention to control the load of the target device through the second drive control command, and the second actual load state of the target device represents the actual control result of controlling the load of the target device through the second drive control command; the target fault level is determined based on the second control feedback information; and the fault action corresponding to the target fault level is executed. This allows for the execution of the fault action corresponding to the target fault level after determining the target fault level, which is beneficial to improving the intelligence level when the device control fails.

[0083] The following explains how to determine the target fault level.

[0084] In one possible implementation, the target fault level is determined based on the second control feedback information, including: If the second drive control command matches the second drive feedback state and the actual state of the second load matches the expected state of the load, then the target fault level is determined to be the first fault level. If the actual state of the second load does not match the expected state of the load, but the control range corresponding to the actual state of the second load matches the expected state of the load, then the target fault level is determined to be the second fault level. If the actual state of the second load does not match the expected state of the load and the control range corresponding to the actual state of the second load does not match the expected state of the load, then the target fault level is determined to be the third fault level. The first fault level is lower than the second fault level, and the second fault level is lower than the third fault level. The fault actions corresponding to the first fault level, the second fault level, and the third fault level are all different.

[0085] In this embodiment, matching the second drive control command with the second drive feedback state can mean that the desired control intention expressed by the second drive control command matches the actual control intention expressed by the second drive feedback state. Figure 1 Matching the actual load state with the desired load state means that the actual control result represented by the actual load state is consistent with the desired control result represented by the desired load state. For example, if the desired control intention is to control the motor to rotate backward, the actual control intention is also to control the motor to rotate backward. Another example is that the desired control result is that the motor is moving and the feedback voltage is approaching 0%, while the actual control result is that the motor is moving and the feedback voltage is approaching 0%.

[0086] In this embodiment, taking a control range of 10% as an example, the control range corresponding to the actual state of the second load and the expected state of the load are matched. For example, it can be that the motor is moving and the feedback voltage is approaching 0%, while the actual control result is that the motor is moving and the feedback voltage is approaching 10%.

[0087] In this embodiment, if the control range corresponding to the actual state of the second load does not match the expected state of the load, for example, the motor may be moving and the feedback voltage may be approaching 0%, while the actual control result may be that the motor is moving and the feedback voltage may be approaching 20%.

[0088] In this embodiment, if the second drive control command matches the second drive feedback state and the actual state of the second load matches the expected state of the load, then the target fault level is determined as the first fault level; if the actual state of the second load does not match the expected state of the load but the control range corresponding to the actual state of the second load matches the expected state of the load, then the target fault level is determined as the second fault level; if the actual state of the second load does not match the expected state of the load and the control range corresponding to the actual state of the second load does not match the expected state of the load, then the target fault level is determined as the third fault level. The first fault level is lower than the second fault level, and the second fault level is lower than the third fault level. The fault actions corresponding to the first fault level, the second fault level, and the third fault level are all different. Multiple fault levels can be determined based on the second control feedback information, thus improving the precision of fault level determination.

[0089] It should be noted that this embodiment is not limited to setting three fault levels; more fault levels can be set, and no limitation is made here.

[0090] The fault actions for different fault levels are explained below.

[0091] In one possible implementation, the fault action corresponding to the target fault level is executed, including: If the target fault level is the first fault level, the fault is recorded; if the target fault level is the second fault level, the fault is recorded and the output capacity of the target device's load is downgraded; if the target fault level is the third fault level, the fault is recorded and the output capacity of the target device's load is disabled.

[0092] In this embodiment, the output capability of the target device's load is downgraded, which may involve limiting the load's maximum output power, highest gear, or other capabilities.

[0093] Please refer to Table 2, which is an example of a fault and its corresponding fault action according to an embodiment of this application.

[0094] Table 2 Minor (i.e., first level of fault) Command confirmation failed, but retrying the periodic monitoring reset control command was successful. The following are possible causes of issues: Low-level driver call failure, low-level driver call not taking effect, recoverable transient overtemperature or overcurrent in the driver chip, event-driven write errors in other software modules, asynchronous operation problems or logic errors in the air conditioning application. Record faults Medium (i.e., second level of failure) After the periodic monitoring was reset, the actual load status was inconsistent with the expected status, but it was still within the controllable range. The waveform distortion of the sensor's offset drive chip feedback offset drive output, the controller system, or the load voltage being unstable or the load specifications not matching the design are all issues. The fault is logged, and the application performs degradation processing on the load output. Critical (i.e., third-level fault) Command confirmation failed and retry was unrecoverable. After periodic monitoring was reset, the actual load status was inconsistent with the expected status and was within an uncontrollable range. Unresponsiveness can be caused by driver chip failure, underlying driver software errors, mismatch between underlying driver logic and application, low or high controller system voltage, low or high load voltage, or periodic write errors in other modules. Record the fault and turn off the output. In this embodiment, if the target fault level is the first fault level, the fault is recorded; if the target fault level is the second fault level, the fault is recorded and the output capability of the target device's load is downgraded; if the target fault level is the third fault level, the fault is recorded and the output capability of the target device's load is disabled. In this way, different fault actions can be set according to different fault levels, and the higher the fault level, the more in-depth the corresponding fault action, which is beneficial to improving the safety of device control.

[0095] For ease of understanding, the following embodiments are described in conjunction with the embodiments described above.

[0096] Please see Figure 4 , Figure 4 This is a schematic flowchart illustrating a device control method according to another embodiment of this application. Figure 4 The process shown may include: S401, Begin.

[0097] S402. Does the data acquisition window meet the requirements?

[0098] Specifically, if the driver chip is in the target operating phase, the acquisition window is considered to be met; otherwise, the acquisition window is considered not to be met.

[0099] S403, feedback sampling and filtering.

[0100] In this embodiment, control feedback information can be collected. Taking an air conditioning application as an example, the air conditioning application needs to periodically read and collect the underlying driver feedback status. The underlying driver feedback status includes the current, voltage, and switching status collected by the driver chip (that is, the driver feedback status). The actual load status is mainly the AD value or PWM duty cycle collected by the sensor or feedback PIN.

[0101] During the ZCU's MCU sleep / wake-up and network sleep / wake-up processes, there may be situations where the underlying software has not yet been initialized. In such cases, reading the data will result in invalid feedback values, leading to subsequent driver and judgment errors. Therefore, a sampling window period needs to be set. First, the MCU's operating status and the controller's network status need to be read. Sleep indicates the MCU is completely asleep and the ZCU is not working; FullWork indicates the MCU and controller have completed the initialization process and are working normally. For network status, air conditioning applications only focus on network sleep and wake-up. Different ZCUs may wake up before or after the MCU enters FullWork. The underlying driver must be initialized before the MCU enters FullWork.

[0102] Therefore, for air conditioning loads that do not require sending a first frame signal (the first frame message sent by the ZCU, which needs to send the actual value of the signal), feedback sampling only needs to begin after the MCU reaches FullWork. It can be assumed that the underlying driver of the load has already been initialized and will not sample invalid values. For loads that require a first frame, it is necessary to determine whether the network wake-up occurs before or after FullWork. If it occurs after FullWork, sampling should also begin after FullWork, such as... Figure 3 As shown. If Wake-on-Network occurs before FullWork, it is necessary to read the driver's initialization status. Data acquisition begins as soon as the driver completes initialization, such as... Figure 2 As shown.

[0103] During ZCU hibernation, since the air conditioner does not require local driving, the air conditioner application can stop data collection and driving when the network goes into hibernation.

[0104] The collected feedback also needs to be filtered. For air conditioning applications, the current and voltage of the driver chip, and the AD values ​​of the sensor are numerical values ​​(e.g., 0 to 100 or 0 to 0x8000). This type of feedback undergoes four rounds of mean filtering. For air conditioning applications, the on / off status and fault status of the driver chip are Boolean values ​​(0 or 1) or simple enumeration values ​​(usually a maximum of 5 states, 0 to 5). This type of feedback undergoes ten rounds of median filtering.

[0105] This step ensures that the air conditioning application does not read invalid values ​​from the underlying driver and load feedback during ZCU sleep / wake-up processes, preventing errors in subsequent judgments. Mean filtering of the collected numerical feedback filters out random noise and smooths the feedback. Median filtering of Boolean or enumerated values ​​eliminates impulse noise. Filtering prevents subsequent judgment oscillations caused by noise.

[0106] S404, Maintenance Commands and Expected Status.

[0107] In this embodiment, the maintenance driver control commands can be used to maintain the expected load state. Optionally, the air conditioning application receives user commands every cycle after Wake-on-LAN. A user command can calculate one or more expected load states and underlying driver control commands as the load runs, and these expected states and control commands need to be maintained. For cycled control, the expected load state and underlying driver control commands need to be updated in real time. For event-based control that detects signal transitions (the underlying driver is called once after a transition is detected), the last expected state and underlying driver control command are recorded.

[0108] For example, when an air conditioning application receives a command to control the motor to 0%, it first controls the motor to rotate in the 0% direction. At this time, the underlying driver control command is for the motor to move forward or backward, and the load expects the motor to be moving and the feedback voltage to approach 0%. When the motor reaches the 0% position, the air conditioning application controls the motor to stop rotating. At this time, the underlying driver command is for the motor to stop, and the load expects the motor to stop moving and the feedback voltage to be near 0%. During this process, the application periodically calls the underlying driver, therefore requiring periodic updates to the commands and expected states.

[0109] It should be noted that this step is used to provide a target for subsequent closed-loop monitoring.

[0110] After calculating the control command, the air conditioning application calls the underlying driver interface to perform the control. After calling the driver interface, the return value needs to be read immediately to determine if the interface call was successful. Then, the underlying driver feedback status is read. For periodic control, the driver feedback status needs to be read immediately and the command confirmed. For event-based control, the underlying driver feedback status is read after 50ms and the command confirmed; if a new event occurs during the waiting period, the command confirmation is performed again on the last control.

[0111] Command confirmation requires verifying that the interface call was successful and that the underlying driver's control command matches the driver's feedback status. If so, the underlying driver can be considered to have correctly received and executed the control command. If the interface call fails or the control command and driver feedback status are inconsistent, the air conditioning application should enter a retry state, re-call the driver interface, and re-confirm the command. A three-retry mechanism should be set up. If all three retries fail, the fault should be recorded and handled according to the reason for the failure.

[0112] This step confirms that the application successfully calls the underlying driver interface each time, ensuring that there are no issues such as call failure or calls not taking effect.

[0113] S405, Periodic closed-loop monitoring.

[0114] In this step, after successful command confirmation, it is necessary to read the underlying driver feedback status of all loads at a 100ms interval and compare the control command and feedback status of each load. If they are inconsistent, the underlying interface is immediately called again to reset the control command. Simultaneously, a 500ms interval is set to read the actual load status of all loads and compare it with the expected load status. If they are inconsistent, the driver is first commanded to stop output, and then the underlying interface is called again to reset the control command after 100ms.

[0115] The underlying driver feedback state is a purely software state that can be directly read, allowing for a shorter cycle. However, the actual load state requires waiting for actual load actions; too high a sampling frequency could lead to incorrect judgments, thus requiring a longer cycle.

[0116] This step ensures that the underlying driver corresponding to the air conditioning load is not interfered with by driver issues, and that the driver state remains stable over a long period. If the problem cannot be resolved, the fault can also be captured and recorded. Possible driver issues include: miswriting of the air conditioning load driver in other software modules of the controller ZCU, command overwriting due to software asynchrony, or driver shutdown caused by overheating or overcurrent in the driver chip.

[0117] S406, Command confirmation.

[0118] S407, Fault Record Processing.

[0119] In this step, for faults occurring during command confirmation and periodic closed-loop monitoring, fault classification is performed based on the cause of the fault, corresponding handling strategies are set, and timestamps, underlying driver control commands, underlying driver feedback status, actual load status, driver fault type, number of retries, and controller system status are recorded. Specific fault records can be found in Table 2, and will not be elaborated upon here.

[0120] This step categorizes faults and handles them differently, ensuring that basic functions are maintained when the interface fails, ensuring safe operation of the load, facilitating fault tracing, analysis, and troubleshooting, and enabling long-term reliability improvements.

[0121] S408, End.

[0122] In summary, in this embodiment, after the ZCU wakes up, it first determines whether the feedback acquisition window is met. If so, feedback sampling and filtering are performed, and user commands are received to perform maintenance commands and calculate the desired state before entering the control state machine. The control state machine defaults to a periodic closed-loop monitoring state, continuously monitoring the underlying driver feedback state and the actual load state. If a new user command is received requiring a control command to be issued, or if an inconsistency in the monitored state is detected, the system enters a command confirmation state, calls the driver, and performs confirmation. If the command confirmation retry mechanism also fails, a fault record is established, and the system is processed according to the fault level.

[0123] In other words, this embodiment sets up the following methods in the ZCU air conditioning application software: feedback sampling window and filtering, maintenance of command and expected states, command confirmation and retry mechanism, periodic closed-loop monitoring, and fault classification recording and processing. These methods systematically ensure that during the operation of the air conditioning application software, the underlying driver will not experience problems such as call failures, ineffective calls, or execution discrepancies with expectations.

[0124] Please see Figure 5 , Figure 5 This is a structural block diagram of a device control apparatus according to an embodiment of this application. Figure 5 The device may include a receiving module 510 and a device control module 520, wherein: The receiving module 510 is used to receive user commands for controlling the target device; the device control module 520 is used to determine, based on the user commands, a first drive control command corresponding to the target device and the expected load state of the target device, wherein the first drive control command represents the expected control intention for the load of the target device, and the expected load state of the target device represents the expected control result for controlling the load of the target device according to the first drive control command; control the load of the target device based on the first drive control command and obtain first control feedback information, wherein the first control feedback information includes a first drive feedback state and a first actual load state of the target device, wherein the first drive feedback state represents the actual control intention for controlling the load of the target device through the first drive control command, and the first actual load state of the target device represents the actual control result for controlling the load of the target device through the first drive control command; if at least one of a first matching result and a second matching result is satisfied, a second drive control command is generated to control the load of the target device through the second drive control command, wherein the first matching result is that the first drive control command and the first drive feedback state do not match, and the second matching result is that the expected load state and the first actual load state do not match.

[0125] In one possible implementation, the controller has a built-in driver chip, which includes a driver layer. When the device control module 520 obtains the first control feedback information, it is used to: periodically obtain the first control feedback information through the driver layer when the driver chip is in the target operating stage.

[0126] In one possible implementation, the load is a load with a first-frame requirement, and the wake-up process of the driver chip, from early to late, includes: network wake-up, driver layer preparation, and full working state, with sampling starting after driver layer preparation is completed. The target running phase includes the running phase between driver layer preparation and network sleep. Alternatively, the load is a load without a first-frame requirement, or the load is a load with a first-frame requirement, but the wake-up process of the driver chip, from early to late, includes: driver layer preparation, full working state, and network wake-up, with sampling starting after full working state, and the target running phase includes the running phase between full working state and network sleep. Here, having a first-frame requirement means that activation is required through first-frame interaction.

[0127] In one possible implementation, when the device control module 520 periodically obtains the first control feedback information through the drive layer, it is used to: periodically obtain the first drive feedback state through the drive layer according to a first preset period; and periodically obtain the first load actual state through the drive layer according to a second preset period, wherein the first preset period is less than the second preset period.

[0128] In one possible implementation, after the device control module 520 controls the load of the target device through the second drive control command, it is further configured to: acquire second control feedback information, the second control feedback information including a second drive feedback state and a second load actual state of the target device, the second drive feedback state being used to indicate the actual control intention of controlling the load of the target device through the second drive control command, and the second load actual state of the target device being used to indicate the actual control result of controlling the load of the target device through the second drive control command; determine the target fault level based on the second control feedback information; and execute the fault action corresponding to the target fault level.

[0129] In one possible implementation, when the device control module 520 determines the target fault level based on the second control feedback information, it is configured to: determine the target fault level as a first fault level if the second drive control command matches the second drive feedback state and the actual state of the second load matches the expected state of the load; determine the target fault level as a second fault level if the actual state of the second load does not match the expected state of the load but the control range corresponding to the actual state of the second load matches the expected state of the load; and determine the target fault level as a third fault level if the actual state of the second load does not match the expected state of the load and the control range corresponding to the actual state of the second load does not match the expected state of the load. The first fault level is lower than the second fault level, and the second fault level is lower than the third fault level. The fault actions corresponding to the first fault level, the second fault level, and the third fault level are all different.

[0130] In one possible implementation, when the device control module 520 executes the fault action corresponding to the target fault level, it is used to: record the fault if the target fault level is the first fault level; record the fault and degrade the output capability of the target device's load if the target fault level is the second fault level; and record the fault and disable the output capability of the target device's load if the target fault level is the third fault level.

[0131] The apparatus in this embodiment can be described with reference to the above method, and will not be repeated here.

[0132] This application also provides an electronic device, please refer to... Figure 6 , Figure 6The electronic device 600 shown includes a processor 610 and a memory 620, wherein the memory 610 is used to store computer programs; and the processor 620 is used to execute the programs stored in the memory 610 to implement the methods described in any embodiment of this application.

[0133] This application also provides a vehicle, including the in-vehicle network system or electronic device described above.

[0134] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any embodiment of this application.

[0135] In this application, "multiple" refers to two or more.

[0136] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0137] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if present) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0138] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0139] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if a method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if a method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0140] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A device control method, characterized in that, include: Receive user commands used to control the target device; Based on the user command, a first drive control command corresponding to the target device and the expected load state of the target device are determined. The first drive control command is used to represent the expected control intention of the load of the target device, and the expected load state of the target device is used to represent the expected control result of controlling the load of the target device according to the first drive control command. The load of the target device is controlled based on the first drive control command, and first control feedback information is obtained. The first control feedback information includes a first drive feedback state and a first load actual state of the target device. The first drive feedback state is used to indicate the actual control intention of controlling the load of the target device through the first drive control command, and the first load actual state of the target device is used to indicate the actual control result of controlling the load of the target device through the first drive control command. If at least one of the first matching result and the second matching result is satisfied, a second drive control command is generated to control the load of the target device through the second drive control command. The first matching result is that the first drive control command does not match the first drive feedback state, and the second matching result is that the expected state of the load does not match the actual state of the first load.

2. The method according to claim 1, characterized in that, Applied to a controller, the controller having a built-in driver chip, the driver chip including a driver layer, the step of obtaining the first control feedback information includes: When the driver chip is in the target operating stage, it periodically acquires first control feedback information through the driver layer.

3. The method according to claim 2, characterized in that, The load is a load with a first-frame requirement, and the wake-up process of the driver chip, from morning to night, includes: network wake-up, driver layer preparation, and full working state, with sampling starting after driver layer preparation is completed. The target running phase includes the running phase between driver layer preparation and network sleep; or, The load is a load without a first frame requirement, or the load has a first frame requirement but the wake-up process of the driver chip includes, from early to late, the following sequence: driver layer preparation, full working state and network wake-up, and sampling begins after full working state. The target running stage includes the running stage between full working state and network sleep. The requirement of a first frame indicates that activation requires interaction with the first frame.

4. The method according to claim 2, characterized in that, The step of periodically acquiring the first control feedback information through the driving layer includes: The first driving feedback state is periodically obtained through the driving layer according to a first preset period; The first load actual state is obtained periodically by the driving layer according to a second preset period, wherein the first preset period is shorter than the second preset period.

5. The method according to any one of claims 1-4, characterized in that, After controlling the load of the target device through the second drive control command, the method further includes: Acquire second control feedback information, which includes a second drive feedback state and a second actual load state of the target device. The second drive feedback state is used to indicate the actual control intention to control the load of the target device through the second drive control command, and the second actual load state of the target device is used to indicate the actual control result of controlling the load of the target device through the second drive control command. The target fault level is determined based on the second control feedback information; Execute the fault action corresponding to the target fault level.

6. The method according to claim 5, characterized in that, Determining the target fault level based on the second control feedback information includes: If the second drive control command matches the second drive feedback state and the actual state of the second load matches the expected state of the load, then the target fault level is determined to be the first fault level. If the actual state of the second load does not match the expected state of the load, but the control range corresponding to the actual state of the second load matches the expected state of the load, then the target fault level is determined to be the second fault level. If the actual state of the second load does not match the expected state of the load and the control range corresponding to the actual state of the second load does not match the expected state of the load, then the target fault level is determined to be the third fault level. Wherein, the first fault level is lower than the second fault level, the second fault level is lower than the third fault level, and the fault action corresponding to the first fault level, the fault action corresponding to the second fault level, and the fault action corresponding to the third fault level are all different from each other.

7. The method according to claim 6, characterized in that, The execution of the fault action corresponding to the target fault level includes: If the target fault level is the first fault level, then record the fault; If the target fault level is the second fault level, then the fault is recorded and the output capacity of the target device's load is downgraded. If the target fault level is the third fault level, then the fault is recorded and the load output capability of the target device is disabled.

8. An electronic device, characterized in that, It includes a processor and a memory, wherein: the memory is used to store computer programs; and the processor is used to execute the programs stored in the memory to implement the method as claimed in any one of claims 1-7.

9. A vehicle, characterized in that, Including the electronic device as described in claim 8.

10. A computer-readable storage medium, characterized in that, A computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as claimed in any one of claims 1-7.

Images