Data Management for Inspection Programs

What Is Inspection Data Management?

Inspection data management is the systematic discipline of governing the complete lifecycle of data generated by infrastructure inspection programs — from the moment of capture through processing, analysis, archival, and eventual purging. It encompasses the storage architectures, metadata frameworks, versioning protocols, retention policies, access controls, and integration patterns that transform raw inspection outputs (imagery, point clouds, sensor readings, condition records) into an organized, queryable, and defensible data asset.

For airport pavement inspection programs operating under FAA Advisory Circular 150/5380-7B and ICAO Annex 14, data management is not optional infrastructure — it is a regulatory mandate. Federally obligated airports in the United States must perform detailed pavement inspections at least once per year (or once every three years if using the Pavement Condition Index method per ASTM D5340), generating terabytes of high-resolution imagery, distress records, and condition data that must be stored, cataloged, and retrievable for minimum retention periods defined by aviation authorities. An airport that cannot produce inspection records for a given pavement section upon request during a compliance audit has, in effect, not performed the inspection at all.

The scope of inspection data management extends beyond simple file storage. It requires metadata cataloging so that any image or point cloud can be found by date, location, asset, sensor type, or processing state. It requires data versioning so that repeat surveys of the same pavement section can be compared temporally to detect crack propagation, rutting progression, and PCI deterioration rates. It requires data quality validation to ensure that only survey-grade data enters the historical record. And it requires integration with Asset Management Systems and Pavement Management Systems so that inspection data drives maintenance and rehabilitation decisions rather than languishing in disconnected storage silos.

Section 1: Data Volume and Growth in Inspection

The data volume generated by modern airport pavement inspection programs is substantial and grows geometrically with sensor resolution and survey frequency. A single full-coverage drone inspection of a medium-sized airport (approximately 2 million square feet of paved surfaces — runways, taxiways, and aprons) flown at 100 ft altitude with 1 mm/pixel Ground Sample Distance produces between 10,000 and 50,000 individual images depending on overlap requirements. At typical 24-megapixel sensor resolution (6000 × 4000 pixels, approximately 12 MB per JPEG with EXIF metadata), the raw image set occupies 300 to 1,500 GB of storage.

LiDAR point cloud data adds significant volume beyond imagery. A mobile LiDAR system (MMS — Mobile Mapping System) collecting at 500,000 points per second along a 10,000 ft runway at 5 mph generates approximately 3-5 billion points. In compressed LAZ format at 5:1 compression ratio, this occupies 15-25 GB per runway. Airborne LiDAR (ALS) at 20-50 points per square meter generates 1-3 billion points for a full airport, occupying 5-15 GB in LAZ format.

The cumulative storage requirement over a 30-year asset lifecycle is substantial. Under FAA AC 150/5380-7B, airports may opt for PCI surveys every three years (maximum interval) or annual detailed inspections. Even at the three-year cycle, a medium hub airport accumulates approximately 3-5 TB of inspection data per decade, reaching 10-15 TB over 30 years. At annual inspection frequency, this doubles to 6-10 TB per decade and 20-30 TB over the lifecycle.

Data growth drivers include: sensor resolution increasing from 12 MP to 100+ MP cameras, multispectral and thermal sensors adding additional bands, higher GSD requirements (0.5 mm/pixel vs 1.0 mm/pixel quadrupling image count), and increasing overlap requirements for robust photogrammetric reconstruction (85-90% forward overlap vs 70-80% historical standards). Organizations that do not plan for exponential data growth find their storage infrastructure saturated within 3-5 years of program inception.

Section 2: Storage Architecture — On-Prem NAS, Cloud Object Storage, and Hybrid

The storage architecture for inspection data must balance three competing requirements: low-latency access during active processing and analysis phases, unlimited scalability for growing data volumes, and long-term durability for regulatory retention periods. No single storage technology optimally satisfies all three requirements, which is why hybrid architectures dominate industry best practice.

On-Premises NAS (Network Attached Storage)

