CAN transceiver

Abstract

A transceiver for transmitting and receiving data from a controller area network (CAN) bus is disclosed. The transceiver includes a microcontroller port, a transmitter, and a receiver. The transceiver is configured to receive a data frame from a microcontroller via the microcontroller port and determine whether the microcontroller is authorized to transmit the data frame or a portion of the data frame based on a message identifier in the data frame and a result of an arbitration process. If the microcontroller is not authorized to transmit the data, the transceiver is configured to invalidate the data frame and disconnect the microcontroller from the CAN bus for a predetermined period of time.

Description

Technical Field

[0001] This invention relates to CAN transceivers. Background Technology

[0002] Controller Area Network (CAN bus) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other's applications without a master. CAN is a message-based protocol that uses two wires to enable multiple devices to communicate with each other and is used in many types of applications, including automotive applications. For each message, the data in the packet is transmitted sequentially, but this means that if more than one device transmits messages simultaneously, only the highest priority message can continue, while other devices stop transmitting their messages. This process, called "arbitration," is used by all transmitting devices, and the device attempting to send the highest priority message wins the arbitration. Transmitted packets are received by all devices, including the transmitting device receiving its own message. However, even after losing the arbitration, a malicious device may attempt to hijack bus control.

[0003] CAN is a two-wire, half-duplex, high-speed serial network commonly used to provide communication between network nodes without the need for a microcontroller. A CAN transceiver interfaces between the CAN protocol controller and the physical wires of the CAN bus line. The microcontroller uses the transceiver to send and receive data on the CAN bus. Typical transceivers typically provide communication compliant with the ISO 11898 standard via the CAN bus without requiring careful verification of the data content. Summary of the Invention

[0004] This summary is intended to introduce, in a simplified form, a series of concepts further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0005] In one embodiment, a transceiver for sending and receiving data from a Controller Area Network (CAN) bus is disclosed. The transceiver includes a microcontroller port, a transmitter, and a receiver. The transceiver is configured to receive data frames from a microcontroller via the microcontroller port and determine whether the microcontroller is authorized to transmit the data frame based on a message identifier in the data frame. If the microcontroller is not authorized to transmit the data frame, the transceiver is configured to invalidate the data frame and disconnect the microcontroller from the CAN bus for a predetermined period of time.

[0006] In another embodiment, a method for preventing a node from interrupting communication on a Controller Area Network (CAN) bus is disclosed. The method includes: receiving a data frame from a node; determining, based on a message identifier in the data frame, whether the node is authorized to transmit the data frame; and if the node is not authorized to transmit the data frame, invalidating the data frame and disconnecting the microcontroller from the CAN bus for a predetermined period of time.

[0007] In some examples, the failure of the data frame includes sending a failure signal onto the CAN bus. The transceiver is further configured to verify during the transmission of the erroneous frame whether the microcontroller has lost or won arbitration. The transceiver is also configured to generate a failure signal and send it onto the CAN bus to fail the data frame if the microcontroller sends a portion of the data frame after losing the arbitration. The transceiver may also be configured to send a dominant bit onto the CAN bus to fail the data frame if the controller sends it after losing the arbitration. The transceiver is further configured to verify whether the microcontroller is authorized to send the message identifier embodied in the data frame if the controller sends the data frame after winning the arbitration.

[0008] In some embodiments, the transmitter includes an enable port for enabling or disabling the transmitter, and the transceiver is configured to generate an enable / disable signal based on the detection of an unauthorized message identifier on the transmission line connected between the microcontroller port receiving input from the microcontroller and the transmitter. The transceiver may include a transmission line switch in the transmission line between the microcontroller port receiving data from the microcontroller and the transmitter, and the transceiver may be configured to disconnect the transmission line switch based on the detection of an unauthorized message identifier on the transmission line.

[0009] In some examples, the generation of the failure signal (in some examples, the failure signal may be a CAN error message) includes verifying whether the data frame received from the microcontroller is free of encoding errors. The transceiver can be configured to allow the microcontroller to send an acknowledgment message. If the data frame sent after the microcontroller has lost arbitration includes a partial error message, the transceiver is configured to complete the partial error message and send the data frame onto the CAN bus.

