> But for safety critical projects, the no rtti, no exceptions rule > is pretty common isn't it? Not sure if it's justified or not, but > very common from what I hear. Something to do with code verification, > provability?
I'm a little rusty, but my memory of life-critical avionics certification was that they do not allow exceptions, or dynamically allocated variables (malloc), or even stack type variables (my). The Boeing 777 had a whole bunch of code that got executed at regular intervals. some stuff ran at 120 hz. most ran at 30 hz. I don't know how they did the timnig synchronization to make sure they didn't run too fast, or how they detected if they ran too slow. But the code I was working on was basically nothing but Q-notation arithemetic that mapped to control logic diagrams written by the aero guys. inputs might be sensor data or outputs from other calculations, outputs would be either control surface control values or variables to other blocks of code. Control flow was extremely rudimentary. There migth be an "if" loop to make sure you dont' divide by zero. occaissional range checks were probably the most common control flow structure. I don't remember ever seeing a "for" loop. Object oriented anything was completely out. All variables were static package variables. Ada packages prevented them from being global and so made sure no one else mucked with your data, but they were static, compile time variables. Basically, pretty much all the code always executed every time it got called, and it was supposed to get called at a fixed frequency. Code coverage was meaningless, since almost everything executed on every call. Instead we looked at coverage from a data perspective. Verification consisted of inputing data at min, min+1, middle, max-1, and max for all the input variables and making sure the outputs were in the ranges specified by the documentation to make sure the aero guys got their numbers right and make sure the code compiled and executed correctly. And it was all Q notation (integer math) written in Ada because verifying/certifying floating point algorithms and floating point hardware would have been insane. I do know that non-life critical avionics (an LCD panel that acts like an artificial horizon in the cockpit) did not require nearly as strict requirements. We could do for loops and other more cmoplicated control flow structures. But we had to guarantee our worst-case execution time was always under some fixed amount. It ran at 30 hz or similar speeds as well. The stuff I worked on was again all integer math/Q notation. One algorithm I wrote was an inverse sine function that took in a number and returned the angle. It did a binary search on a table, found the two entries closest to the input, then interpolated between them for the final value. Given teh table size, you could guarantee, by design, what the worst case delay it would take for the function to return. > Not that that gives any lessons for application code > in other domains, necessarily. If I remember correctly, the hardware on the 777 consisted of three processors built by three different manufacturers (in case one manufacturer had a bug) all running the same code with hardware voting logic and such to flag a bad calculation. Not something you'd see in a web server company. I talked to someone more recently who was working on some cockpit display box. The FAA had loosened their requirements to teh point that they were goign to use C or C++ and use dynamically allocated variables. Malloc or soemthing. I don't know if the FAA has similarly loosened their requirements for life-critical avionics or not. But I guess I'm old-school when it comes to life-critical applications. Most code has bugs and most coders write buggy code . And the only way you'er going to achieve hundreds of thousands of hours of hardware/software operation without a single glitch is if you keep it simple stupid. _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
