Patent Description:
CAN bus is a message-based communications bus protocol that is often used within automobiles. The CAN bus protocol is used to enable communications between various electronic control units (ECUs), such as an engine control module (ECM), a power train control module (PCM), airbags, antilock brakes, cruise control, electric power steering, audio systems, windows, doors, mirror adjustment, battery and recharging systems for hybrid/electric cars, and many more.

The data link layer of the CAN protocol is standardized as International Standards Organization (ISO) <NUM>-<NUM>. The standardized CAN data link layer protocol is in the process of being extended to provide higher data rates. The extended protocol, referred to as CAN Flexible Data-Rate or "CAN FD," has become part of the existing ISO <NUM>-<NUM> standard. A further extension, referred to as CAN XL, with a new level scheme allowing even higher data rates is in the definition phase discussed under CiA610 (CAN in Automation), is discussed in draft specification CiA610-<NUM>, and is moving towards standardization in the form of either a further update of the existing ISO11898 standards or a new standard.

<CIT> relates to CAN communication system, a CAN transmission apparatus, a CAN reception apparatus, and a CAN communication method.

In accordance with a second aspect of the present disclosure, a Controller Area Network, CAN, module is provided the CAN module comprising a receive data, RXD, input interface configured to receive a RXD stream from a CAN transceiver, a RXD output interface configured to send a manipulated receive data, MRXD, stream to a CAN controller, and a processing logic configured to identify a first bit sequence in the RXD stream, wherein the processing logic is configured to identify a first position for a first stuff bit in the first bit sequence, wherein the processing logic is configured to manipulate the first bit sequence to generate a second bit sequence comprising a second stuff bit at a second position in the second bit sequence corresponding to the first position of the first stuff bit in the first bit sequence such that the second stuff bit is complementary to a preceding bit of the second stuff bit in the second bit sequence, and wherein the CAN module is configured to send the second bit sequence via the RXD output interface to the CAN controller.

In one or more embodiments, the first bit sequence represents a first identifier of a first CAN frame.

In one or more embodiments, the processing logic is configured to identify a predefined number of identical, successive bits in the first bit sequence and, based on this identification, to predict the first position for the first stuff bit in the first bit sequence before and/or while the first stuff bit is received via the RXD input interface.

In one or more embodiments, the processing logic is configured, based on the first bit sequence, to identify the first position of the first stuff bit in the first bit sequence after the first stuff bit is received via the RXD input interface.

In one or more embodiments, the CAN module comprises a transmit data, TXD, input interface configured to receive a TXD stream from the CAN controller, wherein the processing logic configured to identify a third bit sequence in the TXD stream representing bits of a third CAN frame, wherein the processing logic is configured to identify a third position of a third stuff bit in the third bit sequence, wherein the first bit sequence is a result of the third bit sequence, and wherein the processing logic is configured to identify the first position of the first stuff bit in the first bit sequence based on the third position of the third stuff bit in the third bit sequence.

In one or more embodiments, wherein the processing logic is configured to determine whether the third stuff bit is either a dominant third stuff bit or a recessive, third stuff bit.

In one or more embodiments, the processing logic is configured to manipulate the first stuff bit for generating the second stuff bit to be complementary to its preceding bit only if the third stuff bit is determined to be a recessive third stuff bit.

In one or more embodiments, the processing logic is configured to identify multiple first stuff bits in the first bit sequence, wherein the processing logic is configured to manipulate the first bit sequence to generate the second bit sequence comprising for each first stuff bit an associated second stuff bit at a position corresponding to the position of the respective associated first stuff bit in the first bit sequence.

In one or more embodiments, the processing logic is configured to identify a fourth, dominant, non-stuff bit in the third bit sequence, wherein the processing logic is configured to manipulate the first bit sequence to generate the second bit sequence also comprising a fifth non-stuff bit at a position in the second sequence corresponding to the position of the fourth non-stuff bit in the third bit sequence such that the fifth non-stuff bit matches the fourth non-stuff bit.

In one or more embodiments, the CAN module comprising a transmit data, TXD, input interface configured to receive a TXD stream from the CAN controller, wherein the CAN module comprising a decoder configured to decode an identifier of a CAN frame being received via TXD stream, wherein the CAN module comprising a memory configured to store at least one valid identifier, and wherein the CAN module comprising a compare logic configured to compare the identifier being decoded by the decoder with the at least on valid identifier and output a mismatch signal, if the comparison indicates that the decoded identifier does not match any of the at least one valid identifier.

In one or more embodiments, the CAN module comprising a TXD output interface configured to forward the TXD stream to the CAN transceiver, wherein the CAN module is configured to interrupt the forwarding of the TXD stream in response to the mismatch signal.

In one or more embodiments, the CAN module comprising a signal generator configured to generate an invalidation signal in response to the mismatch signal, wherein the CAN module comprising a signal output interface configured to send the invalidation signal to the CAN transceiver to invalidate the CAN frame of the TXD stream.

In accordance with a second aspect of the present disclosure, a method for the Controller Area Network, CAN, module is provided. The method comprising the steps a) to e):.

In one or more embodiments, the method further comprising the steps f) to i):.

In one or more embodiments, the method further comprising the steps j) to m):.

Embodiments of the present disclosure will be described in more detail with reference to the appended drawings, in which:.

<FIG> depicts a CAN network <NUM> that includes multiple CAN nodes <NUM>, also referred to as "ECUs," each connected to a CAN bus <NUM>. In the embodiment of <FIG>, each CAN node includes a microcontroller <NUM> having an embedded CAN protocol controller <NUM> and a CAN transceiver <NUM>. The CAN protocol controller <NUM> may be referred to as a controller or CAN controller. The CAN transceiver <NUM> may be referred to as a transceiver.

The microcontrollers <NUM> are typically connected to at least one device (not shown) such as a sensor, an actuator, or some other control device and are programmed to determine the meaning of received messages and to generate appropriate outgoing messages. The microcontrollers <NUM>, which may also be referred to as host processors, hosts or digital signal processors (DSPs), are known in the field. In an embodiment, the host supports application software that interacts with the CAN protocol controller.

