COTS software in critical systems: The case for Freely Licensed Open Source Software

Story

December 09, 2010

Dr. Robert B.K. Dewar

AdaCore

COTS software helps reduce development costs for large, long-lived systems, but COTS does not mean proprietary. Freely Licensed Open Source Software (FLOSS) brings COTS benefits but without the restrictions and vendor tie-in typical of proprietary products.

The International Space Station (ISS) (Figure 1) is the antithesis of the notion of Commercial Off-the-Shelf or COTS. There is and will only be one of these amazing items built, and you certainly won’t find it on the shelf. Yet some of the critical software that runs this station was created using COTS tools including, for example, the GNAT Pro Ada compiler, used to build the software running the Canadian Space Arm.

Figure 1: The International Space Station is the antithesis of the notion of Commercial Off-the-Shelf or “COTS.” NASA photo

Why the choice of COTS software for this purpose? Procuring or creating software for large, complex systems is a difficult and expensive process. Addressing this need by increasing use of COTS is a natural response to this difficulty, and it seems to offer many advantages at first glance: reduced cost, economies of scale, widespread use leading to greater reliability, and availability of people who know the system well. These considerations apply especially strongly to one-off projects like the space station, where it is otherwise expensive (and more risky) to build specialized tools.

However, in practice, the promise of COTS is not so easily achieved. One major problem is vendor tie in: If you obtain a proprietary COTS system from a vendor, you are tied into that vendor for support, modifications (in the common case where the COTS software does almost but not quite what you want and must be modified), and availability of updates and improvements. There is also the problem that the general COTS market thrives on frequent updates and rapid obsolescence of old versions. The example of XP/Vista is instructive here, where Microsoft pushed to abandon XP long before users were ready to move to Vista. Even if Microsoft is persuaded (as looks likely) to continue XP support for perhaps another decade, even that is not nearly long enough for some projects.

Modern aircraft such as the Boeing 777 and Boeing 787 (Figure 2) have a very long life, measured in decades. These aircraft have very complex software systems and require the utmost reliability. Software onboard these planes is not only built using COTS tools in many cases, but there are actual COTS software components aboard – where not only the software, but also the certification materials are available “off the shelf.” Given the very long expected life of these planes, concerns about continued availability of COTS tools and components become a critical issue.

Figure 2: Given the very long expected life cycle of modern aircraft such as the Boeing 787, concerns about continued availability of COTS tools and components becomes a critical issue. Boeing photo

One of the things that distinguishes software from hardware (both inside and outside the COTS arena) is that it is notionally easy to modify software. It probably takes no more than a few minutes to completely replace the avionics software of a plane with a new version (not counting, of course, the time and effort to prepare and certify the new version). In the case of one well-known military plane, I have been told that every tail number corresponds to a slightly different set of software components. Hence, the notion of build-once-and-forget certainly does not apply in the case of avionics software.

This ability to change software means that refreshes and improvements to software systems can be implemented in a manner that would not be practical for corresponding hardware systems. Going back to the aforementioned Canadian Space Arm, completely replacing the hardware would be unthinkable; however, there has indeed been at least one complete refresh of the software. But given the possibility of executing such updates, the long-lived availability of software tools and components becomes critical.

Additional considerations in the choice of COTS in software construction include the issues of reliability and warranties. The very fact that a given software component may be used on millions of PCs where reliability is not crucial (or at least is not seen as crucial by manufacturers) means that its use in high-reliability environments is not welcomed by the manufacturers: It is, in fact, actively discouraged with legal disclaimers. In this context, trying to get comprehensive warranties for such products may be completely infeasible.

On the other hand, extensive use can be a significant contributor to reliability, so this widespread use can also work in a positive direction. Software developers can’t guarantee correctness and reliability by testing alone, but nevertheless, a product that has been very widely used tends to become more reliable over time, as problems are smoked out by actual use. In some cases, this method must be relied upon to achieve reliability. As an example, consider ground-based air traffic control systems. Very often, these have to be built on top of general-purpose operating systems such as IBM’s AIX. It is out of the question to certify such systems using standards similar to DO-178. They are far too complex. However, if such a system has been in use for decades, as in this case, that experience instills vital confidence in the system.

Thus, COTS software can provide many advantages. But the fundamental difficulties of inability to make custom modifications and guaranteeing long-term support can often stand in the way of these COTS promises. Unless these problems can be solved, the military industry will fall back into the mode of procuring expensive custom technologies.

Using FLOSS COTS yields best of all worlds

One interesting response to these general problems of acquiring and using COTS software products can be found in the use of commercial Freely Licensed Open Source Software (FLOSS) products. The use of FLOSS COTS can potentially address these fundamental concerns and provide COTS advantages without the attendant disadvantages. These FLOSS advantages include:

Accessible source code

First, the fact that the sources are always available and can be freely modified means that it is at least possible to make modifications. Furthermore, these modifications can be made either by the customer, or by the manufacturer, or by a third party. In the case of proprietary products, the manufacturer can by technical and legal means maintain a firm control over such modification, but the free licensing associated with COTS FLOSS means that such control is not possible.

Perpetual availability

Second, the free licensing means that anything that is out there stays available forever. In the case of proprietary products, manufacturers can force upgrades by licensing conditions, or simply by making products stop working. (For example, some functions of Quicken stop working after a few years if you don’t keep upgrading to the latest version.) In the case of FLOSS products, the licensing guarantees perpetual availability, and long-term support can be provided by the vendor, the customer, or a third party.

Emphasis on support

Finally, the commercial FLOSS market is support-oriented. It doesn’t work to just dump a FLOSS product on the market with no support and expect people to buy it. The precise reason people will pay for something that might otherwise be downloaded free from the Internet is to get a high level of support. If this support means making minor modifications for specific customers or keeping support alive forever on old versions, then it will be provided at a reasonable price. If the manufacturer won’t provide this at a reasonable price, a third party can step in to provide that support. In the case of the GNAT Pro Ada compiler we mentioned in the context of the space station, AdaCore makes new versions available annually, but we still have customers using versions well over 10 years old, which we expect to continue to support indefinitely. Making minor custom improvements is an important part of our commercial offering.

FLOSS for success

In summary, COTS software tools and components are here to stay in the context of critical projects, and the increasing reliance on FLOSS-based COTS tools can ensure that the promises of COTS can flourish without the common disadvantages of this approach.

Dr. Robert B.K. Dewar is cofounder, President, and CEO of AdaCore. He has been involved with the Ada programming language since its inception in the early 1980s. He has coauthored compilers for SPITBOL (SNOBOL), Realia COBOL for the PC (now marketed by Computer Associates), and Alsys Ada, and he is a principal architect of AdaCore’s GNAT Ada technology. Robert has also written several real-time operating systems for Honeywell, Inc. He is frequently invited to conferences to make presentations on a range of topics including open-source software, programming language issues, and safety certification.

AdaCore 1-877-787-4628 www.adacore.com