A Petri-net transition is enabled only when every input place contains at least the number of tokens required by its input arc. Firing subtracts those input tokens and adds the output tokens. In the one-machine example below, the legal sequence Start, Complete, Start, Complete moves two modeled parts from Raw to Finished, returns the machine-availability token, and satisfies two conservation checks at every intermediate marking. The final marking is [0, 1, 0, 2] in the place order [Raw, MachineFree, InProcess, Finished].
Start before drawing this marking. The machine is occupied, so another start is disabled; completion is enabled.Scope and terminology first
This note uses an ordinary, untimed place/transition net, often shortened to a P/T net. A place is a circle that holds a nonnegative integer number of tokens. A transition is a bar representing an event. Directed arcs connect places to transitions or transitions to places, never two places or two transitions. The distribution of tokens over all places is the marking, which is the model's current state.
The public catalogue for ISO/IEC 15909-1:2019 identifies edition 2 as the current standard for Petri-net concepts, definitions, and graphical notation; ISO confirmed it in 2025. This article does not reproduce or interpret a licensed clause. The definitions and arithmetic below follow the ordinary weighted firing rule described in Murata's canonical 1989 IEEE survey and stated explicitly for manufacturing models by Huang and colleagues.
Tokens here are bookkeeping units, not physical objects or control signals. One token in MachineFree means “the modeled machine is available” only because we define it that way. The diagram does not sense a guard, command a motor, enforce mutual exclusion in hardware, or prove that a real machine is safe.
Model inputs and assumptions
The fictional cell begins with two parts waiting and one machine available:
| Place | Initial tokens | Meaning in this model |
|---|---|---|
Raw | 2 | parts not yet started |
MachineFree | 1 | availability of the single modeled machine |
InProcess | 0 | part currently occupying the machine |
Finished | 0 | completed parts |
Start consumes one token from both Raw and MachineFree, then produces one token in InProcess. Complete consumes one token from InProcess, then returns one token to MachineFree and produces one token in Finished. All six arcs have the default weight 1.
For a transition t, let Pre(p,t) be the input-arc weight from place p, or zero when no such arc exists. Let Post(p,t) be the output-arc weight. At marking M, t is enabled exactly when
M(p) >= Pre(p,t) for every place p.
If enabled, firing produces
M'(p) = M(p) - Pre(p,t) + Post(p,t).
The NRC-sponsored UCRL-ID-114839 guide gives the same rule for unit-weight arcs: each input place must have a token; firing removes one token from every input and places one in every output. The guide uses Petri nets to explain concurrent events and resource exclusion, but its discussion is not an approval of this fictional cell.
Fire the four-step sequence by hand
Write each marking in the fixed place order [Raw, MachineFree, InProcess, Finished]:
| Step | Requested firing | Marking after the step | Enabled next | Why |
|---|---|---|---|---|
| 0 | — | [2, 1, 0, 0] | Start | raw part and free machine are both present |
| 1 | Start | [1, 0, 1, 0] | Complete | machine token moved into InProcess |
| 2 | Complete | [1, 1, 0, 1] | Start | machine token returned; one raw part remains |
| 3 | Start | [0, 0, 1, 1] | Complete | second part occupies the machine |
| 4 | Complete | [0, 1, 0, 2] | none | no raw or in-process part remains |
The first firing is a component-wise subtraction and addition:
M0 = [2, 1, 0, 0]^T
Pre(:, Start) = [1, 1, 0, 0]^T
Post(:, Start) = [0, 0, 1, 0]^T
M1 = M0 - Pre(:, Start) + Post(:, Start)
= [2,1,0,0]^T - [1,1,0,0]^T + [0,0,1,0]^T
= [1,0,1,0]^T.
At M1, a second Start is illegal even though one raw part remains: MachineFree = 0 is smaller than the required input weight 1. This is the important distinction between drawing an arrow path and executing a token model. Every transition must be rechecked against the current marking.
Cross-check with the incidence matrix
Use columns [Start, Complete]. The input matrix, output matrix, and incidence matrix C = Post - Pre are
Start Complete Start Complete
Pre = [ 1 0 ] Post = [ 0 0 ] Raw
[ 1 0 ] [ 0 1 ] MachineFree
[ 0 1 ] [ 1 0 ] InProcess
[ 0 0 ] [ 0 1 ] Finished
Start Complete
C = [ -1 0 ] Raw
[ -1 +1 ] MachineFree
[ +1 -1 ] InProcess
[ 0 +1 ] Finished.
The four-step sequence fires each transition twice, so its firing-count vector is sigma = [2,2]^T. The state equation gives
C sigma = [-2, 0, 0, 2]^T
M4 = M0 + C sigma
= [2,1,0,0]^T + [-2,0,0,2]^T
= [0,1,0,2]^T.
That matches the row-by-row token ledger. Murata's survey treats matrix equations as one of the principal Petri-net analysis methods; the ICAPS tutorial Petri Nets (for Planners) gives the same state equation and an essential limit: satisfying it is necessary for reachability, not sufficient. A firing-count vector forgets order. A candidate marking still needs an actual sequence in which every requested transition is enabled at its step, so this example keeps the intermediate rows instead of trusting only M0 + C sigma.
Two P-invariants catch lost or duplicated tokens
A place vector y is a P-invariant when y^T C = 0. Multiplying the state equation by such a vector cancels the transition effects, so y^T M has the same value at every reachable marking.
The first vector selects the two machine-state places:
y_machine = [0, 1, 1, 0]^T
y_machine^T C = [0, 0]
MachineFree + InProcess = 1 at M0, M1, M2, M3, and M4.
The machine is therefore represented in exactly one of two states: available or occupied. The second vector selects the three material-state places:
y_part = [1, 0, 1, 1]^T
y_part^T C = [0, 0]
Raw + InProcess + Finished = 2 at every marking.
That invariant catches accidental loss or duplication of the two modeled parts. It does not prove that a physical counter, sensor, or database record is correct; it proves only that the declared net topology conserves its abstract tokens.
Reproducible Schematex source
petri "One-machine cell after Start"
layout: lr
place Raw *2 "raw parts"
place MachineFree *1 "machine available"
place InProcess "part in machine"
place Finished "finished parts"
transition Start "start machining"
transition Complete "complete machining"
Raw -> Start
MachineFree -> Start
Start -> InProcess
InProcess -> Complete
Complete -> MachineFree
Complete -> Finished
fire: Start
Schematex 1.0.13 strictly parsed and rendered this source with no diagnostics on August 28, 2026. After replaying Start, the SVG records four places, two transitions, six arcs, marking {Raw:1, InProcess:1}, and Complete as the only enabled transition. The current Schematex Petri Net reference documents the marking syntax, bipartite checks, weighted arcs, capacity checks, and fire: replay. The renderer also classifies this graph structurally as a workflow net; that label is not a workflow-soundness or liveness proof.
Checks, failure modes, and review boundary
Use these checks before trusting a firing trace:
- Fixed order: name the place order once; every vector and matrix row must follow it.
- Bipartite structure: every arc must connect a place to a transition or a transition to a place.
- Enablement before firing: test every input against its arc weight at the current marking.
- No negative tokens: any negative component means the proposed firing was not legal under the ordinary rule.
- Row and matrix agreement: the step ledger and
M0 + C sigmamust produce the same final marking. - Resource invariant:
MachineFree + InProcessmust remain 1. - Material invariant:
Raw + InProcess + Finishedmust remain 2. - Terminal interpretation: no enabled transition at
M4means this two-part job is finished, not that the model is globally “deadlock-free.”
Two negative tests expose common modeling errors. Request Start, Start from M0: the second firing must be rejected because the machine token is absent. Then delete Complete -> MachineFree: the first part can finish, but the machine token never returns, the second Start stays disabled, and the machine invariant fails. Other frequent errors are treating a place label as a Boolean instead of a token count, forgetting an arc weight, reordering matrix rows, adding transition effects before checking enablement, and assuming a green enabled marker chooses which transition will fire.
Paste the source into the Schematex playground, first run the illegal Start, Start sequence, then restore the legal four-step sequence and verify both invariants at every row. For a real system, replace each token meaning and transition precondition with reviewed requirements, then analyze reachability, deadlocks, timing, and safety in tools and processes appropriate to the application.