7.1 Computer Aided Dispatch (CAD) System Architecture

7.1 Computer Aided Dispatch (CAD) System Architecture

Quick Answer: The Computer Aided Dispatch (CAD) system is the central operational engine of the Public Safety Communications Center (ECC/PSAP). Transitioning from legacy mainframe silos to resilient multi-tier client-server and cloud architectures backed by enterprise Relational Database Management Systems (RDBMS), CAD platforms must satisfy the public safety 99.999% ("five nines") availability standard—permitting no more than 5.26 minutes of unscheduled downtime annually. CAD clusters rely on active-active or active-passive database replication governed by a Quorum Witness to prevent split-brain data corruption. Location validation is executed by real-time GIS geocoding engines evaluating authoritative NG911 address points and road centerlines via phonetic and fuzzy matching algorithms. Unit recommendation has transitioned from rigid, station-based static run cards to dynamic Closest Unit Dispatch (CUD) leveraging Automatic Vehicle Location (AVL) GNSS telemetry and drive-time isochrones that calculate network routing across real-world road geometry and live traffic conditions.

---

1. CAD System Evolution & Multi-Tier Architecture

Historically, emergency dispatching was conducted with physical status cards, punch-clocks, and roller-track conveyor belts that physically transported paper tickets from telephone operators to radio dispatchers. The advent of computing introduced first-generation monolithic mainframes in the 1970s and 1980s. While revolutionary, these early mainframes suffered from single-vendor lock-in, rigid terminal displays, and catastrophic single points of failure.

Modern public safety operations demand modular, distributed multi-tier (n-tier) client-server architectures deployed on-premises across high-availability virtualization clusters, in private municipal clouds, or hosted within FedRAMP-authorized, CJIS-compliant public safety cloud platforms (such as AWS GovCloud or Microsoft Azure Government).

                    CAD MULTI-TIER SYSTEM ARCHITECTURE

  [PRESENTATION TIER: CLIENT WORKSTATIONS & FIELD DEVICES]
   • Dispatcher Consoles (Multi-Monitor Desktop GUIs)
   • Call Taker Telephony Integrations (CPE Softphones)
   • Mobile Data Terminals (MDTs / MDCs in Apparatus)
   • Administrative & Supervisor Monitoring Consoles
                          │
                          ▼  (Encrypted HTTPS / WebSockets / TLS)
  [APPLICATION & BUSINESS LOGIC TIER: SERVICES & ENGINES]
   • Incident Intake & Nature Code Prioritization Engine
   • Real-Time GIS Geocoding & Boundary Intersection Engine
   • Dynamic Closest Unit Dispatch (CUD) & Isochrone Router
   • External Interface Broker (CAD2CAD, RMS, CJIS, Alerting)
                          │
                          ▼  (FIPS 140-2/3 Validated Encrypted DB Links)
  [DATA PERSISTENCE TIER: ENTERPRISE CLUSTERED RDBMS]
        ┌─────────────────┴─────────────────┐
        ▼                                   ▼
 [Primary Node (Active)] <──Heartbeat──> [Secondary Node (Active/Passive)]
        └─────────────────┬─────────────────┘
                          ▼
              [Quorum Witness / Storage]

The Three Core Tiers

1. Presentation Tier (Client Layer): Workstation Graphic User Interfaces (GUIs) deployed across telecommunicator dual- or quad-monitor consoles, supervisor dashboard stations, and ruggedized in-vehicle Mobile Data Terminals (MDTs). The presentation tier captures user keyboard commands, renders live mapping layers, displays call queues, and formats alerts without executing computational business logic.
2. Application / Business Logic Tier: The computational brain of CAD. Operating across clustered application server nodes, this tier executes system rules: evaluating event priority schemes, calculating agency dispatch configurations, querying GIS spatial layers, running unit recommendation algorithms, and translating external messaging protocols. Isolating business logic from client workstations ensures that if an individual desktop crashes, no pending incidents or dispatch queues are impacted.
3. Data Persistence Tier (Database Layer): High-performance enterprise Relational Database Management Systems (RDBMS)—principally Microsoft SQL Server, Oracle Database, or enterprise PostgreSQL. The persistence tier manages transactional integrity, operational logging, spatial indices, and historical archives.

Relational Database Engines & ACID Compliance

