Choose your reading route
eduKateSG · Why Mathematics? · Petri Net Reliability: Places, Transitions, Tokens, Reachability and Stochastic Timing
Start with the question, audit the worked example, or jump to the assumptions and practice. Every chapter stays open for uninterrupted reading.
Understand the question
Define the quantity and follow the mechanism.Route 2 · Chapters 11–20
Reproduce the example
Audit the numbers one step at a time.Route 3 · Chapters 21–30
Check assumptions
See where design and calibration matter.Route 4 · Chapters 31–40
Explore applications
Connect the method to a concrete investigation.Route 5 · Chapters 41–46
Study and verify
Practise, inspect failure cases and read further.
Full chapter index · Practice and checking · Mathematics Learning Hub
Why is mathematics important in Petri net reliability? Many systems contain concurrency, shared resources, synchronisation, repair and sequences that a simple series–parallel diagram cannot express. A Petri net turns those behaviours into places, transitions, tokens and firing rules, then timed or stochastic extensions connect the logic to reliability and availability.
This guide builds the method from reachable markings to continuous-time models and simulation. The numbers are educational illustrations. Real assurance work needs verified semantics, authoritative configuration, suitable data, validated tools and the standards that apply to the system.
Full chapter index
Chapters 1–10 · Understand the question
Chapters 11–20 · Reproduce the example
Chapters 21–30 · Check assumptions
Chapters 31–40 · Explore applications
Chapters 41–46 · Study and verify
A system may have two jobs running together, one repair crew shared by several machines or a spare that activates only after a command. Petri nets express which events can occur concurrently and which compete for resources. Reliability mathematics then asks whether failed markings are reached during the mission and how long the system occupies each state.
Places represent conditions or resources, transitions represent events, and directed arcs define which tokens a transition consumes and produces. The drawing is only the start; arc weights, inhibitor rules and timing semantics determine behaviour. Give every element an operational meaning rather than using abstract circles and bars without traceability.
A token marks a currently available condition or resource. The vector of token counts over all places is a marking. A one-safe model allows at most one token per place, while other models use counts. Reliability states are properties of markings, so token meaning and capacity must be explicit.
A transition is enabled when its input requirements are met. Firing removes and adds tokens according to arc weights. Immediate transitions fire without modelled time; timed transitions wait according to their semantics. Conflicts need probabilities, priorities or nondeterministic rules. Hidden defaults can change the reliability result.
Use places Working, Failed and CrewAvailable. A failure transition moves a token from Working to Failed. A repair-start transition requires tokens in Failed and CrewAvailable, then holds the crew until repair completion returns tokens to Working and CrewAvailable. This tiny net already represents a shared resource more clearly than an independent repair-rate formula.
Let failure rate λ=0.01 per hour and repair rate μ=0.09 per hour, both exponential. The equivalent two-state continuous-time Markov chain has steady-state availability μ/(λ+μ)=0.09/0.10=0.9. The Petri net becomes especially useful when more components compete for one crew or repairs have several stages.
| Quantity | Value |
|---|---|
| Failure rate λ | 0.01/hour |
| Repair rate μ | 0.09/hour |
| Steady-state availability | 0.90 |
CHAPTER 7 OF 46 · Understand the question
7. Mission reliability versus availability
Reliability over a nonrepairable mission asks whether failure has occurred by time t. Availability asks whether the system is functioning at a time or over an interval, allowing restoration. A repairable Petri net can answer availability, but do not label its steady-state operational probability as mission reliability.
Start from the initial marking and fire every enabled transition to enumerate reachable markings and arcs between them. Mark failed, degraded and successful sets. An unreachable dangerous marking has zero probability under the model, but that does not prove it is physically impossible; validate the model boundary and firing rules.
Reachable markings can grow rapidly with components, token counts and resource combinations. Symmetry, invariants, decomposition and aggregation can reduce the state space. Any reduction must preserve the measure being calculated. A compact model that merges states with different future behaviour can be wrong.
A place invariant is a weighted token sum that remains constant under firing. It can prove conservation of resources, such as one repair crew token always being somewhere in the crew cycle. Check invariants before probability calculations; a missing token often reveals a modelling error.
A transition invariant is a firing-count pattern that returns the marking to its starting state. It can reveal cycles such as fail–repair–restore. Invariants describe structure, not timing or probability. A feasible algebraic invariant may still be unreachable from the chosen initial marking.
A deadlock marking enables no transition. It may represent intended shutdown, complete failure or a modelling defect. Classify each deadlock. If recovery should be possible but the net deadlocks, inspect missing resources, arcs and transition guards before adding an artificial escape.
Two enabled transitions may compete for the same token. Immediate-transition weights or explicit probabilities can resolve the conflict, while timed races use waiting-time distributions. A priority rule can suppress a lower-priority transition entirely. Record the convention and connect it to actual control logic.
Independent transitions can be enabled together and fire in either order or simultaneously under the chosen semantics. This captures parallel processes without enumerating every interleaving in the diagram. Quantitative solvers still need a precise rule for timing, ties and resource contention.
A timed net attaches deterministic intervals or delays to transitions. It can represent inspection windows, switching delays and scheduled tasks. The resulting process may not be Markovian. Do not replace a nearly fixed delay with an exponential rate unless the approximation is tested against the decision.
A stochastic Petri net assigns probability distributions to transition firing times. Exponential transitions often generate a continuous-time Markov chain over tangible markings. General distributions require simulation, supplementary variables or non-Markovian methods. State the clock and distribution family for every timed transition.
A marking with an enabled immediate transition is vanishing because no modelled time is spent there. A tangible marking has only timed transitions enabled. Eliminate vanishing markings carefully when generating a Markov chain, preserving branch probabilities into tangible states.
For exponential transitions, each tangible marking becomes a CTMC state. Off-diagonal generator entries sum rates leading between states, and each diagonal is the negative row sum. Solve transient probabilities for mission questions or stationary probabilities when steady state exists and is meaningful.
For the two-state example, generator Q=[[-0.01,0.01],[0.09,-0.09]]. Row sums are zero. Solving steady state gives Working probability 0.9 and Failed probability 0.1. This analytic case is a verification target for the Petri-net solver.
| From state | To state | Rate |
|---|---|---|
| Working | Failed | 0.01/hour |
| Failed | Working | 0.09/hour |
| Each diagonal | Same row | negative row sum |
With two failed components and one crew token, only one repair can be active. Independent component Markov chains would allow impossible simultaneous repairs unless coupled. A Petri net enforces resource capacity through the token, making queueing and priority visible.
Add places for detection, command and spare activation. A failed switch branch can move directly to system failure, while successful coverage enables a spare. Keep coverage probability separate from component failure rates. The earlier dynamic fault-tree guide provides related sequence logic.
The Markov reliability guide explains state probabilities. Petri nets can generate the states from concurrency and resource rules. The Markov assumption applies only when timed transitions and state representation support memorylessness.
Reliability block diagrams describe static success paths. Use them when they are adequate. Petri nets add operational sequences, repair, contention and synchronisation at the cost of more parameters and validation work.
Attach rewards to markings, such as 1 for full service, 0.5 for degraded service and 0 for failure. Expected reward measures delivered performance, while cumulative rewards measure service over time. Units and stakeholder meaning matter; a mathematically convenient reward is not automatically a valid service metric.
Highly reliable systems may produce few failed trajectories in ordinary simulation. Importance sampling and splitting can improve efficiency, but modified probabilities require correct weights. Validate the estimator on a smaller net with an exact answer and report confidence intervals and effective sample size.
Repair time may be lognormal, deterministic or phase-type. General stochastic Petri nets or simulation can represent it. Approximating a distribution by several exponential phases may recover a Markov model; check mean, variance and decision-relevant tail, not just the average.
For every timed or probabilistic transition, record definition, units, source population, configuration, exposure, censoring and uncertainty. Resource and priority rules need evidence too. A detailed net with guessed rates can be less trustworthy than a simple, transparent model.
Sample failure rates, repair distributions, coverage and conflict probabilities from justified joint uncertainty models. Re-solve or simulate the net. Report intervals for reliability or availability and the inputs that drive them. Monte Carlo trajectory error is separate from parameter uncertainty.
Check token conservation, reachable markings, deadlocks, generator row sums and probability totals. Collapse the net to a known two-state case. Remove repair to recover a nonrepairable result. Compare independent modules with product formulas where independence truly applies.
Compare predicted event sequences, resource queues, downtime and failure paths with tests or field histories. Validate intermediate markings as well as the final availability. A model can match total downtime while misrepresenting repair contention, leading to poor staffing conclusions.
Draw the Working–Failed–CrewAvailable net, calculate 0.9 steady-state availability and add a second machine sharing the crew. Identify which simultaneous repair state becomes impossible. This connects graphs, vectors, rates, conservation and conditional reasoning.
Use coins as tokens on hand-drawn places. Let the student fire transitions only when inputs are present. Ask what each coin means, where time enters and whether a deadlock is intended. Physical token play makes formal state logic accessible.
CHAPTER 33 OF 46 · Explore applications
33. Common misconception: tokens are components
A token represents whatever condition or resource the modeller defines. It may be a component, permission, job, crew or count. Misreading token meaning can invalidate every conclusion, so include a legend and capacity rule.
CHAPTER 34 OF 46 · Explore applications
34. Common misconception: every net is Markovian
A Petri net is a structural formalism. It becomes a CTMC only under specific timing assumptions and state representation. Deterministic and history-dependent transitions need other methods or expanded states.
A single crew token can encode a real operational constraint that would require many coupled equations in a direct state model. Petri nets use visual structure and algebra together: the picture describes permission, while probability supplies time.
Define place, transition, token and marking. Build the two-state net, write Q and obtain 0.9 availability. Explain reachability, deadlock and invariants. Add one crew shared by two machines. State when a CTMC translation is valid.
CHAPTER 37 OF 46 · Explore applications
37. FAQ: should every reliability model use Petri nets?
No. Use the simplest method that preserves the mechanisms relevant to the decision. Series–parallel formulas and fault trees are easier to review. Petri nets earn their complexity when concurrency, resource sharing, synchronisation or repair policy matters.
CHAPTER 38 OF 46 · Explore applications
38. FAQ: can simulation replace reachability analysis?
Simulation may miss rare or unreachable markings and does not prove absence. Structural reachability and invariant analysis complement simulation. Use both when practical, especially before rare-event estimation.
Report the initial marking, places, transitions, arc weights, capacities, guards, conflict rules, timing distributions, rewards, failed markings, state-space reductions, solver, random seeds, uncertainty, verification cases, validation evidence and configuration version.
A recent open survey reviews time-dependent Petri nets and performance evaluation. A reliability tutorial discusses stochastic Petri nets and rare-event simulation.
Mathematics matters because concurrency and shared resources change which system histories are possible. Petri nets make permissions, conservation and timing explicit, then connect them to reachability, Markov chains or simulation. Responsible use verifies structure, validates sequences and reports uncertainty.
Repair priorities can starve lower-priority jobs. Model preemption, queue discipline and fairness explicitly. A high-priority policy may improve one mission metric while worsening another. Compare service classes and consequences rather than reporting only aggregate availability.
Build tested subnets for components, crews and switches, then compose them through clearly defined places. Modular diagrams improve review, but shared tokens and synchronisation can create new behaviours. Re-run reachability and invariant checks after composition.
Different tools may implement immediate transitions, priorities and tie rules differently. Export formats do not guarantee semantic equivalence. Preserve tool version and test an interchange with known traces and probabilities before trusting migrated results.
Petri nets appear in reliability, manufacturing, communications, workflow and software verification. Students combine graph structure, linear algebra, probability and simulation. Those skills support several pathways, while professional assurance also needs domain standards and accountability.
A student should fire a small net correctly, identify reachable and deadlocked markings, translate exponential transitions to a generator matrix and explain why a shared crew token matters. The answer should include one structural and one probabilistic verification check.
Extended practice laboratory
Practice case 1: Token firing
Setup: Put one token in Working.
Task: Fire the failure transition.
Checking target: Move the token to Failed and preserve conservation.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 2: Two-state generator
Setup: Use λ=0.01 and μ=0.09.
Task: Write Q.
Checking target: Rows sum to zero.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 3: Availability
Setup: Solve the stationary equations.
Task: Find Working probability.
Checking target: Obtain 0.9.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 4: Shared crew
Setup: Use two failed machines and one crew token.
Task: List enabled repairs.
Checking target: Only one repair can start.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 5: Invariant
Setup: Track one crew token.
Task: Write a place invariant.
Checking target: The weighted sum remains one.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 6: Deadlock
Setup: Remove a repair-complete arc.
Task: Find the deadlock.
Checking target: Classify it as model defect or intended shutdown.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 7: Immediate choice
Setup: Add two immediate branches.
Task: Assign and normalise weights.
Checking target: Preserve branch probabilities after vanishing-state elimination.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 8: Non-exponential delay
Setup: Use a fixed inspection interval.
Task: Choose simulation or a phase approximation.
Checking target: Check mean, variance and tail.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 9: Reachability
Setup: Enumerate markings in a small net.
Task: Mark failed states.
Checking target: Do not claim physical impossibility without validation.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 10: Simulation
Setup: Estimate failed-marking probability.
Task: Report trials and interval.
Checking target: Separate trajectory error from parameter uncertainty.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 11: Validation
Setup: Compare queue lengths and repair sequences.
Task: Use held-out histories.
Checking target: Match intermediate behaviour.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.
Practice case 12: Conclusion
Setup: State marking, timing and failed set.
Task: Name solver and configuration.
Checking target: Separate availability from mission reliability.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows, identify the assumption that carries the most consequence, and describe one verification or validation check. Finish with a cautious sentence that distinguishes the illustrative calculation from a real operational approval.
Method note: For each case, draw the marking before and after the event, list enabled transitions and write the timing or probability convention. Check token conservation and whether a resource is being duplicated. Then explain which marking counts as failed and why the selected metric is reliability, availability or reward. Preserve the net version, units and one alternative semantics that would change the result.
Reflection: Explain why the checking target follows from the setup, what evidence would be needed outside this illustration, and how a wrong assumption could change the result. Preserve the calculation and final cautious sentence for review.