Concept: CANBus to ethernet "bridge"

[yyrkoon 250]

How many people would find a canbus to ethernet "bridge" in hardware / software useful ? Hardware would initially be for the beaglebone black + logic supply serial/cancape. But perhaps could later be made to work with hardware that already has socketcan support. Such as the Microchip MCP2515, and perhaps another embedded Linux / RTOS platform.

 

The Idea  would simply be to make an initially small framework or library( wrapper? ) based off of socketcan, and Unix TCP sockets. Then simply read the canbus, and put the frame data out over a tcp socket. Later, perhaps add in some configuration options, and write over tcp sockets to the socketcan interface.

 

I can think of all kinds of use cases  for such a framework. Ranging from what I've been doing already, to canbus troubleshooting / network design.

 

My reasoning for such a project is in part fairly simple. What I've been doing lately on the beaglebone black + logic supply serial/cancape is very niche. Not much use for many other people. But I suspect that if I make the project more modular. That many more people could get use out of parts of the project I'm working on.

 

One of the thoughts that crossed my mind recently is that I could *potentially* turn such a project into a professional classed CANBUs monitoring / development system. By "professional classed", I mean one that could compete with current hardware / software system already on the market. But not necessarily be sold as one.

 

I'd love to hear what other people think about this concept.

[spirilis 1,265]

Doesn't seem too sensible to me. What CAN-only stuff would you have that needs its frames sent over ethernet? For new projects why not use ethernet natively?

[igor 163]

Doesn't seem too sensible to me. What CAN-only stuff would you have that needs its frames sent over ethernet? For new projects why not use ethernet natively?

 

Wouldn't it make something like remotely controlling vehicles easier?  Chevrolet's ethernet to CAN bridge seems very ad-hock. 

http://hackaday.com/2015/08/22/how-those-hacker-took-complete-control-of-that-jeep/

 

I do not think that connecting cars to networks is sensible, however there is a big push to do that.  I do not have a need for such a bridge, but I can see where it could be useful for those experimenting with V2V, etc.

http://hackaday.com/2015/09/02/v2v-means-safer-roads/

 

Seems like a really strong firewall/packet sanitizer/saneitizer should be part of such a device, since CAN buss often local/may not make robust assumptions about insecurity and misbehaving agents.

[yyrkoon 250]

Doesn't seem too sensible to me. What CAN-only stuff would you have that needs its frames sent over ethernet? For new projects why not use ethernet natively?

Sorry for the late reply. didn't know anyone responded . . . What I propose has nothing to do with ethernet per se. Except that ethernet is actually a well established network medium. In fact, you could use wifi, or bluetooth, it does not matter. However, what I propose will be using the Linux socket API, so the transport method used will need to be some sort of network interface - On the remote end.

 

Have you looked up pricing on CANBUS test equipment, and software ? it's pretty expensive. . . 

 

By the way, this would not be something to put on a car . . . Unless you simply want to log data, or test a new CAN device. CANBUS is used in way more things than just cars. Boats, military equipment, Alternative energy equipment. Just to name 3.

[yyrkoon 250]

Seems like a really strong firewall/packet sanitizer/saneitizer should be part of such a device, since CAN buss often local/may not make robust assumptions about insecurity and misbehaving agents.

send() would have to be implemented in order for that to be a problem. With that said, I'm not sure I see how that would be a concern in a test environment. This is not some alternative for communications. What I propose is an alternative to spending large amounts of monies on ridiculously priced test equipment.

[yyrkoon 250]

Something else that I did not think to mention earlier. Wireshark, and the console version of wireshark( I never remember the name . .  ) can both be made to read, display / inspect CANBUS frames. J1939 too I believe. So think of this as a poor man's alternative to canbus test equipment. Or even just a hobbyist who has no clue how canbus works, but would like to learn more.

 

Documentation on the web as far as the different software protocols go concerning canbus is rather dismal. I guess we have NMEA, and SAE to thank for that . . .

[yyrkoon 250]

@@spirilis

 

Ok, so now that I have more than a few minutes to write a reply, let me explain in greater detail.

 

Personally, I believe I have a need to do this. Because I do not think the beaglebone is capable of handling what I would like it to. Each PGN on our CANBUS network is transmitted 2 times a second. Each PGN varies in frame length, with 1 using only 2 CAN frames, and the longest frame set being 11 frames. Each of these frame sets contain multiple data variables - Pertaining to a given frame set. As many as  . . let us say 20 data variables specific to that set. AC voltage status, DC voltage status, battery status, etc. The Xanbus PDF I recieved from another person not long ago is *looks* 279 pages long, with nothing in it except that which pertains to Xanbus( proprietary NMEA 2000 fast packet PGN listing ). I count 29 66 ( missed a couple pages - heh ) seperate PGN's, all of which can be transmitted twice a second. Kind of. Many do not transmit unless a J1939 ISO request is sent to the global address of the network. and 1 or 2 transmit data 10 times a second. . . .

 

So, add on decoding all this in real time, and sending all that data out over some method ( I chose websockets initially ), I think we're asking too much of the beaglebone black. My project ends up dropping a lot of data, and I believe it is because the beaglebone with its single core 1Ghz A8 processor is simply not fast enough to keep up. It does a really good job, at getting a lot of data out, but not everything. Memory, I am pretty sure is not a major concern. As with everything( system and kworkers too ), I do not go much above 110MB memory used - System wide. Ever.

 

