The tower of Babel
So I have come to ask myself a rhetorical question. Why is the migration of a transfer of the Abarth harness problematic? or
“my last week trawling knowledge on the internet”
Simple really, the bus is stamped all over with proprietary data. You have to pay vast sums of money to get stuff certified. Hobbyists are often frustrated inventors and would like to exploit a good idea if they come up with one. The barriers to complete entry are simply too high. Unfortunately, it seems keeping source code secret seems to have a reputation as being some kind of “good” engineering practice, even though it’s basically fundamentally at odds with honourable science and engineering practice. If you contract an engineer to make something for you, you will get the blueprints – if they don’t provide them, then they didn’t engineer it for you. CAN has a specific requirement for resistance on the bus of usually three wires, typically relatively high resistance between HIGH and LOW signals at stub nodes, and relatively low resistance at bus termination points. Step outside that and you are toast. I have read the North American 2010+ Camaro for example has gone so far down this 'user locked out' path that this is built into the damn radio. Remove the radio and ‘nothing works’. Can’t even so much as unlock the doors, turn on the lights, open a window or even start the engine. If you want an aftermarket stereo the only solution is an expensive replacement control black box that duplicates all the non-audio/radio functions of the system built into the stock radio. I wondered why the heck there are non-audio-radio functions in the damn radio, why have the lawyers not jumped on this with an antitrust case.
Did you hear the joke about buying a car with the hood welded shut? well, car makers realized nobody would see the hood weld shut with the CAB Bus software, so they did it.
This sort of rubbish got Bill Gates into all sorts of 'Antitrust' trouble in 2000, yet in automotive they get away with this 'proprietary' mumbo jumbo. What is needed is a good, standard bus architecture and code, The point about the CAN physical layer , remove the radio and ‘nothing works’ really gives me the pips. Having an entire network become non operational when a single node is physically disconnected that has nothing to do with the actual driving of the car is a major flaw!!
I understood that the original BOSCH concept was opposite to this, one node fails and the rest can carry on with the task, it should be damn illegal to sell a system that shuts down when one node fails in a radio that has no role in the safety of or driveability of a vehicle because of the operating system.
Problem as I wrote before "Matt is correct CAN Bus is EVERYWHERE". How we got ambushed into letting manufacturers locking the user out of these systems is just a function of how clever corporates are, now we are snookered. Your radio packs up and they want you to go to the dealer, want a 'better one' and your stereo guy has to put in an interface black box. Sure it makes stealing the stereo harder ( as it is impossible to sell a stereo that won’t work ) but the car is left immobilised in the Camaro example.
I’m becoming a fan of CAN bus for hobby electronics but I totally understand why more people don’t use it, I get the feeling it's the multitude of varying proprietary variants.
CAN itself is an amazing protocol. The addressing has built-in prioritization and collision avoidance. The CAN controllers can handle serious failures at the physical layer and still work. It can be used in a way very similar to a client /server architecture, but I think of it as really designed for broadcast traffic. For example imagine you have a speed sensor that transmits your speed a few times a second. Your
speedometer sees that data packet and updates the display, the cruise control sees it as well and adjusts your engine to maintain speed. Both nodes execute functions off the one data packet. Your car door listens for a command to lock or unlock. Anything can generate that command… The door switch on any door, the key fob receiver, the alarm module, etc. And those things could listen for those commands also so, for example, the alarm can enable itself. Talk about reliable…
Add you can get CAN Bus controllers pretty cheap and CAN Bus chips 'could' be programmed as simple io expanders that are almost set and forget. And how many hobby grade electronics have had the level of development as automotive electronics?
There is a better way to design embedded systems than what we have.
The wrong way centralizes functionality that has no business being together, and makes it opaque to generic repairmen. This is usually chosen so as to “optimize for cost” by minimizing the number of computers… you know, in a IBM “there’s maybe a market for 5 computers globally” kind of way.
The right way is to keep things as simple as will work, preferably not even using OS’s, when the tasks can be separated so one function per microcontroller. This way there is no multiple stacks of complication, and each separate processor’s code becomes simple and easily maintained. (and preferably also, kept with the install so that future repairmen have a chance to fix it!). This is known as robust design, engineering for maximum reliability, as a priority far above “cost”.
But that won't make money.
As manufacturers get better at this, expect, nay, demand that they become compliant! An essential, and yet still lacking part of this is the availability of the source code, as well as the barrier-to-modification. The auto industry is notorious for keeping all their tech secret – so much so that most “scientifically published, peer reviewed” papers I have read more like sales brochures with bugger all actual detail of the device than the patents that they’re trying to push.
Car manufacturers have a lot to be taught in this regard, but even more so do the “engineering software” companies who “sell products” in the MSFT xOS/iOS style. It’s disgusting, and one day people will find it difficult to believe that it was ever considered reasonable business practice.
All that said CAN is very good – no where near the performance of, say, FireWire, but still exactly as Lee Iacocca “KISS” like as you could hope for in a low speed / high reliability / easily debugged multidrop communications protocol. Firewire is perfection at high bandwidth, but carries with it quite an overhead in terms of protocol, it was clearly designed by a engineering committee of computer geeks totally obsessed with getting the minutia of every little detail right. It is anarchistic democracy to USB’s benevolent dictatorship. CAN is just like a few spanner monkeys talking shop at the garage, and getting the work done whilst occasionally yelling over the top of one another other, but that’s ok, because everyone knows the pecking order, and shuts up and listens when it’s urgent.
Apart from sheer Band Width, CAN craps all over ethernet’s stupid “if a collision, wait a random time, then try again” approach to sharing a wire. Bobs comment about CAN's use in other industries is an example of how 'good' it is (Hint: this is why ethernet is not really used to share wires anymore – do you know the difference between a “hub” and a “switch”? Remember 10Base2 ?). Schneider /Clipsal in Australia has been using C Bus to wire 'smart homes' for years why more folks don't use it probably down to the skill level of the average home wiring electrician happy to bumble along the 'old way' because it's easier.
Aside from the horribleness putting a “standard” behind a paywall (just like selling software licences IMHO, anti educational), CAN is a good bit of kit, whose actual impact on the world for the better will be proportional to those benefiting from it, and therefore dependant upon being widely understood and used where appropriate. (Again, something that paywalls / licensing / general IP legals destroys). I have said I am an open source guy before so you can guess I loathe this closed architecture where car makers can lock you out of something you bought.
Despite this high opinion of CAN Bus I’m looking forward to this getting rid of it on the MultiAir anyway
So, I’m still collating the physical requirements of the devices on the 500 Turbo MultiAir to match an aftermarket ECU, but apparently its all secret. It may take a while.
Thanks for the input people, keep a positive open mind.
Sandy
Share the knowledge
