Real-time Specification for Java (RTSJ)

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Introduction

Some features of the Java language specification, particularly the non-deterministic runtime garbage collections and threading, have
hindered the adoption of Java in industries for Real-Time Systems and software applications. Both industry representatives and academics
understand this limitation of the application of Java in Real-Time so a workshop at the National Institute of Standards and Technology (NIST)
was organized to discuss and propose a draft for Real-Time Specification for Java (RTSJ).
This requirement lead to the formation of an expert group in the Java Community Process (JCP) to draft a specification for Java in Real-Time.

Origin of Real-Time Systems

The first proposal for operating a computer in real time, as in control systems, was published in 1950.
This publication shows a computer in both feedback (feeding the output to the input) and
feed-forward (feeding the input to the output) loops. It was assumed that analog-computing elements
would be used but digital computing was not excluded. The first digital computers developed specifically
for real time control were for airborne operation. By 1954 a Digitrac digital computer was successfully
used to provide an automatic flight and weapons control systems.

The emergence of Real Time Operating Systems (RTOS) in industrial applications started in the 1960s.
Process Fortran compilers also made their appearance. The advent of microprocessor in the 1970s and
the increase of fast memory began to force attention more on the problems of writing correct and dependable
computer control software.

Definition of Real-Time Systems

The definition of real time systems seemed to vary amongst different groups, such as vendors, software developers,
practitioners, academics, researchers and so forth. Here are some of the definitions.

• The Oxford dictionary of computing offers the definition as: “A system in which the time at which the output is
  produced is significant. This is usually because the input corresponds to some movement in the physical world, and
  the output has to relate to that same movement. The lag (delay) from the input time to output time must be
  sufficiently small for acceptable timeliness”.

The above definition covers different types of systems, from workstations running under Unix operating systems where
the user expects to receive a response within a few seconds to aircraft engine control systems which must respond
within a specified time and failure to do so could cause the loss of control and possibility of loss of passengers lives.

Here is another definition that is defined in the Journal of Systems and Control Engineering:

• “Real-Times Systems are those which must produce correct responses within a definite time limit. Should computer
  responses exceed these time bounds then performance degradation and/or malfunctions results”.

The following is an alternative definition to the above:

• “Real-Time Systems read inputs from the plant (a physical system to be computer controlled, eg: robot,
  supermarket automated entrance sliding door, factory automation process, digital camera and so forth) and
  sends control signals to the plant at times determined by plant operational considerations – not at times
  limited by the capabilities of the computer systems”.

Classification

Real-Time Systems and embedded computers are connected to the environment, which it is working in,
by a wide range of interface devices that receive and send stimuli. External processes all operate in
their own time-scales and the computer is said to operate in real time if actions carried out in the
computer relate to the time-scales of the external processes.

Synchronization between the external processes and the internal actions or tasks carried out by the
computer may be defined by:

• The passage of time, or the actual time of the day, in which case the system is said to be clock based
  and the operations are carried out according to a time schedule.
• Actions, which have to be performed not at particular times or time intervals but in response to some events
  in which case it is said to be event based. For Example, switching-off a freezer when the temperature goes below a
  minimum set-point and switch it on when temperature rises to a maximum set-point. Event based systems normally
  employ interrupts to inform the computer system that action is required. Some systems may use polling, that is,
  the computer periodically asks (polls) the various sensors to see if action is required.
• An interactive based in which relationship between the actions in the computer and the system is much more
  loosely defined. The requirement is that a set of operations in the computer should be completed within a
  predetermined time. An automatic bank teller machine is categorized as interactive based synchronization as it
  requires interactive response from the user (customer) to key-in information relating to a transaction and there
  is a time-limit to response, example, if there is no user response within 20 seconds, then the card is ejected.

Time Constraints of Real-Time Systems

Real-Time Systems can be further divided into two main categories according to their time constraints.

• Hard real-time: These are systems, which must satisfy the deadlines on each and every occasion. An example
  is a system, which checks the temperature in a chemical plant process control. The temperature is sampled to read
  every 10 ms (milli-seconds). The control calculation is carried out and the output value is sent to the
  temperature-controller. This task must be satisfied.
