RTC Magazine

As the complexity of embedded systems evolves, real-time Java has come to play a more central role in large-scale applications that demand higher levels of abstraction, portability, and dynamic behavior. Such applications are taking on roles in management of network infrastructure, automation of manufacturing processes and control of power generating equipment. To meet these demands, real-time Java vendors have moved increasingly into the mission-critical domain.

The accelerating penetration into mission critical and the expected eventual integration into safety-critical applications has increased the need to assure that Java can deliver reliable operation without exceeding resource constraints. Among the breadth of conflicting objectives imposed on mission-critical Java developers are ease of development and maintenance, support for dynamic behavior and on-the-fly workload reconfiguration. Additional requirements include high performance, soft and hard real-time constraints and cooling, along with reduction of physical footprint and power consumption,

To meet these heightened demands, standards are being developed to assist developers in making the engineering tradeoffs necessary for components of mission-critical software.

What Does Mission Critical Mean?

While there are differences of opinion about the precise characterization of mission-critical computing, the general consensus of what “mission critical” means centers around the following attributes:

• Mission size: Mission-critical software requires a minimum of one “person year” and more typically 10-100 person years of development. Smaller projects generally cannot justify the higher costs associated with mission-critical development methodologies.
• Critical role: The role of software in fulfilling the mission must be critical to the mission’s success. If the software only contributes to convenience or comfort, it is not mission critical.
• Dedicated resources: Typically, all of the computing resources that run the mission-critical software are dedicated to mission-critical activities and are not available for non-critical computing.

Mission-critical computing involves a broad spectrum of applications. Resource-limited applications such as deep-space probes, remote planetary exploration and communications satellites stand in contrast to the resource-rich applications of telephone switches, semiconductor manufacturing and air-traffic control.

But Why Mission-Critical Java?

Given the breadth of domains spanned by mission-critical software, one challenge is to establish a sufficiently large area of common ground on which to base meaningful standards for mission-critical computing. Here, we outline key requirements that are common to most, if not all, mission-critical software systems.

Part of what makes mission-critical software difficult is the need to integrate large numbers of independently developed components, each satisfying different mission objectives (Figure 1). Over time, most mission-critical systems scale upward in response to evolving requirements and expanding capacity. Each step of the integration process must preserve the key characteristics of each component so that no mission-critical objectives go ignored.

Specific mission-critical scalability issues for which Java is particularly well suited include:

• Portability: Mission-critical software developed and tested in one environment needs to run the same when ported to another mission-critical system.
• Partitioning: Mission-critical software is partitioned so a failure in one part of the system does not cause the entire system to go down.
• Composability: New functionality must be integrated with existing components to extend and evolve the capabilities of the existing mission-critical system. Java’s strong encapsulation, object-oriented inheritance, secure dynamic loading and commercially available frameworks such as OSGi contribute to strong composability of Java software components.
• Levels of abstraction: Mission-critical systems include components from multiple levels of the abstraction hierarchy, ranging from low-level hard real-time device drivers running as interrupt handlers to large real-time databases on general-purpose multiprocessor hardware and COTS operating systems. Java standards under development are working to support components in each abstraction layer and to provide efficient, reliable and safe integration of multilayer systems.

Given that the success or failure of the mission hinges on the ability of software to do its job, software reliability is of critical importance. Many mission-critical systems are required to deliver five nines reliability (correctly operating more than 99.999% of the time). To achieve these levels of reliability, existing Java strengths are complemented with certain mission-critical enhancements, such as:

• Reliable dynamic memory management: Automatic garbage collection successfully reclaims all garbage without conservative approximations and defragments memory to ensure reliable future memory allocation.
• Redundancy and fault tolerance: Mission-critical software achieves high reliability in the presence of hardware failures by efficiently maintaining coherent copies of redundant information on standby computers that can quickly take over if the primary computers fail. Java services to support reliable replication of information include transaction processing and databases and remote method invocation (RMI).
• Static analysis and enforcement: The lower layers of mission-critical software require static determination and guaranteed availability of resources to ensure reliable operation.

One difficulty in developing mission-critical systems stems from the challenge of assuring reliable operation without exceeding resource constraints. Tight resource constraints are especially common within lower layers of the mission-critical software hierarchy. Mission-critical developers often need to sacrifice ease of development and maintenance, certain dynamic behavior and general software flexibility in order to achieve higher performance, harder real-time constraints and smaller memory footprint. Standards for mission-critical Java must enable developers to selectively make these engineering tradeoffs for particular components of the mission-critical system. Working with the J Consortium, Aonix has designed a hard real-time subset of traditional Java that will match C in terms of performance and memory footprint.

How is Mission-Critical Java Different?

Mission-critical Java will match different technical approaches to different abstraction layers of the mission-critical hierarchy. Most generally, we divide the mission-critical Java into three layers: (1) non-real-time computing, (2) soft or firm real-time computing and (3) hard real-time computing (Figure 2).

Traditional Java running on commercially available general-purpose computer hardware and operating systems plays an important role in almost every mission-critical system. These components support accounting and invoicing, management reporting and system configuration. At this level of abstraction, traditional Java serves the needs of mission-critical computing well. RMI and CORBA, enhanced to support real-time constraints, serve to connect this layer with the firm and hard real-time layers.

Firm real-time refers to disciplined development in which software engineers carefully analyze deadlines, resource requirements and schedulability. With firm real-time applications, resource requirements are determined empirically by measuring the behavior of individual components. Although empirical evaluation provides statistical confidence, it does not offer absolute guarantees. Typical firm real-time mission-critical components have timing constraints ranging from one or two ms to tens or hundreds of ms.

