P. 1
Aprovacion y Control Software

Aprovacion y Control Software

|Views: 22|Likes:

More info:

Published by: Olga Rodriguez MOradillo on Aug 20, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

07/05/2014

pdf

text

original

APROBACIÓN Y CONTROL DEL SOFTWARE INTRODUCCIÓN

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 consideración que cualquier parte de la aeronave. Es importante señalar que al hablar del software nos estamos refiriendo tanto al código que es ejecutado por los computadores en el que están instalados, como a los propios datos que estos programas deben utilizar para su correcto funcionamiento. El término también se refiere a los sistemas operativos que están 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 catastróficas por originar fallos en sistemas críticos para la operación segura de la aeronave. Por ello es muy importante entender la importancia que tiene aplicar unos procedimientos de verificación y validación del software que puedan garantizar que no existe riesgo de que se produzcan condiciones de fallo peligrosas o catastróficas.

APROBACIÓN DEL SOFTWARE Certificación de Tipo (TC/STC):
La aprobación del diseño de una aeronave y sus sistemas embarcados, se realiza mediante la emisión de un certificado de tipo (TC) que se otorga al titular del diseño. 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 certificación aplicable, según el tipo de aeronave. Por ejemplo para aviones de transporte son el FAR 25 en los Estados Unidos y CS‐25 en la Comunidad Europea (CE).

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

