В чем разница кодирования между форматами ARINC 429 BNR и BCD?

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

Поле данных

Это просто похоже на базовые арифметические понятия и меня не так сильно волнует. Насколько я понимаю, поле данных BCD работает следующим образом:

Data-Field = 0x12340 означает, что данные на самом деле 12 340 (двенадцать тысяч триста сорок) в базе 10.

Тогда поле данных BNR будет работать так:

Data-Field = 0x7FD1C означает, что данные на самом деле равны -740 (на основе арифметики с дополнением до двух).

Поле матрицы статуса знака

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

Мой вопрос

Итак, я полагаю, что в одном предложении мой вопрос будет звучать так: это единственные различия между типами сообщений ARINC?

Ответы (2)

Ваша основная стратегия декодирования выглядит правильной - я не проверял значения дважды, но логика верна. Однако обратите внимание, что разница между BCD и дополнением до двух не является единственной разницей между BNR и BCD (и дискретными метками, которые также распространены). Двоично-десятичные (BCD) и двоичные (BNR) метки обычно декодируют, как вы показали, но матрица состояния знака (SSM) играет большую роль в интерпретации этих данных, и ее использование не является обязательным.

Для меток BCD SSM сообщает, являются ли данные положительными или отрицательными (или какое направление указывает), следовательно, «Плюс, Север, Восток, Вправо, В, Выше» против «Минус, Юг, Запад, От, Ниже». Он также сообщает, если данные недействительны («Нет вычисленных данных»). Метки BNR включают информацию о знаке уже в кодировке с дополнением до двух, поэтому дублирование этой информации в SSM привело бы к потере ценной полосы пропускания. SSM по-прежнему информирует вас о неверных данных, но также может информировать о (не-)работе в реверсивном режиме («Предупреждение о сбое») или о правильном поведении («Нормальная работа»).

То, что это означает для данного LRU (линейно-заменяемого блока) 1 , может полностью отличаться от любого другого LRU. Чтобы быть уверенным в своей интерпретации метки, вы должны получить руководство по интеграции оборудования для конкретного рассматриваемого LRU, чтобы определить, в каком формате данные предоставляются или должны предоставляться, и что подразумевают значения SSM. Это руководство по интеграции является отдельным документом от любого руководства пользователя или руководства по техническому обслуживанию, которое вы могли получить с LRU для установки на воздушном судне. Обычно он предоставляется только производителям оригинального оборудования других LRU.

Например, метка BNR может по-прежнему содержать удобочитаемое значение, когда для SSM установлено значение «Предупреждение о сбое», но возможность использования этих данных зависит от того, что означает сбой для конкретного LRU. Однажды я столкнулся с LRU, который предоставлял метку барометрической высоты, которая возвращалась к высоте GPS над эллипсоидом, когда был установлен режим отказа. В то время это изменение представленной стоимости не было оценено по достоинству, но оно научило меня всегда сначала проверять SSM, прежде чем поверить в какое-либо конкретное значение. Кроме того, многие метки BNR также масштабируются с некоторым произвольным коэффициентом, чтобы обеспечить более широкий диапазон представляемых значений. Масштабный коэффициент указан в руководстве по интеграции и обычно является фиксированным значением, но я встречал некоторые метки со значениями, масштабированными значениями из других меток.

Формат дискретных меток всегда зависит от LRU. Чтобы узнать, что это за кодировка, вам необходимо иметь руководство по интеграции.

В конечном итоге разница между каждой конкретной меткой ARINC429 будет зависеть от конкретного оборудования, с которым вы взаимодействуете. Стандартные типы данных (BNR/BCD/Discrete) дают приблизительное представление о том, как упаковываются данные, но руководство по интеграции является авторитетным источником для кодирования данных.

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

Будет ли когда-нибудь случай, когда SSM используется в качестве пространства для поля данных (в BCD) аналогично тому, как это делается для чисел в формате BNR?
Я никогда не сталкивался с меткой BCD, которая переопределяла бы SSM для использования в качестве дополнительного пространства данных. Я сильно подозреваю, что любое устройство, которому требуется больше места для данных в новой версии, может изменить метку BCD на метку BNR, а не расширить BCD. Это изменение обеспечит гораздо больший прирост доступного пространства для кодирования. Тем не менее, может быть производитель устройства, который вместо этого решил использовать нестандартную метку BCD. Любые такие исключения должны быть хорошо задокументированы в руководстве по интеграции.
У меня в значительной степени была такая склонность, и я точно знаю, что BNR иногда переопределяет SSM.

Как вы могли заметить из этого руководства по спецификациям или этого отчета об ошибках , два бита, которые служат полем «знак-статус» для данных BCD, показывают только статус, а не знак для данных BNR. Коды состояния для данных BNR включают код «предупреждение о сбое»; нет необходимости сигнализировать предупреждение о сбое в матрице состояния знака данных BCD, поскольку отдельные цифры могут быть установлены на 1111 (четыре последовательные единицы), чтобы указать, что значения ненадежны.

Кроме того, когда широта и долгота закодированы с точностью до 0,1 минуты в двоично-десятичном формате, необходимо использовать другой двоично-десятичный формат, чем обычно. См. комментарий в разделе 2.1.2 отчета об ошибках . Позиции кодирования каждой цифры сдвигаются на 2 бита, так что первая цифра имеет максимальное значение 1 вместо 7, а биты 9 и 10 используются для данных.