Network Attached Storage remains the primary storage tier for active inspection data — the datasets being processed, analyzed, and reviewed in current workflows. NAS systems provide file-level access via NFS (Network File System) or SMB/CIFS protocols, presenting inspection data as a familiar directory structure that integrates with photogrammetry software (Agisoft Metashape, Pix4Dmapper), GIS platforms (ArcGIS, QGIS), and engineering analysis tools.

The recommended NAS configuration for inspection programs uses RAID 6 (double parity) or ZFS RAID-Z2 (double parity with checksumming for bit-rot detection) across 8-24 drive bays. A typical inspection NAS specification includes: 10-100 TB usable capacity in a single volume, 10 GbE or 25 GbE network connectivity for high-throughput image transfer, NVMe read cache for frequently accessed inspection sets, and snapshot capability for point-in-time recovery. The ZFS file system offers particular advantages for inspection data management: block-level checksums detect and repair silent data corruption (bit rot) that would otherwise introduce artifacts into archived imagery, compression (LZ4 or ZSTD) reduces storage footprint without performance penalty, and snapshots provide instantaneous versioning for recovery from accidental deletion or corruption.

Limitations of pure on-prem NAS include: finite scalability (adding capacity requires purchasing and installing new hardware), single-site vulnerability (a fire, flood, or power event at the facility destroys all data), and administrative overhead (hardware maintenance, OS patching, backup management). These limitations drive organizations toward hybrid or cloud-native architectures for the long-term archive.

Cloud Object Storage

Cloud object storage (S3-compatible services such as Amazon S3, Wasabi, Backblaze B2, and Azure Blob Storage) provides a fundamentally different storage model optimized for scalability and durability rather than file-system semantics. Objects are stored in a flat namespace (buckets) and accessed via RESTful HTTP/HTTPS APIs, with each object identified by a unique key and carrying user-defined metadata key-value pairs.

For inspection data management, cloud object storage offers: theoretical infinite scalability — storage capacity expands automatically without provisioning or capacity planning, eleven-nines durability (99.999999999%) through automatic replication across multiple geographic facilities, lifecycle policies that automatically transition objects from hot (frequent access) to cool (infrequent access) to cold (archive) tiers based on configurable rules, and geographic redundancy — data automatically replicated across multiple AWS Availability Zones or Azure Availability Regions.

Cloud storage cost follows a three-tier lifecycle model. For Amazon S3 Standard (hot tier), storage costs approximately $0.023/GB/month. After 90 days of no access, lifecycle policies automatically transition objects to S3 Standard-IA (infrequent access) at $0.0125/GB/month. After 180 days, transition to S3 Glacier Instant Retrieval at $0.004/GB/month, then S3 Glacier Deep Archive at $0.001/GB/month for data that must be retained for regulatory compliance but is rarely accessed. A 5 TB inspection archive costs approximately $115/month in hot storage versus $5/month in deep archive storage — a 23x cost reduction that makes indefinite retention economically feasible.

Hybrid Architecture

The hybrid architecture combines on-premises NAS for active data with cloud object storage for warm/cold archiving. Data flows through a defined lifecycle: raw inspection imagery and telemetry land on the on-prem NAS immediately after capture, the processing pipeline accesses this data with NAS-level performance (sub-millisecond latency) during photogrammetric reconstruction and distress analysis, processed products (orthomosaics, point clouds, distress maps, PCI reports) are retained on NAS for 30-90 days for current project access, and after project completion, the entire dataset — raw imagery, processed products, and reports — is transferred to cloud object storage for long-term archiving.

Data transfer between NAS and cloud is typically performed via AWS Snowball or Azure Data Box for initial bulk migration (petabyte-scale), then rsync or Rclone for ongoing delta transfers. For airports with limited WAN bandwidth (50-100 Mbps typical for non-metro airports), a full survey transfer of 500 GB takes 11-22 hours over a 100 Mbps connection. Scheduled transfers during overnight hours or use of WAN acceleration appliances (Riverbed, Silver Peak) mitigates bandwidth contention.

Section 3: Metadata and Cataloging

