The concept of real-time is often difficult to understand. While many people assume that real-time means really fast, in reality, it refers to a deterministic response—that is, the capability to reliably and, without fail, respond to an event within a guaranteed time period.
A common misconception is that a real-time application requires a specialized operating system. However, a standard PC running Windows can yield acceptable real-time responses for many applications. By integrating specialized hardware and software into these systems, an even more precise level of real-time performance is available.
Definition of Real-Time
Real-time simply is an adjective used to describe an application’s timing requirements. The timing requirements vary from application to application and from user to user. As such, there is no one universal timing constraint that makes something real-time. Soft and hard terms often are used to more precisely define real-time performance.
A system executing in soft real-time can have variable response rates without compromising overall system functionality. For example, in a temperature-monitoring system, data usually is acquired relatively slowly because the temperature does not change rapidly. Data readings may be taken only once a second, and slight variances in the time between readings will not compromise overall system functionality. A soft real-time system such as this generally can execute on a standard Windows operating system.
On the other hand, a hard real-time requirement demands, without fail, accurate response rates within an absolute time. For example, when controlling a distillation process, pressure readings must be taken consistently at specific time intervals to make critical decisions to open and close pressure valves.
If control loops are not executed within the specified time period, pressures can build to dangerous levels. In hard real-time applications such as these, it is important to have hardware and software that can guarantee the response rate and reliability of critical calculations.
Real-Time Capabilities of a Windows Operating System
In Microsoft Windows NT, Windows 98, and Windows 95, events and interrupts are categorized so higher-priority events execute before lower-priority events. However, the actual processes that respond to interrupts, called device drivers, may disable interrupts for a period of time. When this happens, the system cannot respond to any event until the interrupt is unlocked. If an event occurs within the locked period, the interrupt cannot be serviced, and the response time of the application will vary.
Many people wrongly assume that, if the term real-time is used, a proprietary real-time operating system (RTOS) is needed. They do not feel Windows is reliable enough due to the device driver architecture.
This is not true. A modern PC running Windows will have responses up to a few hundred milliseconds. In addition, by using proper programming techniques, Windows users can yield acceptable real-time responses of tens of milliseconds.1 With the growing robustness of Windows NT, in particular, thousands of test engineers have adopted the use of a PC running Windows for measurement and control.
Microsoft also has increased the real-time performance of its operating systems with the introduction of Windows CE. This operating system allows developers to design their applications using standard Windows development tools and then target the applications anywhere depending on their specific performance needs.
The current version of Windows CE is real-time enough for many control applications. Version 3.0, scheduled to release in late 1999, promises better real-time responses for more demanding real-time requirements.
Real Time in Measurement and Automation
Two basic functions of real-time applications for PC-based measurement and automation are real-time sampling through data acquisition and real-time control. For real-time sampling applications, the requirement is the capability to reliably collect the data at whatever rate the user specifies. For PC-based control applications, the real-time constraint is for control decisions to be made within a set time period.
Real-Time Sampling Requirements
When collecting data from a plug-in data acquisition board, the most important real-time characteristic is to maintain the desired sample rates without deviance. For example, when sampling microphones at 100 kHz to look for specific vibration information, the most important real-time requirement is sampling data at the desired 100-kHz rate with as little time variation between data points as possible.
If data is collected at varying rates, subsequent data analysis, such as applying a fast Fourier transform (FFT), will yield erroneous results. Once the data is acquired, subsequent processing, viewing, and disk storage can be done in Windows as these processes are not part of the real-time requirement of this application.
Computer-based plug-in data acquisition board technology has advanced dramatically during the past 15 years to continually improve real-time performance. For example, in early data acquisition board designs, the host computer had to physically access the board and retrieve the data points for samples to be taken. As a result, sampling a signal at 100 kHz required the host computer to access the board 100,000 times a second. To prevent a loss of data with these early boards, expensive multiprocessor computers running specialized RTOSs were used.
Today, however, a plug-in data acquisition board uses advanced circuitry to handle hard real-time requirements, eliminating the need for a specialized RTOS in many cases. A modern data acquisition board samples data as follows:
First, advanced on-board clocks and timers are used to clock the analog-to-digital (A/D) conversions of the input channels.
This data then is placed into a first-in, first-out (FIFO) buffer. Since this process is hardware timed, its real-time response is extremely accurate.
Once the data has been collected in real-time, it is moved to the host PC using direct memory access (DMA). The data acquisition board uses DMA to stream data into the host computer memory without the interaction of the host computer or operating system.
In fact, DMA streams data to memory regardless of what the host PC or operating system is doing. As a result, these FIFOs on the data acquisition boards maintain the real-time data collection should anything occur on the interface bus to impede throughput rates. With the introduction of the PCI bus, plug-in data acquisition boards with advanced PCI bus-mastering techniques can sample data in real-time and send it to computer memory at rates up to 100 MB/s.
If an application requires sampling rates faster than the data acquisition board can transfer data to the host computer memory, then a board with on-board memory must be used. Also, if an application demands mathematically intensive calculations, you may prefer to use a specialized data acquisition board with an on-board processor, a digital signal processor (DSP), or a field-programmable gate array (FPGA) to analyze and reduce the data before transferring it to the host PC.
When sampling multiple channels, some applications require that the channels be sampled simultaneously. Although there are data acquisition boards available that have simultaneous sampling abilities, they are often costly because a separate analog-to-digital converter (ADC) is needed for each channel.
Thus, many users opt for a data acquisition board with a single ADC and an analog multiplexer used to scan each channel into the ADC. This introduces a time skew between the readings on each channel.
Many lower cost data acquisition boards use a single channel clock to control both the scan rate and interchannel delay. This architecture produces the same delay between all channel samples, and between the last channel of a scan and the first channel of the next scan. For example, when sampling five channels at 10 kHz per channel (100 µs between consecutive points on a given channel), the actual time difference between the sampling of each channel is 20 µs (100 µs/5 total channels). This process is known as “Round Robin” sampling.
To achieve more simultaneous sampling, a technique known as interval scanning is used. In this design, two clocks—the scan clock and the channel clock—are used to control the scan rate and the interchannel delay. The faster the channel clock rate, the more closely in time your system samples the channels within each scan.
For example, if the data acquisition board has a maximum sampling rate of 500 kHz, then an A/D conversion can be done on an input signal every 2 µs. Thus, the interchannel delay, controlled by the channel clock, is 2 µs. The total time difference between when the first channel and the last channel are read during a given scan is 10 µs (2µs × 5 channels). The scan rate, controlled by a separate clock independent from the channel clock, can still scan at 10 kHz per channel.
Real-Time Control Requirements
In a real-time control application, process inputs are collected, a control decision is made, and control outputs are generated (Figure 1). For a control system to be guaranteed stable, the time it takes to execute this control loop needs to be deterministic—that is, time must be constant for each execution of the control loop.
As mentioned earlier, Windows provides some degree of real-time responsiveness within a few hundred milliseconds. However, because many real-time control applications require a faster response time, many users choose alternatives to Windows for more precise and reliable real-time control, such as dedicated controllers.
There are many hardware solutions for real-time control. They range from programmable logic controllers (PLC) and dedicated temperature controllers to computers or embedded systems with an RTOS. Different systems must be used depending on the desired control-loop cycle times.
For example, temperature controllers and PLCs typically perform a few loops a second while embedded RTOS systems can achieve responses in microseconds. For faster requirements, specialized hardware like DSPs and FPGAs may be used to achieve real-time speeds in the nanoseconds.
Plug-in data acquisition boards often make good platforms for real-time control because processors, DSPs, or FPGAs can be integrated on the board. Then, data can be sampled, a control decision made, and appropriate outputs generated on the same data acquisition board—independent of what the host computer and Windows operating system are doing.
Some of these boards also offer improved reliability because control algorithms on the board will still run even if the host PC fails. Because many of these boards can be programmed using standard measurement techniques, the real-time control component of an application can easily be integrated into a complete measurement system.
Real-Time Automotive Industry Application
One example that demonstrates the need for real-time control is in the automotive industry where a dynamometer (known as a dyno for short) is used to test rotational properties, such as torque and speed. For engine test, dynos are used to determine engine efficiency and power.
The dyno is set to a desired load level, and two general engine tests typically are run. First, the engine is operated with various dyno loads. The goal is to determine how an engine will respond to various increasing and decreasing loads. The other typical test is to keep the dyno load constant, and then throttle up or down the engine to determine performance based on a particular load.
A real-time constraint for a dyno test is to maintain torque and speed consistently so accurate measurements of the engine performance can be made. This requires various parameters, such as speed, throttle, and temperature, to be measured and compared to setpoints.
If the measured values stray from the desired levels, control outputs must be generated to keep the engine running at the desired rate. Failure to maintain the desired real-time engine control loops will cause inconsistent operation, and any information collected to judge engine performance will be invalid.
Many dynos use plug-in data acquisition boards running under Windows control. For higher control loop rates, a data acquisition board with a built-in processor is better suited because it can guarantee real-time response.
For a basic dyno test fixture, five analog input channels and two analog output channels are used. A strain-gauge load cell is placed on the dyno to determine engine torque. The engine throttle, speed, oil temperature, and coolant temperature also are sampled.
The two analog outputs on the board are used to control the engine throttle and engine coolant. All inputs are sampled at 5 kHz, and the data is averaged to give accurate readings. These readings are compared to desired setpoints and a proportional integral derivative (PID) routine is executed to control the outputs. The analog outputs are updated in real time at 500 Hz.
For the dyno application, a host LabVIEW application running under Windows 95 accesses the shared memory of a National Instruments’ RT Series Intelligent Data Acquisition Board to retrieve status messages and the averaged collected data and to send to the board any new setpoints. This application also provides the user interface for the dyno test stand and logs the
data to disk.
The RT Series Data Acquisition board is programmed with a real-time version of LabVIEW called LabVIEW RT. LabVIEW RT creates embedded executables that run real-time on the processor of the intelligent RT Series data acquisition boards.
Copyright 1999 Nelson Publishing Inc.
February 1999
|
|