Способ и устройство определения потребности для системы автоматического пилотирования летательного аппарата
Группа изобретений относится к способу и устройству определения потребности для системы автоматического пилотирования (АП) летательного аппарата. Для осуществления способа вводят поведенческие параметры АП , проверяют соответствие вводимых параметров языку предметной области, генерируют файлы определения потребности, сохраняют генерированные файлы определения потребности. Устройство определения потребности содержит модуль ввода поведенческих параметров, модуль проверки, модуль генерирования, модуль хранения. Обеспечивается полнота и точность определения потребности для разработки системы АП. 2 н. и 8 з.п. ф-лы, 5 ил.
Изобретение относится к области бортовых автоматических систем летательных аппаратов и, в частности, касается способа и устройства определения потребности для системы автоматического пилотирования летательного аппарата.
Система автоматического пилотирования (АП) осуществляет наведение летательного аппарата в соответствии с заданными значениями пилота и информирует экипаж о ситуации наведения. Управляя рабочими режимами и соответствующими правилами наведения, система АП преобразует заданные значения наведения в команды пилотирования. В конечном счете эти команды позволяют изменять движения летательного аппарата.
«Автопилот» (АП) соединен со многими электронными устройствами летательного аппарата (датчиками, системами тревожной сигнализации, системой управления полетом и т.д.). Кроме того, поведение АП зависит от определенного числа условий и параметров, которые меняются в зависимости от потребности, выражаемой авиаконструктором, например от поведения режимов наведения. Таким образом, АП тесно связан с летательным аппаратом и со специфическими потребностями авиаконструкторов.
Такие бортовые системы, как АП, подлежат сертификации, и их разработка не должна оставлять места неопределенностям. Любое упущение или недопонимание при определении потребности во время доводки АП в ходе или после сертификации существенно сказывается на качестве, времени и стоимости. Полное и достоверное определение потребности является, таким образом, существенным.
В настоящее время реализация определения потребности при разработке АП происходит исключительно документально с использованием документальных моделей. Полнота не поддается измерению и обеспечивается только процессом документальной ревизии.
Кроме того, потребность выражают на естественном языке, который часто является полисемичным. Таким образом, выражение потребности зависит от интерпретации. Следовательно, не существует возможности априорно и систематически гарантировать точность выражения потребности, его однозначность, полноту и отсутствие технических противоречий или несовместимостей.
Поэтому существует потребность в решении, которое позволяет наиболее полно сгруппировать потребности разработки АП и избежать ошибок при интерпретации.
Настоящее изобретение призвано удовлетворить эту потребность.
Изобретение призвано предложить устройство и способ для итеративного и полного определения потребностей разработки АП и проверки соответствия и полноты всего конфигурирования относительно области конфигурирования.
Предпочтительно настоящее изобретение обеспечивает полноту и точность определения потребности для разработки системы АП.
Изобретение призвано также предложить систему, адаптированную для пользователя, которым может быть разработчик оборудования или самолета.
Изобретение призвано предложить также интерфейс человек-машина для ввода параметров системы АП, соответствующий языку предметной области.
Предпочтительно настоящее изобретение можно динамично применять для любого нового окружения АП.
Предпочтительно настоящее изобретение обеспечивает легкий доступ к считыванию параметров конфигурирования АП.
Дополнительной задачей изобретения является обеспечение автоматического генерирования файла определения потребности системы АП при помощи единого ввода параметров пользователем.
Предпочтительно настоящее изобретение применяют в контексте авиационной промышленности.
Для достижения заявленного результата предложены способ, устройство и компьютерный программный продукт.
В частности, устройство определения потребности согласно языку предметной области (DSL) для системы автоматического пилотирования (АП) летательного аппарата содержит:
- модуль ввода поведенческих параметров АП;
- модуль проверки, связанный с модулем ввода, для проверки соответствия вводимых параметров языку предметной области;
- модуль генерирования, связанный с модулем ввода, для генерирования файлов определения потребности; и
- модуль хранения для сохранения генерированных файлов определения потребности.
Представлены различные варианты осуществления.
Различные аспекты и преимущества изобретения будут более очевидны из нижеследующего описания предпочтительного, но не ограничительного варианта выполнения со ссылками на прилагаемые чертежи, на которых:
Фиг. 1 - функциональные блоки устройства определения потребности АП в соответствии с изобретением.
Фиг. 2 - интерфейс человек-машина (ИЧМ) для ввода поведенческих параметров в предпочтительном варианте изобретения.
Фиг. 3 - другой интерфейс человек-машина (ИЧМ) для ввода поведенческих параметров в варианте выполнения изобретения.
Фиг. 4 - этапы заявленного способа для определения первоначальной потребности АП.
Фиг. 5 - этапы заявленного способа для определения потребности на основании уже существующей потребности.
На фиг. 1 представлена компьютерная среда (100), позволяющая применять устройство и способ в соответствии с изобретением для определения потребности автопилота или АП. На фиг. 1 показан пример функциональных модулей в предпочтительном, но не ограничительном варианте выполнения изобретения, позволяющем специалисту применять его версии.
Система 100 включает в себя устройство 101 ввода, выполненное с возможностью сбора данных для определения потребности конфигурируемого автопилота.
Система содержит также модуль 106 хранения для сохранения данных, связанных с определением области конфигурирования АП или языка предметной области “Domain Specific Language PA” (DSL АП) 107, и базу данных 108 из файлов 112 определения потребности.
DSL АП 107 формально выражает различные понятия области АП, их значение, характеризующие их параметры и структуру, области изменения этих параметров, возможные связи между понятиями, а также различные правила и специфические ограничения области АП (например, пределы значения одного параметра в зависимости от значения другого параметра).
Предпочтительно устройство содержит модуль проверки 104, который должен проверять, чтобы совокупность вводимых параметров 102 соответствовала DSL АП 107 с точки зрения структуры, области изменения и соответствия значений. С модулем проверки 104 связан модуль 105 генерирования файла 112 определения потребности. Содержание и структура файла 112 должны строго соответствовать вводу и DSL АП 107.
Средство 110 взаимодействия позволяет пользователю 109 вводить параметры 102. Средство 110 взаимодействия может представлять собой, например, клавиатуру компьютера, систему распознавания голоса, тактильный экран или любое другое средство взаимодействия, преобразующее действия пользователя в команду для устройства 101 ввода.
Интерфейс человек-машина (ИЧМ) 103 позволяет пользователю 109 изменять параметры 102 автопилота АП в соответствии с DSL АП 107 и/или просматривать и изменять предварительно установленное определение потребности.
Средство 111 отображения позволяет пользователю 109 ознакомиться со значением и структурой параметров 102, а также с ранее введенными данными. Средство 111 отображения может представлять собой, например, компьютерный экран, графический планшет, тактильное или аудиоустройство или любое другое средство, позволяющее пользователю ознакомиться с содержимым базы данных 108.
Модуль 106 хранения может быть запоминающим устройством, встроенным в компьютер 100, однако в варианте он может быть внешним. Это запоминающее устройство обеспечивает хранение определения области 107 конфигурирования и базы данных 108. Запоминающее устройство 106 может быть выполнено, например, в виде жесткого диска, памяти FLASH, устройства USB, диска CD-ROM и т.д. Язык DSL АП 107 и базу данных 108 можно также хранить в разных запоминающих устройствах. Компьютер 100 и запоминающее устройство 106 сообщаются между собой для обеспечения обмена данных между модулем 101 ввода и запоминающим устройством. Связь между компьютером и запоминающим устройством может быть проводной (например, электронной шиной, проводом USB, проводом Ethernet и т.д.) или беспроводной (например, WiFi, Bluetooth и т.д.).
Устройство позволяет в операционном режиме параметризовать среди всего прочего режимы, сегменты заданных значений режимов, сценарии активации режимов, сценарии последовательности действий. Устройство и способ могут также позволять параметризовать внешний и эксплуатационный контексты АП (данные, присутствующие в контекстах, и логические схемы выработки этих данных).
Устройство основано на заранее установленном языке DSL АП, обуславливающем определение поведенческих параметров АП. Оно полностью и однозначно определяет ключевые понятия АП. Оно структурирует и устанавливает правила определения режимов наведения.
В соответствии с языком DSL АП 107 устройство 101 ввода позволяет определять поведенческие параметры 102 системы АП, например:
- список режимов наведения, описанных в международных авиационных нормах (CS25/..). Предпочтительно этот список может быть расширен в соответствии с новыми потребностями;
- для каждого режима наведения его логику активации/деактивации;
- для каждого режима наведения его сегменты наведения;
- для каждого режима наведения его логические схемы индикации;
- для каждой логики активации/деактивации ее контекст активации/деактивации, ее запрос активации/деактивации и ее тип активации/деактивации;
- для каждого сегмента наведения его заданные пространственные значения, его логику последовательности действий, его пределы защиты, его режим реверсирования, его конфигурацию пилотирования;
- для каждого заданного пространственного значения его собственные характеристики;
- для каждой собственной характеристики заданного пространственного значения ее правило наведения и ее соответствующие параметры, ее заданное значение и ее соответствующие параметры;
- для каждого контекста активации его элементарные внешние условия, его элементарные эксплуатационные условия;
- для каждой логики индикации ее собственные характеристики.
В нижеследующих таблицах представлен пример определения поведенческих параметров АП. Эти таблицы, их содержание и интервалы представлены исключительно в качестве примера и не являются исчерпывающими.
Определение режима наведения:
| Понятие | Данные | Описание | Кардинальность | Диапазон |
| режим наведения | ссылка | идентификатор режима наведения | 1 | 1..50 |
| логика активации | ссылка логики активации режима наведения | 1..5 | IDT | |
| логика индикации | ссылка логики индикации | 1..10 | IDT | |
| список сегмента наведения | ссылка сегмента наведения | 1..20 | IDT | |
| категория заданных пространственных значений | категория заданного пространственного значения, связанного с режимом наведения | 1..6 | ГОР/ ВЕРТ/ СКОР/ КРЕН/ ТАНГАЖ/ РЫСКАНИЕ/ ТЯГА |
Определение логики индикации:
| Контекст | Данные | Описание | Кардинальность | Диапазон |
| логика индикации | ссылка | идентификатор логики индикации режима наведения | 1 | 1..20 |
| тип индикации | тип отображаемой информации | 1 | MODE/LAW | |
| положение | пара, определяющая положение (строка/столбец/ пиксели/…) |
1 | 1..100 | |
| цвет | 1 | ЗЕЛЕНЫЙ/ СИНЕ-ЗЕЛЕНЫЙ/ КРАСНЫЙ |
||
| мигание | более точно определить в соответствии с нормой | |||
| рамка | более точно определить в соответствии с нормой |
Определение логики активации:
| Контекст | Данные | Описание | Кардинальность | Диапазон |
| логика активации | ссылка | идентификатор логики индикации режима наведения | 1 | 1..150 |
| контекст активации | идентификатор элементарного условия активации | 1..20 | IDT | |
| булев оператор | идентификатор булева оператора | 1..19 | IDT | |
| триггер активации | идентификатор триггера активации | 1 | IDT | |
| тип активации | тип активации режима наведения | 1 | ARM/ENG |
Определение сегмента наведения:
| Понятие | Данные | Описание | Кардинальность | Диапазон |
| сегмент наведения | ссылка | идентификатор сегмента наведения | 1 | 1..400 |
| логика последовательности действий | ссылка логики последовательности действий сегмента | 1 | IDT | |
| режимы реверсирования | ссылка режима наведения реверсирования | 1..3 | IDT | |
| предел защиты | ссылка предела защиты | 1..10 | IDT | |
| конфигурация пилотирования | 1 | КРЕН/ ТАНГАЖ/ РЫСКАНИЕ/ ТЯГА|/ КОЛЛ |
||
| горизонтальное заданное пространственное значение | ссылка заданного значения | 0..1 | IDT | |
| вертикальное заданное пространственное значение | ссылка заданного значения | 0..1 | IDT | |
| заданное пространственное значение скорости | ссылка заданного значения | 0..1 | IDT | |
| заданное пространственное значение положения по крену | ссылка заданного значения | 0..1 | IDT | |
| заданное пространственное значение положения по тангажу | ссылка заданного значения | 0..1 | IDT | |
| заданное пространственное значение положения по рысканию | ссылка заданного значения | 0..1 | IDT | |
| заданное значение тяги | ссылка заданного значения | 0..1 | IDT |
Определение логики последовательности действий:
| Понятие | Данные | Описание | Кардинальность | Диапазон |
| логика последова-тельности действий | ссылка | идентификатор логики активации режима наведения | 1 | 1..150 |
| контекст последовательности действий | ссылка элементарного условия | 1..0 | IDT | |
| булев оператор | ссылка булева оператора | 1..19 | IDT | |
| триггер активации | ссылка триггера активации | 1 | IDT | |
| тип последовательности | тип последовательности | 1 | ИСХ/ ПЕРЕХ/ КОНЕЧН |
Определение заданного пространственного значения:
| Понятие | Данные | Описание | Кардинальность | Диапазон |
| заданное пространственное значение | ссылка | идентификатор заданного пространственного значения | 1 | 1..500 |
| категория | категория заданного пространственного значения | 1 | ГОР/ ВЕРТ/ СКОР/ КРЕН/ ТАНГАЖ/ РЫСКАНИЕ/ ТЯГА |
|
| правило наведения | ссылка правила наведения | 1 | IDT | |
| цель наведения | ссылка выработки цели | 1 | IDT |
Определение активации правила наведения:
| Понятие | Данные | Описание | Кардинальность | Диапазон |
| активация правила наведения | ссылка | идентификатор активации правила наведения | 1 | 1..50 |
| динамика | тип динамики заданного значения наведения | 1 | ЭКО/НОРМАЛЬН./ТОЧНО |
Определение логики выработки заданного значения наведения/пилотирования:
| Понятие | Данные | Описание | Кардинальность | Диапазон |
| выработка заданного значения наведения/ пилотирования |
ссылка | идентификатор выработки цели наведения | 1 | 1..100 |
| ссылка земля-воздух | 0..1 | ВОЗДУХ/ ЗЕМЛЯ/НЕИЗМЕН |
||
| магнитная ссылка | 0..1 | МАГНИТН/ ИСТИН/НЕИЗМЕН |
||
| ссылка скорости | 0..1 | CAS/МАХА/НЕИЗМЕН | ||
| ссылка высоты | 0..1 | БАРОМ/РАДИО/НЕИЗМЕН | ||
| источник | 0..1 | АВТО/РУЧН/НЕИЗМЕН | ||
| изменяемое | 0..1 | ИЗМЕНЯЕМ/ФКСИРОВАН/ НЕИЗМЕН |
Устройство 100 определения потребности выполнено с возможности генерирования файла 112 определения потребности на основании совокупности параметров 102, предварительно введенных оператором 109. Этот файл может служить, например, поддержкой для ревизий, чтобы подтвердить определение потребности, или служить для генерирования базы данных, предназначенной для конфигурируемого АП.
Генерируемый файл структурируют в соответствии с DSL АП 107, и его содержимое соответствует вводу оператора 109. Таким образом, модуль 105 генерирования может связывать каждый из вводов ИЧМ 103 с элементами структуры DSL АП 107. Например, ввод нового элемента данных эксплуатационного контекста должен соответствовать соответствующему понятию в DSL АП 107, то есть булевому элементу данных с единым идентификатором.
Этот механизм предпочтительно можно реализовать посредством нескольких вариантов, например можно разработать ИЧМ 103 таким образом, чтобы выделять заранее и систематически каждое поле ввода для одной структуры области конфигурирования. Другой вариант может состоять в разработке ИЧМ 103, который в момент исполнения динамически адаптирует свои поля для определения DSL АП и динамически связывает, таким образом, каждое поле со структурой языка предметной области АП.
Предпочтительно генерируемый файл 112 может иметь разные форматы: текстовой, машинного кода, исходного кода на таких языках программирования, как С, С++, Java, или исходного кода на интерпретируемом языке, таком как XML или XHTML.
Роль модуля 104 проверки заключается в проверке когерентности и соответствия совокупности вводов оператора относительно DSL АП 107, а также полноты и непротиворечивости вводов, например:
• непрерывности областей активации;
• когерентности поведения выражаемого АП по отношению к эксплуатационным ограничениям, определенным в DSL АП 107 (например, в случае самолета заход на посадку не может происходить на максимальной скорости Vmax), и т.д.
На фиг. 2 и 3 представлены примеры интерфейса человек-машина (ИЧМ) в предпочтительном варианте изобретения.
Предпочтительно интерфейс 300 содержит различные поля для ввода поведенческих параметров АП в соответствии с областью конфигурирования и для подсказки во время этого ввода. Интерфейс позволяет также пользователю просматривать и редактировать предварительно определенную конфигурацию.
Таким образом, ИЧМ позволяет параметризовать:
- логические схемы активации 200 режимов наведения, то есть сценарии включения и запуска с конкретным указанием:
- побуждающего события 300,
- предназначенного для оценки булева уравнения 304. Булево уравнение включает в себя оператор, такой как логическое И или логическое ИЛИ, связанный с одним (в случае унарного оператора) или с несколькими (в случае двоичного оператора) операндами. Операндом является либо булев элемент данных, взятый из контекста, такого как эксплуатационный контекст, либо другое булево уравнение;
- характеристики режимов наведения, в том числе:
- характеристики сегментов наведения 201, 202, 203, связанных с режимом: например, параметры положения самолета в полете, профиль скорости, вертикальный и горизонтальный профили с их категорией заданного значения, параметры пределов защиты, и т.д.;
- сценарий последовательности действий в сегментах: побуждающее событие и подлежащее оценке булево уравнение (работает аналогично логикам активации режимов наведения);
- внешний контекст, то есть:
- уточняют, какие данные необходимо выработать,
- уточняют операции, позволяющие выработать эти данные контекста: булевы операции, операции на оцифрованных значениях, цифровые операции, снабжение ссылками внешних данных
- эксплуатационный контекст 302, то есть:
- уточняют, какие данные необходимо выработать,
- уточняют операции, позволяющие выработать эти данные контекста: булевы операции, операции на оцифрованных значениях, цифровые операции, снабжение ссылками данных состояния АП.
Как было указано выше, язык предметной области поведения АП (DSL АП) позволяет определить, кроме всего прочего, сценарии активации 304 режимов АП. Каждая логика в своем определении снабжает ссылками события 300 и данные эксплуатационного и внешнего контекстов. Таким образом, устройство должно позволить каждому элементу из этих данных иметь свою ссылку в логических схемах, чтобы обеспечивать отображение и генерирование файла в точном соответствии с вводом оператора. Предпочтительно, согласно одному из решений, применяют ключ, который служит ссылкой. В этом случае устройство должно выдавать ссылочные ключи, обеспечивая при этом их единичность.
На фиг. 4 представлены этапы 400, осуществляемые в рамках заявленного способа для определения исходной потребности АП в предпочтительном варианте осуществления при помощи устройства 100.
На первом этапе 401 способ позволяет загрузить файл определения языка предметной области, чтобы в дальнейшем осуществлении способа можно было обратиться от модуля 104 проверки.
Следующие этапы 402-406 позволяют вводить поведенческие параметры рассматриваемой системы АП.
На этапе 402 необходим ввод первого параметра. Согласно способу, извлекают (403) определение соответствующего параметра в файле DSL.
На следующем этапе 404 активируют процедуру проверки достоверности ввода требуемого параметра.
Если тест на следующем этапе 405 подтверждает ввод, способ продолжают на этапе 406, чтобы протестировать, все ли параметры введены. Если остаются другие необходимые для ввода параметры, способ возвращается на этап 402 или продолжается этапом 407.
Если тест на этапе 405 не подтверждает ввод, способ возвращается на этап 402.
На этапе 407 проверяют в целом совокупность вводов параметров относительно DSL.
Если на этапе 408 все вводы являются правильными, способ переходит на этап 409 или возвращается на этап 402.
На этапе 409 на основании совокупности подтвержденных параметров генерируют файл определения потребности.
Файл записывают, и на этапе 410 его можно сохранить, и способ останавливается на этапе 411.
На фиг. 5 показаны этапы 500 в рамках заявленного способа для определения потребности на основании уже существующей.
На первом этапе загружают существующий файл определения потребности. Этот файл может быть предварительно сохранен в запоминающем модуле устройства или на внешнем средстве хранения информации.
На следующем этапе 502 загружают файл определения языка предметной области АП.
На этапе 53 способ позволяет инициализировать модуль ввода на основании параметров, содержащихся в существующем файле.
Затем в рамках способа осуществляют этапы 504-513 по тем же принципам, что и этапы 402-411, описанные выше со ссылками на фиг. 4. Ввод параметра в этом варианте осуществления может заключаться в подтверждении или в изменении уже существующего параметра.
Таким образом, данное описание иллюстрирует предпочтительный вариант осуществления изобретения, который не является ограничительным. Был выбран пример для обеспечения лучшего понимания принципов изобретения и его конкретное применение, однако они не являются ограничительными и должны позволять специалисту вносить изменения и предусматривать версии осуществления с сохранением тех же принципов.
Настоящее изобретение можно осуществлять при помощи материальных и/или программных средств. Оно может представлять собой компьютерный программный продукт на читаемом компьютером носителе. Носитель может быть электронным, магнитным, оптическим, электромагнитным или может быть передаваемым носителем типа инфракрасного. Такими носителями являются, например, полупроводниковые запоминающие устройства (Random Access Memory RAM, Read-Only Memory ROM, ленты, дискеты или магнитные или оптические диски (Compact Disk - Read-Only Memory (CD-ROM), Compact Disk - Read/Write (CD-R/W) and DVD).
1. Способ, осуществляемый на компьютере для определения согласно языку предметной области (DSL) потребности для системы автоматического пилотирования (АП) летательного аппарата, содержащий следующие этапы:
- вводят (402) поведенческие параметры АП;
- проверяют (404, 407) соответствие вводимых параметров языку предметной области;
- в ответ на этап проверки генерируют (409) файлы определения потребности; и
- сохраняют (410) генерированные файлы определения потребности.
2. Способ по п.1, в котором этап ввода включает в себя этапы:
- вводят (402) первый параметр;
- загружают (401) файл определения языка предметной области; и
- подтверждают (404) соответствие первого введенного параметра языку предметной области.
3. Способ по п.1 или 2, в котором этап генерирования файла определения потребности состоит в том, что генерируют файл в одном из форматов (текст, машинный код, исходный код).
4. Способ по п.3, в котором один из форматов генерируемого файла определения потребности является XML или XHTML.
5. Способ по п.3, в котором один из форматов генерируемого файла определения потребности исполнен на языке С, С++, Java.
6. Способ по п.5, содержащий перед этапом ввода следующие этапы:
- загружают заданный файл определения потребности; и
- загружают файл определения языка предметной области.
7. Устройство определения потребности согласно языку предметной области (DSL) для системы автоматического пилотирования (АП) летательного аппарата, при этом устройство содержит:
- модуль 101 ввода поведенческих параметров АП;
- модуль 104 проверки, связанный с модулем ввода, для проверки соответствия вводимых параметров языку предметной области;
- модуль 105 генерирования, связанный с модулем ввода, для генерирования файлов определения потребности; и
- модуль 106 хранения для сохранения генерированных файлов определения потребности.
8. Устройство по п.7, в котором модуль ввода дополнительно содержит интерфейс человек-машина 103, имеющий различные поля для ввода поведенческих параметров АП в соответствии с языком предметной области.
9. Устройство по п.7 или 8, в котором модуль ввода дополнительно содержит средства взаимодействия с пользователем.
10. Устройство по п.9, в котором модуль 106 хранения содержит первый модуль 107 для хранения языка предметной области и второй модуль 108 для хранения генерированных файлов определения потребности.
