If you work with field systems—mining, oil and gas, industrial automation—you’ve probably heard reliability and availability tossed around like they’re the same thing. In the break room, they might sound interchangeable. But when you’re standing in front of a dead panel at 2 a.m. trying to figure out why a pump tripped, the difference hits you. Hard.
I’m Diego Almeida. I’ve spent years bouncing between engineering theory and field reality, often moving between Portuguese and English technical cultures. One thing I’ve noticed: in a lot of Brazilian engineering discussions, we gravitate toward disponibilidade (availability) as the ultimate metric. Meanwhile, in English-language reliability circles, there’s a sharper line drawn between the two. This article is my attempt to clear up that distinction in a way that’s useful for the technician tightening bolts, the engineer writing specs, and the manager signing off on capital projects.
Why the Confusion Exists
In everyday talk, if something is reliable, it’s available when you need it. If it’s available, you assume it’s reliable. But in field systems—remote telemetry units, SCADA networks, offshore platform controls—these two concepts measure different things. Mixing them up leads to bad design decisions, unrealistic maintenance budgets, and finger-pointing when production stops.
Let’s start with clear, practical definitions that work on the ground, not just in a textbook.
Reliability: The Probability of Surviving the Mission
Reliability is the probability that a system will perform its required function under stated conditions for a specified period of time. Notice the key words: probability, required function, stated conditions, and specified period. It’s not about being up right now. It’s about the likelihood of completing a mission without failure.
In field systems, reliability often gets expressed as Mean Time Between Failures (MTBF). For a remote pump controller in the Brazilian cerrado, you might calculate MTBF based on historical failure data: how often does the controller board fry due to lightning? How many hours before a vibration sensor drifts out of calibration? Reliability is a design attribute. You build it in by selecting components rated for high temperature, adding conformal coating against humidity, or derating power supplies.
Think of reliability as the system’s resistance to failure. A highly reliable system rarely breaks. But here’s the catch: when it does break, it might stay broken for a long time if you don’t have the right support structure. That’s where availability comes in.
Availability: The Readiness to Serve
Availability is the proportion of time a system is in a functioning condition. It’s not just about how often it fails, but also how quickly you can get it back online. The classic formula is:
Availability = MTBF / (MTBF + MTTR)
Where MTTR is Mean Time To Repair. This includes everything from diagnosing the fault, traveling to the site, finding the spare part, replacing it, and verifying the fix. In a remote Amazonas site, MTTR might be measured in days, not hours, because the technician needs a boat and good weather just to arrive.
So, a system can be extremely reliable (high MTBF) but have poor availability if the logistics chain is slow. Conversely, a less reliable system with lightning-fast repair processes (low MTTR) can still achieve high availability. This is the core trade-off that field engineers manage every day.
A Practical Example: Two Pump Controllers
Let’s ground this with numbers. Imagine two different pump control systems for a mining operation in Minas Gerais.
System A: The Durable PLC
- MTBF: 10,000 hours (very reliable, fails about once every 14 months)
- MTTR: 48 hours (specialized technician must fly in from São Paulo, part is not stocked locally)
- Availability = 10,000 / (10,000 + 48) = 99.52%
System B: The Simple Relay Logic
- MTBF: 2,000 hours (fails roughly every 3 months)
- MTTR: 2 hours (any local electrician can swap a relay with a part from the corner store)
- Availability = 2,000 / (2,000 + 2) = 99.90%
Surprisingly, System B has higher availability despite being four times less reliable. In a remote location where downtime directly stops production, System B might be the smarter choice—even if it feels “less engineered.” This is the kind of counterintuitive result that makes purely reliability-focused engineers uncomfortable, but it’s daily bread for maintenance managers.
Where Portuguese and English Engineering Cultures Diverge
In my experience, Brazilian technical specifications often emphasize disponibilidade as a contractual requirement: “The system must have 99.5% availability.” This is a valid, measurable target. But it sometimes overshadows the underlying reliability engineering. The thinking goes: “If the vendor guarantees 99.5% availability, they’ll figure out the reliability and maintainability.” The problem is, the vendor might achieve that 99.5% by stocking a huge local spare parts inventory and putting a technician on permanent standby—costs that eventually get passed on or that evaporate after the warranty period.
In more reliability-centered cultures, you’ll see specifications that demand a certain MTBF for critical components, independent of the overall availability number. They want the thing to be inherently durable, not just quickly fixable. Both approaches have merit, but the best field systems come from a blend: designing for high reliability and planning for fast, local repair.
The Hidden Factor: Maintainability
You can’t talk about reliability and availability without bringing in maintainability. Maintainability is the ease and speed with which a system can be restored to operational status after a failure. It directly feeds into MTTR. Good maintainability means:
- Clear fault diagnostics (a display that shows the error code, not just a blinking red LED)
- Modular components that can be swapped without special tools
- Accessible spare parts, ideally common across multiple systems
- Documentation written in the local language, with pictures
I’ve seen beautifully reliable German equipment become a nightmare in the Brazilian interior because the manual was only in German and the nearest spare PLC module was in Frankfurt. The MTBF was stellar. The MTTR was measured in weeks. Availability tanked. The lesson: reliability without maintainability is a trap.
Designing for Both: Practical Strategies
So how do you balance these factors when you’re specifying or designing a field system? Here are some strategies that have worked in projects I’ve been involved with, from telemetry for water treatment in São Paulo to wellhead controls in Espírito Santo.
1. Map the Failure Consequences, Not Just the Failure Rates
Not all failures are equal. A failure in a tank level sensor might be an annoyance; a failure in a safety shutdown valve could be catastrophic. Use a simple criticality matrix: rank each component by the consequence of its failure (safety, production loss, environmental impact) and its likelihood. For high-consequence, high-likelihood items, invest in both reliability (better components, redundancy) and maintainability (local spares, clear procedures). For low-consequence items, you might accept lower reliability if the repair is trivial.
2. Redundancy: The Double-Edged Sword
Redundancy is the classic way to boost availability without improving individual component reliability. A 1oo2 (one out of two) voting architecture means the system works if at least one of two parallel components works. This dramatically increases system availability, but it also doubles your maintenance burden—now you have two items to monitor, test, and eventually replace. In field systems, redundancy also adds complexity, which can reduce reliability if not managed well. I’ve seen redundant power supplies where the automatic transfer switch became the single point of failure because nobody tested it.
3. Design for the Real MTTR, Not the Ideal One
When calculating availability, don’t use the manufacturer’s optimistic repair time. Go to the field. Ask the technician how long it actually takes to get a replacement pressure transmitter from the warehouse. Include travel time, paperwork, and the inevitable coffee break. In many Brazilian industrial sites, the real MTTR is 2-3 times the “technical” repair time because of logistics and bureaucracy. Use the real number in your availability model, and you’ll make better decisions.
4. Standardize and Simplify
Every different model of instrument or controller adds to your spare parts inventory and your training burden. Standardizing on a few proven models across multiple sites improves both reliability (you learn which ones are durable) and maintainability (technicians become experts, spares are pooled). This is a low-tech, high-impact strategy that often gets ignored in favor of shiny new features.
Measuring What Matters: Metrics for the Field
Beyond MTBF and MTTR, there are other metrics that give a clearer picture of field system performance. Here are three I find particularly useful.
Operational Availability (Ao): Unlike inherent availability (which only counts active repair time), Ao includes all downtime—logistics delays, administrative waiting, even weather. Ao = (Total Time – Total Downtime) / Total Time. This is the number your production manager actually cares about.
Failure Rate (λ): The inverse of MTBF, often expressed in failures per million hours. Useful for comparing components. A pressure transmitter with λ = 100 failures per million hours is ten times more reliable than one with λ = 1000.
Probability of Failure on Demand (PFD): Critical for safety systems. This is the probability that a safety function will fail when called upon (e.g., an emergency shutdown valve that doesn’t close during a gas leak). PFD is the unreliability for on-demand systems, and it’s what SIL (Safety Integrity Level) ratings are built on.
When High Availability Masks Poor Reliability
There’s a dangerous pattern I’ve observed: a system achieves its contractual availability target because the maintenance team is heroic. They’re constantly firefighting, swapping parts, resetting controllers. The availability dashboard looks green, but the underlying reliability is terrible. This is unsustainable. It burns out technicians, inflates maintenance costs, and eventually leads to a catastrophic failure when the right spare isn’t on hand.
In one natural gas compression station, the availability KPI was 99.7%—world-class on paper. But digging into the data revealed that the MTBF of the control system was only 500 hours. The high availability was entirely due to a dedicated technician living on-site and a well-stocked warehouse. When that technician retired, availability crashed to 95% within three months because the knowledge and motivation left with him. The system wasn’t reliable; it was just well-nursed.
This is why I advocate for tracking both metrics independently. Availability tells you if you’re meeting production targets today. Reliability tells you if your design is sustainable for the next 10 years.
Cultural and Regional Considerations
Working across Portuguese and English engineering environments has taught me that context shapes how we prioritize these concepts. In Brazil, the high cost of imported equipment and the logistical challenges of remote sites often push teams toward maximizing availability through local ingenuity—the famous jeitinho. This can be a strength: Brazilian technicians are incredibly resourceful at keeping old equipment running. But it can also mask the need for fundamental reliability improvements.
In more industrialized, supply-chain-rich environments, the bias is often toward replacing unreliable equipment with more reliable (and expensive) alternatives, because the logistics for repair are so efficient that MTTR is naturally low. Neither approach is universally correct. The best field engineers I’ve worked with adapt their thinking to the local reality: they design for reliability where the supply chain is weak, and they optimize for maintainability where skilled technicians are abundant.
Practical Steps to Improve Both Reliability and Availability
Here’s a checklist I use when auditing or designing field systems. It’s not theoretical—it’s based on failures I’ve seen and fixes that worked.
- Environmental hardening first. Heat, humidity, dust, and voltage spikes kill field electronics faster than any other factor. Specify IP65 or better enclosures, use surge protection on all signal and power lines, and consider active cooling only if passive methods are insufficient. A sealed, passively cooled cabinet in the shade is more reliable than one with a fan that will eventually clog and fail.
- Simplify the architecture. Every additional component is a potential failure point. Do you really need that intermediate junction box, or can you run the cable directly? Can a single multi-function device replace three separate ones? Fewer parts = fewer failures.
- Build in diagnostics. A system that can tell you why it failed saves hours of troubleshooting. At minimum, every field device should report its own health status (e.g., via HART or Modbus diagnostics). Better yet, use a central SCADA or IoT platform that aggregates diagnostic data and alerts you to degrading conditions before they become failures.
- Stock spares strategically. Use a criticality analysis to decide what to stock where. High-criticality, long-lead-time items should be on-site. Low-criticality, short-lead-time items can be at a regional warehouse. And don’t forget consumables: gaskets, fuses, batteries. A $2 fuse can take down a $200,000 system if you don’t have one.
- Train for diagnosis, not just repair. Many training programs teach technicians how to replace a part, but not how to figure out which part to replace. Invest in troubleshooting skills. A technician who can accurately diagnose a fault in 30 minutes instead of swapping parts for 4 hours dramatically reduces MTTR.
- Review failures systematically. Every failure is a free lesson. Hold a brief, blameless post-mortem: What happened? Why? What can we change to prevent it or reduce the repair time next time? Document and share the findings across sites. This turns individual failures into organizational reliability improvements.
FAQ: Reliability vs. Availability in Field Systems
What is the main difference between reliability and availability?
Reliability is the probability that a system will work without failure for a defined period under specified conditions. Availability is the percentage of time the system is actually operational. A system can be highly reliable but have low availability if repairs are slow, or it can be less reliable but highly available if repairs are very fast.
Why does MTTR matter more than MTBF in some remote sites?
In remote locations, the time to diagnose, travel, and repair can be days or weeks. Even if the equipment rarely fails (high MTBF), the long repair time (high MTTR) drastically reduces availability. In these cases, investing in local spares, remote diagnostics, and simplified repair procedures often yields better availability than buying more reliable equipment.
How can I calculate the real availability of my field system?
Use operational availability (Ao) rather than inherent availability. Track total downtime including logistics, administrative delays, and weather. Ao = (Total Time – Total Downtime) / Total Time. This gives a realistic number that reflects what your operation actually experiences, not just the theoretical repair time.
Is redundancy always the best way to improve availability?
Not always. Redundancy increases availability on paper, but it adds complexity, cost, and maintenance burden. If the redundant components share a common failure mode (like a power supply or a software bug), the redundancy may be ineffective. Redundancy works best when combined with diversity—using different technologies or suppliers for the redundant paths.
Closing Thoughts
Reliability and availability are not competing goals; they’re two lenses on the same problem: keeping field systems running in harsh, remote, and unforgiving environments. The engineer who understands both—and who can adapt the balance to the local reality of supply chains, technician skills, and environmental conditions—is the one whose systems actually work, year after year.
Next time you’re writing a specification or reviewing a design, ask two questions: “How often will this fail?” and “When it fails, how quickly can we fix it with the resources we actually have?” The answers will guide you to better decisions than any single metric ever could.