Task 14 — International Airport and Air Traffic Network

Objective

Create a large air-traffic and airport-operations management system for a network of ten airports.

The system manages:

• airports
• runways
• terminals
• gates
• aircraft
• aircraft types
• airlines
• flights
• flight schedules
• flight legs
• passengers
• tickets
• baggage
• cargo
• pilots
• cabin crew
• crew assignments
• ground crews
• gate assignments
• runway assignments
• fuel requirements
• aircraft maintenance
• weather restrictions
• delays
• cancellations
• diversions
• rerouting
• connections
• airport capacity
• air-traffic sectors
• operational events

The implementation must coordinate resources across the entire airport network while preserving scheduling, capacity, safety, and operational constraints.

This task is intentionally large.

The goal is to model a realistic distributed transportation system where many independent entities affect each other.

Airport Network

Create ten airports:

AP01 — London
AP02 — Paris
AP03 — Frankfurt
AP04 — Madrid
AP05 — Rome
AP06 — Belgrade
AP07 — Istanbul
AP08 — Dubai
AP09 — New York
AP10 — Tokyo

Use these IDs throughout the task.

Airport

Each airport contains:

• ID
• Name
• City
• Country
• Timezone
• Terminals
• Runways
• Gates
• Maximum Hourly Arrivals
• Maximum Hourly Departures

For example:

type Airport struct {
    ID                    string
    Name                  string
    City                  string
    Country               string
    Timezone              string
    MaxHourlyArrivals     int
    MaxHourlyDepartures   int
}

Terminal

Each terminal belongs to an airport. A terminal contains:

• ID
• Airport ID
• Name
• Supported Flight Types
• Gates

Supported flight types may include:

• domestic
• international
• cargo

Gate

Each gate contains:

• ID
• Terminal ID
• Maximum Aircraft Size
• Supported Flight Types
• Status

Possible gate states:

• available
• occupied
• maintenance
• closed

A gate may only serve aircraft compatible with its size and flight type.

Runway

Each runway contains:

• ID
• Airport ID
• Length
• Supported Aircraft Categories
• Status

Possible states:

• available
• occupied
• maintenance
• closed
• weather_restricted

Aircraft Type

Aircraft types define physical and operational characteristics. A possible model:

type AircraftType struct {
    ID                 string
    Manufacturer       string
    Model              string
    PassengerCapacity  int
    CargoCapacityKg    float64
    FuelCapacityLiters float64
    MinimumRunwayM     int
    Category           string
}

Example aircraft types:

A320
A321
B737
B787
A350
B777

Aircraft

Each aircraft contains:

• ID
• Airline ID
• Aircraft Type ID
• Registration
• Current Airport
• Current Status
• Flight Hours
• Cycles

Possible states:

• available
• scheduled
• boarding
• in_flight
• maintenance
• grounded
• delayed

Airline

Create several airlines.

For example:

AL01
AL02
AL03
AL04
AL05

Each airline contains:

• ID
• Name
• Home Airport
• Aircraft Fleet

Flight

A flight represents a commercial service. For example:

type Flight struct {
    ID             string
    AirlineID      string
    FlightNumber   string
    OriginAirport  string
    DestinationAirport string
    ScheduledDeparture time.Time
    ScheduledArrival   time.Time
    AircraftID     string
    Status         FlightStatus
}

Possible states:

• scheduled
• boarding
• gate_closed
• taxiing
• departed
• in_flight
• landed
• completed
• delayed
• cancelled
• diverted

Flight Leg

A route may contain multiple legs. For example:

London -> Belgrade -> Istanbul -> Dubai

A flight itinerary may therefore contain several flight legs. A possible model:

type FlightLeg struct {
    ID               string
    FlightID         string
    OriginAirportID  string
    DestinationAirportID string
    DepartureTime    time.Time
    ArrivalTime      time.Time
}

Base Route Network

Create scheduled routes between the ten airports. At minimum, include:

AP01 <-> AP02
AP01 <-> AP03
AP01 <-> AP09

AP02 <-> AP04
AP02 <-> AP05
AP02 <-> AP06

AP03 <-> AP06
AP03 <-> AP07
AP03 <-> AP10

