ЗАЩИЩЕННАЯ КОМПЬЮТЕРНАЯ СИСТЕМА С АРХИТЕКТУРОЙ "КЛИЕНТ-СЕРВЕР" ДЛЯ ИНТЕРАКТИВНЫХ ПРИЛОЖЕНИЙ

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

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

Стандарт ARINC 661 обеспечивает стандартизированную основу для реализации этих компьютерных архитектур в аэронавтике. Компоненты такой системы главным образом представляют собой:

- графический сервер, обеспечивающий возможность вычерчивать основные графические объекты на основании подсказок, принимаемых в форме запросов или команд, поступающих от экипажа или от "программ-клиентов". Этот сервер соответствует "системе отображения в кабине экипажа". Он содержит устройства отображения, человеко-машинные интерфейсы, базу данных характеристик «виджетов», или "библиотеку виджетов", и диалоговый протокол форматов "ARINC 661". "Виджет " представляет собой модуль программного обеспечения, связанный с графическим представлением;

- программы-клиенты, в стандарте ARINC 661 называемые "пользовательским приложением", или "UA", выполняющие функции оперативного управления и посылающие запросы на сервер, чтобы отображать информацию.

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

Фиг. 1 и 2 изображают функциональные потоки интерактивного сервера при инициализации системы и во время использования системы. Интерактивное приложение или программа-клиент посылает при инициализации системы в форме команд "конкретизации понятий" определение интерактивных страниц, которые сохраняются на сервере в форме модели "виджетов". "Виджет", как должно быть понятно, является модулем программного обеспечения, связанным с графическим представлением и поведением, представленным на устройствах отображения в кабине экипажа, которые также называются "DU". Виджеты позволяют экипажу с помощью средства управления давать инструкции системе управления воздушного судна и принимать информацию. На основании этой модели, как можно увидеть на фиг. 2, графические команды циклически генерируются и посылаются в графическую машину. Модель виджетов может быть модифицирована либо с помощью отправки команды от приложения по его собственной инициативе, либо с помощью действия пользователя на средстве управления, которое также генерирует ответ от приложения в форме команды. На фиг. 2 маршрут, предпринимаемый командами от этих средств, представлен жирными стрелками.

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

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

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

Проблема целостности относится к трем типам событий:

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

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

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

Для надежности необходимо предложить проверку на месте целостности для функции оперативного управления в системе кабины экипажа. Одна из обычно реализуемых методик является "обратной связью", которая состоит из верификации, посредством инверсного вычисления, согласованности параметров, отображаемых с помощью параметров, предоставляемых для системы. Математическое обоснование этого механизма основано на том, что произведение функции и ее обратной величины равно функции тождества (F°F^-1 = тождество). Таким образом, если можно найти обратную функцию F^-1 для отображаемой функции F критического параметра p, достаточно проверить, что F(F^-1(p))=p, чтобы гарантировать, что функция F действительно была выполнена. С точки зрения системы, чтобы гарантировать, что нет сбоя, который может влиять и на функцию, и на ее мониторинг, функции F и F^-1 должны быть достаточно отделенными. Определенные механизмы отделения или "разделения", таким образом, реализуются в структуре главной вычислительной машины каждой основной части вычисления, чтобы предотвращать возможное повреждение от сбоя первой функции, влияющее на вторую функцию (в частности, функцию мониторинга). Фиг. 3 иллюстрирует механизм управления "обратной связи" для подсистемы отображения, традиционно содержащий:

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

- средство для обработки упомянутых параметров и;

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

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

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

- отображения на устройствах "DU" критических значений данных, посылаемых в форме команд интерактивным приложением, размещенным в программе-клиенте. Ссылка в особенности будет делаться на отображение параметров двигателя, отправляемых соответствующими компьютерами;

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

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

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

Цель данного изобретения состоит в том, чтобы предложить механизм для защиты системы с архитектурой "клиент-сервер", который позволяет

- предотвращать случайный запуск функции пользователем;

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

- гарантировать согласованность информации между сервером и программами-клиентами.

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

- использовании "защитных блокировок";

- использовании математических "сигнатур";

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

фиг. 4 представляет различные потоки данных в контексте аэронавигационного приложения "клиент-сервер";

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

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

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

Фиг. 4 представляет блок-схему обменов данными между различными компонентами системы с архитектурой "клиент-сервер" авиационного электронного оборудования. Ядро системы представляет собой устройство отображения или DU. Оно отображает виджеты из модели виджетов, которая является структурой данных в запоминающем устройстве, управляемом сервером ARINC 661, хранящем свойства каждого виджета и иерархию между виджетами. Эта модель создается из "файла определения пользовательского приложения", или "UADF", более просто называемого ниже "DF". "DU" взаимодействует с различными средствами взаимодействия, управляемыми пользователем и "UA".

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

Защита отображения

Необходимо гарантировать защиту отображения критических элементов данных, посылаемых в ARINC 661 посредством UA или DU. Сервер ARINC 661 управляет отображением виджетов на DU в два этапа:

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