The CAN bus <NUM> carries analog differential signals and includes a CAN high (CANH) bus line <NUM> and a CAN low (CANL) bus line <NUM>. The CAN bus is known in the field.

<FIG> depicts an expanded view of one CAN node <NUM> from <FIG>. In the expanded view of <FIG>, the microcontroller <NUM> includes a host <NUM>, which may be, for example, a software application that is stored in memory of the microcontroller and executed by processing circuits of the microcontroller <NUM>. The microcontroller <NUM> and the CAN transceiver <NUM> of the CAN node <NUM> are connected between a supply voltage, Vcc, and ground, GND. As illustrated in <FIG>, data communicated from CAN protocol controller <NUM> being implemented by the microcontroller <NUM> to the CAN transceiver <NUM> is identified as transmit data (TXD) and data communicated from the CAN transceiver <NUM> to the CAN protocol controller <NUM> being implemented by the microcontroller <NUM> is referred to as receive data (RXD). Throughout the description, TXD is carried on a TXD path and RXD is carried on an RXD path. Data is communicated to and from the CAN bus <NUM> via the CANH and CANL bus lines <NUM> and <NUM>, respectively.

The CAN protocol controller <NUM> is preferably embedded within the microcontroller <NUM>, but may also be implemented external to the microcontroller <NUM> (e.g., a separate IC device). The data link layer operations between the CAN protocol controller <NUM> and the CAN transceiver <NUM> is known in the field.

For example, in receive operations, the CAN protocol controller <NUM> receives from the transceiver <NUM> serial bits in a bit stream, referred to as a RXD stream, via the RXD path. The CAN protocol controller <NUM> stores the received bits until an entire message is available for fetching by the microcontroller <NUM>. The CAN protocol controller <NUM> can also decode the CAN message according to the standardized frame format of the CAN protocol.

In transmit operations, the CAN protocol controller <NUM> receives a message from the microcontroller <NUM> and transmits the message as serial bits in a bit stream, referred to as a TXD stream, via the TXD path in the CAN frame format to the CAN transceiver <NUM>.

The CAN transceiver <NUM> is located between the CAN controller <NUM> being implemented by the microcontrollers <NUM> and the CAN bus <NUM>. The CAN transceiver <NUM> is configured to implement physical layer operations as known in the field.

For example, in receive operations, a CAN transceiver <NUM> converts analog differential signals from the CAN bus <NUM> to the RXD stream of serial bits that the CAN protocol controller <NUM> can interpret. The CAN transceiver <NUM> may also protect the CAN protocol controller <NUM> from extreme electrical conditions on the CAN bus <NUM>, e.g., electrical surges.

In transmit operations, the CAN transceiver <NUM> converts serial bits of the TXD stream received via the TXD path from the CAN protocol controller <NUM> into analog differential signals that are sent on the CAN bus <NUM>.

As noted above, the CAN protocol controller <NUM> can be configured to support the normal mode or the flexible data rate mode. As used herein, "CAN normal mode" (also referred to as "CLASSICAL CAN mode") as well as "CAN FD mode" refer to frames that are formatted according to the ISO <NUM>-<NUM> standard.

<FIG> depicts the format of an ISO <NUM>-<NUM> frame <NUM> (in the classical base frame format (CBFF) or standard format) that is used in CAN normal mode and <FIG> depicts the format of an ISO <NUM>-<NUM> frame <NUM> (in the FD base frame format or FBFF) that is used in CAN FD mode. The fields of the CAN normal mode and CAN FD mode frames are defined as follows:.

There is also another version of the classical frame format, referred to as "classical extended frame format (CEFF)," in which the FDF bit is in the old r1 position, whereas the FDF bit is in the r0 position in CBFF. There is also a "FD extended frame format (FEFF)," where "extended" refers to a <NUM>-bit identifier. Of note, the CAN protocols use the reserved bit (r0 or r1) (also referred to generally as the FDF bit) within a CAN frame to identify a frame as a CAN FD mode frame. In particular, the FDF bit is a <NUM>-bit field that indicates whether the frame is a CAN normal mode frame (ISO <NUM>-<NUM>) or a CAN FD mode frame (ISO <NUM>-<NUM>). When the FDF bit is dominant (e.g., low or "<NUM>"), the frame is a CAN normal mode frame and when the FDF bit is recessive (e.g., high or "<NUM>"), the frame is a CAN FD mode frame. In a CAN normal mode frame, the reserved bits (r0, r1) are always driven dominant to the bus lines.

CAN messages are broadcast messages and the identifier is typically unique to the sender CAN node on the same CAN bus. The CAN protocol controllers <NUM> of the receiving CAN nodes <NUM> have identifier filters that are "tuned" to certain identifiers to make sure that the host receives only relevant messages and is not bothered with irrelevant messages. Standard CAN frames have an <NUM>-bit IDENTIFIER field to carry an <NUM>-bit identifier and extended CAN frames have a <NUM>-bit IDENTIFIER field to carry a <NUM>-bit identifier. The IDENTIFIER field <NUM> of a standard CAN frame is depicted in <FIG> and the IDENTIFIER field of an extended CAN frame is depicted in <FIG>. As shown in <FIG>, the <NUM>-bit IDENTIFIER field is divided into two sections, an <NUM>-bit base IDENTIFIER field <NUM> and an <NUM>-bit extended IDENTIFIER field <NUM>.

To enable synchronization between a transmitting CAN node <NUM> and another receiving CAN node <NUM>, long monotonous sequences of a large number of identical bits are to be prevented. The CAN protocol controller <NUM> is therefore configured for so-called bit stuffing. According to bit stuffing, the CAN protocol controller <NUM> inserts an additional inverse bit after five identical bits in the TXD stream. This means that the inverse bit is the inverse of (one of or each of) the previous five identical bits. For example, if five dominant bits are sent in series in the TXD stream, the CAN protocol controller <NUM> inserts a recessive bit as a stuff bit after the fifth dominant bit in the TXD stream. The same applies if, for example, five recessive bits are sent in series in the TXD stream, because in this case the CAN protocol controller <NUM> inserts a dominant bit as a stuff bit after the fifth recessive bit in the TXD stream. The TXD stream results in a CAN message transmitted via the CAN BUS <NUM> and is addressed through the identifier for a particular receiver CAN node <NUM>. The transceiver <NUM> of this receiver CAN node <NUM> will convert the received message into serial bits in the form of a RXD stream.

