5 ms·

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

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!

sbradford26 8y ago
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.
- WalterBright 8y ago
  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.
WalterBright 8y ago
> 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.
- cryptonector 8y ago
  In a fly-by-wire design (which is de rigeur now), stopping all operations would be way worse than continuing.
  - WalterBright 8y ago
    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 https://www.digitalmars.com/articles/b14.html Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html
    - gizmo686 8y ago
      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.
      - WalterBright 8y ago
        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.
- hackits 8y ago
  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.

sbradford26 8y ago

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.

WalterBright 8y ago
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.

WalterBright 8y ago

> 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.

cryptonector 8y ago
In a fly-by-wire design (which is de rigeur now), stopping all operations would be way worse than continuing.
- WalterBright 8y ago
  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 https://www.digitalmars.com/articles/b14.html Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html
  - gizmo686 8y ago
    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.
    - WalterBright 8y ago
      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.
hackits 8y ago
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.