Electrical adjustment fault data storage method

Abstract

The application discloses an electric adjustment fault data storage method, relates to the technical field of fault data storage, and discloses an electric adjustment fault data storage method, wherein fault data is broadcast to a CAN bus by a fault electric adjustment and is stored by distributed backup of a receiving electric adjustment, so that the technical problem that single-point fault may cause permanent loss of data is effectively solved, the fault data can be reliably stored when the electric adjustment is physically damaged, and subsequent fault analysis is facilitated.

Description

Technical Field

[0001] This application relates to the field of fault data storage technology, and in particular to a method for storing fault data of electronic control systems. Background Technology

[0002] In the electronic control system of unmanned aerial vehicles (UAVs), the electronic speed controller (ESC) is responsible for regulating motor speed. Accurately recording fault data is fundamental for fault diagnosis and system optimization when the ESC malfunctions. Currently, the industry commonly employs two data storage mechanisms. The first mechanism relies on the faulty ESC's own storage unit for data retention. In practical applications, when a UAV experiences a power outage due to an ESC malfunction, leading to a crash, the faulty ESC often suffers physical structural damage, causing its internal storage medium to fail, resulting in the permanent loss of critical parameters, operating status, and other core information at the time of the fault. This data loss directly leads to a lack of basis for subsequent fault analysis, making it difficult to pinpoint the root cause and severely impacting product iteration and safety performance improvement. The second mechanism transmits fault data to the flight control unit or dedicated recording equipment via a communication bus for off-site storage. While this avoids the risks of single-point storage, different brands of flight control equipment use non-standardized communication protocols, requiring significant resources for protocol parsing and adaptation development, extending project cycles. Furthermore, the additional dedicated storage hardware not only increases the overall system cost but also introduces new connection nodes and potential fault sources, reducing system integration and reliability.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method for storing fault data of electronic speed controllers (ESCs), which aims to ensure that fault data can still be reliably preserved when the ESC is physically damaged, so as to facilitate subsequent fault analysis.

[0005] To achieve the above objectives, this application proposes a method for storing power dispatcher fault data, the method comprising: When an ESC malfunctions, the faulty ESC generates fault data and sends the fault data to the CAN bus; the fault data includes the faulty ESC identifier, fault type, fault occurrence time, and operating parameters before the fault. The receiving ESC on the CAN bus receives the fault data and performs CRC verification on the received fault data to obtain the fault data that passes the verification. The receiving ESC is an ESC on the CAN bus that can receive and store fault data, except for the ESC that is currently transmitting fault data. This includes fault-free ESCs and ESCs that have experienced a fault but have not yet transmitted fault data. The fault data that passes the verification is added to the storage queue, and when the storage location is idle, it is retrieved from the storage queue and stored in the local storage space of the receiving ECH to obtain backup fault data; When fault data is needed, the backup fault data is read from any ESC that stores backup fault data via the CAN bus.

[0006] In one embodiment, when an ESC malfunctions, the step of generating fault data and sending the fault data to the CAN bus includes: When the ESC detects a fault in itself, the faulty ESC generates a lock message and sends the lock message to the CAN bus; After sending the lock message, the faulty ESC waits for a preset time while monitoring other lock messages on the CAN bus. The fault dispatcher performs fault transmission channel contention processing based on other monitored locking messages to determine the dispatcher that has the right to send fault messages; The fault-transmitting ESC, having obtained fault transmission permission, sends its fault data message to the CAN bus; After sending the fault data message, the faulty ESC generates an unlock message and sends the unlock message to the CAN bus.

[0007] In one embodiment, the step of determining the dispatcher that obtains fault transmission permission by performing fault transmission channel contention processing based on other monitored locking messages includes: The faulty ESC obtains its own ESC identifier and the ESC identifier contained in other monitored locking messages; The faulty ESC compares its own ESC identifier with the ESC identifiers in other monitored locking messages. When the comparison result shows that the faulty ESC identifier value is less than the ESC identifier value in other locked messages, the faulty ESC obtains the fault transmission permission. When the comparison result shows that the value of its own ESC identifier is not less than the value of the ESC identifier in other locking messages, the faulty ESC locks its own fault transmission channel.

[0008] In one embodiment, the step of receiving the fault data on the CAN bus and performing CRC check processing on the received fault data to obtain fault data that passes the check includes: The receiving ESC receives messages from the CAN bus and performs type determination processing on the messages; When the message type determination result is a locked message, the receiving ESC performs fault transmission channel locking processing. When the message type determination result is a fault data message, the receiving ESC performs buffering processing on the fault data message to obtain buffered fault data; and the receiving ESC performs CRC check processing on the buffered fault data to obtain fault data that passes the check. When the message type determination result is an unlock message, the receiving ESC unlocks its own fault transmission channel.

[0009] In one embodiment, when the message type determination result is a locked message, the receiving switch performs fault transmission channel locking processing as follows: The receiving ESC determines whether it has sent a locking message; When the judgment result is that it has not sent a lock message, the receiving ESC directly locks its own fault transmission channel. When the judgment result is that it has sent a lock message, the receiving ESC compares its own ESC identifier with the ESC identifier in the received lock message. When the comparison result shows that the value of its own ESC identifier is greater than the value of the ESC identifier in the received lock message, the receiving ESC locks its own fault transmission channel; when the comparison result shows that the value of its own ESC identifier is not greater than the value of the ESC identifier in the received lock message, the receiving ESC keeps its own fault transmission channel unlocked.

[0010] In one embodiment, when the message type determination result is a fault data message, the receiving switch performs buffering processing on the fault data message to obtain buffered fault data, the step includes: After receiving a fault data packet, the receiving ESC stores the fault data packet in the receiving buffer queue; The receiving ESC performs an integrity check on fault data packets in the receiving buffer queue to determine whether the fault data has been received completely. When the fault data is received completely, the receiver ESC will extract the complete fault data from the receive buffer queue to obtain the buffered fault data; when the fault data is not received completely, the receiver ESC will continue to wait to receive subsequent fault data packets.

[0011] In one embodiment, the step of receiving the ESC to perform CRC check processing on the buffered fault data to obtain fault data that passes the check includes: The receiving ESC extracts the CRC checksum from the cached fault data; The receiving ESC calculates the valid content of the cached fault data according to the CRC check algorithm to obtain the calculated CRC check code; The receiving ESC compares the extracted CRC checksum with the calculated CRC checksum. When the CRC checksums match, the receiving ESC marks the cached fault data as fault data that has passed the checksum verification; when the CRC checksums do not match, the receiving ESC discards the cached fault data.

[0012] In one embodiment, the steps of adding the verified fault data to a storage queue, and retrieving it from the storage queue and storing it in the local storage space of the receiving switch when the storage location is idle, to obtain backup fault data, include: The receiving ESC adds the verified fault data to the storage queue; The system receives the status of the local storage space from the electronic speed controller to determine whether the storage space is free. When the storage space is idle, the receiving ESC retrieves the verified fault data from the storage queue; The receiving ESC writes the retrieved, verified fault data into the local storage space to obtain backup fault data; and the receiving ESC updates the status information of the local storage space and records the storage information of the backup fault data.