The CAN protocol controller <NUM> of the receiver CAN node <NUM> knows about bit stuffing in the RXD stream and removes each stuff bit from the serial bits of a received RXD stream. For example, the CAN protocol controller <NUM> is preferably configured to identify bit sequence of five identical bits in the RXD stream and is further configured to remove a sixth stuff bit in the RXD stream following the received bit sequence of five identical bits. By removing a stuff bit, the actual bit series, which represents message data of the message to be transmitted, can be restored. The CAN protocol controller <NUM> in the receiver CAN node <NUM> is configured accordingly for this purpose. It is to be noted, that a stuff bit may also be referred to as a complementary stuff bit.

A stuff bit in the TXD stream as well as a stuff bit in the RXD stream are not used to represent relevant message data to be transmitted from a sender CAN node <NUM> to another receiver CAN node <NUM>. Nevertheless, a CAN protocol controller <NUM> in the receiver CAN node <NUM> may be configured to assess received bits of a RXD stream, and thus also to assess a stuff bit in the RXD stream. If a stuff bit in the RXD stream violates the rules of bit stuffing, a stuff error may be detected by the CAN protocol controller <NUM> of the receiver CAN node <NUM> based on the violation.

Disturbances on the CAN bus <NUM> that occur solely during the transmission of a stuff bit can lead to a violation of the bit stuffing rules. The violation of the bit stuffing rules leads to the previously mentioned detection of the stuff error. However, if the disturbance occurs solely during the transmission of the stuff bit, there is in fact no transmission error of relevant message data, but solely a transmission error of the stuff bit. A transmission error of the stuff bit may not negatively affect the transmission of the relevant message data. Against this background, there is a need to prevent stuff bit transmission errors.

The present disclosure is based on the finding that an erroneous stuff bit received at the CAN transceiver of a receiver CAN node <NUM> via a CAN bus <NUM> can still be corrected within the receiver CAN node <NUM> before the stuff bit is forwarded to the CAN protocol controller <NUM> of the receiver CAN node <NUM>. Instead, the erroneous stuff bit may be corrected after being received at the CAN transceiver <NUM> such that corrected stuff bit reaches the CAN protocol controller <NUM> of the receiver CAN node <NUM>. As a result, a stuff error is prevented. It is to be noted, that the findings apply in an analogous manner for a CAN transceiver of a CAN node <NUM>, which acts as a transmitter node via the CAN bus <NUM>. Thus, even if the following explanations may relate as an example to a CAN transceiver of a receiver CAN node <NUM>, the following explanations apply analogously to a CAN transceiver of a transmitter CAN node <NUM>.

Based on the underlying concept described above, a CAN module <NUM> is proposed that can be integrated, for example as illustrated in <FIG>, into the RXD path extending from the CAN transceiver <NUM> to the CAN protocol controller <NUM>. In this regard, the CAN module <NUM> may be separate from the CAN transceiver <NUM> and may also be separate from the CAN protocol controller <NUM>. In this embodiment, the RXD path may extend from the CAN transceiver <NUM> to the CAN module <NUM>. A further RXD path is provided extending form the CAN module <NUM> to the CAN protocol controller <NUM> in place of the RXD path.

Instead of a separate embodiment of the CAN module <NUM>, it is also possible for the CAN module <NUM> to be at least partially integrated with the CAN transceiver <NUM>, at least partially integrated with the CAN protocol controller <NUM>, or at least partially integrated with both. In the following discussion, it is assumed for simplicity that the CAN module <NUM> is separate from the CAN transceiver <NUM> and the CAN protocol controller <NUM>. However, the following explanations of the CAN module <NUM> apply in an analogous manner to arrangements in which the CAN module <NUM> is configured at least partially integrated with the CAN transceiver <NUM>, at least partially integrated with the CAN protocol controller <NUM>, or at least partially integrated with both.

<FIG> depicts an embodiment of a CAN node <NUM> that is configured to implement the CAN module <NUM>. The CAN node <NUM> comprises the CAN module <NUM> as well as the CAN transceiver <NUM>, the CAN protocol controller <NUM>, and the host <NUM> as described above with reference to <FIG>. As shown in <FIG>, the CAN module <NUM> is located in signal direction of the RXD path before the CAN protocol controller <NUM> such that a message communicated on the RXD path can be manipulated at the CAN module <NUM>, before a manipulated message, which is based on the message of the RXD path, is communicated on the RXD path to be received at the CAN protocol controller <NUM>.

An embodiment of the CAN module <NUM> is schematically illustrated in <FIG>. The CAN module <NUM> may be formed by software module, a hardware module or a combination thereof. Further, the CAN module may be formed by a separate apparatus or may be formed as a part of a CAN node. The CAN module <NUM> comprises a RXD input interface <NUM> configured to receive a RXD stream <NUM> from the CAN transceiver <NUM>, and a RXD output interface <NUM> configured to send a manipulated receive data, MRXD, stream <NUM> to a CAN controller <NUM>. A partial section of an example of a RXD stream <NUM> and a partial section of an example of a MRXD stream <NUM> are shown in <FIG>. The CAN module <NUM> comprises a processing logic <NUM> configured to identify a first bit sequence <NUM> in the RXD stream <NUM>, wherein the processing logic <NUM> is configured to identify a first position for a first stuff bit <NUM> in the first bit sequence <NUM>. The processing logic <NUM> is also configured to manipulate the first bit sequence <NUM> to generate a second bit sequence <NUM> comprising a second stuff bit <NUM> at a second position in the second bit sequence <NUM> corresponding to the first position of the first stuff bit <NUM> in the first bit sequence <NUM> such that the second stuff bit <NUM> is complementary to a preceding bit of the second stuff bit <NUM> in the second bit sequence <NUM>. The CAN module <NUM> is configured to send the second bit sequence <NUM> via the RXD output interface <NUM> to the CAN controller <NUM>.