Another concern is logging. You probably know as well as I that this should *not* be done local to the beaglebone. Unless some form of durable storage media was used. By durable of course, I mean non flash media. But since I have the need to log data, why not log it remotely. Then if logging remotely, why not just shuffle all that data off to a remote system. Which could log, and decode the data it is already dealing with ?

 

So that is my personal use case. The rest I've been talking - CANBUS test equipment, etc. I'm still considering. I think it has merit, and I think it would not be too hard to implement. At minimum, frames get sent out over ethernet, or some network interface, to a machine that may / may not be running wireshark, or some specially written application for frame examination. Passed that, one could even create a virtual CANBUS network, for testing purposes. With access to a real physical CANBUS interface if needed.

 

Now all that I've mentioned in the last paragraph could potentially be made to work on the beaglebone. But again, it would very likely be dog slow. We've had wireshark custom compiled, and running on the BBB, and it was a horrible experience to say the least . . .

 

Anyway, I'm not saying I know it all, just saying that it may be worth considering. As usual, you're welcome to give me pause for thought . . .

[JonnyBoats 40]

For what it is worth, I believe this is a worthwhile project that could benefit many users.

[dpharris2 2]

I think an Ethernet-CAN sign a Connected Launchpad would be useful and less expensive.  :-)

[yyrkoon 250]

I think an Ethernet-CAN sign a Connected Launchpad would be useful and less expensive.  :-)

I kind of agree but . . .There is a problem with that.

 

There are no CANBUS transceiver boosterpacks - period. With the Beaglebone black you have several options for capes. SO for those who do not wish to entrench themselves into more hardware design, at least initially. That's a dead end for them. Also, with a Beaglebone black you do not *ever* have to worry about running out of resources. Unless you're simply being careless. That and the BBB can decode a 250kbit/s "stream", and send that data out over a websocket in real time. Plus a lot more. So much of this, or perhaps all the connected launchpad can do. I have no illusions about that. On the flip side of that coin though, I have no illusions that any of the connected launchpads can do what the Beaglebone's can. Meaning, the Beaglebones can do a lot more in the same amount of time. At the cost of being less  deterministic, and so far, I'm not seeing much of a problem with that.

 

But I just so happen to own one such connected launchpad for this purpose. Perhaps we'll eventually offer up boosterpacks as well.

[dpharris2 2]

I have a small CAN transceiver board.  It will take an ISO1050, or a number of other transceivers.  It has on-board power regulator, and RJ45x2 connectors.  Interface is CAN-RX and TX, GND, and two power in/out, so its very flexible.  I could convert to a shield/booster-pack, but this is more useful since it can connect to any of my dev boards: Tiva, Arduino, NXP, Nucleo, etc.  

 

David

[dpharris2 2]

Further ... the price difference between Beaglebone (I have two BBBs) and Tivas, Nucleos etc is significant.  If the BBB is also used for other things then it is ok, but for a CAN-Ethenet, the BBB is overkill in my opinion.   BUT, thats not to say its not useful :-)   I am part of a dev team for OpenLCB/LCC, which is a bus for model railroad -- we are targeting Arduino thru ARM thru BBB, so its all good, as they say!  

 

David

[yyrkoon 250]

Further ... the price difference between Beaglebone (I have two BBBs) and Tivas, Nucleos etc is significant.  If the BBB is also used for other things then it is ok, but for a CAN-Ethenet, the BBB is overkill in my opinion.   BUT, thats not to say its not useful :-)   I am part of a dev team for OpenLCB/LCC, which is a bus for model railroad -- we are targeting Arduino thru ARM thru BBB, so its all good, as they say!  

 

David

Well, actually I had more than just CAN<->Ethernet bridge in mind. The idea I originally had was to use this for CANBUS development. So, in other words, this bridge should be configurable on the fly, and over the network. I hd a lot more in mind as well, but that project I put on the bck burner until I think it through more. Which for me, means I need to think about it a good long while. Everything said and done, It could still very well be overkill.

 

And yeah, the connected LP's are literally less than half the cost of a BBB. But . . . BBB's are also more generic, and good overall development / hacking fun - Well, it's all fun really, but the LPs are a bit more specific purpose. One of the main reasons besides the CAN, and Ethernet though is that these(connected LP's ) have what seems one hell of an ADC module on them. Well two really( I think ).

 

Sadly I've yet to toy with it yet

[yyrkoon 250]

@@dpharris2

 

So the cool thing I was thinking of. With Linux, we have the socketCAN libraries / driver modules to play with. So, you could essentially, model a whole CANBUS network, even very complicated ones through virtual interfaces. E.G. you could experiment before investing into actual hardware.

[yyrkoon 250]

Dahm I keep remembering stuff to say after I post . . heh.

 

So also there is no "law" that says these virtual CAN interfaces have to be experimental either. In the case of Beagelbone's these virtual CAN interfaces can be made to interact with the single, or dual physical CAN interfaces on the board. This is where the BBB's outshine the LP's. *BUT* While I can see that s being very useful, I do not know of many situations where that would / could be used. But imagine for example, a remote dev bord of some kind, with no CAN capability, accessing a LAN / Wifi network, spitting some data to a BBB, then the BBB injects that data into the CANBUS network . . . Useful ? I'm still not sure, but it seems like it could be very useful.

 

EDIT:

 Yeah I do not know. Thinking about this more, you honestly do not need a virtual CAN interface to do this. But I still think this capability is useful, but need to think it through more . . .