APROBACIN Y CONTROL DEL SOFTWARE INTRODUCCIN

El software embarcado a bordo de una aeronave es algo que no se puede ver o que no se puede tocar, pero que debe ser tratado con el mismo cuidado y consideracin que cualquier parte de la aeronave. Es importante sealar que al hablar del software nos estamos refiriendo tanto al cdigo que es ejecutado por los computadores en el que estn instalados, como a los propios datos que estos programas deben utilizar para su correcto funcionamiento. El trmino tambin se refiere a los sistemas operativos que estn embebidos en los computadores embarcados, y permiten su funcionamiento y el interfaz con el resto de equipos.

Las consecuencias de un fallo de un programa Software pueden variar desde efectos insignificantes, que no afectan a las prestaciones de la aeronave y sus sistemas, o al confort de sus pasajeros, hasta consecuencias que pueden ser catastrficas por originar fallos en sistemas crticos para la operacin segura de la aeronave. Por ello es muy importante entender la importancia que tiene aplicar unos procedimientos de verificacin y validacin del software que puedan garantizar que no existe riesgo de que se produzcan condiciones de fallo peligrosas o catastrficas.

APROBACIN DEL SOFTWARE Certificacin de Tipo (TC/STC):

La aprobacin del diseo de una aeronave y sus sistemas embarcados, se realiza mediante la emisin de un certificado de tipo (TC) que se otorga al titular del diseo. Las modificaciones que se realizan en las aeronaves y sus sistemas, cuando son realizados por empresas que no son las titulares del certificado de tipo original, se realiza mediante un certificado de tipo suplementario (STC). Durante ambos procesos el titular del certificado es responsable de demostrar un plan con los requisitos de seguridad establecidos en el mbito de certificacin aplicable, segn el tipo de aeronave. Por ejemplo para aviones de transporte son el FAR 25 en los Estados Unidos y CS25 en la Comunidad Europea (CE).

La aprobacin del software embarcado a bordo de una aeronave es por tanto una parte del proceso de certificacin de una aeronave y sus sistemas, cuyo objetivo es demostrar que se cumplen con los requisitos de

seguridad mnimos establecidos en el correspondiente cdigo de aeronavegabilidad.

La criticidad (Criticality) de las funciones que son realizadas por un paquete de software depende de la severidad de las consecuencias de sus fallos. Para el DO178B / ED12B el rango de estos niveles vara desde el nivel A hasta el Nivel E, que corresponde a que se pueda clasificar la severidad de los posibles fallos como catastrficos o sin efectos (Figura 2).

Calificacin de equipos (Sistema TSO):

Cuando un equipo o componente de una aeronave se quiere desarrollar bajo los estndares tcnicos prescritos y aprobados mediante una Orden de Especificacin Tcnica (TSO), tambin se deben aplicar procedimientos para la verificacin y validacin del software de acuerdo con un estndar aceptable por la autoridad de aviacin competente (EASA, FAA). Las TSO aplicables a todos los equipos de avinica que requieren aprobacin por parte de la autoridad se encuentran especificados en la CSETSO publicada por la EASA. En todas las especificaciones de TSO se establece al documento DO178B/ED12B como estndar aceptable para realizar validacin y verificacin del software embarcado y as obtener la certificacin/aprobacin del equipo o componente.

La aprobacin de un equipo, incluyendo su hardware y software, mediante una TSO, no significa la aprobacin de su instalacin en una aeronave, pero facilita significativamente este proceso. La responsabilidad de la aprobacin mediante una TSO es del fabricante original del equipo (OEM), mientras que la aprobacin de la instalacin de su equipo es responsabilidad del titular del certificado de tipo (TC), o del titular de un STC.

Proceso de verificacin de la Seguridad de un Sistema:

Como vemos en la figura 1 el proceso de la verificacin de la seguridad de un sistema empieza en las decisiones de diseo a nivel de aeronave, como parte de una estrategia global para garantizar la seguridad de la aeronave durante su operacin en vuelo. Este proceso se lleva a cabo de acuerdo con el material gua publicado por las autoridades de certificacin y procedimiento recomendados por industria ( AMC 25.1309 Y SAE ARP 4761.)