AP04 <-> AP05
AP04 <-> AP09

AP05 <-> AP06
AP05 <-> AP07

AP06 <-> AP07
AP06 <-> AP08

AP07 <-> AP08
AP07 <-> AP10

AP08 <-> AP09
AP08 <-> AP10

AP09 <-> AP10

The network must support both direct flights and connecting itineraries.

Airport Time Zones

Every airport has its own timezone. Flight scheduling must preserve:

• UTC timestamp
• local departure time
• local arrival time

Internal processing should use a consistent absolute time representation.

Local time should be derived for display.

Airport Capacity

Every airport has:

• maximum arrivals per hour
• maximum departures per hour

The scheduler must reject or reschedule flights that exceed airport capacity.

For example:

AP06
Max Arrivals Per Hour = 12
Max Departures Per Hour = 12

If 13 departures are scheduled inside the same operational hour:

one flight must be moved or rejected

Runway Scheduling

Every departure and arrival requires a runway slot. A possible model:

type RunwaySlot struct {
    AirportID string
    RunwayID  string
    FlightID  string
    StartTime time.Time
    EndTime   time.Time
    Operation string
}

Operation:

• takeoff
• landing

Two flights must not occupy the same runway at overlapping times.

Gate Scheduling

Flights require gate occupancy before departure and after arrival. A gate assignment contains:

type GateAssignment struct {
    FlightID   string
    AirportID  string
    GateID     string
    StartTime  time.Time
    EndTime    time.Time
}

Gate assignments must not overlap.

Aircraft Size Compatibility

Each gate supports a maximum aircraft category. For example:

• small
• medium
• widebody

An A350 or B777 must not be assigned to a gate that only supports medium aircraft.

Runway Compatibility

Each aircraft type has:

MinimumRunwayM

The airport must contain an available runway whose length is sufficient.

Aircraft Scheduling

The same aircraft cannot operate overlapping flights.

The scheduler must also consider turnaround time. For example:

        Flight A arrival: 14:00
        Minimum turnaround: 60 minutes
        Next departure: must be >= 15:00

Aircraft Turnaround

Turnaround may include:

• passenger unloading
• baggage unloading
• cleaning
• refueling
• catering
• crew change
• boarding

A possible model:

type TurnaroundRequirement struct {
    AircraftTypeID string
    MinimumMinutes int
}

Passenger

Each passenger contains:

• ID
• First Name
• Last Name
• Passport Number
• Nationality

Ticket

A ticket connects:

• Passenger
• Flight
• Seat
• Booking

For example:

type Ticket struct {
    ID          string
    PassengerID string
    FlightID    string
    Seat        string
    Status      TicketStatus
}

Possible states:

• reserved
• confirmed
• checked_in
• boarded
• cancelled
• used

Capacity Validation

The number of confirmed passengers must not exceed aircraft passenger capacity. For example:

Aircraft Capacity = 180
Confirmed Tickets = 181

must be rejected.

Booking

A passenger may book an itinerary containing multiple flights. For example:

AP06 -> AP03 -> AP10

The system must verify connection feasibility.

Connection Time

Every airport has minimum connection time. For example:

AP03 Minimum Connection Time = 50 minutes

For:

Flight 1 arrives = 10:00
Flight 2 departs = 10:35

connection is invalid.

Missed Connection

If an inbound flight is delayed and the passenger can no longer make the connection:

connection becomes missed

The system should search for an alternative route.

Baggage

Each baggage item contains:

• ID
• Passenger ID
• Flight ID
• Weight
• Current Airport
• Status

Possible states:

• checked
• loaded
• in_transit
• unloaded
• transferred
• delivered
• lost

Baggage Weight

Every ticket may have a baggage allowance. The implementation should detect excess baggage.

Baggage Connection

For connecting passengers, baggage must also transfer between flights. For example:

AP06 -> AP03 -> AP10

At AP03:

baggage must move from inbound aircraft to outbound aircraft

Cargo

Flights may carry cargo.

Cargo contains:

• ID
• Weight
• Volume
• Origin
• Destination
• Priority
• Type

Possible cargo types:

• standard
• perishable
• fragile
• medical
• hazardous

