Air India 787 Crashes in Western India

So do we great majority of time … the so called “vast experience” that allows some of us to make instant connections that appear to outsiders as “knowing how to react” is the same process , we string together conclusions based on probabilities from the data we were trained on - when you see something and can extrapolate from what you see and arrive at certain conclusions is because you have seen this pattern before - thats all there is to it.
Admittedly, AI cannot come close to what we would refer as a genius or at least somebody with a creative streak … but most of us don’t either, most of us operate on daily basis using the same set of well learned patters we have acquired during our “data training” just like your typical AI and for a good reason - our brains are composed out of bazillions of binary switches that operate at the same level like basic computer transistors and approach complexity the same way.
While that is true, humans also possess critical thinking. When we hear something that sounds "sus" as the kids would say, we are likely to weight it lower at least, and more likely we'll look deeper to verify whether it's true or not.

"AI" LLMs, though, will give a true expert's opinion the same weight as your weird uncle's opinion. And since true experts are vastly outnumbered by weird uncles, they're more than likely going to be wrong; whereas a human can filter out those things that we find unlikely to be true. AI will get there someday, but it still has a LONG way to go.
 
No, I'm not. First, you used a science fictional computer to make a point, next, you used a summary from AI that read much like the contents of this thread. It was a fair summary of the rumors floating around. I suspect your expertise is something other than writing software. I don't pretend to be a code expert, but I still need to understand it reasonably well.

These AI systems, such as Chat GPT and the others, aren't flying your plane. The AIs you cited are very different software from almost anything else you use. The software for our planes and commercial jets was created prior to AI becoming popular. People are using AI to write code, but capable people still look through the code. The AI generates exactly what someone asks for, but won't handle exceptional circumstances unless those were part of the query. In some ways, AI creating code may be better as it will "close" code blocks better. I've seen bugs from people failing to close loops or decisions. The compiler or interpreter should have caught them, but there was sufficient ambiguity that the problem appeared at run time. I've noticed bugs when a user entered data that was interpreted as a hex code, which later caused memory leaks.- an abbreviation for 10% ethyl acetate was entered as 10%EA which the system interpreted as something else. I don't know if AI generated code would have handled that any better or worse.

The failures are lapses in training, people cutting costs, or an unanticipated problems. In a small plane, there are some options at 600 feet, but in a 787, the best option with dual engines out is simply to pick the best place to crash because there isn't time for anything else. As we don't know whether the automation failed, this is a straw-person argument.

The 777 and earlier aircraft seem to do most of the flying in the same fashion. This paragraph contradicts your earlier comments as I parse it, especially the last sentence.
Well said. I was beginning to think I needed to set my hair on fire.
 
These AI systems, such as Chat GPT and the others, aren't flying your plane. The AIs you cited are very different software from almost anything else you use. The software for our planes and commercial jets was created prior to AI becoming popular. People are using AI to write code, but capable people still look through the code.
Which '"capable people", exactly?

Is every coder involved in avionics automation required to have at least a PPL?

I ask because I see it in my own industry. We regularly find instances where a very capable coder/analyst makes a critical error due to a lack of understanding a use case or edge scenario.

Something that any basic journeyman electrician knows is a hazard may be completely outside of the world view and experience of a coder, even after decades "in the industry". I can have 3-4 "experts" review the code vs. the requirements spec, and it will still be missed because the people doing the review have never done hot-line work in a bucket truck.

My point is that the intersection of technical product development capability and use case understanding is a VERY small group of people. Code libraries get farmed out to Dev contractors in India (or elsewhere) and get "optimized" or version ported by grad students who have never seen the real world where the code will be used. The coders may be competent in their field but this doesn't mean that they understand how the code will interact with the real world.....

.....when an unforeseen minor control glitch in the passenger entertainment system causes the electrical bus controller to throw an unhandled exception at 700 feet off the ground just after rotation.
 
Two weeks any word on cvr fdr boxes?
Will we ever know? Honest question.
 
Which '"capable people", exactly?

Is every coder involved in avionics automation required to have at least a PPL?

I ask because I see it in my own industry. We regularly find instances where a very capable coder/analyst makes a critical error due to a lack of understanding a use case or edge scenario.

Something that any basic journeyman electrician knows is a hazard may be completely outside of the world view and experience of a coder, even after decades "in the industry". I can have 3-4 "experts" review the code vs. the requirements spec, and it will still be missed because the people doing the review have never done hot-line work in a bucket truck.

