3 ms·

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 te

by Glawen 7y ago

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.

m463 7y ago
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.
- Glawen 7y ago
  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.
  - m463 7y ago
    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.
Corrado 7y ago
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.

by Glawen 7y ago

m463 7y ago

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.

Glawen 7y ago
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.
- m463 7y ago
  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.

Corrado 7y ago

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.