Una vez establecidos los objetivos de seguridad para cada sistema, se analiza la arquitectura del sistema y se establecen unos niveles de aseguramiento de desarrollo (DAL), de acuerdo con los criterios establecidos en el documento SAE ARP 4754. Estos niveles de aseguramiento del desarrollo se distribuyen a nivel de cada equipo y componente del sistema, distinguiendo la parte soporte fsico Hardware de la parte del soporte lgico Software( Figura 1).

Clasificacin del Software:

De acuerdo con DO178B/ED12B, el software embarcado en una aeronave se puede clasificar en cinco niveles, de acuerdo con las posibles consecuencias de un fallo en la aeronave, la tripulacin y el pasaje. Estos niveles tambin se designan como niveles de aseguramiento del desarrollo (DAL), con objeto de mantener cierta concordancia con la terminologa de los niveles que se asignan a los equipos que tienen incorporados componentes electrnicos complejos a los que se aplica procesos similares de desarrollo (DO254 / ED80).

Como vemos en la figura 2 el nivel ms crtico es el Nivel A, que tiene consecuencias catastrficas para la aeronave sus ocupantes, mientras que en nivel ms bajo (Nivel E) no tiene ningn impacto significativo en la operacin segura de la aeronave. Entre estos dos niveles, el grado de severidad seestablece teniendo cuenta la capacidad de la tripulacin para poder hacer frente a la situacin adversa provocada por el fallo de un componente o equipo, y controlar la aeronave.

No obstante es interesante sealar que el nmero de paquetes de Software nivel E que se estn desarrollando se estn incrementando para satisfacer las necesidades del pasaje respecto a sistemas de entretenimiento y comunicaciones, pero la criticidad de estos sistemas se puede ver incrementada si de alguna manera se integran con otros sistemas crticos o esenciales para operacin segura de la aeronave.

Ejemplos de Niveles de Software A modo de ejemplo podemos ver en la siguiente tabla (3) como se podran clasificar algunos equipos y sistemas de una aeronave de acuerdo con el nivel de de seguridad que se debe aplicar, teniendo en cuenta las consecuencias de sus fallos.

Breve Introduccin al estndar DO178B / ED12B:

Que es el DO178B/ED12B El RTCA DO178B, o su homlogo EUROCAE ED12B es el ltimo estndar de verificacin y validacin del software aceptado por las autoridades de certificacin EASA /FAA, y ha sido desarrollado conjuntamente por expertos de la industria y las agencias de los Estados Unidos y Europa. A la hora deaprobar un paquete de software que va a ser embarcado en un equipo o componente de una aeronave, se pueden utilizar el RTCA DO178B/ED12B o el EUROCAE ED12B de forma indistinta, pero para simplificar este captulo vamos a utilizar la referencia ms extendida dentro de la industria de Avinica, DO178B/ED12B, el cual ha sido oficialmente reconocido como un estndar por la organizacin internacional de estandarizacin ISO.

DO178B/ED12B establece los procesos que se deben aplicar durante el ciclo de vida de un paquete de software con el objetivo de garantizar que cada lnea de cdigo esta libre de errores y que en el proceso de codificacin y ensamblado del cdigo ejecutable no hay riesgo de incluir cdigo extrao ajeno al proceso de desarrollo.

Los beneficios de aplicar el DO178B/ED12B, aparte que es imprescindible para la aprobacin de equipos que van ser instalados a bordo de aeronaves, son: Permite verificar la calidad y integridad del software, Permite una mayor reusabilidad, Disminuir los costes de mantenimiento, Conseguir una integracin ms rpida con l soporte fsico (Hardware) en el que va a ser instalado, y Obtener una mayor portabilidad.

MODIFICACIN DEL SOFTWARE EMBARCADO

Debido a los continuos avances tcnicos, la modificacin del software embarcado por los operadores de las aeronaves se puede considerar como un procedimiento comn. Estos procedimientos reducen el tiempo de parada de la aeronave para mantenimiento, e incrementa la eficacia de las tareas de mantenimiento de los equipos. Cuando se ha de considerar modificaciones y actualizaciones sobre el software, es importante distinguir entre el cdigo ejecutable y los datos que son usados por este cdigo ejecutable.

Software Actualizable sobre el Terreno (FLS):

