CN118250193A

CN118250193A - Fault detection system and method

Info

Publication number: CN118250193A
Application number: CN202311775841.5A
Authority: CN
Inventors: M·P·德尔哈克
Original assignee: Analog Devices Inc
Current assignee: Analog Devices Inc
Priority date: 2022-12-23
Filing date: 2023-12-22
Publication date: 2024-06-25

Abstract

The present disclosure relates to fault detection systems and methods. The fault monitoring system and method presented herein performs the steps comprising: in response to the host device receiving the valid command, an acknowledgement response is transmitted to the host device if no fault condition exists in the circuit. Whether a fault condition exists in the circuit may be determined by monitoring the circuit. If a fault condition is found, an error acknowledgment response different from the acknowledgment response may be transmitted to the host. Conversely, if an invalid command is received from the host, no acknowledgement response and no error acknowledgement response are transmitted to reduce unnecessary communications.

Description

Fault detection system and method

Cross-reference to related patent applications

The present application is entitled "fault monitoring system and method" filed on day 2022, month 12 and 23 and listed as priority to co-pending and commonly assigned U.S. provisional patent application No. 63/435,206 by inventor MARK PATRICK DERHAKE in accordance with 35u.s.c. ≡119 (e), the entire contents of which are incorporated herein by reference. Each reference mentioned in this patent document is incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates generally to systems and methods for fault monitoring applications, such as automotive lighting applications. More specifically, the present disclosure relates to systems and methods for improving bandwidth in serial communication applications.

Background

To reduce circuit complexity and cost, the use of universal asynchronous receiver/transmitter (UART) in Controller Area Network (CAN) communications in applications such as automotive lighting applications has become commonplace. Typically, a host microcontroller unit (MCU) implemented on the same board as the plurality of slaves communicates directly with the slaves, and the slaves in turn control the plurality of LEDs. The slave devices typically have fault monitoring circuitry that alerts the host MCU, for example, to initiate certain actions in the event a fault is detected. In such conventional approaches, communication between the MCU and the slave devices involves the MCU transmitting instructions to each slave device individually to constantly poll the slave device's fault registers. The fault register typically contains all possible fault conditions that the fault monitoring circuit may detect. However, such an approach increases the number of commands that the MCU must send, thereby reducing the available bandwidth available for communication. What is needed, therefore, are systems and methods that mitigate the shortcomings of existing designs.

Drawings

Examples of which will be described with reference to embodiments of the invention are illustrated in the accompanying drawings. These figures are intended to be illustrative, not limiting. While the invention will be generally described in the context of these embodiments, it will be understood that it is not intended to limit the scope of the invention to these particular embodiments. The items in the drawing are not to scale.

Fig. 1 illustrates a UART in an exemplary CAN communication system according to various embodiments of the present disclosure.

Fig. 2A illustrates a generic format of a write packet and a corresponding acknowledgement packet.

Fig. 2B shows a generic format of a read packet and a corresponding acknowledgement packet.

Fig. 3 shows an example of a conventional acknowledgement frame.

Fig. 4 illustrates an example of an error acknowledgement frame in accordance with various embodiments of the present disclosure.

Fig. 5 is a flow chart of an exemplary fault communication process for improving throughput in accordance with various embodiments of the present disclosure.

Detailed Description

For purposes of explanation, specific details are set forth in the following description in order to provide an understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these details. Furthermore, those skilled in the art will appreciate that the embodiments of the invention described below can be implemented in numerous ways, such as a process, an apparatus, a system, a device, or a method on a tangible computer readable medium.

The components or modules shown in the figures are illustrative of exemplary embodiments of the invention and are meant to avoid obscuring the invention. It should also be understood that throughout the discussion, components may be described as separate functional units, which may include sub-units, but those skilled in the art will recognize that various components or portions thereof may be separated into separate components or may be integrated together, including within a single system or component. It should be noted that the functions or operations discussed herein may be implemented as components. The components may be implemented in software, hardware, or a combination thereof.

Furthermore, connections between components or systems in the figures are not intended to be limited to direct connections. Rather, data between these components may be modified, reformatted, or otherwise changed by intermediate components. In addition, additional or fewer connections may be used. It should also be noted that the terms "coupled," "connected," or "communicatively coupled" are to be understood as including direct connections, indirect coupling via one or more intermediary devices, and wireless connections.

