Результат интеллектуальной деятельности: УСТРОЙСТВО ПЕРЕДАЧИ ЗАЩИЩЕННОГО ФАЙЛА

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

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

Уровень техники

С недавнего времени авиационные компании предоставляют своим пассажирам услуги связи в полете, в частности возможность получать доступ к Интернету и отправлять/получать электронную почту через спутниковую связь. Для этого салон самолета оборудуют кабельной сетью типа Ethernet или сетью WLAN (IEEE 802.11b/g), к которой известным образом могут подключаться пассажиры. Описание такой системы связи можно найти, в частности, в международной заявке WO 00/14987.

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

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

На фиг.1 схематично показана бортовая сеть 100, разделенная на защищенную зону А и незащищенную зону В. Линии 110 связи являются однонаправленными линиями от А к В, например линиями связи Ethernet, использующими кабельный монтаж только с одной скрученной парой, соответствующей направлению связи от А к В. Такая система эффективно обеспечивает защиту зоны А, но все же имеет два основных недостатка. Прежде всего, она окончательно блокирует любую связь в направлении от зоны В к зоне А. Во-вторых, при передаче данных из зоны А в зону В прибор-получатель не может направить подтверждение о приеме в прибор-отправитель этих данных. Это не совместимо с большинством существующих протоколов связи и, кроме того, лишает прибор-отправитель возможности убедиться в нормальном прохождении передачи.

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

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

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

Предпочтительно два первых уровня первого протокола являются уровнями Ethernet. Например, стеком первого протокола является TFTP/UDP/IP/Ethernet.

Согласно первому варианту выполнения два первых уровня второго протокола являются уровнями ARINC 429.

Согласно второму варианту выполнения два первых уровня второго протокола являются уровнями CAN.

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

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

Фиг.1 - схематичный вид известной бортовой сети связи.

Фиг.2 - схематичный вид бортовой системы связи согласно первому варианту выполнения изобретения.

Фиг.3 - протокол связи между прибором защищенной зоны и прибором незащищенной зоны.

Фиг.4 - схематичный вид бортовой системы связи согласно второму варианту выполнения изобретения.

Фиг.5 - схематичный вид бортовой системы связи согласно третьему варианту выполнения изобретения.

Фиг.6 - фрейм, используемый на линии связи, работающей по протоколу ARINC 429.

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

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

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

На фиг.2 схематично показана бортовая система связи в соответствии с настоящим изобретением.

Обозначениями LRU₁ и LRU₂ показаны приборы связи, принадлежащие соответственно к защищенной зоне А и к незащищенной зоне В. Подсети, соответствующие зонам А и В, являются коммутируемыми и/или совместно используемыми сетями Ethernet. Например, подсеть зоны А может быть сетью AFDX (Avionics Full Duplex Switched Ethernet), описание которой можно найти в документе "CES White Paper on AFDX" на сайте www.ces.ch. Линии связи Ethernet зон А и В, такие как линии 240 и 241, могут быть типа дуплексных линий связи. Что же касается каждой линии связи Ethernet от зоны А к зоне В, такой как линия 210, то она обязательно должна быть симплексной.

Согласно изобретению каждая линия связи от зоны В к зоне А, такая как линия 220, отвечает протоколу, отличному от протокола линий связи 210, например протоколу ARINC 429, повсеместно используемому в области авиации. Протокол ARINC 429 нормализует физический уровень, а также уровень линии связи. Он использует пару скрученных проводов и однонаправленную передачу, в данном случае от В к А.

В альтернативном варианте линии связи от зоны В к зоне А должны соответствовать протоколу CAN (Control Area Network), распространенному в области автомобилей. Уровень линии связи и некоторые аспекты физического уровня протокола CAN нормализованы по стандарту ISO 11898-1. Этот протокол предусматривает передачу типа полудуплексной на простой паре проводов. На практике в рамках настоящего изобретения будет использоваться только передача от зоны В к зоне А.

На фиг.3 показаны стеки протоколов, применяемые в системе связи согласно варианту выполнения изобретения. Прибор LRU₁ использует первый стек 330 протокола для передачи по однонаправленной линии связи Ethernet и второй стек 350 протокола для приема данных по линии обратной связи, в данном случае линии связи 310, соответствующей протоколу ARINC 429. Симметрично прибор LRU₂ использует первый стек 340 протокола для приема данных по линии связи 310 Ethernet и второй стек 360 протокола для передачи по линии связи 320.

