En este escenario los organismos reguladores solo recomiendan la implementación del sistema propuesto, por lo que las aerolíneas pueden decidir si invertir y contratar el servicio es viable para ellas o no. Bajo esta perspectiva, se considera que se capturaría el 10% del mercado. Considerando los datos obtenidos en las secciones anteriores, en la tabla 3-8 se muestran los datos que se utilizarán para calcular el ROI correspondiente a este escenario.
Equipo Precios, en dólares
Gasto recurrente mensual de los aviones $285,276
Gasto recurrente mensual del sistema terrestre $500
Inversión en infraestructura requerida por el avión $5,611,200
Inversión en terrestre $102,000
Tabla 3-8. Inversiones necesarias y gastos recurrentes correspondientes al 10% del mercado
Entonces el ROI bajo las condiciones de este escenario es: 46 meses
Se puede notar que el ROI en ambos escenarios es parecido. Independientemente de cual escenario se adopte, en promedio el periodo de retorno de inversión es de 3 años y medio.
Conclusiones
Esta investigación considera a los enlaces satelitales como el sistema de transmisión del método propuesto. Aprovechando las facultades que desde sus orígenes han poseído, y combinadas con los avances tecnológicos actuales, hacen posible gozar de conexiones de banda ancha en redes móviles, como es considerado la red de comunicaciones a bordo de un avión.
La industria de la aviación ha empleado los servicios que ofrecen los sistemas de comunicación satelital durante varios años, complementando a los sistemas de
59
comunicación tradicionales, y los resultados han beneficiado a la industria en términos de seguridad y control.
El servicio de Swiftbroadband de Inmarsat, además de ofrecer cobertura casi global, fue desarrollado para proveer servicios de comunicación de voz y datos a cualquier usuario móvil de la industria aeronáutica basado en transmisiones bajo el protocolo IP. Los servicios que se pueden ofrecer a bordo de un avión a través de Swiftbroadband son diversos, proporcionando a los pasajeros grandes beneficios así como a la tripulación. Estas características y el ancho de banda disponible por canal permiten considerar a Swiftbroadband como el sistema de comunicaciones que soportará los requerimientos del sistema que se propone en esta investigación. Vale la pena mencionar, que el sistema propuesto esta sujeto a las condiciones de confiabilidad y disponibilidad que proporcione el sistema satelital.
El resultado del análisis de la viabilidad económica del sistema que se propone muestra la clara oportunidad que tiene este sistema para ser adoptado en el mercado.
60
Capítulo 4
Desarrollo de la propuesta
Gracias a la investigación bibliográfica de los sistemas de comunicación en la industria de la aviación, de los sistemas satelitales de acceso móvil a Internet y de los protocolos para transportar tráfico de tiempo real fue posible desarrollar una propuesta para almacenar en tiempo real los datos de vuelo FDR que se almacenan en las cajas negras en un servidor terrestre. Se presenta en primer lugar la investigación realizada para calcular la capacidad de transmisión de información requerida para cumplir con el mínimo de parámetros de vuelo que la FAA exige en la regulación 14 CFR 121.344.
Posteriormente se especifican los componentes del sistema y se describen las funcionalidades de cada uno de ellos. No es necesario especificar el diseño del enlace lógico en las primeras 4 capas del modelo OSI puesto que el equipo propuesto funciona con estándares robustos y populares en la industria, por ejemplo, el protocolo IP y UDP correspondientes a las capas de red y transporte. En capas inferiores el protocolo de la red de acceso interna del avión es WiFi (802.11g) o Ethernet. El equipo satelital, dependiendo del proveedor, asegura la comunicación y control lógico entre el avión y la estación terrestre satelital. Por lo tanto, dadas las características del protocolo UDP, se requiere el diseño de un control del enlace lógico a nivel de las capas de sesión, presentación y aplicación.
4. 1
Cálculo de la capacidad del sistema
Cómo se describió en el capítulo 2, actualmente el FDR se limita a almacenar los parámetros de vuelo enviados por el FDAU. El FDAU le proporciona a la información que proviene de los sensores distribuidos en el avión el formato apropiado para su almacenamiento.
A raíz de diversas investigaciones de accidentes aéreos en donde la carencia de información no permitió definir sus causas, la FAA publicó en 1997 la regulación 14 CFR 121.344 que especifica que ciertos aviones manufacturados a
61
partir del 2002 deberán ser equipados para registrar obligatoriamente mínimo 88 parámetros de vuelo (Federal Aviation Administration, 1996). Esta regulación especificó también el rango, resolución, precisión del sensor recomendada e intervalo de muestreo de cada parámetro (ICAO, International Civil Aviation Organization, 2007).
Considerando que el FDAU digitaliza las señales provenientes de los sensores y las envía al FDR en una ráfaga de datos bajo el protocolo ARINC 717 o 513, fue muy importante para esta investigación conocer la velocidad de la información mínima requerida para almacenar los parámetros especificados en la regulación 14 CFR 121.344, que corresponde a la información que es almacenada por el FDR. Este resultado influyó de forma importante en el diseño del método, ya que fue posible calcular la capacidad mínima requerida del sistema de comunicaciones.
Tomando como referencia los 88 parámetros obligatorios y de acuerdo al rango, resolución y muestreo de cada uno, fue posible obtener la capacidad requerida en términos de bits por segundo. Ésta ráfaga de bits representa los datos (que denominamos datos FDR) que se respaldan en el sistema terrestre propuesto como parte del resultado de esta investigación (ver Anexo A).
En términos generales, para transmitir los datos FDR que representan los parámetros de vuelo se requiere de 752 b/s, pero como se puede notar en el anexo A, los intervalos de muestreo van de 0.125 s para algunos parámetros hasta 64 s para otros, lo que causa que la cantidad de bits generados no sea uniforme en el tiempo (Fig. 4-1).
62
Figura 4-1. Bits generados en un periodo de 64 segundos.
En la figura 4-1 se utilizaron intervalos de 0.125 s, se consideró este valor porque este es el intervalo mínimo de muestreo en algunos parámetros. El intervalo máximo es de 64 s, que es donde se genera la mayor información que es de 980.5 bits.
Los bits siguen un patrón repetitivo cada 4 segundos, en donde la cantidad mínima es de 10 bits, que se generan en ciertos instantes de tiempo, y la máxima de 724 bits, que se genera cada 4 segundos (Fig. 4-2). Se puede notar también como para ciertos intervalos la cantidad de información es mayor que en otros puntos generando fluctuaciones variables de tráfico.
63
Figura 4-2. Patrón en el periodo de 0 a 4 segundos
En la figura 4-3 se observa el resultado de la acumulación de los datos FDR
durante 2.5 segundos, para . La
acumulación se ve afectada por incrementos repentinos cada segundo como consecuencia de los intervalos de muestreo de los parámetros. La cantidad de datos FDR acumulada en 64 segundos es de 48.128 kbits, que es el intervalo de muestreo más alto, dando una velocidad de transmisión de 752 bits/s.
Se podría intentar uniformizar el tráfico pensando en una simplificación del sistema de comunicaciones (evitando las fluctuaciones de tráfico mostradas en la fig. 4-2). Sin embargo, los FDAUs comerciales actuales capturan señales que corresponden a un número superior a los 88 parámetros obligatorios, además, la ráfaga de datos entre el FDAU y el FDR es prácticamente uniforme y su operación está especificada en palabras (de 12 bits cada una) por segundo en el orden de 64 wps, 128 wps, 256 wps, 526 wps y 1024 wps.
Para efectos de clarificar el método de diseño seguido, se asume en las siguientes secciones, una tasa de repetición de datos de 256 wps, es decir
64
3072bits/s. Esta información corresponde a la que se almacena en las cajas negras.
Figura 4-3. Acumulación de bits en un periodo de 2 segundos.
4. 2
Descripción detallada de la propuesta
El método que se propone permitirá capturar, transmitir y almacenar en tiempo real los datos de vuelo que se almacenan en las cajas negras FDR de los aviones. Dicho método funciona sobre una red satelital de comunicaciones. La figura 4-4 muestra la localización de los dos subsistemas que permiten realizar el método dentro de una red satelital interconectada a Internet. El primer subsistema (1.1) se encuentra dentro del avión y tiene la función de extraer, procesar y transmitir los datos de vuelo a través del uplink de la red satelital. El segundo subsistema (1.2) se encuentra en un lugar seguro conectado a Internet mediante un enlace confiable y tiene la función de capturar y almacenar los datos de vuelo, así como proveer servicios de información y de administración a usuarios previamente registrados.
65
Figura 4-4. Red satelital de comunicaciones interconectada a internet
El satélite forma parte de una red satelital móvil global y hace posible el enlace bidireccional entre los sistemas de transmisión aéreo y terrestre. El método propuesto también incluye un protocolo de comunicación de capas superiores que establece la conexión, transmite los datos y monitorea el enlace lógico entre los dos subsistemas.
En la figura 4-5 se puede observar más detalladamente en que consiste el subsistema 1.1 que se coloca entre el FDAU y el FDR con una conexión adicional a la red de acceso local del avión, típicamente usando el protocolo Ethernet. De modo que el subsistema 1.1 consiste en un divisor de potencia y en el servidor del avión. El FDAU se encarga de capturar y digitalizar las señales analógicas provenientes de los sensores ubicados en el avión. La información así obtenida constituye los parámetros de vuelo a los que el FDAU también se encarga de codificar en el formato bifásico de Harvard como está especificado en el estándar ARINC 717 y 513 para ser transmitida hacia el FDR. Los FDAU‘s comerciales típicamente soportan velocidades de transmisión de 128 o 256 palabras por segundo, cada palabra de 12 bits. Por lo tanto la rapidez de los datos es alrededor de sólo 3 kbits/s en banda base lo que permite utilizar un divisor de potencia técnicamente sin restricciones de impedancia para encaminar los datos simultáneamente hacia el servidor del avión y hacia el FDR, lo cual evita
66
alteraciones mayores en la infraestructura ya instalada en los aviones. Los datos capturados en el servidor del avión son procesados de acuerdo al protocolo de comunicación propuesto en la sección 4.3 y son enviados a través de la LAN del avión al sistema de transmisión satelital.
Figura 4-5. Subsistema ubicado en el interior del avión que extrae, procesa y transmite los datos de vuelo
El subsistema 1.2, que se muestra detalladamente en la figura 4-6, se encuentra en un lugar seguro conectado a Internet mediante un enlace confiable. Como se puede notar existen dos tipos de acceso al subsistema, un acceso es por medio de servicios web que esta destinado para usuarios previamente registrados, como aerolíneas, fabricantes de equipo, escuelas de aviación y organismos reguladores que deseen consultar la información almacenada en la base de datos FDR. El otro acceso, que cuenta con un enlace de respaldo, provee el servicio de captura y almacenamiento a los servidores de los aviones previamente registrados. Ambos accesos al subsistema terrestre están protegidos por firewalls para evitar la entrada de tráfico no deseado y proteger la información almacenada.
El subsistema terrestre consiste de 5 servidores y 3 bases de datos interconectados a través de una red de área local. El servidor http provee servicios web a usuarios previamente registrados que después de un proceso de autentificación y autorización pueden consultar la información almacenada de algún vuelo en particular. La base de datos de usuarios provee la información para
67
Figura 4-6. Arquitectura del subsistema terrestre, que almacena los datos FDR y administra la consulta de la información por usuarios autorizados
validar a los usuarios que deseen acceder al servidor web. El servidor de administración de usuarios es el que gestiona la autentificación y la autorización de los usuarios al servidor web.
El servidor de administración de sesiones se encarga de gestionar las operaciones de las sesiones establecidas previamente solicitadas por los servidores de los aviones. El servidor de administración de aviones es el que gestiona la autentificación y autorización del servidor del avión que desea establecer la sesión. La base de datos de aviones provee la información para que el servidor de administración de aviones valide al servidor del avión que solicita el inicio de sesión. Una vez realizada la autentificación y autorización, la base de datos FDR crea los registros para el almacenamiento de los datos enviados por el servidor del avión. El servidor de administración de tráfico administra el tráfico de
68
información entre los servidores para garantizar la coordinación de las operaciones de los servidores y evitar congestionamiento en alguno de los enlaces. Cada servidor y cada base de datos, en realidad puede ser un cluster de servidores y bases de datos por lo que el control de tráfico en la LAN terrestre es necesario.
Los datos enviados y recibidos entre el subsistema terrestre (1.2) y el subsistema a bordo del avión (1.1) son protegidos por medio de una firma digital. Para ello ambos servidores deben intercambiar sus llaves públicas para verificar dicha firma. Este proceso se describe explícitamente en la sección 4.3.3. Las llaves públicas de los servidores de los aviones se almacenan en la base de datos de los aviones. Cuando un servidor de un avión inicie una sesión, la base de datos le asigna un campo para la llave pública que esta asociada con dicho avión. La forma específica en cómo se inician, terminan y controlan las sesiones, se describe en siguiente sección en donde se desarrolla el protocolo de comunicación de capas superiores
4. 3
Diseño del enlace lógico de la propuesta
Considerando que los datos de vuelo FDR se deben enviar a través de una red IP satelital, es indispensable proporcionarle a la ráfaga de datos el tratamiento adecuado para que puedan ser enviados, recibidos y almacenados satisfactoriamente. Para tal efecto se propone encapsular un nuevo protocolo dentro de los encabezados IP/UDP como se muestra en la figura 4-7. La función principal es garantizar el almacenamiento seguro y oportuno de los datos de vuelo FDR en una base de datos terrestre. Se recomienda el protocolo UDP como protocolo de transporte ya que permite una transferencia de datos más rápida comparada con el TCP. Sin embargo, el protocolo UDP no garantiza la recepción de los paquetes y por ello se incluye en el protocolo propuesto un método de monitoreo y control de la transmisión para asegurar la recepción de los paquetes.
IP UDP FDRP Payload: -Mensajes de control -Datos de vuelo FDR 160 bits 96 bits 32 bits Tamaño Variable
Figura 4-7. Encapsulamiento del paquete del protocolo FDRP (Flight Data Remote Protocol) en los protocolos IP/UDP
69
Este nuevo protocolo, llamado Flight Data Remote Protocol (FDRP), tiene la intención de hacer disponible un formato para la transmisión de paquetes construidos a partir de la información capturada del FDAU, así como las reglas y procedimientos para el establecimiento de una sesión, para la transmisión de la información y su monitoreo. Las partes que participan en el intercambio de paquetes a través del protocolo FDRP son el servidor en el avión y el servidor terrestre enlazado a una base de datos en la que se almacenan los datos de vuelo FDR. El protocolo FDRP contempla dos tipos de contenido (payload) en cada paquete: los mensajes de control y los datos de vuelo FDR. Cada paquete transmitido sólo contiene un tipo de contenido. El formato de los encabezados FDRP se describirá en la sección 4.3.2.
4. 3. 1
Operación del protocolo
Se propone que el protocolo FDRP cuente con tres funciones principales que permiten la transmisión de información satisfactoria así como su integridad y autenticidad. Estas funciones son:
1. Establecimiento y cierre de la sesión 2. Transmisión de los datos de vuelo FDR 3. Monitoreo
El objetivo de incluir estas funciones es reducir el formato del encabezado del protocolo propuesto, es decir, se puede emplear un solo formato a diferencia de utilizar tres que desempeñen cada uno una sola función. Esto tiene la ventaja de facilitar la configuración de firewalls y de reducir la latencia que ya es bastante grande en un enlace satelital.