Military Airfield Pavement Inspection by Drone

Who runs into this

The Pavement Condition Index is a military method before it is a civil one. It was developed by the US Army Corps of Engineers with US Air Force funding, and the FAA and the Naval Facilities Engineering Command adopted it afterwards. A military airfield therefore already has the vocabulary: sections, sample units, a walked ASTM D5340 survey, and a pavement management system , usually PAVER, that turns the survey into a work plan. What it often lacks is a look at the whole surface between two walked surveys.

It shows up in three questions.

• Which of the D5340 distress types can an automated survey actually record, and which still need a rater on foot?
• Can two surveys a year apart be compared section by section, so that a change in the figure is a change in the pavement and not in the method?
• Can the survey run on an installation that keeps operational data inside the perimeter, or on a remote airfield with no network and little time on the pavement?

The pavement condition assessment is the service behind this page. It is not offered yet and is in active development, and its pavement processing is a working prototype close to a first MVP. The runway pavement check covers the lighter recurring look. This page sets out what the platform already does, what the prototype adds, and what it does not do yet.

Where this applies, and where it does not

This applies to paved runways, taxiways and aprons that are rated by the D5340 method, asphalt and jointed concrete alike, whether or not the airfield is civil. It applies most where the walked survey is sampled and infrequent, where the pavement is ageing, and where an evaluation team wants to test the prototype on its own sections.

It does not replace the walked survey where a requirement names it. It does not assess structural capacity, which needs deflection testing or coring, and it does not measure friction or roughness, which D5340 excludes by its own scope. And it does not see through water, snow or contamination on the day.

What the platform already does

Survey flights and capture between movements

The service is in active development and not offered yet. The platform already plans the flights and captures the imagery. The survey is planned from the surfaces in scope and flown in overlapping passes in the windows air traffic control opens between aircraft movements. Every agreed runway, taxiway and apron is imaged, not a sample of units. Capture takes about an hour of flying per kilometre of a 45 m wide runway, plus battery changes, with taxiways and aprons adding time in proportion to their area.

The imagery is retained with RTK positions to about ±1 cm. If an engineer disputes a section, it is re-examined against those frames rather than re-flown, and the same frames can be processed again when the detection model improves.

Capture on a closed network

For installations whose rules keep operational data inside the perimeter, and for remote or temporary airfields with no usable connection at the pavement, there is an offline field deployment. A field laptop serves the app on a local network on the airfield with offline map tiles, so the survey is planned and flown and the imagery stays on site with nothing uploaded. The offline workflow is described in full elsewhere.

The field laptop does not run the pavement processing. That runs on a separate GPU machine, as described below, so where and when the imagery is processed is agreed per installation.

Weather and surface state

Results are best on a calm, sunny day. High wind blurs the images and low light forces a high ISO, so harsher conditions are flown with an adjusted, slower surface-scan configuration rather than ruled out. Standing water, snow cover and heavy contamination hide the surface, and a pass over them is reflown once the surface is clear rather than rated through. This page states no temperature, wind or ingress rating.

The surface at survey resolution. Cracking reads as a shadow line and raveling as texture loss, which is why sun on the pavement helps where the movement windows allow it.

The prototype: crack detection coded to D5340

The pavement processing is a working prototype in development, close to a first MVP. It runs on the orthomosaic built from the survey imagery. A detection model marks each crack, and a set of rules turns the detected cracks into ASTM D5340 distress codes.

• 41, alligator cracking , on asphalt.
• 43, block cracking, on asphalt.
• 48, longitudinal and transverse cracking, on asphalt.
• 63, linear cracking, on concrete.

The system also recognises grass, patches and debris. All three are in development and short of training data, and none is coded as a D5340 distress.

The output is a section and sample-unit inventory as GeoJSON, with a JSON or Markdown report keyed by section and sample-unit ID. The processing runs on a separate GPU machine, not on the field laptop. Because the imagery is kept, an earlier survey can be re-run on a newer model, which is a manual step today. Where an evaluation team has a day on the airfield, the inventory can be read before the walk to see where cracking is concentrated, while the walked units are still chosen by the sampling rules.

