If we ask these same questions for commercial aircraft, we can pretty well answer these questions in the affirmative, at least from a software point of view. No life has ever been lost as far as we know on a commercial aircraft because of a software error. That’s an impressive safety record, so let’s see how we have achieved this. First, the software on board an aircraft is certainly complex; the Boeing 787 for instance has well over five million lines of critical code. For ordinary users of computers, and ordinary programmers using standard techniques, we don’t believe for a moment that software of this size or complexity can be reliable, and indeed we are used to our personal computers crashing frequently, not to mention our phones and other computer controlled devices. But the software on board planes is definitely not ordinary software created by ordinary programmers using standard techniques. On the contrary, the FAA requires extraordinarily rigorous procedures for creating this software (embodied in the DO-178B certification standard (See here), recently updated to DO-178C (See here). It’s painstaking work, and typically significantly increases the cost of producing software, but it’s remarkably effective in yielding software, that, if not perfect, is good enough in practice so that software is not the weak link in the chain.
Furthermore, we rely on an air traffic control system that is itself a highly complex set of reliable certified software components. And we also rely on simple principles of air traffic control, for example keeping aircraft well separated, operated by a small army of highly skilled air traffic controllers.
So can’t we just apply the same reliable procedures to drone software? I see two huge problems. First, there will be severe resistance to the extra costs and long time scales involved. Although we have been successful in enforcing good procedures for developing avionics software, we have failed in other areas. Voting machine software is still regarded as proprietary, and widely shown to be unreliable and insecure. Modern cars have huge amounts of software aboard (there are more lines of code on a Chevy Volt than aboard the Boeing 787), yet no significant certification of automotive software is required. Have people died as a result? We really don’t know. For example in the recent Toyota incidents of unintended acceleration, the final report was heavily redacted, and the government did not have full access to the software. Given the constraints on the study, the conclusion that the government team was unable to find a software cause for the problem was not really surprising. It should not be interpreted, as it sometimes was in the press, as saying that the software was not at fault, but rather that we simply don’t know. As an example from another safety-critical domain, medical instrumentation software is supposed to meet certain FDA certification standards, but a loophole allows modification of existing devices to be grandfathered in, and from the extent to which this loophole is used, you would think that no new advances had been made for a long time. In one ironic case a patent was invalidated on the grounds that the FDA application said that no new technology was involved. Have people died because of software failures in medical instrumentation? There we do know that the answer is yes (for example the Therac-25 accidents as summarized in http://www.ccnr.org/fatal_dose.html), and the recent uptick in incidents of software-related injuries and deaths from insulin pumps is causing the FDA to take another look at certification requirements for these devices.
The FAA is moving slowly on the issue of drone software certification because of concerns that we don’t know how to proceed safely, but as we see, the U.S. Congress (with police forces and national security agencies egging them on) has signaled that delays are not acceptable, and you have to worry that any attempt to require full certification of drone software will be met by heavy opposition from interests that want these things in the air yesterday.
To make things worse, the complexity of drone software is far higher in my view than standard avionics software. If we have hundreds or even thousands of these things buzzing around in our cities, we are not going to be able to have anything like a coordinated air traffic control system to make sure they don’t cause dangerous collisions, so we will have to depend on autonomous software of far greater intelligence than typical avionics software of today, or on the skills and diligence of the operators controlling them remotely. These people are essentially doing what teenagers do when they play video games. The big difference is that a mistake with a drone can kill real people, unlike a mistake in a video game, which resets and gives you another life.
Do I have a simple suggestion to fix this worrisome situation? Unfortunately no. I think it’s really a very difficult problem from a technical software point of view, from a regulatory point of view, and perhaps also from a political point of view in light of a popular current theory that we are over-regulated and that regulations kill jobs. I fear that Congress is steaming ahead here much too rapidly, without a sufficient appreciation of the risks involved. I understand that many may be worried about Fourth Amendment implications of drones, but surely we can all agree that the safety issue is paramount. We don’t want these things crashing into people and causing death and destruction even if they don’t have sidewinder missiles!
About the author:
Dr. Robert Dewar is co-founder, president and CEO of AdaCore and Emeritus Professor of Computer Science at New York University. With a focus on programming language design and implementation, Dr. Dewar has been a major contributor to Ada throughout its evolution and is a principal architect of AdaCore's GNAT Ada technology. He has co-authored compilers for SPITBOL (SNOBOL), Realia COBOL for the PC (now marketed by Computer Associates), and Alsys Ada, and has also written several real-time operating systems, for Honeywell Inc. Dr. Dewar has delivered papers and presentations on programming language issues and safety certification and, as an expert on computers and the law, he is frequently invited to conferences to speak on Open Source software, licensing issues, and related topics.
Part 1 of this three-part article reviews the basics of object-oriented programming and summarizes the challenges it presents for high-integrity programming. Part 2 will provide a primer on the Ada programming language, and Part 3 will detail the tools Ada offers to help developers meet the OOP challenges.
---------------------- If you found this article to be of interest, visit Military/Aerospace Designline
where you will find the latest and greatest design, technology,
product, and news articles with regard to all aspects of military,
defense and aerospace. And, to register to our weekly newsletter, click here.
I agree RC aircraft rules are a good place to start, but they are usually over unpopulated areas and noted to pilots. What happens when everywhere is opened to drones? As a private pilot I'm very worried about one of those drones colliding into me.
With respect to doors being smashed in the name of delivering a subpoena, I don't want to sound paranoid or sound like one of those survivalist guys, which I'm not, but given today's political climate, particularly taking into consideration whether or not you live on a neighborhood susceptible to this type of police action (it wouldn't and doesn't happen in affluent communities) one might want to consider installing a reinforced door or even, perhaps, a fake door that is actually a wall, with the real door located elsewhere. This sounds ridiculous, but but it is a fact that the wrong doors have been smashed down and innocent people killed. (Just watch any episode of the TV show Cops (What we now consider as normal and "acceptable" is scary.)) Unless and until Congress and/or the courts do something about this, what I'm describing may be the only practical solution short of moving to another neighborhood. Wayne.
By downgrading the professional status of engineers, societies wordwide have lost control over who makes what.
With regard to weapons, this is A Bad Thing.
Drones are something that really should not be developed without licensing; but there is no longer any way to rein in the techies who can do this stuff.
A Drone, like an amateur radio set, shouldn't be deployed without licensing, because the potential for nuisance, nay disaster, is hugely greater.
Airspace is a public resource with risks to health and its use needs to be common-sense rationed to trained professionals, just like pharmaceuticals, medicine, guns(except in the US), high voltage electricity, poisons, biohazards (oops, already losing that one).
Yes, and it was captured by technology created by www.keshefoundation.com. Listen to Sterling Allan's interview from this website. You will be amazed. Ask yourself a question: How can a drone be captured while flying at high speed, intact and so that self destruction sequence was not able to start ? I particularly liked the bit where Mr. Keshe said that F16 and F18 are obsolete. They can fly at at Mach 2 or Mach 3 at most and need refueling every two hours. Technology developed by Keshe Foundation can fly Mach 30, 40, 50 and dont need refueling. They develop their own gravity that is always 1G, so pilot don't feel the high speed. They are also undetectable in radar. I could hear Allan gasping when he heard this. This technology will be given to all governments and a demonstration will be held during this month. Iranian's are using 4th generation tech, Keshe Foundation is currently finishing testing with their 6th generation tech. Too good to be true ? Well, a US spy drone was captured while in mid air. Makes one think, yes ?
Drones of incredible capability are available right now for a few hundred dollars and they can be operated by virtually anyone that is reading this forum. Checkout DIYdrones.com to see the open source state of the art. Today A checkbook is all that is required to own a drone.
When you talk about high-profile passenger plane incidents you're dealing with issues like "icing over" multiple pitot tubes which louses up all the parameters coming out of the air data system. This is generally a "legacy architecture" issue, I could be wrong but I wouldn't expect to find that technology in a modern drone design when more reliable data comes from navigation data provided by the GPS and/or inertial system. But it does indicate we need to be careful we don't "mandate in" components from older designs to modern drones for collision avoidance reasons simply because these are components we have a "safety record" for from experience on piloted aircraft, awful as it may be, and rushing pell-mell towards a solution tends to increase the risk that bad decisions like this may creep into the specifications.
Air France crash had a similar problem, the plane was flying fine but its instruments went wild...the pilot got lost not knowing which indicators to trust and which not...and probably didn't have enough experience in actually flying the plane without autopilot...Kris