Reference in the specification to "one embodiment," "a preferred embodiment," "an embodiment," or "an embodiment" means that a particular feature, structure, characteristic, or function described in connection with the embodiment is included in at least one embodiment of the invention and may be included in more than one embodiment. Furthermore, the appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment.

The use of certain terminology in various places throughout the specification is for the purpose of description and should not be taken as limiting. The service, function or resource is not limited to a single service, function or resource; the use of these terms may refer to a related set of services, functions, or resources, which may be distributed or aggregated.

The terms "include" and "comprising" are to be construed as open-ended terms, and any list below is an example and is not meant to be limiting of the listed items. Any headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. Each reference mentioned in this patent document is incorporated herein by reference in its entirety.

Furthermore, it should be noted that the embodiments described herein are built in the context of UART in CAN communication systems, but those skilled in the art will recognize that the teachings of the present disclosure are not limited to such applications and may equally be used in other contexts.

In this document, the terms "acknowledgement", "acknowledgement frame" and "acknowledgement response" are used interchangeably. Similarly, the terms "acknowledgement frame", "error acknowledgement frame" and "error acknowledgement response" are used interchangeably. Further, the terms "microcontroller unit" and "microcontroller" are used interchangeably. The terms "normal" and "conventional" refer to conventional methods as recognized by one having ordinary skill in the art.

Fig. 1 illustrates a UART in an exemplary CAN communication system according to various embodiments of the present disclosure. The system 100 includes three different boards 102-106, each including a CAN transceiver 112-116. In an embodiment, board 102 may include a host device, which is implemented as a host MCU in FIG. 1. Conversely, plate 104 includes slaves 130, 132, and plate 106 includes slave 134. The slave devices 130-134 may perform any number of tasks according to commands received from the host MCU 120.

As mentioned in the background, in conventional applications, the slave devices equipped with fault monitoring circuitry are implemented on the same board as the master MCU. Typical faults or errors that the fault monitoring circuitry may detect in the lighting application and communicate to the host MCU include electrical shorts of LEDs on terminals or grounded; an open condition in a circuit such as a PCB trace of an LED; exceeding the temperature limit; an address error; communication errors; and many other errors.

Where the MCU communicates with each slave device individually, sends commands to constantly poll the slave device's failure registers, and the conventional approach of receiving failure information from each slave device unnecessarily increases bandwidth overhead and reduces available bandwidth. For example, whenever a host MCU sends a valid command to any of the slave devices, e.g., in a write packet, as shown in fig. 2A, or in a read packet, as shown in fig. 2B, the slave device will typically respond with a corresponding data frame to confirm that the slave device successfully received the command sent by the host MCU. Fig. 3 shows an example of a conventional acknowledgement frame containing eight data bits between a start bit, a parity bit (0 xC 3) and a stop bit. In order to reduce the traffic between the MCU and a single slave device and increase the available bandwidth, it is therefore desirable to have a system and method that allows for a reduction in the total number of commands that the MCU must transmit to each device during normal operation.

Returning to FIG. 1, various embodiments herein utilize a host MCU 120 that can remotely control any number of slave devices (e.g., 130-134) without the need for a local on-board MCU or clock. Advantageously, this allows a single MCU (e.g., 120) to control any number of boards, e.g., multiple headlamps, without having to implement one dedicated MCU for each board, i.e., each headlamp. Further, to help alleviate the need to actively poll slave devices 130-134 for faults by communicating exclusively with a fault register (not shown in FIG. 1), various embodiments herein utilize a novel acknowledgement frame that may be used as an error acknowledgement frame. In embodiments, such error acknowledgement frames may include any number of bits, for example, between at least one start bit and one stop bit. The error acknowledgment frame may be unique and significantly different from the traditional acknowledgment frame in the following respects: in operation, in response to a successful command sent from the host MCU 120 to any of the slave devices 130-134 and any number of faults in the circuitry, a different frame may be sent instead of the legacy acknowledgement frame.

It should be noted that error acknowledgement responses according to various embodiments herein may further include any number of unique responses, in addition to including, for example, a general purpose error message, representing any number or combination of faults that may have been detected by any of the slave devices 130-134.

