Hacker News Reader

Comment by roland35 | Hacker News Reader

Software development often does seem like a struggle between reliability/robustness and safety/correctness. Figuring out what to do with asserts falls in this debate!

For embedded development I have often had ASSERTs log out to a serial port with the function name/line # and continue operating - this can then be connected to any logging device. This makes the system a little more robust (it won't crash, right away at least) but less correct/safe.

During development testing we often had complaints of machines freezing due to asserts, which always increased the priority of those bugs! Definitely a good thing in the long run to fix those bugs and make the system more correct. Stopping all executing may not be the correct 'safe state' for an airplane though!

View on HN

> Stopping all executing may not be the correct 'safe state' for an airplane though!

It absolutely is. It's a (literally) disaster to allow code that has entered an unknown state to control aircraft functions. There is NO WAY such a design would EVER be certified by the FAA.

In a fly-by-wire design (which is de rigeur now), stopping all operations would be way worse than continuing.

That is certainly not how fly by wire systems are designed. The FAA would never certify a design that relied on allowing software in an unknown state to access critical flight controls.

Here's how it's done:

Assertions in Production Code https://www.digitalmars.com/articles/b14.html

Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html

Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html

I've never written written safety critical software, but I believe the point is that "stop all execution" is not always an adequate response to an unknown state; this does not imply that "proceed as if nothing went wrong" is an acceptable response. I would imagine the response to an unknown state would be "return to a known state". This could be accomplished by rebooting (returning the software itself to a known good state), passing control to a redundant system (possibly done by halting all execution of the affected system, but the design needs to consider more than that), falling back to some form of a safe mode, where the bad state is not present, but safety critical functionality can continue.

When you're at 30,000 feet, nobody wants to go experimenting with a system controlling critical flight operations that has gone into an unknown state.

The pilot often has the option of rebooting the system and trying it again, but that's dangerous. On an episode of "Aviation Disasters", I don't remember the exact details, but the pilot got a warning of a failed system. After a consult with the ground, they told him to reboot it. After a while, it failed again. They told him don't worry about it, reboot it again.

It (the airplane, that is) crashed.

Aircraft systems are designed to be decoupled from each other as much as possible, so failures do not propagate. In particular, they must not propagate to the backup system, or the "safe mode". The engineers do work hard at this, and sometimes they don't get it right, and another bitter lesson is learned.

The "safe mode" system must be physically and electrically decoupled from the normal system.

An example of getting it wrong is I've seen demonstrations on TV of people hacking in through the wireless key locks on a car to take control of the brakes. That's seriously bad engineering - not so much the vulnerability to hacking because happens, but the fact that the door lock system is connected to the brake system. It's cowboy engineering at its worst.

Keeping systems isolated is an orthogonal concern. The question is weather rebooting the system is safer then shutting it off. The fact that shutting it off should be safe is a separate concern. At a minimum, shutting it off reduces your redudancy; and it the system fails again (even in an undetected way), that should be fine, because you (should) have enough redundancy to handle an arbitrary system fail in unexpected ways.

This may be n sample size of 1. After reading the NASA programming guidelines for remote vehicles and operation of equipment on mars my programming and system programming got a lot better.

Boil it down very simply without going into detail. * On start-up each module allocates all its memory (it has a fixed bounds) * Each loop loop of each module has a interation bounds * Assert pre-condition and post-condition of routines and leave them in production.

Usually the hardware is tri or even quad redundant so the system can handle one of the boxes halting execution while it is either reset or other action is taken. If several failures happen one box may be powered off by the others to stop erroneous outputs from the failed box.

May? The offending box gets electrically isolated from the craft if any fault is detected in it. Any fault. Now, the pilot may attempt to restart it by manipulating the circuit breakers, but that's the pilot's option.

Reply on news.ycombinator.com