Результат интеллектуальной деятельности: УСТРОЙСТВО ДОСТУПА К ДАННЫМ НА БОРТУ ЛЕТАТЕЛЬНОГО АППАРАТА

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

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

Известны устройства типа DDS (от Data Distribution Service), позволяющие объединить базы данных для их общего использования (выигрыш в согласовании, облегчение обслуживания и разработки приложений, оптимизация использования баз данных и т.д.). Эти устройства обеспечивают независимость клиентских приложений от предоставления данных и от их местонахождения. Однако такие устройства пока внедрены только на земле, так как не отвечают специфическим условиям в области авиационной электроники. Действительно, бортовые электронные сети, например, типа AFDX (от Avionics Full Duplex), не предназначены для транзактной обработки, а скорее для «вещания», то есть для передачи данных от передающего устройства на несколько приемных устройств. Это создает проблему, в частности, для управления доступами к полустатическим данным, то есть к данным, которые могут быть изменены. Таким образом, использование устройства типа DDS в области авиационной электроники не представляется возможным.

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

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

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

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

- средства для подписки бортового электронного приложения на абонемент на изменение единицы данных,

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

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

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

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

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

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

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

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

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

Фиг.2 представляет внутреннюю работу фасада;

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

Фиг.4 представляет пример прохождения обновления единицы данных в предпочтительном варианте выполнения изобретения.

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

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

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

На фиг.1 представлен пример применения устройства доступа к данным в соответствии с настоящим изобретением. Устройство содержит первый сервер ADBS1 и второй сервер ADBS2, дублирующий данные первого сервера ADBS1 для обеспечения резервирования. Устройство содержит также, по меньшей мере, одного клиента 101. Каждое из приложений, которому требуется доступ к данным, связано со своим собственным клиентом 101. Клиент 101 содержит фасад 103, который является промежуточным звеном между бортовым электронным приложением 102 и сервером (или серверами), для доступа к данным. Бортовому электронному приложению 102 требуется доступ для считывания и/или записи к данным, хранящимся в сервере, например, к данным аэронавигации, полетного плана, метеонаблюдений или извещений NOTAM. Таким образом, функцией фасада 103 является обеспечение доступа к данным для бортового электронного приложения 102. Клиенты и серверы ведут диалог через программное обеспечение связующего слоя, называемый middleware.

Согласно варианту выполнения изобретения, клиенты сгруппированы в семейства. Эти семейства существуют, например, в количестве трех (i) LocalClient - клиент в одном месте нахождения с сервером данных (Pattern “Database Server on Favored Client”), (ii) AvionicClient - бортовые электронные клиенты и (iii) OWClient - клиенты части бортовой электроники, называемой «открытый мир» (Open World).

В этом случае фасад указывает в запросе семейство, к которому принадлежит передающий клиент.

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

Оба сервера ADBS1, ADBS2 имеют аналогичную структуру. Сервер содержит: точку входа (или Front End) 104.1, 104.2 для управления запросами, передаваемыми клиентами, блок (или Pool) администраторов запросов 106.1, 106.2, по меньшей мере, одну базу данных 107.1, 107.2 и редактор (или “publisher”) 108.1, 108.2. Функцией блока администраторов запросов 106.1, 106.2 является обработка запросов. Администратор запроса предназначен для обработки только одного запроса за один раз. Точка входа 104.1, 104.2 содержит стек 105.1, 105.2 для хранения запросов в стадии ожидания. Редактор 108.1, 108.2 позволяет объявлять изменения единицы данных для клиентов. Редактор обеспечивает предоставление услуги объявления и абонирования на изменения данных, которая будет подробно описана ниже.

Точка входа 104.1, 104.2 сервера предназначена для управления запросами, передаваемыми в нее клиентами. Управление запросами включает в себя:

- сбор запросов, передаваемых клиентами,

- проверка стека 105.1, 105.2 запросов в состоянии ожидания для контроля его от насыщения (контроль потока),