[0013] In one embodiment, when fault data needs to be obtained, the step of reading the backup fault data from any ESC storing backup fault data via the CAN bus includes: External devices send data read commands to the target ESC via the CAN bus; The target ESC receives the data read instruction and parses and processes the data read instruction; The target ESC accesses the local storage space based on the parsing results, searches for backup fault data, and sends the found backup fault data to external devices via the CAN bus.

[0014] In one embodiment, the method further includes: Before sending the fault data to the CAN bus, the faulty ESC first saves the fault data to its own local storage space.

[0015] The fault data storage method for ESCs proposed in this application broadcasts fault data to the CAN bus via a faulty ESC and performs distributed backup storage by a receiving ESC. This effectively solves the technical problem that a single point of failure may lead to permanent data loss and ensures that fault data can still be reliably preserved when the ESC is physically damaged, facilitating subsequent fault analysis. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating an embodiment of the electronic control fault data storage method of this application; Figure 2 For this application Figure 1 A detailed flowchart of step S100; Figure 3 For this application Figure 2 A detailed flowchart of step S130; Figure 4 For this application Figure 1 A detailed flowchart of step S200; Figure 5 For this application Figure 4 A detailed flowchart of step S220; Figure 6 For this application Figure 4 A detailed flowchart of step S230 provided in one embodiment; Figure 7 For this application Figure 4 A detailed flowchart of another embodiment of step S230 is provided; Figure 8 For this application Figure 1 Detailed flowchart of step S300; Figure 9 For this application Figure 1 A detailed flowchart of step S400.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of this application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be understood that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0022] In existing technologies, ESC fault data storage solutions store fault data within the faulty ESC itself, which may be lost due to physical damage, affecting fault analysis. Sending data to the flight controller or other dedicated equipment for storage faces challenges such as complex protocol integration, high communication costs, and increased system costs due to additional hardware. None of these solutions can effectively guarantee the integrity and reliability of fault data without incurring additional costs.

[0023] Based on this, embodiments of this application provide a method for storing power dispatcher fault data, referring to... Figure 1 The method for storing fault data of the electronic control unit includes steps S100 to S400, wherein: Step S100: When the ESC fails, the faulty ESC generates fault data and sends the fault data to the CAN bus; the fault data includes the faulty ESC identifier, fault type, fault occurrence time, and operating parameters before the fault. Step S200: The receiving ESC on the CAN bus receives the fault data and performs CRC verification on the received fault data to obtain the fault data that passes the verification. The receiving ESC is an ESC on the CAN bus that can receive and store fault data, except for the ESC that is currently sending fault data. It includes fault-free ESCs and ESCs that have experienced a fault but have not yet sent fault data. Step S300: Add the verified fault data to the storage queue, and when the storage location is idle, retrieve it from the storage queue and store it in the local storage space of the receiving ECH to obtain backup fault data; Step S400: When it is necessary to obtain fault data, read the backup fault data from any ESC that stores backup fault data via the CAN bus.

[0024] In this embodiment, the ESC (Electronic Speed ​​Controller) is an electronic device used to control the motor speed, responsible for receiving control commands and driving the motor. Fault data refers to the set of fault-related information generated and recorded by the ESC itself when an abnormality or fault occurs during operation. Fault data may include the unique identifier of the faulty ESC, the specific type of fault, the precise time of the fault occurrence, and key operating parameters of the ESC before the fault, such as current, voltage, and speed. The CAN bus, or Controller Area Network bus, is a serial communication bus widely used in automotive electronics, industrial automation, and other fields, allowing multiple nodes (such as ESCs) to exchange data on the same bus. In this embodiment, the CAN bus serves as the communication medium for transmitting fault data between ESCs.

[0025] In this embodiment, CRC check, or Cyclic Redundancy Check, generates a checksum by calculating a check code for each data block. The receiver recalculates the checksum upon receiving the data and compares it with the received checksum to detect any errors during transmission, thus ensuring data integrity and accuracy. The storage queue is a First-In-First-Out (FIFO) data structure used to temporarily store data awaiting processing or storage. In this embodiment, faulty data that passes the checksum verification is temporarily placed in this queue while waiting to be written to local storage. Backup faulty data refers to a copy of the faulty data received, verified, and stored in the local storage space of the receiving electronic speed controller (ESC). This backup faulty data serves as redundant storage of the original faulty data, aiming to prevent data loss due to damage to the original faulty ESC, thereby improving the reliability and recoverability of the faulty data.

[0026] In this embodiment, when an ESC (Electronic Speed ​​Controller) malfunctions, the faulty ESC generates fault data and sends it to the CAN bus. This fault data may include the faulty ESC's unique identifier, fault type, time of fault occurrence, and operating parameters prior to the fault. Specifically, after detecting its own anomaly, the faulty ESC can immediately encapsulate a predefined fault data packet into a CAN message and send it. Alternatively, after detecting a fault, the faulty ESC can repeatedly broadcast its fault data at fixed time intervals to ensure that the data can be received by other nodes in the network.

[0027] In this embodiment, the receiving ESC on the CAN bus receives the fault data and performs CRC check processing on the received fault data to obtain fault data that has passed the check. The receiving ESC continuously monitors the communication on the CAN bus. When it receives a message, it can first determine whether the message type is a fault data message. If so, it extracts the data content and the attached CRC checksum from the message. Subsequently, the receiving ESC uses a preset CRC algorithm to calculate the data content and compares the calculation result with the extracted checksum. If the two match, the fault data is considered complete and accurate, and it is marked as fault data that has passed the check. As an optional implementation, the receiving ESC can also use a simple checksum algorithm to perform integrity checks on the received fault data.

[0028] In this embodiment, the verified fault data is added to a storage queue. When a storage location becomes available, the data is retrieved from the storage queue and stored in the local storage space of the receiving ECH, thus obtaining backup fault data. After receiving the verified fault data, the receiving ECH can temporarily store it in a first-in-first-out (FIFO) storage queue. A background process or task continuously monitors the status of the receiving ECH's local storage space. Once a free storage location is detected, the process retrieves the fault data to be stored from the storage queue and writes it to the local non-volatile storage medium, thereby forming backup fault data. As another implementation, if the local storage space becomes available immediately upon receiving the verified fault data, the data can also be written directly without going through the temporary storage queue.

[0029] In this embodiment, when fault data is needed, it is read from any ESC storing backup fault data via the CAN bus. The external device can be a diagnostic tool or a host computer, which can send a data read command to the ESC network via the CAN bus. This command can be a broadcast command, requesting all ESCs storing backup fault data to send their data. The ESC receiving the command will access its local storage space, locate and retrieve the backup fault data, and then send this data to the external device via the CAN bus. Alternatively, the external device can also send a read command to an ESC with a specific address in the network to obtain the backup fault data stored in that ESC.

