E-Stop and Fuel, software that keeps you awake at night
jacquesmattheij.com
jacquesmattheij.com
> Toyota also claimed that no defects existed and that the electronic control systems within the vehicles were unable to fail in a way that would result in an acceleration surge. More investigations were made but were unsuccessful in finding any defect until April 2008, when it was discovered that the driver side trim on a 2004 Toyota Sienna could come loose and prevent the accelerator pedal from returning to its fully closed position.[4]
Based on those two sources it seems the issue was hardware related, and Toyota may have tried papering over the matt issue. The faulty matt design issue doesn’t support your claim of shoddy software practices and hiring underpaid junior developers. That may still be the case but it appears not to have caused the SA issue.
If the pedal is not stuck, there is a limit to the amount of force you could put on it over a period of time.
If it is jammed, a adult could put a lot of force on it when it is not fully pressed.
This is not the kind of code that should ever have full authority over a 250 kW drive system, even less so with humans in and around that system.
http://www.sddt.com/Commentary/article.cfm?SourceCode=201311...
A common configuration involves emergency stops, guard doors, light curtains, etc. being wired in a pair of loops with the relay. The relay continuously monitors both loops (usually with a phased pulse train), and any interruption or crossover will trip the unit. Only when the loop states return to nominal will the relay permit a reset to re-enable the outputs.
The safety relay's outputs are generally connected to dumb hardware interlocks on the various dangerous bits of the machine.
Special if you use a lot of drives in a machine, any kind of Safety Integrated reduce the wiring a lot and makes cabinets much much smaller.
But on the other side, for just once, yes I like Pilz PNOZ. Easy to use .. and I'm pretty sure you can buy a PNOZ even in 100 years.
Most of our customers would run away screaming from anything that's not hardwired safety, and are too cheap to shell out for a fully-blown safety PLC like the GuardLogix.
Most maintenance people like hardware solutions because they are more easy to bridge ... With a software solution you can show easy for each safety button/switch a message on a display. Do it with a wired safety.
For some applications where you need to have humans working in the same area with the robot things get a lot hard. You probably need some software involved in enforcing speed limits for robots. The compliance engineers I've talked to say getting safety certification for software is quite arduous. In this case the off-the-shelf solutions the parent child comments mention become valuable.
Wow. Where I am we sometimes do this, but never without real thought. And, generally, we revisit that part of the process again and again over time.
One example: initial setup of a CNC machine part. If you don't have $50K-$100K, you are setting this up by hand. You are moving the cutting head while your hand is in the same space. If you screw up, it probably won't rip your hand off, but you will likely wind up with a solid, painful gash and it might break a small bone if you get really unlucky.
People don't respect servos enough. They're remarkably powerful and probably moreso than you expect.
Curious what specifically you need your hand inside for? Do you simply mean the machine is on (though entirely inactive) while putting the part in, touching off the part slipping the business card in and out, or something else entirely?
It's remarkably easy to get your hand pinched if you take it a little too cavalierly.
Of course as more often you can build the same machine, as better you can work out details. But sometimes there is just "one" machine. Then usually have to work out the the flaws first ..
A friend from school cleaned a CNC mill while the machine worked. The safety door was manipulated and the 2D table drove over his hand ..
[0] https://www.fanucamerica.com/home/products-services/robots/c...
We also designed our own 802.11 access points.
All of our competitors had at least one fire. In a hotel with hundreds of people asleep. It didn’t matter if they used commercial gear or not. Every one of them had a fire.
We never had one, but I was obsessed with not hurting anyone because we had missed something.
And yes, it kept me up at night.
When you design your own hardware there's way too many things that can go wrong.
Is that a diplomatic way of saying someone lost the source code?
Hello, rounding errors. Oh hell no.
We certainly cannot use it for money, for example. Most shops I know of have fancy decimal libraries they never get to use because an unsigned long unit of centicents is simpler, predictable and easy to encode and assume client software will have the same rounding strategy.
If anything errors in floating point numbers are graceful and give you a lot of leeway before they become catastrophic. Fixed point works until you hit 2(n-1) bits then probably breaks unexpectedly. Where n is the last exponent you have seen in business.
Floating point libraries can't even do this.
You can call it a knee-jerk reaction, but the law itself clearly has that bias, and for good reason.
All regulations were paved in blood.
First week on the job in e-commerce, I educated the junior engineers on the problems that can arise when using floating point math with currencies, then prioritized work to remove any floating point math from the code. That doesn't mean I wouldn't use floating point anywhere else. In aerospace in particular, I've used floating-point without issue, so I don't think you're point about currencies has any relevancy to the GP's comment regarding fuel estimation.
E.g.
step = 0.001
fprime = (f(x+step) - f(x)) / step
Floating point is used regularly in avionics and other fields involving critical computations, it is not the floating point data type itself that is problematic, what is problematic is poorly understanding the underlying implementation details and what kind of limitations that will cause.
A good example is trying to count integers with more bits than the underlying precision of the implementation will allow. But in this particular case floating point would have been my 'tool of choice' anyway, fixed point would have introduced a lot of complications for very little gain - if any - gain and would not be worth it.
So in many cases I would agree with you that rounding errors could cause huge problems but in this particular case the inputs were in ranges where this could not happen, the software was tested exhaustively across all input ranges to ensure well defined behavior.
Clearly 'blame' isn't an appropriate response. It has to involve tooling.
This leads to glacial progress but I find that is preferable over the 'move fast and break shit' mentality that pervades the software industry.
There are procedures in various safety-conscious industries for handling this kind of development. I like that you used the word "systemic" because it is literally a systems issue, not a software, or electronics, or mechanical issue. The entire system has to be considered and analyzed for potential faults.
I spent over a decade writing code for medical devices and while the software aspect of these systems was the most advanced in terms of development process (unlike what many on HN seem to think :-), everything we did had to be considered from a system perspective because even if the individual parts were designed properly, it was possible for the interactions between them to cause problems.