El Software Actualizable sobre el terreno (FLS), "Field Loadable Software, es cdigo ejecutable o un paquete de datos que puede ser cargado en un computador (LRU), mientras ste se encuentra instalado dentro de la aeronave, y esta se encuentra en una rampa o un hangar de un aeropuerto.

El paquete de software FLS se puede cargar en un equipo de la aeronave (LRU) por personal de mantenimiento autorizado, de acuerdo con un procedimiento definido en el Manual de Mantenimiento de la Aeronave (AMM), o un procedimiento aprobado incluido en un Boletn de Servicio (SB) preparado por el fabricante de la aeronave, y aprobado por la autoridad competente sobre el diseo, o en su nombre por el propio fabricante de equipo, cuando este disponga de estos privilegios mediante la aprobacin de su organizacin de diseo (DOA).

Tipos de Paquetes Software Actualizable sobre el Terreno

Podemos diferenciar tres tipos de FLS: Partes de la Aeronave con Software Actualizable(LSAP) Loadable Software Aircraft Parts Software Modificable por el Usuario(UMS) User Modifiable Software Software con Opciones Seleccionables (OSS) Option Selectable Software Partes de la Aeronave con Software Actualizable (LSAP) Un software tipo LSAP, es un software que es esencial para la operacin segura de la aeronave, o requerido para cumplir con requisitos de operacin especficos. Es decir para demostrar cumplimiento con requisitos especficos de aeronavegabilidad o con reglamentos de operaciones. Un paquete LSAP no suele ser considerado como un componente del hardware en el que es instalado (Target Hardware), pero es parte del diseo aprobado de la aeronave y por lo tanto es un componente de la aeronave que requiere una documentacin formal controlada para su autorizacin de puesta en servicio.

Ejemplos tpicos de soportes fsicos (Target Hardware) en los que se puede instalar un paquete LSAP incluyen: Electronic Flight Instrument Systems (EFIS) Flight Guidance Computers (FGC) Electronic Engine Controls (EEC) Digital Flight Data Acquisition Units (DFDAU) Auxiliary Power Units Electronic Control Unit (ECU)

Software Modificable por el Usuario (UMS) El trmino software modificable por el usuario (UMS) es software que el titular diseo aprobado (TC/STC) ha declarado que puede ser modificado por el usuario. Las modificaciones que pueden ser realizadas por el usuario podran incluir modificaciones de los datos, o modificaciones del cdigo ejecutable, o ambas.

El titular del certificado de tipo y fabricante de una aeronave establece qu paquetes de software pueden ser modificados por el usuario, dentro de las limitaciones que son tenidas en cuenta durante elproceso de certificacin de la aeronave y sus equipos. Un paquete de software UMS normalmente pueden ser actualizados por el operador de la aeronave, una organizacin

responsable de su diseo (DOA), o por el fabricante del equipo, sin que la autoridad competente que emiti la aprobacin al diseo de la aeronave y sus sistemas tenga que realizar revisiones y aprobaciones adicionales.

Ejemplos tpicos de soportes fsicos (Target Hardware) en los que se pueden actualizar o modificar UMS son: Aircraft Condition Monitoring Systems (ACMS) InFlight Entertainment Systems (IFE)

Software con Opciones Seleccionables (OSS) Un paquete de software con opciones de aplicacin que puedan ser seleccionadas (Option Selectable Software OSS) es un paquete que contiene combinaciones de mdulos y rutinas aprobados y validados que pueden ser activados o modificados por el operador de la aeronave dentro de las limitaciones establecidas durante la aprobacin de su diseo de tipo (TC/STC) obtenida por su titular. Estas opciones pueden ser seleccionadas por la tripulacin de vuelo o activadas por el personal de tierra.

Ejemplos tpicos de soportes fsicos para software OSS se suelen encontrar en los sistemas de Avinica Modular Integrada (IMA), presentes en aeronaves de ultima generacin (B777, A380), o en aeronaves en las que se ha sustituido toda la avinica convencional por un sistema integrado de avinica (Honeywell EPIC, Rockwell Collins Proline, Thales Topdeck, Garmin G1000, etc.).

