System and method for tunneling standard bus protocol messages through an automotive switch fabric network

A system and method for tunneling standard bus protocol messages through an automotive switch fabric network. When a bus protocol message arrives on a connecting node in the network, a bus driver in the node will capture the message and store it into a message buffer where the message can be further processed by a tunneling application. Each received bus protocol message will be broken, or combined, to suit the available packet size of the underlying transmit layer of the switch fabric network. Data portions such as message identification, sequence number, port number, bus data type, and data length are reserved in each data packet. If the message is being broken down, the sequence number is used to differentiate the broken segments of the bus protocol message. The bus data type is used to indicate the type of protocol data being transmitted over the switch fabric. The same tunneling application may be used to reassemble the bus protocol message at a receiving node.

FIELD OF THE INVENTION

This invention in general relates to in-vehicle communication networks and particularly to a system and method for tunneling standard bus protocol messages through an automotive switch fabric network.

BACKGROUND OF THE INVENTION

The commonly assigned U.S. patent application entitled “Vehicle Active Network,” Ser. No. 09/945,581, filed Aug. 31, 2001, Publication Number US 20030043793, the disclosure of which is hereby expressly incorporated herein by reference, introduces the concept of an active network that includes a switch fabric. The switch fabric is a web of interconnected switching devices or nodes. The switching device or nodes are joined by communication links for the transmission of data packets between the switching devices or nodes. Control devices, sensors, actuators and the like are coupled to the switch fabric, and the switch fabric facilitates communication between these coupled devices.

The coupled devices may be indicator lights, vehicle control systems, vehicle safety systems, and comfort and convenience systems. A command to actuate a device or devices may be generated by a control element coupled to the switch fabric and is communicated to the device or devices via the switch fabric nodes.

In the context of vehicular switch fabric networks, a challenge is presented in terms of connecting the switch fabric network to standard or legacy bus architectures such as the Controller Area Network (CAN) protocol, the SAE J1850 Communications Standard, the Local Interconnect Network (LIN) protocol, the FLEXRAY Communications System Standard, the Media Oriented Systems Transport or MOST Protocol, or similar bus structures. A need exists for switch fabric networks to operate seamlessly with the standard bus architectures and for switch fabric networks to handle message protocols associated with these standard bus architectures.

It is, therefore, desirable to provide a system and method to overcome or minimize most, if not all, of the preceding problems especially in the area of tunneling standard bus protocols across the nodes in an automotive switch fabric network.

DETAILED DESCRIPTION

What is described is a system and method for tunneling standard bus protocol messages through an automotive switch fabric network. In sum, when a bus protocol message arrives on a connecting node in the network, a bus driver in the node will capture the message and store it into a message buffer where the message can be further processed by a tunneling application. The tunneling application periodically checks if there are any new bus protocol messages coming from a port connected to the bus. Each received bus protocol message will be broken, or combined, to suit the available packet size of the underlying transmit layer of the switch fabric network. Data portions such as message identification, sequence number, port number, bus data type, and data length are reserved in each data packet. If the message is being broken down, the sequence number is used to differentiate the broken segments of the bus protocol message. The bus data type is used to indicate the type of protocol data being transmitted over the switch fabric. The same tunneling application may be used to reassemble the bus protocol message at a receiving node.

Now, turning to the drawings,FIG. 1illustrates a vehicle20including a network22to which various vehicle devices24a-fare coupled directly via interfaces26a-band coupled indirectly via legacy buses A, B. The vehicle devices24a-fmay be sensors, actuators, and processors used in connection with various vehicle functional systems and sub-systems, such as, but not limited to, diagnostic, control-by-wire applications for throttle, braking and steering control, adaptive suspension, power accessory control, communications, entertainment, and the like. The vehicle devices24a-fis particularly adapted to provide one or more functions associated with the vehicle20. These vehicle devices24a-fmay be data producing, such as a sensor, data consuming, such as an actuator, or processing, which both produces and consumes data.

The interfaces26a-bare any suitable interface for coupling the particular vehicle device24a-bto the network22, and may be wire, optical, wireless or combinations thereof. The standard buses A and B may include one or more legacy communication media, i.e., legacy bus architectures such as the Controller Area Network (CAN) protocol, the SAE J1850 Communications Standard, the Local Interconnect Network (LIN) protocol, the FLEXRAY Communications System Standard, the Media Oriented Systems Transport or MOST Protocol, or similar bus structures. In this embodiment, the standard buses A and B are configured to permit communication between the network22and devices24c-f.