- подтверждение прав доступа передающего клиента (контроль доступа),

- проверка, чтобы передатчик не превысил свою квоту запросов в состоянии ожидания (контроль потока),

- сохранение новых запросов в стеке 105.1, 105.2 запросов в ожидании обработки,

- хронологическая регистрация каждого запроса для мониторинга обработки каждого запроса,

- мониторинг нормальной работы администраторов запросов 106.1, 106.2.

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

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

В случае, когда клиенты сгруппированы в семейства, точка входа 104.1, 104.2 содержит несколько стеков запросов в ожидании обработки. Каждый из стеков выделен для одного семейства клиентов. Это позволяет ограничить возможные насыщения стека запросов. Например, можно выделить один стек для запросов, поступающих от OW (клиенты части бортовой электроники, называемой «открытый мир» или Open World). В случае притока запросов от OW насыщается только стек, выделенный для OW. С этого момента сервер отклоняет любые новые запросы, поступающие от OW, но продолжает накапливать запросы, поступающие от бортового электронного оборудования. Этот принцип выделенного стека обеспечивает защиту, например, от неисправного приложения OW, непрерывно выдающего запросы. Согласно такой же схеме можно также интегрировать один стек для запросов от привилегированного клиента. В схеме архитектуры, где сервер находится вместе с привилегированным клиентом (NavDB и FMS), можно предусмотреть защиту запросов этого привилегированного клиента при помощи выделенного стека. Этот вариант имеет смысл только в случае, когда привилегированный клиент и сервер работают на одном и том же вычислителе.

Этот вариант не применим для обработки запросов на запись, так как не позволяет гарантировать сохранение порядка запросов.

Роль точки входа в мониторинге блока администраторов запросов основана:

• на локальной (и удаленной) хронологической регистрации запросов,

