stringtranslate.com

MIL-STD-1553

MIL-STD-1553 es un estándar militar publicado por el Departamento de Defensa de los Estados Unidos que define las características mecánicas , eléctricas y funcionales de un bus de datos en serie . Originalmente fue diseñado como un bus de datos de aviónica para uso con aviónica militar , pero también se ha utilizado comúnmente en subsistemas de manejo de datos a bordo de naves espaciales (OBDH), tanto militares como civiles, incluido el uso en el telescopio espacial James Webb . Cuenta con múltiples capas físicas de línea balanceada redundante (comúnmente dual), una interfaz de red (diferencial) , multiplexación por división de tiempo , protocolo de comando/respuesta semidúplex y puede manejar hasta 31 terminales remotas (dispositivos); 32 suele estar designado para mensajes de difusión. Una versión de MIL-STD-1553 que utiliza cableado óptico en lugar de eléctrico se conoce como MIL-STD-1773 .

MIL-STD-1553 se publicó por primera vez como estándar de la Fuerza Aérea de EE. UU. en 1973 y se utilizó por primera vez en el avión de combate F-16 Falcon . Rápidamente siguieron otros diseños de aviones, incluidos el F/A-18 Hornet , el AH-64 Apache , el P-3C Orion , el F-15 Eagle y el F-20 Tigershark . Es ampliamente utilizado por todas las ramas del ejército estadounidense y por la NASA . [1] Fuera de EE.UU. ha sido adoptado por la OTAN como STANAG 3838 AVS . STANAG 3838, en forma de MoD Def-Stan 00-18 Parte 2 del Reino Unido, [2] se utiliza en el Panavia Tornado ; BAE Systems Hawk (Mk 100 y posteriores); y ampliamente, junto con STANAG 3910 "EFABus", en el Eurofighter Typhoon . [3] Saab JAS 39 Gripen utiliza MIL-STD-1553B. [4] El MiG-35 de fabricación rusa también utiliza MIL-STD-1553. [5] MIL-STD-1553 está siendo reemplazado en algunos diseños estadounidenses más nuevos por IEEE 1394 (comúnmente conocido como FireWire). [6]

Revisiones

MIL-STD-1553B , que reemplazó a la especificación anterior MIL-STD-1553A de 1975, se publicó en 1978. La diferencia básica entre las revisiones 1553A y 1553B es que en esta última, las opciones se definen en lugar de dejar que el usuario las decida. definir según sea necesario. Se encontró que cuando la norma no definía un ítem, no había coordinación en su uso. Hubo que rediseñar el hardware y el software para cada nueva aplicación. El objetivo principal del 1553B era brindar flexibilidad sin crear nuevos diseños para cada nuevo usuario. Esto se logró especificando explícitamente las interfaces eléctricas para poder garantizar la compatibilidad eléctrica entre diseños de diferentes fabricantes.

Desde 1978 se han publicado seis avisos de cambio de la norma. [7] Por ejemplo, el aviso de cambio 2 en 1986 cambió el título del documento de "Bus de datos múltiplex de comando/respuesta de división de tiempo interna de la aeronave" a "Comando/respuesta de división de tiempo digital bus de datos multiplex".

MIL-STD-1553C es la última revisión realizada en febrero de 2018. La Revisión C es funcionalmente equivalente a la Revisión B, pero contiene gráficos y tablas actualizados para facilitar la lectura del estándar. [8]

El estándar MIL-STD-1553 lo mantienen tanto el Departamento de Defensa de EE. UU. como la rama aeroespacial de la Sociedad de Ingenieros Automotrices .

Capa fisica

Un único bus consta de un par de cables con una impedancia de 70 a 85 Ω a 1 MHz. Cuando se utiliza un conector circular, su pin central se utiliza para la señal bifásica Manchester alta (positiva). Los transmisores y receptores se acoplan al bus mediante transformadores de aislamiento, y las conexiones cortas se ramifican mediante un par de resistencias de aislamiento y, opcionalmente, un transformador de acoplamiento. Esto reduce el impacto de un cortocircuito y garantiza que el bus no conduzca corriente a través del avión. Se utiliza un código Manchester para presentar tanto el reloj como los datos en el mismo par de cables y para eliminar cualquier componente de CC en la señal (que no puede pasar los transformadores). La velocidad de bits es de 1,0 megabit por segundo (1 bit por μs ). La precisión combinada y la estabilidad a largo plazo de la velocidad de bits solo se especifican dentro de ±0,1%; la estabilidad del reloj a corto plazo debe estar dentro de ±0,01%. El voltaje de salida pico a pico de un transmisor es de 18 a 27 V.

