CAN over IP

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I found hints on google dating back to 1999 about a proposal for a
CAN-over-IP standard.  I was wondering, is there such a thing, do you
know of any implementations, or applications using this technique?  I
would find it utterly useful for testing things, but before I start to
re-invent the wheel, I would like to hear your opinions/links.

Also, I am sorry, if I have missed some obvious specs., or code out
there; I have tried not to.  :-)

Thanks in advance,
Andi.

Re: CAN over IP
Quoted text here. Click to load it

It does not make sense - CAN is not a protocol but a transport layer and IP
is a protocol.
Maybe you meant IP-over-CAN ? Although it also does not make too much sense
regarding
small data payload of CAN messages (up to 8 bytes in one transfer)...

- Dejan



Re: CAN over IP
Dejan schrieb:

Quoted text here. Click to load it

It does not make sense as an implementation for real applications, but
it's very nice for mere simulation purposes.  Think of it as a wrapper
around a low-level driver: I want all outgoing communication to the
driver end up as IP packets which can be received on a remote host.
Additionally, this could be handled in user space if I only write a
library doing exactly that, e.g., using the CANpie API.  However, I am
not looking for a CANopen library (or any other level 7 protocol) as I
really only want to wrap the low level calls by actual CAN applications
at hand.

Anyway, thanks for your answer,
Andreas.


Re: CAN over IP


Quoted text here. Click to load it

If CAN is a transport layer and since IP is a network
layer it could make sense. TCP/IP/Eternet for instance
provides a solution for a reliable transfer of data over
Ethernet in a point to point configuration.

TCP frames are encapsulated in IP frames and are delivered
to the TCP end points stripped from IP headers and tailers.

You could theoretically encapsulate CAN transport layer
frames in IP frames.


Re: CAN over IP

[...]
Quoted text here. Click to load it

I beleive that Heinz's last two sentences are paramount!  (IMHO) One of the
most important aspects of CAN is the arbitration inherent in the protocol.
The pseudo-random delay before retry built into IP is quite unlike CAN's
message priority resolution scheme:  competing IP messages are resolved via
a "roll of the dice" while competing CAN messages are resolved based upon
the lowest value'd message ID.  Random vs. Deterministic.

Otherwise, wrapping CAN messages in UDP datagrams is a good idea, and makes
a lot of sense for remote development.

TJL




Re: CAN over IP
Quoted text here. Click to load it

There is no retry built into IP.  What are you referring to here??  I don't
know CAN, but I do know IP, and it is a best-effort datagram protocol - NO
RETRIES.  Retries are done by upper layer protocols like TCP, but UDP doesn't
do retries either, and this thread is talking about CAN over UDP over IP.

Quoted text here. Click to load it

Again, I don't know what you're referring to here?  Where do you get "roll
of the dice"?

Quoted text here. Click to load it

Cool.

========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos                           Email: snipped-for-privacy@klos.com
    Klos Technologies, Inc.                Web:   http://www.klos.com /
==== I don't think infinity is as big as it seems - P.Klos, 20-Mar-2005 ====

Re: CAN over IP

Quoted text here. Click to load it

I presume in both instances he's talking about Ethernet
CSMA/CD.  Which, of course, has nothing to do with IP.

--
Grant Edwards                   grante             Yow!  My mind is making
                                  at               ashtrays in Dayton...
