¿Qué es la Gestión de Datos de Inspección?

Gestión de Datos para Programas de Inspección

¿Qué es la Gestión de Datos de Inspección?

La gestión de datos de inspección es la disciplina sistemática de gobernar el ciclo de vida completo de los datos generados por los programas de inspección de infraestructura, desde el momento de la captura hasta el procesamiento, análisis, archivo y eventual eliminación. Abarca las arquitecturas de almacenamiento, los marcos de metadatos, los protocolos de versionado, las políticas de retención, los controles de acceso y los patrones de integración que transforman los resultados brutos de la inspección (imágenes, nubes de puntos, lecturas de sensores, registros de condición) en un activo de datos organizado, consultable y defendible.

Para los programas de inspección de pavimentos aeroportuarios que operan bajo la Circular de Asesoramiento 150/5380-7B de la FAA y el Anexo 14 de la OACI, la gestión de datos no es una infraestructura opcional, es un mandato regulatorio. Los aeropuertos federalmente obligados en los Estados Unidos deben realizar inspecciones detalladas del pavimento al menos una vez al año (o una vez cada tres años si se utiliza el método del Índice de Condición del Pavimento según ASTM D5340), generando terabytes de imágenes de alta resolución, registros de deterioro y datos de condición que deben almacenarse, catalogarse y ser recuperables durante los períodos mínimos de retención definidos por las autoridades de aviación. Un aeropuerto que no pueda presentar los registros de inspección de una sección de pavimento determinada cuando se le solicite durante una auditoría de cumplimiento, en efecto, no ha realizado la inspección en absoluto.

El alcance de la gestión de datos de inspección se extiende más allá del simple almacenamiento de archivos. Requiere catalogación de metadatos para que cualquier imagen o nube de puntos pueda ser encontrada por fecha, ubicación, activo, tipo de sensor o estado de procesamiento. Requiere versionado de datos para que los estudios repetidos de la misma sección de pavimento puedan compararse temporalmente y detectar la propagación de grietas, la progresión de roderas y las tasas de deterioro del PCI. Requiere validación de la calidad de los datos para garantizar que solo los datos de calidad de estudio ingresen al registro histórico. Y requiere integración con Sistemas de Gestión de Activos y Sistemas de Gestión de Pavimentos para que los datos de inspección impulsen las decisiones de mantenimiento y rehabilitación en lugar de languidecer en silos de almacenamiento desconectados.

Sección 1: Volumen y Crecimiento de Datos en la Inspección

El volumen de datos generado por los programas modernos de inspección de pavimentos aeroportuarios es sustancial y crece geométricamente con la resolución del sensor y la frecuencia de los estudios. Una sola inspección de cobertura completa con dron de un aeropuerto de tamaño mediano (aproximadamente 2 millones de pies cuadrados de superficies pavimentadas, pistas, calles de rodaje y plataformas) volado a 100 ft de altitud con una Distancia de Muestreo en Tierra de 1 mm/píxel produce entre 10,000 y 50,000 imágenes individuales dependiendo de los requisitos de superposición. Con una resolución de sensor típica de 24 megapíxeles (6000 × 4000 píxeles, aproximadamente 12 MB por JPEG con metadatos EXIF), el conjunto de imágenes sin procesar ocupa 300 a 1,500 GB de almacenamiento.

Los datos de nube de puntos LiDAR añaden un volumen significativo más allá de las imágenes. Un sistema LiDAR móvil (MMS, Sistema de Mapeo Móvil) que recolecta a 500,000 puntos por segundo a lo largo de una pista de 10,000 ft a 5 mph genera aproximadamente 3-5 mil millones de puntos. En formato LAZ comprimido con una relación de compresión de 5:1, esto ocupa 15-25 GB por pista. El LiDAR aerotransportado (ALS) a 20-50 puntos por metro cuadrado genera 1-3 mil millones de puntos para un aeropuerto completo, ocupando 5-15 GB en formato LAZ.

El requisito de almacenamiento acumulativo a lo largo de un ciclo de vida de activo de 30 años es sustancial. Según la FAA AC 150/5380-7B, los aeropuertos pueden optar por estudios PCI cada tres años (intervalo máximo) o inspecciones detalladas anuales. Incluso en el ciclo de tres años, un aeropuerto de centro de conexiones mediano acumula aproximadamente 3-5 TB de datos de inspección por década, alcanzando 10-15 TB en 30 años. Con una frecuencia de inspección anual, esto se duplica a 6-10 TB por década y 20-30 TB a lo largo del ciclo de vida.

Los impulsores del crecimiento de datos incluyen: el aumento de la resolución del sensor de 12 MP a cámaras de más de 100 MP, los sensores multiespectrales y térmicos que añaden bandas adicionales, los requisitos de GSD más altos (0.5 mm/píxel frente a 1.0 mm/píxel que cuadruplican el recuento de imágenes) y los requisitos de superposición crecientes para una reconstrucción fotogramétrica robusta (85-90% de superposición frontal frente a los estándares históricos del 70-80%). Las organizaciones que no planifican el crecimiento exponencial de los datos encuentran su infraestructura de almacenamiento saturada en 3-5 años desde el inicio del programa.

Sección 2: Arquitectura de Almacenamiento, NAS Local, Almacenamiento de Objetos en la Nube e Híbrido

