When Do I Need a Real-Time System?

A real-time solution is required for applications that must deterministically perform a critical task in software without interruption or interference from other noncritical tasks. Deterministic applications often perform a critical task iteratively, so that all iterations consume a measurably precise amount of processor time. Thus, deterministic applications are valuable not so much for their speed, but rather for their reliability in consistently responding to inputs and supplying outputs with very little jitter. (Jitter is the average difference in time that a given loop takes to execute.)

A common example of a deterministic application is a time-critical control loop, which gathers information about a physical system and responds to that information with precisely timed output. Consider the oil industry, for instance, where thousands of feet of pipes are assembled daily. As two pipes are mechanically joined end-to-end at their threads, the torque required to twist the pipes together ramps up until the pipes are fully interconnected. Suppose the machine connecting the pipes uses a control loop to respond to an increase in resistance between the pipes by applying more torque. Furthermore, suppose that once a critical level of torque is attained, the control loop is triggered to terminate. Under these conditions, the loop must execute deterministically because lag in the software could result in severe damage to the pipes and other equipment. The graph below illustrates torque versus time in LabVIEW, revealing a sharp rise in torque, which corresponds to a completed connection between two pipes:
You should use a real-time operating system to guarantee that the time-critical task precisely executes on a specified time schedule. The Windows operating system, on the other hand, is designed to offer time-slices or processor time to background tasks as it sees fit. Because the user often has very little control over how processor time is shared, Windows is not considered a real-time operating system. Consequently, noncritical tasks (such as screen savers and virus protection software) may interfere with a time-critical process in LabVIEW, such as a data acquisition application or a control loop, starving it of valuable processor time.

Consider the following example. If Windows is commanded to open a Web browser, the processor temporarily suspends execution of LabVIEW instructions to begin executing instructions required to launch Internet Explorer. From the user’s perspective, this might not make a visible change on the LabVIEW front panel, but if several instances of Internet Explorer were launched, the user would eventually detect a noticeable amount of lag on LabVIEW’s user interface and in the time it takes to launch additional Web browsers. More importantly, however, a time-critical application, such as the pipe assembly example mentioned above, would greatly suffer because LabVIEW would not be capable of immediately responding to a critical condition, such as when the pipes have been fully connected and the torque quickly ramps up.

When considering test and measurement solutions for an application, you must know how to distinguish between applications that require real-time processing performance and those that do not. Some data acquisition systems do not require real-time processing performance because they do not involve a time-critical software process. Consider an application where data must be continuously acquired at a rate of 1 MSample/s, processed, and logged to disk. The application does not respond with output, it simply gathers data very quickly with precise timing. National Instruments manufactures E-series Multifunction I/O (MIO) boards that can perform this task without real-time technology. Such an application only needs precise hardware timers to ensure that samples are digitized at the specified interval.

Once digitized, the MIO board stores values in a FIFO hardware buffer, which begins to fill. Once the FIFO buffer reaches a critical level, data is transferred in blocks to a RAM buffer, where it resides until LabVIEW is told to read the data from the RAM buffer. The rate at which this data is read from the RAM buffer depends on how quickly LabVIEW can "read" the data in a loop, which in turn is governed by processor speed and other factors including, but not limited to the following:

• File I/O
• Signal Processing
• Background tasks (such as a screen saver, Web browser, anti-virus software, and so on)
• User interface activity
• Other hardware communication (such as GPIB, RS-232, and so on)

As the programmer assigns more tasks to the loop, loop iterations will require more time to complete. Likewise, as the user interacts with other programs, generates user interface events, and performs other hardware I/O, the loop execution speed will slow, because the operating system must appropriate and share processor time between more instructions.

Now, assume that there is a minimal amount of activity on the data bus and that there are only a few other applications running besides LabVIEW. Under these conditions, most modern computers can easily read from the RAM buffer at a sufficient rate such that no data is overwritten or lost as an E-series board acquires data at its maximum (hardware-limited) rate. Moreover, each time data is read from RAM, the processor will typically have extra time to perform other tasks like streaming data to disk and signal processing.

As conditions vary, the user will empirically determine their computer’s limitations and adjust parameters accordingly, but the main point is that despite software interruption from other processes, the data acquisition, or hardware process, will consistently acquire at a rate of 1 MSample/s. The reason for this is that the MIO board has dedicated onboard counter/timers that regulate analog-to-digital (A/D) conversions, so there is no way another software process can affect this rate. However, the loop in LabVIEW that reads data from the RAM buffer is very susceptible to such interruptions, so it is up to the user to ensure that other applications do not starve LabVIEW of valuable processor time required to gather data sitting in RAM.

The lesson learned here is that the reading loop in LabVIEW may not execute deterministically, but the data is still acquired deterministically by the hardware! In fact it is very improbable that any two read operations will take exactly the same number of clock cycles as the operating system allocates time-slices to other on-going processes. However, as long as the processor can come back to the reading loop frequently enough to gather data from RAM, the hardware rate of acquisition will not exceed the average software reading rate. Thus, the presence of a RAM buffer eliminates the risk of lost data when other applications are sharing processor time. This is known as a buffered acquisition and is very common in data acquisition.

The discussion above illustrates when a system might not need to incorporate real-time technology. Many data acquisition systems today currently operate similarly to the above example because a hardware-timed acquisition will yield data that is precisely spaced in time and can be processed later. However, when applications -- such as the pipe torque example mentioned above -- acquire signals that must be processed immediately and must incorporate a response signal, the application is considered real-time and will typically require special real-time hardware and software.

Reader Comments | Submit a comment »