Aircraft cargo capacity must not be exceeded.

Cargo Restrictions

Some aircraft or airports may not support hazardous cargo.

The implementation must validate:

• aircraft capability
• airport handling capability
• cargo type

Pilot

A pilot contains:

• ID
• Name
• Licenses
• Certified Aircraft Types
• Maximum Duty Hours
• Current Duty Hours
• Current Status

Possible status:

• available
• assigned
• off_duty
• suspended

Cabin Crew

Cabin crew contains:

• ID
• Name
• Qualified Aircraft Types
• Maximum Duty Hours
• Current Duty Hours
• Status

Crew Assignment

Every flight requires:

• pilot
• co-pilot
• minimum cabin crew

A possible model:

type CrewAssignment struct {
    FlightID       string
    PilotIDs       []string
    CabinCrewIDs   []string
}

Crew Validation

Crew must satisfy:

• correct aircraft certification
• available during flight
• no overlapping assignment
• duty-hour limit
• minimum rest period

Duty Time

For example:

Maximum duty = 10 hours
Already used = 8 hours
New flight duty = 3 hours

assignment must be rejected.

Ground Crew

Each airport may have ground teams. Teams may handle:

• baggage
• fuel
• catering
• cleaning
• pushback
• cargo
• maintenance

A flight turnaround may require several ground-service assignments.

Fuel

Every flight requires estimated fuel. A possible simplified model:

type FuelRequirement struct {
    FlightID        string
    RequiredLiters  float64
    ReserveLiters   float64
}

Total fuel must not exceed aircraft capacity.

Airport Fuel Stock

Airports may also track fuel inventory. For example:

type FuelInventory struct {
    AirportID      string
    AvailableLiters float64
}

Refueling reduces airport fuel inventory.

Aircraft Maintenance

Aircraft maintenance may depend on:

• flight hours
• flight cycles
• calendar date
• reported defects

A possible model:

type MaintenanceRequirement struct {
    AircraftID      string
    DueFlightHours  float64
    DueCycles       int
    DueDate         time.Time
}

Maintenance State

An aircraft due for mandatory maintenance must not be scheduled for a new flight.

Aircraft Failure

An aircraft may report a technical problem before departure.

Example:

Flight F120
Aircraft AC17
Engine sensor fault

The aircraft becomes:

grounded

The system must determine whether a replacement aircraft is available.

Replacement Aircraft

A replacement aircraft must:

• belong to compatible airline pool
• support required passenger capacity
• support required cargo
• be available at departure airport
• satisfy route/runway constraints
• not have overlapping schedule

Weather

Airports may have weather conditions. For example:

type WeatherCondition struct {
    AirportID  string
    Timestamp  time.Time
    WindSpeed  float64
    Visibility float64
    Storm      bool
}

Weather Restrictions

Weather may cause:

• reduced runway capacity
• departure delays
• arrival delays
• runway closure
• airport closure

For example:

Visibility < minimum

may prevent landing for some aircraft categories.

Airport Closure Scenario

Assume:

AP07 closed from 14:00 to 18:00

due to severe weather. The system must determine:

• which departures are affected
• which arrivals are affected
• which aircraft are already in flight
• which passengers have connections through AP07
• which cargo routes use AP07

Flight Delay

A delay contains:

• Flight ID
• Original Time
• New Time
• Reason

Delay reasons may include:

• weather
• technical
• crew
• airport_capacity
• late_aircraft
• security

A delay may propagate to later flights using the same aircraft.

Delay Propagation

For example:

        Aircraft AC10
        
        Flight F1:
            arrival delayed by 90 minutes
        
        Flight F2:
            same aircraft scheduled 45 minutes after original arrival

Flight F2 must also be delayed because turnaround is no longer possible.

Cancellation

A flight may be cancelled. The system must then process:

• passengers
• baggage
• cargo
• crew assignments
• gate assignment
• runway slot
• aircraft schedule
• connections

Resources reserved for the cancelled flight must be released.

Diversion

An aircraft already in flight may be unable to land at its destination.

The system must select a diversion airport. A valid diversion airport must satisfy:

• runway length
• aircraft category
• airport status
• available arrival capacity
• fuel range