b) генерирование так называемых графических инструкций XGL посредством просматривания структуры данных.

Подсистема защиты должна охватывать эти два этапа.

a) Защита модели виджетов

Эту модель могут модифицировать два типа события:

- команда в A661, посылаемая посредством UA;

- событие, посылаемое авиационным электронным оборудованием кабины экипажа, называемым "CDS" (системой отображения в кабине экипажа), получающееся, например, в результате реконфигурирования устройств DU;

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

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

Поэтому защита модели виджетов сводится к следующему:

- управлению ее целостностью относительно DF при инициализации,

- затем гарантированию того, чтобы модель не была непредвиденно модифицирована во время выполнения программы;

- наконец, проверке того, что ее изменения согласовываются с командами ARINC 661, принимаемыми от приложений UA и от событий CDS.

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

Для этого процесса защиты подсистема защиты использует "сигнатуры", при этом сигнатура является математическим кодом, связанным с атрибутами защищенных виджетов. Этот код в общем представляет собой код "Хемминга". Следует отметить, что DF можно рассматривать как набор команд ARINC 661 и поэтому можно использовать один и тот же метод сигнатур для команды ARINC 661, посылаемой UA и файлом DF. Для этих сигнатур можно использовать функцию, которая принимает во внимание:

- тип команды и ее код A661;

- идентификаторы виджета;

- значение команды.

Например, при инициализации DU или при реконфигурировании подсистема согласованности вычисляет сигнатуру DF для защищенных виджетов и их "родителей" и сигнатуру модели и удостоверяется в том, что эти две сигнатуры согласовываются. Таким образом имеем:

SignatureDF = f(Σ атрибутов защищенных виджетов DF)

SignatureMod = f(Σ атрибутов защищенных виджетов модели)

Во время выполнения программы, пока никакое событие не модифицирует модель, подсистема согласованности циклически пересчитывает в каждом временном интервале Δt сигнатуру модели и удостоверяется в том, что SignatureMod в t+Δt = SignatureMod в t.

Когда модель виджетов модифицируется после команды ARINC 661, посылаемой посредством UA, подсистема согласованности выводит команду A661 из изменения атрибутов модели. Применяется следующее соотношение:

Команда A661 = F^-1 (изменение атрибутов модели)

Это верифицирует соответствие с принимаемой командой A661. В качестве первого примера, виджет x страницы у типа "кнопки-переключателя" переключается из ненажатого состояния в нажатое состояние. Функция F-1 (изменение атрибутов модели) позволяет выводить команду ARINC 661, называемую "Нажать виджет x страницы y". В качестве второго примера, "текстовый" атрибут виджета x2 "текстового окна" страницы у принимает значение "ALPHA" (АЛЬФА), которое позволяет выводить команду "Установить текст "ALPHA" виджет x2 страницы y".

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

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

- Чтобы предотвращать несогласованность модели с DF:

сравнение сигнатуры DF с сигнатурой модели при инициализации и при реконфигурировании.

- Чтобы избегать непредвиденной модификации модели в отсутствие команды:

сравнение сигнатуры модели во время выполнения программы между t и t+Δt;

- Чтобы избегать выполнения команды, которая не соответствует принимаемой команде:

вычисление команды ARINC 661 при модификации модели и сравнение с принимаемой командой.

b) Защита генерирования графических инструкций

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

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

Для всех защищенных виджетов типа "метки":

- найти команду "XGLWriteText" в стеке графических инструкций, соответствующих виджету. Для этого необходим параметр "ID (идентификатор) обратной связи" в команде XGLWriteText на модели SGLFeedbackVertex существующей функции;

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

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

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

- циклическая верификация согласованности соответствия стека генерируемых графических инструкций (XGL) и модели виджетов посредством добавления функций типа "ID обратной связи" в графическом языке XGL.

Защита согласованности действий

Согласованность действий на устройствах DU объединяет некоторое количество элементов, которые представляют собой:

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

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

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

а) Переходное взаимодействие

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

b) Взаимодействие отправки команды

Для взаимодействия отправки команды критические виджеты имеют так называемый тип "проверки допустимости UA". Эти виджеты имеют конкретный признак ожидания подтверждающего сообщения от клиентского приложения перед изменением состояния. Например, кнопка с двумя состояниями (нажатое/ненажатое) может посылать, в случае щелчка на курсоре, запрос на изменение состояния в UA, который запускает эту функцию и ожидает подтверждающего сообщения от UA прежде, чем фактически изменить его состояние. Если подтверждающее сообщение не достигает виджета в пределах определенного времени, он возвращается к своему начальному состоянию. Этот механизм гарантирует согласованность между состоянием HMI (человеко-машинного интерфейса) и состоянием UA, если возможно гарантировать обработку критических элементов данных между UA и DU, этот момент обсуждался в предыдущем разделе.

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

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