[0030] In this embodiment, when an ESC (Electronic Speed ​​Controller) malfunctions, the faulty ESC actively sends fault data to the CAN bus, where a receiving ESC in the network receives, verifies, and backs up the data locally. This solves the problem of critical fault data loss due to physical damage to the faulty ESC in traditional solutions. Furthermore, this method utilizes the existing CAN bus for data transmission and local storage by the ESC, avoiding the need for additional hardware and complex protocol integration. This reduces system costs and development difficulty, improves the reliability and recoverability of fault data storage, and provides data support for subsequent fault analysis.

[0031] In one feasible implementation, refer to Figure 2 Step S100 includes steps S110 to S150, wherein: Step S110: When the ESC detects a fault in itself, the faulty ESC generates a locking message and sends the locking message to the CAN bus. Step S120: After sending the lock message, the fault ESC waits for a preset time while monitoring other lock messages on the CAN bus. Step S130: The fault dispatcher performs fault transmission channel contention processing based on other monitored locking messages to determine the dispatcher that has obtained fault transmission permission. Step S140: The fault ESC that has obtained fault transmission permission sends its fault data message to the CAN bus. In step S150, after sending the fault data message, the fault ESC generates an unlock message and sends the unlock message to the CAN bus.

[0032] In this embodiment, when an ESC detects a fault, to avoid data transmission conflicts on the CAN bus with other ESCs that may also fail simultaneously, the faulty ESC generates a specific locking message. This locking message may contain a unique identifier of the faulty ESC, indicating that the ESC has entered a fault state and is attempting to acquire bus transmission rights. By sending this locking message to the CAN bus, other ESCs can detect that an ESC is competing for bus resources, thus providing a basis for subsequent contention processing. The locking message can be preset with a high priority to ensure that it can be received by other ESCs in a timely manner.

[0033] In this embodiment, after sending a lock message, the faulty ESC does not immediately send fault data but enters a waiting state for a preset period of time. During this period, the faulty ESC actively monitors communication on the CAN bus, paying particular attention to whether other ESCs have also sent lock messages. The preset time is designed to provide other ESCs that may fail simultaneously with the opportunity to send lock messages, allowing all competitors to demonstrate their competitive intent within the same time window. By monitoring other lock messages, the faulty ESC can understand how many ESCs are currently competing for fault data transmission rights on the bus, providing necessary information for subsequent competition processing.

[0034] In this embodiment, the preset time is determined based on the CAN bus baud rate, the transmission time of a single-frame lock message, and the maximum number of ESCs in the system, ensuring that all potential competitors can complete the transmission of the lock message within this time window. Specifically, the preset time can be calculated as follows: Preset time = (Transmission time of a single-frame lock message + Frame interval time) × Maximum number of ESCs in the system × Redundancy coefficient. The transmission time of a single-frame lock message is determined by the CAN bus baud rate and the frame length of the lock message, i.e., by dividing the frame length (number of bits) by the baud rate. For example, when the CAN bus baud rate is 1 Mbps and the lock message uses a standard data frame format (including a frame start bit, arbitration field, control field, data field, CRC field, acknowledgment field, and frame end bit, totaling approximately 108 bits), the single-frame transmission time is approximately 0.108 milliseconds. The frame interval time is the minimum interval between adjacent CAN frames specified by the CAN protocol, typically 3 bits of recessive level time, which is approximately 0.003 milliseconds at the aforementioned baud rate. The maximum number of ESCs in the system refers to the upper limit of the total number of ESCs connected to the CAN bus. For example, in a hexacopter or octocopter UAV system, the number of ESCs is 6 or 8. The redundancy coefficient is a preset value greater than 1, such as 1.5 to 2.0, used to provide time margin to cope with actual operating condition deviations such as bus load fluctuations and node response delays. Taking an octocopter UAV system as an example, if the single frame transmission time is approximately 0.108 milliseconds, the frame interval is approximately 0.003 milliseconds, the maximum number of ESCs is 8, and the redundancy coefficient is 2.0, then the preset time = (0.108 + 0.003) × 8 × 2.0 ≈ 1.78 milliseconds. This preset time is much greater than the shortest time required for all ESCs to complete the transmission of the lock message, thereby ensuring that all ESCs that may fail simultaneously have sufficient time window to complete the transmission of the lock message, achieving the technical effect that all competitors can demonstrate their competitive intentions within the same time window.

[0035] In this embodiment, after waiting for and monitoring all contention lock messages, the faulty ESC analyzes and compares its own lock messages with those of other ESCs according to preset contention rules to determine which ESC can obtain the right to send fault data. The purpose of contention handling is to select an ESC to send its fault data first through a fair and deterministic mechanism when multiple faulty ESCs exist simultaneously, thus avoiding bus conflicts. For example, the comparison can be based on the numerical value of the ESC identifier, with the ESC with the smallest value obtaining the transmission right, or a priority-based arbitration mechanism can be used to ensure the orderly allocation of CAN bus resources in multi-fault scenarios.

[0036] In this embodiment, once a faulty ESC gains the right to transmit fault data through contention, it can safely send its complete fault data message to the CAN bus. At this point, since other competitors have been eliminated or are in a waiting state, the faulty ESC can exclusively control the bus resources, ensuring that its fault data message can be transmitted completely and without collisions. The fault data message may include information such as the faulty ESC identifier, fault type, time of fault occurrence, and operating parameters before the fault, to facilitate subsequent fault diagnosis and analysis.

[0037] In this embodiment, after the faulty ESC that has obtained transmission permission successfully transmits its fault data message, it generates an unlock message and sends it to the CAN bus. The purpose of the unlock message is to notify all ESCs on the CAN bus (including other faulty ESCs and receiving ESCs that are in a waiting state) that the current bus fault data transmission cycle has ended, and the bus resources can be released or re-competed for. This helps to restore the normal communication order of the CAN bus and allows other faulty ESCs that may still be waiting to restart the competition process, or allows the receiving ESC to unlock the faulty transmission channel.

[0038] In this embodiment, by employing the above-described technical solution, when multiple ESCs fail simultaneously, this application introduces a mechanism of locking messages, contention handling, and unlocking messages. This effectively solves the problem of CAN bus conflicts and data loss that may result from multiple faulty ESCs simultaneously transmitting fault data. The faulty ESC first sends a locking message to indicate its contention intention. By monitoring other locking messages, it performs orderly contention handling within a preset time, ensuring that only one ESC obtains fault transmission permission. This avoids disordered contention and data collisions on the bus, guaranteeing that the fault data message can be transmitted completely and reliably to the CAN bus. Subsequently, by sending an unlocking message, bus resources are released in a timely manner, allowing other faulty ESCs to continue contention or the bus to resume normal communication. This improves the efficiency and reliability of fault data transmission, ensuring timely backup of fault data and the accuracy of subsequent analysis.

[0039] In one feasible implementation, refer to Figure 3Step S130 includes steps S131 to S134, wherein: Step S131: The faulty ESC obtains its own ESC identifier and the ESC identifier contained in other monitored locking messages; Step S132: The faulty ESC compares its own ESC identifier with the ESC identifiers in other monitored locking messages. Step S133: When the comparison result shows that the value of its own ESC identifier is less than the value of the ESC identifier in other locking messages, the faulty ESC obtains the fault transmission permission. Step S134: When the comparison result shows that the value of its own ESC identifier is not less than the value of the ESC identifier in other locking messages, the faulty ESC locks its own fault transmission channel.