[0010] In some examples, the transceiver may include a receiver line for connecting the receiver to the microcontroller port, wherein the receiver line includes a receiver line switch for enabling or disabling the receiver line. The transceiver may be configured to disable the receiver line when a predetermined message identifier is detected in a received message received from the CAN bus via the receiver. The transceiver may be configured to generate a fail signal when a dominant bit is detected on a transmission line connecting the transmitter and the microcontroller via the microcontroller port. Attached Figure Description

[0011] To gain a more detailed understanding of the above-described features of the invention, a more specific description of the invention, which has been briefly summarized above, can be made by referring to embodiments, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings illustrate only typical embodiments of the invention and should not be considered as limiting the scope of the invention, as other equally effective embodiments are permissible. The advantages of the claimed subject matter will become apparent to those skilled in the art upon reading this description taken in conjunction with the accompanying drawings, in which the same reference numerals are used to refer to the same elements, and in the drawings:

[0012] Figure 1 Describe a Controller Area Network (CAN) bus with terminating end resistors and capacitors;

[0013] Figure 2 Describe the CAN bus communication protocol, showing the representation of "0" and "1" based on the differential voltage at CANH and CANL;

[0014] Figure 3 A schematic diagram of a secure transceiver according to one or more embodiments of the present disclosure is shown; and

[0015] Figure 4 A flowchart illustrating secure CAN data transmission according to one or more embodiments of the present disclosure is shown.

[0016] It should be noted that the figures are not necessarily drawn to scale. Not all components in the secure transceiver are shown. Components omitted are known to those skilled in the art. Detailed Implementation

[0017] Many well-known manufacturing steps, components, and connectors have been omitted or not described in detail in order to avoid obscuring this disclosure.

[0018] It will be readily understood that the components of the embodiments generally described herein and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the more detailed descriptions of the various embodiments illustrated below are not intended to limit the scope of this disclosure, but merely to illustrate various embodiments. While various aspects of the embodiments are presented in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0019] The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be regarded in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims, and not by a detailed description thereof. All variations falling within the equivalent meaning and scope of the claims are covered by the claims.

[0020] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable through the invention should be included in or in any single embodiment of the invention. In fact, language relating to features and advantages should be understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the invention. Therefore, discussions of features and advantages, as well as similar language throughout this specification, may refer to, but do not necessarily refer to the same embodiment.

[0021] Furthermore, the features, advantages, and characteristics described herein can be combined in one or more embodiments in any suitable manner. In view of the description herein, those skilled in the art will recognize that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages that may not be present in all embodiments of the invention can be identified in certain embodiments.

[0022] Throughout this specification, references to "an embodiment," "an embodiment," "an example," or similar language mean that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the invention. Therefore, the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, refer to the same embodiment.

[0023] Controller Area Network (CAN) is a peer-to-peer network. This means there is no master device that controls when each node has access to read and write data on the CAN bus. When a CAN node is ready to transmit data, it checks if the CAN bus is idle and then simply writes a CAN frame to the network. The transmitted CAN frame does not contain the address of the transmitting node or any intended receiving node. However, a unique arbitration ID is contained in the data frame throughout the network. All nodes on the CAN network receive every CAN frame transmitted by any node, and each CAN node on the network decides whether to accept the frame for further processing based on the message or arbitration identifier of the transmitted frame.

[0024] If multiple nodes attempt to transmit messages to the CAN bus simultaneously, the node with the highest priority (the lowest value of the message or the arbitration identifier) ​​will gain bus access. Lower priority nodes (or messages) must wait until the bus becomes available before attempting to transmit again.

[0025] CAN nodes (e.g., ECUs) use transceivers to interface with the CAN bus. Transceivers include Rx and Tx ports to enable communication with other CAN nodes via the CAN bus 100. Transceivers typically provide a simple interface for mode control of devices / microcontrollers within the network. A typical standard transceiver uses a maximum of two dedicated mode control pins, meaning that there are usually no more than four different operating states.

