Simple reliability arithmetic works beautifully for systems that either work or do not and never get repaired, but real plant is messier: equipment is redundant, it can sit in a degraded state, and it gets fixed and returned to service. When repair and redundancy interact, the tidy series-and-parallel formulas of a reliability block diagram stop giving the right answer. The Markov model is the tool built for exactly this situation. It describes a system as a set of distinct states, with defined rates of moving between them, and it lets you compute availability and the time spent working, degraded, or failed. This page introduces Markov state-transition models using a redundant pair that moves between working, degraded, and failed.
Markov reliability model in one line: A Markov reliability model represents a system as a set of discrete states, such as fully working, degraded with one unit down, and completely failed, connected by transition rates that describe how failures and repairs move the system from one state to another. Solving the model gives the long-run probability of being in each state, which yields availability and expected downtime. It is used for repairable and redundant systems where the interaction of failure and repair breaks the simple assumptions behind reliability block diagram math.
A Markov model reframes reliability as a question of which state a system is in rather than simply whether it is up or down. You enumerate the meaningful conditions the system can occupy, and each becomes a state in the model. For a redundant pair of servers, a natural set is three states: both working, one working while the other is down, and both down so the service is failed. The system is always in exactly one of these states, and reliability and availability questions become questions about how much time it spends in each.
What connects the states are transition rates, the speeds at which the system moves between them. A failure of one unit moves the pair from the both-working state into the degraded, one-down state, at a rate set by the units' failure rate. From the degraded state, a repair can carry the system back to both-working at a rate set by how fast a down unit is fixed, or a second failure can carry it onward to the fully failed state. Each arrow between states carries a rate, and it is the balance between failure rates pushing the system toward failure and repair rates pulling it back that determines where it tends to sit.
The defining property that makes the math tractable is the Markov, or memoryless, assumption: the rate of leaving a state depends only on which state the system is currently in, not on how long it has been there or how it arrived. This holds well when failures and repairs occur at roughly constant rates, the same constant-hazard assumption behind exponential lifetimes, and it is what lets the model be solved with standard techniques. When failure or repair times are strongly non-constant, for instance a wear-out process, the plain Markov assumption is strained and either extra states or a different method is needed.
A reliability block diagram computes system reliability by combining component reliabilities through series and parallel rules, and for non-repairable systems, or for a simple snapshot of independent components, it is fast and correct. Its limitation appears when components are repaired and that repair interacts with redundancy. In a redundant pair, whether the system survives a failure of the second unit depends on whether the first unit has already been repaired, and that coupling of failure and repair over time is precisely what the static combinatorial rules cannot represent. The block diagram sees only the instantaneous logic, not the race between the clock on a repair and the risk of a second failure.
The Markov model captures that race directly. By modeling the degraded, one-down state explicitly and attaching both a repair rate leading back to health and a failure rate leading to total failure, it accounts for the fact that a fast repair usually rescues the system before the surviving unit also fails, while a slow repair leaves a long window of vulnerability. The long-run occupancy of the failed state, which the model computes, reflects this balance and gives an availability that a static parallel calculation would get wrong. This is why repairable, redundant systems are the classic home of Markov analysis.
The same machinery extends to richer situations that block diagrams handle poorly: common-cause failures that take out both units at once, standby units that fail at a different rate while idle than while running, imperfect switchover to a backup, and limited repair capacity where only one crew can work at a time. Each of these becomes an extra state or an adjusted transition rate. The cost of this flexibility is that the state count grows quickly as the system gains components and conditions, which is the main practical constraint on Markov modeling and a reason it is often reserved for the parts of a system where redundancy and repair genuinely matter.
A Markov model is only as good as the failure and repair rates driving its transitions, and both are quantities that operational monitoring can measure. The failure rate feeding the arrows toward degradation and failure comes from how often units actually fail in service, while the repair rate feeding the arrows back to health comes from how long restorations actually take, from the moment a unit goes down to the moment it is back in service. Estimating these from real events, rather than from nameplate assumptions, is what makes a Markov availability prediction match the system it describes.
A control or SCADA system is the natural source for both. Alarm and status logs mark when a redundant unit trips or is taken out of service and when it returns, which yields both the failure intervals and the repair durations the model needs. A cloud SCADA platform such as Merobix can gather this state history across many redundant assets and sites, so the failure and repair rates are estimated from a real population of events rather than from one lonely example, and so the mean time to repair reflects genuine field logistics including detection delay and travel to remote sites. Those logistics often dominate availability, and they are visible in the timestamps a monitoring platform already keeps.
There is also a live-monitoring angle that complements the model. A Markov model tells you the long-run probability of sitting in the degraded, one-down state, which is exactly the state where the system is one failure away from an outage. Surfacing that condition promptly matters, because the whole benefit of redundancy depends on repairing the failed unit before its partner also fails. SCADA monitoring that immediately flags entry into the degraded state, and drives an urgent repair, shortens the time spent there and directly improves the availability the Markov model predicts, tying the analysis on paper to the operations that determine the real number.
Use a Markov model when the system is repairable and has redundancy, so that the interaction of repair and failure over time matters, which is exactly where reliability block diagram math breaks down. Block diagrams remain fine for non-repairable systems or a static snapshot of independent components. As soon as questions like whether a failed redundant unit is repaired before its partner fails become important, the state-and-transition view of a Markov model is the right tool.
The memoryless, or Markov, assumption is that the rate of leaving any state depends only on the current state, not on how long the system has been in it or how it got there. This holds well when failures and repairs occur at roughly constant rates, matching exponential lifetimes, and it is what makes the model solvable with standard methods. When failure or repair times vary strongly with age, as in wear-out, the plain assumption is strained and extra states or a different technique are needed.
Each transition rate is the speed at which the system moves from one state to another, with failure rates driving transitions toward more degraded or failed states and repair rates driving transitions back toward healthy ones. A failure of a working unit moves the system toward the failed side, while completing a repair moves it back. These rates are best estimated from real field data on how often units fail and how long repairs take, which is information a SCADA event log can supply.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.