The network22may include a switch fabric28defining a plurality of communication paths between the vehicle devices24a-f. The communication paths permit multiple simultaneous peer-to-peer, one-to-many, many-to-many, etc. communications between the vehicle devices24a-f. During operation of the vehicle20, data exchanged, for example, between devices24aand24bmay utilize any available path or paths between the vehicle devices24a,24b. In operation, a single path through the switch fabric28may carry all of a single data communication between one vehicle device24aand another vehicle device24b, or several communication paths may carry portions of the data communication. Subsequent communications may use the same path or other paths as dictated by the then state of the network22. This provides reliability and speed advantages over bus architectures that provide single communication paths between devices, and hence are subject to failure with failure of the single path. Moreover, communications between other of the devices24c,24fmay occur simultaneously using the communication paths within the switch fabric28.

Referring toFIG. 2, for purposes of illustration, an active network22in accordance with one embodiment includes a switch fabric28of nodes30a-hthat communicatively couples a plurality of devices24a-fvia legacy buses A, B and interfaces26a-b. Connection links or media32interconnects the nodes30a-h. The connection media32may be bounded media, such as wire or optical fiber, unbounded media, such as free optical or radio frequency, or combinations thereof. In addition, the term node is used broadly in connection with the definition of the switch fabric28to include any number of intelligent structures for communicating data packets within the network22without an arbiter or other network controller and may include: switches, intelligent switches, routers, bridges, gateways and the like. Data is carried through the network22in data packet form guided by the nodes30a-h.

The cooperation of the nodes30a-hand the connection media32define a plurality of communication paths between the devices24a-fthat are communicatively coupled to the network22. For example, a route34defines a communication path from a first node30ato a second node30g. If there is a disruption along the route34inhibiting communication of the data packets from the first node30ato the second node30g, for example, if one or more nodes are at capacity or have become disabled or there is a disruption in the connection media joining the nodes along route34, a new route, illustrated as route36, can be used. The route36may be dynamically generated or previously defined as a possible communication path, to ensure the communication between the first node30aand the second node30g.

The network22may comply with transmission control protocol/Internet (TCP/IP), asynchronous transfer mode (ATM), Infiniband, RapidIO, or other packet data protocols. As such, the network22utilizes data packets, having fixed or variable length, defined by the applicable protocol. For example, if the network22uses asynchronous transfer mode (ATM) communication protocol, ATM standard data cells are used.

FIG. 3illustrates several data packet configurations that may be used in connection with switch fabric networks according to the embodiments of the present invention. As described, the network22may be configured to operate in accordance with TCP/IP, ATM, RapidIO, Infiniband and other suitable communication protocols. These data packets include structure to conform to the standard required. In one embodiment, a data packet for this invention may include a data packet200having a header portion202, a payload portion204, and a trailer portion206. As described herein, the network22and the nodes30a-hforming the switch fabric28may contain processing capability. In that regard, a data packet210includes along with a header portion212, payload portion214, and trailer portion216an active portion218. The active portion218may cause the network element to take some specific action, for example providing alternative routing of the data packet, reconfiguration of the data packet, reconfiguration of the node, or other action, based upon the content of the active portion218. The data packet220includes an active portion228integrated with the header portion222along with a payload portion224and a trailer portion226. The data packet230includes a header portion232, a payload portion234and a trailer portion236. An active portion238is also provided, disposed between the payload portion234and the trailer portion236. Alternatively, as shown by the data packet240, an active portion248may be integrated with the trailer portion246along with a payload portion244and a header portion242. The data packet250illustrates a first active portion258and a second active portion260, wherein the first active portion258is integrated a header portion252and the second active portion258is integrated with the trailer portion256. The data packet250also includes a payload portion254. Other arrangements of the data packets for use with the present invention may be envisioned.

The active portion of the data packet may represent a packet state. For example, the active portion may reflect a priority of the data packet based on aging time. That is, a packet initially generated may have a normal state, but for various reasons, is not promptly delivered. As the packet ages as it is routed through the active network, the active portion can monitor time since the data packet was generated or time when the packet is required, and change the priority of the data packet accordingly. The packet state may also represent an error state, either of the data packet or of one or more nodes of the network22. The active portion may also be used to messenger data unrelated to the payload within the network22, track the communication path taken by the data packet through the network22, provide configuration information (route, timing, etc.) to nodes30a-hof the network22, provide functional data to one or more devices24a-dcoupled to the network22or provide receipt acknowledgement.

