CAA bans Boeing 737 max 8

That would be great.

One of my favourite aircraft musuems allows people to crawl around in the aircraft, sit in the pilots seat, pretty much anything.

Among other hightlights, I've sat in a Canberra bomber pilot seat, a F111 pilots seat, and crawled around the insides of a P2 Neptune

A gang of us (including the Master) paid off a ship in Colombo and flew home with BA in a VC10. Once we got in the air and had been fed and watered our OM told one of the stewards that he was a ship's captain and wondered if the plane's captain would let us have a look at the cockpit.

We went up in pairs and spent a good hour each having it all explained to us. Brilliant.
 
Also, whoever brought that baby who is going nuts in the video needs to be shot. Basic etiquette.
Never understood why people bring babies/toddlers to events like this.

Years ago I was helping out at a car/aviation show day. One of the highlights was this bucket of bolts firing up every hour.


This car was seperated from the general public by a string line fence about five metres away.

They'd announce it was starting up, people would race over with their kids to see it and then have to run away with the babies/kids bawling their eyes out from the noise.
 
Last edited:
Rabin even recalled an incident where senior software engineers were told they weren't needed because Boeing's productions were mature. Rabin said: “I was shocked that in a room full of a couple hundred mostly senior engineers we were being told that we weren’t needed.”

This.

All too often, management take the view that software is somehow "easy engineering" - would Boeing outsource its aerodynamics to a bunch of new graduates, and expect success? Or suggest that the undercarriage design be outsourced to a bunch of $9 an hour mechanical engineering graduates? The complexity is easily the match of other disciplines; it's just that civil engineers can't get away with knocking up a shit bridge, saying it's "agile design", and fixing it after the first few cars go into the river. Nor can the metalbenders excuse themselves if the brakes fail, or the engine siezes. Yet, somehow, corporations appear to believe that software doesn't need design, doesn't need quality built in from the start.

There's also a slight undercurrent of "blame brown-skinned software engineers" - foolish, because I've worked with some bloody good Indian engineers. IMHO it's the desire to skimp on costs, and the perception that software is easy to patch, so why not just farm it out? If they'd pushed it out to a US company filled with cheap entry-level graduates, they'd have seen the same outcome.
 
Rabin even recalled an incident where senior software engineers were told they weren't needed because Boeing's productions were mature. Rabin said: “I was shocked that in a room full of a couple hundred mostly senior engineers we were being told that we weren’t needed.”

This.

All too often, management take the view that software is somehow "easy engineering" - would Boeing outsource its aerodynamics to a bunch of new graduates, and expect success? Or suggest that the undercarriage design be outsourced to a bunch of $9 an hour mechanical engineering graduates? The complexity is easily the match of other disciplines; it's just that civil engineers can't get away with knocking up a shit bridge, saying it's "agile design", and fixing it after the first few cars go into the river. Nor can the metalbenders excuse themselves if the brakes fail, or the engine siezes. Yet, somehow, corporations appear to believe that software doesn't need design, doesn't need quality built in from the start.

There's also a slight undercurrent of "blame brown-skinned software engineers" - foolish, because I've worked with some bloody good Indian engineers. IMHO it's the desire to skimp on costs, and the perception that software is easy to patch, so why not just farm it out? If they'd pushed it out to a US company filled with cheap entry-level graduates, they'd have seen the same outcome.
It's not about the color of the skin - I've come across all types who have been shit at engineering - including me - it's all about design practices and ethos. Especially in complicated systems. And having a set and defined process with regards to systems engineering testing and validation.
 
It's not about the color of the skin - I've come across all types who have been shit at engineering - including me - it's all about design practices and ethos. Especially in complicated systems. And having a set and defined process with regards to systems engineering testing and validation.
Strongly agree.

I started in a firm that did mission-critical systems for defence. It was old-school engineering, proud of what it produced; and that pride came from quality and performance. The culture lent itself to continuous improvements of what we did, and how we did it - but it took a lot of effort, and management had to buy in - not just pay lip service.

I've worked for firms since who didn't have that attitude to improvement, or to quality. It's not fun; so as a professional, I tried to rearrange the deckchairs (sorry, improve the bits I could improve, and demonstrate a commitment to quality by example).

"Set and defined process" isn't vital in a written-down sense, so long as there's a clearly understood "this is how we do things" ethos, that is actually believed in, and followed, by everyone on the project. If that's three or five people, you don't need to write it down - but you do need that common understanding. If it's thirty, you might get away with it, using lots of (short) face-to-face meetings. But the undocumented processes that worked for a startup in a single building, just don't scale to a team of hundreds spread across multiple sites - and the chief engineer needs to understand that and deal with it, no buzzwords, no jargon. Too few realise that, in enough time to avoid the Big Ball of Spaghetti Design.

