This article is part of the Embedded Software series: Ada for the Embedded C Developer
The technical benefits of a migration from C to Ada are usually relatively straightforward to demonstrate. Hopefully, this article series provides a good basis for it. However, when faced with having to make an actual business decision, additional considerations need to be considered, such as return on investment, perennity of the solution, tool support, etc. This section will cover a number of the usual questions and provide elements of answers.
What's the Expected ROI of a C to Ada Transition?
From a qualitative standpoint, defects can be found at various times in the software-development lifecycle:
- On the developer's desk
- During component testing
- During integration testing
- After deployment
- During maintenance
Numbers from studies vary greatly on the relative costs of defects found at each of these phases, but there's a clear ordering between them. For example, a defect found while developing is orders of magnitude less expensive to fix than a defect found, say, at integration time, which may involve costly debugging sessions and slow down the entire system acceptance.
The whole purpose of Ada and SPARK is to push defect detection to the developer's desk as much as possible; at least for all defects that can be identified at that level. While the strict act of writing software may be taking more effort due to all of the additional safeguards, this should have a significant and positive impact down the line and help to control costs overall. The exact value this may translate into is highly business dependent.
From a quantitative standpoint, two studies have been done almost 25 years apart and provide similar insights:
- Rational Software in 1995 found that the overall cost of developing software in Ada was half as much as the cost of developing software in C.
- VDC ran a study in 2018, finding that the cost savings of developing with Ada over C ranged from 6% to 38% in savings.
From a qualitative standpoint, particularly with regard to Ada and C from a formal proof perspective, an interesting presentation was made by two researchers in 2017. They tried to apply formal proof on the same piece of code, developed in Ada/SPARK on one end and C/Frama-C on the other. Their results indicate that the Ada/SPARK technology is indeed more conducive to formal-proof methodologies.
Is the Ada Toolset Complete?
A language by itself is of little use for the development of safety-critical software. A complete toolset is needed to accompany the development process, especially tools for edition, testing, static analysis, etc.
AdaCore provides a number of these tools either through its core or add-on package. They include (as of 2019):
- IDE (GNAT Studio)
- Eclipse plug-in (GNATbench)
- Debugger (GDB)
- Testing tool (GNATtest)
- Structural code coverage tool (GNATcoverage)
- Metric computation tool (GNATmetric)
- Coding standard checker (GNATcheck)
- Static-analysis tools (CodePeer, SPARK Pro)
- Simulink code generator (QGen)
- Ada parser to develop custom tools (libadalang)
However, Ada is an internationally standardized language, and many companies are providing third-party solutions to complete the toolset. Overall, the language can be, and is, used with tools on par with their equivalent C counterparts.
Where Can I Find Ada or SPARK Developers?
A common question from teams on the verge of selecting Ada and SPARK is how to manage the developer team growth and turnover. While Ada and SPARK are taught by a growing number of universities worldwide, it may still be challenging to hire new staff with prior Ada experience.
Fortunately, Ada's base semantics are very close to those of C/C++. Therefore, a good embedded-software developer should be able to learn it relatively easily. This article series is a resource available to get started. Online training material also is available, together with on-site in-person training.
In general, getting an engineer operational in Ada and SPARK shouldn't take more than a few weeks of time.
How to Introduce Ada and SPARK in an Existing Code Base?
The most common scenario when introducing Ada and SPARK to a project or a team is to do it within a pre-existing C code base, which can already spread over hundreds of thousands if not millions of lines of code. Rewriting this software to Ada or SPARK is, of course, not practical and counterproductive.
Most teams select either a small piece of existing code that deserves particular attention, or new modules to develop, and then concentrate on it. Developing this module or part of the application also will help develop the coding patterns to be used for the particular project and company. This effort typically involves a few people focused on a few thousand lines of code. The resulting code may be linked to the rest of the C application. From there, the newly established practices and their benefit can slowly spread through the rest of the environment.
Establishing this initial core in Ada and SPARK is critical. While learning the language isn't a particularly difficult task, applying it to its full capacity may require some expertise. One possibility to help accelerate this initial process is to use AdaCore mentorship services.
Read more from the Embedded Software Series: Ada for the Embedded C Developer