El bus se puede hacer doble o triplemente redundante mediante el uso de varios pares de cables independientes y luego todos los dispositivos se conectan a todos los buses. Existe una disposición para designar una nueva computadora de control de bus en caso de falla del controlador maestro actual. Por lo general, las computadoras de control de vuelo auxiliares monitorean la computadora maestra y los sensores de la aeronave a través del bus de datos principal. Una versión diferente del bus utiliza fibra óptica , que pesa menos y tiene mejor resistencia a las interferencias electromagnéticas, incluida la EMP . Esto se conoce como MIL-STD-1773. [9] El experimento "AS 1773" de la NASA tiene una velocidad dual de 1 Mbit/s o 20 Mbit/s, probablemente un predecesor del STANAG 3910 . [10]

Protocolo de autobús

Un sistema de bus de datos multiplex MIL-STD-1553 consta de un controlador de bus (BC) que controla múltiples terminales remotos (RT), todos conectados entre sí mediante un bus de datos que proporciona una única ruta de datos entre el controlador de bus y todos los terminales remotos asociados. También puede haber uno o más Monitores de Autobús (BM); sin embargo, a los monitores de bus no se les permite específicamente participar en transferencias de datos y solo se usan para capturar o registrar datos para análisis, etc. En implementaciones de bus redundantes, se usan varios buses de datos para proporcionar más de una ruta de datos, es decir, redundancia dual. bus de datos, bus de datos triple redundante, etc. Todas las transmisiones en el bus de datos son accesibles para el BC y todos los RT conectados. Los mensajes constan de una o más palabras de 16 bits (comando, datos o estado). Los 16 bits que componen cada palabra se transmiten utilizando el código Manchester , donde cada bit se transmite como una secuencia de 0,5 μs de alto y 0,5 μs de bajo para un 1 lógico o una secuencia baja-alta para un 0 lógico . Cada palabra está precedida por un pulso de sincronización de 3 μs (1,5 μs bajo más 1,5 μs alto para palabras de datos y lo contrario para palabras de comando y estado, que no pueden ocurrir en el código Manchester) y seguido de un bit de paridad impar . Prácticamente cada palabra podría considerarse como una palabra de 20 bits: 3 bits para sincronización, 16 bits para carga útil y 1 bit para control de paridad impar. Las palabras dentro de un mensaje se transmiten de forma contigua y debe haber un espacio mínimo de 4 μs entre mensajes. Sin embargo, esta brecha entre mensajes puede ser, y a menudo es, mucho mayor que 4 μs, incluso hasta 1 ms con algunos controladores de bus más antiguos. Los dispositivos deben comenzar a transmitir su respuesta a un comando válido dentro de 4 a 12 μs y se considera que no han recibido un comando o mensaje si no se ha iniciado ninguna respuesta dentro de 14 μs.

Toda la comunicación en el bus está bajo el control del controlador de bus mediante comandos del BC a los RT para recibir o transmitir. La secuencia de palabras (la forma de la notación es <originator>.<word_type(destination)>y es una notación similar a CSP ), para la transferencia de datos desde el BC a una terminal es

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

y para la comunicación de terminal a terminal 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 .estado (maestro)

Esto significa que durante una transferencia, toda la comunicación la inicia el controlador de bus y un dispositivo terminal no puede iniciar una transferencia de datos por sí solo. En el caso de una transferencia de RT a RT, la secuencia es la siguiente: Una aplicación o función en el subsistema detrás de la interfaz RT (por ejemplo, RT1) escribe los datos que se van a transmitir en una subdirección (de transmisión) específica (búfer de datos). ). El momento en el que estos datos se escriben en la subdirección no está necesariamente vinculado al momento de la transacción, aunque las interfaces garantizan que no se transmitan datos parcialmente actualizados. El controlador de bus ordena al RT que es el destino de los datos (por ejemplo, RT2) que reciba los datos en una subdirección de datos especificada (recepción) y luego ordena a RT1 que transmita desde la subdirección de transmisión especificada en el comando. RT1 transmite una palabra de estado, que indica su estado actual y los datos. El controlador de bus recibe la palabra de estado de RT1 y ve que el comando de transmisión se recibió y se ejecutó sin problemas. RT2 recibe los datos en el bus de datos compartido y los escribe en la subdirección de recepción designada y transmite su palabra de estado. Una aplicación o función en el subsistema detrás de la interfaz RT receptora puede entonces acceder a los datos. Nuevamente, el momento de esta lectura no está necesariamente vinculado al de la transferencia. El controlador de bus recibe la palabra de estado de RT2 y ve que el comando de recepción y los datos se han recibido y actuado sin problemas.

