AppId is over the quota
There is a right way and a wrong way to design embedded systems.
The wrong way centralizes functionality that has no business being together, and makes it opaque to repairmen. This is usually chosen so as to “optimize for cost” by minimizing the number of computers… you know, in a “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 multiplication 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”.
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, 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 read more like sales brochures with even less actual detail than the patents that they’re trying to push.
Unfortunately, it seems keeping source code secret has a reputation as being some kind of “good” engineering practice, even though it’s basically fundamentally at odds with science and engineering. 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.
Car manufacturers have a lot to learn in this regard, but even more so do the “engineering software” companies who “sell products” in the MSFT 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 “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 comittee of computer engineers obessed with getting every little detail right. It is anarchistic democracy to USB’s benevolent dictatorship. CAN is just a few mechanics talking shop, and getting shit done whilst occasionally yelling over the other, but that’s ok, because everyone knows the pecking order, and shuts up and listens when it’s urgent.)
Apart from sheer BW, CAN shits all over ethernet’s stupid “if a collision, wait a random time, then try again” approach to sharing a wire. (Hint: this is why ethernet is not used to share wires anymore – do you know the difference between a “hub” and a “switch”? Remember 10Base2 ?)
Apart from the horribleness putting a “standard” behind a paywall (just like selling software licences imho, anti education.), CAN is a good bit of work, 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 shit destroys).
I’m looking forward to this series :)
Aucun commentaire:
Enregistrer un commentaire