VME: Can you briefly describe DDC-I’s safety-critical software lineup to remind readers of your vantage point?
MORRIS: DDC-I has been involved in safety-critical software design and development for the entire 28 years of its existence. We have software development tools for all the Safe Programming languages such as Ada and JOVIAL. We also help our customers get their applications and systems certified to the FAA DO-178B level "A" specifications. Products include compilers and debuggers for Ada83 and Ada95, JOVIAL, C/C++, FORTRAN, and Real-Time Specification for Java (RTSJ). Services include application development, certification test suite development, DO-178 processes, and DER support. Our tools support all the major safety-critical Operating Systems (OSs) from Wind River and LynuxWorks as well as our own POSIX microkernel. The majority of our customers are defense or aerospace related.
VME: What needs to happen in the industry in the next five years to make DO-178B certification easier for developers and their customers?
MORRIS: In a single acronym, RSC, which stands for Reusable Software Component. If more companies developed their applications, middleware, or operating systems to meet the FAA’s requirements for an RSC, that would make software reuse possible and a lot less costly. Then it would be more of an overall systems-level testing rather than component-level certification. This, of course, would require the registrant to work closely with the third-party software developer to get a first platform certified. It usually is a larger effort and thus more expensive for the first one. The savings come in the follow-on use of the software.
VME: Which hardware technology has impacted safety-critical software development most in the past five years?
MORRIS: From our vantage point, the fact that most are now using COTS processors and peripherals with standard interfaces greatly simplifies the safety-critical software development since the integration only has to be done once. The DoD MOSA initiative also drives much of the safety-critical development to use COTS hardware. So, we as the software developer interface to the processor only once and can reuse that effort and at least the artifacts for that integration.
VME: Which advances in software development have most impacted critical defense apps?
MORRIS: I believe that OSs that have the RSC designation have the biggest impact. It saves a tremendous amount of time and money for the system developer. Another important advance in OSs is ARINC-653 conforming OSs, which prevent one misbehaving application running on the same processor at the same time as other applications from bringing these other applications and the entire system down.
VME: What about DDC-I’s target customers – what are their biggest technical issues and how will they be solved?
MORRIS: Because our customers develop mission-critical and safety-critical systems, the best programming language to date for these applications is, without argument, Ada. However, Ada has fallen from favor for various reasons. Chief among the reasons is the lack of skilled Ada knowledgeable programmers. Thus, finding engineers with Ada programming capabilities is difficult at best. This is forcing customers to develop systems in C++, which until the beginning of this century, was what engineering graduates were trained in.
The problem with C++, though, is that it is inherently unsafe because it contains the C programming language as a subset, and thereby among other things has inherited the problems of dangling pointers and automatic type conversions (the compiler second-guessing the intentions of the programmer). C++ does not (as opposed to Ada and Java) provide the mechanisms for detecting most programming errors early on in the development process either, where they are least expensive to correct.
The problem is now becoming even more complex since the engineering schools are now churning out graduates with little or no C++ experience but rather, Java. Java is better than C++ in many cases but still not safety critical. Recently, the Java community has established its RTSJ that can be used in mission-critical but not safety-critical systems. But, even there, the Java community is driving to develop an open specification of Safety Critical Java (SCSJ). This should solve the problem our customers are facing. Java is well known, there is a wide talent pool, and it is an open specification and thus will be COTS.
VME: What are the benefits of mixed language development and debugging?
MORRIS: Mixed language development allows for reuse of software modules originally developed in a legacy language where the new application is written in a current language like, say, Real-Time Java. If mixed language development were not an option, then such reuse would require a potentially costly rewrite of the old software in the new language, followed by extensive testing at least to the level at which the software was tested originally. Mixed language debugging makes it possible, when debugging the new code, to follow call chains into the old code and inspect the objects of the old code. Debugging the mixed language application is then "seamless" and requires just one debug session. Without this feature, the programmer would have to run multiple debug sessions, and it would be difficult to set breakpoints and keep track of execution and object values.
VME: Why should the DoD look at converting its legacy code to a contemporary programming language?
MORRIS: Military programs live on for generations, but technology does not. Many DoD programs have to be supported for 40+ years. How many COTS items are still around from 40 years ago? The AM radio or the light bulb maybe. So, the DoD is spending tons of money supporting obsolete systems. Even though programming languages last longer than hardware products, they have a shelf life as well. I am aware of many programs still trying to support avionics systems developed on VAX systems a generation ago. They have been known to buy VAX systems on eBay to replace the VAX systems that have failed or to have some insurance that they will still have hardware in case the system does fail.
Many of our key programs are being maintained on obsolete hardware with tools that are also obsolete. Many of these applications were designed with no operating systems but only bare-board runtime systems and schedulers. So, each time the DoD needs to migrate to a new hardware, they have to develop a new port to the target hardware. They should not only migrate to the state-of-the-art programming languages, but also to a popular RTOS. This way, they will be able to migrate to new hardware much more easily as the application is written to the RTOS API and not the hardware drivers. This puts the burden of the hardware port on the COTS RTOS vendor and not the DoD program.