La arquitectura de almacenamiento para datos de inspección debe equilibrar tres requisitos contrapuestos: acceso de baja latencia durante las fases activas de procesamiento y análisis, escalabilidad ilimitada para volúmenes de datos crecientes y durabilidad a largo plazo para los períodos de retención regulatoria. Ninguna tecnología de almacenamiento única satisface de manera óptima los tres requisitos, razón por la cual las arquitecturas híbridas dominan la mejor práctica de la industria.

NAS Local (Almacenamiento Conectado a la Red)

El Almacenamiento Conectado a la Red sigue siendo el nivel de almacenamiento principal para los datos de inspección activos, los conjuntos de datos que se están procesando, analizando y revisando en los flujos de trabajo actuales. Los sistemas NAS proporcionan acceso a nivel de archivo a través de protocolos NFS (Sistema de Archivos de Red) o SMB/CIFS, presentando los datos de inspección como una estructura de directorios familiar que se integra con el software de fotogrametría (Agisoft Metashape, Pix4Dmapper), las plataformas SIG (ArcGIS, QGIS) y las herramientas de análisis de ingeniería.

La configuración NAS recomendada para programas de inspección utiliza RAID 6 (doble paridad) o ZFS RAID-Z2 (doble paridad con suma de verificación para detección de corrupción de bits) en 8-24 bahías de disco. Una especificación NAS de inspección típica incluye: capacidad utilizable de 10-100 TB en un solo volumen, conectividad de red de 10 GbE o 25 GbE para transferencia de imágenes de alto rendimiento, caché de lectura NVMe para conjuntos de inspección a los que se accede con frecuencia y capacidad de instantánea para recuperación en un punto en el tiempo. El sistema de archivos ZFS ofrece ventajas particulares para la gestión de datos de inspección: sumas de verificación a nivel de bloque detectan y reparan la corrupción silenciosa de datos (podredumbre de bits) que de otro modo introduciría artefactos en las imágenes archivadas, compresión (LZ4 o ZSTD) reduce la huella de almacenamiento sin penalización de rendimiento y las instantáneas proporcionan versionado instantáneo para la recuperación de eliminación o corrupción accidental.

Las limitaciones del NAS puro local incluyen: escalabilidad finita (agregar capacidad requiere comprar e instalar nuevo hardware), vulnerabilidad de un solo sitio (un incendio, inundación o evento eléctrico en las instalaciones destruye todos los datos) y sobrecarga administrativa (mantenimiento de hardware, parches del sistema operativo, gestión de copias de seguridad). Estas limitaciones impulsan a las organizaciones hacia arquitecturas híbridas o nativas de la nube para el archivo a largo plazo.

Almacenamiento de Objetos en la Nube

El almacenamiento de objetos en la nube (servicios compatibles con S3 como Amazon S3, Wasabi, Backblaze B2 y Azure Blob Storage) proporciona un modelo de almacenamiento fundamentalmente diferente optimizado para la escalabilidad y la durabilidad en lugar de la semántica del sistema de archivos. Los objetos se almacenan en un espacio de nombres plano (contenedores) y se accede a ellos a través de APIs RESTful HTTP/HTTPS, con cada objeto identificado por una clave única y que lleva pares clave-valor de metadatos definidos por el usuario.

Para la gestión de datos de inspección, el almacenamiento de objetos en la nube ofrece: escalabilidad teóricamente infinita, la capacidad de almacenamiento se expande automáticamente sin aprovisionamiento ni planificación de capacidad, durabilidad de once nueves (99.999999999%) a través de la replicación automática en múltiples instalaciones geográficas, políticas de ciclo de vida que transicionan automáticamente los objetos de niveles calientes (acceso frecuente) a templados (acceso poco frecuente) a fríos (archivo) según reglas configurables y redundancia geográfica, los datos se replican automáticamente en múltiples Zonas de Disponibilidad de AWS o Regiones de Disponibilidad de Azure.

El costo del almacenamiento en la nube sigue un modelo de ciclo de vida de tres niveles. Para Amazon S3 Standard (nivel caliente), el almacenamiento cuesta aproximadamente $0.023/GB/mes. Después de 90 días sin acceso, las políticas de ciclo de vida transicionan automáticamente los objetos a S3 Standard-IA (acceso poco frecuente) a $0.0125/GB/mes. Después de 180 días, transición a S3 Glacier Instant Retrieval a $0.004/GB/mes, luego a S3 Glacier Deep Archive a $0.001/GB/mes para datos que deben conservarse para el cumplimiento normativo pero a los que se accede raramente. Un archivo de inspección de 5 TB cuesta aproximadamente $115/mes en almacenamiento caliente frente a $5/mes en almacenamiento de archivo profundo, una reducción de costo de 23 veces que hace que la retención indefinida sea económicamente factible.

Arquitectura Híbrida

La arquitectura híbrida combina NAS local para datos activos con almacenamiento de objetos en la nube para archivo templado/frío. Los datos fluyen a través de un ciclo de vida definido: las imágenes de inspección sin procesar y la telemetría llegan al NAS local inmediatamente después de la captura, la tubería de procesamiento accede a estos datos con rendimiento a nivel de NAS (latencia de submilisegundos) durante la reconstrucción fotogramétrica y el análisis de deterioro, los productos procesados (ortomosaicos, nubes de puntos, mapas de deterioro, informes PCI) se retienen en el NAS durante 30-90 días para el acceso al proyecto actual y, después de la finalización del proyecto, el conjunto de datos completo, imágenes sin procesar, productos procesados e informes, se transfiere al almacenamiento de objetos en la nube para el archivo a largo plazo.

