Military Airfields / Visual NAVAIDs

Visual NAVAIDs

Reporting an outage auto flags a lighting system the moment it falls below minimums and provides required actions with draft NOTAM verbiage.

Request a demoDAFMAN 13-204 V2, Table A3.1

The problem

Homegrown Excel documents or incomplete records for calculating lighting system outages.

A lighting outage is never just one light. The question that matters is whether the system as a whole still meets the threshold the regulation sets for it, and answering that by hand means knowing every fixture on the system, what percentage is out, and whether adjacent lights are dark at the same time.

Most airfields track that in someone's head or in a spreadsheet that inevitably breaks the moment someone changes the data. The Airfield Manager who knows every circuit eventually PCSes, and the program's memory leaves with them.

How it works

The airfield, fixture by fixture

  1. 01

    Your lighting depicted on satellite imagery

    Every light and sign sits at its surveyed position on a satellite map of your airfield, imported from GeoData or built manually with the in-app editor.

  2. 02

    Click the fixture, report the outage

    Reporting happens on the map, not in a form. Pick the fixture as you sit next to it, mark it out, add a note. Done from a vehicle on the field on a mobile device, tablet or desktop.

  3. 03

    Thresholds evaluated the moment you report

    Glidepath recomputes the system's outage percentage against its DAFMAN 13-204 V2 Table A3.1 threshold, and tells you what actions are required per the table's "NOTES" column.

  4. 04

    The paperwork starts itself

    An outage that warrants action auto-creates a discrepancy assigned to maintenance, and the alert lays out the notification decision for the Airfield Manager.

Visual NAVAIDs satellite map with lighting systems plotted
The Visual NAVAIDs map for a demo airfield: 1,387 lighting fixtures plotted over satellite imagery of the runway and parallel taxiway, with the status bar reporting 39 inoperative and two fixtures near a taxiway junction circled in red to flag the outage.

Built on the regulation

The citation, implemented

  • DAFMAN 13-204 V2, Table A3.1

    The outage engine implements the table's per-system serviceability thresholds: the evaluation an Airfield Manager otherwise performs by hand.

The benefit

What it automates

Threshold detection, instantaneously

The evaluation runs on every report the second an outage is found. Instantly locates outages without the confusion of providing location descriptions.

One report, whole workflow

Outage → tier alert → discrepancy → maintenance assignment in one action, with the trail preserved for the record.

The program survives turnover

System layouts, thresholds, and outage history live in the platform, not in one person's memory. No more broken spreadsheets.

Related

Works alongside

FAQ

Straight answers

How does the airfield map get built?

Two ways: import from GeoData (base GeoBase officer, Google Earth, QGIS), or place fixtures manually with the built-in editor. Either way the result is your airfield: real imagery, surveyed positions.

Does an outage automatically create a work order?

Reporting an outage on the map auto-creates a discrepancy and assigns it to maintenance personnel, so the fix starts moving the moment the outage is known.

Does Glidepath decide notifications for me?

It computes the regulatory tier and presents the decision with the numbers in front of you. The call stays with the Airfield Manager.

What about adjacent lights out on the same bar?

Bar-out detection is part of the evaluation: the engine flags adjacent-fixture conditions that trip a threshold even when the raw percentage alone would not.