Emergency dispatch environments cannot tolerate partial transactions or ambiguous database writes. If a dispatcher assigns Engine 1 to a working structure fire, that unit must simultaneously show as committed across all workstations, mobile terminals, and external logging feeds. Enterprise CAD databases enforce strict ACID compliance:

• Atomicity: Transactions are all-or-nothing. If a CAD transaction requires updating unit status, assigning an incident number, and generating an alert record, all three actions commit together. If network connectivity fails midway, the entire transaction rolls back to the prior clean state.
• Consistency: All data written to disk must conform to defined database schemas, relational integrity rules, and constraint validations (e.g., preventing the creation of an incident without a verified location or assigning a non-existent unit).
• Isolation: Concurrent transactions executed by dozens of telecommunicators execute independently without cross-session interference or data locking deadlocks.
• Durability: Once a transaction commits, it is permanently recorded in non-volatile storage and transaction logs, surviving subsequent server crashes or power failures.

---

2. High Availability, Failover Clustering & Business Continuity

In public safety telecommunications, CAD failure can directly lead to lost lives. The accepted national benchmark for public safety systems is 99.999% availability ("five nines").

$\text{Unscheduled Downtime} = (1.0 - 0.99999) \times 365.25 \times 24 \times 60 = 5.2596 \text{ minutes/year}$

Achieving five nines permits less than 5.26 minutes of unplanned downtime across an entire calendar year. Achieving this standard requires automated database failover clustering.

Active-Active vs. Active-Passive Clustering

Agencies architect database resilience using either active-passive or active-active topology:

The Split-Brain Hazard & Quorum Witness Models

In clustered server environments, nodes continuously exchange high-speed heartbeat packets across dedicated, redundant network interconnects to monitor mutual health. If an internal network switch fails or physical cabling severs while both server nodes remain fully operational, a critical failure mode known as Split-Brain occurs.

In a split-brain condition, both server nodes detect the absence of the other's heartbeat and simultaneously conclude that the partner has died. Both nodes attempt to mount the production database, bind the virtual cluster IP address, and accept read/write transactions from different segments of the PSAP network. This results in catastrophic, unrecoverable database corruption, where conflicting incident numbers and unit assignments are written independently to partitioned storage.

                      SPLIT-BRAIN FAILURE & QUORUM MITIGATION

   [Primary Node 1] ───X─── [Heartbeat Link Severed] ───X─── [Secondary Node 2]
   (Believes Node 2 is dead)                                 (Believes Node 1 is dead)
          │                                                               │
          │                QUORUM WITNESS ARBITRATION                     │
          ▼                       (Majority Vote)                         ▼
   Attempts to seize       ┌────────────────────────────┐          Attempts to seize
   Active Production ◄────┤   INDEPENDENT QUORUM       ├─────►   Active Production
   Status                 │   WITNESS (VOTE = 1)       │          Status
                          └─────────────┬──────────────┘
                                        │
                  Node 1 + Witness = 2 Votes (Majority: 2 of 3)
                  Node 1 WINS: Continues live dispatch production.
                  Node 2 = 1 Vote (Minority): Automatically demounts services.

To prevent split-brain states, high-availability clusters enforce a strict Quorum Voting Model utilizing an independent third entity called a Quorum Witness (configured as a dedicated Disk Witness, a network File Share Witness, or a Cloud-based Witness):

• The Majority Rule: A partition can only assume active production status if it secures a strict majority of available cluster votes: $\text{Quorum Majority} = \left\lfloor \frac{N}{2} \right\rfloor + 1$ In a two-node cluster with one witness ($N = 3$), a partition must achieve at least 2 votes to operate.
• Failsafe Demount: If the network partition severs the heartbeat, Node 1 queries the witness. If Node 1 locks the witness, it secures 2 of 3 votes and remains active. Node 2, unable to lock the witness, achieves only 1 vote (a minority) and automatically demounts its database engines, terminating client listeners to preserve data integrity.

RPO and RTO Public Safety Benchmarks

• Recovery Time Objective (RTO): The maximum tolerable duration of system outage from the moment of failure until full CAD operational functionality is restored. For primary CAD dispatch, the operational target is under 60 seconds (with active-active targeting sub-second recovery).
• Recovery Point Objective (RPO): The maximum tolerable age of data lost when recovery occurs following a catastrophic failure. In public safety dispatch, the RPO is zero seconds ($RPO = 0$). Losing an emergency incident record or an officer distress call is legally and operationally intolerable; hence, database replication across local high-availability nodes must be synchronous.

