Результат интеллектуальной деятельности: МАРШРУТИЗАТОР ACARS ДЛЯ УДАЛЕННЫХ БОРТОВЫХ ПРИЛОЖЕНИЙ

Область техники

Настоящее изобретение в целом относится к области телекоммуникаций в авиации и конкретно к области передачи сообщений ACARS (Aircraft Communication and Reporting System, Авиационная система связи «запрос-ответ»).

Предшествующий уровень техники

В области авиации система ACARS позволяет передавать данные между летательным аппаратом и наземной станцией, в частности, обмениваться информацией типа АОС (Aeronautical Operational Control, Аэронавигационное оперативное управление) с операторами авиационных компаний или информацией типа АТС (Air Traffic Control, Управление воздушным движением) с авиадиспетчерами.

Система ACARS может использовать несколько сред передачи (называемых также media в данной области техники) или, точнее, несколько типов подсетей для обмена данными между летательным аппаратом и землей, а именно: подсетей ВЧ, СВЧ или SATCOM. Телекоммуникационная подсеть СВЧ обеспечивает связь типа «точка-точка» на линии прямого визирования с передатчиками/приемниками на земле, но эта связь характеризуется малой дальностью. Спутниковая телекоммуникационная подсеть SATCOM покрывает практически весь мир, за исключением полярных областей, но такая связь является дорогой. Подсеть ВЧ позволяет покрывать полярные области. Линию передачи данных между бортом самолета и землей в данной области техники обычно называют термином "datalink".

Как правило, передачу данных на землю осуществляют при помощи маршрутизатора ACARS. Этот маршрутизатор представляет собой прибор управления связью или CMU (Communacations Management Unit, Блок управления связью), который автоматически выбирает наиболее подходящую среду передачи (СВЧ, ВЧ, SATCOM) в зависимости от определенного числа параметров, в частности, от доступности среды передачи и от стоимости ее использования.

На фиг.1 схематично показана архитектура коммуникационной системы, использующей известный маршрутизатор ACARS 100. Такой маршрутизатор может включать одно или несколько приложений 110, выполненных с возможностью передачи на землю и приема данных с земли в виде сообщений ACARS. Эти приложения заранее определены при проектировании оборудования. Добавление нового приложения требует доводки маршрутизатора (и даже его замены), а также новой сертификации. Следовательно, установка нового приложения в маршрутизаторе является сложной операцией. Маршрутизатор ACARS можно также связать с удаленными бортовыми приложениями при помощи выделенных линий связи «точка-точка» типа Arinc 429. Протокол передачи сообщений ACARS по этим линиям связи определен в стандарте Arinc 619.

Удаленные бортовые приложения могут находиться в различных типах LRU (Line Replaceable Unit, легкосъемный блок), например, таких как модуль ACMS (Aircraft Condition Monitornig System, система контроля состояния летательного аппарата) для передачи в авиационную компанию сведений, связанных с состоянием самолета, модуль АТС для приема информации по управлению полетом, модуль CMS (Centralised Maintenance System, централизованная система технического обслуживания) для обмена данными по обслуживанию. Эти приложения ведут диалог с маршрутизатором при помощи выделенных интерфейсов, предусмотренных при проектировании маршрутизатора. Иначе говоря, невозможно предусмотреть, чтобы какое-либо дополнительное приложение могло воспользоваться услугой ACARS, предоставляемой маршрутизатором. Это предполагало бы, по меньшей мере, установку нового интерфейса и, следовательно, новую операцию сертификации.

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

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

Сущность изобретения

Объектом настоящего изобретения является коммуникационная система передачи сообщений ACARS, содержащая, по меньшей мере, один бортовой прибор, включающий приложение, выполненное с возможностью передачи и/или приема сообщений ACARS, маршрутизатор, выполненный с возможностью маршрутизации указанных сообщений, передаваемых в направлении или поступающих от множества подсетей (ВЧ/СВЧ/SATCOM), в которой указанный прибор и указанный маршрутизатор соединены с сетью AFDX, и указанное приложение выполнено с возможностью своей динамической регистрации в маршрутизаторе через указанную сеть, при этом маршрутизатор производит маршрутизацию указанных сообщений, только если указанное приложение в нем действительно зарегистрировано.

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

В этом случае запрос о регистрации и возможное подтверждение регистрации предпочтительно передают при помощи стека протоколов APOTA/TFTP/UDP/IP, где АРОТА обозначает уровень адаптации протокола между уровнем TFTP и приложением со стороны прибора и уровень адаптации протокола между уровнем Arinc 618 и уровнем NFTP со стороны маршрутизатора.

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

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

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

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

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

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

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