The payload portion of the data packets carries data and other information relating to the message being transmitted through the network22. The size of the data packet (including the payload portion) will be constrained by the physical layer on which the switch fabric28is built. There are situations where the message size at the application layer will be larger than the packet size allowed to be transmitted over the network22. One situation, as described in more detail below, is where standard bus protocol messages need to be transmitted through the switch fabric28. Accordingly, in one embodiment of the present invention, a message in the application layer that is larger than the packet size of the network22will be broken into smaller units to fit the packet size limitation. Each unit is placed into an individual data packet and transmitted independently over the switch fabric28to a destination node. At the destination node, the individual data packets are reassembled to its original form and passed to the application that receives and processes the message.

Referring toFIG. 4, to illustrate the functionality and the adaptability of a node30a-hin the switch fabric28, in one embodiment, a node30a-hmay have a plurality of input/output ports50a-dalthough separate input and output ports could also be used. Various configurations of the node30a-hhaving more or fewer ports may be used in the network22depending on the application. The nodes30a-hmay include a processor52, at least one transceiver54, and a memory56. The processor52is configured to execute instructions from software components residing in the memory56. Although the processor52and memory56are shown to be integrated with the node, in other applications, the process52and memory56may be located at other places in the switch fabric28. The memory56contains a set of software components to operate the nodes30a-hfor normal data communications and operation within the switch fabric28.

For nodes30a,30c,30e,30gthat are connected to a legacy bus A, B, the node may further have a bus driver, a tunneling application, and a message buffer to store and transmit messages through the switch fabric28. For instance, when a bus protocol message arrives on a connecting node30a,30c,30e,30g, the bus driver will capture the message and store it into the message buffer where the message can be further processed by the tunneling application. The features of the tunneling application are described in more detail below. The tunneling application periodically checks if there are any new bus protocol messages coming from the port connected to the legacy bus A, B. As will be explained further below, in one embodiment, each received bus protocol message will be broken, or combined, to suit the available packet size of the underlying transmit layer of the switch fabric network28. Data portions such as message identification, sequence number, port number, bus data type, and data length are reserved in each data packet. If the message is being broken down, the sequence number is used to differentiate the broken segments of the legacy bus protocol message. The bus data type is used to indicate the type of bus data being transmitted over the switch fabric28. The same tunneling application may be used to reassemble the bus protocol message at a receiving node.

To explain these features further, the embodiment ofFIGS. 1 and 2includes applications where the switch fabric28is connected to devices24c-fthrough one or more standard or legacy buses A, B. For ease of transition from traditional bus architecture to the switch fabric architecture described above, it is important for the switch fabric28to be able to operate seamlessly with current bus protocols. For purposes of illustrating the present invention, assume that the legacy bus A operates in accordance to the Controller Area Network (CAN) protocol and that the legacy bus B operates in accordance to the SAE J1850 Communications Standard. One of ordinary skill in the art having the benefit of this disclosure will realize that other legacy buses may be used including the Local Interconnect Network (LIN) protocol, the FLEXRAY Communications System Standard, the Media Oriented Systems Transport or MOST Protocol, or similar bus structures. The CAN protocol and the SAE J1850 Communications Standard will be used for illustration purposes.

The CAN protocol is an international standard that is based on a message oriented transmission protocol. The CAN protocol supports two message frame formats, a CAN base frame and a CAN extended frame, as will be described further below. Referring toFIG. 5, a CAN frame message300begins with a start of frame portion302, containing a start bit, and ends with an end of frame portion314. Between the start of frame portion302and the end of frame portion314, the main fields of a typical CAN frame message300includes an arbitration field304, a control field306, a data field308, a cyclic redundant check (CRC) field310, and an acknowledge field312. The arbitration field304consists of an identifier and a remote transmission request bit. The length of the identifier (and the size of the arbitration field) will vary depending on whether the CAN frame message is a CAN base frame or a CAN extended frame. The CAN base frame supports a length of 11 bits for the identifier and the CAN extended frame supports a length of 29 bits for the identifier. The remote transmission request bit is used to distinguish between a data frame and a data request frame called a remote frame.

The control field306of the CAN frame message300contains an identifier extension bit that distinguishes between the CAN base frame and the CAN extended frame. The control field306of a CAN frame message300also contains a Data Length Code (DLC) that is used to indicate the number of following data bytes in the data field. If the message is used as a remote frame, the DLC contains the number of requested data bytes.

