Improving System Availability
Print
The availability of your system is dependent on product reliability and system architecture.
Quantifying system reliability is critical to the success of your applications, and, in doing so, you can take measures to improve your system availability to satisfy your needs. Reliability is the conditional probability, at a given confidence level, that equipment will perform its intended functions without failure when used in the manner and for the purpose intended while operating under the specified environments. The availability of a system is defined as the amount of time the system can operate reliably within a given period of time. For example, a system that is designed to be available for 23 hours out of every 24 hours is said to be 95.8 percent available. To improve system availability, it is important to understand mean time between failures (MTBF), build flexibility into your system architecture, and plan for expected and unexpected downtime.
Figure 1. PXI is an ideal platform for applications requiring a high degree of availability.
Understanding MTBF Data
MTBF is a numerical value often used to describe the useful life of a system. To use MTBF data, you must first understand how the number is generated. MTBFs are generally calculated using mathematical models created for electronic components. These formulas are controversial because older models are dated and arguably do not correlate with today’s components, and newer models do not have enough field data to support their accuracy. Because their accuracy is debatable, these models are intended to help quickly calculate the MTBF. Depending on the model and how the system components are represented, you can calculate significant differences for MTBF. It is also critical to use models that take environmental conditions into account. If the quoted MTBF of a system varies from environmental calculations, you could be comparing apples to oranges.
Generally, MTBF is not the best measure of a product or device’s reliability. Consider whether the vendor actively manages quality with a quality management system, what type of continuous improvement processes are followed, and if any rigorous validation testing – such as highly accelerated life test (HALT) o r highly accelerated stress screening (HASS) – is performed. These practices are more appropriate indicators of a product’s reliability.
Figure 2. Minimize changes to your software by using a layered architecture.
Designing a Flexible System Architecture
The availability of your test system greatly depends on its architecture and flexibility. NI provides hardware and software products so you can efficiently build flexible test systems. Giving careful thought to the architecture of these products therefore enhances your system’s availability.
Architecting your software for extended use and long life cycles is crucial to lowering the cost of test and increasing system availability. NI recommends using a layered approach to software architecture. The benefit of a layered approach is that you can change components while minimizing the impact on other portions of code.
For instance, by designing code modules for individual tests and calling these modules from a test executive such as NI TestStand, you can minimize future impact to the code on all layers and reuse the code module in other test systems, thus optimizing your current and past software development. The key is identifying which parts of the test system can be modularized in this fashion.
Figure 3. Without routine calibration, measurement error becomes unpredictable after one year for most instruments due to error from component drift.
Creating a Plan for the Expected and Unexpected
Even the most reliable products are designed to have some expected downtime. This downtime is usually for routine maintenance such as cleaning, replacing parts, and calibrating when appropriate.
As with all test systems, there are a few things you should plan for with PXI systems from National Instruments. You should clean or replace the chassis fan filter at least every six months to ensure proper airflow. Also, most PXI modular instruments require calibration every year. NI or a third-party certified calibration laboratory can perform the calibration for you. And, you should always self-calibrate your test application after the system has been running for at least 15 minutes to account for inaccuracies due to temperature drift.
To protect your software development and minimize downtime from unexpected software issues, consider routinely storing a backup image of your PXI controller. You should do this during the development and deployment of your test system. Every PXI controller from NI comes with the easy-to-use Acronis True Image backup and restore utility.
If you depend on your test system to operate continuously and you can afford very little unexpected downtime, consider having spare components on hand in the event of a component failure. PXI modules and system components, such as the chassis power supply and controller hard drive, can be replaced within minutes, and you can purchase these spare components directly from NI. Replacing these components is easy and does not void the warranty from NI.
Ensuring Your System Success
NI is dedicated to ensuring your system success by improving product quality, assisting you with training and documentation for excellent system architecture, and providing world-class support and services.
– Patrick Webb
Patrick Webb is the PXI systems product manager for National Instruments. He holds a bachelor’s degree in electrical engineering from St. Mary’s University and a master’s degree in business administration from The University of Texas at Austin.
View additional resources on improving long-term system availability.
NI TestStand Advanced Architecture Series
Thousands of developers worldwide create powerful automated test systems using NI TestStand test management software. The NI TestStand Advanced Architecture Series, updated quarterly, offers the latest documents on best practices and development advice from NI TestStand architects and experts.
Read two new white papers from the NI TestStand Advanced Architecture Series.
The mark LabWindows is used under a license from Microsoft Corporation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries.
This article first appeared in the Q2 2008 issue of Instrumentation Newsletter.
Print
Reader Comments | Submit a comment »
Legal
This material is protected under the copyright laws of the U.S. and other countries and any uses not in conformity with the copyright laws are prohibited, including but not limited to reproduction, DOWNLOADING, duplication, adaptation and transmission or broadcast by any media, devices or processes.