Diversion Scenario

Flight:

AP06 -> AP07

AP07 closes after departure. Candidate diversion airports:

AP03
AP05
AP08

The implementation must determine which are valid.

Route Search

The airport network must support itinerary search.

Search parameters may include:

• origin
• destination
• departure date
• maximum connections
• maximum total travel time

The system should return valid route combinations.

Direct and Connecting Routes

For:

AP06 -> AP10

possible routes may include:

AP06 -> AP03 -> AP10
AP06 -> AP07 -> AP10
AP06 -> AP08 -> AP10

The implementation must verify actual flight schedules and connection times.

Route Cost

An itinerary may be evaluated by:

• total duration
• number of connections
• price

The base task should support at least:

shortest total travel time

Passenger Rebooking

When a flight is cancelled or a connection is missed, search for a replacement itinerary.

The replacement must:

• start from current airport
• reach original destination
• have enough seat capacity
• respect connection times

Cargo Rerouting

Cargo affected by cancellation or diversion may also require rerouting.

Cargo constraints must still apply after rerouting.

Air Traffic Sector

Create logical air-traffic sectors between airport regions. A possible model:

type AirTrafficSector struct {
    ID              string
    MaxActiveFlights int
    ActiveFlightIDs []string
}

Sector Capacity

A sector must not exceed:

MaxActiveFlights

If the sector is full, new flights may need:

• delay
• alternate route
• holding

Flight Path

A flight may pass through several air-traffic sectors. For example:

AP01 -> AP09

may traverse:

sector-west-europe
sector-atlantic-east
sector-atlantic-west
sector-us-east

Holding

An arriving flight may enter a holding state when no landing slot is available.

Possible flight state:

holding

Holding increases:

• flight duration
• fuel consumption

Fuel Reserve

An aircraft must maintain reserve fuel.

A flight must not remain in holding when projected fuel would fall below required reserve. At that point:

diversion becomes mandatory

Flight State Machine

A normal flight lifecycle may be:

        scheduled
           ↓
        boarding
           ↓
        gate_closed
           ↓
        taxiing
           ↓
        departed
           ↓
        in_flight
           ↓
        landed
           ↓
        completed

Alternative states:

• delayed
• cancelled
• holding
• diverted

Invalid transitions must be rejected.

Example Invalid Transitions

Examples:

scheduled -> landed
completed -> boarding
cancelled -> departed
in_flight -> boarding

Gate Conflict Scenario

Two flights are assigned to:

Gate G12

Intervals:

Flight A: [12:00 - 13:00]
Flight B: [12:30 - 13:30]

This is invalid. The system must detect the overlap.

Runway Conflict Scenario

Two operations use the same runway:

Flight A landing: [14:00 - 14:05]
Flight B takeoff: [14:03 - 14:08]

This is invalid.

Aircraft Conflict Scenario

Aircraft:

AC20

is assigned to:

Flight F200: [10:00 - 13:00]
Flight F201: [12:00 - 15:00]

This is invalid.

Crew Conflict Scenario

Pilot:

P100

is assigned to overlapping flights. The second assignment must be rejected.

Passenger Connection Scenario

Passenger itinerary:

AP06 -> AP03 -> AP10

Flights:

F610:
    AP06 -> AP03
    08:00 - 09:30

F320:
    AP03 -> AP10
    10:30 - 22:00

Minimum connection at AP03:

50 minutes

Connection time:

60 minutes

Valid.

If F610 arrives at:

09:50

connection becomes:

40 minutes

and is no longer valid.

Passenger Rebooking Scenario

The system must search for another itinerary from:

AP03

to:

AP10

after 09:50.

Airport Operational Snapshot

Create a snapshot containing:

type AirportNetworkSnapshot struct {
    Airports         []Airport
    Flights          []Flight
    Aircraft         []Aircraft
    GateAssignments  []GateAssignment
    RunwaySlots      []RunwaySlot
    CrewAssignments  []CrewAssignment
}

A snapshot represents network state at a specific moment.

Event History

The system must preserve operational history. A possible model:

type OperationalEvent struct {
    ID         string
    Timestamp  time.Time
    EntityType string
    EntityID   string
    EventType  string
    Details    string
}