[0040] In this embodiment, the faulty ESC acquires its own ESC identifier and the ESC identifiers contained in other monitored locking messages, aiming to provide the necessary information foundation for subsequent competition processing. The ESC identifier is a unique identification code for each ESC in the system, typically assigned during system initialization or hardened in the hardware. When a faulty ESC detects its own fault and sends a locking message, it enters a listening state. During this period, it not only knows its own ESC identifier but also receives and parses locking messages sent by other faulty ESCs via the CAN bus, thereby extracting the identifiers of other faulty ESCs carried in these messages. This acquisition mechanism ensures that each participating faulty ESC can grasp the identity information of all competitors.

[0041] In this embodiment, the faulty ESC compares its own ESC identifier with the ESC identifiers in other monitored locking messages. After acquiring all relevant ESC identifiers, each faulty ESC compares its own ESC identifier with the identifiers of all other faulty ESCs it monitors, either individually or as a whole. This comparison can be a simple numerical comparison, such as comparing the binary or decimal values ​​of the two identifiers. This standardized numerical comparison provides a clear basis for subsequent permission allocation, ensuring the fairness and certainty of the competition process.

[0042] Based on this, when the comparison result shows that the faulty ESC's own ESC identifier value is less than the ESC identifier values ​​in other locked messages, the faulty ESC gains fault transmission permission. After the value comparison process, if the faulty ESC finds that its own ESC identifier value is the smallest among all competing ESC identifiers, then the faulty ESC is determined to have gained fault transmission permission. This rule based on the smallest identifier priority is a common arbitration mechanism that ensures that among multiple competitors, only one ESC can ultimately win and gain transmission permission, thereby avoiding bus conflicts caused by multiple ESCs simultaneously sending faulty data packets.

[0043] In this embodiment, when the comparison result shows that the faulty ESC's own identifier value is not less than the ESC identifier values ​​in other locked messages, the faulty ESC locks its own fault transmission channel. If, after comparison, the faulty ESC finds that its own ESC identifier value is not less than (i.e., greater than or equal to) the identifier value of any other competing ESC, it means that it has not obtained the fault transmission permission for this time. In this case, the faulty ESC will actively lock its own fault transmission channel and stop attempting to send fault data packets. This locking mechanism is crucial to ensuring the order of bus communication; it prevents ESCs without permission from continuing to occupy bus resources, thereby ensuring that ESCs with permission can successfully send their fault data.

[0044] In this embodiment, when multiple ESCs fail almost simultaneously, each failed ESC acquires and compares its own identifier with those of other failed ESCs. Based on a preset numerical comparison rule (e.g., the lowest identifier value takes priority), it autonomously determines whether to obtain fault transmission permission. This arbitration method based on ESC identifiers avoids the complexity and uncertainty inherent in traditional bus arbitration, ensuring that only one failed ESC can obtain transmission permission in multi-fault scenarios. This effectively prevents collisions and loss of fault data packets on the CAN bus. Faulty ESCs that do not obtain permission will actively lock their own transmission channel, further ensuring the orderly use of bus resources, improving the reliability and real-time performance of fault data transmission, and enabling the system to obtain fault information promptly and accurately, providing a data foundation for subsequent fault diagnosis and processing.

[0045] In one feasible implementation, refer to Figure 4 Step S200 includes steps S210 to S240, wherein: Step S210: The receiving ESC receives a message from the CAN bus and performs type determination processing on the message; Step S220: When the message type determination result is a locked message, the receiving switch performs fault transmission channel locking processing. Step S230: When the message type determination result is a fault data message, the receiving switch performs buffering processing on the fault data message to obtain buffered fault data; and the receiving switch performs CRC verification processing on the buffered fault data to obtain fault data that passes the verification. Step S240: When the message type judgment result is an unlock message, the receiving switch unlocks its own fault transmission channel.

[0046] In this embodiment, the receiver ESC continuously monitors communication on the CAN bus, receiving all arriving CAN messages. Each received message may contain an identifier (CAN ID), which can be used to distinguish the message type and priority. By parsing the message identifier or specific fields in the message content, the receiver ESC can determine whether the currently received message is a lock message, a fault data message, an unlock message, or other regular control message. This type determination is the basis for subsequently adopting different processing strategies for different messages.

[0047] In this embodiment, when the receiving ESC receives a locking message, it locks its own fault transmission channel according to preset rules or protocols. That is, while other fault ESCs are competing for or transmitting fault data, the receiving ESC will pause or prohibit itself from transmitting fault-related messages to avoid bus conflicts or interference with the ongoing fault data transmission process and ensure the orderly transmission of fault data.

[0048] In this embodiment, when the receiving ESC identifies a received message as a fault data message, it first performs buffering processing to ensure data integrity and reliability. Buffering can involve temporarily storing the received segmented fault data messages until all relevant messages are received, forming complete fault data. Subsequently, the receiving ESC extracts the CRC checksum contained in the buffered fault data and calculates a CRC checksum based on a preset CRC checksum algorithm. By comparing the extracted CRC checksum with the calculated CRC checksum, it can be determined whether an error occurred during the transmission of the fault data. Only when the checksums match is the fault data considered valid and reliable, and marked as verified fault data for subsequent storage.

[0049] In this embodiment, when the receiving ESC receives the unlock message, it will release the previously locked state of its own fault transmission channel. This means that the receiving ESC can now re-participate in the contention for the fault transmission channel, or send fault data when it malfunctions, thereby restoring its normal fault handling capability and ensuring that the system can return to normal after the fault handling process is completed.

[0050] In this embodiment, after receiving the lock message, the receiving ESC also starts an unlock timeout timer. The timeout threshold of the unlock timeout timer is set to be greater than the complete processing cycle required for the fault ESC to send the lock message and then the unlock message. This complete processing cycle includes at least: a preset waiting time, a contention processing time, and the total transmission time of the fault data packet. For example, when the preset waiting time is approximately 1.78 milliseconds, the contention processing time (including identifier comparison and data packet preparation) is approximately 0.5 milliseconds, and the fault data packet transmission time is approximately 1.0 millisecond, the complete processing cycle is approximately 3.28 milliseconds. In this case, the timeout threshold can be set to 5.0 milliseconds to provide sufficient redundancy margin.

[0051] Based on this, when the unlock timeout timer reaches the timeout threshold and no unlock message corresponding to the lock message is received, it indicates that the faulty ESC sending the lock message may have suffered extreme hardware damage (e.g., power outage, main control chip failure, etc.) and is unable to send the unlock message normally. The receiving ESC automatically unlocks its own faulty transmission channel and clears the unlock timeout timer to restore its ability to participate in contention and send faulty data in the event of a subsequent fault. When the corresponding unlock message is received before the unlock timeout timer reaches the timeout threshold, the receiving ESC unlocks its own faulty transmission channel according to the normal procedure and clears the unlock timeout timer.

