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.
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.
> Good thing I was standing purposefully near a hard-wired e-stop.
Good work! I always have a hand on the e-stop when testing something that could kill someone. And I mean a hard wired e-stop system using a properly rated safety relay, too... never trust software (even on an industrial PLC).
I was testing without people involved, so only machinery would have been damaged. I am very skeptical of any wireless safety systems. I know they exist and are used.
It's the same reason I usually put in some kind of mechanical stop in the event of an errant bit-flip in a running program or piece of hardware. I put in steel flag that when struck turned 90 degrees locking the other piece of machinery, so it could not move until the other device returned. This was only as a redundancy to the software, and I slept better at night for it. Equipment ran for almost 10 years, 24 times a day, 355 days a year without incident.
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.
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.
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.