We've slightly trimmed the long signature. Click to see the full one.
Re: CAN over IP
On Sat, 9 Jul 2005 15:20:15 +0000 (UTC), snipped-for-privacy@osmium.mv.net (Patrick

Quoted text here. Click to load it

IP does not have a retry mechanism but the 10base2/5 MAC has the
nondeterministic retry mechanism if there is a collision. The problem
with Ethernet CSMA/CD is that _both_ messages are lost if there is a
collision and thus, _both_ messages must be retransmitted, thus
reducing the throughput.

Quoted text here. Click to load it

In CAN, the original high priority message will get through
uninterrupted, while the transmitter of the lower priority message
must back off until the high priority message has been completed and
then try to send the message. Thus, no throughput is lost due to
collisions, only the low priority messages as delayed by one or more
frame times.

The drawback is that each station must hear each other within a bit
time, thus limiting the data rate and/or distance quite rapidly. The
maximum specified transfer rate of CAN is 1 Mbit/s with a distance of
a few tens of meters, which is more than adequate for car/lorry
applications, but may be a bit short in industrial applications.

OTOH, 10base2/5 CSMA/CD Ethernet allows much greater distances, since
the propagation delay can be quite a few (hundred) bit times before
the collision is detected.  The distance throughput product is much
better, but unless you use 10/100/1000baseT point to point full duplex
connections, the connection is not very deterministic.

Paul
 

Re: CAN over IP
Quoted text here. Click to load it
[...]
Quoted text here. Click to load it

Sorry, I had TCP on my brain, you are, of course, correct - the IP/UDP won't
have retry, that's a function
of TCP.  My apologies.  There must be SOME retry policy enforced somethere,
though, right?

Quoted text here. Click to load it

I'm not sure if the throughput reduction will be an issue or not:  a
100baseT link certainly won't have a hard time swallowing ALL of a HS CAN
node's BW, even with the overhead required by UDP packets.

Quoted text here. Click to load it
via
"roll
Quoted text here. Click to load it

The "roll of the dice" was a reference to the retry delay mechanism for TCP,
the pseudo-random
delay between retransmits to "resolve" the collision.

Quoted text here. Click to load it

There is no question that CAN is very efficient when it comes to utilizing
the available BW.

The point of my concern (despite my voicing it in such a mangled way in my
post) is that CAN has an ORDERLY inherent mechanism for message priority
resolution; I don't believe this is the case with IP.  I would assume that
the easiest "fix" for this would be to simply throw much more IP BW (than
that of CAN) at the problem- simply make up for it with a really fast IP
link.

[...]
Quoted text here. Click to load it

In addition to greater distances, Ethernet also allows vastly cheaper
cabling, and far more network topology options.  To get CAN to work at 1Mbps
or even 500kpbs requires VERY careful attention to cabling (coax/twinax is
not unheard of, certainly shielded twisted pair at the very least) and the
physical routing, end terminations, etc.  In other words, it's pretty
fragile.  The act of adding/deleting nodes to/from a HSCAN network can
destabilize everything.  Bus loading becomes a real issue, so # of nodes is
limited.  Setting up the time quanta gets harder and harder with high
bitrates and a 'dynamic' bus.  A CAN <-> IP gateway would allow physical CAN
"subnets"to be interconnected with low cost 10b2 cabling.  Presumably, if it
were (physically) possible to keep the nodes that must exchange data in a
very real-time deterministic fashion linked with "real CAN" interconnects,
that might help the situation.

Thanks for the stimulating thoughts here!!

TJL



Re: CAN over IP
Quoted text here. Click to load it

No.  Not at the IP level.

Quoted text here. Click to load it

There is no such "pseudo-random delay between retransmits" in
TCP.  There is no concept of "collisions" in TCP.  Are you sure
you're not thinking of Ethernet CSMA/CD?

--
Grant Edwards                   grante             Yow!  Here I am at the flea
                                  at               market but nobody is buying
We've slightly trimmed the long signature. Click to see the full one.
Re: CAN over IP

[...]
Quoted text here. Click to load it
somethere,

I meant that in order for "CAN over IP" to work, there must be some sort of
retry policy.  Right?  Otherwise it's a missed message, and that's most
certainly NOT CAN-like behavior.

Quoted text here. Click to load it

At this point, I don't know WHAT I'm thinking of - burried within Ethernet
somewhere, at some level, there's the retry policy that has the random delay
for retry when it's been detected that two nodes are attempting to transmit
at the same time.  Please, I beg you, teach me - what level is this behavior
attributed to?

TJL



Re: CAN over IP
On Sun, 10 Jul 2005 13:04:48 GMT, "Tom LeMense"

Quoted text here. Click to load it

On a CAN network, there are only two situation, in which the
transmitter is automatically resending the frame.

- Every node on a CAN network listens to all messages regardless if
they are interested in a specific message or not. Each node that gets
a syntactically correct frame with correct CRC, will send a dominant
state during the ACK bit. From this the transmitter knows that the
transmitter is connected to a network that has at least one
operational node. If it does not get a dominant ACK bit, the
transmitter can assume that it is not connected to the network and
repeatedly resends the message, hoping that it will be connected a
network and the message will get through.

- If any node on the bus detects a syntax error or failed CRC, it will
jam the bus and the transmitter will resend the message.

These mechanisms do not guarantee a successful end to end delivery,
e.g. due to receiver congestion etc. If you need guaranteed delivery,
then some higher level protocol needs to be built above.

With this in mind, I do not see a need for some retry handling at the
UDP/IP level. If there is a high level protocol for guaranteed
delivery, this would operate just nicely over the UDP connections,
provided that all types of frames are handled, including RTR frames.

Paul
  

Re: CAN over IP
Quoted text here. Click to load it

Except it would be very difficult to do such a "retry"
mechanism, since there's no way for the sender of an IP
datagram to know if it was received incorrectly by somebody
unless you have all of the receiving stations send ACK/NACK
frames. That quickly turns into a nighmare.

Quoted text here. Click to load it

That's Ethernet, which is just one of the physical layers on
which IP is used.

--
Grant Edwards                   grante             Yow!  I'm working under
                                  at               the direct orders of WAYNE
We've slightly trimmed the long signature. Click to see the full one.
Re: CAN over IP
Quoted text here. Click to load it

That's a most excellent point, Grant!  NAK messages, ACK/NAK messages to NAK
messages...  Ugh.

Even if ACK/NAK message were sent, I have to imagine that the transparency
to the higher layers in the CAN node is gone -- e.g. node X sends out a
message, nodes W and Y receive it fine, but node Z gets bad CRC.  The
message is over though, and it's too late to do anything about it "on the
fly" as CAN does.  Node Z would have to send a NAK message, but that's a
seperate message, at best it could only say something like "hey, remember
that message that got sent earlier with message ID 123?  Well, I think it's
junk, so make sure that you ignore it.  Hey, everyone, did you hear me?  Let
me know if you did...."

Quoted text here. Click to load it

Thank you.  That makes all the sense in the world...pardon my ramblings.

So, putting these two points together; if one were to do CAN over IP atop
Ethernet, one would be stuck with pseudo-random retries upon detection of
collision.  I'm back to fearing that the orderly priority resolution of CAN
will be lost if Ethernet is used as the physical layer.

TJL



Re: CAN over IP
On Sun, 10 Jul 2005 02:45:53 GMT, "Tom LeMense"

Quoted text here. Click to load it

In a CAN network, each transceiver on the bus is listening to all
messages on the bus and performs the message syntax and CRC check. If
any transceiver detects something wrong with the frame, it "hijacks"
the frame by violating the syntax at he end of the frame. Every
station should detect this and no stations should get the frame. Since
also the transmitter detects that the frame structure is violated, it
can retransmit it automatically by the hardware.

Even without that mechanism, in a producer/consumer system with the
data producer sending data frames at a predefined rate, the consumer
would just wait for the next update, if one update was missing or
garbled. A timeout mechanism is needed to flag the last received data
as outdated, if no updates have arrived within a predefined time. So
there is no need for a retry mechanism with constant updates.
  
Quoted text here. Click to load it

The Ethernet collision detection mechanism requires that the frame is
long enough so that the collision can be sensed all over the network.
IIRC the minimum total frame length is 64 bytes with 46 payload bytes.
These payload bytes should be more than enough to contain the IP and
UDP headers and trailers as well as the up to 8 byte CAN data and 2-4
the CAN header bytes. Each CAN message would be mapped to 64 byte
(total) frames and at 10Base* the frame length would be 64 us, which
is about half of the 1 Mbit CAN frame time. Thus 10Base* could barely
handle the traffic, assuming no collisions. The 100BaseT should be
able to handle it more easily.
  
Quoted text here. Click to load it

I don't like the 1 Mbit/s speed due to the constrained timing, when
optoisolators are used between the transceiver and the CAN controller.
The 800 kbit/s speed is more tolerant and the loss of throughput is
quite marginal.

I have never heard that Twinax would have been used and I don't
understand how a single coaxial cable could be used to carry the
differential signal in a meaningful way.

The standard RS-485 wiring practice seems to be sufficient at least on
800 kbit/s.
 
Quoted text here. Click to load it

With the 10Base2 there are all kinds of bus topology, termination
restrictions and the use of the BNC T-connector does not help the
reliability.

10/100/1000BaseT are in practice limited to a star topology and
requires extra hardware to connect each node. In some cases Ethernet
hubs/switches would require to support a large temperature range and
tolerate hard environmental conditions.

In order to connect separate CAN subnets using Ethernet or fibers, in
order to be really useful, the gateways would have to be intelligent
enough to transfer only those messages that are needed in separate
subnets and also be able to reassign CAN-IDs to avoid addressing
conflicts. Unfortunately in a producer consumer system, it would be
quite hard for the gateway to learn which frames should be
transferred, so in practice some manual configuration would be
required to select CAN-IDs to transfer and also specify the CAN-ID
remap if needed.

Paul
    

Re: CAN over IP


Quoted text here. Click to load it

SafetyBus p which is a safety protocol over a CAN network
can now be extended over Ethernet through a gateway while
retaining its safety characteristics.
The study and development was performed at IAS Stuttgart.
No additional configuration is needed, the busload must be
less than 25% at 500kbps.
http://www.ias.uni-stuttgart.de/lehre/studien_diplomarbeiten/sada.php?s_id37%0#_aufgabe


Re: CAN over IP
Quoted text here. Click to load it

This is true, but that is not part of CAN _arbitration_, that's part of the
CAN bus error checking.  NO properly functioning node is capable of
attempting to begin a CAN message in the midst of one in progress!  ALL
nodes are 'busy' receiving the frame in process.  The error mechanism that
you're describing here is something that's typically encountered due to
degraded physical layer conditions: e.g. non-optimal quanta settings,
electrical disturbances on the bus, &c.

Quoted text here. Click to load it

Agreed - this is the typical CAN network implementation.  There's no "retry
due to collision" in CAN because there doesn't need to be one!  EVERY
message on the bus is arbitrated; if there's a low priorty (high ID #)
message queued up in one CAN node's transmit buffer somewhere, it will
simply wait there until it wins the arbitration (if ever).  That's really
the only case when a "missing message" occurs - not due to a collision,
simply due to a CAN bus that's heavily loaded with higher priority messages.
Or am I missing your point here?

Quoted text here. Click to load it

My estimate was more coarse, but I came to the same conclusion - 10b would
be too slow to envelop all but the most lightly loaded HSCAN busses.

Quoted text here. Click to load it
1Mbps
is
the
is

Agreed, 1Mbps is dicey at best - it's clearly bumping into the constraints
imposed by the CAN-compliant hardware requirements.  I've personally never
tried 800kbps.  Your statement about 800kbps coexisting nicely with RS-485
wiring practices is good information -- thank you!

Quoted text here. Click to load it

In the case of a high speed CAN network, Twinax is employed as a glorified a
shielded pair, just way more expensive and a real pain in the rear to
terminate.  ('terminate' in the physical sense: install connectors onto)
:-)  Not deployed for automotive AFAIK.

