5 ms·
I really see this as a failure of the Systems Engineering process. With so many people unaware of the impacts of the changes, it’s up to the systems types to ha
by kejaed 7y ago
I really see this as a failure of the Systems Engineering process. With so many people unaware of the impacts of the changes, it’s up to the systems types to have the big picture view and make sure these sorts of things are taken into account.
Especially if as the article says a failure of the AOA sensor on the system would be Hazardous (looks like it was Catastrophic when paired with MCAS in retrospect), that would have made the functional Design Assurance level for this system DAL B, which adds enough rigour not only in the software development process but so much before you even get to that in terms of Safety Assessments and ESPECIALLY change impact analyses when the function changes.
For sure there may have been pressure from management to keep MCAS out of the manual but it’s not really up to he regulatory agency to be experts on the aircraft design, if things are being hidden by the company then I’d consider this bordering on professional misconduct on the parts of the engineers overseeing this work.
I say this as a Professional Engineer working as an aerospace systems engineer.
- kejaed 7y agoThinking about this a little more, I also see a failure here in terms of naming things, which I have noticed in my career can be scoffed at but is so important. As the article says, the function of MCAS changed and its operational envelope was greatly expanded. What if, internally at least, the new system was referred to as MCAS2? This is somewhere that things can get political, as was exactly the case with the Max, where they did not want anything to be considered a change to the aircraft type, let alone knowing the MCAS system existed in two majorly differing versions.
- countbackula 7y agoAdmittedly I have 0 familiarity of the internals of a corporate electrical engineering environment, but this is a logically sound idea that in many other industries is standard. OS 10.02, Apache license v. 2, Archer router xyz Rev 02. What's the limiting factor here in the case of MCAS?
- karmelapple 7y agoThere are definitely different versions of software, each with unique identifiers, such as typical version numbers. There’s also the idea of “flight test ready” software, which is able to go onto a flight, vs software that is only to be used in a lab that is not truly flying in the air and controlling the plane.
- BurningFrog 7y agoPerhaps something entirely different than what you're talking about, but... I believe changing the aircraft type would trigger regulatory events carrying rather gargantuan costs. Avoiding those seem to be the entire reason for the existence of the 737 MAX.
- karmelapple 7y agoNaming things and communicating changes are all core parts of the Systems Engineering process. Failing to clearly communicate precisely how big this change was, and not making it extremely clear to all stakeholders what was happening and doing analyses of how these failure modes have changed, is really awful.
- suzzer99 7y agoThis is so true. Naming to me is one of the most important decisions. When I see someone who frets over naming decisions for hours, or will sit down with me and really think through what we're going to name something - I know they get the gravity of the situation. I trust those kinds of people much more for big picture architectural or project lead decisions.
- sooheon 7y agoDo you have examples off the top of your head of really great names that have come as a result of this process?
- salawat 7y ago>Especially if as the article says a failure of the AOA sensor on the system would be Hazardous (looks like it was Catastrophic From my understanding, this was an intentional decision, as the only way they could certify the airframe without simulator training being required was to feed the MCAS with only 1 sensor. The only way they could do that is keeping the system overall rated as hazardous, as the Catastrophic rating would require multiple redundancy plus the training. This can be corroborated from the Australian 60 minutes expose. >For sure there may have been pressure from management to keep MCAS out of the manual but it’s not really up to he regulatory agency to be experts on the aircraft design, if things are being hidden by the company then I’d consider this bordering on professional misconduct on the parts of the engineers overseeing this work. That is my conclusion as well.
- spking 7y agoThanks for the tip on the AUS 60 Minutes expose. For anyone else interested: https://youtu.be/aO7_indbfME https://youtu.be/aO7_indbfME
- GoToRO 7y agoengineers overseeing this work There the thing: nobody wants to pay engineers on par with managers. Maybe one can not manage something he/she can not understand.
- rjzzleep 7y agoGiven all the environments I've worked in, including midsize construction projects I'm willing to bet my hand on the fact that some engineers or third party planning bureaus actually did spot these flaws and reported them and then were turned down and ignored, but not before having been told that it's not their decision/problem. That's always the moment when I'm happy to have documented the decisions.
- LoSboccacc 7y ago> There the thing: nobody wants to pay engineers on par with managers I used to think like that but I learned in time that the core issue is that engineers rarely know how to present their job in terms of monetary benefit during salary negotiations. i.e. as an automation engineer I led an initiative that saved a previous employer more than 60k€ yearly using automation and optimizing other validation workflows. as principal engineer at my current job I saved them more than 30k€ yearly by replacing a licensed component with an open source one, filling the feature gaps myself outside of work hours. these thing get noticed, not just the stuff done but the ability of thinking in money, and unlocks the full engineering potential in salary negotiations
- 7y ago
- joe_the_user 7y agoI don't know if one could say a failure of the Systems Engineering process. One could also say it is a situation where management, regulatory and market constraints became so unwieldy that there was simply no way Systems Engineering could possibly satisfy the requirements. Sure, it's a failure to push back again this but that seems a bit different.
- TheOtherHobbes 7y agoManagement and "the market" were providing faulty feedback that engineering couldn't push back against, no matter how much force was applied.
- karmelapple 7y agoAs a former Systems Engineer who worked on avionics, I would tend to agree; a major change to a system should have at least triggered the integration-level engineers (called the Platform team at my former job) to think hard about potential broad impacts. It should have resulted in that team actively seeking buy-in, and clear communication that all subsystems comprehended precisely what was changing. It likely should have triggered some kind of additional scrutiny from the safety organization. That it didn’t is heartbreaking. It seems like either some common practices were not followed or were rushed. I can’t see Boeing keeping their CMMI certification level after this news breaks. Certainly some major steps were skipped in the Systems Engineering process.
- Merrill 7y agoSystems Engineering -- The art of working on the overall design while not overlooking any detail that later turns out to have been important.