The MCAS is a good example, why certain software must not be outsourced. Implementing the software correctly to spec isn't enough, you need enough understanding of the application to question the spec itself.
Software engineers are not aerospace engineers. I doubt the software people would have understood the aerodynamic effects of the MCAS system by looking at the requirements.
That is the problem with having pure software engineers implementing such a software. They need to have some aerospace engineering knowledge too. Or at least work directly in one team with aerospace engineers.
I am working as a "software engineer" in the semiconductor industry. By education, I am a physicist. I am in my job for more than 10 years now, and beyond my university education, I have quite a grasp of electrical engineering. Furthermore, most of my colleagues are eletrical engineers. So in doubt, I can just walk over to their desk and discuss any question beyond pure software development issues. And some of the software developers here are just electrical engineers, which expanded their skill profile into software territory.
Doing business this way is quite more expensive than having software developed by a contractor, but it creates safeguards.
That is true. But please keep in mind that the whole MCAS fiasco was precipitated by a dubious cost-cutting initiative related to an engine placed more in front than would be aerodynamically stable. The game was lost in the first quarter. The whole point is that civilian aircraft, unlike fighter jets, have to be aerodynamically stable without the need for such software, whether developed by holistic engineers, or compartmentalised subcontractors.
The 737 MAX is aerodynamically stable. MCAS isn't even active while any flap is extended. MCAS should be active only at angle of attacks, which wouldn't be reached at extreme angle of attacks. The sole purpose of MCAS is to emulate the exact reactions of the older 737 machines in this domain, as this was required for maintaining the same type rating. That is also the reason, the pilots are supposed to deactivate MCAS via the runaway stabilizer checklist. This software isn't required for stable operations of the airplane - Lion air had a MCAS malfunction the day before the crash, but disengaging the electric stabilizers solved the problem and they were able to finish their flight without incidents.
Incorrect. The aircraft is not aerodynamically stable in pitch unaided by software, thereby failing the demonstration of positive pitch stability as written in FAR 25.173. The non-compliance is of the form of a slackening of control stick response force at high AoA due to extra lift generation ahead of the center of gravity caused by the forward mounted engine nacelles.
In regulatory parlance, this specifically means the airframe (the specific physical assembly of parts that collectively determine the flight characteristics of the object in question) possesses an "instability" that disqualifies it from being certified airworthy as a Civil Transport Aircraft unless the FAA amends or reinterprets the requirement.
The penultimate Lion Air flight only recovered thanks to The intervention of a third pilot; a luxury not universal to every cockpit.
>MCAS should be active only at angle of attacks, which wouldn't be reached at extreme angle of attacks.
The potential for MCAS subroutine activation is active during all phases of manually controlled (Autopilot off), flaps up flight,and is gated only by readings from an AoA sensor; which can fail in flight to catastrophic effect.
>The sole purpose of MCAS is to emulate the exact reactions of the older 737 machines in this domain, as this was required for maintaining the same type rating.
Incorrect. The sole purpose of MCAS is to induce an intentional "mistrim" during certain points of the flight envelope to counter the extra lift generated by the repositioned engines, with the end goal of smoothing out the non-compliant stick force response curve. Note, jury is still out whether this should even be allowed. I've gotten wildly different responses based on who I've talked to. Pilots seem to express horror or extreme discomfort. Aerodynamicsts are disconcertingly quiet, but tend toward hard reconfiguration to obviate the need for a software based solution.
Also, MCAS specifically deviates from oldaircraft behavior in that it removes an override of auto-trim commands activated by heavy back pressure on the yoke. There were also specific reconfiguration of the stabilizer trim cutout switches that removed any capability of locking out the MCAS system's ability to actuate the trim motor, while leaving pilot's thrim switches active.
some would, some would not. those that have been doing aircraft software for 20 years probably have a fair knowledge of airplanes, aerodynamics, and flight controls.
your comment expresses my feelings exactly on 'was this a software failure?'. No. But software was involved.
This is the larger problem. There are plenty of aero engineers that are brilliant programmers yet the reverse is a much smaller number. Add to that, aeros that can code are far more expensive than software engineers, it becomes easy to see why they outsource to software people.
That assertion in the article seems to be incorrect according to the linked Bloomberg article, which states that the MCAS software was not outsourced: https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-.... Given that apparent factual error, I’m suspicious of the other claims, which are highly rhetorical and mostly asserted without evidence.
It has been mentioned in the article that MCAS was never outsourced. Also it’s unfair to blame the software engineers who are building it to specification. It would be fantastical to assume that Boeing management( the same one ploughing through engineering with bean counting) would give a rats crap about a low level engineer raising a concern.
First, none of the software in question was outsourced to the company.
Second, the Bloomberg article does not describe the problems Boeing had with the software engineers from HCL, beyond a cryptic, "it took many rounds going back and forth because the code was not done correctly." Was it a genuine misunderstanding of ambiguous language? Was it because the programmers did not have a background in the aerospace problem domain? Or was it because the engineers had a poor grasp of the vocabulary? It seems improper to assume the third situation in the absence of any additional evidence.
Finally, I am not sure what part of "software being outsourced" is considered outrageous. Is there evidence that a software engineer employed by Boeing, rather than by company XYZ, is less likely to produce faulty code? Or is more likely to understand the complex downstream effects of their actions and the equally complex upstream design decisions which informed them? Also, countries don't write code. Companies don't write code. People do. That "India doesn't have a deep background in aerospace" doesn't mean much at the level of individual engineers. I am skeptical that the most highly skilled American programmer has a deep background in aerospace either.
Sorry about the rant: something about the Blookmberg article came across as xenophobic innuendo.
MSFT had a similar experience with HCL (I think it was them, one of the large Indian outsourcing firms in any case) when I was working on Vista. All fixes for bugs identified by static analyzers (PREfix/PREfast) were outsourced to contract programmers who had zero familiarity with the Windows source code. The “fixes” they sent back almost invariably introduced new bugs, and the whole back-and-forth process took much more time and effort (and presumably money) than just having the code owners fix the bugs in the first place.
It has been mentioned in the article that MCAS was never outsourced.
Where did the article say that? To me it explicitly claims it was outsourced:
the McDonnell Douglas influenced Boeing new one tried to patch the problem with software. And it was bad software, written by to engineers paid $9/dollar an hour.
And I am not blaming the software engineers for building it to the specification. In contrary, I clearly stated, that just building it to specification isn't enough for such critical software. Such software needs to be developed in teams where enough team members are senior enough to properly raise concerns where appropriate.
>In offices across from Seattle’s Boeing Field, recent college graduates employed by the Indian software developer HCL Technologies Ltd. occupied several rows of desks, said Mark Rabin, a former Boeing software engineer who worked in a flight-test group that supported the Max.
>The coders from HCL were typically designing to specifications set by Boeing. Still, “it was controversial because it was far less efficient than Boeing engineers just writing the code,” Rabin said. Frequently, he recalled, “it took many rounds going back and forth because the code was not done correctly.”