Yes, there will always have to be design compromises. Sometimes you accept that you're taking a shortcut, and patch it ugly - but you do so with a plan to fix it later (rather than doing everything ugly, with a wave of your hands and insistence that it will all be fine and fixed later). It's a bit like Staff Work - the bulk of execution is coping with the chaos and cockups from trying to achieve "good enough, now", and not "perfect, but too late".

I've always thought that BGHQ and Bde HQ is rather like a software project - trying to write an item of code in the "Orders" programming language. They are very, very similar problems. I've often thought that CAST and the Doctrine Development people should go and talk to the Software Development gurus (the good ones, not the ones trying to sell a silver bullet) - not because they've got all the answers (they haven't) but to see if there are any areas where they can learn from what has worked, and what has failed. To see what approaches have been tried, and which ones worked in which situations.

There are how many Formation HQs and CAST exercises in the British Army? How many Staff Officers trying to write a "program to run a BG/Bde Operation"? And how many software development teams in British industry, who do this day in, day out?
 
Yes, there will always have to be design compromises. Sometimes you accept that you're taking a shortcut, and patch it ugly - but you do so with a plan to fix it later (rather than doing everything ugly, with a wave of your hands and insistence that it will all be fine and fixed later).
This - I've never worked on a project where you had enough time/ resources to get everything absolutely right the first time within the time frame but actually had to make sure to document what was pending and what are potential risks, make them clear and how we were going to handle them, moving forward.
Christ, I almost feel like I should get back into engineering..
 
More info on the chip / software tests by the FAA last week. The FAA imposed a fault condition and a scenario which led to a similar condition to the two lost aircraft:

View attachment 401394

View attachment 401393

View attachment 401395

Sounds like inefficient code run on chips designed to run efficient code and now they want to load share across available chips with some supposed processing availability...

View attachment 401397

FAA and Boeing initially disagreed on severity of "catastrophic" 737 Max software glitch
There's not enough information there to tell what the problem actually is, so I wouldn't jump to the conclusion that it's anything to do with "inefficient code". The article said they created a fault in the microprocessor.

Last week, the Federal Aviation Administration intentionally broke part of the 737 Max’s flight control computer. Inside Boeing’s engineering flight simulator in Renton, Wash, test pilots flew a scenario causing a fault in a microprocessor that lives in a box underneath the floor in an electronics equipment bay of the single-aisle jet, according to two people familiar with the situation.

The result, which both people say was expected as part of the scenario, caused the jet’s simulated horizontal stabilizer to move on its own, swiveling the jet’s nose downward as it began to lose altitude in the simulator. The test pilot initiated the runaway stabilizer trim checklist, according to the people, but found the electric trim switches on the pilot’s yoke unresponsive as the stabilizer continued to force the jet’s nose down even further.
It sounds like when there is a fault in one of the microprocessors, this has the unintended effect of triggering the the same action as when the MCAS system kicks in. This may be more of an unintended response to a loss of output from the microprocessor rather than just slow software.
 
(...) There's also a slight undercurrent of "blame brown-skinned software engineers" - foolish, because I've worked with some bloody good Indian engineers. IMHO it's the desire to skimp on costs, and the perception that software is easy to patch, so why not just farm it out? If they'd pushed it out to a US company filled with cheap entry-level graduates, they'd have seen the same outcome.
There are no doubt quite a few good software people in India, but they will know they're good and won't be working for $9 an hour. What you're going to get for $9 an hour is a warm body with a fake CV (helpfully put together by the recruiter) and quite likely a counterfeit university degree to go with it.

If you want some routine business process software knocked together in Java, you can probably find loads of people in India who will take $9 an hour. Experience and qualified aerospace software engineers though are a little more thin in the ground there, and you're not going to get them for peanuts.

This is so well known in the software industry that anyone at Boeing who claims they thought they were hiring adequately qualified and experienced people on the cheap are clearly lying through their teeth.
 
The following is for a Boeing 787 rather than Boeing 737 Max, but it's relevant as it shows the sorts of things that go on at Boeing. www.cbc.ca/news/business/boeing-air-canada-jet-fuel-leak-1.5193550
A Boeing 787 which was sold to Air Canada developed a fuel leak after delivery. An investigation turned up that Boeing has falsified the production records for the aircraft, claiming that certain work had been done which was not.
Boeing staff falsified records for a 787 jet built for Air Canada which developed a fuel leak ten months into service in 2015.