Metadata is the organizational backbone of inspection data management. Without comprehensive metadata, a collection of 50,000 inspection images is an undifferentiated mass — impossible to query, correlate, or temporally compare. With structured metadata following established standards, the same dataset becomes a searchable, filterable, analyzable asset.

Minimum Required Metadata Fields

Every inspection image, point cloud, and derived product must carry the following metadata fields as a baseline:

Geospatial Metadata Standards

For inspection data management, the SpatioTemporal Asset Catalog (STAC) specification has emerged as the industry standard for organizing geospatial imagery and point cloud metadata. STAC provides a JSON-based metadata structure with three levels: Collection (describes a dataset — e.g., “LAX 2025 Annual Pavement Inspection”), Item (describes a single asset — e.g., an individual image or point cloud tile), and Asset (a link to the actual data file plus its metadata).

STAC Collections support temporal and spatial querying. A query such as “find all inspection images for Runway 12/30 between 2023-01-01 and 2025-06-30 with GSD better than 2 mm/px” executes against the STAC catalog index and returns matching item references with their download URLs. This enables geospatial search across inspection campaigns spanning years and data types.

The ISO 19115 geospatial metadata standard provides a more comprehensive (but more complex) framework for documenting data lineage, processing history, spatial reference systems, and data quality. ISO 19115 metadata records include fields for: identification information (title, abstract, purpose), constraint information (access and use limitations — critical for security-sensitive aerodrome data), data quality information (positional accuracy, completeness, logical consistency), maintenance information (update frequency, next update date), and distribution information (format, distributor, online access URL).

Data Catalog Implementation

A data catalog implements these metadata standards in a searchable database system. The catalog stores the metadata — not the data itself — and provides a query interface for finding and retrieving inspection assets by any combination of metadata fields. The catalog database is typically PostgreSQL with PostGIS extension for geospatial queries, Elasticsearch for full-text search across inspection reports and notes, or a purpose-built platform like STAC Browser or Radiant MLHub for geospatial inspection data.

The catalog must support faceted search: filtering by date range (show only 2024 inspections), geographic polygon (show only southwest apron section), asset type (runway only, not taxiway), sensor type (RTK drone only), processing state (only completed orthomosaics), and quality grade (only surveys with GSD < 1.5 mm/pixel). Each filter combination narrows the result set, enabling engineers to find exactly the inspection data they need from a library spanning years and terabytes.

The catalog also maintains data lineage — the provenance chain from raw capture through processing to final products. Each derived product references its source data UUIDs, processing parameters, and software versions. This traceability is essential for verifying the validity of measurements extracted from processed data: if a distress measurement is questioned, the lineage record shows exactly which source images, calibration file, and processing settings produced it.

Section 4: Data Versioning for Repeat Surveys

Data versioning is what transforms inspection data management from a static archive into a dynamic analytical tool. Without versioning, a 2023 inspection and a 2025 inspection of the same pavement section are two isolated datasets. With versioning, they become a time series — enabling quantitative measurement of pavement deterioration rates, crack propagation velocities, and treatment effectiveness.

Versioning Model

Each inspection campaign receives a persistent survey identifier (UUID v4) and a version number starting at 1. When a pavement section is re-inspected, the new survey data is tagged with the same asset identifier (e.g., LAX-RWY-12-30-SEC-004) but a new survey UUID and version timestamp. The versioning model must distinguish between:

Re-inspection versions: A completely new survey of the same pavement area, acquired on a different date with potentially different sensor configuration, flight plan, and environmental conditions. Each re-inspection version is a standalone dataset that can be compared to previous versions.

Correction versions: A revision to an existing survey dataset — for example, correcting a georeferencing offset after GCP adjustment, or reprocessing orthomosaics with an updated camera calibration file. Correction versions retain the same survey UUID but increment a sub-version identifier (e.g., SURV-2025-001-v2).

Amendment versions: A partial update to a survey — for example, re-flying a section where imagery was overexposed, or adding new distress annotations discovered during QA review. Amendment versions merge new data into an existing survey context.

Temporal Comparison Architecture

