Rugged computers share several attributes that help them operate in harsh environments. They must be designed and built to very tight specifications with reliable, quality components, and tested thoroughly under worst-case conditions of their intended use. But “rugged” doesn’t mean the same thing for different users and applications. A computer destined for an Arctic Sea icebreaker contains a different mix of subsystems and components from one carried by soldiers in the Afghanistan desert. Engineers designing testing procedures must also consider these different environments, by closely simulating the specific conditions the unit will be exposed to.
Defining Operational Parameters is Crucial
Understanding exactly where and how the rugged computer will operate helps Chassis Plans’ engineers configure it correctly for users’ needs. The computer traveling in the Arctic Sea must withstand cold temperatures, salt fog, humidity, and operational shock. The computer carried through the desert has to survive and thrive in heat, blowing sand and dust, plus vehicle vibration over many miles of rough terrain.
Testing specifications like MIL-STD-810 define procedures for simulating the rugged computer’s environment, but test parameters must be specified by the particular operating conditions. For example, MIL-STD-810 has 28 different procedures, from temperature, shock and vibration to acidic atmosphere, ballistic shock, and rail impact. After selecting the right procedures, limits must be applied for simulating the worst-case condition the unit is likely to experience.
C4ISR Application in the Middle Eastern Desert
One computer Chassis Plans’ engineers developed for soldiers in the Middle Eastern desert was a mobile rugged workstation housed in a shock-isolating transit case. The C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) unit consisted of a high-end dual Xeon® server, plus a keyboard and rugged video monitor. Ruggedization strategies differed for each of these sub-units.
Above all, the computer had to operate in high temperatures, which led Chassis Plans’ engineers to design a high-flow cooling system. To optimize cooling, they constructed the frame from aircraft-quality aluminum, and used aluminum-framed fans with an MTBF of over 100,000 hours. The engineers included the company’s proprietary SysCoolTM thermal management subsystem, which monitors temperature and fan operation and has an adjustable alarm setpoint.
The second major design consideration for the box was shock and vibration. The aluminum frame provided strength and rigidity, and shock-isolated drive bays isolated sensitive disk drives from the chassis. A large cross-section hold-down bar kept I/O add-on cards securely in their slots.
For the keyboard and rugged monitor, Chassis Plans’ engineers also used aircraft-quality aluminum construction. Components from the power supply to the controller board to the LCD display operated in extended temperature ranges. The display was optically bonded to an anti-reflective coated cover glass, which included an IR shield to prevent solar loading. A high-intensity LED backlight made the display readable in bright sunlight. The keyboard and pointing device were sealed against water and windblown dust, and friction slides prevented the entrance of foreign substances.
Testing Defined by Operational Parameters
Several different tests were used for the C4ISR unit, such as subjecting it to 50Gs and 40 mph winds blowing sand at it for 6 hours at a time. The full suite of tests included high and low storage and operational temperatures, hot and cold humidity, altitude pressure changes, shock drop tests, operational and non-operational vibration, and blowing sand and dust.
In conclusion, since the process of ruggedization is unique for most applications, it’s important to understand the outside limits of the equipment’s operating conditions at the beginning of the design and configuration process. Specifications such as MIL-STD-810 and MIL-S-901 help characterize these environments and define what the tests should be, but they don’t, and can’t, specify the extreme operational parameters of those tests.