CORBA for Real-Time Systems @ JDJ

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> <script type="text/javascript"> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

  Real-Time (RT) Systems are, in the temporal sense, predictable. They're not necessarily fast, though many are; they don't necessarily deal with high throughput, though many do. Their defining characteristic is their temporal predictability. They run glamorous, high-risk, high-speed applications such as fly-by-wire airplane and missile controls, military data collection and display, and manufacturing process control, but they also run more mundane applications such as e-commerce transaction Systems and materials-handling facilities.

  for example, RT Systems ensure that:

  When the high-fluid-level sensor in a tank is triggered, the pump will receive a shutdown message within 10 seconds.

  When engine RPM exceeds 6,000, fuel flow will be lowered within 20 milliseconds.

  95% of credit card sales approval requests will receive a response within one minute.

  These examples also demonstrate some of the differences among RT Systems. They can work in Time intervals that are long compared to a machine cycle. They can be fast (some RT Systems work in microseconds). Or their reliability can be measured statistically, rather than absolutely.

  Real-Time CORBA Architecture

  RT CORBA doesn't define a magical environment that makes a non-RT CORBA application run with RT predictability. Instead, predictability is achieved through control of resources and load. RT Systems must be built on controllable, predictable hardware running controllable, predictable RT operating Systems. Network delay, although frequently not controllable, must at least be taken into account. Local application behavior is carefully controlled using RT OS capabilities, while distributed behavior is controlled using RT CORBA.

  Real-Time CORBA is a set of optional extensions to the standard CORBA ORB. It supports end-to-end predictability for distributed applications by:

  Respecting thread priorities between client and server during CORBA invocations

  Bounding the duration of thread priority inversions

  Bounding the latencies of operation invocations

  Basic Real-Time Architecture

  As Figure 1 shows, RT CORBA extends the client's current interface, the Portable Object Adapter (POA) interface, and adds interfaces for priority settings, ThreadPool management, priority mapping, communications features and a scheduling service.

  Real-Time Priorities and Threading

  When you write an RT application, you never have enough computing resource to get everything done right away so you have to prioritize. You divide your application's activities by priority and, when they run, you assign each activity a priority based on how urgent or important it is or how often it has to be run. High-priority tasks get first crack at resource – CPU, network, even database rows. You prioritize CPU access by allocating threads with assigned priority values, a function supported by your RT OS. Then you assign priorities to these threads based on a scheduling approach.

  RT CORBA runs on many RT OSs. In each OS priorities are represented by integers, running from a minimum to a maximum value. Trouble is, each RT OS defines its own minimum and maximum value and, in a distributed system, you'll probably have a combination of RT OSs linked by the network. To enable interoperable and portable applications, RT CORBA defines a mapping from its own priority scheme termed Real-Time CORBA Priority to the scheme of the underlying RT OS.

  What happens to the priority of a task that migrates over the wire from one CPU to another? There are two priority propagation models in RT CORBA:

  Client Priority Propagation Model: The client's priority is propagated to the server.

  Server-Set Priority Model: The server determines the priority of requests based on its own prioritization rules.

  There are also two basic ways to manipulate threads in RT CORBA. One set of interfaces, derived from CORBA::Current, affects threads for its object (that's what Current refers to, of course). The other affects ThreadPools. Threads in pools can be pReallocated and partitioned among your active POAs.

  Priority inversion (PI) is the bane of the RT programmer. Here's an example: What if a low-priority task, as part of its function, locks a database row in preparation for a read-and-change and then stops executing because a high-priority task takes over the CPU. Suppose, further, that the high-priority task needs the same database row. It can't proceed because it can't get the mutex lock on the row, but the low-priority task can't get the CPU cycles it needs to finish and unlock because other medium-and high-priority tasks keep getting the CPU Time.

  RT CORBA defines a number of mechanisms that reduce both the occurrence and duration of PIs. Priority inheritance sets the priority of a thread based in part on the priorities of other threads (and especially threads doing work that might interfere). Multibanded communications also work to prevent PI, as we'll see in the next section.

  Real-Time Communications

  Communications Quality of Service (QoS) is crucial to end-to-end predictability, and RT CORBA gives you lots of ways to control it:

  You can set Timeout values for your remote invocations, using the Timeout definitions in OMG's recently adopted asynchronous messaging service specification. These let you define Timeouts for the invocation, the response and the round-trip.

  You can use the concept of priority-banded connections, which are just what the name says. This helps keep lower-priority invocations from interfering with higher-priority work.

  You can ask for a nonmultiplexed connection from a client to a server. The low-priority connections serving the riffraff may be totally jammed, but this connection will always be clear.

  Both client and server can select and configure the protocols used to communicate.

  Real-Time CORBA Management

  A number of interfaces are used to set up and manage the features we've just listed. Most are policies derived from POA::policy, so they'll look familiar to CORBA programmers when they use RT CORBA for the first Time. for Real-Time behavior on the server side you'll have to create a Real-Time POA, that is, one that uses the RT::POA interface and bears policies that make it execute in Real-Time mode.

  The rest of this article focuses on news from OMG's RT CORBA workshop.

  OMG's RT CORBA Workshop

  OMG held its first RT and Embedded Systems Workshop this past July in Falls Church, Virginia, sponsored by Highlander Communications, Objective Interface Systems (OIS) and Vertel – three companies that market RT ORBs. (They're not the only ones; look for a longer list of RT ORBs when we discuss the ORB vendors' roundtable.) Indicating a high interest in distributed RT and embedded Systems, the event drew over 140 attendees. If you missed it, plan for next year's, which is already in the works. In fact, there will be two events: one for RT and one for embedded Systems. You'll find the workshop's URL at the end of this column.

  The four-day workshop started with two days of tutorials: the first on CORBA, the second on the RT extensions. Each of the final two days consisted of several sessions of papers grouped by topic, followed by a roundtable. Every session allowed plenty of Time for Q&A. I can't possibly summarize all the papers in this column, so I'll concentrate on a few and summarize the roundtable discussions too, since they're always spontaneous and fun. OMG posts the papers on its public Web site 30 days after each workshop (see RealTime/2000/presentations.htm" target="new" />www.omg.org/news/

  meetings/RealTime/2000/presentations.htm).

  Please don't view the papers and think you have the full benefit of the workshop; most of the benefit (and the fun!) comes from the interaction between the speakers and the audience, and the opportunity to network with many of the world's experts in distributed RT computing.

  Scheduling and Resource Management

  The first session covered scheduling and resource management. Here's a definition of scheduling: in a basic RT system you set priority levels for each of your tasks, prioritizing important or urgent tasks higher than less important ones. Since a task probably involves more than one computation step, setting priorities for every step of every task may be daunting – kind of like assembler programming before higher-level languages were developed. A scheduling service (such as the one in the RT CORBA specification) lets you group multiple steps into an activity and assign all of the steps a single priority. Whether you assign priorities to each computational step yourself or do it via a scheduling service, this is still static scheduling because each task's priority is assigned statically and can't change even if runTime conditions warrant. (If you recall our previous point about client-propagated and server-defined priority models, you'll recognize that a scheduling service will have to take the priority propagation model into account.)

  Dynamic scheduling adapts computational priorities to changing loads, resource availability and urgency. By collecting and analyzing data at runTime and being clever about the way they assign resources to tasks, dynamically scheduled Systems can optimize resource usage and maximize the number of activities that meet their deadlines. If the system is sufficiently clever, it might even be able to deliver predictable performance when our requirements of strict control over the system aren't quite met. Dynamic scheduling is not straightforward! There's a lot of current research in this area, and many ways to achieve (or, it seems, almost achieve) its goals.

  The first paper, from UCSB, described a feedback system that adjusted task priorities based on runTime data. The second, from BBN, added QoS detection functionality to objects' stubs and skeletons, enabling the system to adapt dynamically to changing loads.

  Case Studies/Experience Reports

  Case studies and experience reports were spread over several sessions. These included descriptions of some of the exciting applications associated with RT computing. for example, Boeing Aircraft described the Weapon Systems Open Architecture (WSOA), a project that also includes Honeywell Technology Center, BBN and Washington University (which contributed the TAO ORB). Additional technology came from DARPA and the Air force Research Laboratory. CORBA portions of WSOA include a hard RT application in an F-15E1 jet fighter and a soft (that is, statistical) RT application in a 737 AFL support plane. A flight demonstration is scheduled for next summer.

  The Software-Defined Radio forum (SDRF), a group of companies, is developing a standard for a family of two-way radios that can be reconfigured in software to work at different frequencies and provide different services. (Think of a handset that can be a cell phone, wireless digital pager, web browser or two-way radio for military, aircraft or marine use, depending on the software you download to run it.) Presenters from Mitre, Software Technology, Inc., and Exigent International presented the group's work including contributions from RT CORBA and the CORBA Component Model (CCM). The forum also incorporated U.S. military work on the Joint Tactical Radio System (JTRS). These embedded Systems run in Real-Time, and thus highlighted both of the workshop's main topics.

  Possibly the most impressive combination of RT CORBA and advanced CORBA features in a running, commercial, embedded distributed RT system is the pick-and-place surface mount technology (SMT) assembly machine described by Bruce Trask of Contact Systems. Competing in a rough market, Contact Systems' goal is to produce machines that place electronic components onto printed circuit boards faster, more accurately and less expensively than their competitors'.

  The machine, which fits on a cart, includes multiple-part feeders on both ends and an assembly in the center where the parts are mounted on a board. Two robot arms alternate between picking up parts from the feeders and placing them on the board. While the arm makes its way from the feeders to the board, an electronic camera takes a picture of the three to five components that it has picked up and adjusts the arm's movement to place the components in their exact places on the board. Although the arm takes 200 ms to move from the feeder to the board, it takes only 50 ms to move from the camera position to the board, giving the system little Time to recognize the components and calculate the movement correction.

  Their current machine has five Pentium processors, seven special-purpose processors and 30 microcontrollers, all networked and controlled by an RT CORBA system based on the TAO ORB. The system also uses the new OMG asynchronous messaging service and a (as yet nonstandard) pluggable protocols framework and RT event service.

  Another paper, hopefully with ramifications for the future, covered micro-CORBA – CORBA for the kind of system-on-a-chip that can be produced so cheaply it can be used once and thrown away (or at least not recovered as might happen if you're probing ocean temperatures with networks of sensors that are released to the currents, or battlefields with networks of sensors that may be blown up, or body parts with networks of sensors that are swallowed). Near its smallest, this kind of system-on-a-chip may have to function with only 64 bytes (not a typo!) of RAM, but its size and correspondingly small cost enable a market with nearly unbelievable numbers of units: sales estimates range up to 11 billion units per year. OMG members plan to standardize a version of CORBA for these chips; look for an RFP before the end of 2000.

  Panel Discussion Winds Up the Day

  A panel discussion with six ORB implementers concluded the first day. Each started by introducing his company and product:

  Ben Watson, Tri-Pacific Software, said they have a compliant RT CORBA 1.0 scheduling service that guarantees all activities will meet their schedules. It works with embedded non-RT as well as RT ORBs. They use UML to do RT modeling. (OMG members are now working on a specification that will add RT concepts to UML.)

  Doug Schmidt spoke about his crew back at UCI, now working on an RT CCM implementation that will include dynamic scheduling, RT notification, fault tolerance and load balancing. Doug, now working at DARPA, on leave from UCI, produced the TAO RT ORB while he was a professor at the University of Wisconsin.

  Malcolm Spence represented Object Computing, Inc. (OCI), a company that sells and supports TAO to customers in telecommunications, aerospace, defense, finance and health care.

  David Barnett, Highlander Communications, focused on his company's adaptation of Inprise's Visibroker ORB for RT embedded Systems. This orb supports the minimum CORBA specification (an official stripped-down version of CORBA suitable for embedded Systems), pluggable protocols and a logging facility.

  Bill Beckwith, CTO of OIS, makers of ORBexpress, described his company's fast RT ORB (remember, we pointed out that RT and fast aren't the same thing) which provides priority management, priority inheritance and replaceable transports, and is suitable for hard RT and embedded applications. They foresee use in fiber optic switches, software-defined radios and transportation Systems including boats, trains and airplanes.

  Sam Aslam-Mir, Vertel, said that his company's primary customer base is telecommunications, which requires both long mean-Time between failure and long equipment lifeTimes. (A lot of 30-year-old telecommunications equipment is still in service, although the pace of technology is bringing this down.) Convergence of telecommunications and computer networking, and the expanding Internet infrastructure, is changing the industry.

  Questions from the Audience

  Panelists then answered questions from the audience, including these:

  Asked about ORBs that combine

  RT and fault tolerance, Beckwith, Schmidt and Aslam-Mir said their companies were all close to providing a solution.

  What about security in RT CORBA applications? Bill Beckwith pointed out that this was a hard problem: RT requires a security implementation able to provide encryption, access decisions and other functions via bounded-Time invocations. Currently, no research indicates that this is even possible, although none says it isn't, either. A number of panelists said there was research underway on this topic. Curiously, several of them wouldn't say where it was being done, or by whom.

  Communications is a hot topic in distributed RT, so it was no surprise when the topic of pluggable protocols came up. A pluggable protocols module allows the application programmer to insert his or her own network software interface, extending the ORB to communicate with a new protocol. Several panelists, including Schmidt, Aslam-Mir and Beckwith, said their products now have this or similar functionality. Some OMG members are planning an effort to standardize extensible transport frameworks.

  To close out the workshop on the last day, Brad Balfour of OIS moderated an end-user panel. The first panel presenter, Craig Rodrigues of BBN, described the Future Scout Cavalry System, a military vehicle program, while Ron Snyder of General Dynamics Land Systems (GDLS) presented a series of slides emblazoned with pictures of the military vehicles and hardware that use the most exciting if not the most peace-loving RT hardware and software.

  ···

  OMG and its member companies hold around five workshops each year. To see what's coming up, go to OMG's homepage www.omg.org, mouse over calendar, and select the top item, meeting schedules. This workshop will split into two next year: one on embedded Systems in January and a separate one on RT now scheduled (albeit not yet predictably!) for May or June. You can download the RT CORBA 1.1 specification from www.omg.org/

  technology/documents/recent/ by clicking on CORBA/IIOP and then on RealTime CORBA in the table that comes up next. The Fault Tolerance specification also appears on this table. The RT specification will move to formal/index.html" target="new" />www.omg.org/technology/documents/formal/ with the CORBA 2.4 release; Fault Tolerance will follow with the CORBA 3.0 release now scheduled for early 2001. To follow the Extensible Transport Frameworks RFP, click on www.omg.org/techprocess/meetings/schedule/.

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> <script type="text/javascript"> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>