Как VOR или VORDME влияют на решение о кодировании между CF или IF-TF соответственно?

Первый; вы должны понимать, что ARINC 424 является отраслевым стандартом. Это не является нормативным. Нормативные документы публикуются RTCA (и EUROCAE в ЕС). Основные требования к кодированию базы данных в целом хорошо приняты и используются в отрасли, поскольку они необходимы для его основной функции взаимодействия. Но существует большая гибкость в том, насколько строго разработчики следуют стандарту.

Приведенный вами пример является примером применения стандарта. Обе комбинации ветвей допустимы, хотя IF-TF предпочтительнее. Обратите внимание, что в ARINC 424 используется слово «должен», а не «должен».

Поработав с FMS, я могу сказать, что VI-CF можно закодировать, но есть потенциальные проблемы, если XYZ не является VOR/DME. Как определяется FOOBR, если нет DME? Это должно быть определено как пересечение с радиалом от другого VOR и радиалом XYZ или как привязка Широта/Долгота.

Если это исправление широты/долготы, вы не можете надежно использовать участок CF, чтобы добраться до него, даже если он номинально находится на радиале, поскольку радиальная ошибка довольно велика и может привести к «пропуску исправления» при полете по радиалу. А поскольку фиксированная широта/долгота является стандартом RNP, предпочтительным типом участка будет участок IF-TF с IF в точке XYZ.

Если FOOBR является перекрестком, он может работать после того, как вы установились на участке CF, отслеживая пересекающийся радиал. Но перехват участка VI является плавающим исправлением, которое усложняет генерацию пути, поскольку относительное положение перехвата и FOOBR вычислить нелегко. Эта проблема значительно упрощается, если FOOBR представляет собой широту/долготу.

По моему опыту, я бы ожидал, что ветвь CF будет закодирована как IF-TF. Это обеспечивает фиксированные начальную и конечную точки и значительно упрощает вычисление перехвата. И для FMS не было бы необычным преобразовать исходный участок CF (на основе VOR/DME) в участок TF.