SAN BRUNO, Calif., 21 Oct. 2010. Real-time operating system (RTOS) designers have succeeded at certifying respective operating systems to the Federal Aviation Administration’s DO-178B safety certification standard, but certifying real-time Java to the DO-178B safety-critical software standard still has challenges.
“DO-178B has not offered a straightforward path for certifying Java or any other object-oriented code,” says Nat Hillary, field applications engineer at LDRA Software Technology in San Bruno Calif. DO-178C offers guidance for certifying object-oriented code to the DO-178C standard. The maturity of Java for embedded devices and the soon-to-be-released standard offered good timing for LDRA to announce a Java version of its tool suite.
“Boeing and Airbus have both publicly stated that certification costs are becoming exorbitantly high,” Hillary says. “The only way for the industry to reduce this increasingly excessive cost factor is by better management of the software development process. Java offers many time-savings features as well as having additional rigor as a language, which ensures that programmers do not make some of the errors that are quite easily made in C. Better quality code leads to fewer errors and less debug time.
“There are two fundamental challenges to certifying Java,” Hillary continues. “The first is the fact that it is dependent on a run-time environment, so it is not possible to certify the program itself; the program needs to be certified in concert with the Java run time." The second challenge involves verifying and documenting the actual source code of the program.
"The biggest challenge is that standard Java, as a modern programming language, supports very high levels of abstraction," says Kelvin Nilson, chief technology officer for Java technology at Atego in San Diego. "While this abstraction makes it easy for developers to create and maintain data processing software, the abstraction complicates safety certification because each line of Java code can represent a large amount of functionality, all of which needs to be carefully scrutinized in the certification effort.
"The JSR-302 expert group is defining a simpler subset of Java that enables more economical certification of safety-critical Java applications," Nilson continues. "Intended to decrease impact on mainstream Java developers, the key changes from traditional Java are no automatic garbage collection because all temporary objects will be allocated on a run-time stack instead of from a garbage collected heap; significant pruning of the standard Java libraries available to developers of safety-critical Java applications; no dynamic class loading; and precise semantic requirements on task scheduling and task synchronization.”
As with C, C++, and Ada, any Java implementations used in avionics systems has to go through the same level of testing rigor, including the use of coverage analysis to assess overall test effectiveness, Hillary says. "This is complicated by the object oriented data types and constructs that are available within Java, so it is imperative that any verification and/or coverage analysis process and/or solution have full awareness of the language and object-oriented concepts.”
To date, there is not an official safety-critical Java standard, yet the upcoming DO-178C object-oriented guidelines will complement Java, Hillary continues.
"The safety-critical Java specification also introduces certain capabilities not supported by traditional Java, such as the ability to directly read and write I/O ports, and the ability to implement first-level interrupt handlers in Java," Nilson says. "However, the key challenges in certifying Java for DO-178B are that it is too big and too abstract, and these challenges are being effectively addressed in the emerging JSR-302 standard."