The data field308of the CAN frame message300is configured to hold up to 8 data bytes. After the data field308, the CAN frame message300has a CRC field310that contains a cyclic redundant check sum. The cyclic redundant check sum allows for errors to be checked for the incoming CAN frame message300. The acknowledge field312includes an acknowledge slot and an acknowledge delimiter. The acknowledge field312is used by a receiving device to acknowledge whether data is received correctly.

The SAE J1850 Communications Standard is an international standard that is also based on a message oriented transmission protocol. The J1850 protocol supports two systems, a 41.6 kb/s Pulse Width Modulation (PWM) scheme and a 10.4 kb/s Variable Pulse Width (VPW) scheme. The VPW will be discussed for purposes of illustrating a message under the J1850 protocol. Referring toFIG. 6, a J1850 frame message400operating under the VPW scheme begins and ends with pre-defined periods called a start of frame portion402and an end of frame portion414. Between the start of frame portion402and the end of frame portion414, the main fields of a typical J1850 message includes a header field404, a data field408, a cyclic redundant check (CRC) field410, and an in-frame response412. The header field304may be one to three bytes and include bits for information such as message priority, size of header, whether an in-frame response is requested, addressing mode, and message type.

The data field408of the J1850 message400is configured to hold up to 8 data bytes. After the data field408, the J1850 message400has a CRC field410that contains a cyclic redundant check sum. The cyclic redundant check sum allows for errors to be checked for the incoming J1850 message400.

The in-frame response412provides a mechanism for devices that receive SAE J1850 frame messages to acknowledge receipt. A bit in the header field304, mentioned above as an in-frame response bit, triggers the device receiving the frame message to append a reply to the end of the transmitting devices original frame message. This provides for efficient communications in that device receiving the message may respond within the same message frame as the original frame message.

The present invention allows the nodes30a-hto be connected to different types of legacy bus protocols and tunnel the legacy bus protocol message through the switch fabric28. The present invention advantageously allows for a modular concept and permits nodes30a-hto be connected to a variety of bus architectures. In one embodiment of the present invention, legacy bus protocol messages (such as the CAN frame message300and the J1850 message400) are tunneled through the switch fabric28protocol by dividing the messages into two or more separate units or data packets for transmission over the switch fabric28. As described inFIG. 3, the switch fabric28protocol may transmit a variety of data packets having specific header portions, payload portions, and trailer portion.

For purposes of illustrating the present invention, assume that the switch fabric28ofFIGS. 1 and 2use data packets such as the data packet200shown inFIG. 3having a header portion202, a payload portion204, and a trailer portion206. This data packet200does not include an active portion although an active portion may also be included (such as those shown inFIG. 3as data packets210,220,230,240,250). Also assume that in one embodiment that the payload portion204of switch fabric28is limited to 8 bytes.

In this embodiment, as shown inFIG. 6, a legacy bus protocol message (such as the CAN frame message300and the J1850 message400) may be divided into at least two separate data packet messages having a first payload portion204aand a second payload portion204b. In particular, in one embodiment, the payload portion204of the data packets200may be divided into a message identification portion260, a sequence number portion262, a control portion264, and a plurality of data elements266-276. Although the exact fields and the division of the number of bytes and bits may vary, in one example, the message identification portion260may include 11 bits, the sequence number portion262may include 1 bit, the control portion264may include 4 bits, and the data elements266-276may be each 1 byte.

The message identification portion260for each of the payload portions204a,204bwill contain a unique message identification assigned to the particular legacy bus message (for example, the CAN frame message300or the J1850 message400). The message identification within the portion260will be the same for all payload portions204a,204bthat are common to the same legacy bus message. The message identification is used by the nodes30a-hto track the received data packets so that it can associated different payload portions204a,204bwith the same legacy bus message.

The sequence portion262contains a sequence number associated with the payload portions204a,204b. The bit(s) for the sequence number portion262in each payload portions204a,204bwill be different. The bits in the sequence number portions262are be used by the nodes30a-h(in conjunction with the message identification) to group the received data packets so that it can re-assemble the legacy message in the correct order.