Предпочтительно первые стеки 330 и 340 протокола представляют собой TFTP/UDP/IP/Ethernet. Напомним, что TFTP (Trivial File Transfer Protocol) является протоколом передачи файла, нормализованным комитетом IETF. Его подробное описание можно найти в RFC 1350 по адресу www.ietf.org/rfc/rfc783.txt.

Когда прибор LRU₁ должен передать файл данных на LRU₂, уровень TFTP открывает временный сеанс при помощи команды записи (WRQ) и разбивает файл на блоки по 512 байт. Блоки передаются на транспортный уровень UDP после присоединения заголовка TFTP. Уровень UDP обеспечивает известную специалистам услугу уровня сообщения без логического соединения и проверки на ошибку. После этого обычным путем в кадрах Ethernet передаются датаграммы IP сообщения. При приеме данные проходят через стек 340 протокола в обратном направлении. Для каждого принятого сообщения TFTP это сообщение упаковывается в фреймы ARINC 429, как указано в 360 и будет пояснено ниже. Фреймы ARINC передаются обычным путем по линии связи 320, и распаковка сообщения производится в 351. Таким образом, для уровня TFTP стеков 330 и 340 все происходит, как если бы передача производилась в сети IP при помощи дуплексных линий связи.

Когда прибор LRU₂ должен передать файл данных на LRU₁, по инициативе LRU₁ открывается временный сеанс при помощи команды записи (RRQ). Передаваемый файл разбивается на блоки по 512 байт уровнем TFTP стека 340, и блоки объединяются с соответствующими заголовками TFTP. Сформированные таким образом сообщения TFTP упаковываются в фреймы ARINC, как показано в 361 и будет подробнее пояснено ниже. Фреймы ARINC передаются обычным путем по линии связи 320 и распаковываются в 351. После этого прибор LRU₁ передает сообщение подтверждения о приеме через стек 330 по симплексной линии связи 310 Ethernet. Сообщение подтверждения о приеме следует в обратном направлении через стек 340 протокола. Здесь тоже для уровня TFTP стеков 330 и 340 все происходит, как если бы передача производилась в сети IP при помощи дуплексной связи.

Линия связи ARINC 320 и механизм упаковки сообщений первого протокола в фреймы второго протокола образуют барьер доступа в защищенную зону.

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

На фиг.4 схематично показана бортовая система связи согласно второму варианту выполнения изобретения. В отличие от первого варианта выполнения с прибором LRU₂ незащищенной зоны могут сообщаться несколько приборов LRU₁, LRU₃, LRU₅ защищенной зоны. Для этого линия связи ARINC 420 типа многоадресной выполняет функцию линии обратной связи с указанными приборами. Напомним, что линия связи ARINC может быть соединена только с одним отправителем, но может обслуживать до двадцати получателей.

На фиг.5 схематично показана бортовая система связи согласно третьему варианту выполнения изобретения. В отличие от первого и второго вариантов выполнения прибор защищенной зоны, такой как LRU₁, может сообщаться с несколькими приборами незащищенной зоны LRU₂, LRU₄, LRU₆. Для этого прибор LRU₁ содержит несколько интерфейсов ARINC 429. Несколько линий связи ARINC 521, 522, 523, соединяющие соответственно приборы LRU₂, LRU₄, LRU₆ с указанными интерфейсами, выполняют функцию линий обратной связи. В этом варианте выполнения предпочтительно можно использовать шину CAN вместо линий связи ARINC, при этом шина CAN может быть соединена с несколькими отправителями.

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

Рассмотренные выше варианты выполнения требуют упаковки сообщений TFTP в фреймы второго протокола, например ARINC 429. Подробное описание протокола ARINC 429 можно найти в статье под названием "ARINC Protocol Tutorial" на сайте www.condoreng.com.

На фиг.6 схематично показан фрейм ARINC. Он состоит из 32-битового слова, содержащего пять полей. Бит Р является битом проверки четности. Поле SSM показывает статус работы прибора. Поле PAYLOAD на 19 бит содержит полезную нагрузку, в случае необходимости дополняемую битами вставки (PAD). Поле SDI позволяет идентифицировать адресат фрейма в случае многоадресной передачи. Наконец, поле LABEL показывает бортовой параметр, соответствующий полезной нагрузке и формату составляющих ее данных.

Далее будут рассмотрены сообщения TFTP, которые могут быть переданы после упаковки по линии обратной связи, а именно АСК, DATA, ERROR.

