PaperlayerView exact revision on arXiv

Source-linked AI summary

A Temporal Planning Approach for Intelligent Flood Response

Fazlul Hasan Siddiqui, Md. Monjurul Islam, Sabah Binte Noor

arXiv:2608.20510v1cs.AI

TL;DR

Flood response needs coordinated, time-aware action planning when multiple areas compete for constrained resources, and prior approaches lacked automated scheduling for this setting. The paper develops a temporal framework in ANML and PDDL 2.1 covering operational constraints and mid-execution replanning. Experiments show feasible planning and support planner-selection guidance, with TFD favored for larger or rapidly replanned scenarios.

  • Problem

    Existing flood-response work does not employ automated planning and scheduling to generate time-aware, coordinated plans under resource constraints.

  • Method

    The framework models the full flood-response cycle with temporal actions, priority and route constraints, resource allocation, symbolic progress milestones, and dynamic replanning in ANML and PDDL 2.1.

  • Results

    TFD is faster and more predictable than FAPE, solves all replanning instances under tested perturbations, and is favored for large-scale scenarios and rapid replanning.

  • Takeaways & Limitations

    Planner choice should depend on scenario scale, plan-quality priorities, and whether the task is initial planning or mid-execution replanning.

  • Takeaways & Limitations

    Future work must add multi-objective optimization and interfaces translating planner output into human-readable schedules or dispatch orders.

Abstract

from arXiv · show

Effective response to multiple, simultaneously flooded areas requires coordinating appropriate actions in the correct temporal order, under severe resource constraints. Automated planning provides a foundation for addressing this challenge by generating time-aware schedules, given a formal description of available resources, constraints, and goals. This work presents an intelligent flood-response framework that exploits temporal planning and models the complete operational life cycle of flood response. The framework incorporates priority-driven triage, route accessibility and travel costs, resource allocation, and supply management, while also supporting mid-execution re-planning in response to unexpected environmental changes. The framework is formulated both in the Action Notation Modeling Language (ANML) and the Planning Domain Definition Language (PDDL) 2.1, facilitating compatibility with a wider range of temporal planners. Experimental results establish the feasibility and scalability of the proposed framework, showing that flood response scenarios can be effectively modeled and solved using temporal planning, while providing guidance on planner selection.

Introduction

Flood response becomes difficult when multiple locations require coordinated actions and scarce resources under tight time constraints. The paper addresses this gap with a temporal planning framework that models operational coordination, constraints, and replanning.

  • Traditional flood-management approaches are increasingly inadequate for simultaneous floods requiring resource allocation under severe time constraints.
  • Prior flood-response studies address evacuation, supply allocation, simulation, resilience, and infrastructure planning, but do not use automated planning to generate coordinated schedules.
  • The framework models allocation of teams, resources, and vehicles together with the timing and sequencing of concurrent actions.
  • It incorporates priority-based triage, route accessibility, vehicle capacity, concurrent-operation scheduling, and symbolic milestones for evacuation and supply progress.
  • The framework supports mid-execution replanning by updating the problem instance with newly observed field conditions and generating an adapted schedule.
  • A representative scenario combines two safe areas and two affected zones with rescue, medical support, evacuation, supplies, vehicle capacities, and vehicle-dependent travel times.

Automated Planning

Automated planning represents actions, states, goals, resources, and temporal constraints so planners can generate valid schedules. Temporal planning extends numeric planning with durative actions, explicit timing, concurrency, and makespan-based schedule evaluation.

  • Classical planning uses propositional facts and actions to transform an initial state into one satisfying specified goal conditions.
  • Numeric planning adds numeric variables and arithmetic updates to represent quantities such as supplies, fuel, and vehicle capacities.
  • Temporal planning addresses duration, deadlines, and concurrency by representing actions with time-dependent conditions and effects.
  • A temporal plan is a timed schedule of durative actions whose preconditions must hold at required time points and whose completion achieves the goals.
  • Makespan measures elapsed execution time, with smaller values indicating more temporally compact schedules and greater action concurrency.
  • Temporal planning fits flood response because operations require synchronized activities with durations under constrained time and resources.

Planning Modeling Languages

