Entiendo que el cohete transmite constantemente la información de telemetría a una instalación de ingeniería en la superficie. También entiendo que es normal que un canal de transmisión cree errores en los datos transmitidos. Sé que existen algoritmos de corrección de errores de datos basados en redundancia. Mi pregunta es, ¿qué sucede si un error es tan grande que el algoritmo no puede corregirlo? ¿El paquete fallido se vuelve a solicitar desde el cohete y se transmite nuevamente? ¿O se considera irrevocablemente perdido?
Es probable que esto se pregunte en referencia a un Tweet de Elon Musk sobre la falla de CRS-7. El texto del Tweet es:
Causa aún desconocida después de varios miles de horas de ingeniería de revisión. Ahora analizando datos con un editor hexadecimal para recuperar los últimos milisegundos.
En Reddit , alguien publicó esta excelente explicación. No es una gran fuente, pero es la mejor explicación que he visto hasta la fecha. Específicamente, este nodo :
Así no es como funciona esto en absoluto. Todo es CCSDS transmitido, por lo general. Cada paquete de 1024 bytes normalmente tiene su propio código de corrección de errores agregado, además de todas las demás características requeridas (marcadores de sincronización de cuadros, codificación de canal virtual, etc.).
Habiendo tenido que hacer este mismo análisis muchas, muchas veces, supongo que los datos están dañados, particularmente los marcadores de sincronización de cuadros (0x1ACFFC1D... cuando haces esto para ganarte la vida, sí, eso es lo primero que se te viene a la cabeza ). Cuando eso sucede, la corrección Reed-Solomon realmente no se puede aplicar porque el marco podría haberse deslizado un poco y eso empeoraría las cosas.
Por lo tanto, tienen que pasar por cada parte de la transmisión en un editor hexadecimal compensando manualmente las cosas un bit a la vez en busca de contenidos de paquete razonables (lo cual es casi imposible, ya que la carga útil está codificada en PN...), y luego, si ven eso, luego pueden extraer los símbolos de corrección RS y hacer una corrección de error, luego decodificar la versión corregida nuevamente. Luego, al siguiente Kb de datos... a mano. Puedes imaginar por qué esto toma un tiempo.
En un foro de Nasaspaceflight.com hubo un comentario interesante sobre la telemetría que vale la pena señalar:
Ya que estamos hablando de telemetría, arrojaré un poco de mi conocimiento al ring.
Construyo sistemas que procesan telemetría terrestre y de vuelo para naves espaciales y aviónica de instrumentos (no vehículos de lanzamiento).
No sé nada sobre la implementación de SpaceX, por lo que ni siquiera intentaré dar nada específico sobre sus vehículos.
Además, parte de lo que describo a continuación para las naves espaciales no se aplica a los vehículos de lanzamiento, ya que no hay tiempo para enviar comandos a un vehículo de lanzamiento, ya que la secuencia de lanzamiento es muy dinámica y depende en gran medida de secuencias de eventos preprogramadas. Hasta donde yo sé, no se envían comandos a un vehículo de lanzamiento durante el lanzamiento después del despegue, aparte de un comando de destrucción FTS.
Hay estándares en el trabajo para la telemetría, por ejemplo, CCSDS. También hay tantas implementaciones diferentes del 'estándar' como fabricantes de aviónica.
En todo lo que trabajo, el software de vuelo de hecho formatea la telemetría, empaquetando marcos dentro de encabezados. Hay múltiples capas de tramas en el trabajo, y puede haber muchos tipos diferentes de tramas de telemetría que caen a diferentes velocidades.
Algunas cosas suceden en un horario determinista, parte de la telemetría puede insertarse desordenadamente si la prioridad de los datos es lo suficientemente alta, y algunas cosas pueden fallar solo si hay ancho de banda disponible para enviarlo sin interrumpir el flujo de alta. telemetría prioritaria.
Dependiendo de los modos de operación de la aviónica, puede haber muchas tasas y mapas diferentes. Por ejemplo, si una nave espacial entró en modo seguro (o si un controlador de modo de emergencia se hizo cargo de la operación de una nave espacial), la velocidad de datos y el mapa de telemetría pueden cambiar a velocidades de bits bastante bajas (mejor para recuperar datos en tierra si hay es un problema de orientación o potencia con los transmisores), y los mapas pueden priorizar solo la telemetría de ingeniería crítica.
Muchos sistemas de aviónica pueden y adquieren datos más rápidamente de lo que envían la telemetría, en cuyo caso los mapas de telemetría definen con qué frecuencia y qué tipo de datos enviar. No es inusual tener instrumentación para hardware de desarrollo que envía telemetría y velocidades superiores a las normales.
Del mismo modo, cualquier condición anómala a menudo se priorizará para enviar ese estado como un marco de telemetría de alta prioridad.
En toda la aviónica de vuelo en la que trabajo, hay varias cajas que se comunican entre sí para enviar datos que terminan enviándose en telemetría. Un evento de alta energía puede (y de hecho es muy probable que lo haga) hacer que la telemetría deje de transmitirse incluso si la aviónica y el software de vuelo continúan adquiriendo datos.
A diferencia de los vehículos de lanzamiento, las velocidades y los mapas en la mayoría de las naves espaciales pueden controlarse y cambiarse de forma autónoma mediante el software de vuelo.
Casi todo en lo que trabajo es capaz de enviar telemetría sin cifrar, sin embargo, en vuelo, uso todo lo que trato de forma predeterminada para usar cifrado. Además del cifrado, también se puede aplicar la aleatorización.
No hay señales de telemetría analógica en nada de lo que trabajo y, hasta donde yo sé, los vehículos de lanzamiento modernos no transmiten ninguna telemetría analógica: todo está codificado, enmarcado y transmitido digitalmente por el software de vuelo dentro de la aviónica.
El otro Jim mencionado anteriormente mencionó que este tipo de evento podría significar el final de la telemetría de almacenamiento y reenvío, y tengo mi propia opinión al respecto. No creo que sea apropiado registrar SÓLO la telemetría en un vehículo de lanzamiento, y que la telemetría de ingeniería durante las primeras fases del lanzamiento deba transmitirse en vivo.
Veo el valor de un registrador de datos robusto que es esencialmente almacenamiento digital empaquetado de la manera más robusta posible, con la intención de construir un paquete que pueda sobrevivir a un percance y recuperarse. Este es un desafío muy difícil en un vehículo de lanzamiento, ya que operan justo al borde de tener un margen suficiente para incluso sobrevivir, ya que la física del lanzamiento es muy desafiante.
En el escenario anterior, donde un evento de alta energía interrumpe la comunicación entre la aviónica, un registro de alta velocidad podría proporcionar una visión crítica de los datos del sensor en un percance, en caso de que se recupere.
Sin embargo, espero que con la proliferación de sensores que generen ingeniería y telemetría operativa habrá algunos datos de menor prioridad que siempre se almacenarán y estarán disponibles para el enlace descendente si las condiciones lo permiten.
Siempre es mejor obtener todos los datos críticos del sensor casi en tiempo real que contar con la recuperación después de un percance. Elegir qué sensores son críticos es una actividad desafiante. En palabras del Sr. Musk, algunas fallas pueden ser contrarias a la intuición y un sensor que pensó que no era crítico puede, en retrospectiva, ser el sensor más crítico necesario para descifrar una cadena de eventos que conduce a una falla catastrófica del vehículo.
Vitya Smirnoff
tildalola
Vitya Smirnoff
Vitya Smirnoff