Reliability and availability are not the same thing. In Brazilian field deployments—where 127V/220V split-phase mains sag under air-conditioner load, where 2G/3G/LoRa connectivity comes and goes like a bus in the interior, and where tropical humidity and ants treat your enclosure as an invitation—the distinction is not academic. It is the difference between a system that works for years and a system that works only when you are standing next to it with a multimeter.
Reliability is the probability that a system will perform its required function without failure for a stated period under stated conditions. Availability is the fraction of time the system is actually able to perform that function. A device can be extremely reliable and still be unavailable. A device can be available most of the time and still be unreliable. If you design embedded systems for field deployment in Brazil, you need to understand both, measure both, and stop pretending that a high MTBF number on a datasheet means anything once the ants find your power supply.
This article is for the engineer who has already learned that the lab bench is not the field. It covers the definitions, the math that matters, the failure modes that Brazilian conditions create, and the design choices that actually move the needle. No theory for theory’s sake. No over-engineered solutions that cost more than the problem they solve.
Defining the Terms Without the Marketing Fluff
Reliability is usually expressed as MTBF—mean time between failures—or as a failure rate in FITs (failures in time, failures per billion hours). Availability is usually expressed as a percentage: 99.9%, 99.99%, and so on. The relationship between them is simple in theory and brutal in practice:
Availability = MTBF / (MTBF + MTTR)
MTTR is mean time to repair. In a data center, MTTR might be minutes because a technician is on site with spare parts. In a field deployment in Mato Grosso, MTTR might be three weeks because the site is a six-hour drive from the nearest city, the road is washed out, and the replacement board is stuck in customs. That is why availability in field systems is often dominated by repair time, not by failure rate. You can double the MTBF and barely move availability if the MTTR is measured in weeks. Or you can design for fast replacement and improve availability dramatically without touching the failure rate at all.
Adjacent concepts you will hear: uptime (the actual time the system is up), downtime (the complement), service level agreements (contractual availability targets), fault tolerance (the ability to continue operating after a fault), and graceful degradation (the ability to lose a function without losing the whole system). In embedded field systems, graceful degradation is often more valuable than fault tolerance because full redundancy is expensive and power-hungry.
Why Brazilian Field Conditions Punish Both
Brazilian field deployments are not a mild environment. The grid is split-phase 127V/220V, which means neutral currents, phase imbalance, and the occasional 220V surge on a 127V line when a neutral connection fails. Sags and spikes are frequent. Micro-outages—a few cycles to a few seconds—are common during storms and switching operations. In rural areas, the grid may be off for hours at a time. If your system does not have a well-designed power supply with hold-up capacitance, brownout detection, and a clean reset circuit, it will not be reliable. If it does not recover automatically after a power event, it will not be available.
Connectivity is the second problem. 2G and 3G networks are being sunset in many regions, but in Brazil they are still the only option in much of the interior. LoRa works well for low-bandwidth telemetry, but it requires line-of-sight or near-line-of-sight and careful antenna placement. Intermittent connectivity means your system must buffer data, retry transmissions, and never assume that a message was received just because it was sent. A system that loses data during a connectivity gap is unreliable. A system that stops logging because the modem is unresponsive is unavailable.
Then there is the environment. Tropical humidity causes condensation inside enclosures, corrosion on connectors, and leakage currents on PCBs. Insects—ants, termites, wasps—find their way into enclosures and short out power supplies or block airflow. UV degrades plastic enclosures and cable ties. Lightning induces transients on long cable runs. All of these are failure mechanisms that reduce reliability. But they also increase MTTR because the failure is often intermittent, hard to diagnose, and requires a site visit.
Reliability: Designing for the Failure You Know Will Happen
Reliability engineering for field systems starts with the power supply. In Brazilian conditions, the power supply is the component most likely to fail, and it is also the component that causes the most confusing downstream failures. A cheap AC-DC converter will die after a few hundred surge events. A good one will survive thousands. The difference is not just the components; it is the design margin. Use a power supply rated for at least twice the expected input voltage range, with transient protection on the input, and with enough hold-up capacitance to ride through a 100ms micro-outage. If the system runs on 127V, design for 90V to 300V input. If it runs on 220V, design for 180V to 400V. The grid in Brazil will test those limits.
Brownout detection is not optional. A microcontroller that runs at 2.7V when the supply is sagging will execute instructions incorrectly, corrupt memory, and write garbage to flash. A brownout detector that holds the processor in reset until the supply is stable prevents this. A watchdog timer that resets the processor if the firmware hangs prevents the system from becoming a brick. These are not advanced techniques; they are basic hygiene. Yet I have seen field systems without them, and I have seen the resulting failures.
Component selection matters. Electrolytic capacitors dry out in heat. Use 105°C rated capacitors, not 85°C. Use conformal coating on PCBs that will be exposed to humidity. Use connectors with gold plating if they will be mated and unmated in the field. Use screw terminals with proper torque, not spring terminals that loosen with vibration. Every one of these choices adds cost, but the cost of a field failure is far higher.
Firmware reliability is a separate discipline. A field system must handle every possible input, every possible sequence of events, and every possible timing anomaly. It must never block on a peripheral that is not responding. It must never assume that a write to flash succeeded without verifying. It must never assume that a sensor reading is valid without sanity-checking it. The firmware must be written defensively, with explicit state machines, timeouts on every operation, and a recovery path for every error. This is not over-engineering; it is the minimum required for a system that will run unattended for years.
Availability: Designing for Fast Recovery and Graceful Degradation
Availability is about time. The less time a system spends in a failed state, the higher its availability. In a field deployment, the biggest lever you have is MTTR. If a failure requires a site visit, the MTTR is measured in days or weeks. If a failure can be recovered remotely, the MTTR is measured in minutes. If a failure can be recovered automatically, the MTTR is measured in seconds.
Remote recovery starts with a reliable communication path. If the system has a cellular modem, it should have a watchdog that resets the modem if it stops responding. It should have a way to reboot the system remotely. It should have a way to read the system logs remotely. It should have a way to update the firmware remotely. All of these features reduce MTTR and increase availability. They also introduce new failure modes—a bad firmware update can brick a system—so they must be designed carefully. But the alternative is a site visit, and site visits are expensive and slow.
Automatic recovery is even better. A system that detects a fault, resets the affected subsystem, and resumes operation without human intervention has an MTTR of seconds. This requires careful design: the system must be able to distinguish between a transient fault and a permanent fault, and it must not get stuck in a reset loop. A common pattern is a multi-stage recovery: first reset the peripheral, then reset the processor, then power-cycle the whole system, then enter a safe mode with reduced functionality. Each stage is more drastic than the last, and each stage is tried only if the previous one fails.
Graceful degradation is the third lever. If the cellular modem fails, the system should continue logging data locally and switch to LoRa if available. If the LoRa link fails, the system should continue logging and retry later. If the main sensor fails, the system should use a backup sensor or estimate the value from other measurements. If the power supply fails, the system should switch to battery power and send an alert. A system that degrades gracefully is still available for its most important functions even when some components have failed.
Measuring What Matters: Field Data Beats Datasheet Numbers
Datasheet MTBF numbers are calculated under laboratory conditions. They assume a constant temperature, a clean power supply, and no insects. They are useful for comparing components, but they do not predict field reliability. The only way to know how your system performs in the field is to measure it.
Start with a field log. Every system should log its uptime, its reset count, its power events, its communication failures, and its sensor errors. This log should be stored in non-volatile memory and transmitted when connectivity is available. Over time, this data will show you which components are failing, which failure modes are most common, and how long the system actually stays up. This is the data you need to improve the design.
Calculate availability from the field data, not from the datasheet. If the system was up for 8,000 hours out of 8,760 hours in a year, the availability is 91.3%. That is a useful number. If the system was up for 8,750 hours, the availability is 99.9%. That is also a useful number. The difference between 91.3% and 99.9% is 75 hours of downtime per year versus 10 hours. In a field deployment, 75 hours of downtime might mean 75 hours of lost data, 75 hours of angry customers, and 75 hours of your time on the phone.
Track MTTR separately. How long does it take to diagnose a failure? How long to get a replacement part? How long to get a technician to the site? How long to restore service? Each of these steps is an opportunity to reduce MTTR. A modular design with field-replaceable units can reduce MTTR from days to hours. A remote diagnostic interface can reduce MTTR from hours to minutes. A well-documented failure code can reduce MTTR from minutes to seconds.
Common Failure Modes in Brazilian Field Deployments
Here are the failure modes I see most often in Brazilian field systems, in rough order of frequency:
1. Power supply failure from surges and sags
The AC-DC converter dies, or the input protection components fail, or the hold-up capacitor dries out. The system resets randomly, or fails to start, or works intermittently. The fix is a better power supply design with proper input protection and thermal margin.
2. Connectivity failure from modem lockup or network issues
The cellular modem stops responding, or the SIM card loses registration, or the network is down. The system stops transmitting data, or the data is lost. The fix is a modem watchdog, a retry mechanism, and local data buffering.
3. Environmental ingress from humidity and insects
Condensation causes corrosion and leakage currents. Ants build nests in the enclosure and short out the power supply. Termites eat the cable insulation. The fix is a sealed enclosure with a desiccant pack, conformal coating on the PCB, and insect-proof cable glands.
4. Firmware bugs that only appear in the field
A race condition that only happens at a certain temperature. A buffer overflow that only happens with a certain data pattern. A watchdog timeout that only happens when the modem is slow to respond. The fix is defensive programming, extensive testing, and a remote firmware update mechanism.
5. Connector and wiring failures from vibration and corrosion
Screw terminals loosen. Crimp connections corrode. Cable ties degrade in UV. The fix is proper torque, gold-plated contacts, and UV-resistant cable management.
Design Tradeoffs: Reliability vs. Availability vs. Cost
Every design decision is a tradeoff. A more reliable component costs more. A more available system requires more redundancy, which costs more. A system that is both highly reliable and highly available is expensive. The question is not how to maximize both; the question is how to spend your budget where it matters most.
For a field system that logs environmental data and transmits it once an hour, a few hours of downtime per year might be acceptable. In that case, spend the budget on reliability—a good power supply, conformal coating, a solid enclosure—and accept that the system will occasionally be down. For a system that controls a pump or a gate, downtime is not acceptable. In that case, spend the budget on availability—redundant power supplies, a watchdog that resets the system automatically, and a remote monitoring interface.
The key is to understand the cost of downtime. If the system is down for an hour, what does that cost? Lost data? Lost production? Angry customers? A safety hazard? The answer determines how much you should spend on availability. If an hour of downtime costs R$10,000, spending R$5,000 on a redundant power supply is a good investment. If an hour of downtime costs R$10, spending R$5,000 on redundancy is a waste.
Practical Checklist for Field-Ready Systems
Here is a checklist I use when reviewing a field system design. It is not exhaustive, but it covers the most common problems:
- Power supply rated for 90V to 300V input, with transient protection and hold-up capacitance for at least 100ms.
- Brownout detector and watchdog timer enabled in firmware.
- Conformal coating on the PCB if the enclosure is not hermetically sealed.
- Enclosure rated IP65 or better, with insect-proof cable glands and a desiccant pack.
- Cellular modem with a hardware reset line and a firmware watchdog.
- Local data buffering in non-volatile memory, with a retry mechanism for transmission.
- Remote firmware update capability with a rollback mechanism.
- Field log with uptime, reset count, power events, and communication failures.
- Graceful degradation path for each major subsystem.
- Documented failure codes and a remote diagnostic interface.
If a design passes this checklist, it has a fighting chance in the field. If it does not, it will fail, and the failure will be expensive.
Frequently Asked Questions
What is the difference between reliability and availability in simple terms?
Reliability is how often a system fails. Availability is how much time the system is actually working. A system can be very reliable—it rarely fails—but still have low availability if it takes a long time to repair when it does fail. In field systems, repair time is often the dominant factor in availability because site visits are slow and expensive.
How do I calculate availability for a field system?
Availability is the total uptime divided by the total time in the period you are measuring. For example, if a system was up for 8,750 hours out of 8,760 hours in a year, the availability is 8,750 / 8,760 = 99.89%. The formula using MTBF and MTTR is Availability = MTBF / (MTBF + MTTR). Use field data, not datasheet numbers, to calculate these values.
Why do Brazilian field systems fail more often than lab systems?
Brazilian field conditions are harsh: split-phase 127V/220V mains with frequent sags, spikes, and micro-outages; intermittent 2G/3G/LoRa connectivity; tropical humidity; and insect ingress. These conditions create failure modes that do not appear in a lab. The power supply, the connectivity module, and the enclosure are the most common points of failure.
What is the most cost-effective way to improve availability in a field system?
Reduce MTTR. A modular design with field-replaceable units, a remote diagnostic interface, and an automatic recovery mechanism can reduce repair time from days to minutes. This often improves availability more than increasing reliability, and it usually costs less than adding full redundancy.
Next Steps for This Blog
This article is the first in a series on field system design for Brazilian conditions. The next article will cover power supply design for split-phase 127V/220V mains in detail, including surge protection, hold-up capacitance, and brownout detection. After that, I will cover connectivity strategies for intermittent 2G/3G/LoRa networks, including data buffering, retry logic, and modem watchdogs. If you have a specific failure you want me to analyze, send it in. I will use it as a case study.