-
Airbus is not going to gloat too much because
All this shows is that those who write safety critical software are not supermen, and are probably no better than your nearest PHP hacker who has left SQL injection back doors all over the place
Probably the biggest thing that protects us is the fact that most of the systems are really old, perform very narrow functions (basically do the same thing every day; airline pilots tend to press the same buttons in the same order every time), and a lot of them (like jet engine ECUs) are carefully designed self contained boxes and then don’t get changed for many years.
Defects discovered by crew are reported internally, covered up immediately because the Daily Trash sharks are always circling, while the mfg sh**s itself and issues a rapid fix under the guise of an innocent sounding “feature update” so the certification agency never finds out
One might think the reason Airbus are not making political capital out of the B737 saga is because they are upright and decent people, but in fact they are keeping quiet because they know their cupboard has just as many skeletons in it as all the others.
Many years ago, 1983, I designed a multizone heating controller which had self-learning optimisation on the advance turn-on. It was all written in Z80 assembler. Many many hundreds were sold and installed (c. £500 each) and no bugs were ever found. Well, all of them will have stopped working in 2012. The reason is that it computed the day of the week from the date (which came out of a clock chip) and the algorithm I used was just a lookup table which took advantage of the fact (?) that a calendar repeats every 29 years, and I never provided for any subsequent 29 year period. I mean, it’s obvious, in 1983 I was 26, and when you are 26 it is unthinkable that you will ever be 55 because nobody who is of any interest to a 26 year old is that old. I left the company (my first business) in 1991, and it went bust in 1993. Go figure, as they say…
I recently spoke to someone who worked on the Honeywell KFC225 autopilot, introduced into general aviation c. 2000 and dropped c. 2003 due to widespread servo burnout issues caused by defective autopilot computer software (believed to be integer maths underflow / dramatic loss of precision). The software had one file per function, because the FAA would push for recertification if more than x functions were changed. If you had 100 functions in one file then any edit of that file changed all 100 functions. The result was an almost unreadable source code… -
GBU-39 Small Diameter BombBoeing, what an enigma. They make bombs to kill 3rd world people, to help make rich people richer, and they make nice planes, overall.
Boeing has never made a bomb. -
Doesn't surprise me at all. Boeing have also screwed up with Starliner, but I see the same issues at other similar companies.
Many projects I have ended up asking "what happens when this timer counter wraps? Have we tested it?". Frequent answers are "don't worry it will not matter". Even if that is true at the time, later coders don't realise, and use it for a purpose where it does matter. We had a bug where random "EEPROM timeouts" were reported, turned out to be a false error due to a timer wrap.
Other frequent answer is "it's too difficult to test". Obviously testing a product for it's lifetime before release is impractical, so one has to be smart about identifying the timer limits and devising tests with special code if necessary.
We were recently requested to add a so-called "safety layer" for an aviation product, it adds a timestamp to each message to identify stale data. Obviously I immediately asked "what happens when...". The answer in this case, "it's not our problem, we've been told to implement according to the spec".
Y2K was a specific instance of a class of bugs, but those same bugs are everywhere in embedded software, even software supposed to be "safety critical". There is an assumption that "implementing to the spec" automagically means good code. Quality becomes a box ticking exercise, it's like a cargo cult. Coders and managers alike continue to operate in blissful ignorance, while the project slips further behind schedule. -
Boeing has never made a bomb.
Maybe not the part that actually goes bang but https://www.boeing.com/defense/weapons/ -
"The FAA has received a report indicating that the stale-data monitoring function of CCS {common core system (CCS) – a Wind River VxWorks realtime OS product} may be lost when continuously powered on for 51 days"
Sounds like its technically not Boeing's fault here, it is the (VxWorks) OS they used. What else uses VxWorks that could also be affected? Airplanes, Rockets, medical devices?, nuclear launch controllers? -
you can't blame a subassembly for a failure unless it happens after it passes testing and is released, otherwise you did not integrate it correctly IMO
-
My point was more that its not just a Boeing subassembly, its used in other places so other things could have issues as well.
-
My point was more that its not just a Boeing subassembly, its used in other places so other things could have issues as well.
scary to think there is a missile silo or detection radar system some where that happens to do a generator test monthly and its not been found.. god forbid someone gets lazy. I wonder if the military is more prone to this (perhaps a UPS can be considered a reliability problem and they would rather tolerate a small power down for seconds on a generator, or budget cuts)? Also mobile things that setup temporarily but connect to a complex sensor grid might have this undetected, used for training frequently, etc (SAM stuff maybe?) -
Boeing, what an enigma. They make bombs to kill 3rd world people, to help make rich people richer, and they make nice planes, overall.
Boeing has never made a bomb.
Unless Wikipedia is wrong, they make rockets and missiles.
I'm not sure if they make the explosive payloads themselves, but even if they don't i think it's fair to say they make weapons of war.