The signalling via (single conductor+shield) coax isn't differential - it's
very similar to 10Base2, atually.

Quoted text here. Click to load it

Oops, I meant to type "10bT" instead of "10b2"...

Quoted text here. Click to load it

Yes, I think that it'd be hard to find automotive grade hubs and switches!
But it certainly is possible to find these for industrial environments.
Even so, I don't think that a switch would help the anticpated latency
issues at all, either, right?

Quoted text here. Click to load it

I was thinking on a somewhat simpler scale; using the message ID filtering
in the CAN<->IP gate's CAN peripheral to handle which message ID's go out to
IP.  This assumes that message ID's within that subnet that were intended to
go out over IP were not too disjoint and therefore possible to setup
filtering in the CAN hardware for minimum latency.  Yes, this would be a
manual configuration, I don't see any way around that at all.  CAN over IP
wouldn't offer any magic solution to this:  A CAN network has to be
carefully 'architected' (physically and logically) no matter what.

Quoted text here. Click to load it

What do you mean by the words "CAN-IDs"?  Do you mean to say 'message IDs'?
[if not, please ignore the next paragraph]

I don't see any point in the notion of 'reassinging' or 'remap'-ing message
ID's.  CAN is intended to be a dataflow network; a message ID should NOT be
used to indicate an _intended recipient_, rather it should be used to
indicate _what sort of information_ that message is conveying.  There
shouldn't be any "addressing conflicts" because there's really no sense of
"address" in CAN.  Consider the case of two functionally identical yet
physically distinct nodes that, for example, measure and report temperature.
They should be using different CAN message ID's because they are reporting
the temperatures are of two different places, so messages from each node
should have different ID's just as a matter of course.