La transferencia de datos entre el NAS y la nube se realiza típicamente a través de AWS Snowball o Azure Data Box para la migración masiva inicial (a escala de petabytes), luego rsync o Rclone para las transferencias delta continuas. Para aeropuertos con ancho de banda WAN limitado (50-100 Mbps típico para aeropuertos no metropolitanos), una transferencia de estudio completa de 500 GB toma de 11 a 22 horas a través de una conexión de 100 Mbps. Las transferencias programadas durante las horas nocturnas o el uso de dispositivos de aceleración WAN (Riverbed, Silver Peak) mitigan la contención del ancho de banda.

Sección 3: Metadatos y Catalogación

Los metadatos son la columna vertebral organizativa de la gestión de datos de inspección. Sin metadatos completos, una colección de 50,000 imágenes de inspección es una masa indiferenciada, imposible de consultar, correlacionar o comparar temporalmente. Con metadatos estructurados que siguen estándares establecidos, el mismo conjunto de datos se convierte en un activo buscable, filtrable y analizable.

Campos de Metadatos Mínimos Requeridos

Cada imagen de inspección, nube de puntos y producto derivado debe llevar los siguientes campos de metadatos como línea de base:

Estándares de Metadatos Geoespaciales

Para la gestión de datos de inspección, la especificación SpatioTemporal Asset Catalog (STAC) se ha convertido en el estándar de la industria para organizar metadatos de imágenes geoespaciales y nubes de puntos. STAC proporciona una estructura de metadatos basada en JSON con tres niveles: Colección (describe un conjunto de datos, por ejemplo, “Inspección Anual de Pavimento LAX 2025”), Elemento (describe un activo individual, por ejemplo, una imagen individual o un mosaico de nube de puntos) y Activo (un enlace al archivo de datos real más sus metadatos).

Las Colecciones STAC admiten consultas temporales y espaciales. Una consulta como “encontrar todas las imágenes de inspección para la Pista 12/30 entre 2023-01-01 y 2025-06-30 con GSD mejor de 2 mm/px” se ejecuta contra el índice del catálogo STAC y devuelve referencias de elementos coincidentes con sus URL de descarga. Esto permite la búsqueda geoespacial a través de campañas de inspección que abarcan años y tipos de datos.

El estándar de metadatos geoespaciales ISO 19115 proporciona un marco más completo (pero más complejo) para documentar el linaje de datos, el historial de procesamiento, los sistemas de referencia espacial y la calidad de los datos. Los registros de metadatos ISO 19115 incluyen campos para: información de identificación (título, resumen, propósito), información de restricciones (limitaciones de acceso y uso, críticas para datos de aeródromos sensibles a la seguridad), información de calidad de datos (precisión posicional, integridad, consistencia lógica), información de mantenimiento (frecuencia de actualización, próxima fecha de actualización) e información de distribución (formato, distribuidor, URL de acceso en línea).

Implementación del Catálogo de Datos

Un catálogo de datos implementa estos estándares de metadatos en un sistema de base de datos buscable. El catálogo almacena los metadatos, no los datos en sí, y proporciona una interfaz de consulta para encontrar y recuperar activos de inspección por cualquier combinación de campos de metadatos. La base de datos del catálogo es típicamente PostgreSQL con extensión PostGIS para consultas geoespaciales, Elasticsearch para búsqueda de texto completo en informes y notas de inspección, o una plataforma de propósito específico como STAC Browser o Radiant MLHub para datos de inspección geoespaciales.

El catálogo debe admitir la búsqueda facetada: filtrar por rango de fechas (mostrar solo inspecciones de 2024), polígono geográfico (mostrar solo la sección suroeste de la plataforma), tipo de activo (solo pista, no calle de rodaje), tipo de sensor (solo dron RTK), estado de procesamiento (solo ortomosaicos completados) y grado de calidad (solo estudios con GSD < 1.5 mm/píxel). Cada combinación de filtro reduce el conjunto de resultados, lo que permite a los ingenieros encontrar exactamente los datos de inspección que necesitan de una biblioteca que abarca años y terabytes.

El catálogo también mantiene el linaje de datos, la cadena de procedencia desde la captura bruta hasta el procesamiento y los productos finales. Cada producto derivado hace referencia a los UUID de sus datos fuente, los parámetros de procesamiento y las versiones de software. Esta trazabilidad es esencial para verificar la validez de las mediciones extraídas de los datos procesados: si se cuestiona una medición de deterioro, el registro de linaje muestra exactamente qué imágenes fuente, archivo de calibración y configuración de procesamiento la produjeron.

Sección 4: Versionado de Datos para Estudios Repetidos

El versionado de datos es lo que transforma la gestión de datos de inspección de un archivo estático a una herramienta analítica dinámica. Sin versionado, una inspección de 2023 y una inspección de 2025 de la misma sección de pavimento son dos conjuntos de datos aislados. Con versionado, se convierten en una serie temporal, lo que permite la medición cuantitativa de las tasas de deterioro del pavimento, las velocidades de propagación de grietas y la efectividad del tratamiento.

Modelo de Versionado

Cada campaña de inspección recibe un identificador de estudio persistente (UUID v4) y un número de versión que comienza en 1. Cuando se vuelve a inspeccionar una sección de pavimento, los nuevos datos del estudio se etiquetan con el mismo identificador de activo (por ejemplo, LAX-RWY-12-30-SEC-004) pero con un nuevo UUID de estudio y una marca de tiempo de versión. El modelo de versionado debe distinguir entre:

Versiones de reinspección: Un estudio completamente nuevo de la misma área de pavimento, adquirido en una fecha diferente con una configuración de sensor, plan de vuelo y condiciones ambientales potencialmente diferentes. Cada versión de reinspección es un conjunto de datos independiente que se puede comparar con versiones anteriores.

Versiones de corrección: Una revisión de un conjunto de datos de estudio existente, por ejemplo, corrigiendo un desplazamiento de georreferenciación después del ajuste de GCP, o reprocesando ortomosaicos con un archivo de calibración de cámara actualizado. Las versiones de corrección conservan el mismo UUID de estudio pero incrementan un identificador de subversión (por ejemplo, SURV-2025-001-v2).

Versiones de enmienda: Una actualización parcial de un estudio, por ejemplo, volando de nuevo una sección donde las imágenes estaban sobreexpuestas, o añadiendo nuevas anotaciones de deterioro descubiertas durante la revisión de QA. Las versiones de enmienda fusionan nuevos datos en un contexto de estudio existente.

Arquitectura de Comparación Temporal

La comparación temporal entre versiones de estudio requiere registro píxel a píxel, la capacidad de superponer exactamente la misma huella geográfica de dos fechas de adquisición diferentes y calcular las diferencias. Esto exige que ambos estudios estén georreferenciados al mismo sistema de coordenadas (típicamente zona UTM con datum WGS84) con precisión de alineación subpíxel.

La tubería de comparación: cargar el ortomosaico del estudio N y el ortomosaico del estudio N-1 para la misma sección de pavimento, calcular la correlación cruzada normalizada o el registro de información mutua para refinar la alineación de georreferenciación inicial, aplicar una normalización radiométrica para compensar las diferentes condiciones de iluminación y calcular el mapa de diferencias que identifica los píxeles cambiados. Los píxeles cambiados se clasifican por tipo (nuevo agrietamiento, ensanchamiento de grietas, crecimiento de desconchado, parcheo, aparición de FOD) y severidad (área de cambio en metros cuadrados, extensión de la longitud de la grieta en metros, aumento del ancho de la grieta en milímetros).

Estrategia de Almacenamiento de Versiones

Almacenar copias completas de cada versión de estudio es prohibitivamente caro. Un enfoque estratégico almacena: el estudio de línea de base completo (versión 1) con imágenes completas, nubes de puntos y productos derivados, versiones incrementales (v2, v3, etc.) que almacenan solo las imágenes sin procesar y los deltas de cambio calculados, y capacidad de reextracción completa, la capacidad de regenerar el conjunto completo de productos de cualquier versión a partir de las imágenes sin procesar cuando sea necesario para comparación o informes.

Para una sección de pavimento con 10 estudios en 30 años, el estudio de línea de base completo requiere 100 GB de almacenamiento. Cada estudio incremental añade 40 GB de imágenes sin procesar y 1-2 GB de productos de detección de cambios, totalizando 500-700 GB para la serie completa, frente a 1 TB si cada versión se almacenara en su totalidad. La reducción del 30-40% es significativa a escala de aeropuerto.

Sección 5: Políticas de Retención y Archivo

Las políticas de retención de datos rigen cuánto tiempo deben conservarse los datos de inspección antes de que puedan eliminarse o transicionarse a un archivo profundo. Estas políticas están impulsadas por requisitos regulatorios, necesidades operativas y consideraciones económicas.

Períodos Mínimos de Retención Regulatorios

El requisito de la FAA AC 150/5380-7B merece una lectura cuidadosa. El párrafo 2.2.1.1 exige que los datos del inventario de pavimentos, ubicación, dimensiones, año de construcción, tipo de material y uso de fondos AIP/PFC, se mantengan durante la vida del pavimento. El párrafo 2.2.1.3 requiere el historial de M&R, incluidos los tipos de deterioro, las cantidades de trabajo y los costos. El Apéndice A especifica que los patrocinadores de aeropuertos deben mantener los registros durante un mínimo de 5 años, pero la AC implica fuertemente que los registros deben conservarse mientras el pavimento permanezca en servicio, un patrocinador que descarta los registros después de 5 años pierde la capacidad de modelar las tendencias de deterioro a largo plazo.

Requisitos de Retención Operativos

Más allá de los mínimos regulatorios, las consideraciones operativas justifican períodos de retención más largos. El modelado de deterioro temporal requiere un mínimo de 3-5 ciclos de estudio (9-15 años en el ciclo PCI de 3 años) para establecer curvas de deterioro estadísticamente significativas para cada sección de pavimento. La defendibilidad legal exige que los registros de inspección se conserven durante la duración de cualquier investigación de incidente o accidente que pueda involucrar la condición del pavimento, típicamente 5-10 años después del evento bajo los estatutos de limitación. El análisis del ciclo de vida del activo que cubre vidas útiles de diseño de pavimento de 20-40 años requiere datos que abarquen el período completo para validar las suposiciones de diseño e identificar fallas prematuras.

Estrategia de Archivo por Niveles

Una estrategia de archivo por niveles minimiza los costos de almacenamiento mientras satisface todos los requisitos de retención:

Nivel 1, Archivo Activo (0-5 años): Conjunto de datos completo retenido en almacenamiento caliente o templado con latencia de recuperación inferior a un minuto. Las imágenes sin procesar completas, las nubes de puntos, los ortomosaicos procesados, los mapas de deterioro y los informes PCI son inmediatamente accesibles para el análisis actual, la presentación de informes anuales y las auditorías de cumplimiento de la FAA.