В качестве примера, фиг. 5 является частью графического представления кнопок с защитной блокировкой в заблокированном и разблокированном положениях в контексте отображения цепей системы управления двигателем. На этом чертеже показаны в центре чертежа два реактивных двигателя летательного аппарата, их схемы подачи топлива, индикации уровня "6100" и две кнопки управления, обозначенные "ENG1" (ДВИГ.1) и "ENG2" (ДВИГ.2), позволяющие включать или выключать реактивные двигатели. Можно ясно понять, что эти кнопки являются фундаментальными для правильного функционирования летательного аппарата. Эти две кнопки защищены посредством защитных блокировок, представленных на фиг. 5 затененными прямоугольниками. В заблокированном положении защитная блокировка закрывает кнопку, как можно увидеть на фиг. 5 слева. В разблокированном положении защитная блокировка находится в опущенном положении и больше не закрывает кнопку, как можно увидеть на фиг. 5 справа. Чтобы выполнить блокирование или разблокирование, пользователь приводит указатель, представленный двумя полужирными символами V, образующими X на фиг. 5, поверх выбранной защитной блокировки, затем щелкает по нему.

Таким образом, чтобы защитить взаимодействие отправки критической команды в ARINC 661 от DU в UA, подсистема защиты одновременно реализует следующие три средства:

- Чтобы избегать несвоевременного инициирования виджета на HMI из-за ошибки человека-оператора;

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

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

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

- Чтобы избегать отсутствия согласованности между HMI и UA, то есть того, что команды не принимаются во внимание и не выполняются посредством UA:

использование только виджетов "проверки допустимости UA".

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

c) Взаимодействие ввода и отображения элемента данных

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

Можно довольствоваться этим механизмом и рассчитывать на пользователя для того, чтобы контролировать, что ввод значения действительно представляет собой значение, учитываемое UA. Однако более безопасно использовать подсистему защиты в соответствии с изобретением, чтобы накладывать систему сигнатур на ввод значения или выбранное значение из DU в соответствии с типом рассматриваемого виджета (окна редактирования или комбинированного окна) в UA. Затем UA удостоверяется в согласованности сигнатуры с вводом значения или выбранным значением прежде, чем проверять допустимость и отправлять подтвержденное значение в DU. Вычисление сигнатуры значения должно быть выполнено настолько близко к вводу, насколько возможно, и в отдельном уровне программного обеспечения. Могут быть предусмотрены некоторые решения, например такие, как "интеллектуальная" клавиатура типа KCCU (модуля управления курсором от клавиатуры), способные сохранять результат ввода и вычислять его сигнатуру или иначе выполнять передачу сигнатуры "ключ за ключом", чтобы восстанавливать ввод на DU и контролировать согласованность.

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

Таким образом, чтобы защитить взаимодействие ввода или выбора критического значения в ARINC 661 от DU к UA посредством одновременного использования следующих четырех средств:

- Чтобы избегать несвоевременной отправки значения с помощью HMI и избегать после ввода отправки неправильного значения:

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

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

управление с помощью подсистемы защиты согласованностью защитной блокировки или диалогового окна с виджетом ввода посредством UA.

- Чтобы гарантировать посредством согласованности между человеко-машинным интерфейсом и UA, например такой, как подтверждение, что ввод значения был принят во внимание:

использование только виджетов "проверки допустимости UA".

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

Фиг. 6 организована в виде в трех столбцов, в которых первый содержит задачи, выполняемые "ПОЛЬЗОВАТЕЛЕМ", второй содержит задачи, выполняемые посредством "DU", третий содержит задачи, выполняемые посредством "UA". Строки задач сгруппированы в логическом порядке, стрелки указывают направление действий, причем строки задач следуют одна за другой в хронологическом порядке. Таким образом, пользователь манипулирует тремя задачами, в которых первая "Защитная блокировка щелчка" состоит в разблокировании выбранной защитной блокировки, вторая "Значение редактирования" состоит во вводе выбранного значения, наконец, третья "Значение мониторинга" состоит в проверке допустимости выбранного значения. DU передает принимаемую информацию, а UA манипулирует обеспечением защиты операций.

Фиг. 7 и 8 организованы в виде четырех столбцов, в которых первый содержит задачи, выполняемые "ПОЛЬЗОВАТЕЛЕМ", второй и третий содержат задачи, выполняемые двумя отдельными уровнями программного обеспечения, принадлежащими "DU" и обозначенными "Уровень 1 SW DU" и " Уровень 2 SW DU", четвертый содержит задачи, выполняемые посредством "UA". Строки задач сгруппированы, как и раньше, в логическом порядке, стрелки указывают направление действий, причем строки задач следуют одна за другой в хронологическом порядке. Пользователь, как и в случае фиг. 6, манипулирует задачами разблокирования, выбора и проверки допустимости.

Представленная ниже таблица резюмирует различные действия "подсистемы защиты" в соответствии с изобретением, распределенные между DU и UA и в соответствии с различными фазами обработки сервера ARINC 661.