In the firm real-time domain of mission-critical systems, the Java virtual machine must implement a more restrictive semantics in order to assure reliable and portable compliance with real-time constraints. In particular, certain characteristics of the virtual machine are constrained by the firm real-time mission-critical Java standard. For example:

• Thread scheduling must strictly honor programmer-specified thread priorities. There can be no priority aging.
• All synchronization queues must be maintained in priority order. All synchronization locks must implement priority inheritance.
• Garbage collection must be accurate, defragmenting, preemptible, incremental and paced. All conforming implementations must quantify the performance parameters of their garbage collection implementation to enable efficient porting and configuration of mission-critical software components for particular virtual machine environments.
• A high-precision reliable timer API must support a monotonically increasing concept of time for drift-free scheduling of periodic and one-shot events.
• A virtual machine management API must provide visibility into the internal operation of the virtual machine. This API provides information such as the amount of CPU time consumed by each thread and each priority level, the blocking relationships between threads that are in the process of synchronizing with each other, and garbage collection pacing parameters.

All of these capabilities have been successfully demonstrated in the PERC firm real-time Java virtual machine, a commercial offering that has been successfully deployed in a number of mission-critical applications. As the standards community continues to refine the definition of firm real-time mission-critical Java, the traditional Java APIs will likely be enhanced to support:

• Partitioning of time and memory: Particular mission-critical Java components may reserve a certain percentage of the total available CPU time and/or a particular amount of heap memory.
• Asynchronous transfer of control: Certain threads may identify themselves as interruptible. Other threads may send asynchronous signals to these threads, asking them to service special requests or to abort their ongoing computation.
• Dynamic workload reconfiguration: New real-time tasks can be added to the workload and existing real-time tasks can be removed from the workload while the application is running. The system provides appropriate introspective analysis of resource capacity and workload requirements in order to avoid accepting more workload than can be reliably serviced.
• Dynamic scheduling: The standard Java scheduler is very simple and does not scale well to large, complex mission-critical systems involving many different importance levels, deadlines and possible transient work overload situations. Under system overload, a dynamic scheduler can selectively shed less important tasks to optimize the utility of completed work.

By its nature, the mission-critical software residing in the hard real-time layer is much simpler and less dynamic than the code residing in the firm real-time layer. In partitioning mission-critical systems into firm and hard real-time layers, system architects generally expect the implementation of the hard real-time software to be much more efficient. For examples, see Figure 3.

Although firm real-time Java will probably run 30 to 50 percent slower than C and will typically require several times as much memory, it is expected that the hard real-time mission-critical layer will match C in both speed and footprint. To satisfy these performance objectives, the hard real-time mission-critical Java standard defines the following:

• There will be no garbage collection of objects residing within the hard real-time heap. To achieve high performance and reliable operation,
• the standard will enable safe stack allocation of objects within each method’s activation frame. Compile-time enforcement will prevent the creation of dangling pointers.
• The standard subset of Java libraries that are available to hard real-time developers is restricted, with each library’s time and memory resource requirements clearly defined.
• To support a more demanding assortment of mission-critical hard real-time activities, the number of thread priorities will be expanded, probably to 128.
• To simplify creation of proofs that certain real-time constraints will be satisfied, the hard real-time mission-critical standard will support immediate priority ceiling protocol and priority inheritance.
• Standard class libraries will abstract the implementation of interrupt handlers and device I/O to enable development of portable device drivers.
• To reduce the likelihood of programmer errors and to ease porting and integration of independently developed components, certain timeliness constraints will be enforced at compile and link time. For example, code that disables hardware interrupts must be bounded in execution time.
• To enforce separation of concerns between hard real-time and firm real-time developers, the standard will define a clear partitioning between objects accessible within each of the two domains. Very efficient communication and coordination between firm real-time and hard real-time components is enabled by an efficient protocol that allows selected data structures to be shared between layers, with encapsulation constraints enforced by the compiler.

Work is under way to develop a prototype implementation of the proposed hard real-time mission-critical Java technology. This work is funded in part by the U.S. Navy under contract N00178-08-C-3087. This project is related to standardization of the Navy Open Architecture Computing Environment.

Standardization Activities

As a modern high-level, object-oriented programming language, most of the Java platform is already ideally suited to the needs of mission-critical computing. Enhancements are needed to make Java more appropriate for firm and hard real-time programming, and for high performance and small footprint in the lower layers of the mission-critical hierarchy, and to do so in ways that fully support the broad set of requirements for mission-critical computing in general.

The Java Community Process (JCP), established under the direction of Sun Microsystems, is the organization that officially endorses all Java standards. Under the rules of the JCP, independent organizations (expert groups) submit to the JCP a Java Specification Request (JSR) to announce their intent to develop a new Java-related standard. After the independent organization has developed a draft standard, reference implementation and Technology Compatibility Kit (TCK), this material is submitted to the JCP for its endorsement to make the standard official.

Since February of 2001, the Real-Time and Embedded Systems Forum of the Open Group (www.opengroup.org) has been hosting a series of meetings focusing on real-time Java standards. In May 2003, the Open Group forum agreed upon the wording of a JSR for a safety-critical Java standard to be developed under the leadership of the Open Group. Consensus within the Open Group’s Real-Time and Embedded Systems Forum is that a separate but related standard should be developed within this Open Group forum to address the special needs of mission-critical computing.

Both the safety-critical and mission-critical Java standards will be related to, but not necessarily derived from the existing Real-Time Specification for Java (RTSJ). Though the requirements of both safety-critical and mission-critical computing overlap with some of the requirements of the RTSJ, they also include many requirements that are incompatible with the original design of the RTSJ. The Open Group seeks to provide the forum within which the various constituents of mission-critical computing can share common concerns in order that the resulting standards serve the broadest possible user community.

Aonix
San Diego, CA.
(800) 972-6649.
[www.aonix.com].