Nivel 2, Archivo Regulatorio (5-10 años): Imágenes sin procesar comprimidas (JPEG2000 sin pérdida o WebP para imágenes, compresión LAS para nubes de puntos) y transicionadas a almacenamiento en nube templado. Los productos procesados (ortomosaicos, informes) permanecen accesibles. Latencia de recuperación: minutos a horas.

Nivel 3, Archivo Permanente (10+ años): Catálogo de metadatos retenido permanentemente en la base de datos. Imágenes sin procesar archivadas en Glacier Deep Archive o almacenamiento frío equivalente. Los productos procesados se retienen solo si no pueden regenerarse a partir de datos sin procesar. Latencia de recuperación: 12-48 horas, iniciada solo para circunstancias extraordinarias (litigios, investigación de accidentes, planificación de rehabilitación importante).

Los tres niveles mantienen el catálogo de metadatos sin cambios. Incluso si los datos de píxeles se archivan en almacenamiento frío con recuperación lenta, el registro de metadatos, incluidas las miniaturas, las mediciones derivadas, los valores de PCI y las clasificaciones de deterioro, permanece inmediatamente buscable para informes y tendencias sin costos de recuperación de datos.

Sección 6: Seguridad de Datos y Control de Acceso

Los datos de inspección aeroportuaria son información de infraestructura sensible. Un conjunto completo de imágenes de alta resolución, nubes de puntos LiDAR y mapas de deterioro para el área de movimiento de un aeropuerto constituye una evaluación detallada de vulnerabilidad de la infraestructura del pavimento. El acceso no autorizado podría permitir que actores maliciosos identifiquen debilidades, planifiquen intrusiones físicas o exploten el conocimiento de la condición del pavimento con fines maliciosos.

Modelo de Control de Acceso

El Control de Acceso Basado en Roles (RBAC) es el modelo de seguridad fundamental para la gestión de datos de inspección. El modelo RBAC define roles con permisos jerárquicos:

La granularidad de los permisos se extiende al alcance espacial, un ingeniero responsable de la Pista 12/30 no debería tener acceso automático a los datos de la plataforma segura o los registros de inspección de las instalaciones de RFF. El geovallado restringe el acceso a los datos mediante polígonos definidos geográficamente: el rol de un usuario permite el acceso solo a los datos de inspección cuya ubicación de adquisición cae dentro de su alcance espacial autorizado.

Cifrado de Datos

Los datos de inspección deben estar cifrados en reposo y en tránsito. El cifrado en reposo utiliza AES-256 (Estándar de Cifrado Avanzado con claves de 256 bits), el estándar aprobado por la Agencia de Seguridad Nacional para información clasificada como Alto Secreto. Para el almacenamiento en la nube, el cifrado del lado del servidor (SSE-S3 con el Servicio de Gestión de Claves de AWS) gestiona las claves de cifrado con rotación automática. Para el NAS local, el cifrado de disco completo LUKS (Configuración de Clave Unificada de Linux) o el cifrado respaldado por hardware en unidades de autocifrado proporcionan una protección equivalente.

El cifrado en tránsito utiliza TLS 1.3 (Seguridad de la Capa de Transporte) para todas las transferencias de datos basadas en HTTP (llamadas API, descargas de imágenes, consultas de catálogo). Para las transferencias de NAS a nube, HTTPS con autenticación TLS mutua o rsync basado en SSH sobre SFTP garantiza que los datos no puedan ser interceptados durante la transferencia. Los túneles VPN entre las redes del aeropuerto y los proveedores de la nube añaden una capa de defensa en profundidad.

Registro de Auditoría

Cada acceso a los datos de inspección debe ser registrado de forma inmutable, el registro no puede ser eliminado o modificado después de su creación, incluso por administradores del sistema. Los registros de auditoría capturan: quién (ID de usuario, rol), qué (identificador de datos, nombre de archivo), cuándo (marca de tiempo UTC con precisión de microsegundos), dónde (dirección IP de origen, geolocalización), cómo (punto final de API, aplicación) y resultado (éxito, fallo, motivo de denegación).

Los registros de auditoría se almacenan en almacenamiento de escritura única y lectura múltiple (WORM), ya sea almacenamiento de objetos en la nube con bloqueo de objetos habilitado (Bloqueo de Objetos S3 en modo de cumplimiento) o dispositivos WORM de hardware dedicados. La retención de los registros de auditoría es típicamente de 3 a 7 años según los requisitos regulatorios (FAA Parte 139, disposiciones de seguridad del Anexo 14 de la OACI). La revisión trimestral de los registros de auditoría identifica patrones de acceso anómalos, por ejemplo, un inspector descargando 50,000 imágenes a las 3 AM desde una dirección IP no aeroportuaria.

Soberanía de Datos

La transferencia transfronteriza de datos de inspección aeroportuaria está sujeta a regulaciones de soberanía de datos. Un aeropuerto en un Estado Contratante de la OACI puede utilizar un proveedor de la nube cuyos centros de datos estén ubicados en un país diferente. Las regulaciones de aviación locales pueden prohibir el almacenamiento de datos de inspección de aeródromos fuera de las fronteras nacionales. La arquitectura de gestión de datos debe soportar el geovallado del almacenamiento: especificar que los datos de inspección para el Aeropuerto X deben residir en centros de datos ubicados dentro del País X, y que el personal del proveedor de la nube en otros países no puede acceder a los datos.