• Soft real-time: These are systems for which an occasional failure to meet a deadline does not compromise
  program correctness. Example of soft-real-time constraint is an automatic bank teller machine. Such an automated
  system is event initiated in that it is started by the customer placing his/her card in the machine. The machine
  response will be specified in terms of an average response time of say, 15 seconds. The actual response time will
  vary according to the time of the day.

A hard time constraint obviously represents a much more severe constraint on the performance of the system as
compared to a soft time constraint and such systems present a difficult challenge both to hardware and to
software developers. Most of real-time systems contain a mixture of activities that can be classified as
clock based, event based or interactive based with both hard-time and soft-time constraints.

Types of Programs

The division of activities carried out by a computer control systems into real-time and non-real-time tasks,
with further subdivision of real-time tasks into two different types (based on time constraints), arises from
the different levels of difficulty in designing and implementing the different types of computer program. Programs
involving real-time and interface operations, are substantially more difficult to construct than, for instance
standard data processing programs. The following are the main types of programs:

• Sequential : Classical sequential programming actions are strictly ordered as a time sequence, which
  the behaviour of the program depends only on the effects of the individual actions and their order, thus the time
  taken to perform the action is not of consequence. There are two requirements for verification. Firstly, a particular
  statement defines a stated action. Secondly, various program structures produce a stated sequence of events.
• Multi-tasking : This program type differs from the classical sequential program in that the actions it
  is required to perform are not necessarily disjoint in time, and it may be necessary for several actions to be
  performed in parallel. The sequential relationships between the actions may still be important. The verification
  requires the application of arguments for sequential programs with some additions. The task (processes) can be
  verified separately only if the constituent variables of each task (process) are distinct. However, if the
  variables are shared, the potential concurrency makes the effect of the program unpredictable. Hence it is not
  capable of verification unless there is some further rule that governs the sequencing of several actions of
  the tasks (processes).
• Real-Time: A Real-Time programs differs from the other types in that, in addition to its actions
  not necessarily being disjoint in time, the sequence of some of its actions is not determined by the
  designer (developer) but by the environment – that is, by events occurring in the outside world which
  occur in real time and without reference to the internal operations of the computer systems.

Java Weaknesses for Real-Time Application

There were issues in Java language specification that slows its adoption in real-time control industries.
The major problem issues were:

• The garbage collected dynamic memory management could interrupt the execution of applications for
  unpredictable intervals of time. This originates from the non-deterministic behaviour of the garbage
  collector, because it chooses when to de-allocate objects from memory heap and in no particular order.
• Thread scheduling. Since the JVM (Java Virtual Machine) relies on the host operating systems scheduler,
  then the operating system must be capable of real-time scheduling. This is not true for all hosts where JVM is available.

It is vital for critical mission real-time control systems software as in a Nuclear Power Plant,
Aircraft Control, Submarine Control, Factory Automation, Airport Aviation Flight Control, Energy and Power Systems Supply,
Telecommunication Satellite and so forth to have a deterministic scheduling of events not in an indeterminate state.
The risks associated with writing such critical mission real-time software in Java far outweighs the other benefits of Java.

Requirement Group for Real-Time Java

In 1998 a group of experts in real-time computer control was formed and coordinated by the
National Institute of Standards and Technology (NIST) to draft requirements for real-time Java.
The members were representatives from 50 different companies, government institutes and researchers
from academic institutions. The main aim of the group was to develop a cross-disciplinary specification
for real-time functionality that is expected to be needed by real-time applications written in Java
programming language and being executed on various platforms. The group workshops at NIST produced
nine core requirements for a Real-Time Java specification, together with number of derived sub-core
requirements. This is the basis of the Real-Time Specification for Java (RTSJ). The weaknesses of the
Java language specification for writing real-time applications are addressed in the core requirements.

Guiding Principles

The Real-Time Java Expert Group (RTJEG), where the specification leader from IBM produced a set of guiding
principles for the design of RTSJ (Real-Time Specification for Java):

• RTSJ should not include any requirement that limits its implementation to any particular Java platform,
  version or environment (Embedded Java, Personal Java or Micro Java).
