CAN over IP

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.

Reply to
Andreas Bauer
Loading thread data ...

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

Reply to
Dejan

Dejan schrieb:

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.

Reply to
Andreas

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.

Reply to
Lanarcam

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

Reply to
Tom LeMense

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

Reply to
Paul Keinanen

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.

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

Cool.

========= For LAN/WAN Protocol Analysis, check out PacketView Pro! ========= Patrick Klos Email: snipped-for-privacy@klos.com Klos Technologies, Inc. Web:

formatting link
==== I don't think infinity is as big as it seems - P.Klos, 20-Mar-2005 ====

Reply to
Patrick Klos

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...
 Click to see the full signature
Reply to
Grant Edwards

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.

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

Reply to
Paul Keinanen
[...]

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?

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.

via

"roll

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.

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.

[...]

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

Reply to
Tom LeMense

No. Not at the IP level.

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
 Click to see the full signature
Reply to
Grant Edwards

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.

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.

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.

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

Reply to
Paul Keinanen

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.

formatting link

Reply to
Lanarcam

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.

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

Reply to
Tom LeMense

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.

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?

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.

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!

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.

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

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?

I was thinking on a somewhat simpler scale; using the message ID filtering in the CANIP 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.

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

Reply to
Tom LeMense

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

Reply to
Paul Keinanen

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.

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
 Click to see the full signature
Reply to
Grant Edwards

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

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.

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.

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

Reply to
Paul Keinanen

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...."

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

Reply to
Tom LeMense

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.