Los proveedores de la nube ofrecen opciones de residencia de datos: Regiones de AWS (us-east-1, eu-west-1, ap-southeast-2, etc.), Regiones de Azure y Regiones de Google Cloud. Cada conjunto de datos de inspección lleva una etiqueta de jurisdicción que determina en qué región de la nube puede almacenarse. La plataforma de almacenamiento aplica esta etiqueta: una solicitud de transferencia de datos que movería los datos fuera de su jurisdicción autorizada es denegada a nivel de API.

Sección 7: Integración con Sistemas de Gestión de Activos y Sistemas de Gestión de Pavimentos

Los datos de inspección crean valor solo cuando se integran con los sistemas que planifican, priorizan y ejecutan el trabajo de mantenimiento y rehabilitación. Los objetivos de integración principales son los Sistemas de Gestión de Activos (AMS) y los Sistemas de Gestión de Pavimentos (PMS) .

Arquitectura de Integración

La integración sigue un patrón de publicación-suscripción: la plataforma de gestión de datos de inspección publica datos de condición procesados al AMS/PMS, y el AMS/PMS consume estos datos para análisis, modelado y planificación de trabajo. El intercambio de datos utiliza APIs RESTful JSON con GeoJSON para características geoespaciales (polígonos de deterioro, líneas de grietas, límites de secciones).

La carga útil publicada para cada sección de pavimento incluye: inventario de deterioros, lista de todos los deterioros observados según ASTM D5340, cada uno con código de tipo (1-19 para asfalto, 21-33 para concreto), nivel de severidad (L, M, H), cantidad (pies cuadrados o pies lineales) y coordenadas geográficas, índices de condición, valor de PCI por sección, por rama y por red, con intervalos de confianza derivados de la densidad de muestreo, métricas de detección de cambios, tasa de propagación de grietas, tasa de deterioro del PCI, tasa de crecimiento de desconchado, progresión de roderas, en comparación con todos los estudios anteriores, acciones de M&R recomendadas, recomendaciones de tratamiento automatizadas basadas en el tipo y la severidad del deterioro (sellado de grietas, parcheo, sobrecarpeta, reconstrucción) con costos estimados y vida útil restante si se aplica el tratamiento.

Estándares de Intercambio de Datos

El formato de intercambio de datos AASHTO PRS (Sistema de Recursos de Pavimentos) y el marco de gestión de activos ISO 55000 proporcionan orientación para la integración de datos de inspección. El formato de intercambio define campos requeridos: identificador de sección (globalmente único), fecha de inspección, método de inspección (PCI, PAVER, automatizado), datos de deterioro (tipo, severidad, extensión según ASTM D5340), índice de condición (PCI calculado), calidad de rodadura (IRI en pulgadas/milla si se mide), capacidad estructural (datos de deflexión si se realizó FWD), textura superficial (número de fricción si se mide) y referencias del historial de mantenimiento.

Flujo de Trabajo de Integración con PMS

Paso 1, Sincronización de inventario: El PMS mantiene el inventario de pavimentos autorizado, secciones, ramas, jerarquía de red, historial de construcción, propiedades de los materiales. La plataforma de inspección importa este inventario en el momento de la configuración del estudio y etiqueta todos los datos recopilados con los identificadores de sección del PMS.

Paso 2, Recopilación de datos: El estudio de inspección se ejecuta, generando imágenes, nubes de puntos y mediciones brutas etiquetadas con los identificadores de sección del PMS incrustados en los metadatos.

Paso 3, Procesamiento y análisis: Las imágenes se procesan en ortomosaicos. La detección de deterioro se ejecuta a través de modelos de IA automatizados y/o anotación manual. El PCI se calcula según ASTM D5340. Los resultados se almacenan en la plataforma de gestión de datos de inspección con metadatos completos.

Paso 4, Publicación de datos: Los datos de condición se empaquetan en el formato de intercambio del PMS y se publican a través de API o transferencia de archivos (CSV, XML, JSON con extensiones geoespaciales). La publicación incluye los datos de condición más las métricas de calidad (confianza del estudio, GSD, brechas de cobertura).

Paso 5, Ingestión del PMS: El PMS ingiere los datos de condición, actualiza los registros de condición de las secciones, recalcula las estadísticas a nivel de red, ejecuta modelos de deterioro, actualiza las prioridades de M&R y genera escenarios presupuestarios. El PMS publica de vuelta a la plataforma de inspección: registros de tratamiento (qué se hizo, dónde, cuándo, costo), lo que permite a la plataforma de inspección realizar un seguimiento de la efectividad del tratamiento comparando la condición antes y después del tratamiento.

Integración con PAVEAIR de la FAA

El sistema PAVEAIR de la FAA (el PMS oficial para aeropuertos federalmente obligados que reciben fondos AIP) requiere formatos de datos específicos para la importación de datos de inspección. PAVEAIR acepta datos de condición en archivos planos en formato PAVER, un formato de texto delimitado por columnas que especifica rama, sección, tipo de deterioro, severidad y cantidad. Las plataformas de gestión de datos de inspección que se integran con PAVEAIR automatizan la conversión de los datos de deterioro de ASTM D5340 al formato compatible con PAVEAIR, eliminando los errores de entrada de datos manuales y reduciendo la carga administrativa para los ingenieros de pavimentos aeroportuarios.

