{"id":"psap-multi-protocol-avl","slug":"psap-multi-protocol-avl","title":"PSAP Multi-Protocol AVL","description":"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 oper","category":"geospatial","tags":["geospatial","ai"],"lastModified":"2026-04-22","source_ref":"content/modules/psap-multi-protocol-avl.md","url":"/developers/psap-multi-protocol-avl","htmlPath":"/developers/psap-multi-protocol-avl","jsonPath":"/api/docs/modules/psap-multi-protocol-avl","markdownPath":"/api/docs/modules/psap-multi-protocol-avl?format=markdown","checksum":"c5809929e23632a1e640389dcf45906e6d842339cb9dcbe69dc1ed1880f7a2cb","headings":[{"id":"overview","text":"Overview","level":2},{"id":"key-features","text":"Key Features","level":2},{"id":"use-cases","text":"Use Cases","level":2},{"id":"integration","text":"Integration","level":2},{"id":"open-standards","text":"Open Standards","level":2}],"markdown":"# PSAP Multi-Protocol AVL\n\n## Overview\n\nDispatch 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.\n\nThe 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.\n\n```mermaid\nflowchart TD\n    A[NMEA Feed] --> D[AVL Normalisation Layer]\n    B[TAIP Feed] --> D\n    C[Telematics or J2540 Feed] --> D\n    D --> E[Common Position and Quality Model]\n    E --> F[Freshness and Direction Checks]\n    F --> G[Dispatch and CAD Surfaces]\n    F --> H[Maps and Command Dashboards]\n    F --> I[Proximity and Nearest-Unit Queries]\n```\n\n**Last Reviewed:** 2026-04-22\n**Last Updated:** 2026-04-22\n\n## Key Features\n\n- **Multi-Protocol AVL Ingestion**: Accept mixed legacy and modern location feeds without requiring a single fleet-wide hardware replacement.\n\n- **Normalised Location Model**: Translate different wire formats into one consistent view of object type, position, heading, timing, and quality.\n\n- **Live Operational Fan-Out**: Make fresh observations available to dispatch and monitoring workflows as soon as they arrive.\n\n- **Proximity and Radius Queries**: Support operational questions such as which units are nearest to a call right now.\n\n- **Cross-Fleet Continuity**: Keep services operational while different providers and tracking generations coexist.\n\n- **Observation History for Review**: Preserve a normalised record of what was received and when, supporting later operational review.\n\n## Use Cases\n\n- **Mixed Fleet Dispatch**: A service with several AVL vendors works from one dispatch picture instead of separate tracking consoles.\n\n- **Gradual Fleet Modernisation**: Legacy hardware can remain in service while new providers are introduced into the same operational model.\n\n- **Nearest Appropriate Unit Selection**: Dispatchers use one normalised position view to support proximity and capability decisions.\n\n- **Supervisory Playback**: Supervisors review a coherent location history rather than replaying multiple proprietary tools.\n\n## Integration\n\n- **Real-Time Dispatch and CAD**: Normalised positions support unit recommendation, dispatch review, and incident monitoring.\n\n- **Mapping and GIS Workflows**: The same position model can drive live maps and operational overlays across the platform.\n\n- **Vehicle Telemetry and Resource Tracking**: AVL observations become part of the wider operational awareness picture used by command and supervisors.\n\n- **Field and Command Dashboards**: Dispatchers and commanders consume the same location context rather than vendor-specific interpretations.\n\n## Open Standards\n\n- **NMEA 0183**: supports one of the most common open GPS and AVL wire formats used by vehicle and device trackers.\n\n- **SAE J2540**: supports emergency and fleet telematics environments that exchange tracking data using the J2540 format.\n\n- **ETSI TS 102 708**: supports standards-based location and telematics ingestion from European-style tracking environments.\n\n- **TAIP**: supports legacy telematics deployments that still report position using the Trimble ASCII Interface Protocol.\n\n- **OGC SensorThings API**: compatible publication of normalised observations supports open geospatial and sensor-fusion workflows.\n\n- **WGS 84 / EPSG:4326**: all normalised positions use the common latitude and longitude reference model expected by modern mapping systems.\n"}