# PSAP Multi-Protocol AVL

## Overview

Dispatch centres rarely inherit one clean vehicle-tracking standard. One fleet may emit NMEA sentences, another may rely on legacy telematics, and specialist assets may arrive through a different provider again. The operational problem is not the existence of those feeds. It is turning them into one trustworthy, current picture for dispatch and command.

The Multi-Protocol AVL module gives the platform that translation layer. It ingests mixed position feeds, normalises them into one responder-location model, and makes those observations usable across dispatch, mapping, and command workflows without forcing an agency to replace existing hardware first.

```mermaid
flowchart TD
    A[NMEA Feed] --> D[AVL Normalisation Layer]
    B[TAIP Feed] --> D
    C[Telematics or J2540 Feed] --> D
    D --> E[Common Position and Quality Model]
    E --> F[Freshness and Direction Checks]
    F --> G[Dispatch and CAD Surfaces]
    F --> H[Maps and Command Dashboards]
    F --> I[Proximity and Nearest-Unit Queries]
```

**Last Reviewed:** 2026-04-22
**Last Updated:** 2026-04-22

## Key Features

- **Multi-Protocol AVL Ingestion**: Accept mixed legacy and modern location feeds without requiring a single fleet-wide hardware replacement.

- **Normalised Location Model**: Translate different wire formats into one consistent view of object type, position, heading, timing, and quality.

- **Live Operational Fan-Out**: Make fresh observations available to dispatch and monitoring workflows as soon as they arrive.

- **Proximity and Radius Queries**: Support operational questions such as which units are nearest to a call right now.

- **Cross-Fleet Continuity**: Keep services operational while different providers and tracking generations coexist.

- **Observation History for Review**: Preserve a normalised record of what was received and when, supporting later operational review.

## Use Cases

- **Mixed Fleet Dispatch**: A service with several AVL vendors works from one dispatch picture instead of separate tracking consoles.

- **Gradual Fleet Modernisation**: Legacy hardware can remain in service while new providers are introduced into the same operational model.

- **Nearest Appropriate Unit Selection**: Dispatchers use one normalised position view to support proximity and capability decisions.

- **Supervisory Playback**: Supervisors review a coherent location history rather than replaying multiple proprietary tools.

## Integration

- **Real-Time Dispatch and CAD**: Normalised positions support unit recommendation, dispatch review, and incident monitoring.

- **Mapping and GIS Workflows**: The same position model can drive live maps and operational overlays across the platform.

- **Vehicle Telemetry and Resource Tracking**: AVL observations become part of the wider operational awareness picture used by command and supervisors.

- **Field and Command Dashboards**: Dispatchers and commanders consume the same location context rather than vendor-specific interpretations.

## Open Standards

- **NMEA 0183**: supports one of the most common open GPS and AVL wire formats used by vehicle and device trackers.

- **SAE J2540**: supports emergency and fleet telematics environments that exchange tracking data using the J2540 format.

- **ETSI TS 102 708**: supports standards-based location and telematics ingestion from European-style tracking environments.

- **TAIP**: supports legacy telematics deployments that still report position using the Trimble ASCII Interface Protocol.

- **OGC SensorThings API**: compatible publication of normalised observations supports open geospatial and sensor-fusion workflows.

- **WGS 84 / EPSG:4326**: all normalised positions use the common latitude and longitude reference model expected by modern mapping systems.