The records stated that manufacturing work had been completed when it had not.
According to an aviation expert, the falsification of these records is a serious safety problem.
On the latest revelations related to falsifying records for the Air Canada jet, Mike Doiron of Moncton-based Doiron Aviation Consulting said: "Any falsification of those documents which could basically cover up a safety issue is a major problem."
In the aviation industry, these sorts of documents are crucial for ensuring the safety of aircraft and the passengers onboard, he said.
Apparently in 2015 Boeing paid $12 million to the US FAA to settle ongoing investigations. As part of the settlement Boeing was to deal with certain safety issues. However, some of the enforcement of safety was delegated to Boeing itself.
In 2015, Boeing paid the FAA $12 million US to settle ongoing investigations. As a part of the five-year agreement, Boeing agreed to work with the agency to address safety oversight issues within the company.
That agreement details an "obscure program" that delegates some safety checks to Boeing itself, said Michael Laris, a Washington Post reporter who has looked into many of Boeing's safety issues that prompted the agreement with the FAA.
Questions are now being raised as to whether having Boeing police themselves is a good idea.
After the devastating 737 Max crashes, Laris said questions are being raised about the effectiveness of Boeing's oversight program.
According to Transport Canada, the falsified documents relating to the fuel leak issue are under the jurisdiction of the US. However, Transport Canada are taking all of this into account when looking into other safety validation efforts relating to Boeing.
Transport Canada said the incident involving falsified documents fell under the jurisdiction of the FAA.
Transport Canada said it is evaluating how all of this new information emerging about Boeing will impact ongoing aircraft safety validation efforts.
 
Despite the doom and gloom surrounding the grounding of the Max Boeing has received a badly needed massive shot in the arm from IAG.

Parent company of BA and a couple of others has just placed a huge order for the type.
IAG (British Air) gives huge boost to MAX - Leeham News and Analysis

One has to hope however that Boeing manages to sort their problem out with the FAA, for this not to turn out as a bit of a gamble.

There is a very well informed site that has provided good analysis of the initial and ongoing details of what happened and what is being done about it. This has uncovered a further ‘wrinkle’ that may prove difficult for both Boeing and the FAA.

In fact an ongoing safety aspect that seemingly was never discovered or brought to light before now, but may bring a further set of problems in the recertification of the latest 737...and to earlier models.
MoA - Boeing 737 MAX Crash Reveals Severe Problem With Older Boeing 737 NGs
 
Last edited:
The contradictions in this whole tragic saga are mind bending.

Get brown skinned software engineers to do the easy stuff then blame brown skinned pilots for being incompetent.

Having made the assumption that brown skinned pilots are incompetent, remove training to save costs.

As has been pointed out, essentially commit fraud by circumventing the Certification process.

Short interval to crash 2 aircraft in quick succession (and kill @350 people).

Blame brown skinned pilots / software engineers, involve test pilots from Certifying Authority (now considered essential part of the process, anyone seen my horse, I need to shut the stable door?).

Test pilots unable to fly aircraft in failure mode in question.

And my prediction for Boeing’s next move once blaming everyone else falls on its arse: Starbucks (HQ down the road) order in extra humble pie.
 
Test pilots unable to fly aircraft in failure mode in question.
One thing which jumped out at me was that the simulator didn't replicate real life. Simulators only do what they're programmed to do. In this case once the 'problem' was active and the speed got high it was simply physically impossible to turn the trim wheel enough but that never made it into the sim.
 
One thing which jumped out at me was that the simulator didn't replicate real life. Simulators only do what they're programmed to do. In this case once the 'problem' was active and the speed got high it was simply physically impossible to turn the trim wheel enough but that never made it into the sim.
Weirdly, you just reminded me of this...not the same thing at all..but it just popped in my head...


 
I would have thought that comparing the Nimrod fiasco with the 737Max fiasco is the last thing a Boeing fanboi like yourself would do.

In any case, I can’t see how the two are anything other than remotely related, as the real scandal with the 737 Max isn’t the faulty technical solution but the way that Boeing undermined the certification process and tried to hoodwink their customers.

Furthermore, I believe that I have read somewhere that stability augmentation systems have been used successfully on other aircraft to overcome design related stability issues. The B52 being one example.
the stability augmentation system fitted to the B-52’s in the 60’s was to smooth out the ride and stop their very bendy airframes doing this in turbulence.

1561972922158.jpeg


It’s failure mode is a bumpy ride, not an uncontrollable plane.
 
Last edited:
more pertinently, what was the correct solution to the 737 MAX' problems. oh wise one?

The correct solution is that the 737 MAX should have been recertified as the all new plane it actually is. It’s not a 737 except for the ‘737’ in its name.
 
One thing which jumped out at me was that the simulator didn't replicate real life. Simulators only do what they're programmed to do. In this case once the 'problem' was active and the speed got high it was simply physically impossible to turn the trim wheel enough but that never made it into the sim.
And of course the simulator would have only been programmed to do what Boeing told the simulator company to do.
 

Similar threads


Latest Threads

Top