With reference to the aforementioned embodiment, it is noted that the RXD stream <NUM> is sent from the CAN transceiver <NUM> to the RXD input interface <NUM> of the CAN module <NUM> via the RXD path. The RXD stream <NUM> comprises a series of bits, and a partial section of this series of bits of the RXD stream <NUM> is shown schematically in <FIG>. The illustrated bits of the RXD stream <NUM> comprise a first bit sequence <NUM> as a portion of the series of bits. Thus, the first bit sequence <NUM> also comprises a series of bits. In principle, it is possible for the first bit sequence <NUM> to form, for example, a partial section of an identifier of a CAN frame, such as the identifier <NUM> of the frame of <FIG>. In general, a bit sequence does not necessarily require that the bits of the bit sequence are distributed with equal duration. Instead, the bits of a bit sequence may vary in their time duration.

The processing logic <NUM> of the CAN module <NUM> is configured to identify the first bit sequence <NUM> in the RXD stream <NUM>. The first bit sequence <NUM> includes the first stuff bit <NUM>. The first stuff bit <NUM> may, in a particular point of time, be the last bit in the first bit sequence <NUM> received at RXD input interface of the CAN module <NUM>. The processing logic <NUM> may identify the first bit sequence <NUM> in the RXD stream <NUM> by, for example, the first stuff bit <NUM> and/or the sequence <NUM> of five identical bits in the RXD stream <NUM> that directly precedes it. Another possibility for identification is explained further on in this description.

In the RXD stream <NUM>, the associated bits are transmitted sequentially from the CAN transceiver <NUM> to the RXD input interface <NUM> of the CAN module <NUM>. Because of this serial transmission of the bits over the RXD path, it is possible for the processing logic <NUM> of the CAN module <NUM> to identify a first position of the first stuff bit <NUM> in the RXD stream <NUM>. The term "first" is used for the purpose of distinction. The first bit sequence <NUM> is a partial section of the RXD stream <NUM>, and it follows that the processing logic <NUM> is also configured to identify the first position of the first stuff bit <NUM> in the first bit sequence <NUM>. Preferably, the first position of the first stuff bit <NUM> in the first bit sequence <NUM> refers to the identical first position of the first stuff bit <NUM> in the RXD stream <NUM>.

It is noted that <FIG> further schematically illustrates a partial section of a series of bits of an example TXD stream <NUM>. The TXD stream <NUM> is sent from the CAN protocol controller <NUM> to the CAN transceiver <NUM> via the TXD path. In principle, it is possible that the CAN module <NUM> is integrated in the TXD path, so that the CAN module is integrated in the signal direction of the TXD path between the CAN protocol controller <NUM> and the CAN transceiver <NUM>. However, it is also possible that the TXD path is branched, so that the TXD stream <NUM> is sent from the CAN protocol controller to both the CAN transceiver <NUM> and the CAN module <NUM>. The TXD stream <NUM> comprises a series of bits, and a partial section of this series of bits of the TXD stream <NUM> is shown schematically in <FIG>. The illustrated bits of the TXD stream <NUM> comprise a bit sequence <NUM> of a portion of the series of bits. This bit sequence <NUM> is referred to as the third bit sequence <NUM>. Thus, the third bit sequence <NUM> also comprises a series of bits. In principle, it is possible for the third bit sequence <NUM> to form, for example, a partial section of an identifier of a CAN frame, such as the identifier <NUM> of the frame of <FIG>.

In the example of <FIG>, the third bit sequence <NUM> of the TXD stream <NUM> comprises a series <NUM> of five consecutive identical bits. According to the bit stuffing rules, a stuff bit <NUM>, referred to as the third stuff bit <NUM>, is inserted into the TXD stream <NUM> following the series <NUM> by the CAN protocol controller <NUM>. The CAN transceiver <NUM> receives the TXD stream <NUM> and sends a corresponding message over the CAN bus <NUM>. At the same time, this message is received by the CAN transceiver <NUM> over the CAN bus <NUM> such that the CAN transceiver <NUM> sends an RXD stream <NUM> based on the received message over the RXD path. If the CAN bus <NUM> is subject to a disturbance, particularly if a signal representing the third stuff bit <NUM> is transmitted over the CAN bus <NUM>, the RXD stream <NUM>, which should actually be identical to the TXD stream <NUM> in the examples explained previously, may have the first stuff bit <NUM> that does not correspond to the third stuff bit <NUM> of the TXD stream <NUM>. As can be seen in the example in <FIG>, the third stuff bit <NUM> of the TXD stream <NUM> has a value of "<NUM>", whereas the first stuff bit <NUM> of the RXD stream <NUM> has a value of "<NUM>". Thus, the first stuff bit <NUM> is in error. The error may have been caused by a disturbance on the CAN bus <NUM>.

If the RXD stream <NUM> shown in <FIG> with the associated first bit sequence <NUM> were to arrive at the CAN protocol controller <NUM>, the CAN protocol controller <NUM> would interpret the first bit sequence <NUM> as an error frame because the first bit sequence <NUM> has six consecutive identical bits with the value "<NUM>". If the CAN protocol controller <NUM> detects a sufficient and predetermined number of times that the CAN protocol controller <NUM> appears to have transmitted an error frame itself, the CAN protocol controller <NUM> initially switches to a passive mode and, if a further number of apparently transmitted error frames are detected, switches to an off mode.

If the detection of an error frame by the CAN protocol controller <NUM> is based on a sequence of bits affected by a disturbance on the CAN bus <NUM>, the detection of the error frame may be a false positive detection. The CAN module <NUM> may be used to prevent this false positive detection.