• Any modifications shall not, in any circumstances, prevent the execution of properly written non
  real-time software designed for any other JVM implementation.
• Even though the difficulty in specifying platform-independent real-time parameters is recognized,
  the W.O.R.A (Write Once Run All) principles must be pursued to the greatest possible extent.
• The specification should also include the current practice features of real-time systems while
  allowing the addition of advanced ones in the future.
• The most important feature to be pursued is predictability even at the cost of some general purpose performance.
• Any modifications must not include any extension to the language that lead to a requirement of compiler changes and
  hence increasing the likelihood of frequent releases.

Java Specification Request for Real-Time

There is a Java Specification Request (JSR-1) for Real-Time in the Java Community Process (JCP).
The package name of this API for Real-Time Java is called “javax.realtime” and it has already had a
final release in January of 2002. Real-Time Java (RTSJ) targets the EmbeddedJava, PersonalJava, JavaOS
for Business, JavaOS for Consumer, and Enterprise Java (when implemented on an RTOS) platforms.

JSR-1 extends the Java Platform with an industry standard set of extensions that enables the construction of
systems that exhibit real-time behaviour. It also targets both “hard real-time” and “soft real-time” systems.
The “javax.realtime” API addressed the deterministic guarantees and/or control in the areas of thread scheduling,
synchronization overhead, lock queuing order, class initialization, maximum interrupt response latency, and
GC (garbage collector) characteristics.

Real-Time JVM guarantees deterministic run-time behaviour such as a real-time garbage collector. This JVM would
only be implementable atop suitable target platforms, such as a real-time operating system (RTOS).

Design and Implementation

There are seven functional areas of focus for Real-Time Java: thread scheduling and dispatching, memory management,
synchronization and resource sharing, asynchronous event handling, asynchronous transfer of control, thread terminations,
and physical memory access.

• Thread scheduling and dispatching: A fixed-pre-emptive priority scheme with FIFO (First In, First Out)
  order inside priorities is defined to be the base scheduling policy. In addition, a set of features and an API
  are defined to host a variety of other scheduling mechanisms and policies.
• Memory Management: Both the advantages and drawbacks of garbage collected memory are recognized.
  Therefore, two simultaneous approaches are used to overcome the drawbacks: new memory regimes without garbage
  collection are introduced and standard interfaces to install real-time garbage collectors are also available.
• Synchronization and Resource Sharing : The priority ceiling emulation and priority inheritance protocols
  are established to bind the priority inversions in the monitors used to implement the keyword synchronized.
  Priority inheritance is provided by default, with optional priority ceiling.
• Asynchronous Event Handling : New extensions are specified to allow event-driven real-time applications
  to be implemented in RTSJ. Asynchronous event objects are added to represent asynchronous events that are expected
  to occur. These objects are then mapped to asynchronous event handlers to be executed whenever the event happens.
  These handlers are executed as real-time threads. It is easy to code an event-driven system structured so that each
  event is serviced by a thread created for that particular event and it makes the scheduling attributes of each event
  clear to the scheduler. The time between an event and the service of the event is an overhead on real-time
  responsiveness. Thread creation is slow. It is a resource allocation service, and real-time programmers avoid
  resource allocation when they are concerned about time.
• Asynchronous Transfer of Control : The semantics of the interrupt() method is expanded allowing it
  to occur anywhere in the code instead of only in certain blocking calls. An Asynchronously Interrupted Exception is
  then added to specify, through the throws clause in its signature, whether a method is able to receive this exception.
  Asynchronous transfer of control is a mechanism that lets a thread throw an exception into another thread.
• Thread Termination : A means is defined to request the orderly termination of a thread. It uses the
  asynchronous events mechanism to trigger the interrupt() method of the thread. The new semantics of this method
  would then enable correct thread termination.
• Physical Memory Access : A new memory region that can be mapped to a fixed physical location is defined.
  This enables threads inside Real-Time Java to communicate with physical devices directly

Dependent Specifications with implications in Control Industries