Temporal comparison between survey versions requires pixel-to-pixel registration — the ability to overlay exactly the same geographic footprint from two different acquisition dates and compute differences. This demands that both surveys be georeferenced to the same coordinate system (typically UTM zone with WGS84 datum) with sub-pixel alignment accuracy.

The comparison pipeline: load survey N orthomosaic and survey N-1 orthomosaic for the same pavement section, compute normalized cross-correlation or mutual information registration to refine initial georeferencing alignment, apply a radiometric normalization to compensate for different lighting conditions, and compute the difference map identifying changed pixels. Changed pixels are classified by type (new cracking, crack widening, spalling growth, patching, FOD appearance) and severity (area of change in square meters, crack length extension in meters, crack width increase in millimeters).

Version Storage Strategy

Storing full copies of every survey version is prohibitively expensive. A strategic approach stores: the full baseline survey (version 1) with complete imagery, point clouds, and derived products, incremental versions (v2, v3, etc.) storing only the raw imagery and computed change deltas, and full re-extraction capability — the ability to regenerate any version’s complete product set from raw imagery when needed for comparison or reporting.

For a pavement section with 10 surveys over 30 years, the full baseline survey requires 100 GB of storage. Each incremental survey adds 40 GB of raw imagery and 1-2 GB of change detection products, totaling 500-700 GB for the full series — versus 1 TB if every version was stored in full. The 30-40% reduction is significant at airport-wide scale.

Section 5: Retention and Archiving Policies

Data retention policies govern how long inspection data must be preserved before it can be deleted or transitioned to deep archive. These policies are driven by regulatory requirements, operational needs, and economic considerations.

Regulatory Minimum Retention Periods

The FAA AC 150/5380-7B requirement deserves careful reading. Paragraph 2.2.1.1 mandates that pavement inventory data — location, dimensions, construction year, material type, and AIP/PFC fund usage — be maintained for the life of the pavement. Paragraph 2.2.1.3 requires M&R history including distress types, work quantities, and costs. Appendix A specifies that airport sponsors must maintain records for a minimum of 5 years, but the AC strongly implies that records should be kept as long as the pavement remains in service — a sponsor who discards records after 5 years loses the ability to model long-term deterioration trends.

Operational Retention Requirements

Beyond regulatory minima, operational considerations justify longer retention periods. Temporal deterioration modeling requires a minimum of 3-5 survey cycles (9-15 years at the 3-year PCI cycle) to establish statistically significant deterioration curves for each pavement section. Legal defensibility demands that inspection records be retained for the duration of any incident or accident investigation that may involve pavement condition — typically 5-10 years after the event under statutes of limitation. Asset lifecycle analysis covering 20-40 year pavement design lives requires data spanning the full period to validate design assumptions and identify premature failures.

Tiered Archiving Strategy

A tiered archiving strategy minimizes storage costs while satisfying all retention requirements:

Tier 1 — Active Archive (0-5 years): Full dataset retained on hot or warm storage with sub-minute retrieval latency. Complete raw imagery, point clouds, processed orthomosaics, distress maps, and PCI reports are immediately accessible for current analysis, annual reporting, and FAA compliance audits.

Tier 2 — Regulatory Archive (5-10 years): Raw imagery compressed (lossless JPEG2000 or WebP for imagery; LAS compression for point clouds) and transitioned to cool cloud storage. Processed products (orthomosaics, reports) remain accessible. Retrieval latency: minutes to hours.

Tier 3 — Permanent Archive (10+ years): Metadata catalog retained permanently in the database. Raw imagery archived to Glacier Deep Archive or equivalent cold storage. Processed products retained only if they cannot be regenerated from raw data. Retrieval latency: 12-48 hours, initiated only for extraordinary circumstances (litigation, accident investigation, major rehabilitation planning).

All three tiers maintain the metadata catalog unchanged. Even if the pixel data is archived to cold storage with slow retrieval, the metadata record — including thumbnails, derived measurements, PCI values, and distress classifications — remains immediately searchable for reporting and trending without data retrieval costs.

Section 6: Data Security and Access Control