Fig. 4 illustrates an example of an error acknowledgement frame (0 x 3C) in accordance with various embodiments of the present disclosure. As depicted, the error acknowledgment frame 400 is uniquely different from a conventional acknowledgment frame, as shown in fig. 3. It should be appreciated that in an embodiment, if there is no error, the error acknowledgment frame 400 may be a mirror image of a conventional acknowledgment frame. Further, in an embodiment, if an error is detected in UART communication, neither a legacy acknowledgement frame nor an error acknowledgement frame is sent.

Advantageously, the error acknowledge frame 400 may be used to constantly monitor the slave device for faults in circuit behavior without the MCU having to send additional commands to poll the slave device's fault registers.

In an embodiment, in response to receiving a valid command, e.g., from an MCU, a single slave device may respond with a legacy acknowledgement or a new type of error acknowledgement. Conversely, in the event that an invalid command is received by the slave device, the slave device may respond by not returning an acknowledgement.

Advantageously, the combination of these responses allows the host MCU to achieve near real-time monitoring of any number of slave devices. By comparison, assuming there are 11 slaves receiving the command, each device is periodically polled for error status using conventional methods, four frames (sync, device ID, address and CRC) must be sent to each device to request their status. In turn, each device will respond with a normal acknowledgment frame and two additional frames of data containing error registers. As a result, 847 bits are transmitted and received in total ((11 bits per frame) ×4 command frames+3 response frames) ×11 devices). Further, assume that communication is at 1MBPS (one million bits per second), which means an extra time of 847 microseconds for viewing the error status register. Further, the problem is more serious at lower communication rates. Instead, the systems and methods herein reduce or eliminate this additional time altogether because the information has been transferred during the previous write command.

Fig. 5 is a flow chart of an exemplary fault communication process for improving throughput in accordance with various embodiments of the present disclosure. In an embodiment, process 500 may begin at step 505 when a device, such as a board, receives a command from a host device. At step 510, it may be determined whether the received command is a valid command, and if so, the process 500 may proceed to step 515 to determine whether the board includes a fault, such as a short circuit condition, for example. Otherwise, once the received command is determined to be invalid, the process 500 may pass to step 530 to disable the board from responding to the host with a confirmation, and revert to receiving the next comment from the host at step 505. In an embodiment, if it is determined at step 515 that the board does not include a fault, the board may transmit an acknowledgement to the host and revert to step 505 to receive the next comment from the host.

Conversely, if it is determined that the board does not include a failure, the board may transmit an error acknowledgement to the host at step 525 before reverting to receiving the next comment from the host at step 505. Those skilled in the art will recognize that: (1) certain steps may optionally be performed; (2) The steps may not be limited to the specific order set forth herein; (3) certain steps may be performed in a different order; and (4) certain steps may be performed simultaneously.

In general, the systems and methods herein implement a novel error acknowledgement frame that alerts a host device to a failure to improve communication throughput and allows near real-time monitoring of the failure, thereby eliminating the need to directly request failure information from each slave device.

Aspects of the invention may be encoded on one or more non-transitory computer-readable media having instructions for causing one or more processors or processing units to perform steps. It should be noted that the one or more non-transitory computer-readable media should include volatile and non-volatile memory. It should be noted that alternative embodiments are possible, including hardware embodiments or software/hardware embodiments. The hardware-implemented functions may be implemented using ASICs, programmable arrays, digital signal processing circuitry, and the like. Accordingly, the term "means" in any claim is intended to encompass both software implementations and hardware implementations. Similarly, as used herein, the term "computer readable medium" includes software and/or hardware having a program of instructions embodied thereon, or a combination thereof. In view of these alternative embodiments, it should be understood that the figures and accompanying description provide those skilled in the art with functional information needed to write program code (i.e., software) and/or fabricate circuits (i.e., hardware) to perform the required processing.

It should be noted that embodiments of the present invention may further relate to computer products with a non-transitory tangible computer-readable medium that have computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and configured for the purposes of the present invention, or they may be of the kind well known or available to those having skill in the relevant arts. Examples of tangible computer readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM and holographic devices; a magneto-optical medium; and hardware devices that are specially configured to store or store and perform program code, such as Application Specific Integrated Circuits (ASICs), programmable Logic Devices (PLDs), flash memory devices, and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher level code that are executed by a computer using an interpreter. Embodiments of the invention may be implemented, in whole or in part, as machine-executable instructions, which may be located in program modules that are executed by a processing device. Examples of program modules include libraries, programs, routines, objects, components, and data structures. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Those skilled in the art will recognize that no computing system or programming language is critical to the practice of the invention. Those skilled in the art will appreciate that the foregoing examples and embodiments are illustrative of the scope of the present disclosure and are not limiting of the scope of the present invention. All permutations, enhancements, equivalents, combinations and modifications thereto that will become apparent to those of skill in the art upon a reading of the specification and a study of the drawings are intended to be included within the true spirit and scope of the present disclosure. It should also be noted that the elements of any claim may be arranged in a variety of ways, including having a variety of dependencies, configurations, and combinations.

