2.0 Related work

Wildfire modelling has been developed to provide support during incidents in terms of operations management, planning and even scientific analyses, with FARSITE being one such tool [Reference Finney6]. It was developed by the U.S. Forest Service, and the fire propagates its perimeter as expanding ellipses, with the rate of spread and intensity governed by the Rothermel model [Reference Rothermel7]. The fire simulator includes effects such as spotting and fuel moisture. Prometheus, a wildfire simulator, adopts a similar perimeter expansion methodology but is calibrated for Canadian forests [8, Reference Tymstra, Bryce, Wotton, Taylor and Armitage9].

These tools are semi-empirical and, while robust, simplify processes such as spotting, assume continuous fuels and are highly sensitive to uncertainties in wind, fuel and moisture inputs, which can lead to incorrect predictions and biased judgements [Reference Alexander and Cruz10]. Consequently, there is increasing interest in complementing, rather than replacing, these established tools with systems based on artificial intelligence (AI). Examples of domain-specific LLMs, such as WildfireGPT, have begun to appear [Reference Ramesh, Sun, Li, Zhang, Annam, Fang and Tong11]. Although their language capabilities could be used for wildfire discussions, they would require very specialised training data and the algorithmic precision necessary for adequate wildfire behaviour predictions. However, LLMs can also serve as an additional layer to support resource allocation and communication under uncertainty, improving human decision-making [Reference Chen, Tao, Tang, Qin, Yang and Zhu12].

The potential of LLMs extends beyond wildfire scenarios. In healthcare, advanced reasoning models have demonstrated diagnostic performance comparable to human physicians in medical scenarios [Reference Vrdoljak, Boban, Males, Skrabic, Kumric, Ottosen, Clemencau, Bozic and Völker13]. Similarly, in disaster response, LLMs, such as disaster response GPT, have been able to translate brief situation reports into structured plans of action, although human validation was still required [Reference Odubola, Adeyemi, Olajuwon, Iduwet, Aniekan and Odubola14]. In other fields, such as logistics and supply chain management, LLMs and forms of generative AI have been used to find new ways to enhance decision making, automate operations, or reduce disruptions, but they were found to be prone to hallucination issues [Reference Boone, Fahimnia, Ganeshan, Herold and Sanders15].

The trend is to use generative AI and LLMs for enhancing the speed and adaptability of human reasoning, provided their outputs are properly supervised and evaluated. Their integration offers rapid decision-support systems for dynamic environments such as wildfires, clinical emergencies, disaster response and logistics.

3.0 Theory

This section introduces the theoretical basics to understand the various concepts needed to perform the present work.

3.4 Neural networks and large language models

An artificial neural network is a computational architecture based on biological neural networks. These artificial neural networks contain computational units, known as neurons, which are connected through weights that scale their inputs. These weights scale the computed function of the neuron, and the results are propagated through the neural network layers as outputs. Multilayer neural networks used for machine learning or artificial intelligence typically consist of:

• • Input layer: Receives the inputs

• • Hidden layers: Intermediate layers where the computations take place

• • Output layer: Produces the final outputs

The chain structure of the layers forming a neural network consists of the input features $x$ , the weights $W$ , the bias $b$ , the activation function $g$ , and the output ${h_i}$ :

(1) \begin{align} {h^{\left( 1 \right)}} = {g^{\left( 1 \right)}}\left( {{W^{\left( 1 \right){\rm{\top }}}}x + {b^{\left( 1 \right)}}} \right) \\[-30pt] \nonumber \end{align}

(2) \begin{align} {h^{\left( n \right)}} = {g^{\left( n \right)}}\left( {{W^{\left( n \right){\rm{\top }}}}{h^{\left( {n - 1} \right)}} + {b^{\left( n \right)}}} \right) \\[4pt] \nonumber \end{align}

Based on advanced forms of statistical language models, which model the likelihood of a word appearing in a given sequence [Reference Shannon22], combined with machine learning methods, such as recurrent neural networks or reinforcement learning [Reference De Mulder, Bethard and Moens23] and transformer architectures [Reference Brown, Mann, Ryder, Subbiah, Kaplan, Dhariwal, Neelakantan, Shyam, Sastry and Askell24], LLMs are trained iteratively to learn how to provide an outcome expected by humans. This capability is relevant in many fields, such as SoS modelling, to obtain evolving models that better reflect real-world decision-making [Reference Luzeaux and Ruault25].