Краткое описание чертежей

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

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

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

фиг.3 - схема стеков протоколов, применяемых в системе, показанной на фиг.2;

фиг.4 - схема первой функциональной возможности уровня протокола АРОТА, показанного на фиг.3;

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

Подробное описание частных вариантов выполнения

В дальнейшем описании рассмотрим случай, когда летательный аппарат оборудован сетью AFDX (Avionics Full DupleX, Бортовая полнодуплексная сеть). Следует напомнить, что сеть AFDX, разработанная для нужд авиации, основана на коммутируемой сети Ethernet и была стандартизирована в стандарте Arinc 664, часть 7. В частности, подробное описание этой сети можно найти в документе под названием "AFDX protocol tutorial" по адресу URL:

http://sierrasales.com/pdfs/AFDXTutorial.pdf

Идея, лежащая в основе изобретения, состоит в том, чтобы предусмотреть протокол, позволяющий любому приложению, установленному в терминальном устройстве (End System), пройти динамическую регистрацию в маршрутизаторе с целью использования услуги связи ACARS. По сути, указанный протокол распространяет доступ к услуге связи ACARS на любое предварительно зарегистрированное удаленное приложение, как если бы оно находилось внутри маршрутизатора или как если бы бортовой прибор использовал протокол Arinc 619 на выделенной линии связи Arinc 429 с маршрутизатором.

На фиг.2 показана бортовая коммуникационная система, использующая маршрутизатор ACARS 200 согласно варианту выполнения изобретения. Маршрутизатор 200, а также один или несколько приборов 210, содержащих соответственно приложения, обозначенные client appl_1, client appl_2,…, client appl_N, соединены с сетью AFDX 220. Приборы 210 являются терминалами (End Systems) в соответствии со стандартом Arinc 664. Маршрутизатор предназначен для маршрутизации сообщений ACARS через множество подсетей, в частности, подсетей ВЧ, СВЧ, SATCOM и даже WiMAX или Wi-Fi, причем этот список не является исчерпывающем.

Каждое из приложений client appl_1, client appl_2,…, client appl_N выполнено с возможностью использования услуги ACARS. Для этого оно должно предварительно пройти регистрацию в маршрутизаторе согласно процедуре, которая подробно будет описана ниже. Добавление нового приложения не требует изменения аппаратной или программной конфигурации маршрутизатора, поэтому нет необходимости в его повторной сертификации. Следует отметить, что эта архитектура обеспечивает одновременно большие возможности модульности и гибкость изменения. В частности, можно легко индивидуализировать коммуникационную систему ACARS и интегрировать в нее самостоятельно разработанные приложения, сохраняя при этом тот же маршрутизатор.

На фиг.3 схематично показаны стеки 310 и 300 протоколов, соответственно применяемые со стороны приложения-клиента и маршрутизатора ACARS.

Нижние уровни протокола каждого стека представляют собой уровни сети AFDX, то есть уровень связи Ethernet, уровень сети IP и транспортный уровень UDP.

Со стороны приложения-клиента прикладной уровень, обозначенный в данном случае "приложение канала передачи данных ACARS", может передавать сообщения ACARS в маршрутизатор классическим образом в формате Arinc 620. Вместе с тем, в отличие от известных технических решений, где эти сообщения передаются по линиям связи Arinc 429 с использованием протокола передачи файла Arinc 619, в данном случае до передачи при помощи сеанса связи TFTP (Trivial File Transfer Protocol, Простой протокол передачи данных) они преобразуются уровнем адаптации протокола, обозначенным АРОТА (ACARS Protocol Over TFTP and AFDX, Протокол ACARS через TFTP и AFDX). Подробное описание протокола TFTP можно найти в документе RFC 1350 на сайте комиссии EETF. В нашем случае следует просто напомнить, что протокол TFTP является очень простым протоколом передачи файла, использующим UDP в качестве подчиненного транспортного уровня.

Ролью уровня АРОТА в стеке 310 протоколов является предоставление услуги ACARS (в виде SAP или Service Access Point, Точка доступа к услуге) для удаленного бортового приложения, иначе говоря, доставка услуги ACARS на уровень этого приложения. Для этого уровень протокола АРОТА ведет диалог с высшим прикладным уровнем при помощи сервисных примитивов ACARS и с нижним уровнем через сервисные примитивы передачи файла. Он также производит обмен пакетами, обозначенными APOTA-PDUs (Protocol Data Units, протокольные единицы данных) со своим аналогом в пакетном протоколе 300.

