CANBus is also used on spacecraft to communicate between payloads and the on-board computer. Sometimes it is used in concert with MilBus 1553 as the payloads and sensors are acquired from various sources. I believe that work is being done to standardise to one solution, but in the meantime we end up programming for both!
An Introduction to the CAN Bus: How to Programmatically Control a Car
101–110 of 110 posts
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#102Earlier quoted context omitted.
> It's not that hard to make a controller that lets you physically turn the wheel using an RC remote > The reason terrorists don't do that has nothing to do with being hard. This is false. Remote-controlled VBIEDs are absolutely a thing
Um.... reread that comment. He's saying that VBIEDs are totally possible, and that this example of CAN Bus control isn't going to cause a new era of terrorist actions, because it's just as easy to do it with servos and/or ropes and cables. What he's saying is not false.
What he's saying is that terrorists are doing it. Not that it's a potential thing, but that there are war zones where it is happening.
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#103Q: What is a good simulator for car hacking? I expected to find some vehicle simulator that allows me to load several car specs, similar to a flight simulator. Plus integration of some advanced racing / driving software - I could not find any of these, but I am not an expert in this field. Where to find these? THANKS!
There are some great tools here to get you started:
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#104Interesting - never realized there would be multiple CAN buses in a car. That probably makes it a lot easier to not screw things up - if you know that the medium speed bus is only connected to non-safety-critical systems, then it's easier to trust that when you send out your hand-crafted CAN packets, you're not going to cause anything too drastic to happen.
Indeed. Especially important when you remember that most of the (many!) devices in a car sitting on CAN buses come from outside suppliers, and black-box testing of these modules can only go so far to verify the CAN implementation and stability. AFAIK, Ford actually mandates that their suppliers use a standard CAN stack provided/licensed by Ford (FNOS, the Ford Network Operating System) to try and ensure a level of qu…
Yes, we need property testing of this stuff to become the norm.
https://erlangcentral.org/videos/testing-automotive-software... http://www.cs.tufts.edu/~nr/cs257/archive/john-hughes/quviq-...
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#105Earlier quoted context omitted.
There are used beds that use the bus available on eBay and other auction sites. Be aware that it's only on their high-end beds, If you're looking to bid on one, know that they weigh over 600 lbs and need wide doorways (ask me how I know..) Current prices are $900 and up, and often don't come with the inflatable mattresses (hospital may not want the potential biohazard liability, so disposes of it first).
> they weigh over 600 lbs and need wide doorways Spot the Orderly?
We would occasionally get a new model delivered by truck. The one door between the lab and the elevator was a normal (narrow) door. So we'd have to lift the bed onto it's side and maneuver it through. So that's how I know how much they weigh and that they need wide doors. :)
The bizarre story was we had an employee that was diabetic, and she passed out one day. When the paramedics arrived, they found her already sitting in a hospital bed.
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#106CAN frames are not standardized. You cannot have a single command to do operations on any car. Each manufacturer has different bit patterns and also it varies between car models. Atleast with Chrylsers I know its true. There should be a lookup based on the car's model with a unified API which I think will happen soon based on the pace of car tech progress. Also note that once the frame is on the bus, it get executed and an ACK will be sent. There is no authentication mechanism in place. So once you put a frame into the CAN bus, there is no way to stop it. This will be the top pain points for car techs to fix.
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#107Reversing this stuff is a big pain in the back. I'm doing Ford (Mercury) dash display controller as my free time pet project and it's only by reverse engineering the protocol. I'm mimicking stock headunit and collect data from MS CAN. But need to admit, that there's lots of logic in the protocol, so can be reverse engineered with brains.
Some pics and text (sorry, Russian only for now)
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#108Reversing this stuff is a big pain in the back. I'm doing Ford (Mercury) dash display controller as my free time pet project and it's only by reverse engineering the protocol. I'm mimicking stock headunit and collect data from MS CAN. But need to admit, that there's lots of logic in the protocol, so can be reverse engineered with brains. Some pics and text (sorry, Russian only for now) https://www.drive2.ru/l/4744730…
This controller operates when stock headunit is removed and can print out on the stock dash display (FDIM) the following info:
- clock (can be taken from 2010+ GPSM module or from external RTC clock - DS3231 based) - tire pressure (from broadcasts 2010+ or from Ford TPMS protocol 2008+) - tire temp (from TPMS protocol) - RPM - engine temp - current speed
units are configurable (12/24h clock, psi/kpa pressure, C/F temperature)
Probably will share code and PCBs on github soon, now this thingy is under heavy test in my car and other cars of some enthusiastic guys
There are plans to extend the device with CAN proxy to allow it to work together with stock headunit and also sit on both HS and MS can buses to get more data do display
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#109CAN Bus is great. I highly recommend reading the CAN Open Spec if your going to be implementing new systems using CAN Bus. https://en.wikipedia.org/wiki/CANopen Many more things besides auto's use CAN. One of my current projects involves exercise equipment that internally speaks CAN Bus. There is great support in Arduino for interfacing with stuff like this.
Isn't CAN very limited in terms of bandwidth? Seems like this wouldn't be appropriate for most applications of interest? When I worked at an equipment manufacturer, everyone was very concerned about accidentally saturating the bus, and we even had a very compact data representation.
Noone ever talks about the very significant downsides of CAN:
- CAN is very slow despite high baudrates. As used in automotive max 40% of all bits are actual databits. That value is for frames with 8 bytes. For 4 bytes that drops to 25% so people avoid these frames. That means in practice one gets only 1500 frames/s at a typical 250kbps.
- a roundtrip takes 2 frames because the CAN request frame is broken to the point that standards like J1939 do not use it.
- CAN-B error detection mechanism has holes in it due to bit-stuffing. Effectively the CRC is circumvented, so error detection rates are nowhere near the projections made in the design documents.
- CAN-FD increases the payload, stuffing 5x (typical) more databits in the same frame. That means bits are transmitted at only 22% of the datarate, worse for higher datarates, much worse for frames with only 8 bytes. CAN-FD hardly improves latency or the frame-rate, but it does much improve error-detection rates.
So the take-away here is, yes, CAN sucks, quite badly. CAN-FD improvements really only suit niche applications.
It is possible to do much better and achieve roughly 4x the CAN-B performance (on metrics such as throughput, latency and robustness (all of them)), on the same bus.
Re: An Introduction to the CAN Bus: How to Programmatically Control a Car
#110"we flipped the problem (and the OBD-II port) inside out and found naked access to HS1, HS2, HS3 and MS. The solution was on the back of the OBD-II port where all those buses arrive to a device called the Gateway Module." This seems like a critical hack. Is this normal of all (non-ford) cars as well? I'm gonna guess Car mfg's are going to start encrypting the CAN bus [1]. [1]: http://www.eetimes.com/document.asp?doc_…
Unfortunately it's pretty much industry standard that once you have physical access to the relevant CAN bus you can read (and write) everything. The normal protection which is mostly deployed is that the end-user only has access to the CAN bus on the ODB2 interface, which is behind a gateway and should not expose safety critical things. Some car manufacturers however might also only use a single CAN bus for everythin…
"Unfortunately"? I get what you're saying, but encryption will just mean that hobbyists will be completely locked out of everything. It's not like the manufacturers will go through the trouble of making it possible for a car owner to decrypt the bus traffic in their own car.