By Scott Hamilton and Laura Mueller
Update, March 9, 2023: Some readers have interpreted this story as reporting that new deliveries directly from Boeing are being delayed. The wording is somewhat ambiguous. To clarify, airplanes purchased by lessors–who have taken delivery from Boeing–are experiencing delays in delivery to their lessees due to the issues with the Boeing software reconfiguration described.
March 6, 2023, © Leeham News and Airfinance Journal: A new issue with a software program is delaying deliveries of some Boeing 737 MAXes by up to a year, joint reporting by Leeham News and Airfinance Journal learned. The Federal Aviation Administration views its use as a safety matter that must be resolved before delivery on aircraft undergoing reconfiguration. It is not a safety issue when aircraft are delivered to the originally intended operator.
The Boeing software, called Option Selection Software (OSS), is used by Boeing to identify software installed on 737 MAXes that must be reconfigured when the airplanes are going from one airline going to another. For example, if a 737 was built for Airline A and instead it will go to Airline B, reconfiguring the cockpit display and related systems may be necessary. We are told that MAXes and 787s are impacted, given their large inventories of airplanes that have been stored long enough that some original customers no longer wanted the aircraft. When sold or reconfigured for a different operator, Boeing uses the OSS to reconfigure the software and identify related parts for any changes.
This issue has not been reported previously.
A retired Boeing employee said that the reason that fully functional OSS software is so critical to Boeing is that the assembly paperwork systems used by Boeing in the factory (Product Data Manager and Catia/Enovia) to define the job sequences lack the ability to indicate the software revision levels loaded into the black boxes. That data is not found on the face of the engineering drawings.
The retired Boeing employee continued that Boeing identifies and installs each black box per their engineering drawings and then has the vendor supply the correct software for each specific. Boeing has separate assembly jobs in the factory that load and record the software program and revision level for each black box installed. This data is supplied by the black box maker to Boeing outside of Boeing’s Drawing Control System.
The ship’s record assembly paperwork that is stamped and inspected showing this data is not electronically searchable for the software info. While the Boeing drawing tree tells you the wire bundles and black boxes installed in each airplane, the drawing does not tell you what software was loaded. This seems to be the crux of the issue, the retired employee said.
Boeing, which did not answer specific questions, instead provided this statement through a spokesman:
“As the commercial market recovers, there have been delays in execution of certain modification work. We continue our relentless effort to deliver on our customer commitments and this focus has helped identify areas that we can improve.
“We’re taking comprehensive action, from an increase in engineering capacity to process improvements that enable on-time delivery. As a result, we are enhancing quality, stability, and predictability throughout our modification business and our customers are starting to see our progress.”
The FAA declined to comment on the specifics, but said, “our interest is what you’d expect it might be for the safety ramifications of any aircraft-related software.”
Additionally, reconfiguration may also be required when going from one regulatory jurisdiction to another—for example, from the Federal Aviation Administration’s authority to the European regulator, EASA. The reconfiguration requirement does not affect the cabin; it’s only for the cockpit and related systems and parts.
Initially, it was thought all 7-Series airplanes were impacted. But only the MAX and 787 appear to be affected.
New production airplanes that are switching operators before delivery appear to be affected. New 737s ordered by the company 777 Partners, which planned to lease them to Canada’s Flair Airlines, instead were sold by Boeing to other lessors before delivery to Partners. The new owners had their own customers in mind. Initially told that the cockpit could be reconfigured within two months, the software issue emerged and blew up this timing, lessors said. Now, reconfiguring the software won’t happen until January 2024 (plus or minus a matter of weeks).
Lessors said that historically if a lessor wanted to repurpose an FAA configuration to EASA metrics, it might be weeks and no more than 2-3 months for manuals and pin selection changes. Today, the lessor is in a queue of perhaps six months to receive attention and then a quote of six months to complete the tasks.
Lessors Altavair, BBAM, and BOC Aviation are affected with MAXes. Lessor AerCap is understood to be affected with Boeing 787s. There may be others.
Boeing has 138 MAXes in storage ordered by and built for China’s airlines and an unknown number for other airlines that ceased operations during the pandemic. LNA/AFJ are told that these airplanes may also be impacted, though Boeing denies it.
Boeing CEO David Calhoun announced in September that Boeing was going to remarket these airplanes, which the Chinese government has so far refused to authorize delivery. But Calhoun reversed course in January, announcing on Jan. 26 that remarketing the aircraft is “paused.” Calhoun cited appearance of a thaw in US-China relations as the reason. (Days later, tensions heightened again when a Chinese spy balloon entered US territory. It was eventually shot down off the coast of South Carolina.)
However, the timing suggests the pause may be related to the software issue. LNA/AFJ are told the issue was discovered in the Autumn 2022, shortly after the initial decision to remarket the Chinese airplanes. Multiple sources say the software issue is why Calhoun reversed course.
“I am not surprised that Boeing denies that the pause in remarketing white tail Max’s is linked to the problems but it definitely is a huge part of it,” said a person familiar with the situation.
What happened to cause this disruption?
As a legacy of MAX and 787 gaffs, the FAA insists upon complete validation that the system standard is flawless. Experience with this process is unproven and has rarely been necessary in the past. The software is supposed to produce data on a number of operating functions and identifies certain systems and parts that need reconfiguring. LNA/AFJ is told that the OSS isn’t necessarily identifying all that needs to be reconfigured.
The software challenge seems to be rooted in the ability to validate that the existing standard is the current standard. LNA/AFJ is told that the FAA put a “pause” on the process (to borrow Calhoun’s word) while Boeing figures out how to validate the process.
“The FAA has lost all confidence in Boeing,” LNA/AFJ are told.
The repurposing effort runs head-first into a cavalcade of demands on engineering resources (e.g., certification completion of MAX 7/10, 777X, engineering replacement on P2F work that had previously been assigned to Ukraine/ Russia, and a plethora of return to service demands on Boeing from the pandemic’s parked planes). The queue of projects is wildly outstripping the availability of engineering resources. And, the pandemic led to an exodus of proven/experienced talent. Now, the replacements may be learning these tasks and assignments for the first time.
The question being posed by the FAA is “if this software is not recording MAX display software configuration software correctly, what else is impacted?” said a person with knowledge of the situation.
The problem applies to 787s as well, but far fewer are involved. However, this is unrelated to the most recent pause in deliveries, which Boeing attributes to paperwork and analysis of the forward pressure bulkhead.
Boeing previously paused deliveries of the 787 when small gaps, the thickness of a piece of paper, were discovered on some newly built aircraft. Boeing built 115 787s during the pause. The FAA put Boeing through a meticulous review process (some complained of FAA nitpicking) before authorizing the fix and allowed Boeing to resume deliveries. It takes five months to rework the built airplanes.
Nearly all customers kept their orders, but there are a few airplanes that are going to a different airline than originally intended. These must go through the cockpit reconfiguration process.
All the customers were given revised delivery schedules after Boeing received authorization to resume deliveries. Now, many customers are being notified that there will be another round of delays of six to as many as 18 months. It’s unclear if this new round of delays is exclusively for the reconfiguration issue. At least one customer points fingers at Rolls-Royce for delays in delivering its Trent 1000 engines, which have been subject to technical issues dating to pre-pandemic times.
Some airlines are complaining that it is taking Boeing up to two years to complete the cabin reconfiguration paperwork, an issue apparently separate from the OSS.
The OSS is also having trouble reconfiguring the Boeing 747-8-based VC-25, used as the US presidential airplane Air Force One. Two whitetail 747-8s were purchased by the government for conversion to Air Force One. These were ordered by the Russian airline TransAero, which was unable to accept delivery. (This long predates the Russian invasion of Ukraine.) The VC-25s, at Boeing’s facility in San Antonio (TX), must be reconfigured from the TransAero system and configured for the military’s specifications. Operators of the OSS have been trying for two years to identify what needs to be changed. Inexperienced personnel due to turnover is identified as the principal reason for this problem.
It took Boeing 20 months to recertify the MAX and nearly as long to receive FAA approval to resume deliveries of the 787. Now, it’s facing another lengthy process. Although the issue was discovered in the Autumn (the exact month is unknown to LNA/AFJ), “Autumn” runs from September 21 to December 21. Boeing hopes to have the Software validation and approval by the end of April. There is no guarantee this goal will be met.
Laura Mueller is content director at Airfinance Journal. Scott Hamilton is editor of Leeham News.
I’m not completely clear, presumably this problem also affects secondhand airline to airline sales?
This story is extremely valuable information to Chinese airlines, if I were them, I would would declare that I am now prepared to accept delivery if Boeing is prepared take $5 million off the price.
On tbe subject of China: one wonders if the “primitive” ARJ21 and C919 suffer from such basic (and inexcusable) software shortcomings…?
I doubt it.
I’d doubt the ARJ21 and C919 have less programmable parts than a 737, which retains many elemts from the rather ancient original 737 design. So yes those manufactorers would have to do the same compliance work when delivering to other jurisdictions. That only shows how complex it is to sell and support planes globally.
If they’ve organised that better or thought of it at all yet, who knows.
Is any of this legacy software for which a replacement should have been funded? Or is it disjointed/connected recent software? In other words, is this largely down to penny pinching or is it largely down to technical competence?
If I got it right one aspect is that hardware is Boeing managed (proper drawing #) while Firmware is supplier managed. Proper linkage is missing.
( in a way the issue that brought down one A400M where a mismatch between FADEC “language” and airframe “language” was introduced. incopatible SW revision sets )
What was the norm is that a customer on the line would purchase all the black boxes outside the Boeing procurement system and Boeing would install them for the purchasers. BA would then get the software bumped, loaded, flashed or whatever you call it for the purchaser. This worked great. The change is that on an aircraftreconfigure, the black box ownership has changed, and its that, the factory support package ended. The black box manufacturer will load the correct software for the new customer BUT the process is different than a complete load on an empty memory. The vendor needs to know what’s in the box as a starting point so they can validate correct function of the reconfigured box AND all the boxes that talk to each other must be updated en mass, so that all the boxes give correct responses to interface inquiry…… Like many things, it’s simple in concept but complex at the execution point……
Are you saying the vendor didnt store a version id in the box that can later be read out by their software used to update the box with a new version?
IMU it is not
version old vs new
selected _option sets_
( changing from customer to customer with a sublevel in different order batches.)
Either you have some versed people around
or you have designed an SW tool that does option matrix compatibility checking.
I do wonder: the AoA mismatch indication that was borked on the MAX ( ordered or not by customers) may that have been fallout from the same problem domain?
( up to now I had assumed that to be caused by insufficient regression testing on the base SW )
All the reconfigurable boxes store their data internally. OSS queries the entire aircraft to produce the equipment list along with the revision list of the software inside. That’s the story, the software querying the airplane isn’t functioning correctly. The data being returned does not match what actually exists. There’s a lot to go wrong because you cannot make the assumption that every box will always play nice with each other and that they are universally updatable to something safe to fly…. let’s take a radio altimeter output. They are either in feet of meters. The pin outs may be different between boxes and the wire bundles may be incompatable. All these combinations are pre flown by computer analysis and the specific wiring for each plane is assembled for each specific customer/line number. If the software can’t reliably read the airplane, as reported, there’s a TON of manual work needed to do the same tasks
So, am I correct then in understanding this discussion that there are 3 points where this problem could have been avoided:
1) Boeing is allowing too much user customisation (feels like the A380);
2) Boeing (or whoever it contracted) has not reached sufficient technical competence on the query s/w; or
3) The “black box” industry (I guess IEEE) has failed by not implementing sufficiently clear standards?
And actually the original 787s had incompatible SW from what the vendors had to what Boeing had… Do we think there could be a trend here?
It is a recuring issue. spectrometer boxes for
SOFIA had unknown/incompatible software loaded.
No connection between software blob and the source code that created it.
Well done software either errors out early on linkup to an incompatible SW revision or has fall back designed in.
Actually creating breakage with interface changes is a thing to be avoided at all cost. you can expand with new stuff but never change working stuff.
You can chance the SW behind that interface to work differently. But the interface as defined must persist.
No, there’s no trend here. There’s not even an issue here. The situation is the same as you’d find if you went shopping for a particular model of Wi-Fi Router or laser printer… until you get home and power it up, you will have no clue as to the software version loaded. Of course it will be one of the software versions issued to-date by the OEM, but exactly which one will depend on the logistics of inventory and spares handling, most likely it will be the version that was current at the time the equipment was manufactured, but may have been updated later somehow or reverted to the. version built in as a “Reset to factory” version. It really doesn’t matter, because your responsibility as the end user is to make sure the latest version is loaded before you put the unit into service and then maintain that status while it is in service.
Avionics isn’t really much different. The article tried to explain (rather poorly) that you never really know “what’s in the black box” until you power it up and query it to find out. To avoid schedule delays, malfunctioning avionics with no MEL relief are often fixed by way of replacement with a known good unit “stolen” from an airplane sitting at a nearby gate that has a later departure time, with the expectation (hope) that a good unit will arrive from the parts store by that time. If it doesn’t, a cascade of robbing Peter to pay Paul may ensue, with each airplane logging an unscheduled removal and replacement (with no failure) as units from one airplane after another are stolen to fill a hole. In all cases, the first thing the technician does is verify that the software loaded on the stolen unit is correct for the airframe it is being installed on, and if is not, the technician must obtain the proper version and load it.
Boeing’s problem is cohesive _options_ management.
The reason why a customer change creates issues and apparently huge amounts of work.
Not/much less so revision management.
I wonder what low cost country (LCC) the Boeing MBAs farmed this out to? Well if you aren’t going to get your bonus one way, you can get it tag onto your $22,000,000.00 another way… The poor small retail investor suffers again.
I guess as a ‘commoner’ living in a world of ‘plug and play’ and automatic driver updates/installs to match system components, and localization of services and language; this is hard to ‘compute’, pun intended.
I recall years ago when I commented on ‘how Boeing et al where going to get 100s of aircraft out of storage, the work involved, the people and skills needed, if I’m doing this (retro) I can’t be doing that (new), the methodology, certificate/safety etc.’ I was met with much vitriol. It keeps on coming. Oy vey!
How does Airbus’ methodology compare to localization? Is it a long process also or more plug and play/automatic?
there are hundreds of separate computers on any modern airliner. dozens of manufacturers, dozens of different data busses and communication standards. some are deliberately isolated on separate busses for security and safety.
it is absolutely shocking to me that there isn’t a database somewhere on the aircraft itself that simply lists every box, manufacturer, model, HW and SW revision, serial number etc that is updated as part of any maintenance (or build) activity. frankly I would expect that for every single serialized part on the aircraft.
Respectfully, your suggestion of a. List in the aircraft already exists. It is the equipment list found near the front of the aircraft logbook. It isn’t used because it is less safe than directly querying the boxes for their snapshot in time revision levels. The list in the equipment section of the logbook may or may not be current as many online updates to software do not require logbook entrys.
that in itself seems to be a critical safety issue. all maintenance of any sort should be logged. a software update is certainly a maintenance activity.
and it shouldn’t be a paper log, it should be a database that can be queried.
I can’t concur that some software updates do not require logging. And it is precisely such lapses in logging why neither paper log nor onboard (or any) database can be used as assurance that a particular software version is loaded on a particular box. Such logs are merely a record that a software version verification was performed on the units installed at the time and the loaded software was recorded as indicated. Single Source of Product Definition (SSPD) is a principle that assures that ambiguity and error due to multiple repositories of information that can go out of sync are minimized. The place where the p/n of the software is engraved is in the software. To see it, query the hosting hardware.
Aircraft with central maintenance computer I think is easier to update all boxes and get a log of software versions on them to check against the drawing specifying version of software in each box. The central maint computer can probably check that all software versions in its system is a combination of approved software pn’s. For older aircraft there is a risk you need to hook up and download software box by box or system by system. Still the same drawing with checkboxes should apply that you document which version is downloaded to each box.
“The FAA has lost all confidence in Boeing,” LNA/AFJ are told.”
No further comment necessary.
-> The software is supposed to produce data on a number of operating functions and identifies certain systems and parts that need reconfiguring. LNA/AFJ to told that the OSS isn’t necessarily identifying all that needs to be reconfigured.
The beauty of selling an aircraft that’s long past its due date I guess, is coming to bite in you know where.
There appears to be a danger that the same issue would happen whenever the aircraft has to be reconfigured in secondary market.
Bodes well for BA to leap forward to producing aircraft in the “metaverse”!
According to Wikipedia, orders for 6 MAXs were cancelled (so far) in 2023.
One wonders if this new problem is a possible cause of that…
This is yet another proof that B has “lost the handle” – or perhaps never had control of it.
It asks the obvious question of what else is lurking in this woodpile, and when will it show up?
This sequential stumbling from crisis to crisis is truly the death by a thousand cuts…
From the customer/airline POV, yes it is a pressure point for concessions, but it also raises the very real fear of painting itself into a corner. Can SW management sleep at night?
Boeing simply cut too deep.
Making commercial aircraft is not like producing washing machines. You need talented airplane guys and gals around to make that happen. Lots of them.
I think BA will rue the day that they did not go through with the Embraer JV. All of that young talent could have been used to solve these issues they face.
Young Embraer Talent (or any young talent) is not the issue, its a basis inherent to a nutty process that the left hand can’t ID the right hand (is that mine or is it the 121st persons over right hand?)
Older hands may know the system and able to get out of it what is needed.
I had one case where we decided trying to understand what they were trying to do with the system was a waste of time, just re-write it the way I knew it needed to work.
“This sequential stumbling from crisis to crisis is truly the death by a thousand cuts…”
That’s the crux here, isn’t it?
A never-ending litany of screw-ups: BA is the “Cup of Plenty” — it just keeps on giving and giving.
Meanwhile, Dave & Co are still collecting their fat compensation packages…while the ship sinks further and further beneath the waves…
Thats not what 2022 10K says
Not what the $40 bill of new orders 2022 to the $400 bill order book says
Reconfiguring will only affect a small number of planes.
Airbus bigger problem is its deliveries last 2 months have been below Boeings, yet their production is supposed to be much higher pm.
‘Boeing and Airbus delivered 38 and 20 commercial jets in January 2023, compared to 32 and 30 deliveries, respectively, in the same month last year.’
Oh Duke. There you are.
If you’re going to stretch the truth, at least try to make it something difficult to find out and subject to interpretation.
Commercial Airplanes delivered 152 airplanes during the quarter and
backlog included over 4,500 airplanes valued at $330 billion
I like [factually-challenged] DoU. He’s my favorite
commenter here, along with the erstwhile Alaskan correspondent.
Then there’s nonsentient but somewhat effective newcomer checkBot..
Furthermore, Duke is only looking at the sale value of the planes, and neglecting the costs to manufacture them. He’d get a more accurate picture if he looked at total margin for the backlog rather than sale price.
4,500 planes at $330B corresponds to $73.3M per plane — which is sale price.
Nominal margin on a BA plane is about $10M — though BA isn’t making that by a long shot. Still, let’s be generous:
4,500 x $10M = $45B.
That isn’t even enough to pay off the present debt load — excluding interest payments.
It is an Airbus tradition to pump out aircraft in December and then lean back in January. . They try to get away from this flood/drought but it is rooted in their system.
No need to regurgitate old news again and again. We now have unofficial numbers for February: Airbus delivery is over 50% higher than BA. BA is trounced (again).
Compliments to LNA / AFJ 👍
This story is one hell of a scoop!
Already being cited by other news outlets:
People were wondering why those two relatively young 787’s were scrapped for parts. This could be part of the reason, when a lessor is unable to re-configure the aircraft and does not want to have assets worth tens of millions, sitting around.
Part it out, file the claim with the insurance company and let them sort it out with Boeing.
As I understand it, it isn’t conjecture. Apparently, it was the lessor who who brought this up. I’ll check again with my guy, but this is what I am hearing…
Excellent — any and all data is welcome.
Imagine what it costs to have a 787 idling for 6 + 6 months. It will be interesting to see if other lessors follow suit 🤔
Can you ‘part out’ sticky tape and wooden doors? (Kidding… No response required 😀)
No wonder AAB settled his dispute with AB: he saw what the alternative was and he didn’t like it 😉
Amazing that the Qatari regulator magically dropped all airworthiness objections when called upon to do so by AAB, isn’t it?
Absolutely… Oh to be a fly on the wall when AAB ‘yielded’ (I’m being kind).
Does this have implications for Boeings control of the aircraft and sanctions, etc. Has it been designed that way deliberately?
Not having a lot of money, I run an older vehicle and am not looking forward to buying a car such as a tesla or BMW that has its software restricted.
This was a Boeing internal jobs that was pushed out to the blackbox manufacturer on cost reasons.
processes were only superficially adjusted.
Back when the 748 was designed and proper documentation was required to base the changes on it was noted after some major hickups that official documentation did not match what was done on the shop floor.
The downside of a quick fix word of mouth decision structure.
Back then the Russian design bureau was lambasted as incompetent. ( not the case : trash in – trash out)
Respectfully, the BBox manufacturers force this process onto BA in order to retain their IP. If BA was in the drivers seat, the revenue split would become far worse to the BBox guys……
Baloney! maybe in IP infatuated domains.
IN a sane environment the BBox manufacturer has written the SW framework for their boxes.
Customer gets access to a configuration tool.
( about the way Bosch handles its automotive FADEC designs. SW engine and config are separate.
engineers at VW twiddled the config ( to their detriment ) basic clean, sane design metrics.
( I would not be surprised to see munged softwareblobs installed on Boeing frames. The past and recent fall out seems to indicate such.)
An obvious measure of your problem-solving culture is the amount of time you take to deliver your product, once a problem is identified.
“…the lessor is in a queue of perhaps six months to receive attention and then a quote of six months to complete the tasks…”
I can see fixing first unit taking longer, but once you understand the issue and get suppliers on board, the turnaround time should drop dramatically.
I’ve said this before on this forum, but I’m not sure most people understand the magnitude of the complexity management issue. First, this is a general issue that impacts almost every technology product there is. It was clear way back in the early 1990’s that unless something different was done in the way complex systems are managed, that they were going to get away from us.
For example, I remember working with senior EEs and helping them with their personal computer problems in the early 1980s. Almost all of them, and by that I mean well over 90%, had an opinion as to how to set the FILES and BUFFERS attributes in their DOS 3.x machines, even though the machines themselves ignored both of those settings at the hardware level. Of course, the real issue was that someone working at the level of the system software actually had very little understanding of what was going on inside the silicon. The alarming thing about this, was that the DOS PC of the 1980s was relatively simple compared to the avionics boxes we were designing, and which these same engineers were working on. This included the chief engineer on the program, who was my boss at the time.
How many layers of abstraction are in a modern product that has a chip in it? We know that way down at the bottom where things are binary, in the hardware itself there are a bare minimum of two layers, and that’s not counting the self-healing routines in the silicon. Your typical software engineer will program in some high level language that is actually just writing code that calls functions and canned routines in a collection of library files that get pulled in by the linker at compile time. And those functions routines were almost certainly written in multiple lower level, but still so-called high level languages. In short, since about 1985 it has been humanly impossible for anyone writing software to actually know how their code works at the level of the silicon.
The implications of this are profound for something like a control system, such as flight controls in an air vehicle. Even if there were no software load options for a single box, performing an adequate Failure Mode Analysis and making sure that every aspect of the system is bounded by proper fail safe logic is an extremely difficult (i.e. expensive) task. If you compound this by permitting one bit of hardware to have multiple software loads, all you have done is add yet another multiplicative layer to the problem. As I read the description of the current problem, my first thought was that the one year estimate was super optimistic, and that would be assuming that they have world class engineering talent working on it, and we know that is highly unlikely.
The reason that it is unlikely is because of the way we have allowed the distribution of engineering talent to evolve in our society. I like to call this the least cost engineer problem (that should sound familiar to anyone who has every listened to any of the nonsense spouted by Harry Stonecipher or Prince Jim McNerney).
In 1970, where in our society was one likely to find the very best engineering talent? The answer is easy. If they weren’t in academia they were in the aerospace industry. Ok, now where are they today? They are at places like Meta, Alphabet, and Microsoft trying to figure out how to monetize the latest AI code. At the same time this societal shift was happening, the two genius luminaries I mentioned were making war on engineering salaries in Boeing. So what was the impact? It was perfectly predictable. The next generation of products they produced couldn’t do their jobs. In the case of commercial airplanes, they started falling out of the sky.
One year? Oh yeah. I’ve got a great deal on a bridge for anyone that wants to believe that.
With all the eyes on Boeing I am amazed this problem wasn’t delt with two years ago.
This problem may or may have not existed 2 years ago. It may or may not have been inside Boeings sphere of control. The articles are silent on exactly when the issueo occurred, other than its here now. This very well could be an unintended consequence of a 3rd party program causing the issue. The articles are unclear on exactly who did what….
If you are busy with sitting pretty solutions can only
begin to be conceived when the problem surfaces in an obnoxious way.
Again, because I think it bears repeating, they got to keep software in-house. This farming out code to the lowest bidder in LCCs, has to stop. Take the cost out of those &%$#@ CEOs exorbitant compensations!
01010111 01101000 01100001 01110100
I would like to see a trail of a single hardware item and what it controlled.
If its ancillary does it really matter? Pull that hardware item and log the rev code that is in it and the problem goes away. Send it back to the mfg.
Give us one hard example.
If the mfg does not know what they sold then no one does.
Thanks for allowing us to view this breaking news outside the paywall. I’m shaking my head, but none of this surprises me.
In aerospace manufacturing we deal with supplier furnished equipment and buyer furnished equipment. Both have multiple software configurations. As many in this forum have commented, yes it’s incredibly complex and they all have to talk to each other. But a well established manufacturer like Boeing has been at this for a long time and has approved FAA processes and procedures on how to manage these complex critical for safety installations. Makes me question how this process broke down but I have a very good idea.
This quote from Retired Tech Fellow & LNA sums it up:
“It was clear way back in the early 1990’s that unless something different was done in the way complex systems are managed, that they were going to get away from us.”
LNN: “The FAA has lost all confidence in Boeing,”
Just have know the folks in Cologne at EASA are really paying attention.
What really bothers me is that no executive (program mgr/director on up) loses their jobs.
But they denied Calhoun his bonus for “delays”… just not on this issue!
Must have stung all the way to the bank….😱🤡
‘What really bothers me is that no executive (program mgr/director on up) loses their jobs.’
So I recently had a conversation about exactly this, with a well respected and well connected individual. My point to him:
“How come the c-suite boys didn’t report this in the latest 10-Q, get ahead of the bad news and dump it in with the bad news for 2022?”
The response was (essentially):
‘The execs aren’t aware of the details of what the problem is. It is held lower down the food chain and all that is sent up is; 1) There’s a problem and 2) It’s going to take this many hours and cost us this much to fix. Especially in a corporation like BA where the focus is on bean-counting.”
Imagine getting paid $22M per year and yet being that detached from the real-world problems in the company…
The present LNA/AFJ article was a market-moving event today!
“Boeing — The aerospace company’s shares fell 1.6% following reports that software issues could delay deliveries of its MAX and 787 aircraft by up to a year.”
So we can surmise that Scott H is solidly in the dog house, now. I’m off to Costco – I think those liver treats are on sale. I’ll pick him up a bag…
@Frank: Scott prefers hamburger or bacon to liver….
EVERYONE….prefers hamburger or bacon to liver, unless – it seems, you have 4 paws and like to lick your privates.
(Re=phrase; You have the ability, to lick your privates…)
Kirkland Brand 4 pack of bacon, coming right up. (you got some space in the freezer to store 3?)
@Frank: says someone who has never had properly prepared Foie Gras
@Frank: Well. that’s an image I want to go to bed with….
Yah – I’ve also eaten my share of liverwurst. It’s OK….but it’s not bacon or beef.
Share the goodness, I say. I can video the action, if you like and send it along to you, so it’ll be indelibly burned into your memory…
Boeings share often move within a 5% or more range over a 1D or 5D
For today opening was $214 lowest was $210 back to $213 by midday then down to $211 at 4PM
Over 5D is between $200 and $215
Lowest in last year (52 weeks) was $113 highest $221
Beacuse its one of the DJ Industrials a lot of volume
Car-boot stock analysts dont look at big picture
And over the past 5 year period we see:
BA stock: still down 40%.
AB stock: up 26%.
Great report and congratulations on the scoop Scott. Sure to get a lot of coverage in the main stream media after this.
I wonder why Boeing CFO Brian West (ex-GE) did not address this issue at the Cowen Aerospace in mid-February?
I wish Boeing were more transparent with the investor community.
Especially since Cowen says they knew about it, over a year ago and this is old news.
They seemed to be the only ones who knew about it, but declined to report anything on the problem.
Well, Cowen basically regurgitated what BA’s IR “texted” them:
-> ‘ … [according to] the analyst at TD Cowen Co. “*BA indicates* this issue has been known for well over a year, isn’t new, was well understood at the time of their investor day and won’t cause any incremental impact to BA’s projected deliveries.”
And, on top of the issues with the 737 MAX and 787 reported in the present article, and the recently revealed forward bulkhead issue in the 787, it turns out that the KC-46A and 767F are now also undeliverable, due to ongoing fuel tank issues:
Thanks. How come there are so many 767F in inventory??
Did I “over-read” this info:
How many frames are currently touched by the reconfigure issue?
Off-topic, but a much-discussed subject here on LNA in recent months:
“Cargojet to sell 777 aircraft, defer cargo conversions as demand slips:
Orders for 6 freighters on hold, pushed back as Canadian carrier responds to e-commerce downturn”
“Canadian airline Cargojet said Monday it plans to sell two Boeing 777-300 aircraft it had planned to convert into freighters and is postponing orders for other large-aircraft modifications to preserve cash as the weak global economy lowers demand for shipping goods.
“The all-cargo carrier, which reported a CA$16.3 million ($12 million) decline in gross margin for the fourth quarter because the normal year-end bump in shipping volumes didn’t materialize, said it expects to finalize the 777-300 sale early this quarter for $53.5 million and defer the delivery of two more 777-300s to help weather the current economic downturn. It didn’t disclose who will buy the aircraft.”
With the events transpiring at SVB, this piece by the estimable Ellen Brown is worth reading:
‘What Will Happen When Banks Go Bust? Bank Runs, Bail-Ins and Systemic Risk’: