RSS Feeds
Real-Time Software Reduces Test Aggravation
Increases data reliability and accuracy
By Jon Titus -- Design News, April 4, 2004
|
|
Get in Line: A premptive RTOS (a) takes a known time to respond to and execute a high-priority task. A non-preembtive OS (b) allows a low-priority task to finish before it passes control to a higher priority task. This lag in providing service can introduce timing erros in tasks that demand immediate execution. |
When people demand high reliability and accurate timing from a test system, they may have to move away from the venerable desktop PC. Engineers who run lengthy test sequences cannot tolerate a PC's operating-system crashes or other software problems. Likewise, engineers who need accurately timed measurements cannot risk having their data-acquisition tasks disrupted by an unexpected event. Several examples highlight the importance of reliability and accuracy in specialized test systems.
Highly accelerated life testing (HALT) and highly advanced stress screening (HASS) involve acquiring data over long periods. During testing, devices get subjected to extreme conditions. Because tests can run for days, a glitch caused by a desktop operating system could corrupt test data or cause timing errors during measurements. Aborting a HALT or HASS test due to computer problems may mean starting over.
At times, engineers may need to rent an expensive test apparatus, such as a wind tunnel or an environmental chamber. The cost of these rentals makes rerunning any disrupted tests a financial burden. So, software that acquires test data and controls test equipment must run reliably without encountering any problems. Likewise, engineers who "shake and bake" an expensive prototype to the point of destroying it (on purpose) cannot ask for a "do-over" if PC-based test routines go awry.
In addition to reliable operation over long periods, engineers also may require accurate timing of events, which falls under the heading "deterministic performance." That means strict timing governs computer operations so that programmers know how long it will take a computer to run control loops, data-acquisition tasks, algorithms, and other operations. An underlying real-time operating system (RTOS) prevents low-priority events and tasks from disrupting high-priority operations.
Systems used at Parker Hannifin (Cleveland, OH), for example, require real-time response from software control loops included in systems that test the company's hydraulic actuators. These actuators go into aircraft control systems. During testing, hydraulic pressure (3,000-5,000 psi) moves an actuator. A sensor attached to the actuator reports position data to a computer so software can adjust pressure to position an actuator for testing.
The control-loop software cannot wait while other tasks allocate memory buffers, transfer data to disk, and so on. The control loop requires priority over these types of non-real-time tasks. In addition, data acquisition must occur at the proper intervals to ensure engineers can correlate test results and control-loop operations. This type of application requires real-time software that provides deterministic performance.
An RTOS uses an established priority to schedule tasks, allocate system resources, and perform housekeeping jobs, all within specific time limits. Thus, programmers know what tasks happen when, and how much of a CPU's time each task will take. An RTOS vendor will specify, for example, "When task b occurs, it always take x µsec to execute." Developers can write code that takes advantage of the deterministic nature of an RTOS so that application software provides careful timing and reliable performance. Well-written real-time code will not let housekeeping tasks interrupt higher-priority measurement tasks. Unfortunately, developers lack that type of control in desktop PCs that run Windows, Mac OS, or Linux.
Programmers write application code for an RTOS using a higher-level language such as C or C++. A compiler that runs on a "host" computer, often a PC, produces code that runs with the RTOS on the "target" computer in a test system. This process works well as long as engineers have chosen a standard target computer system, have defined all needed I/O operations, and have time to write, test, and debug code. In addition, the programmers must have partitioned code into real-time and non-real-time tasks.
Moving application code from a host to a target computer can require considerable effort, particularly for people new to working with an RTOS. Don't expect to push a button and drop real-time C or C++ code into a test system. And although an RTOS may come with fundamental I/O libraries for serial, USB, and Ethernet ports, don't plan to receive plug-and-play drivers for specific test instruments. For this reason alone, you may find it wiser to:
-
Find software that offers real-time performance and integrates measurement tasks, drivers, instrumentation, and communications.
-
Use a target CPU that operates on a bus (cPCI, PXI, or VXI) favored by test-systems developers.
Those standard buses furnish special clock, time, and trigger signals that enhance reliability and real-time performance of test systems while simplifying program development. If need be, add-in modules can lock onto GPS time signals to provide resolution in the range of a few nanoseconds. You can't get more "real time" than that at reasonable cost.