pero facilita significativamente este proceso. La criticidad (“Criticality”) de las funciones que son realizadas por un paquete de software depende de la severidad de las consecuencias de sus fallos. Las TSO aplicables a todos los equipos de aviónica que requieren aprobación por parte de la autoridad se encuentran especificados en la CS‐ETSO publicada por la EASA. mientras que la aprobación de la instalación de su equipo es responsabilidad del titular del certificado de tipo (TC). que corresponde a que se pueda clasificar la severidad de los posibles fallos como catastróficos o sin efectos (Figura 2). En todas las especificaciones de TSO se establece al documento DO‐178B/ED‐12B como estándar aceptable para realizar validación y verificación del software embarcado y así obtener la certificación/aprobación del equipo o componente. Para el DO‐178B / ED‐12B el rango de estos niveles varía desde el nivel A hasta el Nivel E. La aprobación de un equipo. mediante una TSO.1309 Y SAE ARP 4761. incluyendo su hardware y software. Calificación de equipos (Sistema TSO): Cuando un equipo o componente de una aeronave se quiere desarrollar bajo los estándares técnicos prescritos y aprobados mediante una Orden de Especificación Técnica (TSO).) . Este proceso se lleva a cabo de acuerdo con el material guía publicado por las autoridades de certificación y procedimiento recomendados por industria ( AMC 25. Proceso de verificación de la Seguridad de un Sistema: Como vemos en la figura 1 el proceso de la verificación de la seguridad de un sistema empieza en las decisiones de diseño a nivel de aeronave.seguridad mínimos establecidos en el correspondiente código de aeronavegabilidad. o del titular de un STC. FAA). como parte de una estrategia global para garantizar la seguridad de la aeronave durante su operación en vuelo. La responsabilidad de la aprobación mediante una TSO es del fabricante original del equipo (OEM). no significa la aprobación de su instalación en una aeronave. también se deben aplicar procedimientos para la verificación y validación del software de acuerdo con un estándar aceptable por la autoridad de aviación competente (EASA.

de acuerdo con las posibles consecuencias de un fallo en la aeronave. de acuerdo con los criterios establecidos en el documento SAE ARP 4754. Estos niveles también se designan como niveles de aseguramiento del desarrollo (DAL). Estos niveles de aseguramiento del desarrollo se distribuyen a nivel de cada equipo y componente del sistema. con objeto de mantener cierta concordancia con la terminología de los niveles que se asignan a los equipos que tienen incorporados componentes electrónicos complejos a los que se aplica procesos similares de desarrollo (DO‐254 / ED‐80). el software embarcado en una aeronave se puede clasificar en cinco niveles.Una vez establecidos los objetivos de seguridad para cada sistema. . distinguiendo la parte soporte físico “Hardware” de la parte del soporte lógico “Software”( Figura 1). Clasificación del Software: De acuerdo con DO‐178B/ED‐12B. la tripulación y el pasaje. se analiza la arquitectura del sistema y se establecen unos niveles de aseguramiento de desarrollo (DAL).

que tiene consecuencias catastróficas para la aeronave sus ocupantes. Ejemplos de Niveles de Software A modo de ejemplo podemos ver en la siguiente tabla (3) como se podrían clasificar algunos equipos y sistemas de una aeronave de acuerdo con el nivel de de seguridad que se debe aplicar. mientras que en nivel más bajo (Nivel E) no tiene ningún impacto significativo en la operación segura de la aeronave. Entre estos dos niveles.Como vemos en la figura 2 el nivel más crítico es el Nivel A. . No obstante es interesante señalar que el número de paquetes de Software nivel E que se están desarrollando se están incrementando para satisfacer las necesidades del pasaje respecto a sistemas de entretenimiento y comunicaciones. y controlar la aeronave. el grado de severidad seestablece teniendo cuenta la capacidad de la tripulación para poder hacer frente a la situación adversa provocada por el fallo de un componente o equipo. teniendo en cuenta las consecuencias de sus fallos. pero la criticidad de estos sistemas se puede ver incrementada si de alguna manera se integran con otros sistemas críticos o esenciales para operación segura de la aeronave.

se pueden utilizar el RTCA DO‐178B/ED‐12B o el EUROCAE ED‐12B de forma indistinta. A la hora deaprobar un paquete de software que va a ser embarcado en un equipo o componente de una aeronave. el cual ha sido oficialmente reconocido como un estándar por la organización internacional de estandarización ISO. DO‐178B/ED‐12B establece los procesos que se deben aplicar durante el ciclo de vida de un paquete de software con el objetivo de garantizar que cada línea de código esta libre de errores y que en el proceso de codificación y ensamblado del código ejecutable no hay riesgo de incluir código extraño ajeno al proceso de desarrollo. y ha sido desarrollado conjuntamente por expertos de la industria y las agencias de los Estados Unidos y Europa. o su homólogo EUROCAE ED‐12B es el último estándar de verificación y validación del software aceptado por las autoridades de certificación EASA /FAA.Breve Introducción al estándar DO‐178B / ED‐12B: Que es el DO‐178B/ED‐12B El RTCA DO‐178B. DO‐178B/ED‐12B. . pero para simplificar este capítulo vamos a utilizar la referencia más extendida dentro de la industria de Aviónica.

El paquete de software FLS se puede cargar en un equipo de la aeronave (LRU) por personal de mantenimiento autorizado. Estos procedimientos reducen el tiempo de parada de la aeronave para mantenimiento. e incrementa la eficacia de las tareas de mantenimiento de los equipos. y esta se encuentra en una rampa o un hangar de un aeropuerto. y aprobado por la autoridad competente sobre el diseño. − Permite una mayor reusabilidad. MODIFICACIÓN DEL SOFTWARE EMBARCADO Debido a los continuos avances técnicos. o un procedimiento aprobado incluido en un Boletín de Servicio (SB) preparado por el fabricante de la aeronave. cuando este disponga de estos privilegios mediante la aprobación de su organización de diseño (DOA). es importante distinguir entre el código ejecutable y los datos que son usados por este código ejecutable. − Conseguir una integración más rápida con él soporte físico (Hardware) en el que va a ser instalado. aparte que es imprescindible para la aprobación de equipos que van ser instalados a bordo de aeronaves. y − Obtener una mayor portabilidad. mientras éste se encuentra instalado dentro de la aeronave. Cuando se ha de considerar modificaciones y actualizaciones sobre el software. − Disminuir los costes de mantenimiento. de acuerdo con un procedimiento definido en el Manual de Mantenimiento de la Aeronave (AMM). la modificación del software embarcado por los operadores de las aeronaves se puede considerar como un procedimiento común. son: − Permite verificar la calidad y integridad del software. Software Actualizable sobre el Terreno (FLS): El Software Actualizable sobre el terreno (FLS). "Field Loadable Software”. o en su nombre por el propio fabricante de equipo.Los beneficios de aplicar el DO‐178B/ED‐12B. es código ejecutable o un paquete de datos que puede ser cargado en un computador (LRU). Tipos de Paquetes Software Actualizable sobre el Terreno .

o requerido para cumplir con requisitos de operación específicos. Es decir para demostrar cumplimiento con requisitos específicos 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”). dentro de las limitaciones que son tenidas en cuenta durante elproceso de certificación de la aeronave y sus equipos. Un paquete de software UMS normalmente pueden ser actualizados por el operador de la aeronave. es un software que es esencial para la operación segura de la aeronave. Las modificaciones que pueden ser realizadas por el usuario podrían incluir modificaciones de los datos. pero es parte del diseño aprobado de la aeronave y por lo tanto es un componente de la aeronave que requiere una documentación formal controlada para su autorización de puesta en servicio. una organización . Ejemplos típicos de soportes físicos (“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 Unit’s Electronic Control Unit (ECU) Software Modificable por el Usuario (UMS) El término software modificable por el usuario (UMS) es software que el titular diseño aprobado (TC/STC) ha declarado que puede ser modificado por el usuario. El titular del certificado de tipo y fabricante de una aeronave establece qué paquetes de software pueden ser modificados por el usuario. o modificaciones del código ejecutable. o ambas.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.

Aprobación de Software FLS: El DO‐178B/ED‐12B proporciona consideraciones y criterios para el desarrollo de los sistemas cuyo software puede ser modificado por el operador. presentes en aeronaves de ultima generación (B‐777. Ejemplos típicos de soportes físicos (“Target Hardware”) en los que se pueden actualizar o modificar UMS son: − Aircraft Condition Monitoring Systems (ACMS) − In‐Flight Entertainment Systems (IFE) Software con Opciones Seleccionables (OSS) Un paquete de software con opciones de aplicación que puedan ser seleccionadas (“Option Selectable Software” ‐ OSS) es un paquete que contiene combinaciones de módulos y rutinas aprobados y validados que pueden ser activados o modificados por el operador de la aeronave dentro de las limitaciones establecidas durante la aprobación de su diseño de tipo (TC/STC) obtenida por su titular. o en aeronaves en las que se ha sustituido toda la aviónica convencional por un sistema integrado de aviónica (Honeywell EPIC. Estas opciones pueden ser seleccionadas por la tripulación de vuelo o activadas por el personal de tierra. Thales Topdeck. Ejemplos típicos de soportes físicos para software OSS se suelen encontrar en los sistemas de Aviónica Modular Integrada (IMA).responsable de su diseño (DOA). − Si en una misma aeronave existiesen equipos y componente redundantes. Garmin G1000.). A‐380). se deben establecer requisitos . sin que la autoridad competente que emitió la aprobación al diseño de la aeronave y sus sistemas tenga que realizar revisiones y aprobaciones adicionales. etc. han sido verificadas/probadas conjuntamente durante el proceso de verificación. o por el fabricante del equipo. − Se debe establecer un proceso de gestión de la configuración (Configuration Management (CM)) que permita asegurar la correcta configuración de la instalación. Rockwell Collins Proline. con software modificable por el operador. Estos criterios se pueden resumir en los siguientes puntos: − Se debe demostrar que tanto la configuración de hardware como la configuración de software.

Por lo tanto si los datos usados para esta actualización no son válidos o se han corrompido. como por ejemplo cuando se actualiza la base de datos con los parámetros de las prestaciones del motor de la aeronave. podría dar lugar a que se produjesen comportamientos erráticos o fuera de las condiciones aprobadas para operación segura de la aeronave. y considerar sus efectos sobre la despachabilidad de la aeronave. Diferentes algoritmos CRC dan diferentes niveles de aseguramientos de que los datos han sido transferidos correctamente. y por lo tanto la carga de datos en la base de datos es simplemente la escritura o sobre‐escritura sobre viejos datos. y que no está corrupto mediante un chequeo de la redundancia cíclico (Cyclic Redundancy Check (CRC)). − Se debe establecer un procedimiento para asegurar que el software cargado es el software aprobado. es un conjunto de datos que se puede cargar en la memoria de un computador instalado en una aeronave. el cual no es modificable estando la aeronave en servicio. en un sistema gestor de vuelo (FMS). Datos almacenables en una base de datos sobre el terreno (DFLD): Un paquete de datos DFLD (“Database Field Loadable Data”).para simultanear diferentes cargas de software sobre esos componentes. Es importante señalar que la actualización de la base de datos de una aeronave puede tener aspectos relacionados con las prestaciones de la misma. Ejemplos típicos 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 Aviónica Modular Integrada (IMA) . Es importante señalar que la base de datos es un elemento embebido dentro de un computador. El solicitante y la autoridad que va a probar esos procedimientos deberíanasegurarse de que el algoritmo usado es suficiente para el nivel de integridad requerido para el software que va ser cargado. de los nuevos datos distribuidos en fichero proporcionado por el fabricante.

que es una forma de control de redundancia. son fáciles de analizar matemáticamente y son particularmente efectivas para detectar errores ocasionados por ruido en los canales de transmisión. se asume que los datos probablemente no han sido corrompidos. Si ambas sumas concuerdan. . Comprobación de redundancia cíclica (CRC) La comprobación de redundancia cíclica (CRC) es un tipo de función que recibe un flujo de datos de cualquier longitud como entrada y devuelve un valor de longitud fija como salida. Las CRC son populares porque su implementación en hardware binario es simple. y marcado de un paquete de datos o código ejecutable FLS / DFLD es responsabilidad del titular de la aprobación del diseño aplicable al producto. comunicación de dispositivos. etc. etc. verificando que no hayan sido corrompidos es una suma de verificación o “Checksum”. discos portátiles. El proceso consiste en sumar cada uno de los componentes básicos de un sistema (generalmente cada byte) y almacenar el valor del resultado. Este término sueleser usado para designar tanto a la función como a su resultado. Instrucciones de Mantenimiento y el marcado de partes: Las Instrucciones de instalación y mantenimiento. Las CRC pueden ser usadas como suma de verificación para detectar la alteración de datos durante su transmisión o almacenamiento. y se debe realizar de acuerdo con las reglas de aplicación incluidas Parte 21 de la EASA. equipo o componente (el fabricante). El CRC es un código de detección de error‐cuyo cálculo es una larga división de computación en el que se descarta el cociente y el resto se convierte en el resultado.).VERIFICACIÓN DE LOS DATOS Métodos de Detección Método Checksum Un método muy simple para proteger la integridad de datos.) o para datos almacenados (archivos comprimidos. El método se emplea en los sistemas de comunicación (Internet. Posteriormente se realiza el mismo procedimiento y se compara el resultado con el valor almacenado.

el sistema afectado no se debería considerar como operativo y la aeronave no debería ser despachada. o las instrucciones para la aeronavegabilidad continuada (ICAs) elaboradas por los titulares de un STC. en la MEL se debería indicar si el equipo afectado podría ser inutilizado y la aeronave podría ser puestas en servicio. En el caso de equipos cuyo “Part Number” de software no pueda ser verificado. o ha fallado. podría permitir despachar el avión con algún equipo no operativo. antes y después de que se haya realizado una tarea de mantenimiento en dicho equipo. Para cumplir con este punto también se pueden utilizar las recomendaciones del fabricante del equipo y las herramientas recomendadas para conseguir estos propósitos. deberían 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 código ejecutable (FLS / DFLD). y comprobar que tanto el P/N del software como el del hardware están aprobados. o las instrucciones para la aeronavegabilidad continuada (ICAs). la identificación de la unidad en la placa del equipo debería ser cambiada cuando se cargue el nuevo software. . Para equipos embarcados que tengan sólo un “Part Number”. DISTRIBUCIÓN y CONTROL SOFTWARE FLS y DFLD Métodos de Distribución: 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 distribución o transferencia electrónica. Cuando se realice una carga del nuevo software. Si la carga de software no puede ser verificada. que representa una configuración específica de software y hardware. Los manuales de mantenimiento de la aeronave (AMM). deben incluir instrucciones que permitan al personal de mantenimiento verificar la configuración del “Part Number (P/N)”. mediante el uso de una Revisión Redundante Cíclica (CRC).Los manuales de mantenimiento de la aeronave (AMM) elaborados por el titular del Certificado de Tipo (TC). o el procedimiento no ha dado los resultados esperados. En algunos casos la lista de equipos mínimos para el despacho (MEL). el software instalado en el computador afectado debería ser verificado electrónicamente.

Los paquetes de datos siempre se deben acompañar la documentación que autoriza su puesta en servicio (EASA Form 1 o equivalente) Transferencia Electrónica: Proceso por el cual. evitando que sean instalados inmediatamente en los sistemas de la aeronave. El método de transporte debería ser el apropiado para asegurar que no se produce un daño en el soporte físico de almacenamiento o corrupción de sus datos. Una vez recibidos los paquetes de datos deberán ser revisados para comprobar que no tengan un virus. Sistemas de Distribución Electrónica (EDS) .Los paquetes de software y datos del tipo FLS y DFLD pueden ser distribuidos mediante varios métodos que pueden incluir uno o combinación de los siguientes: Mediante Medios Físicos Es un proceso por el cual FLS o los ficheros de una base de datos son transferidos desde la organización de producción o el proveedor. Durante el proceso de carga el mecánico puede controlar a través de un “Display” la unidad a la que está destinada la carga. Módulos Reemplazables a Bordo (OBRM). y deberán ser almacenados en una localización controlada. y de esta forma la aeronave puede llevar consigo su propio software. Además el uso de estas unidades de carga permite almacenar gran cantidad de paquetes a ser instalados. o una memoria flash. Si existiese alguna duda. mediante el uso de un ordenador portátil. un computador de mano o un Portable Data Loader (PDL) y una conexión física temporal realizada mediante un cable de enlace de datos de serie. El fabricante del equipo afectado deberá proporcionar instrucciones de cómo se debería verificar la existencia de un virus. un CD‐ROM. a un lugar remoto usando soportes físicos de almacenamiento como por ejemplo Floppy Disk. no se debería cargar en los sistemas de la aeronave. se realiza una transferencia de los datos a un computador de abordo.

se está desarrollando la distribución electrónica directamente del fabricante al operador. b) Los procedimientos de verificación para asegurar que el software ha sido correctamente carado en el computador aprobado y es compatible (Target Hardware). . Si la aprobación para el paquete de datos o código ejecutable FLS ha sido obtenida mediante un certificado de tipo (TC) o un certificado equipo suplementario (STC). como por ejemplo a través de Internet. o una Orden de Especificación Técnica (TSO). o cualquier otro medio aprobado por la autoridad de certificación.el documento de instalación debería ser aprobado por la correspondiente autoridad de certificación y debería especificar los siguientes elementos: a) La aeronave y la configuración de equipos aplicable.Con objeto de agilizar y disminuir el retraso en la distribución de los paquetes de software y datos que se instalan en las aeronaves. c) Proporcionar los procedimientos de verificación que se han de aplicar después de la carga. Requisitos para la instalación: Un paquete FLS puede ser instalado en una aeronave mediante un boletín de servicio (SB). a un lugar remoto sin el empleo de medios de almacenamiento masivo. o mediante una Orden de Ingeniería (EO).