As previously discussed, the CAN module <NUM> includes an RXD input interface to receive an RXD stream <NUM>. The processing logic <NUM> of the CAN module <NUM> is configured to identify the first bit sequence <NUM> and the first position of the first stuff bit <NUM> in the first bit sequence <NUM>. Further, the processing logic <NUM> is configured to generate a second bit sequence <NUM>. The second bit sequence <NUM> is based on the previously identified first bit sequence <NUM>. However, the first bit sequence <NUM> may include an erroneous first stuff bit <NUM> in the event of disturbances on the CAN bus <NUM>. To prevent the erroneous first stuff bit <NUM> from resulting in a corresponding erroneous stuff bit in the second bit sequence <NUM>, referred to as the second stuff bit <NUM>, the processing logic <NUM> is configured to generate the second bit sequence <NUM> by manipulating the first bit sequence <NUM>. For the second bit sequence <NUM>, the first bit sequence <NUM> is manipulated by the processing logic <NUM> such that the second stuff bit <NUM> of the second bit sequence <NUM> is complementary to the preceding bit of the second stuff bit <NUM> in the second bit sequence <NUM>. The requirement of the second stuff bit <NUM> to be complementary to the preceding bit is sufficient, as this preceding bit is one of five identical bits (of the series <NUM>) preceding the second stuff bit <NUM> in the second bit sequence <NUM>.

The second position of the second stuff bit <NUM> in the second bit sequence <NUM> corresponds to the first position of the first stuff bit <NUM> in the first bit sequence <NUM>. Except for the second stuff bit <NUM>, the second bit sequence <NUM> may correspond to the first bit sequence <NUM>. It follows that the second bit sequence <NUM> includes a series <NUM> of five consecutive identical bits, with the second stuff bit <NUM> in the second bit sequence <NUM> following said series <NUM>. The CAN module <NUM> is configured to send the second bit sequence <NUM> to the CAN protocol controller <NUM> using the RXD output interface <NUM>. Thus, the second bit sequence <NUM> is sent to the CAN protocol controller <NUM> in place of the first bit sequence <NUM>. In light of this, the CAN module <NUM> can be integrated into the RXD path between the CAN transceiver <NUM> and the CAN protocol controller <NUM> such that the RXD stream <NUM> is sent from the CAN transceiver <NUM> to the RXD input interface <NUM> and the MRXD stream <NUM>, which includes the second bit sequence <NUM>, is sent from the RXD output interface <NUM> to the CAN protocol controller <NUM>.

By manipulating the first stuff bit <NUM> to generate the (corrected) second stuff bit <NUM>, the CAN module <NUM> can prevent a false positive detection of an error frame at the CAN protocol controller <NUM>. Rather, the (corrected) second stuff bit <NUM> prevents an error frame caused by disturbances on the CAN bus <NUM> from being sent to the CAN protocol controller <NUM>. The manipulation-generated second stuff bit <NUM> does not contribute to a corruption of the actual message data, since stuff bits in the CAN protocol controller <NUM> are pulled out or cleared before an interpretation of the message based on a received bit stream in the CAN protocol controller <NUM> occurs.

As indicated before, the terms "first", "second", "third" etc. are used for distinguishing purpose only. A second item may therefore not require a first item or third item.

It is to be noted that the first stuff bit <NUM>, the second stuff bit <NUM> and the third stuff bit <NUM> are generally not limited to a specific type of stuff bit. In general, the first stuff bit <NUM> the second stuff bit <NUM> and the third stuff bit <NUM> may be either a recessive stuff bit or a dominant stuff bit.

The processing logic <NUM> of the CAN module <NUM> may be formed by a processing unit, a circuit configured for processing or a combination thereof.

In one or more embodiments of the CAN module <NUM>, the first bit sequence <NUM> represents a first identifier of a first CAN frame. For example, the first bit sequence <NUM> may represent the identifier <NUM> of the CAN frame of <FIG>. In another example, the first bit sequence <NUM> may represent either the first identifier field <NUM> or the second identifier field <NUM> of the CAN frame of <FIG>.

A predetermined identifier of a CAN frame may be stored, preferably as a predefined series of bits, by the CAN module <NUM>, in particular by the processing logic <NUM>. If the first bit sequence <NUM> represents the predetermined identifier, the first bit sequence <NUM> in the RXD stream <NUM> is precisely and quickly identifiable by means of the processing logic <NUM> of the CAN module <NUM>.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> is configured to identify a predefined number of identical, successive bits, in particular the series <NUM> of bits, in the first bit sequence <NUM>. In general according to the bit stuffing rules, a series of five identical bits is followed by an additional bit stuff bit. Based on this underlying concept, in one or more embodiments of the CAN module <NUM>, the processing logic <NUM> is configured to, based on the identification of the predefined number of identical, successive bits, to predict the first position for the first stuff bit <NUM> in the first bit sequence <NUM> before and/or while the first stuff bit <NUM> is received via the RXD input interface <NUM>.

The processing logic <NUM> is preferably configured to identify the first position by the prediction of the first position. In an example, provided that the first stuff bit <NUM> has not yet been received via the RDX stream <NUM> on the RDX input interface <NUM> of the CAN module <NUM> when the first position of the first stuff bit <NUM> is identified, it is preferred that the processing logic <NUM> predicts the first position of the first stuff bit <NUM>. This prediction may then form the identification of the first position of the first stuff bit <NUM>. This prediction is logically possible since the series <NUM> of the predetermined number of identical bits has already been received via the RXD stream <NUM> at the RXD input interface <NUM> of the CAN module <NUM>. The processing logic <NUM> is preferably configured to determine the position of the last bit in the already received series <NUM> of bits of the first bit sequence <NUM>. Based on this position, the next position, which is the first position of the first stuff bit <NUM>, is also computable. Preferably, the processing logic <NUM> is configured to perform this same calculation. In a corresponding manner, the prediction of the first position of the first stuff bit <NUM> may also be performed by the processing logic <NUM> of the CAN module <NUM>. The predefined number may be referred to the number of five.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> is configured, based on the first bit sequence <NUM>, to identify the first position of the first stuff bit <NUM> in the first bit sequence <NUM> after the first stuff bit <NUM> is received via the RXD input interface. The bits of the first bit sequence <NUM> are received sequentially from the RXD input interface <NUM> of the CAN module <NUM> via the RDX stream <NUM>. By receiving the bits of the RDX stream <NUM> sequentially, the positions of the associated received bits are also determined by the CAN module <NUM>. After the first bit sequence <NUM> is completely received by the CAN module <NUM> via the RDX stream <NUM>, the position of the first stuff bit <NUM> can be immediately accessed. Identification of the first position of the first stuff bit <NUM> is particularly simple in this case, and is determined by immediately determining the first position of the first stuff bit <NUM> when received via the RXD stream <NUM> at the RXD input interface <NUM> of the CAN module <NUM>.

