Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Sensors/MEMS

Comply with real-time network needs

Posted: 16 Jul 2008 ?? ?Print Version ?Bookmark and Share

Keywords:real-time performance? TCP? bandwidth? network systems?

Distributed real-time systems must meet smtrict real-time performance demands. Extremely high-performance middleware has evolved that can handle millions of messages per second with tenths of milliseconds of latency, many times faster than messaging systems developed for less demanding enterprise applications. Such technology is fast, flexible, scalable, deterministic and reliable. Just as important, the middleware supports a net-centric design paradigm that eases system integration and evolution.

Real-world applications have driven the evolution of real-time middleware. For example, the Ship-Wide Area Network for the San Antonio class of U.S. Navy vessels comprises hundreds of computers and must be able to take a hit anywhere while continuing operations. This requires middleware supporting automatic discovery, redundant data sources, sinks, data paths and transports. The last-line defense system against incoming missiles and aircraft directs thousand-round-per-second depleted-uranium guns to track down incoming targets traveling at hundreds of miles per hour. It coordinates high-speed radar and decision systems with fast automated guns. The system requires data to be distributed with submillisecond latencies to dozens of nodes, driving the middleware to meet extreme performance requirements. Such applications' connecting of sensors, control and storage forces real-time middleware to provide bandwidth management.

Addressing complexity
Real-time middleware drives communication subsystems; fuses disparate sensors into a single-world view; connects motion control, graphics and controls in flight simulators; and integrates sensors and commands for unmanned vehicles. Each application requires real-time response.

As is often the case, the best way to address complexity is using the simple concept: publish-subscribe paradigm. Conceptually, through publish-subscribe, the necessary information is asked for and sent. The middleware matches senders to receivers, ensuring that each data "contract" is satisfied. In practice, many details must be specified; nonetheless, the overall model is intuitive and usable.

Real-time designs differ from traditional middleware in tuning options. For example, most middleware is built on top of the TCP. In the 1970s, TCP was designed and provided reliable byte-stream connections between two computers. Because it ensures reliability, TCP is very useful and at the same time restrictive. TCP only supports communications between two computers. Its driving state machine has many time-outs; none of them is user-settable. It supports reliability but also hides away all the important details: how many times to retry dropped packets; how much memory to use; when to send retries etc.

Building on UDP
In contrast, real-time middleware is built on top of the User Datagram Protocol, which is a much simpler technology. The middleware offers QoS control of reliability; timing and time-outs; memory and resource usage; network transports; and priorities. It reacts when media drop packets, links go down and hardware fails. Most enterprise middleware uses a daemon-based or broker-based architecture; real-time middleware is primarily based on a decentralized peer-to-peer protocol with no extra hops and no single point of failure. A local in-memory cache provides quick access to recent values without retransmission. Automatic self-discovery and configuration allow components to be added and removed dynamically on a live system without disruption.

Real-time middleware must be blazingly fast. The first step is to slash overhead. Whereas older, client-server designs require a round-trip request/response cycle for each message, publish-subscribe has no request traffic for each message. Older middleware also uses central servers to coordinate data flow. Sending to an intermediate server doubles the latency of sending a "non-stop" peer-to-peer packet, because the packet must be both received and then sent for the second time. In practice, servers may be loaded, congested or not immediately responsive for several reasons. Interposing a server into every transmission also doubles the total traffic on the network.

On hardware and operating systems, the stack-and-raw network transport can handle around 50,000 messages per second. Batching multiple application-level messages into a single transport-level datagram allows server-based architectures to achieve throughput within the range of 100,000 messages per second with latencies of several milliseconds. Because peer-to-peer middleware skips all intermediaries, it is capable of nearly three million application-level messages per second with batching. Peer-to-peer middleware can also deliver latencies below 65?s with no appreciable variation.

Figure 1: Airborne sensors must handle tens of thousands of simultaneous tracks!continuously updated positions of aircraft, ships, vehicles and missiles in an area.

Increasing efficiency
Multicasting is the ability to send a single packet to many destinations. It drastically cuts overall latency and raises effective throughput while increasing efficiency. Multicast can theoretically send information to 50 nodes 50x faster than unicast. However, the reliability of the multicast is a famously hard challenge.

QoS directly affects system performance and capability, and includes:

Reliability!It involves choosing when and how many times to retry dropped transmissions.

Bandwidth control!This entails limiting the bandwidth a single publisher can use.

Resource management!This deals with setting the memory for buffering and retries.

Filters!This involves optimizing information only to those nodes that need them by virtually partitioning the network; restricting the number of updates delivered per unit of time; or delivering only those updates with content that matches a filter.

Fault tolerance!This is concerned with reacting to unexpected failures and situations.

Real-time middleware uses QoS settings to optimize network resources to fit the problem. The middleware may simultaneously receive thousands of updates per second stream of radar tracks; pass updates only every 10s to a human machine interface-operator station; reliably record every reading on a database server; and update a collision checker only for those targets within an 8km radius, all while multicasting to hundreds of applications on the network.

Publish-subscribe middleware allows applications to pool information from many distributed sources and access them from many locations. Many label this new capability as net-centric or data-centric architecture.

A net-centric architecture fundamentally changes how easy it is to design and evolve a networked application, such as the U.S. Navy's E-2C Hawkeye aircraft, a design that net-centric thinking transformed. This architecture is more modular and can be maintained than older, client-server-based designs. It provided a structured overall design paradigm allowing expansion, changes and independent development.

Achieving high performance
In 2005, the Object Management Group adopted a standard called data distribution service (DDS) for real-time systems. DDS is the first middleware specification that targets high-performance distributed systems. It includes both an API specification and a wire-protocol design.

It has become the rallying point for high-performance, standards-based middleware. The U.S. Defense Information Services Agency has mandated DDS for all data-distribution applications in the U.S. military. Most major North Atlantic Treaty Organization weapons system designs are upgrading to DDS; and the technology forms the core communications capability for South Korea's new ship systems.

Real-time middleware delivers the performance and functionality necessary to address the realities challenging the embedded industry.

- Stan Schneider
CEO, Real-Time Innovations Inc.

Article Comments - Comply with real-time network needs
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top