[0026] The CAN protocol specifies the structure of a CAN frame. A CAN frame includes:

[0027] 1. SOF (Start of Frame) bit - Indicates the start of a message with a dominant (logic 0) bit.

[0028] 2. Message or Arbitration ID - Identifies the message and indicates its priority. Frames have two formats - a standard using an 11-bit arbitration ID, and an extended one using a 29-bit arbitration ID.

[0029] 3. IDE (Identifier Extension) bit - allows for differences between standard frames and extended frames.

[0030] 4. RTR (Remote Transmission Request) bit - Used to distinguish between remote frames and data frames. A dominant (logic 0) RTR bit indicates a data frame. A recessive (logic 1) RTR bit indicates a remote frame.

[0031] 5. DLC (Data Length Code) - Indicates the number of bytes contained in a data field.

[0032] 6. Data Fields - Contains 0 to 8 bytes of data.

[0033] 7. CRC (Cyclic Redundancy Check) - Contains a 15-bit cyclic redundancy check code and an implicit separator bit. The CRC field is used for error detection.

[0034] 8. ACK (Acknowledgement) Gap - Any CAN controller that correctly receives a message will send an ACK bit at the end of the message. The transmitting node checks for the presence of an ACK bit on the bus, and if no acknowledgement is detected, it retryes the transmission.

[0035] 9. CAN Signals - These are the data segments contained within the CAN frame data field. CAN signals can also be referred to as channels. Because the data field in classic CAN can contain a maximum of 8 bytes of data, while in CAN FD it can contain a maximum of 64 bytes of data.

[0036] Figure 1 A Controller Area Network (CAN) bus 100 is depicted. The CAN bus 100 includes termination resistors for suppressing wave reflections. In some embodiments, a capacitor 108 may also be used at the termination end. The CAN bus 100 includes a twisted pair 106. The twisted pair 106 includes CANH wires and CANL wires. The CAN bus 100 may include multiple communication microcontrollers or electronic control units (ECUs) 104-1-104-N coupled to the twisted pair via multiple secure transceivers 110-1...110-N. The capacitor 108 is typically 4.7 nF. The value of the capacitor 108 can be increased to approximately 100 nF. By increasing the value of the capacitor 108, the signal voltage at CANL or CANH is improved during intermittent open circuits. In one example, the resistors coupled to the capacitor 108 are typically each 60 ohms (total resistance of 120 ohms at each end).

[0037] As shown in the figure, communication nodes (ECUs) 104-1...104-N are connected via unshielded twisted-pair cable 106. Termination is performed at the leftmost and rightmost edges of the CAN bus 100. There are two options: using a single resistor as shown on the left side of the CAN bus 100, or via two resistors and capacitor 108, referred to as "split termination," as shown on the right side of the CAN bus 100. The latter method is generally used because it provides additional low-pass filtering to improve EMC performance.

[0038] like Figure 2 As shown, during normal operation (when no errors are present), the CAN bus 100 uses signals to indicate that CANH and CANL are driven, causing differential voltages to be generated (to transmit a dominant signal) or no differential signal to be generated (to transmit a recessive bit). In some implementations, for a dominant bit (“0”), the voltage at CANL is approximately 1.5V and the voltage at CANH is 3.5V, and V diffThis represents the difference between the voltage at CANH and the voltage at CANL. In some cases, Vdiff > 0.9V can be considered a dominant bit, and Vdiff < 0.5V can be considered a recessive bit.

[0039] When the CAN bus 100 is idle (e.g., in a recessive state for a period of time), the communication nodes on the CAN bus 100 that wish to send data on the CAN bus (e.g., ECU 104-1…104-N) send a dominant SOF bit to indicate that the node wishes to send a data frame. Next, each node sends a message identifier. It should be noted that the nodes are configured such that no two nodes can send data frames including the same message identifier. The CAN protocol provides an 11-bit message identifier. In another version of the CAN protocol, the message identifier is specified as consisting of 29 bits. The relative priority of message identifiers is characterized by their values. Lower-valued message identifiers have higher priority. For example, a message identifier with the value 11001000111 (0x647) will have a higher priority than a message identifier with the value 11011111111 (0x6FF).