Aprobacin de Software FLS: El DO178B/ED12B proporciona consideraciones y criterios para el desarrollo de los sistemas cuyo software puede ser modificado por el operador. Estos criterios se pueden resumir en los siguientes puntos: Se debe demostrar que tanto la configuracin de hardware como la configuracin de software, han sido verificadas/probadas conjuntamente durante el proceso de verificacin. Se debe establecer un proceso de gestin de la configuracin (Configuration Management (CM)) que permita asegurar la correcta configuracin de la instalacin. Si en una misma aeronave existiesen equipos y componente redundantes, con software modificable por el operador, se deben establecer requisitos

para simultanear diferentes cargas de software sobre esos componentes, y considerar sus efectos sobre la despachabilidad de la aeronave. Se debe establecer un procedimiento para asegurar que el software cargado es el software aprobado, y que no est corrupto mediante un chequeo de la redundancia cclico (Cyclic Redundancy Check (CRC)).

Diferentes algoritmos CRC dan diferentes niveles de aseguramientos de que los datos han sido transferidos correctamente. El solicitante y la autoridad que va a probar esos procedimientos deberanasegurarse de que el algoritmo usado es suficiente para el nivel de integridad requerido para el software que va ser cargado.

Datos almacenables en una base de datos sobre el terreno (DFLD):

Un paquete de datos DFLD (Database Field Loadable Data), es un conjunto de datos que se puede cargar en la memoria de un computador instalado en una aeronave. Es importante sealar que la base de datos es un elemento embebido dentro de un computador, el cual no es modificable estando la aeronave en servicio, y por lo tanto la carga de datos en la base de datos es simplemente la escritura o sobreescritura sobre viejos datos, de los nuevos datos distribuidos en fichero proporcionado por el fabricante.

Es importante sealar que la actualizacin de la base de datos de una aeronave puede tener aspectos relacionados con las prestaciones de la misma, como por ejemplo cuando se actualiza la base de datos con los parmetros de las prestaciones del motor de la aeronave, en un sistema gestor de vuelo (FMS). Por lo tanto si los datos usados para esta actualizacin no son vlidos o se han corrompido, podra dar lugar a que se produjesen comportamientos errticos o fuera de las condiciones aprobadas para operacin segura de la aeronave.

Ejemplos tpicos de computadores a bordo de aeronaves que pueden recibir datos (DFLD) para modificar o actualizar su base de datos son: Flight Management Computer (FMC) Terrain Awareness Warning System (TAWS) Sistemas basados en la Avinica Modular Integrada (IMA)

VERIFICACIN DE LOS DATOS Mtodos de Deteccin

Mtodo Checksum Un mtodo muy simple para proteger la integridad de datos, verificando que no hayan sido corrompidos es una suma de verificacin o Checksum, que es una forma de control de redundancia. El mtodo se emplea en los sistemas de comunicacin (Internet, comunicacin de dispositivos, etc.) o para datos almacenados (archivos comprimidos, discos porttiles, etc.). El proceso consiste en sumar cada uno de los componentes bsicos de un sistema (generalmente cada byte) y almacenar el valor del resultado. Posteriormente se realiza el mismo procedimiento y se compara el resultado con el valor almacenado. Si ambas sumas concuerdan, se asume que los datos probablemente no han sido corrompidos.

Comprobacin de redundancia cclica (CRC) La comprobacin de redundancia cclica (CRC) es un tipo de funcin que recibe un flujo de datos de cualquier longitud como entrada y devuelve un valor de longitud fija como salida. Este trmino sueleser usado para designar tanto a la funcin como a su resultado. Las CRC pueden ser usadas como suma de verificacin para detectar la alteracin de datos durante su transmisin o almacenamiento.

El CRC es un cdigo de deteccin de errorcuyo clculo es una larga divisin de computacin en el que se descarta el cociente y el resto se convierte en el resultado. Las CRC son populares porque su implementacin en hardware binario es simple, son fciles de analizar matemticamente y son particularmente efectivas para detectar errores ocasionados por ruido en los canales de transmisin.

Instrucciones de Mantenimiento y el marcado de partes:

Las Instrucciones de instalacin y mantenimiento, y marcado de un paquete de datos o cdigo ejecutable FLS / DFLD es responsabilidad del titular de la aprobacin del diseo aplicable al producto, equipo o componente (el fabricante), y se debe realizar de acuerdo con las reglas de aplicacin incluidas Parte 21 de la EASA.