Как показано на фиг.3, когда прибор LRU₁ должен передать файл данных на прибор LRU₂, он передает ему сообщение с командой записи (WRQ). Если LRU₂ готов принять файл, он передает в LRU₁ сообщение с подтверждением. После этого для каждого полученного сообщения, содержащего блок данных файла, прибор LRU₂ отправляет в LRU₁ сообщение подтверждения, указывающее номер принятого блока. Конец файла детектируется уровнем TFTP стека 340, когда он получает блок из менее 512 байт. Первое сообщение для подтверждения команды записи условно содержит номер блока 0. Когда прибор LRU₁ передает блок данных, уровень TFTP стека 330 включает счетчик задержки времени. Если сообщение подтверждения не приходит до конца времени задержки, блок данных передается повторно при помощи сообщения TFTP.

Сообщение подтверждения АСК протокола TFTP содержит первое поле Opcode из двух байт, идентифицирующее тип сообщения (Opcode=4), и второе поле из двух байт, указывающее номер блока, прием которого подтверждается. Модуль упаковки включает в фрейм второго протокола второй байт Opcode (первый байт по-прежнему является нулевым для сообщения подтверждения), затем два байта номера блока. Он присоединяет к этому сообщению номера портов UDP прибора-отправителя (LRU₁) и прибора-получателя (LRU₂), используемых для передачи данных. Поскольку каждый номер порта кодируется на одном байте, то для сообщения подтверждения необходимо передать 7 байт, для чего потребуются 3 фрейма ARINC или только один фрейм CAN.

Когда прибор LRU₁ должен принять файл данных от прибора LRU₂, он отправляет ему команду считывания RRQ. Если прибор LRU₂ готов к передаче, то вместо подтверждения он отправляет непосредственно первый блок на 512 байт соответствующего файла. В ответ прибор LRU₁ передает сообщение АСК с подтверждением приема первого блока. Процесс продолжается, как и в предыдущем случае, до передачи последнего блока файла. Если уровень TFTP стека 340 не получает подтверждения в течение данного времени после передачи блока, он повторяет передачу.

Сообщение с данными DATA протокола TFTP содержит первое поле Opcode из двух байт, идентифицирующее тип сообщения (Opcode=3), второе поле из двух байт, дающее номер передаваемого блока, и поле на n байт, где 0≤n≤512, в котором содержится блок данных.

Модуль упаковки 361 включает в фрейм второго протокола второй байт Opcode (первый байт по-прежнему является нулевым для сообщения с данными), затем два байта номера передаваемого блока и, наконец, n байт рассматриваемого блока. Модуль 361 присоединяет к этому сообщению номера портов (UDP) прибора-отправителя (LRU₁) и прибора-получателя (LRU₂), используемых для передачи данных. Таким образом, для передачи блока данных из n байт необходимо передать n+7 байт, для чего потребуется Е[(n+7).8/19]+1 фреймов ARINC, где Е[x] дает целую часть x, и n+7 фреймов CAN.

Если LRU₂ не может принять запрос записи (WRQ) или считывания (RRQ), отправляемый прибором LRU₁, или если во время передачи данных произошла ошибка, уровень TFTP стека 340 отправляет сообщение об ошибке.

Сообщение об ошибке ERROR протокола TFTP содержит первое поле Opcode из двух байт, идентифицирующее тип сообщения (Opcode=5), второе поле из двух байт, содержащее код диагностированной ошибки, и, в случае необходимости, третье поле, содержащее строку ASCII, описывающую ошибку, после которого следует байт ноль. В нашем рассматриваемом случае это третье поле не используется.

Модуль упаковки 361 включает в фрейм второго протокола второй байт Opcode (первый байт по-прежнему является нулевым для сообщения ошибки), затем два байта кода ошибки. Наконец, модуль 361 присоединяет к этому сообщению номера портов (UDP) прибора-отправителя (LRU₁) и прибора-получателя (LRU₂), используемых для передачи данных. Таким образом, для передачи сообщения об ошибке необходимо передать 5 байт, что требует 3 фреймов ARINC или 5 фреймов CAN.

Если прибор LRU₂ соединен с несколькими приборами защищенной зоны, как во втором варианте выполнения, модуль упаковки 361 определяет значение поля SID фрейма ARINC в зависимости от адресата сообщения TFTP.

Вместе с тем, если система использует второй протокол, не позволяющий различать адресаты сообщения TFTP, то предпочтительно модуль 361 присоединяет к включаемому сообщению адрес IP прибора-получателя.

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

В случае четвертого варианта выполнения каждый модуль 361 присоединяет к упакованному сообщению соответствующие адреса IP прибора-отправителя и прибора-получателя сообщения TFTP.