Blackout Bug: Boeing 737 cockpit screens go blank if pilots land on specific runways Boeing's 737 Next Generation airliners have been struck by a peculiar software flaw that blanks the airliners' cockpit screens if pilots dare attempt a westwards landing at specific airports. Amid the various well-reported woes facing America's largest airframe maker, yet another one has emerged from the US Federal Aviation …
Smaller helicopters have a lower rotor-disk loading than do larger ones, so consequently they have a wider autorotation envelope in case of engine loss. This provides more time for the pilot to select an emergency landing site, more time to manoeuvre to get there, and a lower momentum at the final landing. In other words, you're much more likely to walk away from a small helo crash than a large one, and more likely to find a landing site for a helo than for a fixed-wing aircraft.
I flew in one over the Southern Alps in NZ. Absolutely bloody spectacular and equally terrifying. We dropped down into the head of a fiord and I could see no-where to land so I assumed we were having a mechanical failure despite everything sounding OK. Eventually we homed in on a pile of rocks about a foot wider than the skids. I was almost as relieved as I was when I discovered I was too heavy for the tandem parachute jump I'd booked in for, Nothing worse than an active imagination and a knowledge of Newton's Laws and looking down from great heights.
You are perfectly safe flying down a narrow blind valley in a helicopter. It's the fixed-wing pilot who has to hope it's the correct valley and the runway at the bottom is serviceable and he judges the approch adequately.
If the helicopter pilot suddely realised he cannot land, he can slow sufficiently (to a high hover if necessary), do a 180 degree turn and fly back out. The fixed wingpilot cannot either slow down nor has the space to turn around.
Although flying in a valley is *extremely* disorienting because you have a false horizon all around and so cannot determine the aircraft's attitude visually.
As for landing on an area "about a foot wider than the skids" - that's no more an issue than parking your car in a space that's about a foot wider than its wheelbase. Absolutely trivial for any qualified pilot. I regularly landed a helicopter on a trailer that was barely wider than the skids. In fact it's easier than parking a car because you can move the helicopter in any direction. If you misjudge laterally, you cannot move a car sideways!
As for landing on an area "about a foot wider than the skids" - that's no more an issue than parking your car in a space that's about a foot wider than its wheelbase.
I do believe you on the manoeuvrability of choppers.. But if I was to 'touch the sides' while parking my car, or somehow back into a building or mast or powerpole or something, most I'd get is some scratched paint work or perhaps a dent. I don't think I'd like the idea of doing that with some fast moving rotors, even though they're likely to be moving away from me very fast should that happen.
I would dearly love to fly a chopper. Especially if I not only have a landing I can walk away from, but one the craft can immediately fly away from as well :)
I was almost as relieved as I was when I discovered I was too heavy for the tandem parachute jump I'd booked in for,
All I can say is... If you have the opportunity, go for it! And if you cannot for some reason you can fix, FIX IT!.
Jumping out of a perfectly good aeroplane with little more than a silk sheet strapped to my back is one of the best experiences I've ever, well, experienced. Those all-too-few seconds of freefall are incredible, very much worth the (sadly rather high) price of admission.
Of every thing I have done in my life, everything I have experienced, only my faith has held anything more enjoyable - and even then the tandem jump rates higher than most of that stuff :)
Icon ---> If that does happen, you won't have long to worry about it. But it very rarely happens, I can't remember the last time I heard of it in NZ.
Smaller helicopters have a lower blade-disc rotational inertia, giving less time for the pilot to react to a power failure or air turbulence . For example the Robinson R44 has about 4 seconds of rotor inertia available rather than 1.6 seconds for the Robinson R22, before the incident becomes unrecoverable. Smaller helicopters also are more likely to have teeter-totter blade disc attachment, with it's risk of mast bumping or tail chop off. Smaller helicopters are not necessarily safer.
"
... they have a wider autorotation envelope in case of engine loss ...
"
Completely wrong I'm afraid. The rate of rotor decay increases with the inertia of the rotor so bigger is better, but decreases with the drag of the rotor, so lighter is better. Therefore there is no general rule, though bigger helicopters IME have a slower rotor decay when it all goes quiet.
A pilot in a small two-seat Robinson (R22) has about 1.6 seconds to lower the collective in the event of an engine failure before the rotor speed decays so much that it becomes irrecoverable. The pilot of the larger (but otherwise similar) 4-seat R44 has 4 seconds to react - more than twice as long.
I am not a commercial pilot, but I do have a PPL(H)
I have done it only twice and I liked it, almost. It was between Nice and Monaco, (a meting with Fortune Computer).There is however only water between, and almost because the door by the front passenger suddenly opened mid flight. The pilot asked the passenger to keep it close with his hand which he did but he got awfully pale and I felt sorry for him.
Ah yes, if the weather is nice, it's a nice flight.
I once got sent there by the boss to help an old friend of his with some networking and stuff. It was a lot less glamorous than it sounds - sleeping on an inflatable bed, never left the apartment between being dropped off by the taxi and being picked up again for the flights back, and walking what seemed like bloomin miles through Nice's large terminal building. On that latter point, the checkin desks are at one end of the building, the helicopter part of the terminal is at the other end, as is the bit used by the cheap airline I'd been booked on - result, have to walk almost the full length of the building to get to the checkin desks, then walk all the way back again to the departure lounge :-( But I digress.
When we went out to the heli, I deliberately went for the front passenger seat - and it seemed no-one else wanted it. IIRC same on the way back. You get a much better view, although in the event of it all going titsup you are closer to the crash.
I was supposed to be getting the bus back, but my host decided to pay the extra for the heli back and get a few more hours work out of me.
Monte Carlo is quite an eye opener for someone not used to buildings on such steep ground. My host's apartment was on the 6th floor from street level - but looking out that side across the street was a school playground, which was on street level on it's other side ! Looking over the balcony railings on the seaward side was a different game altogether - it was a looooong way down.
Oh yes, an IT angle ? The number of WiFi SSIDs was incredible - I couldn't count them as the list would refresh long before I got anywhere near the middle let alone the end. IIRC it was something in the order of 50 or 60+ - that's a heck of a lot of contention given this was the days when only the 2.4G spectrum was commonly used.
And my laptop broke down during the trip :-(
I can thoroughly recommend reading "Chickenhawk" an account of a Huey driver in Vietnam.
I particularly liked the passage when he was on a rescue mission and was far too overloaded to take off in the tiny clearing he had landed in (he would need to be moving to get clear air).
So he just made the clearing bigger using the rotors...
As has been observed before, helicopters don't really fly. They beat the air into submission
Nah, that's not how they fly at all. The real reason is that they are so ugly, the earth repels them. That's what us fixed wing guys tell the egg whisk drivers anyway.
On the other hand, only yesterday I was telling someone that airplanes can't actually take off under their own power - that's why they tell you to put the armrests down before take off. As the plane sets off down the runway, turning fuel into noise, the passengers all grip the armrests and pull - and that's what lifts the airplane off the ground :-) For me, the funniest part of that joke was that the person I was telling it to really didn't know whether I was being serious or not !
OK, I'll get my coat.
In a previous life, my colleagues and I used to chopper around quite a bit—Wessex, occasionally Sea King, lots of Puma and a ton of deafening Chinook, one memorable ride in a Huey thanks to friendly Spams—and I certainly couldn't tell you to the nearest ten how many journeys—some of them almost embarrassingly brief—I made in the course of 12 years.
Since that time I've learned a lot more about helicopters.
I'm glad I didn't know then what I know now.
I remain mildly amazed that I'm still alive.
Many years ago I met a RN helo pilot who moved on to another avionics career. I asked him why. After the other five pilots in his intake of six had all died or been invalided out, he left!
(This was in the 70s, the eggbeaters were probably running on clockwork or something.)
As the old rule says:
"Take off is optional. Landing is mandatory - even if it requires lithobraking."
The problem with some airports is that it now can cost more in car parking charges for 15 minutes to drop someone off (the "express drop off" zone at London Stansted - not in even IN London) than the person you're dropping off may have paid for their return flight.
It’s statistically far-far safer then UK Roads and being scraped up by a Highway’ Agency Wombkw/Police/Paramedic holy trinity.
I’d speculate there are few dickhead pilots looking to shove their 737 in front of a 747 to get to the runway first with a bird being hung out of the cockpit window at the losing pilot in the other plane.
The military can definitely force someone to fly Boeing if that person is in the military.
Fortunately most of the aircraft with a Boeing logo on in the US military these days was actually built by other companies which have since been bought out, and the ones they've supplied recently (eg the KC-46) are mostly grounded due to Boeing-related issues (debris in the fuel tanks, cargo locks unlocking in flight, etc).
Ryanair apparently use the 737-Max (they've ordered over 200 of them for use from this summer onwards!), but can't tell you at time of booking if that's what you're getting, and (IIRC) won't give you a refund if you want to back out after discovering you're about to get on the twitchy plane.
This is Ryanair's planned seat configuration for the MAX (if they don't change their mind and decide to set it to be the same for both aircraft types):
Ryanair apparently use the 737-Max (they've ordered over 200 of them for use from this summer onwards!), but can't tell you at time of booking if that's what you're getting, and (IIRC) won't give you a refund if you want to back out after discovering you're about to get on the twitchy plane.
Not a problem for me, I just don't book with Ryanair anyway (and yes, I see their planes regularly, usually when they are crossing the highway on an overpass).
It's a bit trixy: One can carefully & responsively select an Airline (like SAS) that doesn't have Boeing and then they might farm over the actual flight to one of their Partners, which do, and the Partners are the only ones flying the way that you need to go!
This post has been deleted by its author
Boeing does seem to be having rather a bad year. Clearly a name change is in order. If you can guess the the new corporate moniker, I'd suggest grabbing the associated .com domain and selling it to them for enough money to finance a comfortable retirement.
Not to defend Boeing in any way, but they’ve got over 10,000 planes in the air and almost 6,000 more on order. Then they’ve got a telecoms empire, missiles, all kinds of weird microwave products as well as radar, IR and a corner on foundational remote sensing tech. They’ve also got a substantial financial operation, leasing services as well as third party support services for everything imaginable. Key to their ongoing success is their contract services for their products. Wall Street loves a company with over a decade of guaranteed future revenue...
The point is they are a very large company with interests in many areas. It takes a lot more than what they’re going through to bring down something that big.
As someone said previously, the only reason Boeing has so many successful products in "their" catalogue is because they have bought out the original manufacturer. But sometimes they even manage to stuff that up - they bought McDonnell Douglas for the MD(Hughes) 500 helicopter and the NoTaR technology but apparently hadn't noticed MD and McDonnell Douglas Helicopters were two separate companies, and MDH managed to keep the IP for both the 500 and NoTaR..
In my mind I have one part of the company writing a geometry engine than works with angles between -pi and +pi radians (-180 to +180 degrees) with +/-pi/2 (+/-90 degrees) correctly sanitised, and another part of the company writing higher level functions that sends it 0-2pi radians (0-360 degrees).
Not to mention of course that exactly which end of the runway you approach from when landing on a given day is more normally dictated by the prevailing wind conditions etc than anything else...
At some airports the wind is coming from a single direction about 360 days a year. Besides that, at an airport quite close to me there are some runways with restricted directions. Landings on those are always North to South, take offs are always South to North. Whether those runways are in use for take offs or landings depends in the wind direction.
Some runways are even more restricted - you take off in one direction, you land in the other, anything else means you become part of the scenery. Eg there's Courchevel Airport in the French Alps. Along with some others, you are only allowed to fly there if you've had specific altiport training.
On the approach, there is a point somewhat before you reach the runway where not landing (ie doing a go around) is no longer an option - there's not enough room to turn away and you aren't going to climb over the big lump of rock at the other end of the runway. So arrive at that point too low and you hit the big lump of rock the runway is built on, arrive too high and you either can't outclimb the sloping bit of runway in the middle, or you miss the runway and become part of the lump of rock at the other end.
Mind you, that's fairly tame compared with some places. I vaguely recall it may have been in Indonesia in Arthur Williams' series Flying to the ends of the earth" where they landed at one short strip that ended very abruptly at a rock face, and with a variety of bits of aircraft scattered around. That guy does some seriously "interesting" stuff - hence the icon, I'll raise one to him.
Not just simulators, from a report in El Reg from 2007, wraparound caused an early version of the F-22 flight software to kill the nav console when the plane's longitude changed from 180 west to 180 east.
https://www.theregister.co.uk/2007/02/28/f22s_working_again/
The smiley face of nostalgia - going through the comments on that article, I found my first ever El Reg comment (although as an A/C) ------>
Not really, this should really be covered by unit tests of the low level methods. I'm really struggling to understand what the bug could be to cause such an odd behaviour - I don't buy the comment on it being memory related, presumably some divide by zero issue but for that to blank out all displays is just staggering in how such a design could happen.
Testing all possible runways really shouldn't be needed as there shouldn't be anything special about them this fundamental, you can't test every possible starting position either.
If you thought that headings were significant, you'd probably just run a loop "for I in (1,360,1)" or maybe "for I in (1,361,1)" during unit test. Except that low level math routines usually work in radians, not degrees, so you'd probably do something like "for I in (0.001, 2.0*PI, 0.001)" which might or might not catch the error.
Software testing is **HARD**. Which is one of the (many) reasons that hardly anything works quite right.
If you thought that headings were significant, you'd probably just run a loop "for I in (1,360,1)" or maybe "for I in (1,361,1)" during unit test. Except that low level math routines usually work in radians, not degrees, so you'd probably do something like "for I in (0.001, 2.0*PI, 0.001)" which might or might not catch the error.
Except that runways only have 36 possible nominal directions and the problem also occurs in simulators.
Software testing is **HARD**. Which is one of the (many) reasons that hardly anything works quite right.
Wrong! I won't say it is easy, but proper software testing is something that can be taught and learned. The real problem is, that most programmers are too lazy to test properly. And yes, I am a programmer and testing isn't my favorite pastime either.
Dear Sir,
IMHO it's not that software developers are too lazy to test properly. It is more that software developers know too much about the software so they tend to test around its pitfalls.
Software testing, even test-driven-development and regression tests, *must* *always* *only* be based on the requirement specification. Even low level functions have requirement specifications. There's normally a number of boundaries in such a specification that determines the outcome of the low-level function. Those boundaries need to be tested in Unit testing. Unit testing, then, needs to be part of an automated regression test. Ideally, if certain boundaries cause unexpected results, the low level function in question should decline to run and instead throw some sort of an exception.
The one thing that is *hard* to test is the User Interface and / or User Experience... That's where the Business Analysts come in... These people know the business domain and have a good understanding of what the software is expected to do, so they need to get their hands dirty with regards to the test phase of a project... Be that through active testing, or through writing precise and detailed test script documents.
Best regards,
Guus
How many airports have runways approached from the West? And yet it is only a few where recent-build 737s should not go.
Besides, it is only on instrument approaches at these specific airports so, while it might not be tan(270) causing the problem "all by itself", some weird combination of lat/long coordinates, course, altitude, speed and old-fashioned Bad Luck might still explain it.
Either that, or some Boing programmer really hates those places for some reason and wanted to stop 'his' planes ever going there...
Helicopter icon, 'cos I'd still rather trust an ignorant drain pipe than several tons of quality Boing engineering...
This post has been deleted by its author
In particular, loose fan, compressor or turbine blades from an engine failure can act like shrapnel.
They are supposed to be contained by the engine housing, but increasingly, it seems, they have broken through - especially the large fan blades - as in the case of Southwest 1380 near Philadelphia.
The regulations require the nacelle to contain a broken fan blade, but assume that failed bits at the turbine end of the engine will escape obliging the designers to maximise systems segregation in the zones of the aircraft that could be impacted. This meant that despite the fact that the Quantas engine failed in a spectacular manner there was still enough systems redundancy to allow them to get back down.
"
I am not aware of any aircraft failure that has prevented the aircraft from getting back down.
"
All aircraft get back down, but not necessarily all in one piece or at a surviable vertical decsent rate.
For a case where an engine failure led to a crash (which some people survived due to some remarkable piloting), google United Airlines Flight 232 in Iowa in 1989. An uncontained engine failure severed all 3 hydraulic systems, which meant that none of the control surfaces were operational. The only control the pilots had wer the throttles of the remaining engines.
"Analysis of the preliminary elements from the incident investigation shows that an oil fire in the HP/IP structure cavity may have caused the failure of the Intermediate Pressure Turbine (IPT) Disc.". That was in engine no.2, and after landing they had some problems shutting down engine no.1, so there appears to have been some damage to its control system
The one with the total hydraulic failure was United 232, a DC10, where an uncontained stage 1 fan disc failure severed all three hydraulic circuits.
The big diference is that combat aircraft are expected to fly into areas where small bits of heavy metal often traverse through the airspace at supersonic velocities. Thus the chances of a turbine taking damage and shedding bits are intrinsic to the design. In civil flight, the design objective is for this kind of situation not to occur in the first place. Statistics show that this design objective is by and large valid.
Yet, when I fly, I try to avoid seating witin the ballistic cylinders of the engines, which has the added advantage of reducing noise levels where I sit.
Large photo of the purported 'shrapnel' damage can be seen here (there's a link above the photo to load the large version), and turns out to be rocks/other debris:
http://avherald.com/h?article=4d1aea51&opt=0
There's a large hole torn above one of the passenger windows, but also inconsistent with warhead penetrators.
However, there are very clear shrapnel type holes on what is either the elevator or one of the flaps, and indeed on what looks like the tail fin.
That doesn't preclude a loss of engine integrity being the cause, but it would be misleading to suggest the aircraft didn't show signs of damage like to have occurred prior to the unscheduled landing.
After having seen more photos of the damage (more available now at that link), in this case photos of both sides of the vertical stabilizer (i suppose they flipped it over), that puncture (seems to have gone clean through it) does suggest something of relatively high velocity striking it, from the side. I've seen more than my share of crash photos, but I don't recall having seen anything like that on a relatively undamaged tail; the vertical tail seems to be the one flight surface that often survives relatively intact, in all but the most forceful of impacts... plenty of exceptions, but it's quite often the single largest contiguous section of aerodynamic surface that remains after impact.
Not a new rumour, it's been around a while.
https://en.wikipedia.org/wiki/Boeing_Honeywell_Uninterruptible_Autopilot and elsewhere.
I didn't believe much of it back then, I still don't.
On the other hand, lots of people back then wouldn't have believed the Snowden revelations which largely turned out to be based on reality, and "everybody knew it was happening".
And on the other other hand, until recently most people didn't realise just how stupid Boeing management and their regulatory colleagues could be.
"And on the other other hand, until recently most people didn't realise just how stupid Boeing management and their regulatory colleagues could be."
In the case of Boeing Manglement and the FAA being self-serving pays better than being diligent or stupid.
This sounds such a silly thing, but shirley, the CDUs going blank is a symptom of a much more severe problem - that the computer controlling their output has crashed.
I can't see any way that entering certain lat and long co-ordinates could affect the power to the CDUs, but I'm prepared to believe a buffer overflow could perhaps corrupt the video memory, or alternatively just crash the nav comp.
I'd like to see the contents of every deleted message between the QA engineers and their maneagmenet...
ROFL
Engineers would not be deemed worthy to know Senior Management Email Addys. When I went to a Boeing site the workers had different easting places and entrances to the bosses. Mind you BAE wasn't that much different.
No, the backups wouldn't be receiving any runway information and would be immune to this bug. Most airliners will use mechanical backups and the few that have switched to glass backups are air-gapped from the rest anyway; usually equipped with their own AHRS/ADIRS units, pitot-static probes, backup batteries, etc.
I've also been seeing a lot of pilots carrying portable equipment lately. Personally, I carry a Garmin Aera 660 (GPS navigator and EFB), a Dynon D2 (GPS-derived Attitude, altitude, air speed, etc), and a Sporty's SP-400 (Comm radio with nav capabilities, including ILS). Essentially a full-panel between them; so long as the controls respond, I can land it.
Most airliners will use mechanical backups and the few that have switched to glass backups are air-gapped from the rest anyway;
Good. Glad they're keeping the planes air-gapped from each other. Could get quite messy if they didn't! :)
The bug itself is very troubling, but what is much troubling is what the bug implies about the quality of the software at large. First it implies a lack of bounds checking on the display unit. Second, a lack of testing on the display data inputs. Third, no checking of what the FMS is pushing out. Fourth, no one bothered to write a rational error-handling on the display unit in case values were out-of-bounds (especially since this causes the entire display to go dark instead of just a single value).
But what really worries me is that a software glitch can trigger a failure of all display units simultaneously, rather than just ones showing specific pages. SO would a bad value that is only displayed on one of those tertiary EIS display pages cause the displays to go out as well? What about garbage from the WX Radar?
They obviously do Agile and it is a Minimum Viable Product. It works most of the time.
Ah! That explains so much!
And here was me, when years past searching MS forums, that "MVP" was some sort of accrediation given to their 'better' support people!
(Although if the stuff MS churned out was what they classed as 'minimum viable", one of us needs to re-learn or re-think the meaning of those words! :) )
The shrapnel has been very much debunked by aviation experts and photo analysis-types as mud and stones. Holes don't tend to cast shadows.
We saw this with MH17. Initially people saw the back of the plane and thought they could see holes, meaning the missile struck there. This turned out to be completely inaccurate, and the photos of the front of the cockpit showed damage that was easily shown to not be mud/stones, but shrapnel damage.
Don't just report what people are saying, go and check the details out.
Really, every bit of evidence I've seen of the crash leads me to believe that the pilot probably just set take-off power, and left it at that power level for a bit too long and caused the turbine to overheat and eventually fail.
Probably left it at take-off power longer than recommended, trying to get as far and away as possible to minimize the risk of a repeat of IranAir 655 or MH 17. 99% of the time, leaving the engines at full power for extended periods of time is just going to result in needing the engine to be inspected and some parts replaced, and maybe a reprimand. And the engines were relatively new, so likely just a repeat of Southwest 1380 or 3472 would've been far likely the worst case.
The ADS-B data from the aircraft showed the aircraft climbed much quicker than what would be expected in normal flight, but would be consistent with staying at take-off power beyond the initial climb-out.
"the crash leads me to believe that the pilot probably just set take-off power, and left it at that power level for a bit too long and caused the turbine to overheat and eventually fail."
Keep reading. It's not that simple.
Takeoff at 06:12, crashed at 06:18. Source: various news reports agree
Engines: CFM56-7
Source: http://www.b737.org.uk/limitations.htm#Power_Plant
The take-off thrust, with the associated limits, shall not be used continuously more than 5 minutes. The duration may be extended to 10 minutes in case of engine failure in multi-engine aircraft. If the duration exceeds 5 minutes, this shall be recorded in the engine log book.
Source: Type Certificate Data Sheet on file with EASA, page 20 https://www.easa.europa.eu/documents/type-certificates/engine-cs-e/easae004
Even if the pilots ran the engines at TOGA power all the way into the ground, it wouldn't exceed the engine certification.
You should also learn about failure modes when engines go overtemp. They can certainly be damaged (this is why the event is logged, because the engine should be inspected), but that's more likely to result in excess fuel burn, oil consumption, and higher risk of future problems like an In Flight Shut Down (IFSD, each of which are recorded and tracked). The engine doesn't suddenly explode and set the aircraft on fire because you drove it hard for an extra minute.
II am well aware that it wouldn't explode the second it exceeded the limitations, which is why I said the pilot would risk the normally minimal damage to reduce the risk of remaining in dangerous airspace. I'm well aware that that even exceeding those limitations is almost always safe, I've pushed engines at 100% power for longer than recommended before, once pushing a BeechJet at 100% power for close to 25 minutes to get above an incoming Hurricane
Those specification are intended to apply to engines in normal conditions, not a hot-and-high airport like Tehran, and especially not one that was rushing their turn-around.
I am also basing my conclusion on how the aircraft's climb rate -increased at the 3 minute mark when previous flights slowed the climb rate at that point into the flight. At 2 minutes, the rate of climb is normally 1750 fpm, hits just shy of 2100 fpm, then tapers back down to 1700, at the 4 minute mark, and reducing to zero climb at the 7 minute mark. The doomed flight continued increasing its climb to over 2700 fpm up until the fateful moment.
I am also basing my assumption on the fact that the CFM56 engines have experience 2 uncontained failures in the last 3 years (SWA-1380 and SWA-3472). And in both cases, both were well within normal specifications. I suspect that the engines aren't quite as reliable as their certification documents say they are.
>Debunked by the actual experts working with the real data or perhaps by those kinds of experts ...
Well, not an expert but...
Shrapnel from what? no one seems to be saying what might have caused the shrapnel other than suggest that it couldn't have come from whatever caused an engine fire, they just say 'shrapnel' and nod their heads in agreement as if that is all the explanation needed.
When presenting on software development I used to say: "if aeronautic engineering was performed to the same quality standards as software development, planes would be raining from the skies".
As software intrudes ever more deeply into aeronautics, I've stopped using that analogy.
"International custom is for the manufacturer to analyse these boxes;" I don't think so. The analysis is by international agreement the responsibility of the aviation investigation authorities in the country of the incident (different rules if outside a country - https://www.emsa.europa.eu/retro/Docs/marine_casualties/annex_13.pdf. (Ignore the marine in the link, it is aviation)). Black box analysis, particularly in technically difficult cases, is most highly developed in a few countries and those countries are often invited to assist the responsible state. The assistance of manufacturers (or anybody else) may be sought but that is at the discretion of the responsible country.
A few years back I read somewhere that the software on planes really wasn't of the quality that might be expected. One comment was about the presence of lots of "if's and else's", obviously with the final else being trusted to just take care of everything else that might not have been thought of.
I won't have read it on Facebook or some such, it'll have been somewhere with at least half a reputation for having posters that might know what they're on about...
For the life of me I can't remember where it was now.. Can anyone close to plane software confirm - is the code absolutely tip-top, or closer to dog dirt?
I worked on an airplane that had a mysterious HUD blanking issue.
It was eventually traced to a missing & in a C statement. Resulting in a bit wise comparison instead of Boolean comparison of values.
It was found using a datarecorder I designed and playing the data back into a HUD om the ground.
Somewhere in the various customer sites I've worked on there was a vendor-specific serial data bus used for multivariable data logging at a few tens of kbytes per second on an RS422 serial line (which was typically operating at near maximum speed and with limited noise immunity). Whoever threw it together (I refuse to say "designed" it), they hadn't entirely thought it through - the "framing" of the data was done by a particular frame header pattern of data bits and bytes, and the authors had decided to ignore the historically wel known risk that genuine data might match the framing sequence, which could then result in the data transfer "losing sync". In the case of this application, connectivity could be lost until the transmitter was switched off and on again and/or the data values had changed,
I can't help wondering if something along those lines might be happening on these 737 cockpit displays - some kind of valid (but misleading in the circumstances) control sequence in the protocol is being mimicked by genuine data? I know a proper design would have a negligible probability of allowing that, but the one I'm thinking of was done on the cheap as an afterthought.
Both ARINC429 and ARINC664 properly implemented ought to be immune to this kind of issue.
Anyone know what the relevant 737's display panels use as data inputs? ARINC429? ARINC664? Other ?
The document at
https://www.boeing.com/commercial/aeromagazine/aero_04/textonly/ps02txt.html
says
"Advanced Common Display System Components.
The CDS comprises six flat panel LCD display units and two display electronic units (DEU)." (plus lots more), Elsewhere it talks about ARINC 500-series and ARINC 700-series inputs on the various generations of 737 but not immediately obvious what kind of datalink feeds the display units themselves from the DEUs in the recent "virtual cockpit" models.
We'll find out in due course. But there's a chance there may be more to this than simple software.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