Los manuales de mantenimiento de la aeronave (AMM) elaborados por el titular del Certificado de Tipo (TC), o las instrucciones para la aeronavegabilidad continuada (ICAs) elaboradas por los titulares de un STC, deberan incluir los procedimientos que deben ser seguidos para realizar el mantenimiento de equipos de a bordo a los que se pueda cargar paquetes de datos o cdigo ejecutable (FLS / DFLD).

Los manuales de mantenimiento de la aeronave (AMM), o las instrucciones para la aeronavegabilidad continuada (ICAs), deben incluir instrucciones que permitan al personal de mantenimiento verificar la configuracin del Part Number (P/N), antes y despus de que se haya realizado una tarea de mantenimiento en dicho equipo. Si la carga de software no puede ser verificada, o el procedimiento no ha dado los resultados esperados, o ha fallado, el sistema afectado no se debera considerar como operativo y la aeronave no debera ser despachada. En algunos casos la lista de equipos mnimos para el despacho (MEL), podra permitir despachar el avin con algn equipo no operativo. En el caso de equipos cuyo Part Number de software no pueda ser verificado, en la MEL se debera indicar si el equipo afectado podra ser inutilizado y la aeronave podra ser puestas en servicio.

Para equipos embarcados que tengan slo un Part Number, que representa una configuracin especfica de software y hardware, la identificacin de la unidad en la placa del equipo debera ser cambiada cuando se cargue el nuevo software. Cuando se realice una carga del nuevo software, el software instalado en el computador afectado debera ser verificado electrnicamente, y comprobar que tanto el P/N del software como el del hardware estn aprobados.

DISTRIBUCIN y CONTROL SOFTWARE FLS y DFLD Mtodos de Distribucin:

El operador es responsable de establecer un proceso para asegurar que los datos recibidos son datos aprobados y que estos datos no han sido corrompidos durante proceso de distribucin o transferencia electrnica, mediante el uso de una Revisin Redundante Cclica (CRC). Para cumplir con este punto tambin se pueden utilizar las recomendaciones del fabricante del equipo y las herramientas recomendadas para conseguir estos propsitos.

Los paquetes de software y datos del tipo FLS y DFLD pueden ser distribuidos mediante varios mtodos que pueden incluir uno o combinacin de los siguientes:

Mediante Medios Fsicos Es un proceso por el cual FLS o los ficheros de una base de datos son transferidos desde la organizacin de produccin o el proveedor, a un lugar remoto usando soportes fsicos de almacenamiento como por ejemplo Floppy Disk, un CDROM, Mdulos Reemplazables a Bordo (OBRM), o una memoria flash.

Una vez recibidos los paquetes de datos debern ser revisados para comprobar que no tengan un virus, y debern ser almacenados en una localizacin controlada, evitando que sean instalados inmediatamente en los sistemas de la aeronave. El fabricante del equipo afectado deber proporcionar instrucciones de cmo se debera verificar la existencia de un virus.

El mtodo de transporte debera ser el apropiado para asegurar que no se produce un dao en el soporte fsico de almacenamiento o corrupcin de sus datos. Si existiese alguna duda, no se debera cargar en los sistemas de la aeronave. Los paquetes de datos siempre se deben acompaar la documentacin que autoriza su puesta en servicio (EASA Form 1 o equivalente)

Transferencia Electrnica: Proceso por el cual, mediante el uso de un ordenador porttil, un computador de mano o un Portable Data Loader (PDL) y una conexin fsica temporal realizada mediante un cable de enlace de datos de serie, se realiza una transferencia de los datos a un computador de abordo.

Durante el proceso de carga el mecnico puede controlar a travs de un Display la unidad a la que est destinada la carga. Adems el uso de estas unidades de carga permite almacenar gran cantidad de paquetes a ser instalados, y de esta forma la aeronave puede llevar consigo su propio software.

Sistemas de Distribucin Electrnica (EDS)

