Data Acquisition Devices Operating in Real-Time
CHESTERLAND OH—August 10, 2011
Many vendors claim to have “real-time” systems, but without defining what they mean by the phrase and what time frame they have in mind, it’s impossible to compare and contrast real-time systems. For example, many people have seen automobiles that claim to have “real-time four-wheel drive.” Does this mean that other vehicles have non-real-time operation? What exactly does “real-time” mean? This confusion can be clarified by defining the phrase and describing what time scales are appropriate for different applications. Specific examples of system operation based on different response times further help users understand what is possible and impossible for their real-time applications.
In general, there are three factors that define exactly what real-time operation encompasses. In addition, it’s essential to identify a time frame for real-time operation. Any real-time system must have stable and repeatable program execution–the program must produce the same result for any given set of inputs and it must do so within the same time frame. Therefore a system that produces the same output, but exhibits variability in the time it takes from input to output, cannot be considered real-time. Another key to any real-time system is the time it takes from an event or change of an input occurring to the instant the output updates. It’s critical that a real-time system provides a guaranteed time for which the output will respond to a change in the input. Finally, the execution of the program must be predictable. It’s not acceptable for the output of the program to be dependent on factors that are unknown, or at minimum, uncontrollable. Any factors that determine the output state for a given input state must be known and controllable. However, these three factors alone are not adequate to describe or compare real-time systems since they do not establish a time frame for operation.
Every process or application has its own real-time context–the time needed for the system to respond to a change or request. This time frame can vary dramatically, depending on the process. However, there are a few categories of typical time scales for real-time systems. At the low end of the scale, there are systems where a response time measured in minutes is acceptable. A restaurant could easily be considered a real-time operation – they take orders, cook the food and (hopefully!) deliver it in a guaranteed and predictable manner. In an average sit-down restaurant, the food might take 15 minutes to a half-hour. On the other hand, at McDonald’s, a wait of three minutes might be at the high end of customer expectations.
Moving on to faster systems, there are many examples where a response within seconds is necessary. NASCAR race fans marvel at the real-time response of pit crews when a car comes in for fuel or a tire change. In this case, getting in and out in tens of seconds is often expected. Additionally, any processes where temperature control is needed can manage response times measured in seconds. In conditions with a large thermal mass, temperature changes occur very slowly and a controller needs to respond to changes within a few seconds to keep the temperature at a desired set point.
Even faster systems require response times that are measured in milliseconds. These include devices like PLCs that are controlling production lines, test stands that apply a stimulus and measure the response of a system or device being tested, or systems that require feedback control loops with less than 1 kHz of bandwidth. The latter could be a simple PI or PID control loop for temperature, pressure, flow, voltage, current or position.
On the farthest end of the real-time spectrum, some of the fastest systems demand response times measured in microseconds. Examples include high-speed test stands, fast digital controllers with bandwidths up to 500 kHz, and positioning systems that employ electron beams or lasers–each need extremely fast controllers. These capabilities are often beyond that of a general purpose system and require dedicated hardware designed expressly for the target application.
Considering the preceding requirements for real-time systems and the response time requirements, it is apparent that, for many applications, Windows is not a suitable environment. Essentially, Windows is not 100% stable, as the performance of any application running under Windows is highly dependent on any other activities running on the same CPU. In a best-case scenario, users may simply see delays in the execution of one process under Windows due to another process executing at a higher priority. In the worst case, a badly-behaving process can crash the computer, causing all other processes to stop. This outcome is not acceptable if these processes are in charge of critical control or positioning functions.
Windows is not inherently designed to be a real-time platform. It uses a priority-based time-slicing approach to allocate the resources of the CPU among the multiple processes running at any one time. Typically, kernel processes that interface directly with hardware (including disk drives, the keyboard, mouse or video display) run at the highest priority. And, because of the time slicing approach, users aren’t guaranteed of when a process will be serviced. Therefore, whenever users have a control application running at a lower priority and somebody moves the mouse around, the real-time application will be delayed.
Computer devices that rely on real-time, such as sound cards and disk writers, are able to operate using local processors that buffer and manage data to enable real-time operation. Any device that operates under Windows and needs real-time has its own local intelligence. Modern Windows-based systems such as disk drive controllers, sound cards, and fieldbus cards all have a local processor to achieve the tight timing required for normal operation. While it’s possible to use Windows with a real-time kernel, such as the real-time extensions to Windows, it’s much better to use a device with local intelligence for real-time that communicates with Windows for display and data storage. See Table 1 for an example of system response on real-time.
Table 1 – A system with a 25 µs response time
Control Frequency Process Cycle Time Response Time
(% of cycle time)
Process A 1 kHz 1000 µs 2.5%
Process B 10 kHz 100 µs 25%
Process C 40 kHz 25 µs 100%
Process D 100 kHz 10 µs 250%
In this case, processes C and D cannot run since they consume 100% or more of the CPU resources.
Table 2 compares the system performance when the response time is even faster at 1 µs.
Table 2—A system with a 1 µs response time
Control Frequency Process Cycle Time Response Time
(% of cycle time)
Process A 1 kHz 1000 µs 0.03%
Process B 10 kHz 100 µs 0.3%
Process C 40 kHz 25 µs 1.2%
Process D 100 kHz 10 µs 3%
For older 486 DOS-based systems, average response times range from 10 to 40 µs. These systems typically have much lower overhead than newer Windows-based systems. Windows systems with real-time kernel extensions are somewhat slower, with response times of 25 to 200 µs. In addition to these, National Instruments markets several different real-time products. In a detailed publication, Benchmarking LabVIEW Real-Time FieldPoint Systems, they indicate that the typical input to output time is 5 to 50 ms, depending on the number of channels and system configuration. Meanwhile, Linux-based real-time systems can achieve response times on the order of 5 to 20 µs; even faster are RISC/DSP systems which can process requests in 1 to 10 µs; and still faster are the ADwin-Pro DSP-based systems which have demonstrated response times as fast as 300 ns.
The hardware and software architecture of the ADwin-Pro system has been optimized for real-time operation. For example, online calculation for each measured value for applications like PID loops or digital filters are processed immediately after measurements are made, resulting in very fast updating of output values. The architecture allows overlapping A/D or D/A conversions in parallel with calculations for the highest throughput. For calculations, maximum CPU performance is achieved through the use of a 32-bit floating-point DSP.
In summary, ‘real-time’ control means different things to different people and companies. Without having a defined time frame, it’s impossible to contrast different systems that claim to have real-time response. For the best performance in a Windows environment, however, it’s essential to have a local processor dedicated to maintaining the real-time control functions. At the high end of the real-time spectrum, the ADwin-Pro system has one of the fastest response times available for applications that demand precise and repeatable control. Check out the Adwin-Pro’s product page here.
For further information on the Delphin ADwin-Pro DSP system, other data acquisition and control solutions, and data logging and remote monitoring applications, or to find the ideal solution for your application-specific needs, contact a CAS Data Logger Applications Analyst at (800) 956-4437 or visit the website at www.DataLoggerInc.com.
CAS DataLoggers, Inc.
12628 Chillicothe Road
Chesterland, Ohio 44026