The control portion264contains information that identifies information pertaining to the particular legacy bus protocols and any other information that may help the data packet to route the data packet200to the correct destination node. For instance, the control portion264of the first payload portion204amay include an identification of the tunneling protocol (TP) such as whether the received bus message relates to the Controller Area Network (CAN) protocol, the SAE J1850 Communications Standard, the Local Interconnect Network (LIN) protocol, the FLEXRAY Communications System Standard or similar bus structures. The control portion264of the first payload portion204amay also include a port number (Port #) to help route the data packets200to the correct destination. As mentioned above inFIG. 4, the nodes30a-hhave a plurality of the input/output ports50a-dthat interconnect one node to other nodes. The control portion264of the second payload portion204amay also include information regarding the length of data in the data field of the legacy bus protocol message. For example, the CAN bus protocol includes a Data Length Code (DLC) that can be used to indicate the number of data bytes in the data field.

The plurality of data elements266-276in the first payload portion204awill contain any remaining portions specific to the legacy bus protocols as well as the data elements in the data fields308,408of the legacy bus messages300,400. For instance, as shown inFIG. 8, for the CAN frame message300, some of the data elements266-272in a first payload portion284amay contain the bytes in the arbitration field304of the CAN frame message300. The other data elements274-276may contain a first portion of the data elements in the data field308of the CAN frame message300. The data elements266-276in a second payload portion284bmay contain a second portion of the data elements in the data field308of the CAN frame message300.

On the other hand, as shown inFIG. 9, for the J1850 message400, some of the data elements266in a first payload portion294amay contain the byte(s) in the header field404of the J1850 message400. The other data elements268-276may contain a first portion of the data elements in the data field408of the J1850 message400. The data elements266-276in a second payload portion294bmay contain a second portion of the data elements in the data field408of the J1850 message400.

In a further embodiment, the present invention includes a mechanism for handling acknowledgments used in some legacy buses such the in-frame responses used in the J1850 frame message described above. Referring toFIG. 10, assume that a message needs to be transmitted from a first device24cand tunneled through the switch fabric28(nodes30a,30c) to a second device24e. As mentioned above, if the in-frame response bit is set in the header field304of the J1850 frame message300, the transmitting device24cwill expect an in-frame response from the receiving device (here, node24e).

In one embodiment, the first device24cwill broadcast an original J1850 frame message over the data bus A that interconnects the first device24cand the first node30a(arrow502). The J1850 frame message may have a format similar to the frame message400described inFIG. 6. The first node30awill receive the frame message400and recognize that it needs to be tunneled through the switch fabric28. As explained above, the first node30amay divide the message into two or more data packets that includes payload portions294a,294b(example payload portions are shown inFIG. 9). The divided messages may then be forwarded through the switch fabric28to the second node30c(arrow504). The second node30cwill receive the messages and reassemble payload portions294a,294bback into the original J1850 frame message400transmitted by the first device24c. The second node30cmay then broadcast the message over the data bus B that interconnects the second node30cto the second device24e(arrow510), assuming in this embodiment that the data bus B also operates in accordance to the SAE J1850 Communications Standard.

An issue that may arise during the above-described tunneling operation is that the first device24cmay have set a bit in the header field304, mentioned above as an in-frame response bit, that requires the second device24eto reply with a response. The first node30amay not know the correct in-frame response at the time the original frame message400is seen at the first node30a. The present invention solves this issue by including an application in the first device24cthat includes a retry strategy. Additionally, the method includes configuring the first node30a, upon receipt of the original message300, to reply with a null or invalid response (arrow508). The first device24cwill see the null or invalid response and initiate the retry strategy. Meanwhile, after the second device24ereceives the reassembled frame message300, it will insert the correct in-frame response over the bus interconnecting the second device24eto the second node30c(arrow512). The second node30cwill then tunnel the in-frame response via data packets to the first node30a(arrow514). The retry strategy includes a process that allows the first device24cto broadcast a retry message, after a predetermined period, to the first node30a(arrow508). This will allow the first node30ato then insert the correct in-frame response when it receives the retry message (arrow516).

What has been described is a system and method for tunneling legacy bus protocols or other bus architecture data through an automotive switch fabric network. This is particular useful in transitioning traditional bus architectures to an automotive switch fabric network. In sum, when a bus protocol message arrives on a connecting node in the network, a bus driver in the node will capture the message and store it into a message buffer where the message can be further processed by a tunneling application. The tunneling application periodically checks if there are any new bus protocol messages coming from the port connected to the bus. Each received bus protocol message will be broken or combined to suit the available packet size of the underlying transmit layer of the switch fabric network. Data portions such as message identification, sequence number, port number, bus data type, and data length are reserved in each data packet. If the message is being broken down, the sequence number is used to differentiate the broken segments of the bus protocol message. The bus data type is used to indicate the type of bus data being transmitted over the switch fabric. The same tunneling application may be used to reassemble the bus protocol message at a receiving node. The above description of the present invention is intended to be exemplary only and is not intended to limit the scope of any patent issuing from this application. The present invention is intended to be limited only by the scope and spirit of the following claims.