The framework uses PDDL 2.1 and ANML to express temporal flood-response domains in forms supported by different planners. PDDL uses temporally annotated action schemas, whereas ANML represents time-dependent variables directly on a timeline.

  • Planning modeling languages encode domains and instances through actions, state variables, constraints, temporal properties, initial states, and goals.
  • PDDL separates reusable domain definitions from instance-specific objects, initial states, and goals, while PDDL 2.1 adds numeric fluents and durative actions.
  • PDDL 2.1 places conditions and effects at action start, throughout execution, or at completion; TFD consumes this language.
  • ANML uses variables whose values are implicit functions of time, expressing state transitions directly over an action timeline.
  • ANML distinguishes conditions from effects through relational, assignment, and transition operators with temporal qualifiers; FAPE consumes ANML.

Proposed Temporal Planning Framework

The framework formulates flood response as a temporal planning task over typed facts, rigid numeric fluents, durative actions, initial states, and goals. It represents coordinated operations across affected zones, including priority ordering and resource-constrained logistics.

  • Framework formulation: Flood response is modeled as a temporal planning task coordinating teams, vehicles, priorities, and logistics across affected areas.The running scenario stages resources at a safe hub and serves two affected zones under a strict priority relation.
  • Formal task definition: Definition 7 represents a planning task as Πf = ⟨Ff, Xf, Adf, γf, If, Gf⟩ over a flood-response domain.Ff contains grounded propositional facts, while Xf contains rigid numeric fluents and Adf contains instantiated durative actions.
  • State representation: The model uses predicates for priorities, vehicle and team locations, boarding, evacuation levels, cargo, route accessibility, and valid evacuation or supply steps.These predicates describe the initial operational configuration and constrain feasible plans.
  • Actions and validity: The domain includes nine grounded durative action schemas with temporal preconditions and effects, and assigns unit cost to every action.The initial state captures vehicles, teams, routes, requirements, and milestone levels; the goal condition requires satisfied operational demands and completed evacuation.
  • Running example: The representative instance uses one safe location, two vehicles, two teams, relief goods, and two priority-ordered affected zones.Figure 3 gives vehicle-specific travel times and initializes the relief-goods stock at food=k300.

Modeling Decisions

The framework makes key modeling choices to preserve temporal coordination while keeping planning tractable. It uses symbolic progress milestones, explicit priority constraints, temporal resource locking, and native concurrency.

  • Progress representation: Evacuation and supply progress use ordered symbolic milestones instead of continuous numeric fluents.This avoids large numeric search spaces while preserving multi-trip behavior and capacity-aware progress tracking.
  • Priority handling: Priority relations are encoded in action preconditions so generated plans automatically respect operational ordering.This removes the need for separate validation or post-processing of priority compliance.
  • Resource management: Vehicles and teams are temporally exclusive during transportation, preventing conflicting concurrent assignments.Transportation temporarily makes these resources unavailable for other actions.
  • Concurrency: Independent rescue, medical, transportation, and logistics operations may execute concurrently when resource and ordering constraints are satisfied.Concurrency is provided directly by the temporal-planning formalism.

World Representation

The world representation organizes flood-response entities into typed objects and predicates describing locations, assets, teams, resources, operational status, priorities, and progress. Symbolic milestones encode remaining evacuation and supply demand, while fixed numeric fluents determine durations and capacity-valid steps.

  • Typed entities: The domain has four root types: Location, Vehicle, Team, and Resource.These types are specialized into affected or safe locations, transit or freight vehicles, rescue or medical teams, and consumable supplies.
  • World state: Spatial predicates record vehicle locations, team locations, and whether teams are inside vehicles.Vehicle-status predicates additionally encode evacuation activity, cargo state, and route feasibility.
  • Requirements and priorities: needs rescue(l), needs medical support(l), and prior(l,pl) express location requirements and priority ordering.The prior relation requires location pl to be served before l, restricting concurrent service of lower-priority areas.
  • Operational progress: Evacuation, resource demand, and available stock are represented with ordered symbolic milestones such as p60 ≻ p40 ≻ p20 ≻ p0 and k200 ≻ k100 ≻ k0.The predicates evac level, resource needed, and resource available track these milestone levels.
  • Fixed parameters: Rigid numeric fluents specify team-size durations, vehicle travel times, workload scaling, and valid capacity-bounded progress steps.valid evac step and valid supply step enforce vehicle-capacity constraints.