[0040] If ECU 104-1 and ECU 104-N simultaneously send the SOF bit and then begin transmitting message identifiers 11001000111 and 11011111111 respectively on the fourth bit, ECU 104-1 will win the arbitration because it will send a dominant bit that overwrites the recessive bit sent by ECU 104-N. ECU 104-1 will read the dominant bit after sending it on CAN bus 100 and will continue sending other data bits, while ECU 104-N will read the dominant bit after sending the recessive bit (e.g., the fourth most significant bit in the message identifier example above), and will assume that it has lost the arbitration and will stop sending other data bits on CAN bus 100, waiting for CAN bus 100 to become idle again before attempting to send a message. Meanwhile, the arbitration process will restart.

[0041] However, the process described above only works if ECU 104-N accepts the CAN protocol. If ECU 104-N is a malicious component maliciously programmed to interrupt data transmission on CAN bus 100, ECU 104-N can still overwrite the last bit sent by ECU 104-1 on CAN bus 100 even after losing arbitration. This can be done during the data phase of CAN frame transmission (e.g., during the transmission of data fields) to replace the valid data being transmitted with malicious data. For example, when ECU 104-N detects that ECU 104-1 has sent a recessive bit, ECU 104-N can send a dominant bit on CAN bus 100 to overwrite the recessive bit sent by ECU 104-1. Because the dominant bit overwrites the recessive bit on CAN bus 100, the data sent by ECU 104-1 will no longer be valid data. ECU 104-N can continue to repeat this malicious operation to cause data communication on CAN bus 100 to fail. This failure could, for example, pose a dangerous situation to the vehicle's occupant. If ECU104-1 is transmitting anti-lock braking data while the vehicle is skidding on an icy road, a communication failure caused by malicious action of ECU 104-N could pose a serious risk of injury.

[0042] Again assuming that ECU 104-N is a malicious ECU, ECU 104-N can continue to tamper with the data of high-priority messages by preventing other ECUs (e.g., ECU 104-1) from sending data on CAN bus 100, thereby virtually manipulating CAN bus 100.

[0043] Figure 3 Transceiver 120 is shown. It should be noted that many components of transceiver 120 have been omitted to avoid obscuring this disclosure. Transceiver 120 may be replaced with... Figure 1 Transceiver 110-N in the middle (and of course, any other transceiver on CAN bus 100) to enable Figure 1 The CAN bus 100 shown becomes a secure CAN bus. With transceiver 120 monitoring ECU 104-N, after the first attempt, ECU 104-N will no longer be able to maliciously interrupt data communication on CAN bus 100.

[0044] Transceiver 120 includes a transmit (TX) port 134 and a receive (RX) port 136. Transceiver 120 includes a microcontroller port 122 for sending / receiving data from a microcontroller or ECU. Transceiver 120 also includes a CAN bus port 138 for sending data to / receiving data from the CAN bus 100. Data received from the CAN bus 100 is transferred to the microcontroller so that the microprocessor can functionally process the data. Similarly, when data is received from the microprocessor, the received data is transferred to the CAN bus 100. TX 134 converts data received from the microprocessor into CAN-compliant signals.

[0045] Transceiver 120 also includes a protocol decoder 128. Protocol decoder 128 may be coupled to an on-chip clock source 126 that provides a synchronization clock. A bit timing module 124 may be included to initialize protocol decoder 128. Bit timing module 124 may also track the current bit position in the data frame as data frames are processed by protocol decoder 128. Protocol decoder 128 includes a TXD traffic detection module 130 and an RXD traffic detection module 132. TXD traffic detection module 130 monitors the TXD line coupled to microcontroller port 122, and RXD traffic detection module 132 monitors the RXD line coupled to microcontroller port 122. A violation detector 144 is included to identify any rule violations in data received or transmitted through microcontroller port 122. Validation rules may be stored in memory (not shown) within the protocol decoder. In one example, validation rules are stored in a tamper-proof manner, making them resistant to malicious alteration. In some examples, protocol decoder 128 may also include a processor (not shown). In other examples, protocol decoder 128 may be implemented solely in hardware.

