MATLAB/Simulink project for dynamic evacuation routing in emergency conditions using Particle Swarm Optimization (PSO) and Parallel Particle Swarm Optimization (PPSO).
The project models the evacuation of people from a building as a discrete-event queueing network implemented with SimEvents. The optimizer acts on routing probabilities that determine how pedestrian entities are distributed among alternative paths. The objective is to minimize the total evacuation time while accounting for congestion, queue dynamics, bottlenecks, route switching and possible changes in path availability.
Figure 1. Case-study layout decomposed into queueing-network blocks.
Emergency evacuation is affected by uncertain crowd distributions, bottlenecks, blocked routes, local congestion and behavioral effects. Static evacuation plans are limited because they do not react to the current state of the evacuation process.
This project investigates a dynamic control strategy in which routing decisions are periodically optimized using the current simulation state. The evacuation model provides the performance feedback, while PSO and PPSO search for the routing probabilities that reduce evacuation time.
The optimization problem is formulated as:
where:
xis the vector of routing decision variables;J(x)is the evacuation-time objective returned by the SimEvents model;- each decision variable is normalized in the interval
[0, 1]; - the repository implementation uses a 24-variable decision vector.
The engineering goal is to evaluate whether parallel metaheuristic optimization can support evacuation control under dynamic emergency conditions.
The project compares three evacuation strategies:
| Strategy | Description |
|---|---|
| No optimization | Fixed transition probabilities are used throughout the evacuation. |
| Single optimization | PSO/PPSO computes a routing policy once, before running the evacuation. |
| Periodic optimization | The evacuation is paused periodically, the current state is read, and routing probabilities are re-optimized. |
The periodic strategy is the most reactive one because it updates routing decisions during the evolution of the evacuation.
The building is represented as a network of queueing components. Each building element is modeled as a SimEvents subsystem that processes pedestrian entities.
Main components:
| Component | Modeling role |
|---|---|
| Room / source | Generates pedestrian entities. |
| Corridor | Processes pedestrians with capacity and traversal-time constraints. |
| Stairs | Models slower traversal dynamics due to stair motion. |
| Door / exit | Represents bottlenecks, queues and limited discharge flow. |
| Queue-switching block | Routes entities toward alternative paths according to decision probabilities. |
| Terminator / exit counter | Counts evacuated entities and supports stop conditions. |
Figure 2. Complete SimEvents model of the case study.
The case study consists of a room-like evacuation area with two parallel corridors and two exits. The area is decomposed into six corridor blocks and two exit regions.
The upper corridor is split into four blocks, while the lower corridor is split into two blocks. Exit 1 is reachable through the right-side blocks, and Exit 2 is reachable through the left-side blocks. This decomposition makes it possible to define local routing choices and evaluate how congestion changes over time.
The evacuation dynamics are modeled as a discrete-event system. Each pedestrian is represented as an entity, and each structural element of the building acts as a queueing or service subsystem.
The queueing abstraction is useful because it captures:
- finite-capacity corridors;
- waiting effects near doors and exits;
- service times for crossing building elements;
- state-dependent congestion;
- throughput and utilization metrics.
Doors and narrow passages are modeled as bottlenecks. Under high demand, increasing the desired flow can reduce the actual discharge rate because of crowd pressure and local obstruction. This effect is commonly known as faster-is-slower.
This effect is relevant for evacuation control because the optimal policy is not necessarily the one that sends the largest number of people to the shortest path. A route can become inefficient when it becomes saturated.
The optimizer searches for the routing probabilities that minimize evacuation time.
Workflow:
- initialize model constants and PSO parameters;
- generate a candidate vector of routing probabilities;
- pass the candidate policy to the SimEvents evacuation model;
- simulate the evacuation behavior;
- compute the fitness value from evacuation time;
- update particle positions and velocities;
- repeat until the stopping condition is reached.
The fitness function is exposed in MATLAB through:
CostFunction = @(x) calcoloFitness(x);The sequential optimizer is executed with:
out = PSO(problem, params);The parallel optimizer is executed with:
out = parallelPSO(problem, params, step);The sequential implementation evaluates the particles one after another. For each candidate solution, the SimEvents model is simulated and the resulting evacuation time is used as the fitness value.
The PPSO implementation distributes particle updates and fitness evaluations across a local pool of MATLAB workers. The model constants are copied to the workers before the parallel computation. Group-level best solutions are computed first and then reduced to obtain the global best solution.
This structure reduces execution time when the number of particles increases, because multiple simulation-based fitness evaluations can be executed concurrently.
PPSO experiments were performed on three population scenarios:
| Scenario | People to evacuate | Notes |
|---|---|---|
| Small scenario | 72 | Lower congestion level |
| Medium scenario | 120 | Intermediate congestion level |
| Large scenario | 300 | Stronger congestion and longer evacuation time |
PPSO configuration used in the reported experiments:
| Parameter | Value |
|---|---|
| Maximum iterations | 10 |
| Number of particles | 30 |
| Decision variables | 24 |
| Variable bounds | [0, 1] |
| Fitness objective | Total evacuation time |
The results show that PPSO reduces the computational burden of the optimization phase compared with sequential PSO, especially as the number of particles increases.
Figure 3. Sequential PSO and parallel PPSO single-iteration execution time comparison.
The following table reports the average evacuation time over ten simulations for three strategies.
| Scenario | No optimization | Single optimization | Periodic optimization |
|---|---|---|---|
| 72 people | 1147.3 s | 586.07 s | 385.75 s |
| 120 people | 1471.7 s | 676.68 s | 498.69 s |
| 300 people | 3973.3 s | 1493.4 s | 1016.5 s |
Periodic optimization provides the best evacuation performance in all scenarios. Relative to the non-optimized evacuation, the average evacuation-time reduction is approximately:
| Scenario | Reduction with periodic optimization |
|---|---|
| 72 people | 66.38% |
| 120 people | 66.11% |
| 300 people | 74.42% |
| Scenario | No optimization | Single optimization | Periodic optimization |
|---|---|---|---|
| 72 people | 0.0628 | 0.1228 | 0.1866 |
| 120 people | 0.0815 | 0.1773 | 0.2406 |
| 300 people | 0.0755 | 0.2009 | 0.2951 |
The throughput results confirm that periodic re-optimization improves the effective evacuation rate, particularly in the highest-density scenario.
The optimizer reaches improved evacuation-time values within a small number of iterations.
Figure 4. PPSO best-cost evolution for the 72-person scenario.
Additional convergence plots are available in the results/ folder for the 120-person and 300-person scenarios.
evacuation-parallel-pso-simevents/
├── assets/
│ ├── case_study_layout.png
│ ├── case_study_blocks.png
│ ├── simevents_case_study_model.png
│ ├── queueing_network_model.png
│ ├── faster_is_slower.png
│ ├── corridor_simevents_block.png
│ ├── door_simevents_block.png
│ └── queue_switch_simevents_block.png
├── results/
│ ├── pso_ppso_initialization_time.png
│ ├── pso_ppso_iteration_time.png
│ ├── ppso_convergence_72_people.png
│ ├── ppso_convergence_120_people.png
│ ├── ppso_convergence_300_people.png
│ ├── evacuated_people_72_ppso.png
│ ├── evacuated_people_120_ppso.png
│ ├── evacuated_people_300_ppso.png
│ ├── evacuation_time_comparison.csv
│ ├── throughput_comparison.csv
│ └── results_summary.md
├── building-elementary-blocks/
│ └── DesignPattern.slx
├── funzioni/
├── inizializzazioni/
├── Completo_direzioniDinamiche.slx
├── mainPSO.m
├── mainPPSO.m
├── README.md
└── .gitignore
Generated Simulink artifacts such as slprj/, *.slxc, autosaves, cache folders and generated HTML reports should not be committed.
| File | Role |
|---|---|
mainPSO.m |
Sequential PSO entry point |
mainPPSO.m |
Parallel PSO entry point |
funzioni/calcoloFitness.m |
Fitness evaluation linked to the evacuation model |
funzioni/PSO.m |
Sequential Particle Swarm Optimization implementation |
funzioni/parallelPSO.m |
Parallel Particle Swarm Optimization implementation |
inizializzazioni/ |
Initialization scripts for optimizer and SimEvents constants |
Completo_direzioniDinamiche.slx |
Complete Simulink/SimEvents case-study model |
building-elementary-blocks/DesignPattern.slx |
Library of reusable SimEvents evacuation blocks |
Expected MATLAB environment:
- MATLAB;
- Simulink;
- SimEvents;
- Parallel Computing Toolbox;
- a configured MATLAB path including
funzioni/andinizializzazioni/.
The project depends on SimEvents for model execution. Without Simulink/SimEvents, the source code and saved results can still be inspected, but the full simulation-optimization loop cannot be reproduced.
Run the sequential optimizer from MATLAB:
mainPSORun the parallel optimizer:
mainPPSOThe scripts initialize the problem, load the model constants, execute the selected optimizer and plot the best-cost history.
Possible extensions include:
- replacing probabilistic routing with fuzzy or rule-based decision logic;
- formalizing the cost function analytically from throughput and queue states;
- incorporating sensor-driven real-time occupancy information;
- modeling the effect of acoustic alerts, displays and guidance signals on route compliance;
- evaluating larger and more complex building layouts;
- adding stochastic failures such as blocked corridors, unavailable exits or local hazards.
Michele Abbaticchio
MSc Automation Engineering
Politecnico di Bari
This project was developed as a Bachelor's thesis in Computer Engineering and Automation.