Sección 8: Calidad y Validación de Datos

La validación de la calidad de los datos es el guardián que determina si los datos de inspección ingresan al registro permanente o son rechazados para readquisición. Un solo estudio contaminado por imágenes de mala calidad, georreferenciación incorrecta o clasificación errónea de deterioro corrompe la cadena de análisis temporal, todas las comparaciones posteriores no son fiables porque hacen referencia a una línea de base no válida.

Métricas de Calidad

Flujo de Trabajo de Validación

La validación automatizada se ejecuta inmediatamente después de la carga de datos, antes de que comience cualquier procesamiento. Un servidor de control de calidad escanea cada imagen para: integridad de metadatos EXIF (coordenadas GPS presentes y dentro del límite geográfico esperado, marca de tiempo válida, ID de calibración de cámara presente), calidad del histograma (valor de exposición media entre 80-200 en escala 0-255, no más del 0.1% de píxeles recortados en reflejos o sombras), medición de nitidez (MTF50 mayor de 0.3 ciclos/píxel utilizando el método de borde inclinado) y cálculo de GSD a partir de altitud y distancia focal, verificado contra el plan de estudio.

La validación posterior al procesamiento se ejecuta después de la reconstrucción fotogramétrica y el análisis de deterioro. Las comprobaciones clave incluyen: integridad de la cobertura, cada sección de pavimento en el plan de estudio ha sido fotografiada con la superposición adecuada (calculada a partir de la densidad de la nube de puntos dispersa fotogramétrica), precisión de georreferenciación, los residuales de los puntos de control en tierra están dentro de la especificación del estudio (típicamente 0.05 m RMS para RTK, 0.5 m RMS para no RTK) y auditoría de clasificación de deterioro, una muestra aleatoria del 10% de las secciones de pavimento es revisada manualmente por un inspector de PCI certificado que compara las clasificaciones de deterioro automatizadas con la evaluación manual.

Criterios de rechazo: Cualquier estudio que falle en los umbrales de precisión de geolocalización automatizada, integridad de cobertura o calidad de imagen se marca para vuelo inmediato de repetición. Una sección con GSD que exceda 1.5× el valor planificado no puede producir mediciones fiables del ancho de grieta, volar de nuevo esa sección a la altitud correcta es obligatorio antes de que los datos ingresen al archivo permanente.

Sección 9: Requisitos Regulatorios de Retención de Datos

Los requisitos regulatorios para la retención de datos de inspección forman la línea de base alrededor de la cual deben diseñarse todas las políticas de gestión de datos. El incumplimiento de los requisitos de retención expone a los aeropuertos a la pérdida de fondos federales (subvenciones AIP, aprobaciones PFC), suspensión de la certificación (bajo el Artículo 38 del Anexo 14 de la OACI) y responsabilidad legal en caso de incidentes relacionados con el pavimento.

Requisitos de la FAA (Estados Unidos)

La Circular de Asesoramiento 150/5380-7B de la FAA (fechada el 10/10/2014) rige los requisitos de documentación del programa de gestión de pavimentos para aeropuertos federalmente obligados. La AC define los requisitos mínimos de mantenimiento de registros en el Apéndice A:

Los registros del inventario de pavimentos deben incluir el año de construcción, los tipos de material, los espesores de las capas, las dimensiones y los indicadores de financiación AIP/PFC. Estos registros deben mantenerse durante la vida del pavimento porque establecen la línea de base para el análisis estructural, la estimación de la vida útil restante y la selección de la estrategia de M&R.

Los datos de condición del pavimento (estudios PCI, inventarios de deterioro, clasificaciones de condición) deben conservarse durante un mínimo de 5 años a partir de la fecha de inspección. En la práctica, el mínimo de 5 años es inadecuado para el modelado temporal, la FAA alienta a los aeropuertos a conservar los datos de condición durante todo el ciclo de vida del pavimento.

El historial de mantenimiento y rehabilitación debe conservarse, incluidos los tipos de trabajo, las fechas, los costos, las cantidades y la información del contratista. Estos datos permiten el análisis de efectividad: ¿el sellado de grietas aplicado en 2022 realmente prolongó la vida del pavimento como se proyectó?

Los informes de inspección y los resultados de PAVER deben conservarse durante un mínimo de 5 años y estar disponibles para su revisión durante las inspecciones de cumplimiento de la FAA. La FAA puede solicitar registros que se remonten a múltiples ciclos de inspección para evaluar las tendencias de deterioro y la efectividad del programa.

Requisitos de la OACI (Internacional)

El Anexo 14 de la OACI Volumen I, Sección 10 (Mantenimiento de Aeródromos) y el Manual de Servicios Aeroportuarios de la OACI (Doc 9137) Parte 2 (Pavimento) establecen estándares internacionales para el mantenimiento de registros de inspección:

Los operadores de aeródromos mantendrán registros de inspecciones, mantenimiento y reparaciones durante la vida operativa del pavimento más cualquier período adicional especificado por el Estado.

Este estándar sitúa la obligación de retención en todo el ciclo de vida del activo, típicamente 20-40 años para pavimentos aeroportuarios dependiendo de la calidad de la construcción, la carga y las condiciones ambientales. Las autoridades nacionales de aviación pueden extender este período en sus regulaciones de aviación civil.

Los registros de inspección deben incluir: fecha y hora de la inspección, identificación del inspector, métodos de inspección utilizados, resultados de la inspección (tipos de deterioro, severidad, extensión) y cualquier acción correctiva tomada o recomendada.