[0046] In some examples, an RX switch 140 may be included to enable or disable the RXD line, and a TX switch 142 may be included to enable or disable the TXD line. In some embodiments, the RX switch 140 is optional. In some embodiments, the RX switch 140 and the TX switch 142 may be controlled independently. In some other examples, the TX 134 includes an EN input to enable or disable the TX 134. In some examples, if the TX 134 includes an EN input, the TX switch 142 may not be included. In some examples, different control signals may drive the RX switch 140 based on monitoring of the RXD line.

[0047] Protocol decoder 128 monitors whether the microcontroller connected to microcontroller port 122 has won or lost arbitration. If a CAN frame is tampered with by a malicious microcontroller (or host or ECU), the remote node on CAN bus 100 will stop sending additional data frames due to a bit error. Normally, the remote node will send the erroneous frame when the first 16 bits are present. For the next 16 bits, the remote node will accept the error and will not send the erroneous frame, stopping transmission. This event may provide a malicious microcontroller coupled to microcontroller port 122 with sixteen opportunities to send the remainder of the data frame containing malicious data.

[0048] If the microcontroller has lost the arbitration, there should be no traffic on TXD except for a possible error frame or ACK received as an acknowledgment of the CAN frame. The violation detector 144 can disable TX 134, preventing a malicious microcontroller from sending data to manipulate communication on the CAN bus 100. In another example, the violation detector 144 can disconnect TX switch 142 after the microcontroller sends an ACK or error frame. In some embodiments, TX switch 142 or the EN signal can be activated only if the microcontroller attempts to send data other than an ACK or error frame. In some examples, if TX switch 142 is disconnected or TX 134 is disabled, the TXD line remains disabled for a predetermined period to prevent the microcontroller from further interrupting communication.

[0049] If TX 134 determines that the microcontroller coupled to microcontroller port 122 has lost arbitration and is still attempting to send dominant bits, protocol decoder 128 begins counting the number of bits being sent. In some examples, the counting may include checking the width of the dominant bits sent by the microcontroller. If the microcontroller continues to send more bits, it may be sending a legitimate error message (6 bits or longer), allowing such messages to reach CAN bus 100. However, if the microcontroller stops sending more dominant bits, protocol decoder 128 may send the remaining bits to indicate an error condition. If the microcontroller sends more than one error message within a preselected time interval, protocol decoder 128 may disable the TXD line or TX134 for the preselected time period to prevent the microcontroller from launching a denial-of-service attack. In some examples, if protocol decoder 128 detects that the microcontroller coupled to microcontroller port 122 is sending a message identifier that the microcontroller is not authorized to send, protocol decoder 128 may disable the TXD line or TX134. Similarly, in some instances, if the protocol decoder 128 detects a message identifier that the microcontroller is not authorized to receive, the protocol decoder 128 can invalidate the received message to prevent the microcontroller from reading the message.

[0050] Typically, a microcontroller coupled to microcontroller port 122 can read data transmitted by a remote node that has won arbitration on CAN bus 100. The microcontroller can begin sending data bits onto CAN bus 100. In one example, after receiving a dominant bit, the remote node can trust that the microcontroller coupled to microcontroller port 122 can control CAN bus 100, and a malicious microcontroller can then send a complete CAN frame with a valid CRC to manipulate CAN bus 100. In another example, because the dominant bit sent by the microcontroller overwrites the recessive bit sent by the remote node, the CAN frame sent by the remote node will be corrupted. Protocol decoder 128 is configured to invalidate the data frame and at least temporarily disconnect it after the first attempt to corrupt the data, preventing the microcontroller from corrupting data sent by the remote node or preventing a malicious microcontroller coupled to microcontroller port 122 from manipulating CAN bus 100 after losing arbitration. It should be noted that in Figure 3 In the description, the term "microcontroller" is used for a local host coupled to microcontroller port 122. Remote nodes may also include ECUs or microcontrollers. However, the term "remote node" is used for combinations of remote microcontrollers coupled to their own individual transceivers.