What it does not do yet

• D5340 coding of anything beyond those four. Patches are recognised but not coded, and the system does not classify raveling , weathering, jet blast erosion, oil spillage, joint seal damage, joint spalling , corner spalling and scaling.
• Rutting or depression depth. Both are geometry, and no surface model is built.
• A condition index of any kind, PCI or otherwise.
• Comparison between surveys.
• Import into PAVER.

Where the walked D5340 survey is required, it remains the record. Severity criteria that need touch, such as whether a sealant is still bonded to the joint face, anything below the surface, and calls the standard leaves to a trained rater’s judgement all belong to it. Loose material is a foreign object debris question rather than a pavement defect, because it has a different owner and a different clock.

Keeping a later survey comparable

A condition record is useful once. A change in it is what a work plan runs on, and a change only means something if nothing else moved. TarmacView does not compare surveys yet, but three things can be held fixed from the first one.

• The section boundaries. They are agreed at scoping, ideally as the installation’s existing sections, and kept. A boundary moved between surveys breaks the record for every section it touches, so moving one is a decision with a cost, not an edit.
• The identifiers. The prototype keys its inventory to section and sample-unit IDs, so keeping the IDs keeps two inventories readable against each other. The DoD evaluation manual and PAVER use a network, branch and section structure, which the prototype does not import yet.
• The retained imagery. The frames behind every inventory are kept. When the detection model is updated, an earlier survey can be re-run on its imagery so two surveys are read on one model.

A walked survey that samples units can drift between cycles in which units are walked and in who rates them. The DoD manual is explicit that the evaluator’s most important task is identifying the correct distress type and severity. Whole-surface imagery removes the sampling drift from the capture, and the rater’s judgement stays with the walked survey where it belongs.

How a survey runs

The first survey sets the section map that every later one reuses, so the first step matters most.

The same mission on every visit, generated from the surface geometry, so a later survey covers the same ground as the first.

Governance and the record

A PCI is a statement about a defined area, and the record behind it is what makes it defensible. The DoD evaluation manual keys every pavement record to a network, branch and section identifier, and describes cursory inspections, the kind done when time is short, as valid for limited or immediate use only. Retained, positioned imagery is a dated record of the surface, and the prototype’s inventory is keyed to section and sample-unit IDs. Neither changes which survey a requirement asks for.

Evidence and the honest limits

The strong claim is coverage and retention. The whole agreed surface is imaged in planned passes between movements, and the imagery is kept. Those are properties of how the survey is run, and each one can be checked in a pilot.

The weaker claim is the prototype. It codes cracks by rule into four D5340 types, and how well it agrees with a rater on a given pavement is what an evaluation should measure, by walking a few sections in the same season as a drone survey. The PCI explainer sets out how a PCI is built and why a result from imagery is not one.

Then the limits that do not move. Nothing below the surface, no structural capacity, no friction or roughness, and nothing that water, snow or contamination hides on the day.

Objections worth raising before a pilot

“We already run PCI surveys to the DoD procedure.” Keep running them. The drone survey does not replace them. It captures the whole surface between them, and the prototype shows where cracking is.

“A camera cannot rate severity the way our raters do.” The prototype codes cracking only, and every other distress type stays with your raters. Where severity depends on touch or judgement, the walked survey keeps it.

“Our data cannot leave the installation.” Then the capture runs on the offline field deployment and nothing is uploaded. The crack processing runs on a separate GPU machine, so where it runs is agreed per installation.

“We need a condition index.” The prototype does not produce one. What it produces is a coded crack inventory per section and sample unit, which a rater can check against the walked survey.

Related tasks

If the question is the service itself, the pavement condition assessment page describes it while it is in development. If it is the lighter recurring look, the runway pavement check covers it. If it is the debris the surface sheds, FOD that comes from the pavement itself takes that angle. And if it is the on-site deployment, the technology page covers it. To talk about the development or a pilot on your own sections, contact TarmacView .