Claims

1. A method of fault communication for improving throughput, the method comprising:

In response to receiving a valid command from the first device, performing steps comprising:

Transmitting an acknowledgement response to the first device in response to the absence of a fault condition in the circuit; and

Transmitting an error acknowledgement response to the first device in response to determining that a fault condition exists, the error acknowledgement response being different from the acknowledgement response; and

In response to receiving an invalidation command from the first device, neither the acknowledgement response nor the error acknowledgement response is transmitted to the first device.

2. The method of claim 1, wherein the first device is a host device that controls one or more devices.

3. The method as recited in claim 2, further comprising: in response to determining that the fault condition exists in the circuit, a fault is stored in a register of a second device of the one or more devices.

4. The method of claim 2, wherein the invalidate command is representative of a communication error in a Universal Asynchronous Receiver Transmitter (UART) communication between the first device and at least one of the one or more devices.

5. The method as recited in claim 1, further comprising: a monitoring circuit is used to determine whether the fault condition exists in the circuit.

6. The method of claim 5, wherein the first device does not send a command to poll the monitoring circuitry to determine whether the fault condition exists.

7. The method of claim 1, wherein the active commands comprise commands to control one or more lighting functions in an automotive lighting application.

8. The method of claim 1, wherein the error acknowledgement response is transmitted within an acknowledgement frame comprising a plurality of bits between at least one start bit and one stop bit.

9. A fault detection circuit, comprising:

a monitoring circuit coupled to the circuit, the monitoring circuit determining whether a fault condition exists in the circuit; and

A fault register coupled to the monitoring circuit, the fault detection circuit, in response to receiving a valid command from a host device, performing steps comprising:

Transmitting an acknowledgement response to the host device in response to the absence of a fault condition in the circuit; and

Transmitting an error acknowledgement response to the host device in response to determining that the fault condition exists, the error acknowledgement response being different from the acknowledgement response; and

In response to receiving an invalidation command from the host device, neither the acknowledgement response nor the error acknowledgement response is transmitted to the host device to reduce unnecessary communications.

10. The fault detection circuit of claim 9, wherein the fault register is not periodically polled to determine whether the fault condition exists.

11. The fault detection circuit of claim 9, wherein the invalid command represents a communication error in a Universal Asynchronous Receiver Transmitter (UART) communication.

12. The fault detection circuit of claim 9, wherein the error acknowledgement response comprises an acknowledgement frame comprising a plurality of bits between at least one start bit and one stop bit.

13. The fault detection circuit of claim 9, wherein the error confirmation response includes information identifying a particular fault condition detected by the monitoring circuit.

14. The fault detection circuit of claim 9, wherein the valid commands comprise commands to control one or more lighting functions in an automotive lighting application.

15. A fault detection system, comprising:

A circuit;

A host device coupled to the circuit;

A fault detection circuit coupled to the host device, the fault detection circuit comprising:

a fault register; and

A monitoring circuit that determines whether a fault condition exists in the circuit, the fault detection circuit performing steps comprising, in response to receiving a valid command from the host device:

transmitting an acknowledgement response to the host device in response to the absence of a fault condition in the circuit;

In response to receiving an invalidation command from the host device, neither the acknowledgement response nor the error acknowledgement response is transmitted to the host device.

16. The fault detection system of claim 15, wherein the fault register is not periodically polled to determine whether the fault condition exists.

17. The fault detection system of claim 15, wherein the host device controls one or more devices.

18. The fault detection system of claim 15, wherein the invalid command represents a communication error in a Universal Asynchronous Receiver Transmitter (UART) communication.

19. The fault detection system of claim 15, wherein the error confirmation response includes information identifying a particular fault condition detected by the monitoring circuit.

20. The fault detection system of claim 15, wherein the valid commands comprise commands to control one or more lighting functions in an automotive lighting application.