Es decir que cualquier paquete de código ejecutable que vaya de ser cargado en una aeronave debe estar acompañado de un certificado EASA Form 1 o FAA 8110‐3. Ejemplos de LSAP que requieren un EASA Form 1 podrían ser: − Controles electrónicos del motor (EEC) − Unidad de Adquisición de Datos de Vuelo Digital (DFAU) − Computadores para el día dos de vuelo (FGC) − Aviónica Modular Integrada (IMA) Igualmente cualquier paquete de datos DFLD que pueda afectar al funcionamiento de un equipo esencial para la operación segura de aeronave o que sea requerida para cumplir con requisitos de operación específicos deberán estar acompañado del correspondiente EASA Form 1 o FAA 8110‐3. e) Referencia a los procedimientos de carga aprobados. Ejemplos de bases de datos DFLD a las que necesitan un EASA Form 1 son: − las computadoras del sistema de gestión de vuelo (FMC) . f) Procedimientos para realizar la entrada en el registro de mantenimiento. Documentación Autorizada: para la Puesta en Servicio Métodos de puesta en servicio autorizada Hay que resaltar que la documentación para autorización y distribución depende de si FLS o DFLD es requerido para demostrar cumplimiento con requisitos de aeronavegabilidad requeridos o disposiciones reglamentarias para la operación comercial.d) Las acciones que deben ser tomadas en el caso de que la carga no haya sido satisfactoria. de forma que se permita mantener un adecuado control de configuración. g) Referencia a las páginas o suplementos afectados del manual de vuelo y del manual de operación de la aeronave. En los otros casos será necesario acompañar al artículo del correspondiente certificado de autorización para su puesta en servicio. Si el FLS o el DFLD no son necesarios para verificar cumplimiento con requisitos de certificación u operación. el correspondiente Certificado de conformidad será suficiente.

