3 ms·

It's funny, I honestly had an entirely opposite reaction to that letter. It seems like a reasonable thing for the software developers to look at to confirm the

by sjm-lbm 10y ago

It's funny, I honestly had an entirely opposite reaction to that letter. It seems like a reasonable thing for the software developers to look at to confirm the systems were working as specified, but leaves me with a ton of questions about how this feature was designed overall. It sounds like the only two mistakes that the guy made were to make a double press of the park button (which, as far as mistakes go, isn't the most unreasonable thing to do), and to assume that a car told to be in park would, well, be in park. He ignored warnings, yes, but he was likely worried about getting out of the car and doing other things by that point, which isn't wildly unreasonable either.

freehunter 10y ago
Summon mode is not turned on by default. That's the damning thing here. He turned on the ability to use Summon mode by hand, purposefully. At that point he should know the responsibility that comes with that. That's directly akin to manually disabling traction control on a normal car. At that point, you can't blame the manufacturer for losing control. You held the button down for three seconds and it dinged and the dashboard light came on and you KNEW that it would disable traction control. He enabled Summon mode through the menu, then either accidentally or on purpose triggered Summon mode, then stepped out of the car and the car drove off. He shouldn't have assumed the car was in park when he knew that hitting the park button twice would activate this beta software that he had to manually enable in the first place. He used Summon mode on purpose and didn't pay attention to its limitations or the rules saying "only use this on private property". The only blame Tesla has is selling a car to an irresponsible driver.
- mikeash 10y ago
  I'm pretty sure he had to turn on two separate settings, both with their own warnings. There's one setting to enable Summon, and then there's another setting to disable the requirement for "continuous press," since by default Summon only operates in a dead-man's-switch mode with the driver's finger on a button in the phone app. I do think that the double-click Park feature could use an extra confirmation step. It already pops up a window asking whether you want to go forward or backward, and all they need to do is make it so you have to actively select one, not default it to forward as they currently do.
  - eggy 10y ago
    Being in the stage machinery business, I have never relied on something like a wireless smartphone for a deadman switch. You need certified hardware/sofware meeting relevant standards. This is why I still use industrial PLCs for my installations over my Pic chip or Arduino creations. I will use them in non-safety related, temporary installations, but unless I have had the HW/SW third-party inspected, I'll stay with the certified combination. An industrial e-stop relay is more than just certified compared to a 5V relay you typically use with an Arduino or Pic chip project to control motors, or other actuators. There are protocols, and there can be rules, such if WiFi signal is lost, e-stop, but I have personally tested such a system where the hydraulic lift continued to run when WiFi was lost even with a rule to prevent it. Good thing I was standing purposefully near a hard-wired e-stop.
    - sjwright 10y ago
      If it's programmed defensively, it could be reasonably safe. For example, I would want the car to be performing an ongoing, end-to-end verification of the finger's continued presence on the phone. This could mean, for example, the app could heartbeat the finger's presence multiple times per second. The car would be continuously checking, such that if 500 or 1000 msec had passed since the last end-to-end verification, the car stops. You could even reduce the risk of API/digitizer errors and require the user to continuously tap/stroke/rub/swirl the deadman switch button, or perform some device movement captured by the accelerometer.
      - eggy 10y ago
        In the safety engineering/mechanical engineering business this why you perform an FMEA: a Failure Mode and Effects Analysis. You list all that could possibly go wrong, how it could go and how it could go wrong. You assign a rating for the likelihood of it being detected, the severity if it does fail, and the frequency of occurrence or likely occurrence. You address each failure mode in order, based upon the product of the above three factors (detectability, severity, occurrence), with a mitigation strategy, only if you cannot entirely remove, or design away the risk. You cannot (well you can) install automation controls on any old laptop or notebook. Good luck trying to show your smartphone to the insurance investigator!Our maintenance tablet had to be ruggedized to mil-spec, and had to have a rated e-stop button on it per BSI standards. We never used wireless control without being near a 'hard' e-stop, and always just for maintenance mode, no real runs with people around. If you can get frustrated when your finger's sweaty with your touchscreen, imagine a 15 metric ton lift continuing to move at 100mm/s, because the touch screen on your smartphone still thinks your finger is holding the 'deadman' icon! Not to mention WiFi dropping, or your battery going dead. I can only say this, since I have seen some hairy situations in my day.