Со стороны маршрутизатора уровень протокола Arinc 618 управляет связью ACARS с землей. Так же, как и в предыдущем случае, уровень протокола АРОТА стека 300 протоколов ведет диалог с высшим уровнем при помощи сервисных примитивов ACARS и с низшим уровнем через сервисные примитивы передачи файла. Однако, в отличие от стека 310 протоколов, уровень протокола АРОТА не предоставляет услуги ACARS высшему уровню. Его основной функцией является обеспечение пересылки сообщений ACARS путем передачи файла через уровень TFTP.

В целом, уровень протокола АРОТА обеспечивает, в частности, следующие функции:

- доставка услуги ACARS от маршрутизатора на удаленные приложения;

- динамическая регистрация удаленных приложений, являющихся пользователями услуги ACARS;

- управление потоком на нисходящей линии связи;

- обнаружение неисправных приложений-клиентов;

- обнаружение потери услуги ACARS;

- контроль ошибок.

На фиг.4 схематично показан механизм доставки услуги ACARS для нисходящей линии связи, то есть связи воздух-земля (A/G).

Уровень протокола АРОТА кодирует в 410 сервисные примитивы ACARS, а также их возможные параметры, генерируя примитивы передачи файла. Предназначенный для передачи файл может содержать один или несколько пакетов APOTA-PDU. Название файла, в данном случае обозначенное "#Filename", как правило, содержит код, идентифицирующий приложение-отправитель, код идентификации получателя (то есть, маршрутизатора) и код, указывающий на тип сообщения, содержащегося в файле.

Уровень протокола АРОТА в 420 подает команду на уровень TFTP для передачи файла, содержащего пакеты APOTA-PDU, при помощи примитива передачи файла, обозначенного FT-Write. После этого уровень TFTP передает файл #Filename в виде пакетов TFTP PDU в соответствии со стандартом RFC 1350. Эти стандартные пакеты поступают на маршрутизатор через сеть AFDX при помощи протокола передачи файла TFTP. Уровень протокола АРОТА стека 300 протоколов получает извещение о получении файла #Filename при помощи примитива FT-Data-Ind. Если уровень протокола АРОТА согласен принять файл, он принимает содержащиеся в нем пакеты APOTA-PDU. На этапе 440 сообщения ACARS извлекаются из пакетов APOTA-PDUs и передаются на уровень протокола Arinc 618. Для восходящей линии связи уровни протокола АРОТА пакетных протоколов 300 и 310 работают симметрично.

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

Процедура начинается с отправки приложением запроса на регистрацию в виде сервисного примитива ACARS, обозначенного в данном случае A-Reg-req, передаваемого на уровень протокола АРОТА. Этот примитив позволяет удаленному приложению заявить себя в качестве нового клиента на уровне маршрутизатора и указать метки или подметки сообщений ACARS, которые приложение хочет передавать на землю или принимать с земли.

После этого уровень протокола АРОТА генерирует сервисный примитив передачи файла (FT-Write), параметрами которого являются название файла #Filename (RegReq), пакет APOTA-PDU, обозначенный в данном случае RefReq PDU, и номер порта TFTP (не показан). Название файла содержит тип передаваемого файла, в данном случае запрос на регистрацию, а также код идентификации приложения-отправителя.

При получении маршрутизатором уровень TFTP передает название принятого файла #Filename (RegReq) и пакет RegReq PDU. Пакет RegReq содержит, кроме всего прочего, список меток и подметок ACARS, которые приложение хочет зарезервировать.

Уровень АРОТА маршрутизатора проверяет, является ли запрос на регистрацию правильным, на основании информации, содержащейся в названии файла и/или в передаваемом пакете RegReq PDU. В случае положительного результата маршрутизатор локально регистрирует код рассматриваемого приложения, после чего отправляет сообщение о подтверждении регистрации. В противном случае, если запрос на регистрацию не проходит, маршрутизатор отправляет сообщение об отказе в регистрации. Отправка сообщения подтверждения или отказа в регистрации происходит, как и в предыдущем случае, при помощи сервисного примитива передачи файла (FT-Write). В рассматриваемом случае регистрация подтверждена, и уровень АРОТА генерирует указанный примитив с параметрами, такими как название файла #Filename (RegConf) и пакет RegConf PDU.

По получении терминалом сообщение подтверждения обрабатывается уровнем АРОТА, и подтверждение передается на приложение-клиент при помощи сервисного примитива ACARS, обозначенного A-Reg-conf.