Los registros de resistencia del pavimento (ACN/PCN) deben mantenerse durante la vida del pavimento y actualizarse siempre que ocurran cambios estructurales (sobrecarpetas, reconstrucción). La notificación de PCN es requerida para la publicación en AIP (Publicación de Información Aeronáutica) y las operaciones de vuelo internacionales.

El PANS-Aeródromos de la OACI (Doc 9981) añade requisitos operativos para los registros de inspección del área de movimiento, especificando que los registros deben conservarse durante al menos 3 años para las inspecciones de rutina y más tiempo para las observaciones graves que involucren deficiencias críticas para la seguridad.

Requisitos de EASA (Unión Europea)

El Reglamento (UE) No 139/2014 de la Comisión (Reglamento de Aeródromos) y sus Medios Aceptables de Cumplimiento (AMC) especifican:

Los operadores de aeródromos establecerán un sistema de gestión de registros para la retención de datos y documentación de aeródromos relevantes para la gestión de la seguridad.

Los datos aeronáuticos (incluidos los datos de inspección de pavimentos) clasificados como esenciales o críticos según los requisitos de calidad de datos de EASA (Reglamento 73/2010) deben conservarse durante 5 años con calidad de datos verificada durante todo el período de retención. Los datos clasificados como rutinarios deben conservarse durante 3 años.

El marco de EASA también exige monitoreo de la integridad de los datos, los datos de inspección almacenados para el cumplimiento normativo deben verificarse periódicamente para detectar su integridad (validación de suma de verificación, detección de corrupción de bits) para garantizar que sigan siendo utilizables durante todo el período de retención.

Sección 10: Gestión de Datos en el Contexto de TarmacView

TarmacView está desarrollando la evaluación de la condición del pavimento de aeródromos, la cual aún no se ofrece como servicio. La plataforma ya planifica vuelos de inspección y captura imágenes georreferenciadas con posicionamiento RTK de aproximadamente ±1 cm. Las imágenes se conservan, por lo que un estudio puede volver a ejecutarse en un modelo más nuevo.

Para una ilustración práctica de cómo estos principios de gestión de datos se aplican en un contexto operativo, considere el flujo de trabajo de inspección en un aeropuerto de centro de conexiones mediano:

El equipo de ingeniería de pavimentos despliega un DJI Matrice 350 RTK con una cámara de fotograma completo Zenmuse P1 de 45 MP para el estudio PCI trienal. El dron sigue la trayectoria de vuelo preplanificada que cubre 3.2 millones de pies cuadrados de pavimento a 100 ft AGL con un 85% de superposición frontal y un 70% de superposición lateral. El vuelo genera 16,438 imágenes que totalizan 287 GB. Durante la carga, un paso de QC automatizado detecta que 142 imágenes del segmento norte de la calle de rodaje B tienen un GSD que excede 1.8 mm/píxel debido a una deriva del sensor de altitud barométrica. El paso de QC marca estas imágenes y genera una orden de trabajo de vuelo de repetición para ese segmento específico de 0.3 millas. Después del vuelo de repetición, el conjunto de datos completo pasa el QC.

La tubería fotogramétrica procesa las imágenes en un ortomosaico a 1 mm de GSD con una precisión de geolocalización de 3 cm RMSE (verificada contra 12 puntos de control en tierra). El modelo de detección de deterioro por IA identifica 1,847 instancias de deterioro individuales en todas las secciones de pavimento. Un inspector de PCI certificado revisa una muestra aleatoria del 10%, encontrando un 92.3% de acuerdo con la clasificación automatizada. El 7.7% de desacuerdo se concentra en el agrietamiento en bloque de baja severidad en una sola sección de plataforma, que el inspector corrige manualmente.

El informe de condición final se publica en el PMS: PCI a nivel de red de 74 (Regular), con 12 secciones en condición Grave (PCI 40-55), 31 secciones en condición Regular (PCI 56-70) y 42 secciones en condición Buena a Excelente (PCI 71-100). La comparación temporal con el estudio de 2022 muestra una disminución del PCI en toda la red de 4.2 puntos, consistente con la tasa de deterioro modelada. Tres secciones muestran un deterioro acelerado (caída del PCI > 8 puntos), lo que desencadena una investigación sobre posibles problemas estructurales.

El conjunto de datos completo, 287 GB de imágenes sin procesar, 42 GB de nube de puntos, 8 GB de ortomosaico, 2 GB de datos de deterioro procesados y el PDF del informe, se almacena en el archivo activo (NAS local) durante 90 días, luego transiciona al almacenamiento en nube templado (S3 Standard-IA) durante 5 años para satisfacer los requisitos de retención de la FAA AC 150/5380-7B. Después de 5 años, transiciona al archivo frío (S3 Glacier Deep Archive) durante el resto del ciclo de vida del pavimento. El catálogo de metadatos retiene el registro buscable completo de forma indefinida.

Este flujo de trabajo, habilitado por una gestión de datos integral, transforma una inspección del año 3 de un ejercicio de cumplimiento a un activo estratégico. El ingeniero del aeropuerto puede consultar 15 años de historial de condición para cualquier sección de pavimento con una sola búsqueda en el catálogo, comparar las tasas de deterioro entre secciones con construcción y carga similares, y defender cada solicitud de financiación de mantenimiento con datos de condición cuantitativos y proyecciones modeladas.