TJL



Re: CAN over IP
On Sun, 10 Jul 2005 14:32:47 GMT, "Tom LeMense"

Quoted text here. Click to load it

I am sorry if you got the impression that this mechanism would have
something to do with arbitration, this is error control.

Quoted text here. Click to load it

If you have a not so optimum topology, you could even end up into a
situation, in which one node gets the CRC right, but an other node due
to reflections get the CRC wrong, this node will then jam the last
bits and all other nodes as well as the transmitter should detect this
error condition.

Quoted text here. Click to load it

It should be remembered that in early days of the CAN bus, ordinary
RS-485 transceivers were used by connecting the transmitter input to a
constant "0" state and connecting the data into the transmitter enable
pin, thus driving the transmitter into dominant state only and let the
fail-safe termination handle the recessive state.

Quoted text here. Click to load it

Remapping can be handy if existing subnets are connected to a larger
system. If the individual subnets are configured independently of each
other, there might very well be overlapping assignments. Solving such
conflicts or rearranging local/foreign message arbitration priorities
could also be handy.

Paul
  

Re: CAN over IP
On Fri, 8 Jul 2005 14:00:42 +0000 (UTC), Andreas Bauer

Quoted text here. Click to load it

It is hard for me to imagine how the dominat/recessive state could be
implemented using Ethernet (with RS-485 that would be simple).

However, if you have a high level protocol that could use either CAN
bus or Ethernet as the physical transfer protocol. In that case
DeviceNet and Ethernet/IP might be usable keywords for a search.

Paul
 

Site Timeline