---

3. Incident Intake, Nature Codes & Priority Stratification

Incident creation is the operational gateway of CAD. When a call arrives, the intake workflow captures, validates, and structures critical data into an unalterable incident record.

[Emergency Call Arrives via CPE] ──► [Automated ALI Spill Parsing]
                                              │
                                              ▼
[Raw Street Text & Lat/Long] ──► [Real-Time GIS Geocoding Engine]
                                              │
                                              ▼
[Address Verified & Jurisdiction Determined (Law / Fire / EMS)]
                                              │
                                              ▼
[Telecommunicator Selects Nature Code] ──► [Automatic Priority Assigned (1 to 5)]
                                              │
                                              ▼
[Pending Incident Created] ──► Injected into Active Dispatcher Console Queues

Call Categorization & Nature Codes

CAD systems utilize standardized nature codes (event type identifiers) to define the fundamental character of the incident (e.g., STRUCTURE_FIRE_COMMERCIAL, VEHICLE_ACCIDENT_ROLLOVER, ROBBERY_ARMED_IN_PROGRESS, CARDIAC_ARREST). The assigned nature code binds directly to:

• Automated Dispatch Profiles: Pre-configured minimum equipment requirements (e.g., an armed robbery code automatically requests 2 primary patrol units, 1 secondary cover unit, and 1 field supervisor).
• Pre-Arrival Instructions (PAI): Direct programmatic links to emergency medical, fire, or police dispatch protocol software (such as EMD, EFD, or EPD protocols).
• Response Speed Modifiers: Automatic instructions governing emergency vehicle response modes (e.g., Code 3 / Hot with lights and sirens vs. Code 1 / Cold following standard traffic rules).

Priority Stratification

CAD suites classify incidents across a numerical priority hierarchy that controls how records sort visually on telecommunicator screens and which calls prompt automated audible alerts:

CAD Incident Queues

CAD systems segregate operational data into specialized real-time queues:

1. Pending Queue: Calls that have been created and geocoded by call takers but have not yet been assigned to field units. Sorting is governed strictly by numerical priority, followed by elapsed hold time.
2. Active / Dispatched Queue: Incidents where field units have been assigned and are currently EN_ROUTE, ON_SCENE, or STAGED.
3. Holding / Deferred Queue: Non-emergent incidents intentionally placed in a delayed status due to regional resource depletion, major storm activity, or pending complainant callbacks.

---

4. Real-Time GIS Geocoding Engines & Address Verification

Historically, CAD systems verified street addresses against tabular text databases—principally the Master Street Address Guide (MSAG). The MSAG contained only text strings representing street segments and low/high address ranges. It possessed no spatial awareness: it could not identify where along a roadway an address was located, could not determine whether an incident was on the north or south side of an expressway, and could not visualize building shapes.

Modern CAD systems rely on real-time geospatial geocoding engines integrated with authoritative GIS datasets conforming to NENA-STA-006 (NENA NG9-1-1 GIS Data Model).

                      GEOSPATIAL GEOCODING ENGINE WORKFLOW

  [Caller Location Input: "1424 West Elm St"] ──► [Input Normalization & Parsing]
                                                          │
        ┌─────────────────────────────────────────────────┴─────────────────────────────────────────────────┐
        ▼                                                                                                   ▼
[PRIMARY: Address Point Match]                                                      [FALLBACK: Road Centerline Interpolation]
Query Site/Structure Address Points (SSAP)                                          Match Road Centerline Layer: Elm St
 • Exact parcel or rooftop centroid verified                                         • Check parity: Even number
 • Centimeter-level geodetic coordinate returned                                     • Evaluate range interval: 1400 - 1498
 • Immediate validation to CAD incident                                              • Linearly interpolate point at ~24% along vector
        │                                                                                                   │
        └────────────────────────────────────────┬──────────────────────────────────────────────────────────┘
                                                 │
                                                 ▼
                              [SPATIAL POINT-IN-POLYGON INTERSECTION]
                               • Police Precinct / Beat Polygon Boundary
                               • Fire Station Response District Polygon
                               • EMS Ambulance Operating Zone Polygon
                                                 │
                                                 ▼
                        [CAD POPULATES AUTHORITATIVE RESPONDING AGENCIES]