[0052] By employing the aforementioned unlock timeout timer mechanism, this application effectively solves the problem that, in extreme hardware failure scenarios where a faulty ESC fails after successfully transmitting a fault data message but before transmitting an unlock message, all receiving ESCs on the CAN bus remain locked to the faulty transmission channel, preventing them from responding to subsequent lock contention from newly faulty ESCs and causing the system to lose its fault data backup capability. This mechanism ensures that even in the aforementioned extreme scenario, the receiving ESCs can automatically recover normal fault response capability after the timeout, thereby guaranteeing the continuous availability of fault data backup function for the entire ESC network in scenarios of continuous multi-point faults.

[0053] In this embodiment, through the above technical solution, the receiving ESC can perform type judgment and processing of messages on the CAN bus, enabling the receiving ESC to adopt corresponding strategies according to different message types (lock messages, fault data messages, unlock messages), thereby effectively managing the fault information flow on the CAN bus. Specifically, by responding to lock messages, the receiving ESC can avoid interference during fault data transmission contention, ensuring the orderly transmission of fault data; by caching and CRC checking fault data messages, the integrity and accuracy of received fault data are ensured, preventing the storage of erroneous data; and by responding to unlock messages, its fault handling capabilities can be restored in a timely manner. Furthermore, by introducing an unlock timeout timer, the receiving ESC has the ability to autonomously recover when unlock messages are lost due to extreme hardware damage, preventing the entire bus network's fault backup function from being paralyzed due to the physical damage of a single ESC. Overall, this solution improves the robustness and reliability of the receiving ESC in receiving and processing fault data in complex CAN bus environments, ensuring accurate backup of fault data and providing a data foundation for subsequent fault diagnosis and analysis.

[0054] In one feasible implementation, refer to Figure 5 Step S220 includes steps S221 to S224, wherein: Step S221: The receiving ESC determines whether it has sent a locking message; Step S222: When the judgment result is that it has not sent a locking message, the receiving switch directly locks its own fault transmission channel. Step S223: When the judgment result is that it has sent a lock message, the receiving ESC compares its own ESC identifier with the ESC identifier in the received lock message. Step S224: When the comparison result is that the value of its own ESC identifier is greater than the value of the ESC identifier in the received lock message, the receiving ESC locks its own fault transmission channel; when the comparison result is that the value of its own ESC identifier is not greater than the value of the ESC identifier in the received lock message, the receiving ESC keeps its own fault transmission channel unlocked.

[0055] In this embodiment, the receiving ESC determines whether it has sent a lock message by querying its internal status flags or related registers to determine whether it has already sent a lock message to the CAN bus. This determination aims to distinguish whether the receiving ESC is receiving a lock message for the first time, or whether it has received a lock message from another ESC after attempting to send one itself.

[0056] In this embodiment, when the determination result is that it has not issued a locking message, the receiving ESC directly locks its own fault transmission channel. This means that after receiving a locking message from another ESC, the receiving ESC immediately stops any potential attempts to transmit fault data and relinquishes bus resources to the ESC that has issued a locking message. Locking a fault transmission channel is typically achieved by setting an internal state variable or disabling the corresponding transmission module. When the determination result is that it has already issued a locking message, the receiving ESC compares its own ESC identifier with the ESC identifier in the received locking message. The ESC identifier is a unique numerical identifier assigned to each ESC, used to distinguish different ESCs in bus communication. This comparison determines which ESC has priority in transmitting fault data by comparing the values ​​of the two ESC identifiers.

[0057] In this embodiment, when the comparison result shows that the value of the receiving ESC's own ESC identifier is greater than the value of the ESC identifier in the received lock message, the receiving ESC locks its own fault transmission channel. This means that under the preset arbitration rules (e.g., the smaller the value, the higher the priority), the current receiving ESC has a lower priority than the ESC that has sent the lock message, so it should voluntarily relinquish its transmission permission and lock its own channel. When the comparison result shows that the value of the receiving ESC's own ESC identifier is not greater than the value of the ESC identifier in the received lock message, the receiving ESC maintains the unlocked state of its own fault transmission channel, indicating that the current receiving ESC has a higher priority than or equal to the ESC that has sent the lock message, so it has the right to continue to maintain the unlocked state of its transmission channel in order to send its own fault data in subsequent steps.

[0058] In this embodiment, when the receiving ESC receives a locking message, it no longer simply locks itself, but first determines whether it has already sent a locking message. This determination avoids unnecessary locking operations and improves the flexibility of system response. Especially in complex scenarios where multiple ESCs may attempt to send locking messages simultaneously, priority arbitration based on the ESC identifier is achieved by comparing its own ESC identifier with the ESC identifier in the received locking message. When its own ESC identifier value is greater than the ESC identifier value in the received locking message, the receiving ESC actively locks its own channel, relinquishing the sending permission to a higher-priority ESC; otherwise, it remains unlocked, ensuring that it can continue to send fault data. This mechanism effectively solves the channel contention problem when multiple ESCs send locking messages simultaneously, avoids bus conflicts and data transmission chaos, and ensures that fault data can be sent in a timely and accurate manner by a higher-priority ESC, thereby improving the reliability of fault data storage and the overall stability of the system.

[0059] In one feasible implementation, refer to Figure 6 Step S230 includes steps S231A to S233A, wherein: Step S231A: After receiving the fault data message, the receiving ESC stores the fault data message in the receiving buffer queue; Step S232A: The receiving ESC performs an integrity check on the fault data packets in the receiving buffer queue to determine whether the fault data has been received completely. In step S233A, when the fault data is received completely, the receiving ESC extracts the complete fault data from the receiving buffer queue to obtain the buffered fault data; when the fault data is not received completely, the receiving ESC continues to wait to receive subsequent fault data packets.

[0060] In this embodiment, the receive buffer queue is a data structure used to temporarily store received faulty data packets. Its function is to temporarily store these segmented packets sequentially when faulty data is transmitted in multiple segments, so that they can be reassembled and checked for integrity later. This queue can be implemented using a first-in, first-out (FIFO) mechanism. For example, a contiguous storage area can be reserved in the memory of the receiving circuit breaker, and pointers or indexes can be used to manage the storage and retrieval of packets.

[0061] In this embodiment, integrity checking refers to the receiving circuit breaker analyzing fault data packets in the receive buffer queue to determine whether all the original fault data has been received without loss. Integrity checking can be implemented by: checking whether the sequence numbers in the packets are consecutive, checking whether the total packet length field matches the sum of the lengths of the received packets, or checking for the presence of a specific end-of-transmission marker packet. These checks ensure that the reassembled fault data is complete and logically correct.