3.4.1 Universal approximation theorem

The universal approximation theorem states that a feed-forward neural network with enough hidden layers can approximate the linear output layer to a non-zero amount of error for any Borel measurable function from a finite-dimensional space to another one. A continuous function is Borel measurable if it is continuous for a closed and bounded subset of ${\mathbb{R}^n}$ [Reference Hornik, Stinchcombe and White26, Reference Hornik, Stinchcombe and White27]. Feed-forward networks with hidden layers require activation functions to introduce non-linearity into the model for the hidden layers [Reference Goodfellow, Bengio and Courville28], being some common examples of them:

• • Sigmoid: $\sigma\!\left(x \right) = \frac{1}{{1 + {e^{ - x}}}}$

• • Hyperbolic tangent: ${\rm{tanh}}\left( x \right) = \frac{{{e^x} - {e^{ - x}}}}{{{e^x} + {e^{ - x}}}}$

This theorem implies that, with enough training, a neural network can be trained to obtain outputs with an error very close, but never equal, to zero.

3.6 Basics of rotary-wing aerodynamics

Helicopter aerodynamics studies the numerous complex interactions during the different flight regimes, such as the main rotor wake structure and its effect on the tail rotor, transonic flows over the blades, stalled regions, etc. There are, however, several results based on momentum theory that are simple enough for quick estimations [Reference Glauert31, Reference Johnson32]. The thrust coefficient is one of the most relevant values and is defined as:

(3) \begin{align} {C_T} = \frac{T}{{\rho A{{\rm{\Omega }}^2}{R^2}}} \end{align}

Where T is the thrust, A is the rotor disk area, ${\rm{\Omega }}$ is the rotor rotational velocity, R is the rotor radius and $\rho $ is the flow density. In a similar manner, the power coefficient is defined as:

(4) \begin{align} {C_P} = \frac{P}{{\rho A{{\rm{\Omega }}^3}{R^3}}} \end{align}

Being P power, A rotor disk area, ${\rm{\Omega }}$ , R rotor radius and $\rho $ the flow density. Then, assuming one-dimensional flow for a hovering rotor case, the inflow ratio ${\lambda _h}$ can be defined based on momentum theory as:

(5) \begin{align} {\lambda _h} = \frac{{{v_h}}}{{{\rm{\Omega }}R}} = \sqrt {{C_T}/2} \end{align}

3.6.1 Initial rotor sizing example in conceptual helicopter design

This section includes a small illustrative example of rotor sizing for a conceptual helicopter. It is common to start by considering the hover state [Reference Leishman33] and use Equation (3). Historical trends can be used together with weight build-up methods for an initial value of the thrust coefficient [Reference Raymer4], although the additional weight of a water bucket should be considered. An initial consideration for the process could be to keep the thrust coefficient value similar to other helicopters [Reference Kee34], and modify the rotor geometry:

\begin{align*} {C_T} = \frac{{{T_{ref}}}}{{\rho {A_{ref}}{{\rm{\Omega }}^2}R_{ref}^2}} = \frac{{{T_{new}}}}{{\rho {A_{new}}{{\rm{\Omega }}^2}R_{new}^2}} = \frac{{{T_{ref}} + {\rm{\Delta }}T}}{{\rho \pi {{\rm{\Omega }}^2}{{({R_{ref}} + {\rm{\Delta }}R)}^4}}} \end{align*}

From the additional weight ${\rm{\Delta }}T$ requirement related to the water bucket load, it is possible to use reference values and the relationship above to obtain the variation of the rotor radius ${\rm{\Delta }}R$ for the new geometry. After some manipulation, the increment can be computed using the new relationship:

\begin{align*} {R_{ref}}\left( {\sqrt[4]{{1 + \frac{{{\rm{\Delta }}T}}{{{T_{ref}}}}}} - 1} \right) = {\rm{\Delta }}R \end{align*}

The new rotor radius needs to be checked against operational constraints, such as the need to land in remote wooded terrains, where finding open areas with adequate blade clearance from trees will become more challenging for larger rotor blades. The velocity at the blade tip ( ${V_{tip}} = {\rm{\Omega }}R$ ) is another constraint, as values beyond $M = 0.7$ will be in the transonic region, leading to issues such as additional noise.

It is possible to continue the sizing by using blade element analysis [Reference Leishman33], which provides the analytical result that relates the thrust coefficient to the mean lift coefficient of the entire blade:

(6) \begin{align} {\bar C_L} = 6\left( {\frac{{\pi R}}{{{N_b}c}}{C_T}} \right) = {C_{{l_\alpha }}}\bar \alpha \end{align}

With ${C_{{l_\alpha }}}$ defined as the blade profile lift-slope, $\bar \alpha $ as the mean angle-of-attack of the blades, ${N_b}$ as the blade count and $c$ as the blade chord. It is convenient to introduce the definition of solidity ( $\sigma $ ) [Reference Leishman33] as:

(7) \begin{align} \sigma = \frac{{{N_b}c}}{{\pi R}} \end{align}

The different values in Equation (4) show that if the goal is to keep the thrust coefficient constant at a specific value, the variations of the geometrical values and the aerodynamic properties are going to be correlated. To continue with the example for the initial considerations for the rotor, remaining equations (Equations (4) and (5)) can be combined with Equation (3) to relate the ideal power coefficient to the thrust coefficient:

\begin{align*} {C_P} = \frac{P}{{\rho A{{\rm{\Omega }}^3}{R^3}}} = \frac{{T \cdot {v_h}}}{{\rho A{{\rm{\Omega }}^3}{R^3}}} = \frac{{C_T^{3/2}}}{{\sqrt 2 }} \end{align*}

This relationship is useful for computing power, but it is more convenient for generating a figure of merit (FM) to relate the ideal power to hover and an estimation of a more realistic value of the non-ideal power required [Reference Leishman33]:

\begin{align*} FM = \frac{P}{{\rho A{{\rm{\Omega }}^3}{R^3}}} = \frac{{T \cdot {v_h}}}{{\rho A{{\rm{\Omega }}^3}{R^3}}} = \frac{{C_T^{3/2}/\sqrt 2 }}{{{C_{{P_{real}}}}}} \end{align*}

The power needed can be approximated without measurements by considering losses. If only induced and profile power losses are considered, it is possible to write:

(8) \begin{align} {C_P} = {C_{{P_i}}} + {C_{{P_0}}} \end{align}

Where the induced power losses are considered by adding a correction factor $\kappa $ with a typical value of 1.15 [Reference Leishman33], then:

(9) \begin{align} {C_{{P_i}}} = \kappa C_T^{3/2}/\sqrt 2 \end{align}

Then, for a rectangular blade with an assumed constant blade section profile drag coefficient ( ${C_{{d_0}}}$ ), the profile power coefficient can be found to be [Reference Leishman33]:

(10) \begin{align} {C_{{P_i}}} = \frac{{\sigma\kern-0.1pt{C_{{d_0}}}}}{8} \end{align}

It is possible now to plot the figure of merit with respect to thrust coefficient variations. Helicopter typical values [Reference Kee34] for solidity and blade section profile drag coefficient are, respectively, $\sigma = 0.1$ and ${C_{{d_0}}} = 0.01$ , resulting in Fig. 2. A good performance for hovering rotors is between 0.7 and 0.8 in the figure of merit [Reference Leishman33, Reference Johnson, Withrow-Maser, Young, Malpica, Koning, Kuang, Fehler, Tuano, Chan and Datta35]. The analysis is not extended further for this example, as the process would continue with different considerations and discussions for going deeper into the new concepts’ specifics [Reference Johnson and Sinsay36], which is beyond the scope. Variations in the number of blades, their chord length, aerodynamic profiles, etc., should be considered then.

Figure 2. Figure of merit for a rotor during hover.

3.7 Basics of fixed-wing aerodynamics

For the case of fixed-wing aircraft, there are some useful closed-form solutions under the assumption of inviscid and incompressible flow, especially for finite wings [Reference Anderson37]. An important value is the lift coefficient:

(11) \begin{align} {C_L} = \frac{{2L}}{{{\rho _\infty }V_\infty ^2S}} \end{align}

Where L is the lift force, $\rho $ is the flow density, V is the flight velocity, and S is the wing area. From Equation (11), using the maximum lift coefficient achievable, the stalling velocity can be obtained, which is particularly relevant when designing air tankers that will drop water or retardant:

(12) \begin{align} {V_{stall}} = \sqrt {\frac{{2W}}{{{\rho _\infty }S{C_{L,max}}}}} \end{align}

3.8 System capabilities

Stakeholders define the desired capabilities for the systems to be designed. These capabilities will constrain the requirements for new system concepts, whether they are for aircraft or any other kind. Several of the capabilities that will define the system requirements can be shared between concepts. Some capabilities to satisfy operational needs are defined and listed here, alongside the proposed requirements that will be common to all systems proposed:

1. 1. Adaptability: Ability to respond to dynamic and unforeseen changes in the environment. Common requirements for all systems include modular design for new technologies’ integration and easier manufacturing [Reference Desai and Mital38]; capable of handling various weather conditions and terrains.

2. 2. Communication: Effective use of communication protocols for coordination between different units. Common requirements for all systems include advanced communication systems for interoperability with ground units and other aircraft; encrypted communication.

3. 3. Environmental Assessment: Ability to assess and respond to environmental factors like fire magnitude and weather conditions. Common requirements for all systems include onboard sensors and cameras for monitoring in real-time fire and weather; assessment of terrain features, vegetation types and weather patterns.

4. 4. Operational Efficiency: Ability to perform its intended functions by minimising resources needed and maximising output.

5. 5. Safety and Emergency Response: Ability to respond to medical emergencies and ensure safety protocols. Common requirements for all systems include fire-resistant features to avoid degradation [Reference Ellis, Bojdo, Filippone and Clarkson39].

6. 6. Autonomy: Ability for autonomous operation with minimal human intervention.

3.8.1 Capability and requirement engineering

Capability engineering begins with an understanding of a need, and an exploration of the multiple possible functionalities to achieve a capability, which fulfils the aforementioned need [Reference Lane40]. Available resources are related to existing functions that can contribute to obtaining the new capability. Each potential solution is evaluated to measure performance and cost-effectiveness. Analyses of the SoS are used for the translation of capabilities into requirements in a repeatable and traceable manner. A clear understanding of SoS dynamics is necessary, as it will evolve, resulting in variable performance expectations. The process of translating capabilities into requirements that will support trade-off decisions for the expected level of performance against cost. The process is shown in Fig. 3.

Figure 3. Workflow of capability into requirements translation (adapted from (Reference Lane40)).

Requirements engineering is a systematic process that ensures stakeholder needs are accurately captured and translated into system specifications. To start this process, the necessary capabilities were previously translated into high-level requirements. These are decomposed into detailed functional and performance requirements. This decomposition process involves:

• • Decomposition into lower-level requirements that specify what the system must do to achieve functional and performance requirements.

• • Allocation of these requirements to specific system elements, subsystems, or components.

• • Validation of each level of requirements against stakeholder expectations.

This iterative process continues until a comprehensive set of designs to requirements is established at all levels of the system hierarchy. Traceability is crucial and necessary throughout this process, ensuring that every requirement can be linked back to a stakeholder need or higher-level capability, and that the rationale for each requirement is documented.

Managing requirements effectively involves capturing not only the requirements statements, but also associated metadata from the outset, which is necessary for clarification and linkage among requirements. A general guideline of what each should include is:

• • Requirement Statements: Clear expressions of what the system must do to achieve the desired capabilities.

• • Metadata: Information such as the requirement’s unique identifier, source, rationale, owner, verification method and verification level. These points ensure that the intent and context of each requirement are clear, enhancing communication among project stakeholders and facilitating changes when necessary.

The verification methods are beyond the scope of the present work; however, when they are documented early in the process, traceability is improved and the inclusion of any unforeseen requirements found during a verification stage is easier.

3.8.2 Logical decomposition and system architecture development

Logical decomposition is the process of breaking down a system’s required functionalities into discrete elements [Reference Hirshorn, Voss and Bromley16]. The steps in the process are:

• • Functional Analysis: Identifying and defining the functions to meet any set of desired capabilities.

• • Functional Allocation: Assigning these functions to system elements and their respective subsystems/components.

• • Interface Definition: Identifying the interfaces between system elements and/or the outside world.

This process is iterative and relies on its connection with the ConOps to guide the understanding of how a system will be used. Logical decomposition ensures that all required system behaviours are identified and that the role of each subsystem is clearly defined. With this decomposition, the system design concepts are refined through system architecture development. It is a creative and iterative process whose aspects include:

• • Concept Generation: Propose multiple design concepts that meet the project’s goals.

• • Stakeholder Involvement: Engaging stakeholders to provide feedback and ensure that the architecture and needs are aligned.

• • Analysis and Trade-off Studies: Using modelling, simulation and trade-off analyses to evaluate different design options and select the most suitable design.

The process is recursive, with feedback loops necessary to refine requirements, design solutions and provide a robust concept that meets all requirements and is feasible.

3.8.3 Technical standards considerations

Technical standards contribute to compatibility, interoperability, safety and quality while often reducing costs and development time. They provide the normalisations and guidelines that inform various aspects of system development, which, depending on the case, may include specifications for performance, safety, reliability, materials used in manufacturing, verification procedures and interfaces. Appropriate standards reduce risk and increase interoperability with other systems.

5.0 A use case scenario implementation and evaluation

This section presents the results from the interaction with the LLM and its interactions with the wildfire simulation. Due to the length of the LLM outputs, the most relevant part of the conversation has been extracted and presented here. The ConOps from Section 4.2 are given as an initial context prompt for the commander-LLM, whereas Sections 4.3 and 4.4 are given respectively to the helicopter pilot-LLM and the firefighters-LLM. The simulation driver is the human in the loop, providing prompts to the different LLMs that respectively play the role of IC, helicopter pilot, and firefighter teams and using the output to reconfigure the simulation.

LLM-Incident Commander Reply – 0

‘Initial Briefing and Intent

Task: Our primary task is to contain and control the wildfire while ensuring the safety of all personnel involved.

Purpose: The purpose of this mission is to prevent wildfire from spreading to populated areas, protect natural resources and minimise damage to property and infrastructure.

End State: The end state of this operation is to have the wildfire fully contained with no injuries to personnel, minimal damage to property and a thorough plan for monitoring and managing hotspots.

Summary of Communication Requirements:

• • Clear and complete briefings.

• • Pre-operational medical emergency planning.

• • Tactical pauses and reassessments.

• • Establish and communicate LCES (lookouts, communications, escape routes, safety zones).

• • Safe transitions between shifts.

• • Disciplined radio communication.

• • Standardised air traffic advisories and acknowledgements.

• • Integration of risk management into all phases of operations’.

Simulation Driver Prompt – 1

‘The map of a remote area is divided into coordinates from −50 to 50 in the X axis and −50 to 50 in the Y axis. A UAV is patrolling over the area, and a wildfire is reported. It is unknown how long it has been burning and its actual size. One helicopter and two firefighter teams are available in the local agency. Please state your decision and keep consistency with the IC CONOPS’.

LLM-Incident Commander Reply – 1

‘[…] Summary of Actions

• • UAV: Conduct initial fire location and assessment.

• • Brief teams: Ensure all personnel are aware of their roles, LCES, and medical plans.

• • Medical preparedness: Confirm medical personnel, equipment, and evacuation routes.

• • Deploy helicopter: For reconnaissance or water drops as needed.

• • Deploy firefighter teams: From strategic direction to create containment lines.

• • Tactical pause: Reassess the situation around 1400 hours.

• • Continuous communication: Maintain disciplined and clear radio communication’.

Simulation Driver Prompt – 2

‘The wildfire coordinates are reported to be: (−17.88, 36.07). Upon checking the map of the area, the following are the coordinates of the lakes with water available for water drops: 1) Lake A: (7, −11); 2) Lake B: (−31, 47). The entry point to the map from the helicopter is (−31,−50). Please state your decisions and how you would communicate them’.

LLM-Incident Commander Reply – 2

‘[…] Communication Plan:

