Comment

01 July 2004

The right time is now

The core of real-time performance is its use in control, signal processing, and event response.

Numerous measurement and control applications require real-time performance. To recognize these real-time applications, you must first understand the core of real-time performance and how it works in control, signal processing, and event response. With real-time control, you can continually monitor and stimulate a physical system. Real-time control applications repeatedly perform a user-defined task separated by a specified time interval.

Many real-time control systems exist in the world around you, such as the cruise control in your car or the thermostat controlling the temperature in your house. There are several ways to characterize a real-time control application—control-loop cycle time, determinism, and jitter.

Control-loop cycle time: Most real-time control systems interface with a physical system by comparing the current state with the desired state and then stimulating the physical system based on the comparison.

The time it takes to traverse this loop is considered the control-loop cycle time. This cycle time varies based on the needs of the system. For instance, the control-loop cycle time of an electronic thermostat in a conventional oven is relatively slow. It acquires a temperature, compares that to the desired temperature, and turns the heating coils on or off. In this case a one second loop rate would be suitable.

On the other hand, ovens used in industrial environments require extremely precise temperature for growing crystals and other processes. The control-loop cycle time here would have to be much faster to maintain the stringent temperature requirements.

Determinism: Determinism measures the consistency of the specified time interval between events. Many control algorithms, such as proportional, integral, derivative, require very deterministic behavior.

For example, an elevator gradually moves to the correct floor because of the deterministic behavior of the control algorithm. Without the determinism the elevator would still reach the correct floor, but without the stability.

Jitter: All real-time systems encounter an amount of error called jitter. Jitter is another way of measuring the determinism of a real-time system. You can calculate it as the maximum difference between any individual time delay and the desired time delay in a system.

Hard and soft real time

You can map real-time control performance onto a spectrum of performance.

On one side, hard real-time systems are very deterministic and never miss an event. An example of a hard real-time system is an engine dynamometer. If there is a missed event, the data collected or the road conditions simulated would be incorrect.

On the other side of the spectrum, soft real-time systems do not require the same degree of determinism and occasionally miss events without malfunctioning. An example of a soft real-time system is a temperature monitoring system where missing one data point does not affect the overall trend of the system, because the general trend of temperature is relatively slow to change.

Real-time signal processing

Real-time signal processing has many of the same characteristics as real-time control. It requires deterministic time intervals between repetitive events. But instead of calculating a response, it performs signal processing on the acquired data.

An example of such an application is calculating the frequency of a signal. The application deterministically acquires a collection of values that represents a waveform and then performs a power spectrum on that data in a loop. Although this example analyzes a waveform in blocks of data, it could also have analyzed each data value as you logged it in with a point-by-point analysis routine.

Point-by-point analysis routines: In many applications, point-by-point analysis routines provide better performance. Instead of analyzing blocks of data, these analysis routines maintain a memory of historical data and calculate a new output based on this data and the current value. While these analysis routines take in single values, they generate both single values and waveforms.

For instance, a single-point digital filter acquires a point and outputs a filtered value. A power spectrum function would acquire a point and generate the frequency-domain waveform. Hard real-time performance is necessary in such situations, because missing input values or even acquiring these values after a small time delay destroys the integrity of the historical data for future calculations.

Inline performance: Point-by-point analysis routines reduce the time delay between acquiring the data and generating the processed waveform.

For example, a simple digital filter application acquires 1,000 data points in one second, filters the data, then generates the filtered waveform. Although the filtered waveform is accurate, it is generated an entire second after it is initially acquired, introducing a large time delay or phase difference.

With a point-by-point filter, the waveform is filtered after each value is acquired, reducing the time delay to microseconds.

Improved decision making: You can make better decisions by adding point-by-point analysis routines to applications. By filtering after each point comes in, the resolution in the decision-making process increases. If you want to shut down a system when a low-frequency value exceeds a certain voltage, you can filter the signal and compare it with the limit. With the block analysis routine, the decision happens every second after the waveform registers, and then it undergoes filtering. With the point-by-point analysis routine, you can analyze values as acquired and compare them every millisecond.

Higher performance: Point-by-point analysis routines are often more efficient than their block routine counterparts. Instead of recalculating an output with a whole new set of data, point-by-point analysis calculates the current output by taking into account previous values and the effect of the current value on the previous output.

Real-time event response

With real-time event response, you can respond to a single event within a given amount of time. The real-time system guarantees some maximum response time to a single event. The event can be either periodic or random.

An example of a real-time event response application is a safety monitoring system. If a physical plant enters a dangerous state, the real-time system must respond to the "danger" event within a guaranteed amount of time. The response might include turning off all critical components in the physical plant.

Latency: Latency is the time it takes to respond to an event. It is similar to the determinism in real-time control applications. With real-time event response, there is a guarantee of a worst-case latency. The latency in the physical plant mentioned above is the maximum time it takes to turn off the critical components after the "danger" event occurred.

Real-time operating systems

At the core of a real-time software application is a real-time operating system. One of the main differences between real-time operating systems and general-purpose operating systems is the ability to guarantee a worst-case latency.

With a general-purpose operating system, an external interrupt could go into a queue and receive service later after the operating system has finished its current operation and any other interrupts in the queue. General-purpose operating systems have varying latencies and do not guarantee worst-case latency.

On the other hand, a real-time operating system can halt its current process to handle an interrupt immediately. In essence, the real-time operating system guarantees event response within a certain time interval.

Embedded applications

Many real-time applications are embedded applications, but not all embedded systems exhibit real-time performance. Embedded and real-time are often used synonymously, though they actually describe different characteristics. Although real-time applications always adhere to a strict timing characteristic, embedded systems are not as simple to categorize.

An embedded system is one whose software component is not actively exposed to the user, for example, cell phones or small industrial computers. There is not a defining feature of embedded systems, but they often have smaller memory units, smaller processors, and fewer peripherals such as keyboards. Because they lack the general-purpose nature of desktop computers, you program them as dedicated devices.

Headless: Headless devices are embedded systems without peripherals. Programs easily download to these devices through a network connection. This same network connection often serves as the means of configuring these devices. Although this might seem like a limiting feature, with broadband networks and intelligent application software, you can now create headless devices with a simple pull-down menu.

So, while Windows-based measurement and automation systems satisfy most applications, the determinism of other applications requires a real-time system. You can use existing technology and the deterministic environment of its real-time hardware to create complete, real-time embedded applications. IC

Source: National Instruments (www.ni.com)