[0051] In some cases, if the dominant pulse is less than 6 bits, the protocol decoder 120 is configured to extend the dominant pulse on the CAN bus 100 by a longer amount, such as 11 dominant bits. This can be used to distinguish between security errors and normal errors on the CAN bus 100.

[0052] Optionally, if the microcontroller stops sending additional bits after sending the dominant bit, the protocol decoder 128 may continue sending more bits, up to a total of six bits (or more, depending on the implementation), to send a valid error message on the CAN bus 100 after losing the arbitration. The protocol decoder 128 can then disable the microcontroller's data transmission for a pre-selected period (e.g., a few seconds) to prevent the microcontroller from launching a data interruption attack on the CAN bus 100.

[0053] Violation detector 144 is configured to detect whether a complete frame is received from a remote host and whether the microcontroller coupled to microcontroller port 122 transmits an unauthorized portion of the frame. If an unauthorized portion of the frame is transmitted via the microcontroller, violation detector 144 is configured to disconnect the TXD line or disable TX 134. Violation detector 144 can also be configured to send a fail signal on CAN bus 100 to disable malicious frames transmitted by the microcontroller. Protocol decoder 128 can disconnect TX switch 142 and / or RX switch 140 within a predetermined time. Protocol decoder 128 is configured to verify whether the entire frame is properly received according to the CAN standard.

[0054] In some examples, transceiver 120 may not include any additional pins, allowing it to be used as a "drop-in" transceiver instead of a conventional transceiver. In examples where the protocol decoder 128 is implemented entirely or partially in software, transceiver 120 may be configured to be programmed with additional data verification rules. In some examples, if transceiver 120 can be configured to be programmed, tamper-proof security mechanisms can be employed, allowing only authorized devices or entities to alter the existing programming stored in transceiver 120.

[0055] In some embodiments, transceiver 120 may include a whitelist stored in memory (not shown) that provides verification of message identifiers allowed to be transmitted to CAN bus 100 via transceiver 120. The message identifiers stored in the whitelist can be configured when transceiver 120 is provided for use. Before sending a message identifier to CAN bus 100, protocol decoder 128 verifies whether the verified message identifier is allowed to be sent to CAN bus 100 via the microcontroller. If the whitelist does not include a message identifier, the data frame is rejected. In some examples, if the microcontroller should not receive and accepts a certain message identifier, protocol decoder 128 will invalidate the received message, preventing the received data frame from reaching the microcontroller. The whitelist can be stored in tamper-proof memory so that it cannot be changed after being provided. User-defined settings and data processing instructions can also be stored in memory. For example, the user can change the period during which protocol decoder 128 disables the microcontroller.

[0056] Figure 4A flowchart 200 is shown for preventing a malicious microcontroller (or ECU or local host) from interrupting or damaging data transmission on the CAN bus 100. Therefore, at step 202, the protocol decoder 128 monitors the TX line carrying data from the microcontroller to the CAN bus 100 via the transceiver 120. At step 204, the protocol decoder 128 verifies whether the microcontroller coupled to the transceiver 120 has won or lost arbitration. At step 206, the protocol decoder 128 detects data on the TX line. This data is sent by the microcontroller. At step 208, based on the monitoring of the RXD line, the protocol decoder 128 determines whether the microcontroller has won or lost arbitration. At steps 210 and 212, if the microcontroller has lost arbitration, the protocol decoder 128 verifies whether the data frame sent by the microcontroller includes an ACK or an error frame. If so, the protocol decoder 128 allows data to be transmitted to the CAN bus 100 via TX 134. If the data is not an ACK or an error frame, the protocol decoder 128 can invalidate the data and disable the TX line or TX 134 for a predetermined period. In another example, if the microcontroller has won arbitration and attempts to send a message identifier that the microcontroller is not authorized to send, the protocol decoder 128 can invalidate the data and disable the TX line or TX 134 for a predetermined period. The protocol decoder 128 can also send a recessive bit on the CAN bus 100 to indicate to other nodes on the CAN bus 100 that the CAN bus 100 is idle and the arbitration process can restart.