Airport inspection data is sensitive infrastructure information. A complete set of high-resolution imagery, LiDAR point clouds, and distress maps for an airport’s movement area constitutes a detailed vulnerability assessment of the pavement infrastructure. Unauthorized access could enable threat actors to identify weaknesses, plan physical intrusions, or exploit pavement condition knowledge for malicious purposes.

Access Control Model

Role-Based Access Control (RBAC) is the foundational security model for inspection data management. The RBAC model defines roles with hierarchical permissions:

Permission granularity extends to spatial scoping — an engineer responsible for Runway 12/30 should not automatically have access to secure apron data or RFF facility inspection records. Geo-fencing restricts data access by geographically defined polygons: a user’s role permits access only to inspection data whose acquisition location falls within their authorized spatial scope.

Data Encryption

Inspection data must be encrypted at rest and in transit. At-rest encryption uses AES-256 (Advanced Encryption Standard with 256-bit keys) — the standard approved by the National Security Agency for Top Secret classified information. For cloud storage, server-side encryption (SSE-S3 with AWS Key Management Service) manages encryption keys with automatic rotation. For on-premises NAS, LUKS (Linux Unified Key Setup) full-disk encryption or hardware-backed encryption on self-encrypting drives provides equivalent protection.

In-transit encryption uses TLS 1.3 (Transport Layer Security) for all HTTP-based data transfers (API calls, image downloads, catalog queries). For NAS-to-cloud transfers, HTTPS with mutual TLS authentication or SSH-based rsync over SFTP ensures data cannot be intercepted during transfer. VPN tunnels between airport networks and cloud providers add a defense-in-depth layer.

Audit Logging

Every access to inspection data must be immutably logged — the log record cannot be deleted or modified after creation, even by system administrators. Audit logs capture: who (user ID, role), what (data identifier, file name), when (UTC timestamp with microsecond precision), where (source IP address, geolocation), how (API endpoint, application), and outcome (success, failure, denial reason).

Audit logs are stored in write-once-read-many (WORM) storage — either cloud object storage with object lock enabled (S3 Object Lock in compliance mode) or dedicated hardware WORM appliances. Retention for audit logs is typically 3-7 years per regulatory requirements (FAA Part 139, ICAO Annex 14 security provisions). Quarterly review of audit logs identifies anomalous access patterns — for example, an inspector downloading 50,000 images at 3 AM from a non-airport IP address.

Data Sovereignty

Cross-border data transfer of airport inspection data is subject to data sovereignty regulations. An airport in an ICAO Contracting State may use a cloud provider whose data centers are located in a different country. Local aviation regulations may prohibit storage of aerodrome inspection data outside national borders. The data management architecture must support geo-fencing of storage: specifying that inspection data for Airport X must reside in data centers located within Country X, and that cloud provider personnel in other countries cannot access the data.

Cloud providers offer data residency options: AWS Regions (us-east-1, eu-west-1, ap-southeast-2, etc.), Azure Regions, and Google Cloud Regions. Each inspection dataset carries a jurisdiction tag that determines which cloud region it may be stored in. The storage platform enforces this tag: a data transfer request that would move data outside its authorized jurisdiction is denied at the API level.

Section 7: Integration with Asset Management Systems and Pavement Management Systems

Inspection data creates value only when it integrates with the systems that plan, prioritize, and execute maintenance and rehabilitation work. The primary integration targets are Asset Management Systems (AMS) and Pavement Management Systems (PMS) .

Integration Architecture

The integration follows a publish-subscribe pattern: the inspection data management platform publishes processed condition data to the AMS/PMS, and the AMS/PMS consumes this data for analysis, modeling, and work planning. The data exchange uses RESTful JSON APIs with GeoJSON for geospatial features (distress polygons, crack lines, section boundaries).

The published payload for each pavement section includes: distress inventory — list of all observed distresses per ASTM D5340, each with type code (1-19 for asphalt, 21-33 for concrete), severity level (L, M, H), quantity (square feet or linear feet), and geographic coordinates; condition indices — PCI value per section, per branch, and per network, with confidence intervals derived from sampling density; change detection metrics — crack propagation rate, PCI deterioration rate, spalling growth rate, rutting progression, compared to all previous surveys; recommended M&R actions — automated treatment recommendations based on distress type and severity (crack sealing, patching, overlay, reconstruction) with estimated costs and remaining service life if treatment is applied.