Action Schemas

Nine durative actions organize transport, on-site response, evacuation, and supply operations into a causal and priority-constrained network. The model supports repeated logistics cycles and concurrent execution when constraints permit.

  • Transport actions: BOARDTEAM, DISEMBARKTEAM, and MOVEVEHICLE transport teams and vehicles across accessible routes.Boarding and disembarkation preserve vehicle location during execution and scale with team size; movement uses vehicle- and route-specific travel times.
  • Response actions: RESCUEAFFECTEDPEOPLE and PROVIDEMEDICALSUPPORT require dedicated teams to remain on site and enforce shared triage priorities.Higher-priority locations must be fully serviced before lower-priority locations receive the same task type.
  • Evacuation actions: EVACUATE and DISEMBARKEVACUATEDPEOPLE move civilians in capacity-bounded steps and release vehicles for reuse.Key evacuation milestone updates occur at action start to enable concurrency.
  • Supply actions: LOADRESOURCE and DELIVERRESOURCE shuttle relief goods between depots and affected zones while updating discretized demand milestones.Repeated loading and delivery operations continue until supply requirements are satisfied.
  • Operational cycles: The actions form a causal network linking deployment, evacuation, and supply cycles, with MOVEVEHICLE as the primary shared scheduling resource.Priority constraints span response and logistics actions, enforcing strict triage ordering across zones.

Instance Formulation

The formulation separates a reusable action domain from scenario-specific instances, then defines temporal-plan validity and dynamic replanning for changing flood conditions.

  • Instance Formulation: The domain specification defines object types, predicates, and action schemas, while a problem instance supplies concrete entities, initial state, and goals.Instances also assign static relations, resource distributions, vehicles, teams, and demands.
  • Instance Formulation: Transport, response, and logistics schemas organize movement, on-site services, evacuation, and supply operations within the flood-response domain.The action categories are represented in Tables 1–3 and Figure 4.
  • Instance Formulation: The action network distinguishes causal dependencies from priority constraints, while allowing required facts to originate in the initial configuration.Solid arrows represent causal dependencies and dashed arrows represent priority constraints.
  • Instance Formulation: A representative planning instance is valid only when its temporal conditions hold and its final state satisfies the specified goal condition.The representative goal requires complete evacuation, fulfilled rescue, medical, and resource demands, and no vehicle remaining engaged in evacuation.
  • Plan Validity: Priority ordering is enforced as a hard at-start precondition, preventing lower-priority response actions while higher-priority requirements remain outstanding.This construction guarantees that admissible plans respect priorities without planner-specific post-processing.
  • Dynamic Replanning: The formulation assumes complete and correct world information, but supports replanning when route, infrastructure, or demand information changes during execution.Previously executed actions are preserved while the remaining schedule is recomputed.
  • Dynamic Replanning: Replanning reconstructs the state before surprise time T, incorporates newly observed facts or revised goals, and invokes the temporal planner to generate an updated schedule.The process begins from the original instance and plan and produces a revised planning instance and schedule.
  • Dynamic Replanning: The replanning benchmark-generation procedure is introduced after the scalability benchmark description and separates benchmark construction from the replanning evaluation.The supplied section identifies the benchmark-generation method and complexity characteristics as the next topic.

Benchmark Generation and Replanning Setup

