MIL-STD-1553

MIL-STD-1553 es el estándar militar publicado por el Departamento de Defensa de Estados Unidos que define las características mecánicas, eléctricas y funcionales de un bus de datos en serie. Fue diseñado en principio para su uso en aviación militar, pero ha terminado por utilizarse habitualmente en subsistemas embarcados de manejo de datos en vehículos espaciales, tanto militares como civiles. Proporciona una interfaz física de línea balanceada dual, una interfaz de red diferencial, multiplexación por división en el tiempo, protocolo de comando/respuesta half-duplex y hasta 31 terminales remotos. Una versión de MIL-STD-1553, que utiliza cableado óptico en lugar de eléctrico, es conocida como MIL-STD-1773.

MIL-STD-1553 fue publicado por primera vez en 1973 como un estándar de la de la U.S. Air Force, y fue utilizado en el avión de combate F-16 Fighting Falcon. Rápidamente le sucedieron otros diseños de aviones, entre ellos el F-18 Hornet y el F-20 Tigershark. Actualmente es ampliamente utilizado por todas las ramas del ejército de Estados Unidos y ha sido adoptado por la OTAN como STANAG 3838 AVS. MIL-STD-1553 está siendo reemplazado en nuevos diseños norteamericanos por FireWire.^[1]

Revisiones

MIL-STD-1553B que reemplazó a la anterior especificación MIL-STD-1553A de 1975, fue publicado en 1978. La diferencia básica entre 1553A y 1553B es que en aquella, las opciones son definidas en lugar de dejar que sea el usuario quien las defina según sus necesidades. Se descubrió que cuando el estándar no definía un elemento, no había coordinación en su uso. Tanto hardware como software tuvieron que ser rediseñados para cada nueva aplicación. El objetivo principal de la 1553B era proporcionar flexibilidad sin tener que crear nuevos diseños para cada usuario. Esto se consiguió especificando explícitamente las interfaces eléctricas, de tal manera que la compatibilidad eléctrica entre diseños de diferentes fabricantes estuviera asegurada.

Han sido publicadas seis modificaciones del estándar desde 1978.^[2] Por ejemplo, el anuncio de modificación 2 de 1986 cambiaba el título del documento de "Aircraft internal time división command/response multiplex data bus" to "Digital time division command/response multiplex data bus".

El estándar MIL-STD-1553 es mantenido en la actualidad tanto por el DoD de los Estados Unidos como por la rama aeroespacial de la Society of Automotive Engineers.

Capa física

Cada bus consiste en un cable de pares con una impedancia de entre 70 y 80 Ω a 1 MHz. Cuando se utiliza un conector circular, su pin central se usa para la señal Manchester bifásica de nivel alto (positivo). Transmisores y receptores se acoplan al bus por medio de transformadores de aislamiento y los conectores en "T" se ramifican mediante un par de resistores de aislamiento y transformadores acoplados. Esto reduce el impacto de un eventual cortocircuito y asegura que el bus no conduce corriente hacia la aeronave. Se usa un código Manchester para transmitir tanto la señal de reloj como los datos en el mismo par y para eliminar la componente continua de la señal (que no puede transmitirse a través de los transformadores). La tasa binaria es de 1.0 mbps (1 bit = 1 μs). La especificación sobre la precisión combinada y la estabilidad a largo plazo de la tasa binaria es de un margen del ±0.1%; la estabilidad del reloj a corto plazo debe ser del ±0.01%. La tensión pico a pico de un transformador es de entre 18 y 27 V.

El bus puede tener redundancia doble o triple mediante el uso de varios pares de cable independientes a los que todos los dispositivos están conectados. Se prevé designar un nuevo computador para el control del bus en caso de fallo del controlador principal. Habitualmente, el ordenador auxiliar de control de vuelo auxiliar monitoriza al principal y a los sensores de la aeronave mediante el bus de datos principal. Una versión diferente del bus utiliza fibra óptica, que pesa menos y es más resistente a interferencias electromagnéticas, incluso las de EMP. Esto es conocido como MIL-STD-1773.

Protocolo de bus