Data Exchange Standards

The AASHTO PRS (Pavement Resource System) data exchange format and ISO 55000 asset management framework provide guidance for inspection data integration. The exchange format defines required fields: section identifier (globally unique), inspection date, inspection method (PCI, PAVER, automated), distress data (type, severity, extent per ASTM D5340), condition index (computed PCI), ride quality (IRI in inches/mile if measured), structural capacity (deflection data if FWD was performed), surface texture (friction number if measured), and maintenance history references.

PMS Integration Workflow

Step 1 — Inventory sync: The PMS maintains the authoritative pavement inventory — sections, branches, network hierarchy, construction history, material properties. The inspection platform imports this inventory at survey setup time and tags all collected data with PMS section identifiers.

Step 2 — Data collection: Inspection survey executes, generating imagery, point clouds, and raw measurements tagged with PMS section identifiers embedded in metadata.

Step 3 — Processing and analysis: Imagery is processed into orthomosaics. Distress detection runs via automated AI models and/or manual annotation. PCI is computed per ASTM D5340. Results are stored in the inspection data management platform with full metadata.

Step 4 — Data publication: Condition data is packaged into the PMS exchange format and published via API or file transfer (CSV, XML, JSON with geospatial extensions). The publication includes the condition data plus quality metrics (survey confidence, GSD, coverage gaps).

Step 5 — PMS ingestion: The PMS ingests the condition data, updates section condition records, recalculates network-level statistics, runs deterioration models, updates M&R priorities, and generates budget scenarios. The PMS publishes back to the inspection platform: treatment records (what was done, where, when, cost), enabling the inspection platform to track treatment effectiveness by comparing pre- and post-treatment condition.

FAA PAVEAIR Integration

The FAA’s PAVEAIR system (the official PMS for federally obligated airports receiving AIP funds) requires specific data formats for inspection data import. PAVEAIR accepts condition data in PAVER-format flat files — a column-delimited text format specifying branch, section, distress type, severity, and quantity. Inspection data management platforms that integrate with PAVEAIR automate the conversion from ASTM D5340 distress data to PAVEAIR-compatible format, eliminating manual data entry errors and reducing the administrative burden on airport pavement engineers.

Section 8: Data Quality and Validation

Data quality validation is the gatekeeper that determines whether inspection data enters the permanent record or is rejected for re-acquisition. A single survey contaminated by poor-quality imagery, incorrect georeferencing, or erroneous distress classification corrupts the temporal analysis chain — all subsequent comparisons are unreliable because they reference an invalid baseline.

Quality Metrics

Validation Workflow

Automated validation runs immediately after data upload, before any processing begins. A quality control server scans each image for: EXIF metadata completeness (GPS coordinates present and within expected geographic boundary, timestamp valid, camera calibration ID present), histogram quality (mean exposure value between 80-200 on 0-255 scale, no more than 0.1% of pixels clipped in highlights or shadows), sharpness measurement (MTF50 greater than 0.3 cycles/pixel using the slanted-edge method), and GSD computation from altitude and focal length, verified against the survey plan.

Post-processing validation runs after photogrammetric reconstruction and distress analysis. Key checks include: coverage completeness — every pavement section in the survey plan has been imaged with adequate overlap (computed from the photogrammetric sparse point cloud density); georeferencing accuracy — ground control point residuals are within the survey specification (typically 0.05 m RMS for RTK, 0.5 m RMS for non-RTK); and distress classification audit — a random 10% sample of pavement sections is manually reviewed by a certified PCI inspector who compares automated distress classifications against manual assessment.

Rejection criteria: Any survey failing automated geolocation accuracy, coverage completeness, or image quality thresholds is flagged for immediate re-flight. A section with GSD exceeding 1.5× the planned value cannot produce reliable crack width measurements — re-flying that section at the correct altitude is mandatory before the data enters the permanent archive.