In one or more embodiments, the CAN module <NUM> comprises a transmit data, TXD, input interface <NUM> configured to receive a TXD stream from the CAN controller <NUM>. As indicated before, the CAN controller <NUM> may also be referred to as the CAN protocol controller <NUM>. As schematically illustrated in <FIG>, the CAN module <NUM> may be integrated in the TXD path extending from the CAN protocol controller <NUM> to the CAN transceiver <NUM>.

In one or more embodiments, the CAN module <NUM> a TXD output interface <NUM>. The CAN module <NUM> may be configured to forward a TXD stream received via the TXD input interface <NUM> to the TXD output interface <NUM>, such that the TXD stream is sent via the TXD output interface <NUM> to the CAN transceiver <NUM>.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> is configured to identify a third bit sequence <NUM> in the TXD stream representing bits of a third CAN frame. Further, the processing logic <NUM> may also configured to identify a third position of a third stuff bit <NUM> in the third bit sequence. In an example, the third bit sequence <NUM> comprises the third stuff bitt <NUM>. The third stuff bit may be the last bit in the third bit sequence. The third bit sequence may comprise a series <NUM> of five identical bits followed directly by the third stuff bit <NUM>. For the identification of the third bit sequence <NUM> in the TXD stream <NUM> as well as for the identification of the third position of the third stuff bit <NUM> in the third bit sequence <NUM>, reference is made in an analogous manner to the preceding explanations, preferred features and advantages as explained in connection with the identification of the first bit sequence <NUM> in the RXD stream <NUM> and the identification of first position of the first stuff bit <NUM> in the first bit sequence <NUM>.

As previously explained, a message sent by the CAN transceiver <NUM> over the CAN bus <NUM> is simultaneously monitored by CAN transceiver <NUM> so that a respective RXD stream is generated by the CAN transceiver <NUM> from this monitored message. Consequently, the first bit sequence <NUM> is a result of the third bit sequence <NUM>. Therefore, the processing logic <NUM> may be configured detect, whether a third bit sequence <NUM> is received at the TXD input interface <NUM>, wherein the processing logic <NUM> may also be configured to manipulate the first bit sequence <NUM> to generate the second bit sequence <NUM> only if third bit sequence <NUM> is detected. Otherwise, if the first bit sequence <NUM> is not a result of the third bit sequence <NUM>, the processing logic <NUM> may not detect the third bit sequence <NUM> and, as a result, may also not manipulate the first bit sequence <NUM>, but forwards the first bit sequence <NUM> unchanged via the TXD output interface <NUM>.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> of the CAN module <NUM> is preferably configured to identify the first position of the first stuff bit <NUM> in the first bit sequence <NUM> based on the third position of the third stuff bit <NUM> in the third bit sequence <NUM>. It is expected that the receiving of the first bit sequence <NUM> via the RXD input interface <NUM> is time delayed relative to the receiving of the third bit sequence <NUM> via the TXD input interface <NUM>. Given this time delay, the identification of the third position of the third stuff bit <NUM> may be performed by the processing logic <NUM> before the first stuff bit <NUM> is received with the first bit sequence <NUM>. Further, the first position of the first stuff bit <NUM> may be identified based on the identified third position of the third stuff bit <NUM> by the processing logic <NUM> before the first stuff bit <NUM> is received with the first bit sequence <NUM>. In other words, the first position of the first stuff bit <NUM> may have already been identified by the processing logic <NUM> before the first stuff bit <NUM> has been received by the CAN module <NUM>. Once the third stuff bit <NUM> has been received, a manipulation of the first bit sequence <NUM> may be performed to generate the second bit sequence <NUM>. In this case, the manipulation of the first bit sequence <NUM> is not delayed, in contrary may even be ahead, in time by the identification of the first position of the first stuff bit <NUM>. As a result, the second bit sequence <NUM> can be generated by the processing logic <NUM> without a time delay.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> may be configured to manipulate the first bit sequence <NUM> to generate the second bit sequence <NUM> comprising the second stuff bit <NUM> at the second position corresponding to the third position of the third stuff bit <NUM> in the third bit sequence such that the second stuff bit <NUM> matches the third stuff bit <NUM>.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> is configured to determine whether the third stuff bit <NUM> is either a dominant third stuff bit or a recessive third stuff bit. This may support the match of the second stuff bit <NUM> with the third stuff bit <NUM>.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> is configured to manipulate the first stuff bit <NUM> for generating the second stuff bit <NUM> to be complementary to its preceding bit only if the third stuff bit <NUM> is determined to be a recessive third stuff bit <NUM>.

