Multiplex communications – Duplex – Transmit/receive interaction control
Reexamination Certificate
1999-12-14
2003-11-25
Hsu, Alpus H. (Department: 2665)
Multiplex communications
Duplex
Transmit/receive interaction control
C370S466000, C370S469000, C370S474000
Reexamination Certificate
active
06654355
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention pertains to the field of network communication. More particularly, the present invention pertains to enabling communication between two or more controller area network (CAN) nodes of different CAN networks connected by a network implementing transmission control protocol/Internet protocol (TCP/IP), such as the Internet or an Ethernet.
2. Description of Related Art
A recent innovation in local area networks is the Control Area Network (CAN) standard, the basic level of which is identified in ISO 11898 and ISO 11519-1. The CAN standard was originally developed to specify distributed real-time control system requirements in automotive applications. An implementation according to the CAN standard is a real-time, distributed control system including different electronic components that communicate with each other not by signals carried by dedicated wires, but by signals conveyed by a linear bus according to the CAN protocol. Manufacturers such as Intel, Phillips, National Semiconductor, Nippon Electric Company, Siemens and Motorola provide very low cost CAN chips that conform to the protocol. The use of CAN technology has been extended to other custom applications, including industrial control applications.
As shown in
FIG. 1
, a CAN-type network
11
a
provides for communication of pre-determined messages between stations
12
a
(nodes of the CAN network, each of which are a control unit) interconnected in a linear bus structure by a CAN bus
14
a
. Each CAN station is the peer of every other station. Instead of addressing a message to another station by indicating the other station, a transmitting station indicates to all other stations the content of the message using an identifier provided with the message. In such content-based addressing, each message is broadcast to all other, receiving stations, and each receiving station discards the message unless the message is on a pre-determined acceptance list for the receiver.
There are now two versions of CAN, differing in the length of the identifier. A CAN implementation according to the CAN specification, part A, uses an 11-bit identifier. One according to the CAN specification, part B, uses a 29-bit identifier. See
CAN Specification, Version
2.0, by Robert Bosch GmbH, Postfach 50, D-7000 Stuttgart 1.
Any station of a CAN network can use the CAN bus to transmit (broadcast) a message when the bus is unoccupied. While transmitting a message, a station monitors the bus for an indication that another station is also attempting to transmit a message. If another station is also attempting to use the bus, the contention for the bus is arbitrated using a scheme in which each message is pre-assigned a priority that accompanies the message.
Message transfer in a CAN-type network is achieved using four types of frames. A data frame, as shown in
FIG. 2
, conveys data from a transmitter station to receiver stations, and has an identifier (of different length depending on the version of CAN, as described above) that indicates the type of message, i.e. its content, used for content-addressing. A remote frame, as shown in
FIG. 3
, conveys a request for a data frame having an identifier that is the same as used in the remote frame. A remoter frame uses a remote transmission request (RTR) bit to identify itself, i.e. to indicate that it is a request for a CAN message. An error frame, as shown in
FIG. 4
, is transmitted by any station when the station detects a communication (bus) error, i.e. when the station receives a message but the cyclic redundancy check (CRC) for the message fails. An overload frame (not shown), is used to provide extra delay between data frames or remote frames, a delay that is in addition to the interfame spacing (FIG.
2
).
Various application layers have been developed with specifications specifically oriented to industrial and process control applications, control networks for heavy duty trucks and buses, distributed control systems and control networks for cars. However, all of these systems are limited to inter-node communication, and will not support communicating with nodes across an intervening network using a different protocol, such as TCP/IP, which is used for communication on the Internet.
What is needed is a device that enables communication between stations of two different CAN-type networks interconnected by an intervening network, and especially an intervening network using TCP/IP, such as the Internet. Such a device would have to overcome the difficulty that a TCP/IP network uses physical addressing, while a CAN network uses content-based addressing, as indicated above.
What is also needed is a way to view the content of messages being communicated in a CAN-type network using a remote computer interconnected to the CAN-type network via an intervening network using TCP/IP, such as the Internet. This would allow both monitoring a CAN-type network and also diagnosing problems for the CAN-type network, all from a remote location.
SUMMARY OF THE INVENTION
Accordingly, the present invention provides a method and corresponding apparatus for communicating a controller area network (CAN) message between a sending node, attached to a sending CAN network, and a receiving node; where the sending and receiving nodes are interconnected by a network communicating according to transmission control protocol/Internet protocol (TCP/IP); where the CAN message includes a CAN message payload, which in turn includes an identifier field, intended to identify the content of the CAN message, based on a pre-determined identifier-content correspondence that is CAN-network-dependent or, more generally, node-dependent, a remote transmission request bit, a control field, and a data field, if any; and where the communicating is according to TCP/IP performed by transmitting TCP/IP frames, including a header, a footer, and a TCP/IP data field. The invention provides for having the sending node extract the CAN message payload from the CAN message; having the sending node embed the CAN message payload in the TCP/IP frame as the TCP/IP data field of the TCP/IP frame; having the sending node refer to a routing form to determine the address on the TCP/IP network of the receiving node; and
having the sending node transmit the TCP/IP frame over the TCP/IP network using the address for the receiving node from the routing form.
In a further aspect of the invention, the receiving node extracts the CAN message payload from the TCP/IP frame;
alters the identifier of the CAN message payload, as needed, so as to correspond to the CAN message content at the receiving node, the altering performed by reference to a mapping relating identifiers according to their usage at different network addresses; and, if the receiving node is attached (directly connected) to a CAN network, having the receiving node broadcast the CAN message on the CAN network to which it is directly connected. If the receiving node hosts a browser, there is no broadcasting of the received CAN message payload, but only a displaying of the CAN message by the browser for examination by the user of the browser.
REFERENCES:
patent: 5732074 (1998-03-01), Spaur et al.
patent: 6292862 (2001-09-01), Barrenscheen et al.
patent: 6434156 (2002-08-01), Yeh
patent: 1197396 (2002-04-01), None
patent: 1233577 (2002-08-01), None
Stevens, W. Richard, “TCP/IP Illustrated, vol. 1”, 1994, Addison Wesley, pp. 9-10.*
Eltze, Jens, “Double-CAN Controller as Bridge for Different CAN Networks”, 1997, NEC Electronics*
Ekiz, Kutlu, Baba, and Powner, “Performance Analysis of a CAN/CAN Bridge”, 1996, University of Sussex School of Engineering.*
Ekiz, Kutlu, and Powner, “Design and Implementation of a CAN/CAN Bridge”, 1996, University of Sussex School of Engineering.*
“CAN Specification, Version 2.0,” R. Bosch GmbH, pp. 1-68, Sep. 1991.
“The CAN Protocol,” downloaded from http://www/kvaser.com/can/protocol, downloaded on Aug. 30, 1999; copyright 1998, 2 pp.
“ISACAN-PC-The Hitex intelligent CAN interface for PCs,” Hitex Automation Engineering,
Langer Wolfgang
Marbach Alain
Femal Michael J.
Golden Larry I.
Hsu Alpus H.
Molinari Michael
Schneider Automation Inc.
LandOfFree
Bridge for CAN to TCP/IP connection does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Bridge for CAN to TCP/IP connection, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Bridge for CAN to TCP/IP connection will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3138737