Con objeto de agilizar y disminuir el retraso en la distribucin de los paquetes de software y datos que se instalan en las aeronaves, se est desarrollando la distribucin electrnica directamente del fabricante al operador, a un lugar remoto sin el empleo de medios de almacenamiento masivo, como por ejemplo a travs de Internet.

Requisitos para la instalacin:

Un paquete FLS puede ser instalado en una aeronave mediante un boletn de servicio (SB), o mediante una Orden de Ingeniera (EO), o cualquier otro medio aprobado por la autoridad de certificacin. Si la aprobacin para el paquete de datos o cdigo ejecutable FLS ha sido obtenida mediante un certificado de tipo (TC) o un certificado equipo suplementario (STC), o una Orden de Especificacin Tcnica (TSO),el documento de instalacin debera ser aprobado por la correspondiente autoridad de certificacin y debera especificar los siguientes elementos: a) La aeronave y la configuracin de equipos aplicable. b) Los procedimientos de verificacin para asegurar que el software ha sido correctamente carado en el computador aprobado y es compatible (Target Hardware). c) Proporcionar los procedimientos de verificacin que se han de aplicar despus de la carga.

d) Las acciones que deben ser tomadas en el caso de que la carga no haya sido satisfactoria. e) Referencia a los procedimientos de carga aprobados. f) Procedimientos para realizar la entrada en el registro de mantenimiento, de forma que se permita mantener un adecuado control de configuracin. g) Referencia a las pginas o suplementos afectados del manual de vuelo y del manual de operacin de la aeronave.

Documentacin Autorizada:

para

la

Puesta

en

Servicio

Mtodos de puesta en servicio autorizada Hay que resaltar que la documentacin para autorizacin y distribucin depende de si FLS o DFLD es requerido para demostrar cumplimiento con requisitos de aeronavegabilidad requeridos o disposiciones reglamentarias para la operacin comercial. Si el FLS o el DFLD no son necesarios para verificar cumplimiento con requisitos de certificacin u operacin, el correspondiente Certificado de conformidad ser suficiente. En los otros casos ser necesario acompaar al artculo del correspondiente certificado de autorizacin para su puesta en servicio.

Es decir que cualquier paquete de cdigo ejecutable que vaya de ser cargado en una aeronave debe estar acompaado de un certificado EASA Form 1 o FAA 81103. Ejemplos de LSAP que requieren un EASA Form 1 podran ser: Controles electrnicos del motor (EEC) Unidad de Adquisicin de Datos de Vuelo Digital (DFAU) Computadores para el da dos de vuelo (FGC) Avinica Modular Integrada (IMA)

Igualmente cualquier paquete de datos DFLD que pueda afectar al funcionamiento de un equipo esencial para la operacin segura de aeronave o que sea requerida para cumplir con requisitos de operacin especficos debern estar acompaado del correspondiente EASA Form 1 o FAA 81103. Ejemplos de bases de datos DFLD a las que necesitan un EASA Form 1 son: las computadoras del sistema de gestin de vuelo (FMC)

 la base de datos terrenal del sistema de aviso de proximidad a tierra (TAWS)

Documentacin navegacin:

para

las

bases

de

datos

de

Para la distribucin autorizada de una base de datos de navegacin (NDB), que es requerida para una aprobacin de tipo operacional (BRNAV, PRNAV, RNP) el artculo deber ir acompaado de la carta de aceptacin Letter of Acceptance LOA Tipo 1 o Tipo 2 emitido por la autoridad competente, ya que en estos casos no hace falta un documento equivalente a un EASA Form 1.

El titular de una LOA Tipo 1 no tiene por qu distribuir datos para las bases de datos de navegacin directamente a los usuarios finales. El titular de una LOA Tipo 2 puede distribuir datos para base de datos de navegacin directamente a los operadores y usuarios finales. El titular de una LOA Tipo 2 puede recibir datos directamente de las agencias autorizadas, como por ejemplo los Servicios de Informacin Aeronutica estatales (AIS), o puede obtener los datos a travs de un titular de una LOA Tipo 1.

Obtencin y documentacin de paquetes FLS y DFLD

Paquetes iniciales FLS y DFLD Los paquetes iniciales FLS y DFLD se obtienen normalmente durante la entrega de un avin nuevo y estn ya instalados en los soportes fsicos a los que estn destinados (LRU o LRM), o mediante la documentacin que acompaa la aeronave, en un formato de soporte de almacenamiento fsico. Hay que sealar que los P/N de los equipos hardware, no tiene por qu indicar necesariamente cul es el P/N del Software cargado.