[0062] In this embodiment, when the integrity check confirms that all fault data has been received, the receiving ESC splices or reassembles all messages constituting complete fault data in the receive buffer queue to form a complete fault data block. This complete fault data block is the buffered fault data, which will be retrieved from the receive buffer queue and prepared for subsequent CRC check processing. When the integrity check result indicates that the fault data has not been completely received, the receiving ESC will not immediately process the incomplete data in the current queue, but will maintain the state of the receive buffer queue and continuously monitor the CAN bus, waiting to receive the remaining subsequent messages constituting complete fault data. This mechanism ensures that even in the case of data segmented transmission, complete fault data can eventually be collected.

[0063] In this embodiment, when receiving fault data packets, the receiving ESC no longer simply processes them immediately after reception. Instead, it first stores the received packets in a receive buffer queue. Subsequently, by performing an integrity check on the packets in the receive buffer queue, it can effectively identify whether all fault data has been received. When fault data is transmitted in multiple segments, this scheme ensures that all segmented packets are correctly collected and reassembled, avoiding CRC check failures or fault data loss due to incomplete data. This significantly improves the reliability and accuracy of fault data reception, providing a complete and effective data source for subsequent CRC check processing, thereby ensuring the integrity and availability of backup fault data, which is of great significance for accurate fault diagnosis and analysis.

[0064] In one feasible implementation, refer to Figure 7 Step S230 further includes steps S231B to S234B, wherein: Step S231B: The receiving ESC extracts the CRC checksum from the cached fault data; Step S232B: The receiving ESC calculates the valid content of the cached fault data according to the CRC check algorithm to obtain the calculated CRC check code; Step S233B: The receiving ESC compares the extracted CRC checksum with the calculated CRC checksum. In step S234B, when the CRC checksums match, the receiving ESC marks the cached fault data as fault data that has passed the checksum verification; when the CRC checksums do not match, the receiving ESC discards the cached fault data.

[0065] In this embodiment, Cyclic Redundancy Check (CRC) codes are widely used in data communication and storage to detect errors that may occur during data transmission or storage. Before the faulty ESC generates a fault data message and sends it to the CAN bus, a CRC checksum is typically calculated based on the valid content of the fault data message and appended to a specific location in the fault data message. After receiving the complete fault data message and performing buffering, the receiving ESC can parse the pre-applied CRC checksum from the buffered fault data. This extracted CRC checksum serves as a commitment to data integrity from the original sender and is the benchmark for subsequent verification processes.

[0066] Based on this, after receiving and buffering the fault data, the receiving ESC uses the same CRC checksum algorithm as the fault ESC to recalculate the valid content (i.e., the part that does not contain the original CRC checksum) in the buffered fault data. The CRC checksum algorithm treats the data as a binary polynomial and performs division with a preset generator polynomial, taking the remainder as the checksum. Common CRC algorithms include CRC-8, CRC-16, and CRC-32. The specific algorithm chosen depends on the stringency of data integrity requirements and computational resource limitations. Through the above calculation, the receiving ESC can independently generate a CRC checksum based on the currently received data content.

[0067] In this embodiment, after obtaining the original CRC checksum extracted from the cached fault data and the CRC checksum recalculated based on the valid content of the cached fault data, the receiving switch performs a comparison operation. If the two are exactly the same, it indicates that the valid content of the fault data packet has not been erroneous or corrupted throughout the entire process from the fault switch to the receiving switch's transmission and buffering. Conversely, if the two are inconsistent, it indicates that the data may have been interfered with during transmission or buffering, causing the data content to be altered.

[0068] In this embodiment, when the extracted CRC checksum matches the calculated CRC checksum, it indicates that the cached fault data has high integrity and reliability. At this time, the receiving ESC will mark the cached fault data as "fault data that has passed verification," allowing it to enter the subsequent storage queue for persistent storage. Conversely, if the CRC checksums do not match, it means that the cached fault data may be corrupted or incomplete. To avoid storing erroneous data, the receiving ESC will immediately discard the cached fault data, thereby preventing inaccurate fault information from being recorded.

[0069] In this embodiment, after receiving and buffering a fault data message, the receiving ESC can effectively verify the integrity and accuracy of the buffered fault data by extracting the original CRC checksum and recalculating it. Only when the checksums match is the data marked as verified and subsequently stored, thus ensuring that the backup fault data stored in the local storage space is reliable and undamaged. This effectively avoids data corruption caused by interference or errors that may occur during CAN bus transmission, improves the accuracy and reliability of fault data storage, provides a solid data foundation for subsequent fault analysis and diagnosis, and significantly enhances the robustness of the entire ESC fault data storage system.

[0070] In one feasible implementation, refer to Figure 8 Step S300 includes steps S310 to S340, wherein: Step S310: The receiving ESC adds the verified fault data to the storage queue; Step S320: Receive the status of the local storage space from the ESC and determine whether the storage space is free; Step S330: When the storage space is idle, the receiving ESC retrieves the verified fault data from the storage queue. In step S340, the receiving ESC writes the retrieved, verified fault data into the local storage space to obtain backup fault data; and the receiving ESC updates the status information of the local storage space and records the storage information of the backup fault data.

[0071] In this embodiment, the receiving ESC adds the verified fault data to a storage queue, aiming to provide a temporary buffer for fault data to be stored. The storage queue typically employs a first-in, first-out (FIFO) data structure, effectively decoupling the generation (verification successful) of fault data from the actual storage operation, thereby smoothing the data flow, handling instantaneous data spikes, and avoiding data loss due to busy storage media. This storage queue can be implemented based on the receiving ESC's internal random access memory (RAM), managed, for example, through a circular buffer, linked list, or array. When verified fault data is available, it is appended to the tail of the queue.

[0072] In this embodiment, the receiving ESC monitors the status of the local storage space to determine whether the storage space is free. This step is crucial to ensuring that data can be safely and efficiently written to the local storage medium. The local storage space can be a non-volatile memory such as electrically erasable programmable read-only memory (EEPROM) or flash memory. The receiving ESC can obtain the current status of the storage space by querying the status register of the storage controller or the storage medium, for example, determining whether there is an ongoing write / erase operation, or whether there is enough remaining space to accommodate new faulty data.

[0073] In this embodiment, when monitoring results show that the storage space is idle, the receiving ESC retrieves the verified fault data from the storage queue. This operation is a consumer-side behavior of the storage queue, ensuring that data write operations are only performed when preset conditions are met. Typically, the receiving ESC retrieves the first data to enter the queue from the head of the storage queue to maintain the order of data processing. Subsequently, the receiving ESC writes the retrieved verified fault data into the local storage space, thereby obtaining backup fault data. This step achieves persistent storage of fault data, ensuring that the fault data is retained even if the ESC loses power. The write operation may involve specific programming timings and protocols of the storage medium; for example, for flash memory, an erase operation may be required before programming and writing.

[0074] Based on this, the system receives status information from the local storage space updated by the electronic switch and records the storage information of the backup failure data. This step is crucial for subsequent failure data management and retrieval. The storage information may include metadata such as the starting address of the backup failure data, data length, storage timestamp, and data checksum. This information can be stored in a specific area of ​​the local storage medium, such as as part of the file system or a separate index table, so that the backup failure data can be accurately and efficiently located and read when needed, and the allocation of storage space can be maintained.

