-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Software concerns
- Thread starter spatterso911
- Start date
-
- Tags
- Model S User Interface
gg_got_a_tesla
Model S: VIN 65513, Model 3: VIN 1913
Yeah, I was wondering about that right after I posted. The wipers might be all automatic by default and controlled via the touchscreen, if needed? Let me not speculate further; can someone else who attended the weekend event please chime in?
MitchL
S#945
I think stalk 2 is the wipers (+ turn signal). I was messing with the stalks and the wipers ran, pretty sure that was the one.
AFAIK, on the betas, lights live only on the touch screen. If the automatic mode works as well as it does on my Honda, I'll be happy.
/Mitch.
All of the controls could just be inputs to a computer that decides to turn on the headlights.
However the headlights should be built in such a way that if they are turned on, they stay on even if the computer vanishes into dust.
So if the computer dies, you may not be able to turn the lights on, but they will stay on even if it crashes and doesn't come back.
If the car computers crash horribly, you want the lights to stay on, the brakes to work and the car to coast to a stop.
I can not imagine building critical systems any other way.
However the headlights should be built in such a way that if they are turned on, they stay on even if the computer vanishes into dust.
So if the computer dies, you may not be able to turn the lights on, but they will stay on even if it crashes and doesn't come back.
If the car computers crash horribly, you want the lights to stay on, the brakes to work and the car to coast to a stop.
I can not imagine building critical systems any other way.
Usually hi/lo beam is controlled on the same stalk as the turn signal. You push in/out for hi/lo beam control. And you push down/up for turn signal control. And you could put nob that you turn for wiper control.
MitchL
S#945
I'm not super concerned about software, I am assuming that Tesla has put critical functions in separate computers (drive train control, suspension, charger, ABS, locking, etc.) and just interconnects everything with a network. I also am convinced that they've got some decent software skills, both hardcore real-time/embedded people and UI designers.
In fact, this separate CPU notion is the right way to do it not only for safety, but for schedule (teams work independently on subsystems), lower cost (subsystems are reusable in other platforms), reliability, testability, etc.
Only the communication protocol needs to be understood in advance, and the rest is an integration issue. If the central touch screen (integration point) fails, the core function should not fail.
That said, there are LOTS of systems, and there's a big effort. Thinking about what might be its own system on the Model S:
- The drive train, of course
- Battery charger
- ABS
- Suspension system
- Seat belts, air bags
- Seat controls
- Windows, doors
- Locking system
- Headlights
- Wipers
- Climate control
Most modern cars have lots of small microprocessors that communicate via CAN or other industrial buses. It'd be far easier to integrate subsystems from external suppliers - you don't make your own ABS or airbags, you integrate someone else's.
Just because everything's integrated from separate systems doesn't mean it will be reliable though... the touch screen has lots of control over critical safety features, even if it is not directly overseeing them. for example, the 17" screen must have access to:
- The ECU/drivetrain (valet mode)
- Headlights
- Trunk/Frunk latches
- Suspension system
- battery charger
- sunroof
A program that goes crazy and jams up the car's system CAN bus(es) could wreak havoc on the other systems even if they're well debugged. This part intrigues me, as I'd like to write apps for the car, but I wonder how they'll let us (software people) mess with that without any liability issues.
For me, the "dream" document I'd like to see is the top-level network design and communication protocol specifications - it'd be a fascinating read.
/Mitch.
In fact, this separate CPU notion is the right way to do it not only for safety, but for schedule (teams work independently on subsystems), lower cost (subsystems are reusable in other platforms), reliability, testability, etc.
Only the communication protocol needs to be understood in advance, and the rest is an integration issue. If the central touch screen (integration point) fails, the core function should not fail.
That said, there are LOTS of systems, and there's a big effort. Thinking about what might be its own system on the Model S:
- The drive train, of course
- Battery charger
- ABS
- Suspension system
- Seat belts, air bags
- Seat controls
- Windows, doors
- Locking system
- Headlights
- Wipers
- Climate control
Most modern cars have lots of small microprocessors that communicate via CAN or other industrial buses. It'd be far easier to integrate subsystems from external suppliers - you don't make your own ABS or airbags, you integrate someone else's.
Just because everything's integrated from separate systems doesn't mean it will be reliable though... the touch screen has lots of control over critical safety features, even if it is not directly overseeing them. for example, the 17" screen must have access to:
- The ECU/drivetrain (valet mode)
- Headlights
- Trunk/Frunk latches
- Suspension system
- battery charger
- sunroof
A program that goes crazy and jams up the car's system CAN bus(es) could wreak havoc on the other systems even if they're well debugged. This part intrigues me, as I'd like to write apps for the car, but I wonder how they'll let us (software people) mess with that without any liability issues.
For me, the "dream" document I'd like to see is the top-level network design and communication protocol specifications - it'd be a fascinating read.
/Mitch.
Similar threads