My point is that the intersection of technical product development capability and use case understanding is a VERY small group of people. Code libraries get farmed out to Dev contractors in India (or elsewhere) and get "optimized" or version ported by grad students who have never seen the real world where the code will be used. The coders may be competent in their field but this doesn't mean that they understand how the code will interact with the real world.....

.....when an unforeseen minor control glitch in the passenger entertainment system causes the electrical bus controller to throw an unhandled exception at 700 feet off the ground just after rotation.

I understand the point you are trying to make, and it isn't invalid. Certainly there is room for error in coding software for aviation applications. But we also have decades of experience doing it, and there are written/published standards for writing such code. I'm not sure if that exists for software coding writ large, but I've seen behind the curtain for fighter aviation software coding, and it is a whole lot less loose and "break things" mentality than what I seem to gather tech in general (particularly AI) has become. I guess I'm saying the comparison is maybe apples to oranges. This software rigidity is especially evident in any flight safety critical area, such as FCS software, or I'd imagine, automatic electrical load shedding.
 
Two weeks any word on cvr fdr boxes?
Will we ever know? Honest question.
I wonder the same. the boxes are in the possession of a foreign government, and they show no signs of wanting to send the boxes here for analysis. We will only know what that government wishes to share.

Indian culture is a “save face” culture. Not as much as asian cultures, but it’s there. I suspect at this point that it is some type of maintenance and/or pilot issue, but we may never know.
 
I wonder the same. the boxes are in the possession of a foreign government, and they show no signs of wanting to send the boxes here for analysis.
Or, said from a different perspective, the boxes are in possession of the government responsible for the operator, and they show no signs of wanting to send them to outsiders.

Fits a little better with the rest of your post that I didn’t quote, I think.
 
While that is true, humans also possess critical thinking. When we hear something that sounds "sus" as the kids would say, we are likely to weight it lower at least, and more likely we'll look deeper to verify whether it's true or not.

"AI" LLMs, though, will give a true expert's opinion the same weight as your weird uncle's opinion. And since true experts are vastly outnumbered by weird uncles, they're more than likely going to be wrong; whereas a human can filter out those things that we find unlikely to be true. AI will get there someday, but it still has a LONG way to go.
So it's basically a Facebook comments section.
 
I s'pose they could've hit an air pocket...:rolleyes:
Since we are going into silly sarcasm, I s'pose the "air pocket" could have loosened the improperly installed power cable on an important subsystem too. </sarcasm>
 
There are a couple comments showing concern that India hasn’t sent the FDRs to the US for analysis. Why should they? It’s an Indian-owned and operated plane that crashed in India. They have every right to run their investigation as they see fit.
 
Which '"capable people", exactly?

Is every coder involved in avionics automation required to have at least a PPL?

I ask because I see it in my own industry. We regularly find instances where a very capable coder/analyst makes a critical error due to a lack of understanding a use case or edge scenario.

Something that any basic journeyman electrician knows is a hazard may be completely outside of the world view and experience of a coder, even after decades "in the industry". I can have 3-4 "experts" review the code vs. the requirements spec, and it will still be missed because the people doing the review have never done hot-line work in a bucket truck.

My point is that the intersection of technical product development capability and use case understanding is a VERY small group of people. Code libraries get farmed out to Dev contractors in India (or elsewhere) and get "optimized" or version ported by grad students who have never seen the real world where the code will be used. The coders may be competent in their field but this doesn't mean that they understand how the code will interact with the real world.....

.....when an unforeseen minor control glitch in the passenger entertainment system causes the electrical bus controller to throw an unhandled exception at 700 feet off the ground just after rotation.
It seems you are describing the very lack of proper code review by "capable people". The capable people should be those who have done the "hot line work" and know enough coding to be able to read and understand the software. There are different skill sets in creating code, reviewing it, and writing the specifications. If the people writing the specifications don't explain the hazards, use case, or edge scenario, how is the person writing the code going to know to code for them? Some code libraries get farmed out- others do not. My employer does code in-house. But even if it is farmed out and optimized by grad students, proper specs and review should eliminate the problems you see. It is a management issue.

.....when an unforeseen minor control glitch in the passenger entertainment system causes the electrical bus controller to throw an unhandled exception at 700 feet off the ground just after rotation.
Again, assumptions are being made that are not in evidence as yet (and may also be totally unrelated)
 