Los mensajes consisten en una o más palabras de 16 bits (comando, datos o estado). Cada palabra está precedida por un pulso de sincronización de 3 μs (1.5 μs a nivel bajo más 1.5 μs en alto para palabras de datos y viceversa para palabras de comando y estado, estas secuencias no se pueden dar en un código Manchester) y a continuación un bit de paridad par. En la práctica cada palabra podría considerarse como una palabra de 20 bits: 3 para sincronización, 16 para la carga útil y 1 bit para el control de paridad. Las palabras en el interior de un mensaje son transmitidas de forma contigua y hay una pausa de 4 μs entre mensajes. Los dispositivos deben empezar a transmitir su respuesta a un comando válido entre 4 y 12 μs y se considera que no han recibido un mensaje si no se ha iniciado una respuesta tras 14 μs.

El controlador maestro se encarga del control de toda comunicación en el bus, cualquier emisión o recepción se basa en un comando del maestro a un terminal. Por su parte las terminales se distinguen por una dirección (0 ~ 31) y a su vez cada terminal podría recibir datos o entregar datos desde diferentes áreas de memoria. Cada área diferente de memoria dentro de un mismo terminal se identifica con un valor de 5 bits llamado subdirección (1~30) (los valores 0 y 31 quedan reservados para transacciones de tipo Mode Code).

La secuencia de palabras (la forma de la notación es <origen>.<tipo_de_palabra(destino)> y es una notación similar a la de los CSP), para la transferencia de datos del controlador maestro a un terminal es

master.command(terminal) → terminal.status(master) → master.data(terminal) → master.command(terminal) → terminal.status(master)

y para comunicación de entre terminales es

master.command(terminal_1) → terminal_1.status(master) → master.command(terminal_2) → terminal_2.status(master) → master.command(terminal_1) → terminal_1.data(terminal_2) → master.command(terminal_2) → terminal_2.status(master)

Esto significa que durante la transferencia entre terminales remotos, la comunicación se realiza mediante el controlador de bus. Los datos son escritos primero en un buffer del terminal remoto que inicia la comunicación. El controlador de bus lee los datos del buffer de dicho terminal y los escribe en el buffer del terminal de destino.

Las secuencias garantizan que el terminal está en funcionamiento y en disposición de recibir datos. La petición de estado al final de una transferencia de transmisión de datos asegura que los datos han sido recibidos y que el resultado de la transferencia de datos es aceptable. Esta secuencia es lo que da a MIL-STD-1553 su alta integridad. Las secuencias que se han presentado están simplificadas y no muestran las medidas a tomar en caso de error u otro fallo.

Un dispositivo terminal no puede originar una transferencia de datos por sí solo. Las peticiones de transmisión de un dispositivo terminal son generadas por el controlador maestro sondeando a los terminales. Las funciones de alta prioridad (por ejemplo, comandos a las superficies de control de la aeronave) son sondeadas con más frecuencia. Los comandos de baja prioridad son sondeados menos frecuentemente. De todos modos, el estándar no especifica ninguna temporización en particular para una palabra en concreto -- es decisión de los diseñadores del sistema. La ausencia de respuesta cuando un dispositivo es sondeado indica un fallo.

Existen cinco tipos de transacciones entre el controlador de bus y los terminales remotos.

Receive data. El controlador de bus envía una palabra de comando de 16 bits, inmediatamente seguido de entre 1 y 32 palabras de datos de 16 bits. El terminal remoto seleccionado envía entonces una única palabra de estado de respuesta de 16 bit al controlador de bus.
Transmit data. El controlador de bus envía una palabra de comando al terminal remoto. El terminal remoto envía entonces una única palabra de estado de respuesta, seguida inmediatamente de entre 1 y 32 palabras al controlador de bus.
Broadcast data. Novedad de 1553B. El controlador de bus envía una palabra de comando con la dirección de terminal 31, que es en realidad un comando de tipo broadcast, seguido de entre 1 y 32 palabras. Todos los terminales remotos aceptarán los datos pero ninguno responderá. Esto puede ser usado para actualizaciones completas del sistema, tales como la hora.
Mode Code. El controlador de bus envía una palabra de comando con una subdirección de 0 o 31. Este comando puede o no estar seguido de una única palabra dependiendo de qué código sea usado. El terminal remoto responde con una palabra de estado de respuesta que podría o no estar seguida de una única palabra de datos.
RT to RT Transfer. El controlador de bus envía un comando de recepción de datos seguido por un comando de transmisión de datos. El terminal transmisor envía una palabra seguida de entre 1 y 32 palabras de datos al terminal receptor. El terminal receptor envía entonces su palabra de estado.