Функцией протокола АРОТА является также контроль потока на нисходящей линии связи. Предпочтительно этот контроль потока предусматривают по причине неодинаковости скорости передачи между сетью AFDX (100 Мбит/с) и подсетями СВЧ/ВЧ/SATCOM (менее 31 кбит/с), что может привести к перегрузке на уровне маршрутизатора. При этом следует отметить, что на восходящей линии связи нет необходимости в каком-либо механизме контроля потока.

Произведя свою регистрацию в маршрутизаторе, удаленное приложение может передавать сообщения ACARS. Для этого уровень АРОТА удаленного приложения передает сервисный примитив передачи файла (FT-Write) на уровень АРОТА маршрутизатора. Параметрами этого примитива являются название файла, содержащее, в частности, код удаленного приложения, тип сообщения (восходящая или нисходящая линия связи) и размер сообщения.

Когда уровень АРОТА маршрутизатора принимает этот запрос, он прежде всего проверяет, чтобы удаленное приложение было действительно известным и зарегистрированным. В противном случае запрос отклоняется, и передача файла прекращается. После этого он проверяет тип сообщения, чтобы определить, должен ли он осуществить контроль потока. В случае подтверждения (нисходящая линия связи) он проверяет, чтобы размер сообщения был меньше, чем свободное место в его буфере приема. Если это так, маршрутизатор дает согласие на передачу TFTP. Если нет, эта передача отменяется, и уровень АРОТА маршрутизатора сообщает об этом уровню АРОТА удаленного приложения при помощи сервисного примитива с указанием об отказе. После этого уровень АРОТА удаленного приложения перестает передавать новые запросы.

Когда буфер приема маршрутизатора ACARS освобождается, поскольку хранившееся в нем сообщение успешно передано на землю или поскольку маршрутизатор получил команду на удаление сообщения, он сообщает об этом на уровень АРОТА удаленного приложения при помощи сервисных примитивов, указывающих соответственно на подтверждение передачи на землю или на удаление сообщения. По получении одного или другого из этих примитивов уровень АРОТА удаленного приложения может передавать новые запросы.

Предпочтительно название файла в параметре сервисного примитива передачи файла (FT-Write) может также содержать указание о приоритете и/или указание о стратегии маршрутизации. Эти указания позволяют маршрутизатору, с одной стороны, установить иерархию поступающих потоков и, с другой стороны, выбрать для каждого поступающего потока наиболее подходящую среду передачи ВЧ/СВЧ/SATCOM в зависимости от соответствующей степени их незанятости.

Уровень протокола АРОТА позволяет также обнаруживать неисправные удаленные приложения-клиенты. Удаленное приложение является неисправным, если оно больше не может обрабатывать сообщения, которые ему направляются по восходящей линии связи.

Чтобы обнаружить такую неисправность, уровень протокола АРОТА маршрутизатора периодически передает тестовое сообщение (в данном случае обозначенное "Testlink") в каждое из зарегистрированных приложений. При каждой отправке таймер устанавливают на значение (T_test) и, когда таймер доходит до конца этого времени, передают новое тестовое сообщение. Если для одного из этих приложений передача сообщения не состоялась, то есть если маршрутизатор не получил от этого приложения подтверждение приема до момента срабатывания указанного таймера, это приложение считается неисправным. Этот механизма обнаружения позволяет маршрутизатору определить максимально быстро, что удаленное приложение не работает, и, следовательно, не принимать сообщения, поступающие с земли и предназначенные для этого приложения.

В то же время, удаленное приложение может обнаружить потерю услуги ACARS, например, в случае проблемы в сети AFDX. Для этого удаленное приложение устанавливает таймер на значение Т_mon>T_test во время своей регистрации в маршрутизаторе. После этого таймер переустанавливают на значение Т_mon при каждом получении тестового сообщения (Testlink). Если реле времени доходит до конца установленного времени, приложение делает вывод об отсутствии тестового сообщения и о потере услуги ACARS.

Наконец, уровень протокола АРОТА позволяет контролировать ошибки, которые могут появиться в услуге ACARS. В частности, если обнаружена ошибка, например, если передача файла не состоялась, принятое сообщение неправильно сформатировано, название файла в параметре запроса на передачу является ошибочным, или если передача сообщения не разрешена при текущем состоянии уровня протокола, реакция на ошибку является следующей:

Если маршрутизатор обнаруживает ошибку, нарушающую сообщение, поступающее от удаленного приложения, это приложение просто «теряет» свою регистрацию в услуге ACARS. В частности, его регистрация аннулируется путем исключения кода приложения из списка зарегистрированных приложений. Приложение получает об этом извещение при помощи сообщения и должно произвести повторную регистрацию для возобновления доступа к услуге ACARS.

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