What is Real-Time CORBA?

Features and Capabilities: 
Real-Time CORBA 

End-To-End System Predictability

Different perceptions still exist about soft and hard real-time requirements and the components required to ensure end-to-end predictability. The end result of the standardization effort was agreement that the standard would be based on the concepts necessary to support fixed priority scheduling.

The priority connection, however, is only one factor of many in determining real-time behavior. Each system component must maintain consistent priority aware behavior. If any part of the system exhibits non-predictable behavior, it will affect the entire system.

Fixed Priority Scheduling

Fixed priority scheduling consists of determining static priority levels for each task based on a scheduling methodology such as rate monotonic analysis (RMA) or deadline monotonic analysis. This is not to say that priorities cannot change, but that priorities are assigned at system initialization and are not changed dynamically except to manage concurrent access to a system. The secret to real-time CORBA is how to expand the notion of priority in a single processor at a system level.

When the Server receives a message, the server-side ORB maps the priority to the server’s operating system native priority level and invokes the operation on the server at the same relative priority level as the client. The resulting effort is a distributed priority inheritance, providing end-to-end predictability in the same manner that would be expected for an operation to occur in a single process.

Priority Banding

The Real-time CORBA Specification also introduced the concept of priority-banded connections. Priority banded connections allow the software developer to separate different types of traffic by priority, and to dedicate separate connections between the client and server for each priority “band”, where a band can encompass any set of CORBA Priority levels. This allows greater predictability for traffic, where there may be a mix of real-time and non-real-time data on the communications transport at any given time. Priority banding also helps to bound and minimize the chances for any priority inversions.

A critical component of system behavior is the network, with the transport mechanism selected affecting predictability and performance, as well as the Quality of Service (QoS) parameters. Since many real-time systems require either higher performance or greater predictability than currently available through TCP/IP, OIS has developed a number of proprietary methods allowing different protocols within their CORBA implementation. In the ORBexpress Product Line, we provide the ability to plug in other transports, regardless of if they are streaming/non-streaming or reliable/non-reliable.

Resource Management

Real-time systems also need to manage their resources in such a way that each application is able to utilize system resources according to their needs, and in overload situations, according to priority. These resources may be operating system threads, memory, or communication endpoints, or they may be network bandwidth. The Real-time CORBA Specification provides open interfaces into the resources controlled by the CORBA middleware.

Thread Pools

The Real-time CORBA Specification has interfaces allowing applications to configure the transport and thread pools used for the servant implementation. This allows the application to ensure that high priority connections have dedicated resources, and to ensure that there are no unbounded blocking periods based on the resource usage by the lower priority applications. The introduction of the Real-time CORBA mutex as part of the standard ensures that shared resources are protected in a consistent, priority-aware manner throughout the system.

Real-Time Operating Systems

Developing predictable, schedulable distributed systems is a special challenge for any systems developer regardless of the distribution infrastructure. Beyond the obvious dependence on the Real-Time Operating System (RTOS) to provide a predictable thread scheduling, distributed systems depend on additional systems variables beyond the scheduling of a single processor. These additional variables include the performance characteristics of other system components:

• • Bus or network protocol stack implementation
  • Bus or network adapter firmware
  • Bus or network media

In addition, classic real-time scheduling theory such as rate monotonic analysis (RMA) does not encompass the scheduling of multiple processors, much less the scheduling of multiple processors and multiple support bandwidth. Distributed system designers face a difficult task in determining the scheduling of the processors, busses and networks for the systems.

The use of CORBA in real-time and embedded systems provides both the distributed communication as well as the framework for enabling the incremental replacement of system components. CORBA provides the location transparency for the objects within a system. This allows for changes in object location without system re-architecture. Systems can be prototyped as monolithic, simulated on a network, and deployed on an airframe bus. The location of the system objects can be determined via actual system benchmarks. CORBA also abstracts the communications transport. New products can be built with better transport technologies without rebuilding existing software.

In the past, real-time CORBA had difficulty in achieving deterministic characteristics within a given system architecture. However, new generation ORBs, such as ORBexpress, have been designed specifically to minimize the ORB memory footprint and bound the latencies inherent within a system.

Predictable
CORBA

Most of the challenge in building a predictable ORB is the inherent difficulties in building any type of predictable distributed systems. An ORB designed, implemented, and tested with predictable behavior as a primary goal can provide system developers the requisite support for developing and deploying schedulable distributed systems.

The OMG has continued to advance these efforts by introducing and enhancing CORBA standards targeted for those systems requiring predictable behavior, such as embedded and real-time systems.

Soft real-time systems favor optimization of typical performance over worst-case performance, and typically do not require definite upper bound latency on the operations. The soft real-time ORBs typically strive for high throughputs and provide some type of mechanism to control resources. While priority inversions should usually be avoided, but in this case, there is not as much emphasis within a soft real-time scenario.

Hard real-time systems require a definite upper bound for the latency of critical operations. Developers of hard real-time distributed CORBA systems must be able to determine the least upper bound of remote operations. This is possible if the RTOS, ORB, and the transport (bus or network) all use predictable, schedulable logic. Using an unpredictable transport protocol, or a non-real-time system, precludes even the most predictable ORB from achieving bounded, end-to-end invocation latencies.

However, if a well-constructed ORB is given a predictable operating system (i.e. a real-time operating system) and a deterministic transport, the expected end result is a bounded, end-to-end invocation between a client and server.

In order to achieve these bounded communication results, the ORB must:

• • Respect the priorities between client and server for resolving resource contention during the processing of a CORBA invocation.
  • Bound the duration of thread priority inversions during end-to-end processing.
  • Bound the latencies of operation invocations.

Only by designing a hard real-time system, including these critical components, will the designer achieve the hard real-time results expected.