Petri-Net Modelling of a Rail Network

Student: Tahmina Ahmed
Course: Event-Driven Systems (University of Adelaide)
Assignment: Petri-Net Modelling of Railway Interlocking System
Language: Java (JDK 11)
Testing: JUnit 4

---

Project Overview

This project implements and models a railway interlocking system using Petri-Net principles.
The network represents 11 interconnected sections that control train movement between North–South (N-S) and South–North (S-N) directions.
The model ensures safe and conflict-free train routing through concurrency control, priority management, and constraint enforcement.

---

Network Description

The entire network contains 11 sections, divided into two independent subsystems:

• Passenger Line — the main north-south route.
• Freight Line — a secondary line connecting to the Islington Workshops.

These two lines are disconnected; trains cannot move from one to the other.

---

Train Movements

North → South (Left → Right)

Type	Entry	Exit	Legal Paths
Passenger	1, 3	4, 8, 9, 11	(1 → 5 → 8), (1 → 5 → 9), (3 → 4), (3 → 7 → 11)

South → North (Right → Left)

Type	Entry	Exit	Legal Paths
Freight	4, 9, 10, 11	2, 3	(4 → 3), (9 → 6 → 2), (10 → 6 → 2), (11 → 7 → 3)

Each train’s movement is validated through section availability and directional consistency.
No two trains may occupy the same section concurrently.

---

Network Segment Modelling and Petri-Net Design

The Petri-Net modelling style follows the methodologies outlined by references [1]–[4].
Each section is modelled as a combination of places and transitions, with transitions representing permissible movements between sections.

---

One-Way Sections

Sections such as 1, 2, 5, 6, 8, 10 permit movement in only one direction.
For example, section 2 contains transition t62 (6 → 2) and exit t20 (2 → 0).

Transition notation:
t<section_from><section_to>

• Example: t62 = transition from section 6 to 2
• Example: t20 = exit transition from section 2 to external sink

Each section’s place is denoted p<i> with a marking m<i> representing train presence.

---

Two-Way Sections

Sections 3, 4, 7, 9, 11 allow bidirectional traffic.
Each such section has two places:

• p<i>L → North → South movement
• p<i>R → South → North movement

This ensures that trains moving in opposite directions cannot occupy the same physical segment simultaneously.
Unlike simplified Petri-Net representations used in some references [3], this design explicitly separates both directions to ensure clearer modelling of interlocking constraints.

---

Junctions

When two legal paths intersect, constraints prevent collisions.
For instance, the intersection between passenger path (1 → 5) and freight path (3 → 4) uses a point structure (L1, R1) to control access.

• Transition t15 (from 1 to 5) requires markings at p1L and R1.
• Transition t34 (from 3 to 4) requires markings at p3L and L1.

Initially, R1 is marked to prioritise passenger trains.
Marking can toggle between L1 and R1 through intermediate transitions:

• tL1j1 → j1
• tj1R1 → R1

Self-looping transitions ensure a marking at R1 remains after t15 fires, maintaining availability state.

---

Entry and Exit Handling

External stations and exit points are modelled as source and sink transitions:

• Entry:

  • Represented by place p0 and source transition t00 (always enabled).
  • A token in p0 indicates an incoming train waiting to enter the network.

• Exit:

  • Represented by transition t<exit_section>0 (e.g., t40, t80, t90, t110).
  • These are sink transitions that can fire spontaneously — trains at exit sections can always leave.

---

Implementation Highlights

Component	Description
InterlockingImpl.java	Implements the railway interlocking logic controlling section occupancy and movement validation.
SectionLedger.java	Tracks section states to ensure one-train-per-section invariant.
TransitionDispatcher.java	Handles event-based movement (firing of transitions).
InterlockingModel.java	Encodes valid connections between sections (1–11).
Test Files	Verify safe movement, priority, and constraint satisfaction through JUnit.

---

Simulation Notes

Each move cycle corresponds to a transition firing in the Petri-Net model.
Trains advance only when the next section is free and no constraint is violated.
Tokens represent train positions; transition firing represents movement.

Example simulation loop:

Tick 1: Train A enters → Section 1  
Tick 2: Transition t15 fires → Train A moves to Section 5  
Tick 3: Transition t58 fires → Train A moves to Section 8 (exit)