Section 9: Regulatory Data Retention Requirements

Regulatory requirements for inspection data retention form the baseline around which all data management policies must be designed. Non-compliance with retention requirements exposes airports to loss of federal funding (AIP grants, PFC approvals), certification suspension (under ICAO Annex 14 Article 38), and legal liability in the event of pavement-related incidents.

FAA Requirements (United States)

FAA Advisory Circular 150/5380-7B (dated 10/10/2014) governs pavement management program documentation for federally obligated airports. The AC defines minimum record-keeping requirements in Appendix A:

Pavement inventory records must include construction year, material types, layer thicknesses, dimensions, and AIP/PFC funding flags. These records must be maintained for the life of the pavement because they establish the baseline for structural analysis, remaining life estimation, and M&R strategy selection.

Pavement condition data (PCI surveys, distress inventories, condition ratings) must be retained for minimum 5 years from the inspection date. In practice, the 5-year minimum is inadequate for temporal modeling — the FAA encourages airports to retain condition data for the full pavement lifecycle.

Maintenance and rehabilitation history must be retained including work types, dates, costs, quantities, and contractor information. This data enables effectiveness analysis: did the crack seal applied in 2022 actually extend the life of the pavement as projected?

Inspection reports and PAVER outputs must be retained for minimum 5 years and be available for review during FAA compliance inspections. The FAA may request records dating back multiple inspection cycles to assess deterioration trends and program effectiveness.

ICAO Requirements (International)

ICAO Annex 14 Volume I, Section 10 (Aerodrome Maintenance) and ICAO Airport Services Manual (Doc 9137) Part 2 (Pavement) establish international standards for inspection record keeping:

Aerodrome operators shall maintain records of inspections, maintenance, and repairs for the operational life of the pavement plus any additional period specified by the State.

This standard places the retention obligation at the full asset lifecycle — typically 20-40 years for airport pavements depending on construction quality, loading, and environmental conditions. National aviation authorities may extend this period in their civil aviation regulations.

Inspection records must include: date and time of inspection, inspector identification, inspection methods used, inspection results (distress types, severity, extent), and any corrective actions taken or recommended.

Pavement strength records (ACN/PCN) must be maintained for the life of the pavement and updated whenever structural changes occur (overlays, reconstruction). PCN reporting is required for AIP (Aeronautical Information Publication) publication and international flight operations.

ICAO PANS-Aerodromes (Doc 9981) adds operational requirements for movement area inspection records, specifying that records must be retained for at least 3 years for routine inspections and longer for serious observations involving safety-critical deficiencies.

EASA Requirements (European Union)

Commission Regulation (EU) No 139/2014 (Aerodrome Regulation) and its Acceptable Means of Compliance (AMC) specify:

Aerodrome operators shall establish a records management system for the retention of aerodrome data and documentation relevant to safety management.

Aeronautical data (including pavement inspection data) classified as essential or critical per EASA’s data quality requirements (Regulation 73/2010) must be retained for 5 years with verified data quality throughout the retention period. Data classified as routine must be retained for 3 years.

The EASA framework also mandates data integrity monitoring — inspection data stored for regulatory compliance must be periodically verified for integrity (checksum validation, bit-rot detection) to ensure it remains usable throughout the retention period.

Section 10: Data Management in the TarmacView Context

TarmacView implements the full inspection data management framework described in this article as a unified platform specifically designed for airport pavement inspection programs. The platform combines storage management, metadata cataloging, temporal versioning, quality validation, security controls, and AMS/PMS integration in a single integrated system.

Automated metadata extraction: When inspection imagery is uploaded, TarmacView automatically reads EXIF GPS tags (latitude, longitude, altitude), EXIF timestamps, DJI XMP telemetry (GimbalPitchDegree, GimbalYawDegree, AbsoluteAltitude, RelativeAltitude, CalibratedFocalLength), and camera calibration identifiers. This metadata is written into the STAC-compliant catalog, making every image immediately discoverable without manual data entry.