The evaluation uses progressively larger temporal-planning instances and controlled mid-plan perturbations to test both initial planning performance and replanning adaptability.

  • Benchmark Generation: The primary benchmark contains 50 instances encoded in both PDDL 2.1 and ANML, with ten problems in each of five increasing-complexity tiers.The benchmark evaluates scalability, runtime performance, and plan quality across PDDL-based and ANML-based planners.
  • Benchmark Generation: Grounded action spaces reach 84,579 actions as agents and locations increase, reflecting multiplicative growth in possible action bindings.This measures the combinatorial expansion targeted by the scalability evaluation.
  • Replanning Setup: The replanning benchmark regenerates a plan from the world state observed when a discrepancy is revealed during execution.The surprise time is placed near the original plan midpoint so substantial work is committed while meaningful recovery remains.
  • Replanning Setup: Route blockage removes vehicle-accessibility facts only after checking that every affected location remains reachable from a safe location.Disconnected instances fall back to the evacuee-increase perturbation.
  • Replanning Setup: Evacuee increase raises a zone’s evacuation milestone and changes the goal so that the zone must reach p0.The selected milestone is strictly higher than the original level.
  • Replanning Setup: The replanning experiment uses 49 solved primary PDDL instances, assigning route blockage to odd-indexed cases and evacuee increase to even-indexed cases.Algorithm 2 is applied with each instance’s plan, surprise time, and perturbation.
  • Evaluation Setup: Evaluation compares FAPE and TFD using coverage, runtime, plan length, makespan, replanning makespan change, plan-length change, and runtime ratio.Coverage, runtime, and plan quality are primary metrics; rrt compares replanning time with original planning time.
  • Evaluation Setup: Experiments run under a 3,600-second limit on a 12th Gen Intel Core i7-12700 system with 16GB RAM and an NVMe SSD.A case counts as solved when a valid plan is returned within the time limit.

Results on Primary Benchmark

TFD provides faster and more predictable solution search, whereas FAPE produces shorter plans; neither planner clearly dominates makespan-based plan quality.

  • Coverage and Runtime: 98% coverage is reached by TFD before 20 seconds, while FAPE plateaus at 86% around 2,430 seconds.Across complexity tiers, TFD also finds solutions faster and its runtime grows more slowly.
  • Coverage and Runtime: On the 42 jointly solved instances, every runtime comparison favors TFD over FAPE.The comparison attributes the difference to TFD’s heuristic forward search and FAPE’s constraint-network propagation cost.
  • Plan Quality: FAPE has a median plan length of 39 steps versus TFD’s 57, but plan length does not account for concurrent execution.A longer plan can have a smaller makespan when its actions overlap.
  • Plan Quality: Makespan comparisons show FAPE is usually slower to execute, although several lower-left cases favor FAPE; overall, neither planner clearly dominates.The divergence is most visible at the high end of the comparison.
  • Scalability: TFD runtime grows almost polynomially with grounded action-space size, while FAPE exhibits noisier and more variable scaling.FAPE’s variance reflects sensitivity to problem structure, flaw resolution order, causal-chain depth, and temporal-constraint density.
  • Scalability: TFD combines faster search with more predictable runtime, a property the evaluation identifies as important for operational deployment.FAPE’s runtime variability is the principal contrast within the examined action-space range.

Results on Replanning Benchmark

TFD successfully replanned all 49 tested instances, with replanning usually faster than initial planning. Route blockages caused modest plan changes, whereas evacuee increases produced larger and more variable changes.

  • TFD successfully solved all 49 replanning instances.
  • Evacuee increases raised plan length by 30.1% on average, compared with 3.1% for route blockages.
  • Replanning runtime increased exponentially as the number of remaining scheduled actions grew linearly.The reported runtime trend is based on the residual plan suffix after the surprise time.
  • Route blockage perturbations increased makespan by 3.2% on average, while evacuee increases raised it by 15.7%.Evacuee increases also produced a 33.7% standard deviation in makespan change.
  • Some replanned schedules had lower makespans than the corresponding original-plan tails.

Discussion

The evaluation favors TFD for large-scale initial planning and rapid mid-execution replanning, while FAPE remains useful when small-scale plan quality is prioritized. The framework demonstrates benchmark-level feasibility but still requires validation in real-world workflows and further decision-support development.

  • TFD is faster and more predictable than FAPE, whereas FAPE produces fewer sequential steps and can achieve lower makespan on smaller instances.
  • TFD appears more viable for city-scale incidents, while FAPE remains acceptable for neighborhood-scale scenarios when there is time to prioritize plan quality.
  • TFD successfully solves dynamic replanning instances and generally returns replans faster than initial plans.
  • The framework generates temporal flood-response plans and supports dynamic adaptation in benchmark experiments.
  • Validation with real-world flood-response data and operational workflows remains necessary for assessing practical deployment feasibility.
  • Future work should add multi-objective optimization and interfaces that translate planner output into human-readable schedules or dispatch orders.
Loading 2608.20510v1…