Sin embargo, si RT no envía su estado o los datos esperados o indica un problema mediante la configuración de bits de error en la palabra de estado, el controlador de bus puede volver a intentar la transmisión. Hay varias opciones disponibles para dichos reintentos, incluido un reintento inmediato (en el otro bus de datos de un par de buses de datos redundantes) y un reintento posterior (en el mismo bus) en la secuencia de transferencias.

Las secuencias garantizan que el terminal esté funcionando y sea capaz de recibir datos. La palabra de estado al final de una secuencia de transferencia de datos garantiza que los datos se han recibido y que el resultado de la transferencia de datos es aceptable. Es esta secuencia la que le da a MIL-STD-1553 su alta integridad.

Sin embargo, el estándar no especifica ningún momento particular para ninguna transferencia en particular; eso depende de los diseñadores del sistema. Generalmente (como se hace en la mayoría de los aviones militares), el controlador de autobús tiene un cronograma de transferencias que cubre la mayoría de las transferencias, a menudo organizadas en un marco o ciclo principal, que a menudo se subdivide en ciclos menores. En una estructura de programación ejecutiva cíclica de este tipo, las transferencias que ocurren en cada ciclo menor (grupo de frecuencia 1) ocurren a la frecuencia más alta, típicamente 50 Hz, las transferencias que ocurren en cada dos ciclos menores, de los cuales hay dos grupos (grupo de frecuencia 2.1 y 2.2) suceden a la siguiente frecuencia más alta, por ejemplo 25 Hz. De manera similar, hay cuatro grupos (3,1, 3,2, 3,3 y 3,4) a, por ejemplo, 12,5 Hz, etc. Por lo tanto, cuando se utiliza esta estructura de programación, todas las transferencias se realizan a frecuencias relacionadas armónicamente, por ejemplo, 50, 25, 12,5, 6,25, 3,125 y 1,5625 Hz (para una trama principal que comprende 32 ciclos menores a 50 Hz). Si bien los RT no pueden iniciar una transferencia directamente por sí solos, el estándar incluye un método para cuando un RT necesita transmitir datos que el controlador de bus no programa automáticamente. Estas transferencias suelen denominarse transferencias acíclicas, ya que están fuera de la estructura utilizada por el ejecutivo cíclico. En esta secuencia, un RT solicita la transmisión a través de un bit en la palabra de estado, el bit de solicitud de servicio. Generalmente, esto hace que el controlador de bus transmita un comando de transmisión de código de modo de palabra vectorial. Sin embargo, cuando un RT sólo tiene una posible transferencia acíclica, el controlador de bus puede omitir esta parte. El RT transmite la palabra vectorial como una única palabra de datos de 16 bits. El formato de esta palabra vectorial no está definido en el estándar, por lo que los diseñadores del sistema deben especificar qué valores de qué RT significan qué acción debe tomar el controlador de bus. Esto puede ser para programar una transferencia acíclica ya sea inmediatamente o al final del ciclo menor actual. Esto significa que el controlador de bus tiene que sondear todos los terminales remotos conectados al bus de datos, generalmente al menos una vez en un ciclo importante. Los RT con funciones de mayor prioridad (por ejemplo, aquellos que operan las superficies de control de la aeronave) son encuestados con mayor frecuencia. Las funciones de menor prioridad se sondean con menos frecuencia.

Se permiten seis tipos de transacciones entre el BC y un RT específico o entre el Controlador de Bus y un par de RT:

