There is 10x to 100x more software in a self flying machine than in a CAT3 autopilot which has 2 pilots watching it anyway.
As with fully self driving cars, it will be achieved one day but we are IMHO decades away.
Considering your run-of-the-mill CAT3 autopilot has to monitor far more systems with a vast range of input variables and characteristics than just a bunch of electric motors, and do that in two independent CPUs (albeit both programmed in Ada), I’m not quite sure which is going to have more lines of code. Bear in mind that only the electric power system management in a Triple7 requires 80k lines of code give or take, whereas the Airplane Information Management System (ie main brains) requires about 610k lines.
I estimate we are 3-5 years away from limited application of autonomous air-taxis. From there on it could become a massive trend or it could remain a niche waiting for further refinement of the technology and economics.
Take a look at how DJI drones can orient themselves today and avoid obstacles. That’s cheap stuff with all R&D done in a country that this forum thinks can only do monkey labor. I’m not saying that is the firmware that should and will drive air-taxis but it shows that it’s not that difficult.
The real challenges for autonomous air taxis is energy storage and safety. The overall software challenge is significantly less complex than self driving cars. Just like the Airbus can auto-land under very specific conditions (ignoring potential mooses on the runway etc.), air-taxis can be made work with today’s technology under very specific circumstances.
Number of lines of code is by no means indicative of quality nor complexity.
It is very indicative in the context of formal verification of software.
I see no problems with autonoumous flying. “All” you need is reliable gyros, fast processors, software, a stable GPS conncetion – and a system that monitors the available precision – which my GNS430Ws also do when selecting NAV/VNAV or LPV minima. GPS outages could be taken care of with an emergency system that (for example) could stabilize the aircraft and land it based on the last position … or whatever.
It is simply a matter of development time and available batteries. I think it is ALL about the batteries, becasue everything else really exists. For $ 500 you can buy a HD photo drone that will follow you when you’re skiing or riding your bike … today.
When the first train was developed there many serious voices that humans cannot take speeds higher than 25 km/h (or so) – and a short time before the Wright Brothers tooks off a journalist of the New York Times wrote that it might take another one to ten million years to solve the problem of flight and to develop a flying machine.
I see no problems with autonoumous flying. “All” you need is reliable gyros, fast processors, software, a stable GPS conncetion – and a system that monitors the available precision – which my GNS430Ws also do when selecting NAV/VNAV or LPV minima. GPS outages could be taken care of with an emergency system that (for example) could stabilize the aircraft and land it based on the last position … or whatever.
Indeed – just land the whole vehicle on top of somebody, just like FPV drones do when they go out of range 
Actually, I reckon a good C++ programmer software architect could code the whole thing up on a 4004 in a few weeks. Start with a GNS430W motherboard… even less. I would however recommend avoiding pointers; they are responsible for 74.8% of bugs. For a high-rel embedded system I would also avoid any storage on the stack and make everything static. But if you put a Java VM on the 430W then you can’t have any bugs anyway…
Peter wrote:
Actually, I reckon a good C++ programmer software architect could code the whole thing up on a 4004 in a few weeks. Start with a GNS430W motherboard… even less. I would however recommend avoiding pointers; they are responsible for 74.8% of bugs. For a high-rel embedded system I would also avoid any storage on the stack and make everything static.
With your 1990 view on software engineering, you should apply for a job at Lillium et al. I am sure they would welcome you.
Peter wrote:
Indeed – just land the whole vehicle on top of somebody,
That’s what a Cirrus does when you land according to the checklist, i.e. pull the red lever under the roof. Now some people think this is too risky (London glide clear rule) while others believe that the odd chance of a Cirrus crashing into my beer garden is not too worrisome.
I haven’t read about any significant hurdle to autonomous air taxis so far. Also there is no definite need for any sort of advanced AI in those.
What if the first step was to define corridors for them to fly in? Similar like trains that can only go on tracks. Those corridors would be designed so that third party risks would be minimal. Nobody claims that the whole planet will exclusively rely on autonomous electric air taxis from next year on. All you have to do is set the right parameters, start there and push it forward.
What if the first step was to define corridors for them to fly in?
That’s a different proposition but not very useful for air taxis in a city environment.
You would still need a redundant system with automatic fallover. That is what you have in all aviation systems: it falls over to the pilots who are paid serious money to watch the instrument panel and hand fly it if they see something go wrong. Designing software and hardware which does this is really hard. You need three of everything plus a very reliable “voting” arrangement. If this is not done, any failure will kill the occupants, and this would not be acceptable to most people.
The presence of a human delivers this redundancy very effectively. And needs no software. You just put the humans through the 14 ATPL exams, a CPL/IR, and a TR 
The point is that the failure of the system and a failure of the human (i.e. a series of aircraft systems failures which render the aircraft unflyable even by hand, followed by pilot incapacitation) is vanishingly unlikely.
And humans (calculated MTBF around 800 years) are easy to manufacture, using a process which is well developed and understood and actually in recent times greatly facilitated by Tinder (with some side effects which are generally well understood). The quality is random, within a spectrum, but there are enough specimens at the good end to enable any almost desired quality to be acquired by selection. And there isn’t much software which walks through the door and wants to give you 100k to do your job.
With automatic trains the problem is fairly trivial. If any one of a load of things goes wrong, cut the power to the motor and maybe apply the brakes.
That’s what a Cirrus does when you land according to the checklist
I can point you to the newly merged and massive Cirrus BRS thread Any discusion of whether Cirrus reckon you should pull the chute regardless of what is below you, will be moved there.
The closest a Cirrus under the parachute came to a dangerous situation was when an SR22 landed landed on a pickup truck on a Freeway – after an engine failure in 450 feet (chute was released in 429 feet).
What people forget– and this would be true for any vehicle with a ballistic recovery system is the loud BANG when the system is actived. In most situations there’s time to run away. Also: Except after midairs and engine failures pilots will try to steer away from dangerous places. But for vehiclea like the Lillium, – without any gliding capabilites and probably mostly operated in cities – the situation would different.