It is again noted that the first bit sequence <NUM> is caused by the third bit sequence <NUM>. A message sent by the CAN transceiver <NUM> based on the TXD stream <NUM> via the CAN bus <NUM> is received again by the CAN transceiver <NUM> with a small time delay, whereby the CAN transceiver <NUM> generates the RXD stream <NUM> based on the message received via the CAN bus <NUM>. Thus, the third position of the third stuff bit <NUM> in the third bit sequence <NUM> corresponds to the first position of the first stuff bit <NUM> in the first bit sequence <NUM>. Furthermore, the third position of the third stuff bit <NUM> in the third bit sequence <NUM> corresponds to the second position of the second stuff bit <NUM> in the second bit sequence <NUM>. The first TXD stream <NUM> transmits the third bit sequence <NUM> to the CAN transceiver <NUM>. If the third stuff bit <NUM> of the third bit sequence <NUM> is a dominant stuff bit, it can be assumed with a higher probability that the dominant stuff bit is robust to disturbances on the CAN bus <NUM>. This is because the dominant stuff bit is represented on the CAN bus <NUM> by a non-zero differential voltage, preferably a differential voltage of <NUM> V, between the CAN bus lines <NUM>, <NUM>. With this in mind, it can be assumed with a higher probability that the dominant third stuff bit <NUM> leads to a dominant first stuff bit <NUM> in the first bit sequence <NUM>. In this case, since the dominant first stuff bit <NUM> corresponds to the dominant third stuff bit <NUM>, manipulation of the first stuff bit <NUM> for generating the second stuff bit <NUM> is not necessary. Instead, provided that the third stuff bit <NUM> is a dominant stuff bit, manipulation of the first bit sequence <NUM> to generate the second bit sequence <NUM> may be suspended. In other words, it may be provided that the second bit sequence <NUM> is formed from the first bit sequence <NUM> without manipulation if the third stuff bit <NUM> is a dominant stuff bit. However, the previously explained manipulation may be performed by the processing logic <NUM> to generate the second bit sequence <NUM> if the third stuff bit <NUM> is a recessive stuff bit. Since processing logic <NUM> only needs to perform the previously explained manipulation in the case of a recessive third stuff bit <NUM>, the computational effort and costs of processing logic <NUM> may be reduced.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> is configured to identify multiple first stuff bits in the first bit sequence, wherein the processing logic <NUM> is configured to manipulate the first bit sequence <NUM> to generate the second bit sequence <NUM> comprising for each first stuff bit <NUM> an associated second stuff bit <NUM> at a position corresponding to the position of the respective associated first stuff bit <NUM> in the first bit sequence <NUM>. Therefore, the preceding explanations for generating a second stuff bit <NUM> by manipulating the first stuff bit <NUM> apply in an analogous manner to each second stuff bit <NUM> of the second bit sequence <NUM>.

<FIG> schematically illustrates another example of the partial sections of the TXD stream <NUM>, the RXD stream <NUM> and the MRXD stream <NUM>. The previous explanations in connection with <FIG> are referred to in an analogous manner. As can be seen from the TXD stream <NUM> of <FIG>, the third bit sequence <NUM> has a bit <NUM> which is assumed not to be a stuff bit. This bit <NUM> is also referred to as the fourth non-stuff bit <NUM>, which is assumed to be dominant. If a message based on the third bit sequence <NUM> is transmitted by the CAN transceiver <NUM> on the CAN bus <NUM>, it is possible, albeit in rare cases, that a signal on the CAN bus <NUM> representing the fourth non-stuff bit <NUM> may be affected by disturbance. This disturbance may cause the message monitored by the CAN transceiver <NUM> to represent the first bit sequence <NUM>, where a sixth bit <NUM> of the first bit sequence <NUM> is a recessive bit even though it should be a dominant bit corresponding to the fourth non-stuff bit <NUM>. Considering the above, there is a demand to prevent the previously explained error by means of the CAN module <NUM>.

In one or more embodiments of the CAN module <NUM>, wherein the processing logic <NUM> is configured to identify a fourth, dominant, non-stuff bit <NUM> in the third bit sequence, wherein the processing logic <NUM> is configured to manipulate the first bit sequence <NUM> to generate the second bit sequence <NUM> also comprising a fifth non-stuff bit <NUM> at a position in the second sequence <NUM> corresponding to the position of the fourth non-stuff bit <NUM> in the third bit sequence <NUM> such that the fifth non-stuff bit <NUM> matches the fourth non-stuff bit <NUM>.

Based on the identification of the fourth non-stuff bit <NUM> as a dominant bit, manipulation at the corresponding bit position of the first bit sequence <NUM> to generate the second bit sequence <NUM> (i.e., at the sixth non-stuff bit <NUM>) may be performed by the processing logic <NUM> such that the fifth non-stuff bit <NUM> of the second bit sequence <NUM> corresponds to the (dominant) fourth non-stuff bit <NUM> of the third bit sequence <NUM>. An error on the sixth non-stuff bit <NUM> of the first bit sequence <NUM> caused by a disturbance on the CAN bus <NUM> can thus be corrected.

It is noted that the last explained manipulation of the first bit sequence <NUM> to generate the second bit sequence <NUM> may be understood as an extension of the previously explained manipulation of the first bit sequence <NUM> to generate the second bit sequence <NUM>. Thus, with the manipulation of the first bit sequence <NUM> that can be performed by the processing logic <NUM> to generate the second bit sequence <NUM>, it can be achieved, on the one hand, that the second stuff bit <NUM> is complementary to the preceding bit in the second bit sequence <NUM> and, on the other hand, that the fifth non-stuff bit <NUM> of the second bit sequence <NUM> matches the fourth non-stuff bit <NUM> of the third bit sequence <NUM>.

In one or more embodiments of the CAN module <NUM>, the processing logic <NUM> may also be configured to identify multiple fourth, dominant, non-stuff bits <NUM> in the third bit sequence <NUM>, wherein the processing logic <NUM> may be configured to manipulate the first bit sequence <NUM> to generate the second bit sequence <NUM> also comprising, for each fourth non-stuff bit <NUM>, an associated fifth non-stuff bit <NUM> at a position in the second bit sequence <NUM> corresponding to the position of the associated fourth non-stuff bit <NUM> in the third bit sequence <NUM> such that each fifth non-stuff bit <NUM> matches the associated fourth non-stuff bit <NUM>.

In one or more embodiments, the CAN module <NUM> comprises the transmit data, TXD, input interface <NUM> configured to receive the TXD stream from the CAN controller <NUM>. The CAN module <NUM> may also comprise a decoder <NUM> configured to decode an identifier <NUM>, <NUM>, <NUM> of a CAN frame being received via the TXD input interface <NUM>. The identifier <NUM>, <NUM>, <NUM> may be referred to as the decoded identifier <NUM>, <NUM>, <NUM>. The CAN module <NUM> may also comprise a memory <NUM> configured to store at least one valid identifier. Further, the CAN module <NUM> may comprise a compare logic <NUM> configured to compare the decoded identifier <NUM>, <NUM>, <NUM> with the at least on valid identifier and output a mismatch signal, if the comparison indicates that the decoded identifier <NUM>, <NUM>, <NUM> does not match any of the at least one valid identifier.