Examples:

• flight scheduled
• gate assigned
• runway assigned
• boarding started
• flight delayed
• aircraft grounded
• replacement aircraft assigned
• flight departed
• flight diverted
• flight landed
• flight completed

Idempotency

Operational commands should contain unique request IDs where duplicate processing could cause state corruption.

Examples:

• ticket purchase
• flight creation
• gate assignment
• fuel update
• maintenance completion
• baggage load event

Processing the same request twice must not duplicate the effect.

Queries

The system should support queries such as:

• all departures from airport
• all arrivals to airport
• all flights for aircraft
• all flights for passenger
• all available gates
• all available runways
• all delayed flights
• all cancelled flights
• all flights affected by airport closure
• all passengers affected by cancellation
• all missed connections
• all aircraft due for maintenance
• all crews currently assigned
• all baggage for flight
• all cargo for flight
• all active flights in air-traffic sector

Commands

State-changing operations include:

• schedule flight
• assign aircraft
• assign gate
• assign runway
• assign crew
• sell ticket
• check in passenger
• load baggage
• load cargo
• start boarding
• delay flight
• cancel flight
• depart flight
• record landing
• complete flight
• ground aircraft
• schedule maintenance
• refuel aircraft
• divert flight
• rebook passenger
• reroute cargo

Large Network Scenario

Create at least:

• 10 airports
• 5 airlines
• 30 aircraft
• 80 scheduled flights
• 250 passengers
• 100 baggage items
• 40 cargo shipments
• 40 pilots
• 80 cabin crew members

The numbers are intentionally large enough to create realistic interactions between resources.

Required Failure Scenarios

The implementation must include scenarios for:

• airport closure
• runway closure
• gate unavailable
• aircraft technical failure
• crew unavailable
• crew duty limit exceeded
• weather delay
• airport capacity exceeded
• flight cancellation
• missed connection
• aircraft schedule conflict
• gate conflict
• runway conflict
• passenger overbooking
• cargo capacity exceeded
• baggage connection failure
• fuel shortage
• holding with low fuel
• diversion
• maintenance due

Required Test Scenarios

Create tests for at least:

• valid direct flight scheduling
• valid connecting itinerary
• invalid connection time
• gate assignment
• gate overlap rejection
• runway assignment
• runway overlap rejection
• aircraft overlap rejection
• aircraft turnaround validation
• passenger-capacity validation
• cargo-capacity validation
• crew certification
• crew overlap rejection
• crew duty-time rejection
• maintenance aircraft excluded
• airport hourly capacity exceeded
• weather delay
• delay propagation
• flight cancellation
• resource release after cancellation
• passenger rebooking
• missed connection
• baggage transfer
• cargo rerouting
• airport closure
• diversion airport selection
• holding
• fuel reserve violation
• flight-state transition
• duplicate operational request

Modeling Goal

The purpose of this task is to model a complex transportation network where many independent resources and state machines interact.

A useful conceptual architecture is:

        Airport Registry
              |
              +-- Airports
              +-- Terminals
              +-- Gates
              +-- Runways
              |
              v
        Flight Scheduler
              |
              +-- Flight Plans
              +-- Aircraft Assignment
              +-- Gate Scheduling
              +-- Runway Scheduling
              |
              v
        Passenger Service
              |
              +-- Booking
              +-- Ticketing
              +-- Connections
              +-- Rebooking
              |
              v
        Baggage and Cargo Service
              |
              +-- Loading
              +-- Transfer
              +-- Capacity
              +-- Rerouting
              |
              v
        Crew Management
              |
              +-- Certification
              +-- Duty Time
              +-- Assignment
              |
              v
        Aircraft Operations
              |
              +-- Fuel
              +-- Maintenance
              +-- Turnaround
              +-- Replacement Aircraft
              |
              v
        Air Traffic Management
              |
              +-- Sector Capacity
              +-- Holding
              +-- Diversion
              +-- Airport Closure
              |
              v
        Operational Event History

The main challenge is keeping flight schedules, airport capacity, aircraft state, crew assignments, passenger connections, baggage, cargo, fuel, maintenance, and air-traffic constraints consistent across the complete network.