Authoritative GIS Layers in CAD

1. Site/Structure Address Points (SSAP): The gold standard of location verification. An SSAP is a high-precision point feature placed directly upon the rooftop centroid, physical structure footprint, or primary driveway access of a building. It matches sub-address elements (apartment numbers, suite designators, building wings) directly to an exact geodetic coordinate.
2. Road Centerlines with Address Ranges: Linear vector geometries representing the physical center of roadways. Each segment contains directional prefixes, standardized street names, street types, directional postfixes, and four critical numerical attributes: Left-From, Left-To, Right-From, and Right-To. If an exact SSAP does not exist (e.g., new construction), the geocoding engine performs linear interpolation along the centerline segment.
3. Jurisdictional & Emergency Service Zone (ESZ) Polygons: Boundary layers defining the statutory geographic limits of law enforcement beats, fire stations, and EMS squads. Once the engine establishes the coordinates, it executes a spatial Point-in-Polygon (PIP) calculation to identify which polygon contains the point, instantly binding the correct responding agencies to the incident.

Geocoding Resolution Algorithms

Callers rarely provide perfectly standardized addresses. When telecommunicators type informal, misspelled, or colloquial data, the CAD geocoding engine invokes specialized algorithms:

               ALGORITHMIC RESOLUTION OF AMBIGUOUS ADDRESSES

  [Raw Input: "Smythe and Main"] 
         │
         ├──► [PHONETIC MATCHING: Soundex / Metaphone]
         │     Converts "Smythe" -> S530; Matches database street "Smith" (S530)
         │
         ├──► [FUZZY STRING MATCHING: Levenshtein Distance]
         │     Calculates edit distance: Smythe -> Smith (Distance = 2)
         │
         ├──► [INTERSECTION PARSING: Topological Cross-Street Tables]
         │     Identifies node where "Smith St" physically crosses "Main St"
         │
         └──► [COMMON PLACE NAME / ALIAS TABLES]
               Input "City Park Pool" resolves to "800 E Washington Blvd"

• Phonetic Matching (Soundex & Double Metaphone): Soundex indexes words by sound rather than spelling, reducing a name to a four-character code consisting of a letter followed by three numerical digits (e.g., "Smythe" and "Smith" both yield S530). Double Metaphone improves upon Soundex by accounting for complex Slavic, Germanic, and Hispanic vowel and consonant variances.
• Fuzzy String Matching (Levenshtein Distance): Measures the minimum number of single-character edits (insertions, deletions, substitutions) required to transform the typed string into a valid database entry. A telecommunicator typing "JEFRSN" matches "JEFFERSON" with a low edit distance, prompting the CAD to suggest the verified name.
• Intersection & Landmark Parsing: Resolves street junctions by evaluating node connectivity in the centerline vector layer. Common place-name alias tables match colloquial landmarks ("Walmart North", "Central High Stadium", "Mile Marker 142.5 WB") directly to validated civic locations.

---

5. Automated Unit Recommendation Engines: Run Cards vs. Dynamic CUD

Once an incident is verified, the CAD recommendation engine must identify and display the optimal field resources for assignment.

                         UNIT RECOMMENDATION ENGINE
                                     │
        ┌────────────────────────────┴────────────────────────────┐
        ▼                                                         ▼
[STATIC RUN CARDS / BOX ALARMS]               [DYNAMIC CLOSEST UNIT DISPATCH (CUD)]
 • Tabular lookup matrices                     • Real-time GNSS/AVL tracking
 • Fixed station assignment order              • Drive-time isochrones across road network
 • Assumes units are in home quarters          • Real-time traffic, bridge limits, turns
 • Inflexible to real-time unit movements      • True fastest-arriving capable unit

Static Run Cards (Box Alarms)

Historically, fire and EMS dispatching relied on physical or electronic Run Cards (often referred to as Box Alarms). A run card is a static, pre-determined lookup table configured by department leadership:

• The service area is subdivided into geographic response boxes (often 1 to 2 square miles).
• For each box and alarm tier (1st Alarm, 2nd Alarm, Working Fire), the run card specifies a rigid sequence of stations or apparatus (e.g., 1st Due Engine: Station 1; 2nd Due Engine: Station 5; 1st Due Ladder: Station 1; Battalion Chief: Battalion 2).
• Critical Operational Flaw: Static run cards assume apparatus are always parked in their home firehouses. If Engine 5 is returning from training and is parked 300 yards from the fire, but Station 1 is the 1st due on the card (located 2.5 miles away), the static system will recommend Engine 1. This introduces unnecessary response delays.