Obtención y documentación de paquetes FLS y DFLD Paquetes iniciales FLS y DFLD Los paquetes iniciales FLS y DFLD se obtienen normalmente durante la entrega de un avión nuevo y están ya instalados en los soportes físicos a los que están destinados (LRU o LRM). − Catálogo ilustrado de partes (IPC). o . en un formato de soporte de almacenamiento físico. ya que en estos casos no hace falta un documento equivalente a un EASA Form 1. no tiene por qué indicar necesariamente cuál es el P/N del Software cargado. o puede obtener los datos a través de un titular de una LOA Tipo 1. o mediante la documentación que acompaña la aeronave. El titular de una LOA Tipo 2 puede recibir datos directamente de las agencias autorizadas. El titular de una LOA Tipo 1 no tiene por qué distribuir datos para las bases de datos de navegación directamente a los usuarios finales. Paquetes LSAP La obtención de paquetes LSAP se debe realizar a través de una fuente autorizada. RNP) el artículo deberá ir acompañado de la carta de aceptación “Letter of Acceptance” LOA Tipo 1 o Tipo 2 emitido por la autoridad competente. como por ejemplo los Servicios de Información Aeronáutica estatales (AIS). El titular de una LOA Tipo 2 puede distribuir datos para base de datos de navegación directamente a los operadores y usuarios finales. usando P/N especificado por el fabricante de la aeronave. P‐RNAV. − Boletines de Servicio (SB). y acompañado del correspondiente EASA Form 1. Para confirmar que un P/N específico está aprobado se deberá consultar con documentos del fabricante de la aeronave como por ejemplo. Hay que señalar que los P/N de los equipos hardware.− la base de datos terrenal del sistema de aviso de proximidad a tierra (TAWS) Documentación navegación: para las bases de datos de Para la distribución autorizada de una base de datos de navegación (NDB). que es requerida para una aprobación de tipo operacional (B‐RNAV.

ode las prestaciones de un modelo de motor. Este documento se suele denominar “Aircraft Configuración List” (ACL). . bases de datos del terreno. y acompañadas de la documentación y del medio de almacenamiento que contiene los ficheros de datos y que debe identificarlos de forma inequívoca. y en él se listan todas las unidades reemplazables en línea (LRU) o módulo reemplazables en línea (LRM) identificándolas como partes con software actualizable (LSAP) que son aplicables a una aeronave en particular. o − Ordenes ingeniería aprobadas por el titular TC o un STC. Los medios de almacenamiento de un paquete de datos DFLD deben ser registrados con la identificación de la organización que los ha proporcionado y los sellos de control y conformidad de calidad aplicables. Por lo tanto el operador debería mantener un registro que proporcione la siguiente información: − La versión actual del Software FLS y los datos DFLD que han sido instalados. junto con las referencias que permitan verificar que dichos paquetes están certificados para su instalación en la aeronave afectada. deben ser adquiridas de una fuente autorizada que sea aceptable para el fabricante de equipo en el que van a ser instaladas (Target Hardware). Control de Aeronave: Configuración del Software de la Para poder controlar el estado de configuración de estos paquetes de software. − Los equipos y sistemas de la aeronave a los que estos paquetes de software y datos son aplicables. Paquetes DFLD La actualización de datos aplicables a las bases de datos de navegación. Esta lista debería contener los datos proporcionados por el titular del certificado de tipo (TC). cartas de información de servicio (SIL) o el Catálogo Ilustrado de Partes (IPC). − Las aeronaves en las cuales han sido instalados estos paquetes de software y datos. el operador deberá mantener al día un Documento de Control de Configuración de cada aeronave con los Part Numbers (P/N) de cada uno de los paquetes de software que han sido instalados en la aeronave. mediante los Boletines de Servicio (SB). o por el fabricante de equipo original (OEM).− Cartas de Información de Servicio (SIL).

o cualquier otro dispositivo diseñado para cumplir con este propósito. Es importante tener en cuenta que en caso de duda sobre el estado de una actualización. como por ejemplo tener dudas sobre si no están corruptos. Para confirmar que paquete de software está cargado en un sistema de la aeronave. la modificación. Todos estos procedimientos relacionados con la adquisición. se debe realizar una comprobación del Part Number (P/N) y la versión del software que está cargado en un sistema. incluyendo el nombre de la persona que es responsable de ello. la incorporación de paquetes de software a una flota de aeronaves deberían ser incluidos en un capítulo del documento de exposición de la gestión del mantenimiento (MME) que la compañía debe preparar para ser autorizada por el operador aéreo (AOC). − Quien puede decidir si es necesario actualizar un equipo o sistema y quien es el responsable de autorizar esta actualización.− Las funciones que estos paquetes de software y datos realiza. Font: AESA (Agencia Española de Seguridad Aérea)‐ Información a personal con licencia LMA Parte 66 . o mediante la propia unidad de control del dispositivo de presentación asociado al sistema. De hecho. mediante el uso de una terminal de acceso de mantenimiento al correspondiente bus de datos. o si es la versión adecuada para una configuración de aeronaves en particular. − Donde y con qué formato se han instalado estos paquetes de software y datos. paquete de software o de datos. no se debería intentar hacer la transferencia de estos datos. accediendo al menú de mantenimiento. se debería poner en cuarentena dicho paquete y mantenerlo pendiente de verificar su integridad y/o confirmar la versión aplicable con el proveedor.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->