[0057] Some or all of these embodiments are combinable, some may be omitted entirely, and additional process steps may be added, while still achieving the product described herein. Therefore, the subject matter described herein can be embodied in many different variations, and all such variations are contemplated within the scope of the claims.

[0058] Although one or more embodiments have been described by way of example and specific examples, it should be understood that the one or more embodiments are not limited to the disclosed embodiments. Rather, it is intended to cover various modifications and similar arrangements that will be apparent to those skilled in the art. Therefore, the scope of the appended claims should be given the broadest interpretation in order to cover all such modifications and similar arrangements.

[0059] Unless otherwise indicated herein or clearly contradicted by the context, the use of the terms “a / an” and “described,” and similar indicators, in the context of describing elements (particularly in the context of the above claims), should be understood to cover both singular and plural. Unless otherwise indicated herein, the description of ranges of values ​​herein is intended only as a shorthand method for individually referring to each individual value belonging to the range, and each individual value is incorporated into this specification as if individually described herein. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes, as the scope of protection sought is defined by the claims set forth below and any equivalents thereof. Unless otherwise required, the use of any and all example or exemplary language (e.g., “for example”) provided herein is merely intended to better illustrate the subject matter and not to limit its scope. The use of the term “based on” and other similar phrases to indicate the conditions that produce the results in the appended claims and the written description is not intended to exclude other conditions that produce said results. No language in this specification should be construed as indicating any unclaimed element necessary for the practice of the claimed invention.

[0060] This document describes preferred embodiments known to the inventors for implementing the claimed subject matter. Of course, after reading the above description, those skilled in the art will understand variations of those preferred embodiments. The inventors expect those skilled in the art to adopt such variations as appropriate, and the inventors intend to practice the claimed subject matter of the invention in other ways than those specifically described herein. Therefore, the claimed subject matter includes all modifications and equivalents of the subject matter recited in the appended claims that are permissible under applicable law. Furthermore, unless otherwise indicated herein or otherwise clearly contradicted by the context, it covers any combination of the foregoing elements with all possible variations.

Claims

1. A transceiver for transmitting and receiving data from a controller area network (CAN) bus, characterized by, The transceiver includes a microcontroller port, a transmitter, and a receiver, wherein the transceiver is configured to receive data frames from the microcontroller via the microcontroller port, and determine whether the microcontroller is authorized to transmit the data field of the data frame based on a message identifier in the data frame, and if the microcontroller is not authorized to transmit the data field, the transceiver is configured to invalidate the data frame on the transmission line and disconnect the microcontroller from the CAN bus for a predetermined period of time; The transceiver is further configured to verify during the transmission of the data frame whether the microcontroller has lost or won arbitration; The transceiver is further configured to generate a failure signal and send the failure signal to the CAN bus to invalidate the data frame if the microcontroller sends the data frame after losing the arbitration. The transceiver further includes a transmission line switch in the transmission line between the microcontroller port receiving data from the microcontroller and the transmitter; The transceiver is further configured to disconnect the transmission line based on the detection of an unauthorized message identifier on the transmission line.

2. The transceiver of claim 1, wherein, The failure includes sending CAN error messages onto the CAN bus.

3. The transceiver of claim 1, wherein, Additionally, it is configured to send a dominant bit onto the CAN bus to invalidate the data frame if the controller sends the data frame after losing the arbitration.

4. The transceiver according to claim 1, characterized in that, Additionally, it is configured to verify whether the microcontroller is authorized to send the message identifier embodied in the data frame if the controller sends the data frame after winning the arbitration.

5. The transceiver according to claim 1, characterized in that, The transmitter includes an enable port for enabling or disabling the transmitter.

6. The transceiver according to claim 5, characterized in that, Additionally, it is configured to generate an enable / disable signal based on the detection of an unauthorized message identifier on a transmission line connected between the microcontroller port receiving input from the microcontroller and the transmitter.

Images