Though developers of avionics software are among the most conservative in the software engineering community, and rightly so, Java is beginning to penetrate even this very specialized industry. The reasons are compelling. Java, designed in the 1990s, offers much better abstraction and stronger object-oriented encapsulation than C and C++. Rigorous enforcement of the type system reduces software engineering errors. Built-in syntactic and library features make multithreaded programming on multi-core processors straightforward. And the popularity of Java makes it easier to recruit Java developers, to license Java development tools, and to find and reuse off-the-shelf software components. Finally, the Java platform offers portability and scalability benefits that far exceed what has been achieved with more traditional legacy languages.
Compared with development in C and C++, typical Java developers are roughly twice as productive during the implementation of new capabilities, and are up to ten times as productive during typical software maintenance activities. With respect to this metric, software maintenance includes making small incremental refinements to the existing software in order to fix bugs, tune performance, or evolve functionality; porting an existing software system to a new operating system or hardware platform; and combining the capabilities of one large software system with another in order to build a larger system that combines the capabilities of each independent subsystem.
The relevance of traditional software engineering benefits to safety-critical avionics development is growing as the software used for avionics and UAVs increases in size and complexity. At the same time, operational practices for these systems are placing increased demand on modular composition of software components.
Early UAVs were little more than remote-controlled drones, with no onboard decision making, and only the minimal control software required to implement the operations requested by the remote-control operator. More recent UAVs are significantly more capable. Some autonomous UAVs now run their own mission planning software onboard. UAVs that operate autonomously can respond quicker to unanticipated threats and opportunities. They can also capture and assimilate more data from a more flexible array of sensors, and can make more informed decisions based on availability of this information.
In the past, the onboard software for unmanned aircraft was small enough that all of the software for each such system could be fully developed and tested by a small team of two or three developers. Today, the onboard software for autonomous flight is much larger, sometimes reaching sizes as large as a million lines of code. Systems this large cannot be developed from scratch for each individual application. Rather, bodies of safety critical code become a library of intellectual property that is maintained and evolved over multiple decades, and the software may be deployed in different configurations for each mission, and across different related products. The software must be reusable and must be easily configured for each distinct application. Because of the rapid obsolescence of microprocessors, with typical processors and many real-time operating system releases having commercial life spans of less than five years, the software must also be portable so as to preserve its value across multiple processor generations and multiple operating systems.
A recent project funded by the European Commission emphasizes these trends. Known as DIANA for “Distributed equipment Independent Advanced avioNics Applications,” this project explored the use of Java as an empowering technology to enable reduction in the costs of avionics software development. Key to the effort was the design and implementation of an advanced avionics platform, identified as AIDA (Architecture for Independent Distributed Avionics). The cost savings derive from shortened development time, reduced software integration efforts, and decreased certification costs. These benefits are achieved through the portability and scalability benefits of Java, which greatly improve the ease with which software components can be reused, custom-tailored for each different situation, and efficiently integrated within different execution contexts. By deploying Java within partitions of an ARINC 653 kernel, the AIDA approach allows the safety certification evidence developed for each application to be directly reused when the same software is deployed as part of a new application.
An interesting aspect of DIANA’s AIDA is to enable dynamic reconfiguration of software components. Since the safety-critical software system is composed of many independently developed software components, there are situations under which these independently developed components may need to be assembled into different configurations in the field. With unmanned aircraft, this is especially relevant to configuration of a UAV with a particular array of sensor and weapons systems on the ground, prior to launching each mission. Depending on the objectives of a particular mission, the UAV may deploy with still-image cameras, infrared (IR) video cameras, electronic eavesdropping equipment, sensors capable of detecting nuclear weapons and materials, LIDAR, cloud-penetrating RADAR, ground-penetrating RADAR, or SONAR sensors. In most cases, the amount of data available from the UAV’s on-board sensors far exceeds the available radio communication bandwidth for transmission of data to a command and control ground station. For this reason, it is highly desirable to perform data analysis on board. If the UAV carries weapons, the choice of weapons carried for each mission may also be subject to configuration choices. In many cases, new sensors, new weapons, and new analysis algorithms will become available after the UAV is initially developed. Being able to reconfigure the UAV’s onboard software to accommodate these new capabilities adds greatly to the generality and utility of the UAV.
A secondary motivation is to keep an aircraft in service even when certain onboard avionics computers may have failed. Typical systems offer redundant flight computers. If one of several flight computers fails, the commercial aircraft or UAV may still be able to remain in service.
Suppose a commercial aircraft or UAV normally runs with three general-purpose AIDA computers. Each of these AIDA computers is running a partitioned kernel and is able to reliably execute multiple mission-critical software modules. In order to fly commercially or launch a particular mission, a certain minimum set of software capabilities must be present. In some cases, certain modules must run redundantly, on different computers or in different partitions of a secure kernel. If one of the three AIDA computers fails to boot, it is disabled and removed from the aircraft. If a replacement computer is not immediately available, the plane may still qualify for commercial flight or UAV missions if the remaining two AIDA computers can be configured to run all of the essential software modules with the required levels of redundancy. The topic of reconfiguring software modules on the ground, in preparation for flight as well as in the air, in case a hardware module fails in flight, has also been considered as part of the DIANA research effort but has not yet been thoroughly studied.
Each avionics software module has different criticality levels. Unmanned aircraft for military applications generally have less stringent safety requirements than commercial aircraft, and several unmanned aircraft have already been programmed with the Java language. Representative applications include ScanEagle by Boeing, Barracuda by EADS, J-UCAS X-45c by Boeing, and Taranis by BAE. The X-45c and Taranis projects are both autonomous aircraft, and the onboard mission planning software for both of these applications is written in Java.
While most current applications of Java in avionics applications target less critical systems, an effort to define a standard subset of Java that is appropriate for use in the highest levels of safety criticality, DO-178B Level A, has been ongoing since 2006. The key objective in establishing this standard is to simplify the code generation model and the run-time environment in order to reduce the effort required to do full Level-A certification. For example, traditional Java supports dynamic class loading and tracing garbage collection, both of which add considerably to the complexity of the run-time environment and the native machine code translation of Java source. The draft standard for safety-critical Java removes both of these features. A static linker replaces dynamic class loading, and safe stack allocation replaces tracing garbage collection.
Other differences between traditional Java and the safety-critical standard are that:
- safety-critical Java supports only a very small subset of the standard edition libraries;
- safety-critical Java provides a larger range of real-time priorities and more precisely constrains the behavior of the priority-based scheduler;
- safety-critical Java uses priority ceiling emulation for all thread synchronization.
The draft safety-critical Java standard also adds the ability to directly access device I/O registers and to implement first-level interrupt handlers in the Java language. The use of Java even for the highest integrity components of a safety-critical system appeals because Java is more portable and more modular than C, C++, and Ada, and because it is easier to recruit competent Java developers than it is to recruit developers of other languages.
In summary, the choice to use Java for avionics software offers improved developer productivity, increased availability of off-the-shelf software components and development tools, greater ease of integrating independently developed software components, and lower costs for software maintenance. The economies of scale associated with the Java language make it easier to recruit Java developers. Traditional Java has already been deployed in a variety of UAV applications, addressing certification concerns by giving special care and attention to the virtual machine implementation and the application software. Traditional Java can be used in less critical applications, such as DO-178B Levels C and D, and it can be used in military and unmanned aircraft applications that are not regulated by the DO-178B guidelines.
To support the highest levels of rigor required by DO-178B Level A certification, as might be required when UAVs operate autonomously within commercial air space, a specification for a safety-critical subset of full Java is being developed with availability expected in 2011. The safety-critical subset differs from traditional Java in restricting libraries, using safe stack allocation instead of a garbage-collected heap, removing support for dynamic class loading, and adding support for device I/O and first-level interrupt handling.
This article was written by Kelvin Nilsen, CTO, Atego Systems (San Diego, CA). For more information, Click Here