Paquetes LSAP La obtencin de paquetes LSAP se debe realizar a travs de una fuente autorizada, usando P/N especificado por el fabricante de la aeronave, y acompaado del correspondiente EASA Form 1. Para confirmar que un P/N especfico est aprobado se deber consultar con documentos del fabricante de la aeronave como por ejemplo; Catlogo ilustrado de partes (IPC), Boletines de Servicio (SB), o

 Cartas de Informacin de Servicio (SIL), o Ordenes ingeniera aprobadas por el titular TC o un STC.

Paquetes DFLD La actualizacin de datos aplicables a las bases de datos de navegacin, bases de datos del terreno, ode las prestaciones de un modelo de motor, deben ser adquiridas de una fuente autorizada que sea aceptable para el fabricante de equipo en el que van a ser instaladas (Target Hardware), y acompaadas de la documentacin y del medio de almacenamiento que contiene los ficheros de datos y que debe identificarlos de forma inequvoca. Los medios de almacenamiento de un paquete de datos DFLD deben ser registrados con la identificacin de la organizacin que los ha proporcionado y los sellos de control y conformidad de calidad aplicables.

Control de Aeronave:

Configuracin

del

Software

de

la

Para poder controlar el estado de configuracin de estos paquetes de software, el operador deber mantener al da un Documento de Control de Configuracin de cada aeronave con los Part Numbers (P/N) de cada uno de los paquetes de software que han sido instalados en la aeronave, junto con las referencias que permitan verificar que dichos paquetes estn certificados para su instalacin en la aeronave afectada.

Este documento se suele denominar Aircraft Configuracin List (ACL), y en l se listan todas las unidades reemplazables en lnea (LRU) o mdulo reemplazables en lnea (LRM) identificndolas como partes con software actualizable (LSAP) que son aplicables a una aeronave en particular. Esta lista debera contener los datos proporcionados por el titular del certificado de tipo (TC), o por el fabricante de equipo original (OEM), mediante los Boletines de Servicio (SB), cartas de informacin de servicio (SIL) o el Catlogo Ilustrado de Partes (IPC). Por lo tanto el operador debera mantener un registro que proporcione la siguiente informacin: La versin actual del Software FLS y los datos DFLD que han sido instalados. Las aeronaves en las cuales han sido instalados estos paquetes de software y datos. Los equipos y sistemas de la aeronave a los que estos paquetes de software y datos son aplicables.

 Las funciones que estos paquetes de software y datos realiza. Donde y con qu formato se han instalado estos paquetes de software y datos, incluyendo el nombre de la persona que es responsable de ello. Quien puede decidir si es necesario actualizar un equipo o sistema y quien es el responsable de autorizar esta actualizacin.

Para confirmar que paquete de software est cargado en un sistema de la aeronave, se debe realizar una comprobacin del Part Number (P/N) y la versin del software que est cargado en un sistema, mediante el uso de una terminal de acceso de mantenimiento al correspondiente bus de datos, o mediante la propia unidad de control del dispositivo de presentacin asociado al sistema, accediendo al men de mantenimiento, o cualquier otro dispositivo diseado para cumplir con este propsito.

Es importante tener en cuenta que en caso de duda sobre el estado de una actualizacin, paquete de software o de datos, como por ejemplo tener dudas sobre si no estn corruptos, o si es la versin adecuada para una configuracin de aeronaves en particular, no se debera intentar hacer la transferencia de estos datos. De hecho, se debera poner en cuarentena dicho paquete y mantenerlo pendiente de verificar su integridad y/o confirmar la versin aplicable con el proveedor.

Todos estos procedimientos relacionados con la adquisicin, la modificacin, la incorporacin de paquetes de software a una flota de aeronaves deberan ser incluidos en un captulo del documento de exposicin de la gestin del mantenimiento (MME) que la compaa debe preparar para ser autorizada por el operador areo (AOC).

Font: AESA (Agencia Espaola de Seguridad Area) Informacin a personal con licencia LMA Parte 66