Figura 6: Formatos de transferencia de información. Nota: "TRANSMITIR COMANDO" es igual a "palabra de comando"
  1. Transferencia de controlador a RT . El controlador de bus envía una palabra de comando de recepción de 16 bits, seguida inmediatamente por de 1 a 32 palabras de datos de 16 bits. Luego, el terminal remoto seleccionado envía una única palabra de estado de 16 bits.
  2. Transferencia de RT al controlador . El controlador de bus envía una palabra de comando de transmisión a una terminal remota. Luego, el terminal remoto envía una única palabra de estado, seguida inmediatamente por de 1 a 32 palabras.
  3. Transferencias RT a RT . El controlador de bus envía una palabra de comando de recepción seguida inmediatamente por una palabra de comando de transmisión. El terminal remoto transmisor envía una palabra de estado seguida inmediatamente de 1 a 32 palabras de datos. El terminal receptor envía entonces su palabra de estado.
  4. Comando de modo sin palabra de datos . El controlador de bus envía una palabra de comando con una subdirección de 0 o 31, lo que significa un comando de tipo Código de modo. El terminal remoto responde con una palabra de estado.
  5. Comando de modo con palabra de datos (transmitir) . El controlador de bus envía una palabra de comando con una subdirección de 0 o 31, lo que significa un comando de tipo Código de modo. El terminal remoto responde con una palabra de estado seguida inmediatamente por una sola palabra de datos.
  6. Comando de modo con palabra de datos (recibir) . El controlador de bus envía una palabra de comando con una subdirección de 0 o 31, lo que significa un comando de tipo Código de modo seguido inmediatamente por una sola palabra de datos. El terminal remoto responde con una palabra de estado.

MIL-STD-1553B también introdujo el concepto de transferencias de transmisión opcionales, en las que los datos se envían a todos los RT que implementan la opción, pero ningún RT responde, ya que esto causaría conflictos en el bus. Estos se pueden utilizar cuando se envían los mismos datos a múltiples RT, para reducir la cantidad de transacciones y así reducir la carga en el bus de datos. Sin embargo, la falta de respuestas explícitas por parte de los RT que reciben estas transmisiones significa que estas transferencias no pueden volver a intentarse automáticamente en caso de un error en la transacción.

Se permiten cuatro tipos de transacciones de transmisión entre el BC y todos los RT capaces:

Figura 7: Formatos de transferencia de información de transmisión
  1. Transferencia de controlador a RT(s) . El controlador de bus envía una palabra de comando de recepción con una dirección de terminal de 31, lo que significa un comando de tipo transmisión, seguida inmediatamente por de 0 a 32 palabras de datos. Todos los Terminales Remotos que implementen transmisiones aceptarán los datos pero ningún Terminal Remoto responderá.
  2. Transferencias RT a RT(s) . El controlador de bus envía una palabra de comando de recepción con una dirección de terminal de 31, lo que significa un comando de tipo transmisión, seguida inmediatamente por un comando de transmisión. El terminal remoto transmisor envía una palabra de estado seguida inmediatamente de 1 a 32 palabras de datos. Todos los Terminales Remotos que implementen transmisiones aceptarán los datos pero ningún Terminal Remoto responderá.
  3. Comando de Modo Sin Palabra de Datos (Broadcast) . El controlador de bus envía una palabra de comando con una dirección de terminal de 31 que significa un comando de tipo transmisión y una subdirección de 0 o 31 que significa un comando de tipo Código de modo. Ninguna terminal remota responderá.
  4. Comando de modo con palabra de datos (transmisión) . El controlador de bus envía una palabra de comando con una dirección de terminal de 31 que significa un comando de tipo transmisión y una subdirección de 0 o 31 que significa un comando de tipo Código de modo, seguida inmediatamente por una palabra de datos. Ninguna terminal remota responderá.

La palabra de comando se construye de la siguiente manera. Los primeros 5 bits son la dirección del terminal remoto (0–31). El sexto bit es 0 para recibir o 1 para transmitir. Los siguientes 5 bits indican la ubicación (subdirección) para almacenar u obtener datos en la Terminal (1–30). Tenga en cuenta que las subdirecciones 0 y 31 están reservadas para códigos de modo. Los últimos 5 bits indican la cantidad de palabras que se esperan (1–32). Todos los bits cero indican 32 palabras. En el caso de un Código de Modo, estos bits indican el número del Código de Modo (por ejemplo, Iniciar Autoprueba y Transmitir Palabra BIT).

La palabra de estado se decodifica de la siguiente manera. 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 solo bit, con algunos bits reservados. Un estado "uno" indica que la condición es verdadera. Más de una condición puede ser cierta al mismo tiempo.