Pardon the source but Air India is starting to look like a clown show. Canceling all flights to the USA?

I wondered about that too- I read about that elsewhere. The reason reported was the problems in the Mid East and Iranian attacks on a US base (sorry, I don't have the reference). However, I think India still allows routes over Russia? If that is true, Air India should have been unaffected, except for some flights to Europe, which could be routed over Russia. My earlier reading indicated flights to Europe were also cancelled.
Note the link in this post:
<speculation with scanty evidence> I wonder if Air India and the Indian government found issues so severe that the planes would have been grounded if inspected in Europe and North America? </speculation with scanty evidence>

If so, I'm very surprised. The Tata group generally has a good reputation for their products. Tata took over Air India in 2022- maybe they need more time to fix it, or they need to do more to fix things. I'm surprised that Singapore airlines owns about 25% of Air India, and Singapore enjoys a good reputation.
 
There are a couple comments showing concern that India hasn’t sent the FDRs to the US for analysis. Why should they? It’s an Indian-owned and operated plane that crashed in India. They have every right to run their investigation as they see fit.
What happened to oh my god the 787 fleet has defects? We have to know what happened? Ground the Fleet!
 
Indian culture is a “save face” culture. Not as much as asian cultures, but it’s there. I suspect at this point that it is some type of maintenance and/or pilot issue, but we may never know.

And a culture of “facilitation payments” up the chain of command…and having to navigate those while staying in 100% compliance with US regulations…from corporate experience.
 
I ask because I see it in my own industry. We regularly find instances where a very capable coder/analyst makes a critical error due to a lack of understanding a use case or edge scenario.
As mentioned above, you're making the assumption that aviation airborne software is developed and certified in the same manner as other industries. Except its not. Just as different areas on an aircraft must meet a defined tiered level of failure probabilities for certification, so does the software. Only once the software meets those standards is it certified for airborne use. As to the entertainment systems, while unfortunately there has been an instance or two where those systems have caused an aircraft accident it was due to shorting and fire and not having the ability or path to shut down the engines, etc.
 
As mentioned above, you're making the assumption that aviation airborne software is developed and certified in the same manner as other industries. Except its not. Just as different areas on an aircraft must meet a defined tiered level of failure probabilities for certification, so does the software. Only once the software meets those standards is it certified for airborne use. As to the entertainment systems, while unfortunately there has been an instance or two where those systems have caused an aircraft accident it was due to shorting and fire and not having the ability or path to shut down the engines, etc.

Back in the day, I was the Chief Engineer for the USAF ATF Program (YF-22/YF-23). One of the competitors was briefing the design plan for the Avionics with a Vu-Graph (Remember those things called overhead projectors?) showing all sorts of avionics sensors, etc. connected to the flight control system. I jumped out of my seat, whipped out my pocket knife and cut the Flight Control parts out of his chart and stated in an not subdued tone, the following.

"You can connect those gizmos to the stuff I cut out when you prove to me that you have the same discipline towards Safety of Flight as the Flight Control Designers. I have observed the habit ot Radar, ECM, Displays, etc people is to be somewhat slipshod and fix things in version 2,3,4,5, ad nauseum. Connecting stuff like that can lead to loss of an airplane and God Forbid, the Pilot."

Things changed subsequent to that. The USAF long ago developed procedures for certifying software and the contractor team just needed a reminder which I was happy to supply.
 
There are a couple comments showing concern that India hasn’t sent the FDRs to the US for analysis. Why should they?
Because they are reportedly "too damaged" for the data to be downloaded from them using the equipment the Indian version of the NTSB has.
How they can be that damaged, when the tail is virtually intact (and so should be the tail CVFDR), and someone walked away from the aircraft in seat 11A (so the forward CFVDR shouldn't have too much damage), is something that doesn't make that much sense to me.
 
Two general comments that I'm too lazy to choose quotes to respond to:

The venn diagram representing career pilots and career software developers likely has near zero overlap. A weekend warrior in either should not have input into the development of software that is controlling mission critical systems in aviation or elsewhere. The goal is zero failure, but that's not realistic in any complex system. Nuclear power plants are run by software automations, but it's clear Japanese developers didn't think an earthquake and tsunami were something they needed to program to detect and build the systems to contain the core in that event. Aviation kills far less people than just about anything you compare it to and is safer than any time in history. There will always be loss of life associated with aviation because while we can develop systems to make flying safer, there doesn't appear to be any progress into making crashing an airliner safer or the occupants. No amount of automation, zero automation, billion hour pilots, robot pilots, AI, Elon Musk or really anything is going to eliminate that planes will crash because they are complex systems traveling through a truly random world.

I love a good crash investigation and the discussion around it, but this thread blows my mind. The number of people who are hanging their hat on a cause with zero evidence to back it up is wild or condemning the entire industry over what they think was the cause of this crash.
 
Which '"capable people", exactly?

Is every coder involved in avionics automation required to have at least a PPL?

I ask because I see it in my own industry. We regularly find instances where a very capable coder/analyst makes a critical error due to a lack of understanding a use case or edge scenario.

Something that any basic journeyman electrician knows is a hazard may be completely outside of the world view and experience of a coder, even after decades "in the industry". I can have 3-4 "experts" review the code vs. the requirements spec, and it will still be missed because the people doing the review have never done hot-line work in a bucket truck.

My point is that the intersection of technical product development capability and use case understanding is a VERY small group of people. Code libraries get farmed out to Dev contractors in India (or elsewhere) and get "optimized" or version ported by grad students who have never seen the real world where the code will be used. The coders may be competent in their field but this doesn't mean that they understand how the code will interact with the real world.....

.....when an unforeseen minor control glitch in the passenger entertainment system causes the electrical bus controller to throw an unhandled exception at 700 feet off the ground just after rotation.

There are people that develop the requirements for software components - the good ones know how to extract those requirements from SMEs. And know how to communicate requirements to the code slingers. One does not need to be a medical doctor to be able to develop safe* software for medical devices. One does not need a degree in chemical engineering to be able to develop safe* software for chemical plants. It does help to have an evil mind that can consider all sorts of edge/boundary conditions.


*safe - well, being safe enough. Nothing is completly without risk.
 
It does help to have an evil mind that can consider all sorts of edge/boundary conditions.
I love this. So true. The guy that knows how a given system should operate (the operator or engineer) has to also have “if/then & and/or” type thinking to best communicate to the programmer teams. Makes design work so much easier and fun.
 
Since we are going into silly sarcasm, I s'pose the "air pocket" could have loosened the improperly installed power cable on an important subsystem too. </sarcasm>
Heh, wouldn't have to loosen anything if the dearth of air flamed out the engines. :)
 
I worked on s/w that involved anything from ballistic and cruise missile telemetry packages to mailroom scales.

Requirements, specs, testing, and validation were very different. I had looked into flight control jobs and their requirements were even more rigid.

There are a lot of complexities: each component can do exactly what it’s intended to do, account for edge cases and bad inputs, but all those components still may not play well together. Human safety s/w systems are hard.

There was a comment somewhere above about software in the Fukushima plant not anticipating an earthquake and tsunami. I remember following that pretty closely. It’s been a while and I’m fuzzy on details, but I don’t think that was an automation problem. That was a human design limitation. The reactors scrammed like they were supposed to, but that fuel stays hot for weeks(?), months(?). The cooling system requires power, but the entire grid was down. The backup generators were installed in a location that was thought to be above a worst case flood. They weren’t. I remember reading the engineers scavenged car batteries from the parking lot in an attempt to keep any power at all to run cooling pumps. Eventually the fuel overheated and melted.

Human limitations in considering “worst case” contributed. Those limitations apply to software design, hardware design, electrical, hydraulic,…. And don’t forget that one time someone improperly torques a bolt.

Airliners are exceedingly complex, and everything matters.
 
. If the people writing the specifications don't explain the hazards, use case, or edge scenario, how is the person writing the code going to know to code for them? Some code libraries get farmed out- others do not. My employer does code in-house. But even if it is farmed out and optimized by grad students, proper specs and review should eliminate the problems you see.
Every spec I have ever read (and I've read a lot) has both gaps and wording that require assumed knowledge to completely comprehend.

Reviews sort out the majority of those gaps, but no process is perfect. Any software more complex than a 5 command IRQ handler is going to have flaws, so it all comes down to minimizing the number and potential impact of those flaws

My point is that the best developers have a detailed knowledge of both the development process and the application space. IMNSHO, a team leader or project manager absolutely MUST possess both, and this is a rare and exceedingly valuable combination of skills and experience.
 
And a culture of “facilitation payments” up the chain of command…
Bingo....

My Made in USA personal safety product export sales efforts to the Indian Air Force resulted in a waste of time and money. The Indian testing laboratory clearly and intentionally tilted the test process (and acceptance sub-standard test results) to favor a significantly lower quality Indian manufactured "knock off" that did not meet (not even close) the contract's detailed specification requirements.
 
Every spec I have ever read (and I've read a lot) has both gaps and wording that require assumed knowledge to completely comprehend.

Reviews sort out the majority of those gaps, but no process is perfect. Any software more complex than a 5 command IRQ handler is going to have flaws, so it all comes down to minimizing the number and potential impact of those flaws

My point is that the best developers have a detailed knowledge of both the development process and the application space. IMNSHO, a team leader or project manager absolutely MUST possess both, and this is a rare and exceedingly valuable combination of skills and experience.
It seems you are projecting your experience onto all software development, which is a good first approximation that doesn't apply everywhere. There's a spectrum that runs from script kiddies trying to sell a phone app to regimented code development that most of us would probably find stifling. I'm pretty certain that Boeing is close to the stifling end of that spectrum for their flight software. I'm going to, perhaps improperly, project my experience onto Boeing for their mission critical software. My employer makes lab equipment, specialized cameras, and test/measurement equipment used in harsh environments (space, underwater, remote locations). It HAS to work. All the time. They probably have multiple tiers of code review and testing. They also work within heavily defined hardware which may be years behind the consumer state-of-the-art, but is tested and known to be reliable. Operating systems may be custom but they are well tested. They aren't running Windows, iOS, or other consumer-level operating systems. The flight management system is locked down and separate from the entertainment system which probably isn't tested so vigorously. Can they make mistakes? Sure! Am I saying the software can't be related to the crash? No way- there's no information to support any theory right now.
 
Reviews sort out the majority of those gaps, but no process is perfect. Any software more complex than a 5 command IRQ handler is going to have flaws, so it all comes down to minimizing the number and potential impact of those flaws
Except on the aviation side it goes beyond simply "minimizing" the number of flaws and their effects as you must determine and qualify when those flaws may happen depending on the design level and failure condition requirements. So when you get to the engine control and flight control software levels, the certification standards will require you to show the failure probabilities are on the order of 1^ (-9) or less. Basically a failure condition that is "extremely improbable" and "is not anticipated to occur during the entire operational life of all aircraft of one type." Its the same failure probability process used for most critical aircraft system certifications.
 
Man, it feels like it had been weeks just days ago.

The data has been downloaded and it's being analyzed.

Why would they be examining the data? Air India is inspecting 787's as a result of the crash so they obviously know what happened :rolleyes:. They must have been reading this thread or watching YouTube.
 
While that is true, humans also possess critical thinking. When we hear something that sounds "sus" as the kids would say, we are likely to weight it lower at least, and more likely we'll look deeper to verify whether it's true or not.

"AI" LLMs, though, will give a true expert's opinion the same weight as your weird uncle's opinion. And since true experts are vastly outnumbered by weird uncles, they're more than likely going to be wrong; whereas a human can filter out those things that we find unlikely to be true. AI will get there someday, but it still has a LONG way to go.

What you refer as critical thinking is just another pattern matching where we learn that some people are more trustworthy than others - no different than any other pattern matching we learn over time …. A five year old is just as likely to trust an expert as he is his weird uncle - until he learns to know better, so there is no built in advantage for people -AI can do that as well.

What truly separates people from AI is that our internal wiring ( genetics ) differ from one to another and allows some people to achieve truly spectacular results despite almost exactly the same “training data set” as other humans - that cannot be replicated by feeding AI more and better training data and requires change in the algorithm itself ( similar to different genetics in people ) and thats much harder.

What I suspect will happen that once AI gets better , it will eventually come up with better algorithms on its own in an iterative like process ( similar to our evolution but many orders of magnitude faster ) and some of these algorithms will result in similar “genius” like AI outcomes - but I am just guessing , ultimately this may turn out to be one of these “ we got this working 95% but the last 5% will take another 200 years” type of problem, it is hard to say.
 
Last edited:
Except on the aviation side it goes beyond simply "minimizing" the number of flaws and their effects as you must determine and qualify when those flaws may happen depending on the design level and failure condition requirements. So when you get to the engine control and flight control software levels, the certification standards will require you to show the failure probabilities are on the order of 1^ (-9) or less. Basically a failure condition that is "extremely improbable" and "is not anticipated to occur during the entire operational life of all aircraft of one type." Its the same failure probability process used for most critical aircraft system certifications.
I mentioned earlier that you only need to convince whatever authority that your probabilities of rare events are probable. After publishing safety reports for many different turbofans, I sometimes wondered where that final number comes from (even though I'm presented with all of the ingredients!) But our group mainly put lipstick on the pig, made sure the language met FAA and EASA requirements (anyone here still say "FAR 91"? Not in a report, unless referring to legacy stuff!), charts and images were legible, links worked properly, and we didn't touch any engineering data (though we could question it, if questionable, which occasionally happened.) The documents went through three levels of review after publication, before the FAA or EASA (and other authorities) got them for approval. Hundreds of test plans and test and comparative analysis reports per engine (GE9X was the last project we did prior to my retirement.)
One could also attempt to convince the authorities that your very special way of doing something presented an equivalent level of safety to the requirement (ELoS). That usually was needed when something novel was implemented, which the regulations didn't explicitly cover. (And was often included in the next amendment.)
But the improbable does sometimes happen. And worse, the unforeseeable does happen, and like some simple inventions, they are obvious once you see them.
 
It seems you are projecting your experience onto all software development, which is a good first approximation that doesn't apply everywhere. There's a spectrum that runs from script kiddies trying to sell a phone app to regimented code development that most of us would probably find stifling. I'm pretty certain that Boeing is close to the stifling end of that spectrum for their flight software. I'm going to, perhaps improperly, project my experience onto Boeing for their mission critical software. My employer makes lab equipment, specialized cameras, and test/measurement equipment used in harsh environments (space, underwater, remote locations). It HAS to work. All the time. They probably have multiple tiers of code review and testing. They also work within heavily defined hardware which may be years behind the consumer state-of-the-art, but is tested and known to be reliable. Operating systems may be custom but they are well tested. They aren't running Windows, iOS, or other consumer-level operating systems. The flight management system is locked down and separate from the entertainment system which probably isn't tested so vigorously. Can they make mistakes? Sure! Am I saying the software can't be related to the crash? No way- there's no information to support any theory right now.
I work in safety critical systems as well. And while the processes are heavy, often how people do things can leave you quite concerned.

My area is automated train control. And I will say that for a lot of systems I know of, I would happily ride them. However, if I hear they are having issues like disabled train or passenger assistance events, I would start thinking what if. In my experience no one has ever managed to test all the corner cases. I am talking decades old code based which is about as revenue proven as you get. And they still find “well we didn’t think of that scenario” safety impacting bugs. After all the FEMCA, hazard logs, reviews and mitigations as well. And this is with regression tests taking up to 6 months with an army of testers after being very specific to only new changes.

It is entirely possible for there to be unknown safety problems. The name of the name is never to prevent all out comes but to adopt the layered Swiss cheese model. The idea being multiple levels of safety and mitigation to reduce the likelihood of any holes lining up. Even then it’s never ever a case of perfect safety but As Low As Reasonably Practical or ALARP.
 
But the improbable does sometimes happen. And worse, the unforeseeable does happen, and like some simple inventions, they are obvious once you see them.
True. Nothing is an absolute. But most of my experience with failure probabilities is after the fact when the extremely improbable catastrophic failure does happen. And usually after reapplying the quantitative and qualitative safety objectives developed for those failure conditions to the actual failure, most times you find objectives are still valid.

It’s the unforeseen work-hardening limits of titanium studs vs carbon steel studs or the improper actions of a pilot or mechanic that cuts a new hole in the original “swiss cheese” probability model. Regardless, with the continued application of fault-tolerant design concepts and consensus standards to new aircraft, we will get one step closer to that elusive goal of zero failures.

One could also attempt to convince the authorities that your very special way of doing something presented an equivalent level of safety to the requirement (ELoS). That usually was needed when something novel was implemented, which the regulations didn't explicitly cover. (And was often included in the next amendment.)
There is a certification regulatory path via Part 21.16 Special Conditions and 21.17 Special Classes that is a level above the ELoS process. For example, the eVTOL certifications are all being performed under 21.17 as no regulations exist for powered lift aircraft. However, all the existing catastrophic failure probabilities are still in play for that certification method.
 
Last edited:
Back
Top