[0075] In this embodiment, through the above technical solution, the receiving power switch can effectively buffer the fault data that has passed verification, ensuring that data is not lost even if the local storage space is temporarily occupied or the arrival rate of fault data is uneven. By continuously monitoring the storage space status and only writing when idle, write failures caused by storage conflicts or insufficient resources are avoided, thereby improving the reliability and efficiency of fault data storage. At the same time, updating and recording storage information facilitates the subsequent retrieval and management of fault data, ensuring the integrity and traceability of the backup fault data.

[0076] In one feasible implementation, refer to Figure 9 Step S400 includes steps S410 to S430, wherein: In step S410, the external device sends a data read command to the target ESC via the CAN bus; Step S420: The target ESC receives the data read instruction and parses the data read instruction. In step S430, the target ESC accesses the local storage space based on the parsing results, searches for backup fault data, and sends the found backup fault data to the external device via the CAN bus.

[0077] In this embodiment, the external device can be a diagnostic tool or a host computer. It sends a data read command to the target ESC via the CAN bus. This command is carried in the form of a CAN message, which includes a specific CAN identifier (CAN ID) and a data field to indicate that this is a data read request. It may also contain a unique identifier for the target ESC to ensure that only the specified ESC responds to the request. The external device can construct a command message containing parameters such as request type and data range according to a preset communication protocol.

[0078] In this embodiment, the target ESC continuously monitors messages on the CAN bus. When a message is received, its internal CAN controller and processor work together to first check the CAN ID of the message to determine if it is a data read command for itself. If a match is found, the ESC will further parse the data segment of the message to extract the specific instruction content, such as a request to read all backup fault data, specific type of fault data, or fault data within a specific time period. This parsing process ensures that the ESC can accurately understand the intent of the external device.

[0079] In this embodiment, after successfully parsing the data read instruction, the target ESC will search for data in its local storage space (e.g., non-volatile memory) according to the conditions specified in the instruction. Once the backup fault data that meets the conditions is found, the target ESC will encapsulate it into a series of CAN messages. Considering the data length limit of CAN messages, if the amount of backup fault data is large, the ESC will adopt a packet transmission mechanism to divide the data into multiple small blocks, add a sequence number and checksum to each data packet, and send them one by one to the external device via the CAN bus. After receiving all the data packets, the external device will reassemble and verify them to restore the complete backup fault data.

[0080] In this embodiment, the external device can proactively and accurately initiate data read requests to the target ESC that stores backup fault data. The target ESC can accurately identify, parse, and respond to these requests, thereby effectively retrieving and transmitting the required backup fault data from its local storage space. This not only improves the efficiency and reliability of fault data acquisition but also simplifies fault diagnosis and analysis, enabling system maintenance personnel to easily obtain critical fault information and providing support for fault investigation and system optimization.

[0081] In one feasible implementation, the method further includes: before sending the fault data to the CAN bus, the fault ESC first saves the fault data to its own local storage space.

[0082] In this embodiment, local storage space typically refers to the non-volatile memory inside the faulty ESC, such as EEPROM (Electrically Erasable Programmable Read-Only Memory) or Flash memory. When the faulty ESC detects a fault and generates fault data, it immediately writes this data into its internal non-volatile memory. This storage operation typically employs a fast write mechanism to ensure that data is preserved as much as possible before the ESC completely fails. For example, strategies such as double-buffered write, circular storage, or event-triggered storage can be used to ensure data integrity and timeliness. The timing of this operation, "before sending the fault data to the CAN bus," emphasizes the priority of data saving operations. This means that before the faulty ESC prepares to broadcast the fault data externally via the CAN bus, it will prioritize writing the fault data into its local storage space. This sequence ensures that even if CAN bus communication is blocked due to a fault, or if the faulty ESC deteriorates further during transmission, a reliable copy of the fault data has already been obtained locally.

[0083] In this embodiment, before sending fault data to the CAN bus, the faulty ESC prioritizes saving it to its local storage space, enhancing the reliability and recoverability of the fault data. Even if the faulty ESC encounters communication failure, bus congestion, or further deterioration leading to complete failure when attempting to send data via the CAN bus, the critical fault data has already been backed up locally in real time. This avoids the risk of fault data loss due to external communication links or the faulty ESC's own momentary poor condition, providing a more comprehensive data foundation for subsequent fault diagnosis and analysis. When fault data needs to be retrieved, in addition to reading backup data from other receiving ESCs, fault data can also be directly recovered from its local storage space if the faulty ESC itself is accessible. This forms a multi-layered protection mechanism, improving the success rate of fault data retrieval and the overall robustness of the system.

[0084] In one feasible implementation, when multiple ESCs fail simultaneously, each faulty ESC competes for the fault transmission channel by locking messages. The ESC with the smaller ESC identifier value gains the fault transmission permission, while the ESC with the larger ESC identifier value locks its own fault transmission channel. Although the ESC with the larger ESC identifier value has locked its own fault transmission channel, its CAN bus receiving channel remains operational. Therefore, this ESC can still act as a receiving ESC, receiving and storing the fault data transmitted by the ESC that has gained fault transmission permission. Specifically, the faulty ESC with the larger ESC identifier value continuously monitors the communication on the CAN bus, normally receives the fault data messages transmitted by the faulty ESC with the smaller ESC identifier value, and performs buffering, CRC check processing, and local storage on the received fault data messages, thereby saving the fault data of the faulty ESC with the smaller ESC identifier value to its own storage space.

[0085] In one feasible implementation, a faulty ESC can still process CAN bus messages even if it malfunctions without affecting CAN bus communication. This faulty ESC can also act as a receiving ESC, receiving and storing fault data sent by other faulty ESCs, whether it has not yet sent its own fault data (i.e., is waiting or competing) or has completed sending its own fault data and sent an unlock message. In other words, fault data is mutually backed up among the ESCs; each ESC can act as both a sender and receiver of fault data from other ESCs. This fault node backup mechanism further improves the redundancy of fault data storage and the overall reliability of the system without increasing hardware costs.

[0086] In this embodiment, for example in a multi-rotor UAV application scenario, assuming the ESC identifiers are 1 to 8, with ESC 3 and ESC 5 malfunctioning simultaneously. ESC 3, with a smaller identifier value, wins the fault transmission permission in the competition and sends its fault data to the CAN bus. ESC 5, with a larger identifier value, has locked its own fault transmission channel, but its receiving channel is functioning normally. Therefore, ESC 5 can act as a receiving ESC, receiving the fault data sent by ESC 3 and performing buffering, verification, and storage. Simultaneously, ESCs 1, 2, 4, 6, 7, and 8, which are not malfunctioning, also act as receiving ESCs, receiving and saving the fault data of ESC 3. Subsequently, ESC 3 sends an unlock message, and ESC 5 unlocks its fault transmission channel and sends its own fault data. ESC 3 and the other ESCs again act as receiving ESCs, saving the fault data of ESC 5. This cycle continues until the fault data of all malfunctioning ESCs has been sent and saved in multiple ESCs.