La siguiente imagen ejemplifica muchos de los conceptos de protocolo y capa física explicados anteriormente. Por ejemplo, la dirección RT contenida en la palabra de comando tiene un valor de 0x3 (en el rango de 0 a 31). El sexto bit es 1, lo que indica una transmisión desde RT. La subdirección es 0x01. Los últimos 5 bits indican la cantidad de palabras que se esperan que tomen un valor de 1, que coincide con la única palabra de datos (valor 0x2) después de la palabra de estado.

También como se explicó anteriormente, los dispositivos deben comenzar a transmitir su respuesta a un comando válido dentro de 4 a 12 microsegundos. En el ejemplo, el tiempo de respuesta es 8,97 us, por lo que está dentro de las especificaciones. Esto significa que el Terminal Remoto (RT) número 3 ha respondido a la consulta del Controlador de Bus después de las 8.97 us. La amplitud de la consulta es menor que la amplitud de la respuesta porque la señal se prueba en una ubicación más cercana al terminal remoto.

En la Palabra de Estado, los primeros 5 bits son la dirección del Terminal Remoto que está respondiendo, en este caso 0x3. Una transferencia correcta muestra la misma dirección RT en la palabra de comando que en la palabra de estado.

Una transferencia de RT a BC, con 1 palabra de datos

Descripción conceptual

Figura 1: Ejemplo de arquitectura de bus de datos multiplex MIL-STD-1553B

La Figura 1 muestra un sistema MIL-STD-1553B de muestra que consta de:

El controlador del autobús

Sólo hay un controlador de bus a la vez en cualquier bus MIL-STD-1553. Inicia toda la comunicación de mensajes a través del bus.

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

La especificación 1553B dicta que todos los dispositivos del sistema estén conectados a un par de buses redundantes para proporcionar una ruta de datos alternativa en caso de daño o falla del bus principal. Los mensajes de autobús solo viajan en un autobús a la vez, según lo determine el controlador del autobús.

Controlador de bus de respaldo

Si bien puede haber solo un BC en el bus a la vez, el estándar proporciona un mecanismo para la transferencia a un controlador de bus de respaldo (BBC) o (BUBC), utilizando indicadores en la palabra de estado y códigos de modo. Esto puede usarse en operación normal donde el traspaso ocurre debido a alguna función específica, por ejemplo, traspaso hacia o desde un BC que es externo a la aeronave, pero conectado al autobús. Los procedimientos de traspaso en condiciones de falla y falla generalmente implican conexiones discretas entre los BC principal y de respaldo, y el respaldo monitorea las acciones del BC principal durante la operación. Por ejemplo, si hay una inactividad prolongada en el bus que indica que el BC activo ha fallado, el siguiente BC de respaldo de mayor prioridad, indicado por las conexiones discretas, tomará el control y comenzará a operar como el BC activo.

El monitor del autobús

Un Bus Monitor (BM) no puede transmitir mensajes a través del bus de datos. Su función principal es monitorear y registrar las transacciones del bus, sin interferir con el funcionamiento del Controlador del Bus o de los RT. Estas transacciones de autobús registradas se pueden almacenar para su posterior análisis fuera de línea.

Idealmente, un BM captura y registra todos los mensajes enviados a través del bus de datos 1553. Sin embargo, registrar todas las transacciones en un bus de datos ocupado puede resultar poco práctico, por lo que a menudo se configura un BM para registrar un subconjunto de las transacciones, según algunos criterios proporcionados por el programa de aplicación.

Alternativamente, se utiliza un BM junto con un controlador de bus de respaldo. Esto permite que el controlador de bus de respaldo "comience a funcionar", si es necesario que se convierta en el controlador de bus activo.

La terminal remota

Se puede utilizar una terminal remota para proporcionar:

Por ejemplo, en un vehículo con orugas, una terminal remota podría adquirir datos de un subsistema de navegación inercial y enviar esos datos a través de un bus de datos 1553 a otra terminal remota, para mostrarlos en un instrumento de la tripulación. Ejemplos más simples de terminales remotas podrían ser interfaces que encienden los faros, las luces de aterrizaje o los anunciadores de un avión.

Planes de Pruebas para Terminales Remotas:

El Plan de prueba de validación de RT está destinado a la verificación del diseño de terminales remotas diseñadas para cumplir con los requisitos de AS 15531 y MIL-STD-1553B con Aviso 2. Este plan de prueba se definió inicialmente en MIL-HDBK-1553, Apéndice A. Se actualizó en MIL-HDBK-1553A, Sección 100 . El plan de pruebas lo mantiene el Subcomité de Redes de Aviónica SAE AS-1A como AS4111 .

El Plan de pruebas de producción de RT es un subconjunto simplificado del plan de pruebas de validación y está destinado a las pruebas de producción de terminales remotas. Este plan de prueba lo mantiene el Subcomité de redes de aviónica SAE AS-1A como AS4112 .

Características del hardware del autobús

El hardware del bus incluye (1) cableado, (2) acopladores de bus, (3) terminadores y (4) conectores.

Cableado

La industria ha estandarizado el tipo de cable como cable twinax con una impedancia característica de 78 ohmios , que es casi el punto medio del rango de especificación de 70 a 85 ohmios.

MIL-STD-1553B no especifica la longitud del cable. Sin embargo, la longitud máxima del cable está directamente relacionada con el calibre del conductor del cable y el retardo de la señal transmitida. Un conductor más pequeño atenúa la señal más que un conductor más grande. El retardo de propagación típico para un cable 1553B es de 1,6 nanosegundos por pie. Por lo tanto, el bus de extremo a extremo de 30 m (100 pies) tendría un retraso de propagación de 160 nanosegundos, que es igual al tiempo de subida promedio de una señal 1553B. Según MIL-HDBK-1553A, cuando el tiempo de retardo de propagación de una señal es superior al 50% del tiempo de subida o bajada, es necesario considerar los efectos de la línea de transmisión. Este tiempo de retraso es proporcional a la distancia propagada. Además, se debe tener en cuenta la distancia real entre el transmisor y el receptor, y las características de forma de onda individuales de los transmisores y receptores.

MIL-STD-1553B especifica que la longitud más larga del ramal es de 20 pies (6,1 m) para ramales acoplados a transformador, pero se puede exceder. Sin ramales conectados, el bus principal parece una línea de transmisión de longitud infinita sin reflejos molestos. Cuando se agrega un trozo, el bus se carga y se produce una falta de coincidencia con las reflexiones resultantes. El grado de desajuste y distorsión de la señal debido a las reflexiones son función de la impedancia presentada por el ramal y la impedancia de entrada del terminal. Para minimizar la distorsión de la señal, es deseable que el trozo mantenga una alta impedancia. Esta impedancia se refleja de regreso al autobús. Al mismo tiempo, sin embargo, la impedancia debe mantenerse baja para que se entregue la potencia de señal adecuada al extremo receptor. Por lo tanto, es necesario un equilibrio entre estos requisitos contradictorios para lograr la relación señal-ruido y el rendimiento de la tasa de error del sistema especificados (para obtener más información, consulte MIL-HDBK-1553A).

aplastar

Figura 9: Interfaz de bus de datos usando acoplamiento de transformador

Cada terminal, RT, BC o BM, está conectado al bus a través de un trozo, formado por un tramo de cable del mismo tipo que el propio bus. MIL-STD-1553B define dos formas de acoplar estos ramales al bus: ramales acoplados a transformador y ramales acoplados directos. Se prefieren los terminales acoplados a transformadores por su tolerancia a fallas y una mejor adaptación a la impedancia del bus, y la consiguiente reducción de reflexiones, etc. El apéndice de MIL-STD-1553B (en la sección 10.5, Stubbing) establece "El método preferido de stubping es para usar terminales acoplados a transformador... Este método proporciona los beneficios de aislamiento de CC, mayor rechazo de modo común, duplicación de la impedancia efectiva del terminal y aislamiento de fallas para todo el terminal y terminal... debe evitarse en la medida de lo posible. Los terminales acoplados no proporcionan aislamiento de CC ni rechazo de modo común para el terminal externo a su subsistema. Además, cualquier falla de cortocircuito entre las resistencias de aislamiento internas del subsistema [sic] (generalmente en una placa de circuito) y la unión del bus principal provocará una falla en todo el sistema. bus Se puede esperar que cuando la longitud del trozo de acoplamiento directo supere los 1,6 pies (0,49 metros)], comenzará a distorsionar las formas de onda del bus principal".