La palabra de comando está formada como sigue. Los primeros 5 bits son la dirección del terminal remoto (0 ~ 31). El sexto bit es cero para recepción o uno para transmisión. Los siguientes 5 bits indican la subdirección, que representa un área de memoria en la cual se guardarán u obtendrán los datos en el terminal (1 ~ 30). Nótese que los valores 0 y 31 están reservados para los códigos de modo. Los últimos 5 bits indican el número de palabras a esperar (1 ~ 32). Si es todo ceros indica 32 palabras. En el caso de un código de modo, estos bits son el número de código de modo; Initiate Self Test y Transmit BIT Word son ejemplos.

La palabra de estado se decodifica como sigue. Los primeros 5 bits son la dirección del terminal remoto que está respondiendo. El resto de la palabra son códigos de condición de un único bit. Algunos bits están reservados. Un estado 'uno' indica que la condición es cierta; Message Error y Service Request son ejemplos. Más de una condición puede ser cierta al mismo tiempo.

Descripción conceptual

La Figura 1 muestra un sistema típico MIL-STD-1553B.

Consiste en:

un bus MIL-STD-1553B con redundancia doble
una controlador de bus
tres terminales remotos
un monitor de bus

El controlador de bus

Hay sólo un controlador de bus al mismo tiempo en cualquier bus MIL-STD-1553. Éste inicia toda comunicación de mensajes sobre el bus.

La Figura 1 muestra los detalles del bus de datos 1553:

funciona conforme a una lista de comandos guardada en su memoria local
ordena a los distintos terminales remotos que envíen o reciban mensajes
da servicio a cualquier petición que reciba de los terminales remotos
detecta y subsana errores
guarda un historial de errores

V+P´+

Los terminales remotos

Un terminal remoto puede ser usado para proporcionar:

una interfaz entre el bus de datos MIL-STD-1553B y un subsistema añadido
un puente entre un bus MIL-STD-1553B y otro bus MIL-STD-1553B

Por ejemplo, en un vehículo con localizador, un terminal remoto podría adquirir datos de un subsistema interno de navegación y enviar los datos a través del bus de datos 1553 a otro terminal remoto para su visualización en un instrumento de tripulante. Ejemplos más simples de terminales remotos podrían ser las interfaces que encienden los faros, las luces de aterrizaje o las balizas en un avión.

Planes de testeo para terminales remotos:

El RT Validation Test Plan está orientado a la verificación de terminales remotos diseñados para cumplir los requerimientos de AS 15531 y MIL-STD-1553B con su revisión 2. Este plan de testeo fue definido inicialmente en MIL-HDBK-1553, Appendix A y Fue actualizado en MIL-HDBK-1553A, Section 100. El plan de testeo es mantenido actualmente por el SAE AS-1A Avionic Networks Subcommittee como AS4111.

El RT Production Test Plan es una subsección simplificada del plan de test de validación y está orientado a testeo de la producción de terminales remotos. Este plan de testeo es mantenido por el SAE AS-1A Avionic Networks Subcommittee como AS4112.

Monitor de bus

Un monitor de bus no puede transmitir mensajes sobre el bus de datos. Su papel principal es monitorizar y grabar las transacciones del bus, sin interferir en la operación del controlador de bus o los terminales remotos. Las transacciones del bus pueden ser almacenadas para un posterior análisis off-line.

Idealmente, un monitor de bus captura y graba todos los mensajes enviados a través del bus de datos 1553. Sin embargo grabar todas las transacciones de un bus de datos con mucha actividad sería poco viable, por lo que un monitor de bus está configurado a menudo para grabar una selección de transacciones, basado en algún criterio proporcionado por el programa de aplicación.

Un monitor de bus puede ser usado en también en conjunto con un controlador de bus auxiliar. Esto permite al controlador auxiliar estar en funcionamiento incluso antes de tener que pasar a ser el controlador de bus activo.