• на числе учетов каждого запроса (чтобы обеспечить защиту от сообщения-убийцы (“killing message”),

• на степени заполнения стека (или стеков) запросов в ожидании обработки.

Эту информацию используют для пополнения статистики в рамках механизма распределения нагрузки между серверами (или load-balancing), позволяющего определять уровень занятости каждого сервера.

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

Каждый сервер содержит несколько администраторов запросов, сгруппированных в совокупность, называемую совокупностью или “pool” администраторов запросов 106.1, 106.2.

Каждый администратор запросов обрабатывает один запрос за один раз. Он отбирает первый запрос в ожидании обработки из стека 105.1, 105.2, управляемого точкой входа 104.1, 104,2. Администраторы запросов не должны содержать остаточных данных после обработки каждого запроса. Эти администраторы запросов называются администраторами без состояния (“stateless”). Эта характеристика позволяет избежать хранения промежуточного состояния. В случае остановки администратора запросов он запускается повторно сразу же без необходимости инициализации предварительного состояния. Запрос, который находился в стадии обработки во время остановки администратора запросов, переходит для обработки к другому администратору запросов. Администратор запросов, запускающийся повторно после остановки, берет из стека для обработки первый запрос, ожидающий обработку.

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

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

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

На фиг.2 показан пример внутренней работы фасада 103. Функцией фасада является обеспечение доступа к данным, хранящимся в серверах, для бортового электронного приложения 102. Определение предназначенных для использования серверов находится на стороне клиента. Чтобы скрыть местонахождение баз данных от бортовых электронных приложений, фасад выполняет роль промежуточного звена между клиентом и доступом к серверам. Фасад содержит:

- интерфейс 301.1, 301.2 доступа к данным (API) баз, обеспечивающий определенную восходящую совместимость различных версий интерфейса,

- средства 302 для локализации сервера (или серверов), в котором хранится единица данных, запрошенная пользователем,

- средства 303 для приема сообщений о состоянии серверов для определения их занятости,

- средства для переправки запроса на резервный сервер (или backup) в случае неисправности основного сервера,

- средства 304 для управления абонементами клиента на изменения полустатических данных, при этом указанные средства содержат:

• средства для приема уведомлений, передаваемых редактором 108.1, 108.2, по полустатическим данным,

• средства для подписки бортового электронного приложения 102 на абонемент на изменение единицы данных,

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

Фасад выполнен модульным, чтобы соответствовать потребностям клиента, для которого он предназначен. Фасад содержит только интерфейсы 301.1, 301.2, необходимые для клиента. Действительно, нет смысла предоставлять доступ ко всем базам данных, управляемым устройством, для всех клиентов.

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

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

Общая обработка запроса содержит следующие этапы:

- маркировка запроса по текущему времени,

- в случае запроса считывания предварительный поиск во внутренней кэш-памяти 312 (локальное хранение в фасаде),

- для случая считывания, если единица данных имеется в наличии в кэш-памяти 312, направление ответа клиенту,

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

- создание запросного сообщения и отправка в направлении сервера,

- постановка в очередь 312 (“pending queue”) запроса на стадии обработки,

- запуск таймера мониторинга этого запроса,

- при этом обработка ответа содержит следующие этапы:

• в случае успеха: извлекают из очереди ожидающий запрос и отвечают приложению, а также, в случае необходимости, обновляют кэш-память,

• в случае неудачи: применяют выбранную политику толерантности к ошибкам для возможной повторной передачи,

• в конце попыток снова относят окончательную ошибку приложению.

Повторная передача запроса на другой сервер в случае неудачи зависит от нескольких критериев:

- Причина предыдущей неудачи, если возврат был осуществлен сервером. Бесполезно повторно направлять «убивающее» сообщение, обнаруженное на уровне сервера.

- Политика толерантности к ошибкам (“fault tolerance”) (один или несколько дубликатов).

- Занятость «дубликата» в зависимости от его рабочего состояния.

Предпочтительно фасад содержит средства 305 для отправки запроса на наименее загруженный сервер. Приложения направляют запросы в серверы для получения доступа к данным. Эти средства 305 используются в случае применения функции распределения нагрузки (или “load balancing”) между серверами. Таким образом, этот отличительный признак позволяет избежать перегрузки одного сервера запросами, тогда как другой практически не используется. Эти средства 305 применяют, например, степень заполнения стека (или стеков) запросов в ожидании обработки серверов для определения наименее загруженного сервера.

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

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

На фиг.3 показан пример прохождения обновления единицы данных при помощи устройства в соответствии с настоящим изобретением. На практике приложение абонируется в фасаде. Например, рассматриваемое приложение абонируется на изменения в единице данных В. Сервер объявляет в виде событий изменения состояния данных на уровне администратора событий. Фасад информирует бортовое электронное приложение, если оно абонировано на изменения единицы данных. В данном примере во время изменения единицы данных А фасад получает уведомление, выдаваемое сервером, но не передает его на приложение, которое не абонировано по этой единице данных. Зато при изменении единицы данных В фасад получает уведомление от сервера и передает его на приложение, которое абонировано по этой единице данных.

Изменения состояний, выдаваемые редактором 108.1, 108.2, являются, например, изменением единицы данных, созданием единицы данных или стиранием единицы данных.

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

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

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

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

Согласно предпочтительному варианту выполнения изобретения фасады 103 распределены, по меньшей мере, на первую и вторую группы. На фиг.4 показано прохождение обновления единицы данных в этом предпочтительном варианте выполнения изобретения. Первая группа (Фасад 1) получает напрямую уведомления об изменениях в данных, передаваемые сервером. Фасады, принадлежащие к первой группе, дополнительно содержат средства для передачи упомянутых уведомлений об изменениях данных в фасады, принадлежащие ко второй группе (Фасад 2). Вместе с тем передача уведомлений в фасады второй группы происходит только после того, как упомянутые уведомления пройдут обработку и, в случае необходимости, будут переданы в бортовые электронные приложения, связанные с клиентами первой группы (эту обработку называют на фигуре локальной обработкой).

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