MIL-STD-1553

Ir a la navegaci�nIr a la b�squeda
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?

�ndice
1 Revisiones
2 Capa f�sica
3 Protocolo de bus
4 Descripci�n conceptual
4.1 El controlador de bus
4.2 Los terminales remotos
4.3 Monitor de bus
5 Referencias
6 Enlaces externos
7 V�ase tambi�n
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 O 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 el payload y 1 bit para
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 � 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 � 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 primero 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

Figura 1. Modelo conceptual de un bus MIL-STD-1553B.

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 un 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.