Tesla has finally discovered subassemblies and the concept of minimizing wiring.
Other car companies have been using both for years...even decades, in Toyota's case (the original pioneer behind using subassemblies in automotive design).
So the idea is to make ecu in the vicinity to be responsible of the components, and drive them through communications.
Nothing new, trucks are applying this technique already.
The big drawback is that it increases SW and systems complexity. You cannot believe how few of the SW guys in the automotive industry have a clue about CAN (or flexray) communications and its failures mode. Its unbelievable how much code does not react properly on Communications failures / init / lag.
I know someone who used to work on BMWs and he said when they first came out with the lan-based car wiring problems were almost impossible to diagnose. Basically the shops would just swap parts until something worked. I think it's gotten better now as things have matured.
I expect because tesla is doing it in SV, they have enough software guys available to figure things out (and maybe frontload the diagnostics to make servicing things easier).
That's how technology works - make cheaper and less sophisticated hardware do more and better.
I don't see how this would help, because the default behaviour in a computer software is to inform the user that an error occured, please press enter to continue.
When you write software for a car, you always have to think about the impact of your code in the car, and pressing enter or crashing the sw is not the safe way to respond. So if the comms fails, you have to ask yourself what should the thing you're writing do and what the driver would see or think.
The problem with this architecture is that when you have a physical sensor, it is obvious when it fails and you can easily add contingencies. When you have a sensor other CAN or whatever, you are adding new failure modes: sensor OK but communication not reliable, or sensor info not yet received. You thus need more code to handle those new failure modes which are tricky for the average sw guy.
This is generally how everything computerized is developed.
The hardware is simplified and the software becomes more sophisticated. In this case, the recurring costs are minimized (simplified wiring harnesses that are installed via automation) in favor of an increase in non-recurring costs (more up-front engineering time).
The failure modes of these kinds of designs are by now a solved problem. The fact that automated assembly of simpler wiring harnesses occurs might mean the hardware reliability goes up.
I think the main advantage that Tesla brings to this effort is the fact that they are creating everything in house. This means that they can concentrate on how the system works together as a whole and not have to fight about interfaces between disparate systems. Instead of having to learn how the entertainment center APIs work and writing code against that, they can just walk down the hall and talk to the people creating that code. I think that gives them a massive head start for this type of project. Plus, they have been writing automotive software for quite a while be well versed in it's peculiarities, not to mention the tooling they've likely created to help.
> ts unbelievable how much code does not react properly on Communications failures / init / lag.
I think this is the main reason those we do some kind of engineering work have jobs.
Those issues are prevalent in anything built with some constraint in time and/or money, that would be just almost everything built and in production on Earth.
How is this different architecturally from typical structured wiring in networking, or say the arrangement of USB controllers within a typical laptop / docking station?
Although I'm not thrilled by the idea of my drivers side puddle lamp having it's own [IP] address!
AFAIK systems "bus based" are very similar, even for home/office electric cabling.
In the home/office "domotic" ones there are usually two couples of wires, two are the mains (poass-through) and two are "signal", every device is connected to both.
Tesla's big advantage is that they're not just building autos, they're redefining how they get built. It's not about the car, it's about the machines that make them and the interfaces between them. Effectively, the car is built using an electromechanical design language (DSL) specialized for automated manufacturing.
11 comments
[ 3.2 ms ] story [ 31.6 ms ] threadOther car companies have been using both for years...even decades, in Toyota's case (the original pioneer behind using subassemblies in automotive design).
Nothing new, trucks are applying this technique already.
The big drawback is that it increases SW and systems complexity. You cannot believe how few of the SW guys in the automotive industry have a clue about CAN (or flexray) communications and its failures mode. Its unbelievable how much code does not react properly on Communications failures / init / lag.
I expect because tesla is doing it in SV, they have enough software guys available to figure things out (and maybe frontload the diagnostics to make servicing things easier).
That's how technology works - make cheaper and less sophisticated hardware do more and better.
When you write software for a car, you always have to think about the impact of your code in the car, and pressing enter or crashing the sw is not the safe way to respond. So if the comms fails, you have to ask yourself what should the thing you're writing do and what the driver would see or think.
The problem with this architecture is that when you have a physical sensor, it is obvious when it fails and you can easily add contingencies. When you have a sensor other CAN or whatever, you are adding new failure modes: sensor OK but communication not reliable, or sensor info not yet received. You thus need more code to handle those new failure modes which are tricky for the average sw guy.
The hardware is simplified and the software becomes more sophisticated. In this case, the recurring costs are minimized (simplified wiring harnesses that are installed via automation) in favor of an increase in non-recurring costs (more up-front engineering time).
The failure modes of these kinds of designs are by now a solved problem. The fact that automated assembly of simpler wiring harnesses occurs might mean the hardware reliability goes up.
I think this is the main reason those we do some kind of engineering work have jobs.
Those issues are prevalent in anything built with some constraint in time and/or money, that would be just almost everything built and in production on Earth.
Although I'm not thrilled by the idea of my drivers side puddle lamp having it's own [IP] address!
In the home/office "domotic" ones there are usually two couples of wires, two are the mains (poass-through) and two are "signal", every device is connected to both.
The closest thing in typical networks is - I believe - PoE: https://en.wikipedia.org/wiki/Power_over_Ethernet
In automotive, normally the frame is 0V or "ground" and you need only a single (big) wire with +12 V and the signal cable/wires.