The development of military software, with its strict requirements onsafety and security, is a challenge few programming languages addresswell. Java, however, is in the midst of an evolution that is making thepopular desktop computing language ever more suitable for militarysystems.
Recent work in developing a safety-critical version of Java, augmented by activity promoting increased security, is turning thelanguage of the Internet into the language of the future for robustsystem designs.
Military software challenges developers on many levels, due in nosmall part to the powerful and dangerous systems it controls. Thesoftware must exhibit real-time operation, provide security against avariety of threats, and above all be safe in order to be acceptable.The real-time requirements can be met by a number of operating systemsor through various programming languages, but security andsafety-critical operation are harder to come by.
Security in software means many things. One is that it must beimmune to attack from malicious or even faulty code. Applicationsoftware running on the system should not be able to “hijack” thesystem and assume control or be able to “crash” the system and renderit useless.
At worst, applications should simply fail at their individual tasksand leave the rest of the system running as expected. Secure softwareshould also prevent the compromise of sensitive information.
This sensitive information may be data, such as code encryptionkeys, or behaviors such as frequency-hopping algorithms or even systemfunction. The security should not only protect software in the field,but protect it during development and deployment, as well.
Safety-critical software faces highly demanding requirements at allphases of its development. These stem from the key requirement that thesoftware must be designed to be highly reliable, either by providinghigh-availability through system error detection and fail-over or bybeing fail-safe. Fail-safe designs are those that will always enter asafe state regardless of the failure mechanism.
Determinism is Key to Safety
Achieving this reliability goal, in turn, requires that the software befully deterministic and have no possible paths that will lead to anunknown or unexpected response. To ensure that safety-critical softwaremeets these criteria, it must undergo rigorous testing thatexhaustively evaluates all possible branches within the software.
The ideal programming language for safety-critical software would atthe same time allow succinct implementation of the design, avoiderror-prone constructs, ensure a high degree of checking by thecompiler and still enable traceability from object code level to sourcecode level.
Traceability from object code level to source code level means thatactions at the object code can be mapped to the source level and viceversa, an attribute that greatly eases meeting the requirements onsafety-critical software.
If the language generates object code that do not correspond toactions at the source level, testing and documentation become moredifficult and costly. Similarly, the language should produce finishedcode that is 100% testable, so that there is no “dead code“within the program.
A suitably-designed programming language can go a long way towardsimplifying software development when addressing security andsafety-critical operation. Addressing these needs was one of the goalsin the creation of the Ada language for military systemdevelopment.
Systems experts created Ada and imbued it with critical featuressuch as exception handling to prevent software errors from shuttingdown entire systems, programming constraints that prevented theintroduction of errors, and features to support high-availability anderror-recovery. Ada's design also closed several loopholes which wereand still are present in languages such as C.
Ada was released in 1983 and, to foster system interoperability,ease support logistics, and promote software reuse, the DoD mandatedthe use of Ada in all new system designs that had mission- orsafety-critical requirements.
The DoD did allow a waiver to this mandate, however, if the use ofanother language could be cost-justified. As the computer revolutionswept through the consumer and commercial markets, software languagesand tools for those systems became inexpensive and widely available.
In contrast, Ada had a much smaller application base, so tools costsremained high and the pool of available programming talent remainedsmall. The growing market differential between Ada and commercialmarket languages resulted in many applications becoming costlier todevelop in Ada than in commercial market languages and systemdevelopment projects chose the waiver option in droves, prompting theDoD to remove the Ada mandate in 1997.
Nonetheless, Ada still remains a strong contender for militarysystem development in mission- and safety-critical designs because ofits built-in support for security and safety. Further, the language hascontinued to improve, adopting some of the enhancements that arose inother languages.
The standards group overseeing Ada's development requires that thestandard be reviewed and updated every 10 years. The results of thisprocess were Ada95, which adopted some of the object-oriented(OO) programming features of C++,and Ada 2005, which incorporates further OO improvements as well asenhancements to further support safety and security applications.
Military Java Brews
Now another language is rising that addresses many of the same needsthat Ada targets. The popular Java programming language started outaddressing the vastly different desktop computing environment, but hasbeen evolving to tackle more critical system programming tasks.
The first stage of its evolution was the development of the Real-Time Specification for Java (RTSJ)to address embedded system control with its deterministic timingrequirements. The current stage is the development of a safety-criticalJava (SC-Java).
As a candidate for military software development, the Java languagehas many desirable features. It is widely supported withstate-of-the-art development tools and an extensive experiencedprogrammer base, keeping development costs low and easing long termsystem maintenance. Java's structure guarantees that OO programmingconstructs will be followed, closing the door on many potential designflaws.
As originally developed, however, Java falls short in the area ofsafety-critical design, particularly in determinism and testability.Programs written in Java are intended to run under an interpretercalled the Java VirtualMachine.
The Virtual Machine interprets Java Byte codes – a compactrepresentation of the Java sources – and controls software execution.The breadth of capabilities provided by Java implies a need for afunctionally rich interpreter, which will not be fully exercised by anygiven Java application. This means that the Java program willinevitably include object code that is not needed and which cannot bereached by testing.
|Figure1. Garbage collection in Java based on a high priority thread canresult in unpredictable delays in software execution, preventing itsuse in safety-critical systems.|
Some of Java's automatic features also complicate timing andresource analysis. One of the most significant is Java's automatic”garbage collection,” which eliminates memory leaks by automaticallyfreeing unused memory. In some implementations, this operation runs asa background process (Figure 1 above ).
As a result, however, garbage collection is non-deterministic andoutside of user control. It can occur at any time, so that timing andresource aspects may vary from run to run depending on when during theexecution garbage collection is initiated. Such variability isunacceptable for safety-critical systems.
|Figure2. RTSJ implementation which automatically inserts garbage collectioncode into the object file, creating a program that is difficult tocomprehensively test.|
Another implementation strategy for garbage collection is to havethe Java compiler intersperse code of its own with code that directlyimplements the Java source. This approach, used by some real-time Javaimplementations, allows the garbage collection to be bounded in time.
This approach is not satisfactory for safety-critical systems,however, because it inserts additional paths into the code and thusprevents traceability from final code back to Java Source (Figure 2 above ).
Safety-Critical Java Arises
The appeal of Java's other attributes, however, has prompted the Javadevelopment community to seek solutions to the impediments to usingJava for safety-critical design.
The JSR-302 Expert Group ,composed of companies such as DDC-I with expertise in both Java andsafety-critical system design, formed in August 2006 to define thebaseline language specification and programming guidelines for suchapplications.
The JSR-302 Expert Group is aiming to at least meet the requirementsof the DO-178B standard,Level A , used for certifying avionics system software. A draftversion of the safety-critical Java specification is expected to bereleased for review in mid-2008, with first implementations of SCJavailable by year's end.
The JSR-302 Group's approach has been to start with the Real-TimeSpecification for Java (RTSJ) as its basis (Figure 3 below ). From there theJSR-302 Group is taking steps to limit the size of programs and theJava engine by restricting the SC-Java implementation to the corefeatures that a system must have in order to operate.
|Figure3. Safety-critical Java will be a profile, based on the Real-TimeSpecification for Java and with a limited API, trimmed to essentials inorder to simplify testing.|
This reduction will not change the programming language per se, soSC-Java will be easy for today's Java programmers to adopt. Instead,the specification will simply restrict which predefined classes will beavailable to the safety-critical developer.
Some restructuring of Java may also be required in order to avoidthe accidental use of forbidden constructs. These changes willeliminate some of the standard features of Java but gain the benefit ofgreater predictability for program execution.
Safety-Critical Java will thus provide the means for avoidingfeatures such as garbage collection, dynamic class loading, andjust-in-time compilation. In combination, these restrictions willpermit replacement of the full Virtual Machine with inline codeimplementing the actual functions in use, a key to determinism andtestability.
The development of SC-Java will go a long way toward addressing thesafety requirement of military software design. The securityrequirement has already been partly addressed by the Java architecture,but work still remains. In particular, data security and developmentprotection remain as areas for improvement.
Java Tool Security Growing
The original Java sandbox provided one levelof data security for Web based applications by preventing maliciousapplications from being able to read and report sensitive informationto an outside source.
Code introduced to spy on the system simply does not have access toinformation reserved to other applications. This technology is not theanswer for embedded military applications, however.
Providing this level of security is the task of development toolsand software architects outside of the language itself. One possibleapproach is to encrypt sensitive information and have an operator enterkey codes to obtain access. A captured system, then, could not becompromised simply by reading memory.
The tools are also responsible for securing the developmentenvironment. Built-in system software protection schemes can preventattack from outside sources by implementing anti-tamper technology andby providing an environment that prevents introduced code from gainingsystem control, but they still have a weakness. They cannot preventcode that was built in at the beginning from compromising systemsecurity if it was designed to do so.
Development tools, on the other hand, can be designed in a way thathelps prevent such deliberate sabotage. By creating a trusteddevelopment environment, such tools can prevent unauthorized personnelfrom introducing malicious code into the project data base. It can alsoprovide third-party oversight over code created by authorizeddevelopers to minimize the opportunity for introducing malicious code.
Such tools forthe Java language are now beginning development. They will helpclose the remaining security gaps in Java-based software design.Together with the inherent security of the Java language and thedevelopment of SC-Java, the language of Internet is well on its way tobecoming the safe and secure language needed by military systemdesigns.
Ole N. Oest is Chief TechnicalOfficer and one of the founders of DDC-I.He is a graduate of the Technical University of Denmark, and holds anMS in Electrical Engineering and a PhD in Software Engineering, withspecial interest in programming languages and compiler construction aswell as formal specification and development of programs.