• • To Helicopter Crew: ‘Helicopter team, this is Incident Command. Enter the map at (−31, −50) and proceed directly to Lake B at (−31, 47) to fill the water tanks. After filling up, head to the wildfire at coordinates (−17.88, 36.07) for water drops and aerial reconnaissance. Maintain communication on primary frequency Alpha and report any significant changes. Over’.

• • To Firefighter Team A: ‘Team A, this is Incident Command. Proceed to coordinates (−17.88, 50) and establish a line approaching the wildfire from the north. Ensure LCES is established and ready for a tactical pause at 1400 hours. Maintain communication on primary frequency Bravo and update status every 30 minutes. Over’.

• • To Firefighter Team B: “Team B, this is Incident Command. Proceed to coordinates (−17.88, −50) and establish a line approaching the wildfire from the south. Ensure LCES is established and ready for a tactical pause at 1400 hours. Maintain communication on primary frequency Bravo and update status every 30 minutes. Over’.

• • To UAV Operator: “UAV Operator, continue monitoring the wildfire and provide real-time updates on fire behaviour, spread, and intensity. Report any critical changes immediately on primary frequency, Charlie. Over’.

[…]Summary

• • Helicopter: Fill water at Lake B, perform water drops, and conduct aerial reconnaissance.

• • Firefighter Teams A and B: Approach wildfire from the north and south, respectively, ensuring safety protocols (LCES) are in place.

• • UAV: Provide continuous monitoring and updates.

• • Communication: Maintain disciplined, clear, and regular communication with all teams, ensuring updates and adjustments are communicated promptly.

Figure 7 shows the situation after following the commander’s orders. Notice the helicopter flying towards the required destination with water.

Figure 7. UAV detecting fires.

Simulation Driver Prompt – 3

The simulation continues. The helicopter pilot reports this upon reaching the wildfire: ‘Alpha frequency, Helicopter six eight x-ray (68X) arrived at coordinates (−17.88, 36.07) for water drops and aerial reconnaissance. Beginning operations now. Over’. At the same time, another fire spot has been reported by the UAV: (−19, 36)

LLM-Incident Commander Reply – 3

‘Acknowledgement and Instructions to Helicopter Pilot:

• • To Helicopter Pilot (68X): ‘Alpha frequency, this is Incident Command. Acknowledged, Helicopter 68X. Begin water drops at coordinates (−17.88, 36.07) and continue aerial reconnaissance. Be advised that a new fire spot has been reported by a UAV at coordinates (−19, 36). After initial water drops, proceed to assess and report on new fire spots. Maintain visuals on both spots and update on progress. Over’.

• • To Firefighter Team A: ‘Bravo frequency, this is Incident Command. Be advised that a new fire spot has been reported at coordinates (−19, 36) in proximity to your current target. Adjust your approach to include containment of both fire spots. Maintain LCES protocols and ensure regular status updates. Over’.

• • To Firefighter Team B: ‘Bravo frequency, this is Incident Command. Be advised that a new fire spot has been reported at coordinates (−19, 36) near the initial fire location. Adjust your approach accordingly to assist Team A in containing both fire spots. Maintain LCES protocols and ensure regular status updates. Over’.

[…]Summary of Actions

• • Helicopter 68X: Perform initial water drops, then assess and report on both fire spots.

• • Firefighter Teams A and B: Coordinate to contain both fire spots with adjusted strategies.

• • UAV: Provide detailed real-time updates and monitoring of fire behaviour for both spots.

• • Tactical Pause: Reassess the situation at 1400 hours to ensure effectiveness and safety.”

Simulation Driver Prompt – 4

Team B reports the following: ‘Command, Team B, reporting a medical emergency. Firefighter experiencing heat stroke symptoms. We need immediate medical assistance at our current location. Over’.

LLM-Incident Commander Reply – 4

‘Acknowledgement and Instructions to Helicopter Pilot:

• • To Helicopter Pilot (68X): ‘Alpha frequency, this is Incident Command. We have a medical emergency at Team B’s current location: a firefighter experiencing a heat stroke. Requesting immediate MEDEVAC (medical evacuation). Proceed to Team B’s coordinates. Secure a safe landing zone and prepare for transport. Over’.