Security is a growing concern with in-vehicle networks. Many of the components of an in-vehicle network utilize software that may be updated. In order to update software, in-vehicle networks often have "back door" access ports. If a back door access port is hacked, elements in the in-vehicle network may be compromised. One known attack technique on an in-vehicle network that uses the CAN protocol involves an attacker sending CAN massages from a compromised node using CAN Identifiers that are normally not assigned to this node. Such unauthorized CAN messages may be received by CAN nodes on the CAN bus and recognized as valid messages because the identifier has previously been used within the CAN network. Once received by a CAN node on the CAN bus, the suspicious messages can be used to implement malicious activity within the CAN node. For example, if a node may be allowed to send ID=<NUM><NUM><NUM>, but not <NUM><NUM><NUM>, then sending an error frame for valid reasons at the end of the ID may cause a false alarm. Thus, there is a need to prevent any valid reason for sending error frames during the arbitration phase.

To detect and prevent such an attack on the CAN network and in accordance with an embodiment of CAN module <NUM>, the decoder <NUM> can be configured to decode the identifier of a CAN frame that is being sent by the CAN protocol controller <NUM> to the CAN module <NUM>. The compare logic <NUM> of the CAN module <NUM> may further be configured to compare the decoded identifier of incoming CAN frame to the at least one stored and valid identifier to generate a mismatch signal if any incoming CAN frame does not match any of the at least on valid identifier. Since identifiers are preassigned to each CAN node, if the decoded identifier does not match any of the stored and valid identifier, it can be assumed that the CAN frame is received at the CAN module <NUM> on its TXD input pin form an intruded or hacked CAN protocol controller <NUM>. To protect the CAN network and the CAN nodes connected to it from potential damage, actions can be triggered based on the mismatch signal. For example, in response to mismatch signal, the CAN module <NUM> may be configured to immediately send an error signal such as an error flag to the transceiver via the TXD output interface <NUM>, which sends this error signal onto the CAN bus to prevent a malicious CAN frame form the inferred and/or hacked CAN protocol controller <NUM> from being successfully and completely received by any CAN nodes on the CAN bus, e.g., to invalidate, destroy, and/or kill the CAN frame.

In one or more embodiments, the decoder <NUM> may be configured to decode a CAN frame before the complete CAN frame is received via the TXD stream at the TXD input interface <NUM>.

In one or more embodiments, the compare logic <NUM> may be configured to compare the decoded identifier with the at least one valid identifier before the complete CAN frame is received via the TXD stream at the TXD input interface <NUM>.

In one or more embodiments, the CAN module <NUM> comprises the TXD output interface <NUM> configured to forward the TXD stream to the CAN transceiver <NUM>, wherein the CAN module <NUM> is configured to interrupt the forwarding of the received TXD stream in response to the mismatch signal. For instance, if the comparison indicates that the decoded identifier from the CAN frame does not match any of the valid and stored identifiers, the mismatch signal is generated by the compare logic <NUM> resulting in the interruption of the forwarding of the received TXD stream. The match signal may also trigger the CAN module <NUM> to invalidate, destroy, and/or kill the received CAN frame provided with the received CAN stream before the complete CAN frame is provided to the TXD output interface <NUM>.

In one or more embodiments, the CAN module <NUM> comprises a signal generator configured to generate an invalidation signal in response to the mismatch signal, wherein the CAN module <NUM> may also comprise a signal output interface configured to send the invalidation signal to the CAN transceiver <NUM> to invalidate the CAN frame <NUM>, <NUM>, <NUM> of the TXD stream. The invalidation signal may represent an error frame. Thus, the signal output interface may be configured to cause the invalidation signal on the CAN bus to invalidate the CAN frame <NUM>, <NUM>, <NUM> on the CAN bus.

According to another example of the present disclosure, a method for the CAN module <NUM> is schematically illustrated in <FIG>, the method comprising the steps a) to e):.

The steps a) to e) may be performed in the shown order, but may also be performed at least partly in parallel or in another order. The same applies to the following embodiments of the method as well, also in terms of the further steps of the respective embodiment.

In one or more embodiments, the method as schematically illustrated in <FIG> may comprise the further steps f) to i):.

In one or more embodiments, the method as schematically illustrated in <FIG> may comprise the further steps j) to m):.

The CAN module <NUM> and methods described herein may at least partially be embodied by a computer program or a plurality of computer programs, which may exist in a variety of forms both active and inactive in a single computer system or across multiple computer systems. For example, they may exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats for performing some of the steps. Any of the above may be embodied on a computer-readable medium, which may include storage devices and signals, in compressed or uncompressed form.

The term "processing logic", "processor" or "processing unit" may refer to a data processing circuit that may be a microprocessor, a co-processor, a microcontroller, a microcomputer, a central processing unit, a field programmable gate array (FPGA), a programmable logic circuit, and/or any circuit that manipulates signals (analog or digital) based on operational instructions that are stored in a memory. The term "memory" may refer to a storage circuit or multiple storage circuits such as read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, Flash memory, cache memory, and/or any circuit that stores digital information.

Claim 1:
A Controller Area Network, CAN, module (<NUM>), comprising:
a receive data, RXD, input interface (<NUM>) configured to receive a RXD stream (<NUM>) from a CAN transceiver (<NUM>),
a RXD output interface (<NUM>) configured to send a manipulated receive data, MRXD, stream (<NUM>) to a CAN controller (<NUM>), and
a processing logic (<NUM>) configured to identify a first bit sequence (<NUM>) in the RXD stream,
wherein the processing logic is configured to identify a first position for a first stuff bit (<NUM>) in the first bit sequence,
wherein the processing logic is configured to manipulate the first bit sequence to generate a second bit sequence (<NUM>) comprising a second stuff bit (<NUM>) at a second position in the second bit sequence corresponding to the first position of the first stuff bit in the first bit sequence such that the second stuff bit is complementary to a preceding bit of the second stuff bit in the second bit sequence, and
wherein the CAN module is configured to send the second bit sequence via the RXD output interface to the CAN controller.