El uso de terminales acoplados a transformadores también proporciona una protección mejorada para los terminales 1553 contra rayos. El aislamiento es aún más crítico en los nuevos aviones compuestos donde el revestimiento del avión ya no proporciona un escudo Faraday inherente como era el caso de los aviones con revestimiento de aluminio. [11]

En un ramal acoplado a un transformador, la longitud del cable ramal no debe exceder los 20 pies (6,1 m), pero se puede exceder "si los requisitos de instalación lo dictan". El transformador de acoplamiento debe tener una relación de espiras de 1:1,41 ± 3,0 por ciento. Ambas resistencias R deben tener un valor de 0,75 Zo ± 2,0 por ciento, donde Zo es la impedancia característica del bus a 1 MHz.

Figura 10: Interfaz de bus de datos usando acoplamiento directo

En un ramal de acoplamiento directo, la longitud del cable ramal no debe exceder 1 pie, pero nuevamente esto puede excederse si los requisitos de instalación lo dictan. Las resistencias de aislamiento R deben tener un valor fijo de 55 ohmios ± 2,0 por ciento.

Acopladores de autobús

Los ramales para RT, BC o BM generalmente se conectan al bus a través de cajas de acoplamiento, que pueden proporcionar una o varias conexiones de ramal. Estos proporcionan el blindaje requerido (≥ 75 por ciento) y, para los terminales acoplados por transformador, contienen los transformadores de acoplamiento y las resistencias de aislamiento. Tienen dos conectores externos a través de los cuales se alimenta el bus y uno o más conectores externos a los que se conecta el ramal o ramales. Estos conectores cortos no deben terminarse con resistencias correspondientes, sino que deben dejarse en circuito abierto cuando no se utilicen, con tapas ciegas cuando sea necesario. Uno de los conectores de bus puede terminar donde el acoplador de bus esté físicamente en el extremo del cable de bus, es decir, normalmente no se considera esencial tener una longitud de cable de bus entre el último acoplador de bus y la resistencia de terminación.

Terminación del cable

Ambos extremos del bus, ya sea que incluya un acoplador o una serie de acopladores conectados entre sí, deben terminar (de acuerdo con MIL-STD-1553B) con "una resistencia, igual a la impedancia característica nominal del cable seleccionado (Zo) ± 2,0 por ciento." Normalmente es de 78 ohmios. El propósito de la terminación eléctrica es minimizar los efectos de los reflejos de la señal que pueden causar distorsión de la forma de onda. Si no se utilizan terminaciones, la señal de comunicaciones puede verse comprometida causando interrupciones o fallas intermitentes en las comunicaciones.

Conectores

La norma no especifica los tipos de conectores ni cómo se deben cablear, aparte de los requisitos de blindaje, etc. En entornos de laboratorio, se utilizan comúnmente conectores concéntricos de tipo bayoneta twinax . Estos conectores están disponibles en tamaños estándar ( tamaño BNC ), miniatura y subminiatura. En implementaciones de aviones militares, generalmente se utilizan conectores circulares MIL-DTL-5015 y MIL-DTL-38999 .

Evolución

STANAG 3910 (EFABus) combina un enlace 1553 o 1773 con buses adicionales de alta velocidad de 20 Mbps, ya sean ópticos o eléctricos. En la forma STANAG, el enlace de baja velocidad 1553/1773 sirve como canal de control para el enlace de alta velocidad. En la forma EFABus Express (EfEx), el enlace de alta velocidad actúa como su propio canal de control. De cualquier manera, los autobuses de alta y baja velocidad comparten el mismo modelo de direccionamiento y pueden comunicarse entre sí. [12]

STANAG 7221 (E1553) amplía un enlace 1553 con la capacidad de transportar una señal de 100 Mbps en el mismo cable sin interferir con la señalización antigua. [13] El concepto es similar a cómo ADSL evita las frecuencias de voz, pero se realiza en anchos de banda más altos. [14] Además del 1553B, también funciona con enlaces coaxiales, de par trenzado, portadores de línea eléctrica y ARINC 429 existentes . [15]

Sistemas similares

DIGIBUS (o Digibus , GAM-T-101) es la contraparte francesa de MIL-STD-1553. Es similar a MIL-STD-1553 en la misma noción de controlador de bus, terminal remota, monitor, misma velocidad de transmisión, pero la diferencia es que DIGIBUS utiliza enlaces separados para datos y comandos. [dieciséis]