There is an extension to the RTSJ, which is the Java Specification Requests (JSR-50) for Distributed Real-Time.
The Distributed Real-Time Specification for Java extends RMI in the Real-Time Specification for Java (RTSJ), to
provide support for predictability of end-to-end timeliness of transnode activities. An Industrial Automation Extension
draft (JSR-7) is a specification for a distributed real-time systems for the Java platform that will be utilized in
factory automation environments as well as other automation application domains. JSR-7 will require the
Real-Time Java (RTSJ) for application development.

The JSR-7 specification will target the basic Java Platform with potential extension to both the Embedded and
Personal Java platforms. The specification will result in an industry standard for factory floor automation based
on Java technologies as well as addressing the needs of an industrial conglomerate with dispersed global offices
and manufacturing locations.

Real-Time Computer control software for large-scale operations is more complex to develop than database application
development and the job of developing real-time systems in Java would be easier because there is already an API that
is fully implemented. The reason for this complexity stems from the multi-disciplinary nature of real-time computer
control. It covers Mechanical and Electrical Engineering, Electronics, Artificial Intelligence, Machine Learning,
Mathematical Modelling, Optimizations and Applications, Physics Digital Control and Computer Science. We will see
Java make a gigantic leap into all areas of automation and control from the small, as in a washing machine or
dishwasher, or the medium, as in office assistant robot, to the huge and complex computer control systems used
in Aircraft carrier, Shuttle Spacecraft, Electrical Power Stations, Telecommunication Networks, and so on.

The autonomous rover vehicle, known as Sojourner explored the Martian surface on a mission in 1997. Both
A.M.E.S Research and J.P.L (Jet Propulsion Laboratory) are laboratories where NASA’s rocket scientists design
real-time computer control software for planetary autonomous vehicle such as the Sojourner. One of their current
tools for developing intelligent real-time computer control is the most popular Java Expert Systems Shell (JESS)
from Sandia National Laboratory. Dr. Ernest Friedman-Hill from Sandia and author of JESS has been giving
lectures to the engineers and scientists at both AMES and JPL about intelligent application using JESS.

Conclusion

The weaknesses and deficiencies of the Java language for Real-Time Systems has been addressed in JSR-1 which
is the API for Java Real-Time, package name “javax.realtime“. The real-time JVM was a result of small modifications
to the Java specification language. As you see that there are other Java Specification Requests (JSR) that will
depend on “javax.realtime” , and the lists will grow over time. We will see Java dominate the softwares for the
automation and real-time computer control industries over the coming years.

Resources

Downloads (RTSJ) Reference Implementation:

• TimeSys download page

Web links:

• http://www.jcp.org/jsr/detail/1.jsp
• http://www.itl.nist.gov/div897/ctg/real-time/rtj-final-draft.pdf
• http://www.real-time.org/preview/java.htm
• http://tao.doc.wustl.edu/rtj/
• http://www.rtj.org/doc/javax/realtime/package-tree.html
• http://www.rtjcom.com/home.html
• http://java.sun.com/people/billf/real-time/rtss98WIP.ps
• http://www.opengroup.org/rtforum/
• http://www.netobjectdays.org/pdf/00/slides/eisma.pdf
• Real-Time ADA and Java

Books:

• Software Design for Real-Time Systems by J.E. Cooling , pub: Chapman and Hall , London (1991)
• Real-Time Systems and their Programming Languages by A.Burns and A. Wellings, pub: Addison-Wesley, Workingham (1990)
• Real-Time System Design by S.T.Levi and A.K. Agrawala , pub: McGraw-Hill, New York (1990)
• Real-Time Software Techniques by W.S. Heath, pub: Van Nostrand, New York (1991)

Journal Publications:

• Journal of Systems and Control Engineering
• Artificial Intelligence in Real-Time Control
• IEEE Transaction on Software Engineering
• IEEE Transaction on Industrial Engineering
• Computer Control of Industrial Processes

About the author

Sione Palu has developed software for Publishing Systems, Imaging, and
Web Applications. Currently, Palu develops (Swing-based) his own software application in Symbolic Algebra Systems
with Visualization Mathematics for high-school level. Palu graduated from the University of Auckland, New Zealand,
with a science degree in mathematics and computing. He has a personal interest in applying Java and mathematics in
the fields of mathematical modelling and simulations, symbolic AI and soft-computing, wavelets, digital signal processing,
and control systems.