Dynamic Closest Unit Dispatch (CUD) with Automatic Vehicle Location (AVL)

Modern CAD systems employ Closest Unit Dispatch (CUD) driven by continuous Automatic Vehicle Location (AVL) telemetry:

• In-vehicle GNSS receivers continuously transmit geodetic coordinates, speed, heading, and status to CAD over mobile broadband.
• When an incident occurs, the engine evaluates the live physical coordinates of all units possessing the required capability (e.g., paramedic-certified ALS engines).
• The unit with the shortest calculated arrival time is recommended first, regardless of municipal boundaries or home station territories.

Euclidean Distance vs. Drive-Time Isochrones

ENP candidates must understand why CAD systems cannot calculate unit proximity using simple Euclidean distance (straight-line, "as-the-crow-flies" distance):

$\text{Euclidean Distance: } d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}$

Euclidean calculations assume an infinite, flat, unobstructed plane. In real-world urban and rural geographies, Euclidean calculations produce dangerous dispatch errors:

                    EUCLIDEAN DISTANCE vs. DRIVE-TIME ISOCHRONE

  [Patrol Car A] ──── 1.5 Miles Straight-Line ────► [EMERGENCY SCENE]
        │                                                 ▲
        │ (Trapped behind unbridged river gorge;          │ (Open 4-lane expressway)
        │  requires 8-mile detour = 16 Minutes)           │
        ▼                                                 │
                                                          │
  [Patrol Car B] ───────────── 3.8 Miles Road Network ────┘
                               (Travel time = 4 Minutes)

  • Euclidean Engine Recommends: Patrol Car A (1.5 mi vs 3.8 mi) -> ARRlVES IN 16 MIN
  • Isochrone Engine Recommends: Patrol Car B (Calculates Road Mesh) -> ARRIVES IN 4 MIN

To achieve true operational efficiency, CAD recommendation engines calculate Drive-Time Isochrones (spatial polygons representing equal travel times) using shortest-path graph traversal algorithms (such as Dijkstra's or A* algorithms) across a fully topologically connected vector street network. The engine evaluates:

1. Road Network Hierarchy & Speeds: Distinguishes between interstate freeways (65 mph), arterial boulevards (45 mph), residential streets (25 mph), and unpaved rural tracks (15 mph).
2. Turn Restrictions & Geometric Prohibitions: Models one-way street grids, divided median barriers, "No Left Turn" intersections, and impassable cul-de-sacs.
3. Physical Apparatus Constraints: Fire apparatus cannot traverse roads with low overhead bridge clearances (under 12 feet) or cross bridges with restrictive gross vehicle weight limits (e.g., a 40-ton ladder truck cannot cross a 10-ton rural timber bridge).
4. Dynamic Environmental Telemetry: Ingests live traffic feeds, road construction detours, railroad grade crossing blockages, and severe weather snow routes.

---

6. Operational Traps & ENP Exam Watch

• Availability Benchmark Calculations: Memorize that the 99.999% ("five nines") availability standard translates mathematically to less than 5.26 minutes of unplanned downtime per calendar year.
• Split-Brain Mechanism: On the examination, identify the Quorum Witness (operating under the $\lfloor N/2 \rfloor + 1$ majority rule) as the technical arbiter that prevents split-brain database corruption when server heartbeat links fail.
• RTO vs. RPO: RTO is the duration required to restore operational computing services following a disaster (time to recover). RPO is the maximum allowable age of lost transactional data (point in time of data loss). Public safety CAD demands an $RPO = 0$.
• Euclidean Routing Fallacy: Euclidean distance calculates straight-line spatial separation ($d = \sqrt{\Delta x^2 + \Delta y^2}$) and completely ignores rivers, bridge crossings, one-way streets, apparatus weight ratings, and traffic. Real-world dispatching mandates drive-time isochrones based on topologically connected street networks.
• MSAG vs. SSAP Geocoding: The legacy MSAG is a tabular text range lookup that lacks spatial coordinates. NG911 CAD geocoding relies on Site/Structure Address Points (SSAP) and road centerlines, resolving names via phonetic algorithms (Soundex) and fuzzy string matching.