GOST 26765.52-87 y su descendiente GOST R 52070-2003 son los equivalentes soviético y ruso, respectivamente,de MIL-STD-1553B. La codificación, la velocidad de datos, la estructura de palabras y los comandos de control son totalmente idénticos.

GJV289A es el equivalente chino de MIL-STD-1553. Según se informa, los aviones que utilizan este sistema pueden utilizar armas tanto soviéticas (autobús GOST) [17] como occidentales (autobús MIL-STD-1553). [18]

H009 (también llamado MacAir H009 ), introducido por McDonnell en 1967, fue uno de los primeros buses de datos de aviónica. Se trata de un bus dual redundante controlado por un Complejo de Control Central (CCC), con hasta 16 Unidades Periféricas (PU), que se comunican de forma síncrona mediante un reloj de 1 MHz. H009 se utilizó en los primeros aviones de combate F-15, pero debido a su sensibilidad al ruido y otros problemas de confiabilidad fue reemplazado por MIL-STD-1553.

Herramientas de desarrollo

Al desarrollar o solucionar problemas para MIL-STD-1553, es útil examinar las señales electrónicas. Un analizador lógico con capacidad de decodificación de protocolos, también un analizador de bus o analizador de protocolos, son herramientas útiles para recopilar, analizar, decodificar y almacenar las formas de onda de las señales electrónicas de alta velocidad.

Hardware

Unidad de gestión de protocolo (PMU) Intel M82553 que utiliza la tecnología CHMOS III . Este dispositivo cumple con el estándar de protocolo de interfaz de bus completo. [19]

Ver también

Fuentes

Referencias

  1. ^ "El carguero Cygnus llega a la estación espacial con una gran cantidad de suministros". Vuelo espacial ahora. 2017-04-23.
  2. ^ Comité de estandarización de sistemas de aviónica, Sistemas de interfaz de transmisión de datos de aviónica, parte 2: estándar de bus de datos multiplex de comando/respuesta de división de tiempo , Def Stan 00-18, número 2, 28 de septiembre de 1990
  3. ^ George Marsh, Typhoon: Europe's Finest , Avionics Today, 1 de junio de 2003.
  4. ^ [1] Archivado el 13 de marzo de 2013 en Wayback Machine .
  5. ^ "Avión de combate multifunción MiG-35". Archivado desde el original el 14 de marzo de 2007 . Consultado el 14 de noviembre de 2014 .
  6. ^ "El jet eléctrico". Philips, EH Semana de la aviación y tecnología espacial . 2007-02-05.
  7. ASSIST-QuickSearch - Perfil básico Archivado el 14 de diciembre de 2019 en Wayback Machine .
  8. ^ Resumen de cambios MIL-STD-1553B vs MIL-STD-1553C, Electra IC
  9. ^ MIL-STD-1773: Mecanización de fibra óptica de un bus de datos multiplex de comando/respuesta de división de tiempo interna de una aeronave
  10. ^ Christian Seidleck. Lecciones aprendidas del bus de datos de fibra óptica (FODB) MPTB AS-1773
  11. ^ Hegarty, Michael, "MIL-STD-1553 se vuelve comercial" [ enlace muerto permanente ]
  12. ^ Grupo de trabajo AECMA C2-GT9, Transmisión de datos de alta velocidad bajo STANAG 3838 o control equivalente de fibra óptica, prEN3910-001, Ed P1, ASD-STAN, 31/01/1996.
  13. ^ "MIL-STD-1553B: el bus de datos pasado y futuro". www.highfrequencyelectronics.com .
  14. ^ "STANAG 7221 動作概要 | MIL-STD-1553.jp". www.mil-std-1553.jp (en japonés) . Consultado el 14 de mayo de 2023 .
  15. ^ "STANAG7221". Kingsly Instrumentación y Comunicación Private Limited . Consultado el 14 de mayo de 2023 .
  16. ^ DIGIBUS
  17. ^ "Helicóptero de ataque Z-10, China". Tecnología del ejército .
  18. ^ Pembleton, Gary L. Evaluación de la innovación tecnológica en el PLA
  19. ^ Ormsby, John, editor, "Enfoque de nuevos productos: componentes: la unidad de gestión de protocolos M82553 ofrece a los diseñadores militares un único dispositivo para todos los modos de operación", Intel Corporation, Microcomputer Solutions, enero/febrero de 1988, página 12

enlaces externos