Enterprise hybrid storage: TarmacView supports on-premises NAS configurations for airports that require local data residency, cloud object storage for scalable long-term archiving, and hybrid deployments that automatically tier data between hot NAS and cold cloud storage based on configurable lifecycle policies. The platform abstracts the storage layer so that users interact with the data catalog regardless of where the underlying bytes reside.

Temporal comparison engine: The versioning system assigns persistent survey identifiers and enables pixel-to-pixel overlay of repeat surveys. TarmacView’s temporal comparison computes per-section PCI deterioration curves, crack propagation rates, spalling growth measurements, and rutting progression, all timestamped and versioned for audit defensibility.

Regulatory compliance reporting: TarmacView generates FAA-compliant PCI reports per ASTM D5340, PAVEAIR-compatible data exports, ICAO Annex 14 pavement condition summaries, EASA inspection records, and custom report formats for CAAC, CASA, and Transport Canada. All reports include the data provenance chain linking each measurement to its source imagery.

Integrated quality validation: The platform runs automated QC on every uploaded inspection dataset — checking GSD, coverage completeness, image sharpness, and geolocation accuracy against configurable thresholds — before data enters the processing pipeline. Non-conforming sections are flagged with specific remediation instructions for the flight operations team.

AMS/PMS integration: TarmacView publishes condition data to PAVEAIR, MicroPAVER, dTIMS, and custom PMS platforms via standardized APIs and file formats. The integration bi-directionally syncs pavement inventory, condition records, M&R history, and treatment effectiveness data, ensuring that inspection data drives operational decisions rather than remaining isolated in a viewing-only repository.

For a practical illustration of how these data management principles apply in an operational context, consider the inspection workflow at a medium-hub airport:

The pavement engineering team deploys a DJI Matrice 350 RTK with a Zenmuse P1 45 MP full-frame camera for the triennial PCI survey. The drone follows the pre-planned flight path covering 3.2 million square feet of pavement at 100 ft AGL with 85% forward overlap and 70% side overlap. The flight generates 16,438 images totaling 287 GB. During upload, TarmacView’s automated QC detects that 142 images from taxiway B’s northern segment have GSD exceeding 1.8 mm/pixel due to a barometric altitude sensor drift. The platform flags these images and automatically generates a re-flight work order for that specific 0.3-mile segment. After re-flight, the complete dataset passes QC.

The photogrammetric pipeline processes the imagery into an orthomosaic at 1 mm GSD with 3 cm RMSE geolocation accuracy (verified against 12 ground control points). The AI distress detection model identifies 1,847 individual distress instances across all pavement sections. A certified PCI inspector reviews a 10% random sample — finding 92.3% agreement with automated classification. The 7.7% disagreement is concentrated in low-severity block cracking on a single apron section, which the inspector corrects manually.

The final condition report is published to the PMS: network-level PCI of 74 (Fair), with 12 sections in Serious condition (PCI 40-55), 31 sections in Fair condition (PCI 56-70), and 42 sections in Good to Excellent condition (PCI 71-100). The temporal comparison with the 2022 survey shows a network-wide PCI decline of 4.2 points — consistent with the modeled deterioration rate. Three sections show accelerated deterioration (PCI drop > 8 points), triggering investigation into possible structural issues.

The complete dataset — 287 GB of raw imagery, 42 GB of point cloud, 8 GB of orthomosaic, 2 GB of processed distress data, and the report PDF — is stored in the active archive (on-premises NAS) for 90 days, then transitions to warm cloud storage (S3 Standard-IA) for 5 years to satisfy FAA AC 150/5380-7B retention requirements. After 5 years, it transitions to cold archive (S3 Glacier Deep Archive) for the remaining pavement lifecycle. The metadata catalog retains the full searchable record indefinitely.

This workflow, enabled by comprehensive data management, transforms a year-3 inspection from a compliance exercise into a strategic asset. The airport engineer can query 15 years of condition history for any pavement section with a single catalog search, compare deterioration rates across sections with similar construction and loading, and defend every maintenance funding request with quantitative condition data and modeled projections.