[0087] In this embodiment, through the above technical solution, when multiple ESCs fail simultaneously, not only can the fault-free ESCs receive and save fault data, but ESCs that have failed but have not yet sent fault data or have completed sending fault data can also receive and save each other's fault data, realizing mutual backup between faulty nodes. This mechanism, without requiring additional hardware support, increases the redundancy of fault data storage as the number of ESCs increases. The more ESCs used on a single aircraft, the lower the risk of fault data loss, thereby greatly improving the data security and reliability of the entire ESC system.

[0088] In the embodiments of this application, the fault data storage method of the ESC broadcasts the fault data to the CAN bus through the faulty ESC and performs distributed backup storage by the receiving ESC. This effectively solves the technical problem that a single point of failure may lead to permanent data loss and can ensure that the fault data can still be reliably saved when the ESC is physically damaged, which is convenient for subsequent fault analysis.

[0089] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. All equivalent structural transformations made under the technical concept of this application using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the scope of patent protection of this application.

Claims

1. A method for storing fault data of an electronic speed controller (ESC), characterized in that, The method includes: When an ESC malfunctions, the faulty ESC generates fault data and sends the fault data to the CAN bus; the fault data includes the faulty ESC identifier, fault type, fault occurrence time, and operating parameters before the fault. The receiving ESC on the CAN bus receives the fault data and performs CRC verification on the received fault data to obtain the fault data that passes the verification. The receiving ESC is an ESC on the CAN bus that can receive and store fault data, except for the ESC that is currently transmitting fault data. This includes fault-free ESCs and ESCs that have experienced a fault but have not yet transmitted fault data. The fault data that passes the verification is added to the storage queue, and when the storage location is idle, it is retrieved from the storage queue and stored in the local storage space of the receiving ECH to obtain backup fault data; When fault data is needed, the backup fault data is read from any ESC that stores backup fault data via the CAN bus.

2. The method for storing ESC fault data as described in claim 1, characterized in that, When an ESC malfunctions, the steps of generating fault data and sending the fault data to the CAN bus include: When the ESC detects a fault in itself, the faulty ESC generates a lock message and sends the lock message to the CAN bus; After sending the lock message, the faulty ESC waits for a preset time while monitoring other lock messages on the CAN bus. The fault dispatcher performs fault transmission channel contention processing based on other monitored locking messages to determine the dispatcher that has the right to send fault messages; The fault-transmitting ESC, having obtained fault transmission permission, sends its fault data message to the CAN bus; After sending the fault data message, the faulty ESC generates an unlock message and sends the unlock message to the CAN bus.

3. The method for storing ESC fault data as described in claim 2, characterized in that, The fault dispatcher, based on other monitored locking messages, performs fault transmission channel contention processing to determine the dispatcher that obtains fault transmission permission. The steps include: The faulty ESC obtains its own ESC identifier and the ESC identifier contained in other monitored locking messages; The faulty ESC compares its own ESC identifier with the ESC identifiers in other monitored locking messages. When the comparison result shows that the faulty ESC identifier value is less than the ESC identifier value in other locked messages, the faulty ESC obtains the fault transmission permission. When the comparison result shows that the value of its own ESC identifier is not less than the value of the ESC identifier in other locking messages, the faulty ESC locks its own fault transmission channel.

4. The method for storing ESC fault data as described in claim 1, characterized in that, The steps of receiving fault data on the CAN bus and performing CRC check processing on the received fault data to obtain fault data that passes the check include: The receiving ESC receives messages from the CAN bus and performs type determination processing on the messages; When the message type determination result is a locked message, the receiving ESC performs fault transmission channel locking processing. When the message type determination result is a fault data message, the receiving ESC performs buffering processing on the fault data message to obtain buffered fault data; and the receiving ESC performs CRC check processing on the buffered fault data to obtain fault data that passes the check. When the message type determination result is an unlock message, the receiving ESC unlocks its own fault transmission channel.

5. The ESC fault data storage method as described in claim 4, characterized in that, When the message type determination result is a locked message, the steps for the receiving switch to perform fault transmission channel locking processing include: The receiving ESC determines whether it has sent a locking message; When the judgment result is that it has not sent a lock message, the receiving ESC directly locks its own fault transmission channel. When the judgment result is that it has sent a lock message, the receiving ESC compares its own ESC identifier with the ESC identifier in the received lock message. When the comparison result shows that the value of its own ESC identifier is greater than the value of the ESC identifier in the received lock message, the receiving ESC locks its own fault transmission channel; when the comparison result shows that the value of its own ESC identifier is not greater than the value of the ESC identifier in the received lock message, the receiving ESC keeps its own fault transmission channel unlocked.

6. The ESC fault data storage method as described in claim 4, characterized in that, When the message type determination result is a fault data message, the receiving switch performs buffering processing on the fault data message to obtain the buffered fault data, including the following steps: After receiving a fault data packet, the receiving ESC stores the fault data packet in the receiving buffer queue; The receiving ESC performs an integrity check on fault data packets in the receiving buffer queue to determine whether the fault data has been received completely. When the fault data is received completely, the receiver ESC will extract the complete fault data from the receive buffer queue to obtain the buffered fault data; when the fault data is not received completely, the receiver ESC will continue to wait to receive subsequent fault data packets.

7. The method for storing ESC fault data as described in claim 4, characterized in that, The steps of receiving the ESC to perform CRC verification on the buffered fault data to obtain fault data that passes the verification include: The receiving ESC extracts the CRC checksum from the cached fault data; The receiving ESC calculates the valid content of the cached fault data according to the CRC check algorithm to obtain the calculated CRC check code; The receiving ESC compares the extracted CRC checksum with the calculated CRC checksum. When the CRC checksums match, the receiving ESC marks the cached fault data as fault data that has passed the checksum verification; when the CRC checksums do not match, the receiving ESC discards the cached fault data.

8. The method for storing ESC fault data as described in claim 1, characterized in that, The steps of adding the verified fault data to the storage queue, and retrieving it from the storage queue and storing it in the local storage space of the receiving switch when the storage location is idle, to obtain backup fault data include: The receiving ESC adds the verified fault data to the storage queue; The system receives the status of the local storage space from the electronic speed controller to determine whether the storage space is free. When the storage space is idle, the receiving ESC retrieves the verified fault data from the storage queue; The receiving ESC writes the retrieved, verified fault data into the local storage space to obtain backup fault data; and the receiving ESC updates the status information of the local storage space and records the storage information of the backup fault data.

9. The method for storing ESC fault data as described in claim 1, characterized in that, When fault data needs to be obtained, the steps of reading the backup fault data from any ESC storing backup fault data via the CAN bus include: External devices send data read commands to the target ESC via the CAN bus; The target ESC receives the data read instruction and parses and processes the data read instruction; The target ESC accesses the local storage space based on the parsing results, searches for backup fault data, and sends the found backup fault data to external devices via the CAN bus.

10. The method for storing ESC fault data as described in claim 1, characterized in that, The method further includes: Before sending the fault data to the CAN bus, the faulty ESC first saves the fault data to its own local storage space.

Images