Как обрабатываются ошибки передачи данных телеметрии Falcon-9?

Скорее всего, это вопрос со ссылкой на твит Илона Маска о сбое CRS-7. Текст твита:

Причина до сих пор неизвестна после нескольких тысяч инженерно-часов проверки. Теперь анализ данных с помощью шестнадцатеричного редактора, чтобы восстановить последние миллисекунды.

На Reddit кто-то опубликовал это отличное объяснение. Не отличный источник, но лучшее объяснение, которое я видел на сегодняшний день. В частности, этот узел :

Эта штука работает совсем не так. Обычно это все передается CCSDS. К каждому пакету размером 1024 байта обычно добавляется собственный код исправления ошибок в дополнение ко всем другим необходимым функциям (маркеры кадровой синхронизации, кодирование виртуального канала и т. д.).

Мне приходилось самому много-много раз проводить такой же анализ, и я предполагаю, что данные повреждены, особенно маркеры синхронизации кадров (0x1ACFFC1D... когда вы этим зарабатываете на жизнь, да, это сразу приходит вам в голову) ). Когда это происходит, поправку Рида-Соломона на самом деле нельзя применить, потому что кадр может немного проскользнуть, и это усугубит ситуацию.

Таким образом, они должны пройти через каждую часть потока в шестнадцатеричном редакторе, вручную смещая вещи по одному биту за раз в поисках разумного содержимого пакета (что почти невозможно, поскольку полезная нагрузка кодируется PN...), а затем, если они видят что они могут затем извлечь символы исправления RS и выполнить исправление ошибок, а затем снова декодировать исправленную версию. Затем к следующему килобайту данных... вручную. Вы можете себе представить, почему это занимает некоторое время.

На форуме Nasaspaceflight.com был интересный комментарий по поводу телеметрии, на который стоит обратить внимание:

Раз уж мы заговорили о телеметрии, я добавлю немного своих знаний.

Я создаю системы обработки наземной и полетной телеметрии для космических кораблей и приборной авионики (не ракет-носителей).

Я ничего не знаю о реализации SpaceX, поэтому даже не буду пытаться рассказать что-то конкретное об их кораблях.

Кроме того, кое-что из того, что я описываю ниже для космических кораблей, не относится к ракетам-носителям, поскольку нет времени на отправку команд ракете-носителю, поскольку последовательность запуска очень динамична и в значительной степени зависит от предварительно запрограммированных последовательностей событий. Насколько мне известно, никаких команд на ракету-носитель во время старта после старта не посылается, кроме команды на уничтожение FTS.

Существуют стандарты для телеметрии, например, CCSDS. Также существует столько же различных реализаций «стандарта», сколько производителей авионики.

Во всем, над чем я работаю, программное обеспечение для полетов фактически форматирует телеметрию, упаковывая кадры в заголовки. Работает несколько уровней кадрирования, и может быть много разных типов кадров телеметрии, поступающих с разной скоростью.

Некоторые вещи происходят по детерминированному расписанию, некоторые данные телеметрии могут быть вставлены не по порядку, если приоритет данных достаточно высок, а некоторые вещи могут быть недоступны только при наличии доступной полосы пропускания для их отправки без нарушения потока высокопроизводительных данных. приоритетная телеметрия.

В зависимости от режимов работы БРЭО может быть множество различных тарифов и карт. Например, если космический корабль перешел в безопасный режим (или если контроллер аварийного режима взял на себя управление космическим кораблем), скорость передачи данных и карта телеметрии могут переключиться на довольно низкие скорости передачи данных (лучше для получения данных на земле, если есть проблема с наведением или питанием передатчиков), и карты могут отдавать приоритет только критически важным инженерным телеметриям.

Многие системы авионики могут и действительно собирают данные быстрее, чем отправляют телеметрию, и в этом случае карты телеметрии определяют, как часто и какие данные следует отправлять. Нет ничего необычного в том, что оборудование для разработки оборудования отправляет телеметрию и скорость выше обычной.

Точно так же любое аномальное состояние часто будет иметь приоритет для отправки этого состояния обратно в качестве кадра телеметрии с высоким приоритетом.

Во всей бортовой авионике, над которой я работаю, есть несколько блоков, взаимодействующих между собой для потоков данных, которые в конечном итоге отправляются в виде телеметрии. Энергетическое событие может (и очень вероятно) привести к прекращению передачи данных телеметрии, даже если авионика и бортовое программное обеспечение продолжают собирать данные.

В отличие от ракет-носителей, скорости и карты на большинстве космических кораблей могут управляться, а также переключаться автономно с помощью программного обеспечения полета.

Почти все, над чем я работаю, способно отправлять незашифрованные данные телеметрии, однако в полете все, с чем я имею дело, по умолчанию использует шифрование. Помимо шифрования, может применяться и рандомизация.

Ни на чем, над чем я работаю, нет сигналов аналоговой телеметрии, и, насколько мне известно, современные ракеты-носители не передают никакой аналоговой телеметрии — все это закодировано в цифровом виде, сформировано и передано бортовым программным обеспечением внутри авионики.

Другой Джим выше упомянул, что этот тип события может означать конец телеметрии с промежуточным хранением, и у меня есть свое мнение на этот счет. Я не считаю целесообразным ТОЛЬКО регистрировать телеметрию на ракете-носителе, и что инженерная телеметрия на ранних этапах запуска должна передаваться в прямом эфире.

Я вижу ценность надежного регистратора данных, который по сути является цифровым хранилищем, упакованным настолько надежно, насколько это возможно, с намерением создать пакет, который может выдержать сбой и быть восстановленным. Это очень сложная задача для ракеты-носителя, поскольку они работают на грани наличия достаточного запаса, чтобы даже выжить, поскольку физика запуска очень сложна.

В приведенном выше сценарии, когда высокоэнергетическое событие прерывает связь между авионикой, высокоскоростная регистрация могла бы предоставить некоторую критическую информацию о данных датчиков в случае аварии, если бы их можно было восстановить.

Однако я ожидаю, что с распространением датчиков, генерирующих инженерную и оперативную телеметрию, будут некоторые данные с более низким приоритетом, которые всегда будут храниться и предоставляться для нисходящей линии связи, если позволят условия.

Всегда лучше получить все важные данные датчиков практически в реальном времени, чем рассчитывать на их восстановление после аварии. Выбор того, какие датчики имеют решающее значение, является сложной задачей. По словам г-на Маска, некоторые отказы могут противоречить интуиции, и датчик, который вы считали некритичным, может, оглядываясь назад, оказаться самым важным датчиком, необходимым для расшифровки цепочки событий, которая приводит к катастрофическому отказу транспортного средства.