Defining Real-Time Control |
||||||||||||||||||||||||||||||||||||||||
What is real time? Many vendors claim to have real-time systems, but without defining what they mean by real-time and what time frame they have in mind, it’s impossible to compare real-time systems. You may have even seen automobiles that claim to have “real-time 4-wheel drive.” Does this mean that other vehicles have non-real-time operation? In this paper we hope to clarify the situation. We will begin by defining what real-time means and describe what time scales are appropriate for different activities. Then we will provide some examples of system operation based on different response times. What factors define real-time operation? In general, there are three factors that define what real-time operation encompasses. In addition, it’s essential to identify a time frame for real-time operation.
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. This must be specified for comparison of different systems. What are Typical Time Scales for Real-Time System? Every process or application has its own real-time context; the time needed for the system to respond to a change or request. Depending on the process, this time frame can vary dramatically. Minutes – Service in a restaurant At the low end of the scale, there are systems where a response time measured in minutes is
acceptable. You might consider a restaurant as a real-time operation. They take your order, cook
the food and deliver it to you in a guaranteed, predictable manner, hopefully! If you visit a nice sit
down restaurant it might take 15 minutes to a half hour. On the other hand if you go to
McDonald’s 3 minutes might be at the high end of your expectations. Seconds – NASCAR pit stop, temperature control Moving to faster systems, there are examples where a response within seconds is necessary. NASCAR race fans can appreciate the real-time response of pit crews when a car comes in for fuel or a tire change. Here getting in and out in a few seconds or tens of seconds may be adequate. Many processes where temperature control is needed exhibit response times measured in seconds. If you have a large thermal mass, changes occur very slowly and a controller needs only to respond to changes within a few seconds to keep the temperature at a desired set point. Milliseconds – PLC, production lines, test stands, control with <1 kHz bandwidth Even faster systems require response times that are measured in milliseconds. These include things like PLC’s that are controlling production lines, test stands that apply a stimulus and measure the response of a system or device under test 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. Microseconds – High-speed test stands, fast digital controllers (5 kHz to 500 kHz) Some of the fastest systems require response times measured in microseconds. For example 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. Windows and Real-time If you consider the preceding requirements for real-time systems and the response time requirements it should be obvious that, for many applications, Windows is not a suitable environment. First, Windows is not 100% stable. 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, you may simply see delays in the execution of one process under Windows due to another process executing at a higher priority. In a worst case scenario, a badly behaving process can “crash” the computer causing all other processes to stop. This situation is not tolerable if these processes are in charge of critical control or positioning functions. Windows is not inherently designed to be real-time. It uses a priority-based time-slicing approach to allocate the resources of the CPU amount the multiple processes running at any one time. Typically, kernel processes that interface directly with hardware (including as disk drives, the keyboard or mouse or video display) run with the highest priority. And, because of the time slicing approach, you can not be precisely guaranteed when a process will be serviced. So, if you have a control application that is running at a lower priority and somebody moves the mouse around, the real-time application will be delayed. Any device that operates under Windows and needs real-time has its own local intelligence If this is the case, you may be asking yourself "how do devices that do need real-time such as sound cards or writing to a disk operate properly?" The answer is that these devices typically have local processors that buffer and manage data to enable real-time operation. In the case of modern Windows-based systems, the following devices all have a local processor to achieve the tight timing required for normal operation:
Real-Time Windows Extensions You may be asking yourself what about the real-time extensions to Windows? While it’s possible to use Windows with a real-time kernel, it’s much better to use a device with local intelligence for real-time that communicates with Windows for display and data storage. Examples of system response on real-time Example 1 – A system with a 25 μs response time
In this case, processes C and D can not run since they consume 100% or more of the CPU resources. Now, compare the system performance if the response time is 1 μs.
Response times of typical systems For older 486 DOS-based systems typical response times are 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. National Instruments markets several different real-time products. In a recent 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. 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. Still faster are the ADwin DSP-based systems which have demonstrated response times as fast as 300 ns (see figure 1).
Figure 1 – ADwin Response time is less than 1 μs: typically 0.3 μs to timer or trigger signal
Advantages of the ADwin Architecture The architecture, both hardware and software, of the ADwin system has been optimized for realtime operation. For example, online calculation for each measured value for applications like PID loops or digital filters are processed immediately after measurements are made for 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. Summary Real-time control means different things to different people. Without having a defined time frame it’s impossible to compare different systems that claim to have real-time response. For the best performance in a Windows environment, it’s essential to have a local processor dedicated to maintaining the real-time control functions. The ADwin system has one of the fastest response times available for applications that demand precise and repeatable control. |