by sjm-lbm 10y ago

freehunter 10y ago

Summon mode is not turned on by default. That's the damning thing here. He turned on the ability to use Summon mode by hand, purposefully. At that point he should know the responsibility that comes with that. That's directly akin to manually disabling traction control on a normal car. At that point, you can't blame the manufacturer for losing control. You held the button down for three seconds and it dinged and the dashboard light came on and you KNEW that it would disable traction control. He enabled Summon mode through the menu, then either accidentally or on purpose triggered Summon mode, then stepped out of the car and the car drove off. He shouldn't have assumed the car was in park when he knew that hitting the park button twice would activate this beta software that he had to manually enable in the first place. He used Summon mode on purpose and didn't pay attention to its limitations or the rules saying "only use this on private property". The only blame Tesla has is selling a car to an irresponsible driver.

mikeash 10y ago
I'm pretty sure he had to turn on two separate settings, both with their own warnings. There's one setting to enable Summon, and then there's another setting to disable the requirement for "continuous press," since by default Summon only operates in a dead-man's-switch mode with the driver's finger on a button in the phone app. I do think that the double-click Park feature could use an extra confirmation step. It already pops up a window asking whether you want to go forward or backward, and all they need to do is make it so you have to actively select one, not default it to forward as they currently do.
- eggy 10y ago
  Being in the stage machinery business, I have never relied on something like a wireless smartphone for a deadman switch. You need certified hardware/sofware meeting relevant standards. This is why I still use industrial PLCs for my installations over my Pic chip or Arduino creations. I will use them in non-safety related, temporary installations, but unless I have had the HW/SW third-party inspected, I'll stay with the certified combination. An industrial e-stop relay is more than just certified compared to a 5V relay you typically use with an Arduino or Pic chip project to control motors, or other actuators. There are protocols, and there can be rules, such if WiFi signal is lost, e-stop, but I have personally tested such a system where the hydraulic lift continued to run when WiFi was lost even with a rule to prevent it. Good thing I was standing purposefully near a hard-wired e-stop.
  - sjwright 10y ago
    If it's programmed defensively, it could be reasonably safe. For example, I would want the car to be performing an ongoing, end-to-end verification of the finger's continued presence on the phone. This could mean, for example, the app could heartbeat the finger's presence multiple times per second. The car would be continuously checking, such that if 500 or 1000 msec had passed since the last end-to-end verification, the car stops. You could even reduce the risk of API/digitizer errors and require the user to continuously tap/stroke/rub/swirl the deadman switch button, or perform some device movement captured by the accelerometer.
    - eggy 10y ago
      In the safety engineering/mechanical engineering business this why you perform an FMEA: a Failure Mode and Effects Analysis. You list all that could possibly go wrong, how it could go and how it could go wrong. You assign a rating for the likelihood of it being detected, the severity if it does fail, and the frequency of occurrence or likely occurrence. You address each failure mode in order, based upon the product of the above three factors (detectability, severity, occurrence), with a mitigation strategy, only if you cannot entirely remove, or design away the risk. You cannot (well you can) install automation controls on any old laptop or notebook. Good luck trying to show your smartphone to the insurance investigator!Our maintenance tablet had to be ruggedized to mil-spec, and had to have a rated e-stop button on it per BSI standards. We never used wireless control without being near a 'hard' e-stop, and always just for maintenance mode, no real runs with people around. If you can get frustrated when your finger's sweaty with your touchscreen, imagine a 15 metric ton lift continuing to move at 100mm/s, because the touch screen on your smartphone still thinks your finger is holding the 'deadman' icon! Not to mention WiFi dropping, or your battery going dead. I can only say this, since I have seen some hairy situations in my day.