• • To Firefighter Team A: ‘Bravo frequency, this is Incident Command. Be advised that Team B is experiencing a medical emergency. A firefighter with heat stroke symptoms. Continue current operations, but prepare to assist with medical evacuation if required. Over’.

• • To Firefighter Team B: ‘Bravo frequency, this is Incident Command. Acknowledged, Team B. Medical emergency confirmed. Immediate medical assistance will be dispatched to your current location. Ensure the firefighter is moved to a shaded area and start cooling measures immediately. Maintain hydration and monitor vital signs. Stand by for further instructions. Over’.

[…]Summary of Immediate Actions

• • Team B: Administer first aid for heat stroke, move the firefighter to a shaded area and prepare for MEDEVAC.

• • Helicopter 68X: Divert to Team B’s location for MEDEVAC, ensure safe landing and transport.

• • UAV: Provide aerial monitoring and support for MEDEVAC operations.

• • Team A: Continue firefighting operations, and remain on standby to assist with evacuation if needed.

• • All Units: Maintain clear communication and follow updated instructions from Incident Command.

Simulation Driver Prompt – 5

The helicopter is en route to Team B for evacuation. Team A is alone without aerial support from the helicopter 68X. It is possible to ask the UAVs to loiter over the firefighters and help other agencies with an additional two helicopters and three firefighter teams.

LLM-Incident Commander Reply – 5

Summary of Updated Plan of Action

• • UAV Support: Redirect UAV to provide continuous aerial support and monitoring for Team A.

• • Request Additional Resources: Contact other agencies for two additional helicopters and three firefighter teams.

• • Team A Operations: Continue firefighting efforts with UAV support, maintain LCES and report status every 15 minutes.

• • Helicopter 68X: Complete MEDEVAC, then refill water at Lake B and resume firefighting support.

• • Continuous Communication: Ensure all units maintain clear and disciplined communication, updating on status and any changes.

Simulation Driver Prompt – 6

Before this prompt, during the conversation, the LLM is informed that it can request help from other agencies. After doing so, it is informed of the following: You receive the following over the radio: ‘Command, Team A, reporting signs of severe exhaustion among crew members. Requesting immediate relief and rotation of resources. Over’. ‘Command, Team C, entering the area from point (−1,50). Over’. ‘Command, Team D, we are entering from point (−1,50). Over’. ‘Command, Team E, now entering from point (−1,50). Over’. ‘Incident Command, this is Helicopter Five Four Zulu (54Z). Entering from point (50, 8). Ready for further instructions. Over’. ‘Incident Command, this is Helicopter two one tango (21T). Entering from point (50, 8). Ready for further instructions. Over’.

LLM-Incident Commander Reply – 6

[…]To all units: ‘All units, this is Incident Command. Be advised that Team A is experiencing severe exhaustion. Teams C, D and E are now entering the area for relief and rotation. Helicopters 54Z and 21T are refilling at lakes A and B, respectively, and will provide aerial support and water drops. Maintain LCES protocols and update status regularly. Over’.

Monitor and Adjust Operations as Necessary

• • Team A: Provide immediate relief and ensure safe rotation with incoming teams.

• • Teams C, D and E: Establish LCES, focus on their assigned fire spots and ensure a smooth transition.

• • Helicopters 54Z and 21T: Conduct water drops and provide aerial reconnaissance.

• • UAV: Monitor the situation and provide real-time updates.

Summary of Updated Plan of Action

• • Team A: Immediate relief by Teams C, D and E. Ensure safe rotation and rest.

• • Teams C, D and E: Take over firefighting operations with clear focus areas and support.

• • Helicopter 54Z: Refill at Lake A, conduct water drops and provide reconnaissance.

• • Helicopter 21T: Refill at Lake B, conduct water drops and provide reconnaissance.

• • UAV Support: Monitor relief operations and fire behaviour, providing real-time updates.

• • Continuous Communication: Maintain clear and regular communication with all units, updating on the status and any changes.

Figure 8 show the final stages of the operation. The wildfire is being reduced with the different agents around it, continuing until the end of the simulation when the wildfire is completely extinguished. Notice the area where the vegetation has been removed by either fire or the work of the agents.

Figure 8. Wildfire under control.