Ada in the IoT?

For the great majority (I assume) of my audience, if you think about Ada at all, you probably think about military and aerospace applications. Using Ada in the IoT might seem like overkill – cumbersome, over-powered and entirely unnecessary. Or so I thought until I talked to Quentin Ochem of Adacore at ARM TechCon.

For those of you unfamiliar with Ada, I’ll start with a quick summary. The language was developed under a US Department of Defense contract with the objective of ensuring intrinsically high quality by construction. This would be achieved, to the greatest extent possible, be ensuring errors would be found in the compiler rather than at run-time. The language was named after Ada, Countess Lovelace, the only legitimate child of Lord Byron and famous for developing the first algorithm to be run on a machine. Closer to home, VHDL was founded in large part on Ada syntax, thanks to another US DoD contract which wanted to maximize overlap of this hardware language with the software language.

As you might expect, Ada products from Adacore have been used in spacecraft, aircraft and military programs. But they have also been selected for hospital IS management, financial systems, grid management, railway control and air traffic management systems. They are also being used in a Toyota research program in Japan, together with Adacore’s Spark formal verification software, to develop a vehicle (car, truck, etc) component implementation that can be proven to be free of run-time errors. These are all programs that come closer to our day-to-day lives, yet all require very high assurances of safety, and increasingly security. And since many of these applications are either mobile or remote, they clearly impact IoT implementations, whether at the edge or in the cloud.

Of course one concern might be that Ada run-time libraries would be too heavy to be used at the edge. But Quentin told me they have already ported to an AVR 8-bit controller with 256KB memory, so that shouldn’t be a concern. Another might be lack of a pool of trained software engineers. Quentin said this is more an issue of commitment than difficulty. In their experience, good C/C++ developers can get up and running with Ada in a week. Presumably it takes longer for them to become fully proficient, though perhaps no more so than in switching from C++ to Python. (And yes, Ada now supports object-oriented programming if you were wondering.) Another concern would be interoperability with legacy software (who can afford to rewrite everything in Ada?). This apparently isn’t a problem – bindings are provided to interface with C, C++, Java and Python, among other languages. You only have to consider Ada for the bits you feel are safety-critical.

One very interesting tool in the Adacore product lineup is Spark, a formal prover for Ada code. Formal proving started for software but has been commercially much less successful that its cousin in hardware-proving, perhaps in part because of the loose structure of common programming languages. As a tightly constrained language Ada software-proving is apparently more tractable (though presumably you still need to bound the scope of code in which you are aiming to prove properties). This should further enhance the appeal of Adacore in safety-critical applications. By way of example there is an interesting blog on rewriting part of the control software for a drone in Ada, to make the device less prone to crashes. Safety-proving in this project was accomplished using Spark.

As we move (asymptotically) closer to IoT hardware aiming for safety and security by construction, questions about why we can’t do the same for the software running on that hardware are likely to become more urgent. Perhaps Ada’s day in the commercial sun is dawning. You can learn more about Ada and Adacore HERE.

More articles by Bernard…